L'incendie OVHcloud: la localisation ne remplace pas la séparation des sinistres

Synthèse

• Les alarmes incendie se sont déclenchées sur le site strasbourgeois d’OVHcloud à 00 h 35 le 10 mars 2021. Le feu a débuté dans les salles d’énergie du rez-de-chaussée de SBG2, a détruit ce bâtiment, endommagé quatre des douze salles de SBG1 et imposé une coupure de courant sur tout le campus. SBG3 et SBG4 n’ont pas été consumés par l’incendie initial, mais les services y étaient indisponibles en raison de l’isolation électrique, des inspections de sécurité, du nettoyage et du redémarrage progressif nécessaires. Aucune personne n’a été tuée ni blessée.
• L’enquête française sur la sécurité industrielle n’a pas déterminé la cause précise des défaillances électriques quasi-simultanées observées sur un onduleur et ses batteries au plomb associées. Elle a en revanche établi les facteurs de propagation et d’intervention: absence de système d’extinction automatique dans aucun des cinq bâtiments strasbourgeois, propagation rapide de la fumée à travers la conception ouverte de SBG2 orientée vers le refroidissement, capacité limitée en eau d’extinction et une coupure électrique difficile à l’échelle du site. Des systèmes de détection fonctionnels, le personnel de nuit, la séparation coupe-feu protégeant SBG3 et l’arrivée d’un bateau-pompe franco-allemand de grande capacité ont limité les conséquences plus graves.
• La perte de disponibilité et la perte permanente de données ont été des conséquences distinctes. OVHcloud a fait état d’environ 65 000 clients et 120 000 services perturbés, tandis que Netcraft a observé qu’environ 3,6 millions de sites web répartis sur 464 000 domaines sont passés hors ligne. OVHcloud a déclaré que de nombreux clients ayant perdu des données n’avaient pas souscrit de sauvegarde optionnelle. Cela ne clôt pas la question de la responsabilité: le document d’enregistrement d’OVHcloud lui-même indiquait que les sauvegardes proposées pouvaient être stockées dans le même centre de données ou dans un autre, et un jugement d’appel ultérieur concernait un client dont la sauvegarde automatisée payante avait été détruite dans le même bâtiment que la production.
• L’événement a révélé une erreur de catégorie dans l’approvisionnement cloud. La souveraineté des données, la juridiction légale, la latence, la disponibilité, la sauvegarde et la reprise après sinistre sont liées mais pas interchangeables. Conserver les données en France ou dans l’Union européenne peut satisfaire une politique de localisation tout en permettant aux copies de production et de récupération de partager un même risque physique. Inversement, une copie géographiquement éloignée peut rester à l’intérieur du même territoire juridique et sous les mêmes contrôles européens.
• OVHcloud a divulgué d’importants changements post-incendie, notamment une extinction automatique élargie, un compartimentage renforcé, des salles d’énergie séparées, des coupures électriques à distance, des audits de site, une collaboration avec les services d’incendie et de nouvelles options multizones et de sauvegarde distante. Une clôture responsable exige néanmoins des preuves spécifiques au service et au site: couverture complète des contrôles, inspection indépendante, exercices réalistes d’incendie et d’isolation électrique, emplacements de sauvegarde déclarés, tests de restauration réussis et preuve que la récupération client ne dépend pas de la région sinistrée ou du même plan de contrôle.

Un incendie physique est devenu un événement de responsabilité pour le cloud

L’expression « données dans le cloud » encourage une abstraction. Elle est utile lorsque les ingénieurs souhaitent une interface standard pour la capacité de calcul, mais dangereuse lorsque les décideurs commencent à considérer l’emplacement, l’énergie et l’incendie comme des détails relevant d’autrui. Chaque serveur virtuel repose dans une salle. Chaque réplique de stockage occupe un équipement connecté aux systèmes électriques et de refroidissement. Chaque flux de travaux de récupération dépend de personnes, de réseaux, d’identifiants, de catalogues et d’un endroit depuis lequel une capacité de remplacement peut être obtenue.

Strasbourg a rendu cette chaîne physique visible. Aux premières heures du 10 mars 2021, le feu a détruit SBG2, l’un des bâtiments du campus d’OVHcloud au Port du Rhin. SBG1 a été partiellement détruit. Les deux autres centres de données du site ont été arrêtés, bien que la communication initiale de l’entreprise les décrivait comme non endommagés.

La perte s’est donc propagée via au moins trois mécanismes distincts: l’équipement a été physiquement détruit; l’équipement des bâtiments adjacents a été exposé à la chaleur, à la fumée, à l’eau ou à l’incertitude; et l’équipement sain est devenu indisponible lorsque le site a dû être isolé électriquement et sécurisé.

Ces mécanismes sont importants car ils correspondent à différents contrôles. L’extinction automatique et le compartimentage peuvent contenir un incendie. Des zones d’alimentation indépendantes peuvent réduire la zone que les pompiers doivent déconnecter. Une application multisite peut continuer pendant qu’un site est indisponible. Une sauvegarde distante et vérifiée peut soutenir la reconstruction après la destruction des données. Une page d’état peut guider les clients à travers ces options. Qualifier tout cela de « redondance » masque qui contrôle chaque couche et quel événement elle peut survivre.

La reconstitution publique la plus autorisée est le rapport d’enquête de mai 2022 du Bureau d’enquêtes et d’analyses sur les risques industriels, ou BEA-RI,May 2022 investigation report. Son mandat était la prévention, non l’attribution de responsabilité civile ou pénale. Cette limite est importante. Le rapport peut établir des observations, des causes possibles, des facteurs contributifs et des recommandations de sécurité. Il ne peut être transformé en une conclusion judiciaire selon laquelle chaque faiblesse identifiée était négligente ou qu’une faiblesse a légalement causé la perte d’un client particulier.

L’analyse de la responsabilité pose une question connexe mais plus large: quels acteurs avaient autorité sur les conditions qui ont permis qu’un événement nocturne sur un équipement se transforme en une panne touchant plusieurs bâtiments, une restauration prolongée et une perte client irréversible? OVH contrôlait la conception et l’exploitation du site, les produits proposés, l’exactitude de leurs descriptions et la réponse. Les clients contrôlaient la classification des charges de travail, l’architecture, de nombreuses sélections de services et les copies indépendantes.

Les régulateurs et les organismes professionnels contrôlaient des parties du cadre minimal. Aucun de ces rôles n’efface les autres.

Ce que les preuves établissent, et ce qu’elles n’établissent pas

Le rapport BEA-RI situe la première alarme à 00 h 35. Un agent de sécurité est arrivé dans une salle d’énergie de SBG2 à 00 h 37 et a constaté une épaisse fumée noire. Le bâtiment a été évacué à 00 h 39, le service d’incendie et de secours du Bas-Rhin a été appelé à 00 h 42, et les premiers équipages sont arrivés à 00 h 59. La page d’incident publique d’OVH indiquait 00 h 47 comme heure de déclenchement de l’incendie.

La différence doit être conservée plutôt que forcée en un seul horodatage: l’enquête de sécurité avait accès aux alarmes et aux enregistrements opérationnels, tandis que la page de l’entreprise fournissait un repère d’incident public.

L’alimentation de secours de SBG2 a été coupée à 01 h 13 et celle de SBG1, SBG3 et SBG4 à 01 h 28. Les pompiers avaient observé des arcs électriques et ont retenu le déploiement massif d’eau jusqu’à ce que le risque puisse être maîtrisé. À 01 h 42, le feu s’était propagé dans tout le premier étage. Vers 02 h 00, les pompiers ont signalé l’implication généralisée de SBG2. Le bateau-pompe de grande capacité EUROPA est arrivé vers 03 h 00, puisant dans le cours d’eau adjacent. L’incendie a été éteint à 10 h 02 et l’intervention a été considérée comme terminée à 18 h 13.

L’enquête a situé l’origine de l’incendie dans des salles abritant des batteries et des équipements d’alimentation sans interruption. Les enregistrements vidéo et de surveillance ont montré un défaut électrique quasi simultané sur l’unité d’onduleur ASI2 et ses batteries associées, qui se trouvaient dans des salles séparées. L’onduleur avait fait l’objet d’une maintenance ce matin-là et des mesures d’humidité inhabituelles ont été relevées plus tard dans la journée. Les enquêteurs ont énuméré plusieurs hypothèses, notamment l’humidité, un dysfonctionnement lié à la maintenance ou un fonctionnement hors des conditions prévues.

Ils ont explicitement déclaré que les preuves étaient insuffisantes pour choisir une cause initiatrice précise.

Cette retenue a souvent été perdue dans les récits qui affirment qu’un système de refroidissement fuyant ou un onduleur récemment révisé a « causé » l’incendie. Leregistre d’accident ARIA françaisest une corroboration utile pour le cadre de la salle des machines et l’intervention, mais il ne transforme pas un mécanisme plausible en une cause racine prouvée. Un compte rendu crédible devrait dire que les premiers événements électriques et la zone d’origine sont connus; la raison pour laquelle ces événements se sont produits n’a pas été résolue dans le rapport BEA-RI publié.

Cette distinction n’empêche pas l’analyse des contrôles. Une organisation doit être préparée à une défaillance d’équipement sans savoir quel composant tombera en panne ensuite. La protection contre l’incendie est conçue autour de cette incertitude. La question de responsabilité n’est pas seulement de savoir si OVH aurait dû prévoir une séquence électrique particulière.

Il s’agit de savoir si la détection, le contrôle automatique, le compartimentage, l’eau, l’isolation électrique, la conception du bâtiment et les procédures d’urgence ont donné aux personnes et aux services adjacents une protection indépendante suffisante après que quelque chose s’est enflammé.

Le bâtiment a détecté le danger mais n’a pas pu le contenir

Le site de Strasbourg a bien rempli une mission de sécurité des personnes. La détection de fumée optique et par aspiration a fonctionné. La présence de personnel de nuit a permis une vérification rapide et un appel précoce aux pompiers. Tout le monde s’est échappé et il n’y a pas eu de blessés. Le rapport BEA-RI reconnaît ces contrôles. La responsabilité devrait conserver les barrières qui ont réussi aussi soigneusement que celles qui ont échoué, car la conception future dépend de la connaissance de ce qui a réellement fait gagner du temps.

La détection n’était pas accompagnée d’une extinction automatique. L’enquête a conclu qu’aucun des cinq bâtiments du site ne disposait d’un système de protection incendie automatique. Les salles de batteries et d’onduleurs de SBG2 étaient surveillées, mais il n’existait aucun système conçu pour éteindre, contrôler ou retarder l’incendie à son stade le plus précoce. Un tel système aurait pu agir avant la coupure électrique complète et sans exposer les pompiers à des équipements sous tension. Il n’aurait pas garanti l’extinction, en particulier dans une salle électrique, mais il aurait pu modifier la courbe de croissance du feu.

Le bâtiment a ensuite favorisé la propagation de la fumée et de la chaleur. SBG2 utilisait une conception de refroidissement ouverte, en forme de tour, très perméable à l’air extérieur. Dans les quinze minutes suivant l’événement initial, les détecteurs par aspiration s’étaient activés à chaque niveau. Le BEA-RI a prévenu que le déclenchement des détecteurs indiquait de la fumée, pas nécessairement des flammes, mais a conclu que la construction permettait à la fumée de se propager rapidement. En environ quatre-vingt-dix minutes, SBG2 était généralement impliqué.

Le contraste avec le SBG3 adjacent était instructif: des murs coupe-feu de deux heures et une porte coupe-feu, ainsi que l’eau d’extinction, l’ont laissé moins endommagé que le SBG1, plus petit et moins protégé.

L’eau et l’électricité ont interagi avec cette conception. L’approvisionnement public en eau d’extinction disponible pour la première intervention était insuffisant pour l’événement en développement, selon l’enquête, et OVH ne disposait ni de sa propre réserve d’eau d’extinction ni d’un moyen de pomper directement depuis le canal voisin. L’arrivée d’EUROPA a été décisive. L’indépendance électrique, normalement un atout pour un centre de données, a également rendu l’isolation d’urgence difficile: le site combinait des alimentations du réseau, des générateurs et de grands systèmes de batteries.

Les services d’incendie ne pouvaient pas appliquer en toute sécurité des jets d’eau importants tant que ces sources n’étaient pas neutralisées.

C’est le paradoxe de la résilience des infrastructures. L’alimentation de secours préserve l’informatique lors d’une panne ordinaire du réseau, mais devient une autre source d’énergie à gérer pendant un incendie. Un flux d’air ouvert peut réduire le coût de refroidissement et améliorer l’efficacité opérationnelle, mais peut affaiblir le confinement de la fumée et de la chaleur. Des équipements denses et des services publics partagés sur le site peuvent améliorer les économies d’échelle, mais concentrent les conséquences. Chaque optimisation crée un risque qui doit être contrôlé par une barrière différente.

Laréponse formelle d’OVH aux recommandations du BEA-RIa fait valoir que l’absence d’extinction automatique ne violait pas une exigence réglementaire et que les directives sectorielles citées par l’enquête étaient postérieures à la conception de SBG2. C’est pertinent pour l’analyse juridique et de conformité. Cela ne met pas fin à la responsabilité opérationnelle. La conformité minimale demande si une règle imposait un contrôle. La résilience demande si le contrôle était nécessaire pour un scénario crédible à conséquences élevées. La décision d’OVH, après l’incendie, de généraliser l’extinction automatique sur les sites qui n’en étaient pas équipés est en soi une preuve que le traitement du risque a changé.

Quatre bâtiments ne signifiaient pas quatre résultats indépendants

Depuis un tableau de bord client, SBG1, SBG2, SBG3 et SBG4 pouvaient apparaître comme plusieurs emplacements d’infrastructure. Pendant l’incident, ils ont constitué un seul site d’urgence. SBG2 a brûlé. SBG1 et SBG3 ont été affectés par l’incendie à des degrés divers. SBG4 n’a pas été endommagé par l’incendie initial. Pourtant, l’électricité a été coupée aux quatre, l’accès a été contrôlé, les systèmes partagés ont dû être évalués et l’infrastructure survivante a nécessité un nettoyage, une inspection, un recâblage et un redémarrage progressif.

Lejournal de mise à jour contemporain de Strasbourgd’OVHcloud rend le caractère physique de la récupération inhabituellement visible. Les équipes ont retiré, nettoyé, inspecté, réinstallé et redémarré l’équipement salle par salle, allée par allée, baie par baie et serveur par serveur. Les serveurs contaminés par la suie ont été transférés dans une usine à Croix pour des travaux spécialisés. Les machines récupérables de SBG1 ont été transférées vers d’autres centres de données. Des spécialistes de la récupération de données ont tenté de récupérer des disques dans les salles endommagées.

La première récupération n’a pas été linéaire. SBG3 est devenu opérationnel le 18 mars. Le soir du 19 mars, de la fumée a été détectée dans une salle de batteries non connectée de SBG1. OVH a de nouveau arrêté SBG1 et SBG4 par précaution et a révisé le calendrier de redémarrage. La restauration des services a repris le 22 mars. Fin mars, les serveurs bare-metal de SBG4 étaient accessibles et les services de SBG3 revenaient en pourcentages, tandis que l’équipement de SBG1 était encore en cours de nettoyage, de réparation et de relocalisation.

Le document d’enregistrement d’OVH a par la suite indiqué que la plupart des services clients étaient revenus dans les trois à quatre semaines et que le service avait été entièrement rétabli pour les quelque 65 000 clients touchés, utilisant environ 120 000 services, début mai. « Service rétabli » ne peut pas être interprété comme « toutes les données restaurées ». Un serveur de remplacement peut être provisionné alors que les anciens disques et enregistrements du client restent détruits.

Le rapport de récupération doit distinguer la disponibilité de l’infrastructure, le démarrage de l’application, la restauration des données, l’actualité des données et l’acceptation par l’entreprise.

Pour mesurer l’impact, il faut plus d’un chiffre

Lamesure externe de la panne par Netcrafta relevé environ 3,6 millions de sites web répartis sur 464 000 domaines distincts hors ligne et plus de 18 % des adresses IP attribuées à OVH dans son enquête récente ne répondant pas pendant la fenêtre mesurée. C’est une vue à l’échelle d’Internet de la perte de joignabilité. Elle capture les sous-domaines hébergés et les accords d’hébergement en aval, ce qui explique pourquoi elle dépasse largement le nombre de clients d’OVH.

Les 65 000 clients touchés et les 120 000 services d’OVH décrivent des relations commerciales et de produits. Aucun de ces chiffres n’indique combien d’utilisateurs finaux n’ont pas pu accéder à un service, combien d’entreprises ont perdu un canal de revenus ou combien d’ensembles de données étaient irrécupérables. Lesreportages contemporains de Reutersont identifié des portails gouvernementaux, des banques, des magasins, des sites d’actualités et d’autres services en ligne parmi les perturbations. Ces exemples montrent la diversité des conséquences, pas un recensement complet.

L’effet a également varié dans le temps. Un site web sans état avec le code dans un dépôt externe pouvait être reconstruit dans une autre région en quelques heures. Un service géré avec des données de récupération détenues par le fournisseur pouvait revenir lorsqu’OVH restaurait sa plateforme. Un client bare-metal attendant une inspection ou une relocalisation physique pouvait rester indisponible pendant des semaines. Un client dont les seules données de production et sauvegardes ont été détruites faisait face à une perte permanente, quelle que soit la rapidité avec laquelle un nouveau serveur vide arrivait.

Un rapport d’incident responsable devrait donc utiliser plusieurs dénominateurs: clients, services, serveurs physiques, domaines, adresses inaccessibles de l’extérieur, plages de durée, restaurations réussies par le fournisseur, reconstructions initiées par le client et cas de perte de données permanente. Il devrait identifier combien de clients n’avaient pas de sauvegarde, une copie dans le même bâtiment, une copie sur le même site, une région OVH différente ou une copie sous contrôle indépendant. Les preuves publiques ne fournissent pas cette matrice complète.

Cette absence est importante car la remédiation doit suivre le mécanisme de perte. Si les clients n’ont pas sélectionné une sauvegarde distante clairement proposée, une meilleure éducation au produit et des paramètres par défaut plus sûrs sont pertinents. Si un produit appelé sauvegarde plaçait toutes les copies dans un même bâtiment sans divulgation claire du domaine de défaillance, la conception du produit et les contrats sont essentiels.

Si des copies distantes existaient mais que les clients ne pouvaient pas les récupérer parce que l’identité, les clés, les catalogues ou les chemins réseau étaient liés à Strasbourg, l’indépendance du système de récupération est le problème. Regrouper ces cas sous « certains clients n’avaient pas de sauvegarde » empêche une responsabilisation précise.

Une sauvegarde est une promesse de restauration future

Ledocument d’enregistrement 2021 d’OVHcloudindiquait que les services de sauvegarde de données étaient des services payants optionnels pour la plupart des clients et que certains avaient subi une perte de données permanente. Il indiquait également que les clients pouvaient choisir des options proposées dans lesquelles les données sauvegardées étaient stockées soit dans le même centre de données, soit dans un centre de données différent. Certains services gérés par le fournisseur, y compris la messagerie, n’ont été que légèrement interrompus et n’ont pas perdu de données car OVH les sauvegardait.

Ces divulgations réfutent deux récits simplistes. Il est inexact de dire qu’OVH sauvegardait tous les services et n’a pas réussi à préserver toutes les copies. Il est également insuffisant de dire que chaque client qui a perdu des données n’a pas souscrit de sauvegarde. Les modèles de service différaient. Certains clients conservaient la responsabilité de la seule copie durable, certains sélectionnaient des options du fournisseur avec des emplacements différents, et certains consommaient des services pour lesquels OVH contrôlait la récupération.

Une sauvegarde ne se définit pas simplement par une tâche de copie réussie. C’est une promesse contrôlée selon laquelle, après des défaillances spécifiées, une organisation peut récupérer une version suffisamment récente et intacte de ses informations et l’utiliser pour restaurer un service prioritaire dans un délai acceptable. Cette promesse contient au moins six propriétés:

1. Périmètre:les données, l’état du système, les configurations, les magasins d’identités, les clés, les logiciels et les dépendances externes inclus ou intentionnellement exclus.
2. Point:l’âge maximal acceptable des données restaurées, généralement exprimé en objectif de point de récupération, et l’historique de rétention nécessaire en cas de corruption ou de découverte différée.
3. Isolation:les défaillances physiques, logiques, administratives et du fournisseur qui ne peuvent pas détruire ou altérer toutes les copies ensemble.
4. Accès:les informations d’identification, les clés de chiffrement, les catalogues, les outils, les chemins réseau et les personnes autorisées nécessaires pour récupérer la copie en cas de crise.
5. Temps:la durée testée pour obtenir la capacité, transférer les données, reconstruire les dépendances, rapprocher les transactions et ramener une fonction métier à un état acceptable.
6. Preuves:la surveillance de la réussite de la sauvegarde, les contrôles d’intégrité, les restaurations échantillonnées, les exercices de service complets et les enregistrements conservés montrant le résultat.

Strasbourg a principalement testé l’isolation physique et le temps de récupération, mais a exposé les six. Une image disque sans enregistrements DNS, secrets, code de déploiement ou cohérence de base de données peut ne pas redémarrer une application. Une copie distante chiffrée avec des clés disponibles uniquement via la région défaillante peut être durable et inutilisable. Une archive de plusieurs téraoctets qui prend des jours à récupérer peut manquer un objectif commercial de douze heures. Une sauvegarde stockée dans le même domaine énergétique et d’incendie peut être parfaitement à jour jusqu’à l’événement qu’elle était censée couvrir.

L’autorité française de protection des données, la CNIL, énonce maintenant clairement la leçon physique dans songuide de sécurité des sauvegardes: conservez au moins une copie sur un site géographiquement distinct, isolez au moins une copie hors ligne, protégez les sauvegardes au même niveau de sécurité que la production et testez l’intégrité et la restauration. Leguide de sécurité du cloud de la CNILdemande aux clients de vérifier qu’un fournisseur de cloud dispose d’emplacements de sauvegarde géographiquement éloignés de ses centres de données. Ces documents de 2024 sont des conseils ultérieurs, pas la preuve de l’obligation contractuelle précise pour chaque service OVH en 2021. Ils constituent une référence claire pour les pratiques actuelles.

L’affaire Bati Courtage a rendu le langage produit lourd de conséquences

Le litige d’un client donne une spécificité juridique à la limite de la sauvegarde. France Bati Courtage utilisait un serveur privé virtuel OVH et une option de sauvegarde automatisée payante. Selon le dossier, OVH l’a informé en avril 2021 que la sauvegarde avait également été totalement et irréversiblement détruite parce que les copies se trouvaient dans le même bâtiment que le serveur principal. Le client a réclamé des millions d’euros pour perte de données et préjudice commercial en aval allégué.

L’issue a changé en appel. Dans sonarrêt du 24 avril 2025, la cour d’appel de Douai a retenu un manquement contractuel parce qu’OVH n’avait pas pu laisser au client l’accès à la sauvegarde réalisée et la conserver pour récupération. Elle n’a pas retenu la demande distincte du client selon laquelle OVH était en faute pour ne pas avoir situé les services dans des lieux géographiquement isolés. Elle a également maintenu la conclusion antérieure selon laquelle OVH n’avait pas commis de faute grave ni de manquement sérieux à la sécurité incendie dans ce litige, a rejeté la défense de force majeure d’OVH, a confirmé les limitations de responsabilité applicables et a réduit l’indemnisation à 1 800,48 €.

Cette décision est plus étroite et plus instructive que l’indemnisation de première instance largement rapportée. Elle n’établit pas que chaque contrat de sauvegarde OVH promettait un centre de données distant. Elle n’établit pas de règle générale selon laquelle toute sauvegarde sur le même site est juridiquement défectueuse. Elle montre en revanche que la responsabilité ne peut être résolue en disant que « le client était responsable de la politique de sauvegarde » lorsque le client a payé le fournisseur pour effectuer une sauvegarde et que le fournisseur avait des obligations contractuelles concernant la copie résultante.

L’affaire démontre également pourquoi les étiquettes contractuelles ont besoin d’une topologie derrière elles. Des termes comme « physiquement isolé », « infrastructure », « local », « région » et « distant » peuvent avoir des significations différentes. Une baie de disques séparée est isolée d’une défaillance de serveur. Une salle séparée peut être isolée d’un incendie de baie. Un bâtiment séparé peut survivre à certains événements de salle mais pas nécessairement à une coupure de courant du campus ou à une fermeture de périmètre.

Une région séparée est plus robuste, à condition que les régions ne partagent pas de dépendances de contrôle, de compte, de clé ou de réseau qui bloquent la récupération.

Les clients ne devraient pas avoir à déduire ces limites d’un adjectif marketing. Une description de service devrait nommer le domaine de défaillance de la copie, indiquer si l’emplacement est sélectionné par défaut ou par option, si l’emplacement peut changer, les dangers auxquels la conception est censée survivre, l’objectif de récupération et les obligations restantes du client. Les fournisseurs devraient conserver la version historique de ces représentations car l’interface et la documentation disponibles lors de l’achat d’un service peuvent devenir ultérieurement des preuves essentielles.

La limitation contractuelle et la responsabilité opérationnelle divergent également. L’indemnisation en appel était faible parce que le tribunal a appliqué les limitations convenues après avoir évalué les demandes et les clauses dont il était saisi. Un plafond de responsabilité ne rend pas la perte de données permanente acceptable sur le plan opérationnel, pas plus qu’une perte alléguée importante ne prouve que le fournisseur doit légalement ce montant. Les contrats répartissent l’exposition financière. Ils ne restaurent pas les informations et ne prouvent pas qu’un contrôle a été conçu de manière appropriée.

La responsabilité partagée doit être suffisamment précise pour fonctionner

« La responsabilité partagée » est souvent utilisée comme une façon polie de dire que les deux parties avaient du travail à faire. À moins que le travail ne soit nommé, l’expression répartit le blâme après l’échec au lieu d’attribuer les contrôles avant. Strasbourg soutient une division plus précise.

OVH était responsable de la probabilité qu’un événement électrique local se transforme en perte d’un bâtiment. Il a choisi la conception physique, la détection et l’extinction incendie, le compartimentage, l’isolation des services publics, les procédures d’urgence, le cadre de maintenance, les ressources en eau et la relation avec les pompiers publics. Les clients ne pouvaient pas installer d’extincteurs automatiques dans SBG2 ni créer une coupure d’urgence de l’électricité. Ce sont des contrôles du fournisseur même lorsque les contrats clients limitent les dommages.

OVH était également responsable de la vérité sur ses produits. Seul le fournisseur pouvait savoir où une sauvegarde automatisée atterrissait, quels services il sauvegardait par défaut, quelles régions partageaient des systèmes et comment le plan de contrôle se comportait en cas de perte de Strasbourg. Il devait décrire ces propriétés avec suffisamment de précision pour qu’un client puisse prendre une décision en matière de risque. Lorsque OVH s’engageait à fournir le service de sauvegarde, il était responsable de l’exécution du service promis et des preuves concernant la copie résultante.

Les clients étaient responsables du modèle de conséquences. Un fournisseur ne pouvait pas savoir, sans un accord de gestion spécifique, si un petit serveur virtuel contenait un site de test jetable ou la seule copie de plusieurs années d’archives commerciales. Le client devait classer les données, fixer des objectifs de récupération, sélectionner une architecture proportionnée à l’impact, conserver des copies en dehors du domaine de défaillance principal et tester la reconstruction. L’achat d’infrastructure ne transférait pas au client l’obligation de décider combien de temps l’entreprise pouvait tolérer sa perte.

La limite se déplace avec le modèle de service. Dans le bare-metal non géré ou l’infrastructure en tant que service, le client est normalement responsable de la sauvegarde cohérente avec l’application et du basculement. Dans une base de données gérée, un produit de messagerie hébergé ou un service de sauvegarde explicite, le fournisseur est davantage responsable de la copie, de la rétention, de la cohérence et du chemin de restauration.

Un revendeur de place de marché ou un fournisseur de services gérés introduit une couche supplémentaire: il peut choisir OVH, configurer la sauvegarde, représenter la résilience à ses propres clients et conserver le seul accès administratif. Les clients finaux doivent connaître cette chaîne.

Lesfondamentaux de la sauvegarde actuels de l’ANSSI, l’agence française de cybersécurité, transforment ces devoirs en contrôles pratiques. Ils préconisent des objectifs de point et de temps de récupération, le schéma 3-2-1, au moins une copie hors ligne ou hors site correctement protégée, des tests de restauration réguliers, un ordre de restauration et la protection des supports d’installation et des configurations d’application. Pour la sauvegarde externalisée, l’ANSSI souligne l’emplacement dans l’UE, le comportement de réplication du fournisseur, le chiffrement contrôlé par le client et le temps de récupération. C’est un rappel utile que la résilience physique, l’isolement cyber, la souveraineté et la récupérabilité doivent être conçus ensemble.

La localisation répond à plusieurs questions différentes

L’identité européenne d’OVHcloud comptait en 2021 et compte toujours. Pour les gouvernements et les organisations réglementées cherchant une alternative aux hyperscalers non européens, un fournisseur français exploitant des centres de données européens peut offrir des avantages juridictionnels, économiques et opérationnels significatifs. L’incendie de Strasbourg n’a pas rendu la souveraineté des données non pertinente. Il a montré que la souveraineté ne remplace pas l’ingénierie de la disponibilité.

« Où sont les données? » peut signifier au moins cinq choses:

• Emplacement légal:les règles de protection des données, de divulgation, d’insolvabilité et sectorielles de quel pays régissent le stockage, le traitement et l’accès.
• Contrôle d’entreprise:quelles sociétés mères, administrateurs, sous-traitants et demandes légales étrangères peuvent influencer le service.
• Emplacement physique:quel bâtiment, plaine inondable, réseau électrique, approvisionnement en eau, campus et danger régional contient chaque copie.
• Emplacement logique:quelle région, zone, compte, locataire, système de clés et plan de contrôle doivent fonctionner pour récupérer ou basculer les données.
• Distance opérationnelle:quelle latence, bande passante, dotation en personnel et temps de récupération séparent la production de ses utilisateurs et de la copie de récupération.

Une politique qui dit « toutes les données doivent rester en France » répond en partie à la première question et contraint la troisième. Elle n’exige pas que la production et la sauvegarde occupent le même bâtiment. La France contient plusieurs zones métropolitaines et régions cloud. Une politique exigeant le stockage dans l’UE permet une diversité géographique encore plus grande tout en préservant un périmètre juridique de l’UE. La question de savoir si cela est suffisant dépend de la loi de l’organisation, de son modèle de menace, de la sensibilité des données et de l’objectif de récupération.

L’explication des transferts internationaux de la Commission européenneempêche également une simplification inverse: le RGPD n’impose pas une règle absolue selon laquelle les données personnelles ne peuvent jamais quitter l’Espace économique européen. Il prévoit des décisions d’adéquation, des garanties et des dérogations limitées pour les transferts. Certaines organisations adoptent néanmoins des exigences de localisation plus strictes en raison du droit sectoriel, de la politique publique, des promesses contractuelles ou de l’exposition à une juridiction étrangère.

Leguide de qualification SecNumCloud de l’ANSSIillustre le modèle de souveraineté plus riche. Il traite de l’emplacement dans l’UE non seulement pour les données client, mais aussi pour l’administration, la supervision, les sauvegardes, les annuaires et les données techniques, tout en tenant compte du contrôle de l’entreprise et de l’exposition à une législation non européenne. Ce cadre concerne le contrôle sur le service et les données, pas simplement la latitude et la longitude d’un disque.

La conclusion pratique est constructive: la souveraineté et la séparation des sinistres peuvent se renforcer mutuellement. Un organisme public français peut conserver la production sensible dans un environnement européen qualifié, maintenir une copie de récupération UE géographiquement distincte, utiliser le chiffrement et les clés contrôlés par le client et conserver des procédures d’exportation testées vers un autre environnement approuvé. L’architecture peut coûter plus cher et nécessiter un examen juridique minutieux. Le compromis doit être explicite plutôt que caché dans le mot « local ».

La concentration est une propriété de l’application autant que du marché

La panne a touché des portails gouvernementaux, du commerce, des médias, des jeux et des services destinés au public parce que de nombreuses organisations avaient choisi un seul fournisseur ou en avaient hérité par l’intermédiaire d’un fournisseur. C’est la concentration du cloud au niveau du marché. Il y avait également une concentration à l’intérieur des applications individuelles: la production, les sauvegardes, le DNS, la messagerie, la gestion et les outils de déploiement pouvaient partager OVH ou Strasbourg même lorsqu’ils apparaissaient comme des produits distincts.

Les deux formes nécessitent un traitement différent. Les régulateurs peuvent surveiller la dépendance systémique à un petit groupe de fournisseurs de cloud. Les équipes d’approvisionnement peuvent éviter une concentration non examinée de fournisseurs entre les départements. Les propriétaires d’applications doivent cartographier les dépendances qui déterminent si leur propre service peut récupérer. Une entreprise peut utiliser trois fournisseurs de cloud dans son portefeuille alors qu’un système critique n’a toujours pas de copie indépendante.

Une autre peut rester avec un seul fournisseur mais utiliser des régions véritablement séparées, des sauvegardes exportables, un DNS indépendant et des supports de récupération hors ligne.

La réglementation financière exprime de plus en plus cette responsabilité conservée par le client. Lesorientations de 2019 de l’Autorité bancaire européenne sur l’externalisationexigent des établissements concernés qu’ils gouvernent les risques d’externalisation et restent capables de surveillance plutôt que de devenir des coquilles vides. Le règlement européen sur la résilience opérationnelle numérique (DORA), adopté ultérieurement, exige des entités financières concernées qu’elles maintiennent et testent périodiquement les dispositifs de sauvegarde, de restauration et de récupération. Sesexigences de l’article 12incluent la ségrégation physique et logique lorsque les entités restaurent des données de sauvegarde à l’aide de leurs propres systèmes. Ces règles ont des champs d’application définis et ne doivent pas être projetées rétroactivement sur chaque client OVH de 2021. Elles montrent la direction d’une pratique responsable: l’externalisation n’externalise pas la responsabilité de l’organe dirigeant pour la continuité.

Le cadre de mise en œuvre détaillé de DORA va plus loin. Lerèglement délégué de 2024 sur la gestion des risques TICinclut des scénarios impliquant la perte partielle ou totale de locaux et de centres de données, la défaillance d’un service tiers, les basculements vers une capacité redondante et les pannes de courant généralisées. Strasbourg est exactement le type d’événement combiné physique et fournisseur qu’un exercice sérieux devrait modéliser.

La conception multi-fournisseur peut réduire certaines dépendances mais n’est pas automatiquement supérieure. Elle ajoute de la complexité en matière d’identité, de réseau, de cohérence des données, de compétences, d’observabilité et de coordination des incidents. L’objectif correct est une récupération portable et testable pour les fonctions importantes, pas un slogan architectural. Parfois, cela signifie un service actif dans des zones indépendantes. Parfois, cela signifie une capacité de préchauffage dans une autre région.

Parfois, une sauvegarde protégée associée à l’infrastructure en tant que code et une reconstruction testée répondent aux besoins de l’entreprise à un coût bien moindre.

La restauration doit être prouvée du côté du client

La restauration par le fournisseur et la récupération par le client ne suivent pas la même horloge. OVH pouvait déclarer un centre de données opérationnel lorsque l’alimentation, le réseau et une grande partie des serveurs étaient disponibles. Un client devait encore valider les systèmes de fichiers, les bases de données, les files d’attente, les certificats, le DNS, les intégrations et les transactions commerciales. Si le serveur d’origine était détruit, le client devait provisionner une alternative, récupérer les données, reconstruire l’application et rapprocher tout ce qui s’était produit après la dernière copie utilisable.

Un exercice de récupération mature commence par une perte supposée, pas par une exportation pratique. L’équipe doit faire comme si la région principale était inaccessible, que les administrateurs normaux ne pouvaient pas se connecter via son chemin d’identité et que le support du fournisseur était saturé. Elle doit obtenir la sauvegarde en utilisant des informations d’identification et des clés stockées en dehors de l’environnement défaillant, créer une capacité propre dans la destination approuvée, restaurer les dépendances dans l’ordre documenté, valider l’intégrité des données, rediriger les utilisateurs et mesurer le résultat commercial.

Les preuves devraient répondre à des questions pratiques. Quel était l’horodatage de la base de données restaurée? Quelles écritures ont été perdues? Toutes les versions du stockage d’objets étaient-elles incluses? Les clés pouvaient-elles être récupérées sans affaiblir le contrôle d’accès? Le DNS a-t-il changé dans le délai prévu? Les fournisseurs externes de paiement, de messagerie et d’identité ont-ils accepté les nouvelles adresses? Combien de temps jusqu’à la première transaction sûre, et combien de temps jusqu’à la pleine capacité? Qui a approuvé le retour et quel rapprochement restait-il?

La seule surveillance des sauvegardes ne peut pas répondre à ces questions. Un travail réussi prouve que le logiciel a écrit quelque chose sur une cible. Un test d’intégrité prouve que des données sélectionnées peuvent être lues. Une restauration technique prouve que les systèmes peuvent être reconstruits. Un exercice de service prouve que l’organisation peut fournir sa fonction prioritaire dans les conditions de défaillance supposées. Chacun est utile; aucun ne doit être présenté comme le suivant.

C’est particulièrement important pour les petites organisations. Elles n’ont peut-être pas besoin d’une infrastructure active-active ou d’un second cloud dédié. Elles ont besoin d’une voie de sortie proportionnée. Une petite entreprise peut exporter sa base de données et ses documents critiques vers une destination chiffrée sous un compte séparé, conserver ses informations d’identification de domaine et de déploiement de manière indépendante, documenter une reconstruction propre et tester une restauration échantillon. Le contrôle doit correspondre au coût de la perte des enregistrements, pas au prix mensuel du serveur.

La remédiation d’OVHcloud a traité la chaîne physique

La réponse d’OVH au BEA-RI décrivait un programme substantiel « Hyper Résilience ». L’entreprise a déclaré qu’elle renforcerait la détection, généraliserait l’extinction automatique là où elle était absente, repenserait les zones et le compartimentage, augmenterait la résistance au feu ordinaire de soixante à 120 minutes et placerait les salles d’énergie et de batteries à l’extérieur des bâtiments du centre de données pour les nouveaux sites et, dans la mesure du possible, sur les sites existants.

Elle prévoyait des coupures électriques à distance par zone afin que les intervenants puissent isoler le danger sans désactiver inutilement les zones non affectées.

La réponse indiquait également que les services d’incendie locaux avaient visité chaque site OVH dans les quatre mois suivant l’incident, que les documents d’urgence et les procédures de coupure de courant avaient été révisés et qu’un nouveau département des risques industriels avait été créé. À Strasbourg, OVH a installé une citerne d’eau privée de 120 mètres cubes en collaboration avec le SIS67. Elle a déclaré que tous les sites avaient fait l’objet d’une analyse des risques d’incendie et que l’efficacité serait mesurée par une étude de vulnérabilité une fois les travaux terminés.

SBG5, ouvert en juillet 2022, a été présenté comme un exemple des nouvelles normes.

Ces actions correspondent bien à la chaîne causale et de propagation de l’enquête. L’extinction traite la croissance précoce. Des compartiments coupe-feu plus robustes traitent la propagation verticale et entre bâtiments. Les salles d’énergie externes séparent les risques d’inflammation des salles de serveurs. Les coupures par zone traitent le délai et le rayon de souffle de l’isolation électrique. Le stockage d’eau traite la capacité de première intervention. Les visites et exercices des services d’incendie traitent le manque de familiarité, les plans et les décisions de commandement.

Ledocument d’enregistrement universel 2025 d’OVHcloudindique que le groupe a poursuivi la cartographie des risques des sites en 2025 et décrit l’Hyper Résilience comme un renforcement de la sécurité des centres de données au-delà des recommandations réglementaires et des assureurs. Il enregistre également une provision continue pour les conséquences de l’incendie de Strasbourg, y compris les actions en responsabilité. C’est la preuve d’un programme durable et d’un traitement financier, pas d’un certificat d’achèvement indépendant site par site.

Une clôture responsable publierait ou fournirait aux clients qualifiés et aux auditeurs une matrice de contrôles: quels sites disposent d’une extinction automatique dans chaque salle d’énergie et informatique concernée; lesquels ont des compartiments de 120 minutes; quelles salles de batteries sont externes; quelles zones ont une isolation commandée à distance; quelles exigences de débit d’eau ont été testées; quels exercices avec les services d’incendie ont eu lieu; quels constats restent ouverts; et quel tiers indépendant a vérifié le fonctionnement. Un engagement politique est le début de la remédiation.

La couverture et l’exercice contradictoire montrent si elle fonctionne.

L’entreprise mérite également d’être reconnue pour avoir conservé un journal de mise à jour public détaillé pendant une récupération difficile, mobilisé une capacité de nettoyage et de récupération spécialisée, remplacé l’infrastructure, communiqué les progrès spécifiques aux produits et publié une réponse formelle aux recommandations de sécurité. La transparence n’est pas complète simplement parce que les mises à jour sont fréquentes, mais ces enregistrements permettent aux clients et aux enquêteurs de reconstituer des décisions qui, autrement, disparaîtraient.

La conception du produit a évolué, mais la configuration détermine toujours la résilience

La documentation actuelle d’OVHcloud est plus explicite sur les domaines de défaillance que le langage antérieur à l’incendie visible dans le litige Bati Courtage. Songuide des modes de déploiementdistingue les régions à une zone de disponibilité, les régions à trois zones et les zones locales. Il indique qu’une région à 1 AZ reste vulnérable aux défaillances affectant un centre de données entier, tandis que l’architecture à 3 AZ utilise des zones indépendantes pour les cas de production et de reprise après sinistre plus exigeants.

L’aperçu des régions et des zones de disponibilitéde l’entreprise indique de même que les clients recherchant une résilience plus élevée doivent sélectionner une région multizone prise en charge et construire pour plusieurs zones. Les verbes comptent: le fournisseur fournit les zones; le client doit répartir les ressources et l’état de l’application entre elles. Le simple fait de lancer dans une région 3 AZ ne garantit pas qu’une machine virtuelle, une base de données ou un volume placé manuellement s’étende sur les zones.

Ladocumentation actuelle sur la sauvegarde d’instancedistingue désormais les sauvegardes locales et distantes. Une sauvegarde locale reste dans la même région. Une sauvegarde distante crée une copie dans une autre région sélectionnée et est facturée séparément. C’est un langage de domaine de défaillance beaucoup plus clair. Cela préserve également un choix explicite du client, ce qui signifie que l’approvisionnement et la configuration restent une partie du contrôle.

La documentation actuelle ne doit pas être utilisée pour reconstituer ce qui était proposé à chaque client en mars 2021. Elle est pertinente pour la question de responsabilité actuelle: le marché a-t-il appris à exposer la localisation et la résilience séparément? OVHcloud le fait désormais dans ces guides produits. La prochaine étape d’assurance consiste à rendre la distinction cohérente entre les pages produits, les contrats, les paramètres par défaut du panneau de contrôle, les API, les factures et les réponses du support, y compris pour les produits où les sauvegardes gérées par le fournisseur suivent des règles différentes.

Une conception plus sûre peut également utiliser des paramètres par défaut progressifs. Un service de développement à faible coût peut raisonnablement proposer par défaut une sauvegarde locale si l’interface l’étiquette comme une protection contre la défaillance d’instance, pas contre un sinistre régional. Une base de données de production ou un produit de marque de sauvegarde pourrait exiger du client qu’il confirme le domaine de défaillance, afficher un avertissement lorsque toutes les copies partagent le même site et proposer une destination distante dans la même région juridique.

L’objectif est une acceptation éclairée du risque, et non forcer chaque charge de travail dans l’architecture la plus coûteuse.

Le conseil d’administration a besoin de preuves sur deux plans de contrôle

L’incendie de Strasbourg a traversé un plan de contrôle des installations et un plan de contrôle de la récupération client. Le conseil d’administration et la direction des risques d’OVH ont besoin d’assurance sur les deux. L’ingénierie incendie ne peut pas être traitée comme une note de bas de page immobilière, et les produits de sauvegarde ne peuvent pas être traités uniquement comme des revenus de stockage.

Pour la couche installation, la direction doit connaître la perte maximale probable sur chaque site, et pas seulement la redondance des équipements. Les rapports doivent montrer la couverture de l’extinction, l’intégrité des compartiments, la séparation des salles d’énergie, les performances de détection, l’eau d’urgence, le temps d’isolation électrique, la familiarité des services d’incendie, les exceptions de maintenance et les travaux correctifs en retard. Les exercices doivent supposer que les contrôles ordinaires échouent et que les pompiers ont besoin d’une autorité immédiate et précise pour isoler l’énergie.

Pour la couche service, la direction doit savoir comment les domaines de défaillance des produits sont représentés et testés. Les rapports doivent montrer combien de services commercialisés avec un langage de sauvegarde ou de haute disponibilité stockent chaque copie sur un seul site ou une seule région; combien de clients ont choisi une protection distante; le succès de la restauration par produit et par échelle; les dépendances en matière de clés et d’identité; la distribution des temps de récupération; la dérive de la documentation; et les réclamations indiquant que les clients ont mal compris l’emplacement.

Le conseil d’administration doit également recevoir les exceptions, pas seulement les moyennes. Un taux de réussite des travaux de sauvegarde de 99,99 % peut coexister avec des milliers de copies dans un seul domaine physique. Un pourcentage global d’extinction peut cacher un ancien bâtiment à haute densité. Un temps de restauration moyen peut cacher les ensembles de données les plus volumineux et les plus importants. L’exposition des risques extrêmes relève de la gouvernance parce que Strasbourg était un événement extrême avec un impact concentré.

Un défi indépendant devrait retracer une promesse client jusqu’au bout. Sélectionnez un service vendu comme sauvegardé. Enregistrez ce que l’interface et le contrat disent. Localisez chaque copie et ses métadonnées de contrôle. Supprimez le site principal de l’exercice. Refusez les chemins normaux d’identité et de support. Restaurez vers une destination qui satisfait aux règles de localisation du client. Comparez les résultats mesurés avec l’objectif de récupération promis. Toute rupture est un écart exploitable, qu’il appartienne au produit, à l’infrastructure, au support ou au client.

Ce que les clients devraient exiger avant de qualifier un service de résilient

Les organisations n’ont pas besoin d’un accès privé à chaque plan de centre de données. Elles ont besoin de réponses suffisamment détaillées pour décider si un service correspond aux conséquences d’une défaillance. Les questions suivantes transforment les leçons de Strasbourg en preuves d’approvisionnement:

Les réponses doivent être liées au produit exact. Le rapport de résilience d’entreprise d’un fournisseur peut ne pas décrire le VPS économique, l’instantané local ou la base de données gérée achetés. Les certifications peuvent établir des contrôles utiles mais peuvent avoir des exclusions de périmètre. Un accord de niveau de service de disponibilité fournit un recours après le dépassement d’un seuil; il ne décrit pas en soi la durabilité des données ni ne garantit la récupération.

Les clients doivent également vérifier la concentration sous les noms des revendeurs. Un fournisseur de sauvegarde gérée peut stocker son dépôt dans la même région OVH que la production. Une marque d’hébergement secondaire peut utiliser OVH en sous-main. Le DNS, la messagerie, le code source, les secrets et les communications d’incident peuvent tous partager le même fournisseur. La diversité se mesure par les chemins survivants, pas par le nombre de factures.

Enfin, un client doit décider quel niveau de perte est acceptable. Une perte de données nulle et un temps d’arrêt quasi nul en cas de sinistre régional nécessitent une réplication continue, une conception d’application, une capacité et des tests opérationnels qui peuvent être coûteux. Une copie hors ligne hebdomadaire peut être adéquate pour une archive statique et désastreuse pour les transactions. La responsabilité n’exige pas le même contrôle partout. Elle exige une relation consciente entre la conséquence, la récupération promise, l’architecture et les preuves.

Le signal durable

L’incendie de Strasbourg n’a pas été seulement un malheureux départ de feu suivi d’un rappel de faire des sauvegardes. Il a été une démonstration de la façon dont les abstractions échouent sous la contrainte physique. Des bâtiments séparés ont formé un seul site d’urgence. Des serveurs sains sont devenus indisponibles avec les serveurs endommagés. Une sauvegarde terminée pouvait disparaître avec la production. Un emplacement européen qui servait la souveraineté et la latence pouvait devenir une concentration de risque d’incendie. Un serveur de remplacement pouvait restaurer l’infrastructure sans restaurer l’activité du client.

Le dossier public contient également des améliorations significatives. La détection et le personnel de nuit ont protégé la vie. Les pompiers et le bateau-pompe EUROPA ont limité la propagation. OVH a mené une récupération difficile et transparente, a accepté les recommandations du BEA-RI en termes opérationnels et a lancé un vaste programme de résilience physique. Sa documentation produit actuelle distingue plus clairement la sauvegarde locale de la sauvegarde distante et le déploiement à zone unique du déploiement multizone. Ce ne sont pas des changements cosmétiques.

La norme de responsabilité restante est la preuve dans la durée. OVH devrait être en mesure de montrer que les contrôles physiques identifiés après l’incendie sont installés, maintenus et exercés sur les sites concernés; que le langage produit correspond aux vrais domaines de défaillance; et que la récupération gérée fonctionne lorsqu’une région et ses chemins de contrôle normaux sont absents. Les clients devraient être en mesure de montrer que les données critiques ont une copie utilisable en dehors du danger principal, dans les limites juridiques approuvées, et que leurs équipes peuvent la restaurer dans l’objectif commercial.

Aucun fournisseur de cloud ne peut promettre qu’un bâtiment ne brûlera jamais. Aucun client ne peut éliminer toutes les dépendances. La promesse crédible est plus étroite: un événement physique prévisible ne consumera pas silencieusement la production, la récupération et les moyens de comprendre ce qui a été perdu; les choix de localisation seront explicites à la fois sur la juridiction et le danger; et le mot « sauvegarde » sera étayé par la seule preuve qui compte en fin de compte, une restauration réussie dans les conditions pour lesquelles la copie a été achetée.