Passé quasi inaperçu dans nos contrées, un incendie est survenu le 5 juin à New Delhi (Inde). Il a causé des dégâts importants sur une salle serveur, perturbant des clients majeurs, dont des services Google Cloud en Inde, et laissé certains acteurs craindre la perte de décennies de données. DCmag a enquêté sur cet incident qui a mis en lumière les limites des dispositifs de sécurité (notamment les batteries lithium‑ion), les arbitrages d’infrastructure et les risques pour la continuité des services cloud.
- Le feu s’est déclaré le 5 juin dans une installation exploitée sous l’enseigne STT (ST Telemedia Global Data Centres) — site référencé comme STT Delhi 2 — et a « causé des dégâts importants » touchant principalement une salle de données et l’infrastructure électrique associée, selon une lettre interne de Tata Communications qui exploite également le site.
- Les autorités de Delhi ont indiqué que l’incendie semblerait être parti des unités de batteries lithium‑ion, ce qui expliquerait la violence du sinistre et la difficulté d’extinction. Elle ont indiqué que l’incendie était resté circonscrit à la salle des batteries, affectant une partie du troisième étage.
- Des clients rapportent des conséquences sévères, des pertes de plus de vingt ans de données opérationnelles et commerciales stockées sur les équipements affectés pour certains, des pertes économiques immédiates et le risque de perte d’abonnés suite aux interruptions pour d’autres.
- De son côté, Google a confirmé sur sa page d’incidents qu’un incendie dans un centre tiers avait entraîné une coupure d’alimentation d’équipement réseau, provoquant des ralentissements et une isolation d’un point de présence à Delhi ; des problèmes de latence persistants ont été notés dans plusieurs régions indiennes.
- Deux pompiers ont été brûlés aux mains en luttant contre les flammes. Aucun blessé ni décès parmi les civils n’a été signalé.
Séquence technique probable et indices matériels
À la lecture des différents rapports publiés dans la presse indienne, la chronologie la plus cohérente est la suivante : départ de feu dans la zone batteries, coupure d’urgence de l’alimentation réseau, isolation d’un point de présence local de Google à Delhi, puis dégradation de la capacité de routage et hausse de la latence sur plusieurs métropoles indiennes. Google a d’ailleurs confirmé que certains clients en Inde avaient subi des perturbations intermittentes après qu’un incendie dans un centre tiers a déclenché un arrêt d’urgence des équipements réseau.
Le 23 juin, Google indiquait encore travailler à la restauration de capacité supplémentaire et à l’augmentation des marges de réseau, ce qui suggère que le site servait bien de nœud critique pour l’interconnexion régionale, pas seulement de salle compute.
Le sinistre semble avoir principalement endommagé une salle de 1,1 MW de capacité. Mais les descriptions publiées après l’incendie sont sévères : racks serveur brûlés, infrastructure électrique sinistrée, plafonds effondrés et débris au sol, ce qui implique une propagation rapide et une perte importante d’équipements adjacents au foyer initial. Ce type de dommage est compatible avec un incident de batteries lithium‑ion mal contenues ou mal compartimentées, surtout si la propagation thermique a été alimentée par la densité énergétique des modules et par la proximité d’équipements critiques.
Pour l’instant, aucun document public ne détaille la marque, la chimie exacte, le nombre de modules ou l’architecture BMS/UPS, ce qui empêche de conclure sur une défaillance de conception précise.
Ce que disent les exploitants
Tata Communications (via sa filiale Novamesh) affirme avoir activé ses protocoles de continuité immédiatement après l’incident et dit avoir récupéré une majorité des données des clients touchés, avec seulement quelques cas demandant encore validation et reconstruction.
La société précise aussi que certains clients disposant d’architectures multi-sites résilientes n’ont subi aucune interruption, ce qui confirme que l’impact n’était pas uniforme et dépendait fortement du niveau de redondance contractuel et technique.
Le rapport indépendant de root cause analysis annoncé par STT GDC n’est pas public à ce stade. On ne connaît pas encore la configuration exacte du local sinistré, ni le positionnement des batteries, ni le niveau de conformité aux standards de sécurité incendie locaux. On ignore également si le feu a été aggravé par une défaillance de maintenance, un défaut d’installation, ou une absence de cloisonnement suffisant entre batteries et équipements réseau.
Notre lecture
L’incident révèle des arbitrages cruciaux : densité de puissance vs sécurité incendie des batteries, coût des redondances physiques (multi‑sites) vs dépendance au même bâtiment pour des POP réseau, et le niveau de garanties contractuelles sur récupération et sauvegarde. Des clients sans stratégie de sauvegarde multi‑région risquent des pertes irréversibles.
Pour les opérateurs cloud et colocation, l’événement souligne la nécessité de repenser les dispositifs de secours — par exemple éloigner ou compartimenter les systèmes de batterie, renforcer la détection précoce et les systèmes d’extinction adaptés aux risques chimiques des lithium‑ion — et de revoir les SLA et assurances selon l’exposition au risque.
L’élément le plus important n’est pas seulement la cause initiale, mais la façon dont un feu localisé a pu affecter simultanément la récupération de données, les services de connectivité et la perception de fiabilité du site. Dans un data center urbain à forte densité, le moindre incident côté énergie peut se transformer en incident de disponibilité si les batteries, les chemins de câbles et le POP réseau sont trop imbriqués. Autrement dit, l’enjeu n’est pas seulement la prévention du feu, mais la capacité à empêcher la cascade technique et commerciale après le feu.
