Résumé

  • Le rapport officiel de la BEA-RI, publié le 24 mai 2022, situe le départ du feu au rez-de-chaussée de SBG2, dans les salles d'énergie abritant batteries et onduleurs ; ces salles étaient équipées d'une détection incendie mais d'aucun système d'extinction automatique.
  • Le même rapport place la première alarme à 00h35 et l'appel des pompiers à 00h42, tandis qu'OVHcloud situe le départ de feu à 00h47 : environ douze minutes d'écart entre les deux récits.
  • L'enquête officielle n'établit pas de cause définitive et laisse cette question à l'expertise judiciaire.
  • En 2023, le tribunal de commerce de Lille Métropole a condamné OVHcloud à verser 100 000 euros à Bati Courtage et 150 000 euros à Bluepad, au motif que la sauvegarde payante était conservée dans le même bâtiment que la production.
  • La solidité de la reconstruction et des changements d'architecture annoncés après l'incendie n'est attestée par aucun audit indépendant publié à ce jour.

Une nuit, deux chronologies

Le 10 mars 2021, peu après minuit, un incendie se déclare sur le campus de Strasbourg d'OVHcloud. Le rapport d'enquête de la BEA-RI, le bureau d'enquêtes et d'analyses sur les risques industriels du ministère de la Transition écologique, publié sous la référence MTE-BEARI-2022-005 le 24 mai 2022, en donne la séquence la plus détaillée disponible (rapport BEA-RI).

Selon ce document, la première alarme retentit dans la salle de sécurité du site à 00h35. À 00h37, l'agent de sécurité atteint la salle énergie 2, au rez-de-chaussée du bâtiment SBG2, et constate une épaisse fumée noire. Le bâtiment est évacué à 00h39 et le service d'incendie et de secours est appelé à 00h42. Les premiers intervenants arrivent à 00h59. L'alimentation de secours de SBG2 est coupée à 01h13, puis celle de SBG1, SBG3 et SBG4 à 01h28. Le feu est éteint à 10h02 et l'intervention s'achève à 18h13, après l'emploi d'environ 4 000 litres de mousse. Une copie miroir du rapport, conservée sur un site tiers, reproduit la même séquence (copie du rapport).

OVHcloud raconte une autre origine. Son message publié le jour même sur son forum communautaire indique que l'incendie s'est déclaré à 00h47 dans une salle de SBG2 (message d'OVHcloud du 10 mars 2021). Sa page d'information sur le site de Strasbourg reprend l'horaire de 00h47 et décrit des systèmes de détection activés instantanément, une réponse conforme au protocole prévu pour les salles d'énergie, et des opérations de lutte qui n'ont pu être menées qu'après la coupure de l'alimentation électrique de l'ensemble du site, y compris les quatre centres de données (page d'information d'OVHcloud).

L'écart ne porte pas seulement sur une minute de chronologie. La BEA-RI décrit une détection à 00h35, une reconnaissance humaine deux minutes plus tard et un appel aux secours sept minutes après le déclenchement de l'alarme. OVHcloud décrit une détection immédiate et une réponse protocolaire.

Les deux récits ne peuvent pas être harmonisés sans arbitrage : la question de savoir combien de temps s'est écoulé entre le premier signal et la première action de secours extérieure reste ouverte, et c'est précisément l'intervalle déterminant pour un bâtiment dont les salles d'énergie n'étaient pas protégées par extinction automatique.

Détecter n'est pas éteindre

Le point le plus lourd du rapport officiel tient en une phrase. L'incendie a pris naissance dans les locaux abritant les batteries et les alimentations sans interruption nécessaires au fonctionnement des serveurs. Ces salles, appelées salles d'énergie, étaient équipées d'une détection incendie mais ne disposaient d'aucun système d'extinction automatique. Les départs de feu se sont produits quasi simultanément sur des batteries et sur un onduleur (rapport BEA-RI).

Cette formulation décrit un mécanisme de défaillance précis : la capacité à savoir qu'un feu existe était présente, la capacité à l'étouffer immédiatement ne l'était pas. Le bâtiment a donc dépendu d'une intervention humaine puis de l'arrivée des secours, dans un environnement électrique qu'il fallait d'abord mettre hors tension. Le rapport relève lui-même que la coupure de l'alimentation, nécessaire à la sécurité des intervenants, a conditionné le déroulement de la lutte.

Le bilan matériel est documenté : SBG2 détruite, SBG1 partiellement détruite à hauteur de 4 salles sur 12, et une liaison entre bâtiments, vers SBG3, endommagée. Le rapport ne recense aucune victime ni blessé. Il refuse en revanche de désigner une cause unique et indique que cette question relevait encore de l'expertise judiciaire au moment de sa publication. Il en tire des enseignements de sécurité portant sur les systèmes d'extinction automatique, la maintenance des batteries, la conception des bâtiments et la planification des urgences, y compris la coupure électrique (rapport BEA-RI).

L'humidité près des onduleurs : une observation, pas une cause

Une partie de la couverture technique de l'enquête s'est concentrée sur un point connexe : la présence d'eau ou d'humidité détectée près des onduleurs avant l'incendie. Le rapport lui-même ne tranche pas la question de savoir si cette mesure d'humidité relevait d'une erreur de mesure (compte rendu technique).

La distinction importe. Une observation d'humidité consignée avant un départ de feu est un élément d'enquête. Elle n'est pas une cause établie, et aucun document officiel disponible ne la présente comme telle. Toute reconstitution qui désignerait une cause unique — l'eau, une batterie, un onduleur — contredirait l'état du dossier tel que l'enquête publique le laisse.

L'ampleur de la panne

La mesure indépendante la plus citée provient de Netcraft, qui a suivi la disponibilité des adresses attribuées à OVHcloud pendant l'incident. Environ 3,6 millions de sites web, répartis sur quelque 464 000 domaines distincts, étaient hors ligne au point culminant. Entre 06h00 et 07h15 UTC le 10 mars 2021, plus de 18 % des adresses IP attribuées à OVHcloud ne répondaient pas (analyse Netcraft).

Les sites concernés comprenaient des banques en ligne, des services de messagerie, des sites d'information, des boutiques en ligne et plusieurs sites gouvernementaux. La couverture d'agence du même jour décrit des millions de sites perturbés, des portails d'agences publiques, des banques et des sites de presse hors service, et une partie de l'espace web en .fr touchée (dépêche Reuters). Des reprises techniques contemporaines décrivent l'ampleur immédiate de l'interruption et les consignes données aux clients pour activer leurs plans de reprise (couverture technique du 10 mars 2021).

De son côté, OVHcloud a estimé à environ 120 000 le nombre de services entièrement ou partiellement affectés, dont environ 113 000 entièrement rétablis au moment de sa mise à jour. L'entreprise indique avoir livré 14 472 serveurs dédiés comme solutions alternatives dans d'autres centres de données et rétabli 30 775 serveurs privés virtuels, avec environ 5 900 encore en attente (page d'information d'OVHcloud). Ces chiffres sont des données d'entreprise, arrêtées à une date de mise à jour non précisée : ils ne constituent pas un décompte audité.

Ce qu'OVHcloud a annoncé

La réponse commerciale a combiné arrêt de la facturation et mesures de compensation. OVHcloud a indiqué avoir cessé de facturer les services SBG affectés et adopté des mesures de gratuité pour les clients touchés (page d'information d'OVHcloud). Un plan de compensation par paliers a été annoncé : pour les serveurs privés virtuels détruits, six mois de compensation en l'absence de reprise d'activité ; en présence d'un plan de reprise, soit une reconstruction, soit un remboursement intégral assorti de trois ans de service gratuit si la reconstruction était impossible (couverture du plan de compensation).

L'entreprise a également indiqué que le site de Strasbourg n'était pas classé Seveso, que les pompiers avaient isolé le site et son périmètre à partir de 02h54, qu'à 04h09 le feu avait détruit SBG2 tout en menaçant les centres de données voisins, et qu'à partir de 05h30 le site était inaccessible à ses équipes, sous la direction de la préfecture (message d'OVHcloud du 10 mars 2021). Elle s'est engagée à communiquer de manière transparente sur les causes et les impacts, tout en précisant que les autorités et les assureurs enquêtaient encore sur la chronologie, le départ et la propagation du feu (page d'information d'OVHcloud).

Ce que les tribunaux ont tranché

Les décisions les plus concrètes sur la responsabilité ne portent pas sur la sécurité incendie, mais sur la sauvegarde. Le tribunal de commerce de Lille Métropole a condamné OVHcloud à verser 100 000 euros à Bati Courtage par décision du 3 février 2023, puis 150 000 euros à Bluepad par décision du 16 mars 2023, soit 250 000 euros au total. Le motif retenu est que les services de sauvegarde payants souscrits par ces clients conservaient leurs sauvegardes dans le même bâtiment SBG2 que les données de production, de sorte que les deux copies ont été détruites dans le même incendie. Le tribunal a jugé que le service de sauvegarde promis n'avait pas été délivré, tout en rejetant les demandes fondées sur une négligence en matière de sécurité incendie (compte rendu de la condamnation, analyse des décisions).

Ces éléments doivent être lus avec leurs limites. Les montants, la motivation et l'issue procédurale proviennent de la couverture spécialisée et non de l'inspection directe des jugements. La presse professionnelle indiquait qu'OVHcloud entendait faire appel du jugement Bluepad ; aucune issue d'appel confirmée n'a été documentée ici, et cette question doit rester traitée comme non résolue (analyse des décisions).

La portée réelle du raisonnement est cependant claire : la promesse contractuelle la plus vérifiable — la sauvegarde — a été jugée non tenue pour deux clients, tandis que l'allégation la plus difficile à établir — la faute dans la conception du bâtiment — n'a pas été retenue. C'est une ligne de partage utile pour quiconque achète de la redondance : ce qui est écrit dans un contrat est contrôlable en justice, ce qui relève de l'ingénierie de sûreté l'est beaucoup moins.

La réparation reste à prouver

Sur la suite, les éléments publics disponibles échouent au même test. Aucun audit publié, aucune revue d'ingénierie indépendante, aucune décision d'appel statuant au fond sur l'architecture de sauvegarde n'a été trouvé. Il n'existe pas davantage de documentation publique établissant que la localisation des sauvegardes et la réplication hors site ont été modifiées dans les contrats clients de manière vérifiable, ni de bilan réglementaire ou prudentiel quantifiant la perte résiduelle (contexte de la reprise).

Cela ne signifie pas que rien n'a été fait. Cela signifie que la déclaration de l'exploitant reste, à ce jour, la principale preuve de sa propre réparation. Or l'incendie de 2021 a précisément montré où ce type de preuve peut manquer : le bâtiment savait détecter un feu, annonçait de la redondance, et n'a pas pu empêcher la perte simultanée de deux copies de données clients.

Le prolongement le plus utile n'est donc pas une nouvelle reconstruction narrative, mais un jeu de preuves : un audit post-incident publié ; une décision au fond sur la localisation des sauvegardes ; la divulgation de changements contractuels sur la réplication hors site ; la déclaration d'incidents ultérieurs sur des sites comparables ; des conclusions d'autorités de tutelle ; et des résultats d'assurance ou de recours subrogatoire chiffrant la perte résiduelle.

Conclusion : une conséquence bornée, une responsabilité partiellement établie

Ce que l'on peut affirmer est circonscrit. Un feu a détruit SBG2 et endommagé SBG1 le 10 mars 2021. Le mécanisme initial est documenté et n'inclut ni extinction automatique dans les salles d'énergie, ni traçabilité parfaitement concordante entre l'exploitant et l'enquête publique. Deux clients ont obtenu une indemnisation pour des sauvegardes stockées dans le même bâtiment que leur production. Aucune cause unique n'a été établie.

Ce qui reste incertain est tout aussi circonscrit : la cause exacte du départ de feu, l'issue d'appel des décisions de 2023, et la réalité vérifiée des changements d'architecture annoncés. Sur ce dernier point, l'entrée de répertoire consacrée à OVHcloud (fiche OVHcloud) et les rapports d'incident ultérieurs constituent des points de contrôle plus utiles qu'une déclaration.