L'incendie d'OVHcloud a montré que la localisation des données n'est pas une séparation des catastrophes

Résumé

• Les alarmes incendie se sont déclenchées sur le site strasbourgeois d'OVHcloud à 00h35 le 10 mars 2021. Le feu a commencé 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 l'ensemble du campus. SBG3 et SBG4 n'ont pas été consumés par l'incendie initial, mais les services y étaient indisponibles car une isolation électrique, une inspection de sécurité, un nettoyage et un redémarrage progressif étaient nécessaires. Personne n'a été tué ni blessé.
• L'enquête française de sécurité industrielle n'a pas déterminé la cause précise des défaillances électriques quasi simultanées observées au niveau d'un UPS et de ses batteries au plomb associées. Elle a établi des facteurs de propagation et de réponse: absence de système d'extinction automatique dans aucun des cinq bâtiments strasbourgeois, mouvement rapide de la fumée à travers la conception ouverte axée sur le refroidissement de SBG2, capacité en eau d'incendie limitée et une coupure électrique difficile à l'échelle du site. Des détections fonctionnelles, le personnel de nuit, une séparation résistante au 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 de données permanente ont été des résultats différents. OVHcloud a signalé environ 65 000 clients et 120 000 services perturbés, tandis que Netcraft a observé environ 3,6 millions de sites web sur 464 000 domaines hors ligne. OVHcloud a déclaré que de nombreux clients ayant perdu des données n'avaient pas sélectionné une sauvegarde optionnelle. Cela ne clôt pas la question de la responsabilité: le propre document d'enregistrement d'OVHcloud 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 a été détruite dans le même bâtiment que la production.
• L'événement a exposé 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 non interchangeables. Conserver les données en France ou dans l'Union européenne peut satisfaire une politique de localité tout en permettant aux copies de production et de récupération de partager un même risque physique. Inversement, une copie géographiquement distante peut rester dans le même territoire légal et sous les mêmes contrôles européens.
• OVHcloud a divulgué des changements substantiels après l'incendie, notamment une suppression automatique plus large, un compartimentage plus fort, 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 multi-zones et de sauvegarde distante. Une clôture responsable nécessite néanmoins des preuves spécifiques au service et au site: couverture de contrôle terminée, 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 du 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é cloud

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

Strasbourg a rendu cette chaîne physique visible. Aux premières heures du 10 mars 2021, l'incendie 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 même si la première mise à jour de l'entreprise les décrivait comme non endommagés. La perte s'est donc propagée par 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 mis en sécurité.

Ces mécanismes sont importants car ils correspondent à différents contrôles. La suppression 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 multi-sites 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. Appeler tout cela « redondance » dissimule 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 français, ou BEA-RI,rapport d'enquête de mai 2022. Son mandat était la prévention, pas 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 pas être converti 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 d'équipement nocturne devienne une panne multi-bâtiments, une restauration prolongée et une perte irréversible pour les clients? 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 de la charge 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 minimum. Aucun de ces rôles n'efface les autres.

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

Le rapport du BEA-RI situe la première alarme à 00h35. Un garde a atteint une salle d'énergie de SBG2 à 00h37 et a trouvé une épaisse fumée noire. Le bâtiment a été évacué à 00h39, les sapeurs-pompiers du Bas-Rhin ont été appelés à 00h42 et les premiers équipages sont arrivés à 00h59. La page publique d'incidents d'OVH utilisait 00h47 comme heure à laquelle le feu s'est déclaré. La différence doit être préservée plutôt que forcée dans 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 marqueur d'incident public.

L'alimentation de secours de SBG2 a été coupée à 01h13 et celle de SBG1, SBG3 et SBG4 à 01h28. Les pompiers avaient vu des arcs électriques et ont retenu le déploiement d'eau majeur jusqu'à ce que le risque puisse être maîtrisé. À 01h42, le feu s'était propagé au premier étage. Vers 02h00, les pompiers ont signalé une implication généralisée de SBG2. Le bateau-pompe de grande capacité EUROPA est arrivé vers 03h00, s'approvisionnant dans la voie d'eau adjacente. Le feu a été éteint à 10h02 et l'intervention a été considérée comme terminée à 18h13.

L'enquête a situé l'origine du feu dans des salles abritant des batteries et des équipements d'alimentation sans interruption (UPS). Les enregistrements vidéo et de surveillance ont montré une panne électrique quasi simultanée au niveau de l'unité UPS ASI2 et de ses batteries associées, qui se trouvaient dans des salles séparées. Il y avait eu une maintenance de l'UPS ce matin-là et des mesures d'humidité inhabituelles 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 en dehors des conditions prévues. Ils ont explicitement déclaré que les preuves étaient insuffisantes pour sélectionner une cause initiatrice précise.

Cette retenue a souvent été perdue dans les récits qui affirment qu'un système de refroidissement qui fuyait ou un UPS récemment révisé a « causé » l'incendie. Leregistre d'accident ARIA français officielest une corroboration utile pour le cadre de la salle des machines et la réponse, 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é.

La 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 incendie est conçue autour de cette incertitude. La question responsable n'est pas seulement de savoir si OVH aurait dû prévoir une séquence électrique particulière. C'est 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 se soit 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 optique et par aspiration de fumée 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 a évacué et il n'y a pas eu de blessés. Le rapport BEA-RI crédite ces contrôles. La responsabilité doit conserver les barrières qui ont fonctionné 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 suppression automatique. L'enquête a révélé qu'aucun des cinq bâtiments du site ne disposait d'un système de protection incendie automatique. Les salles de batteries et d'UPS de SBG2 étaient surveillées, mais il n'y avait pas de système conçu pour éteindre, contrôler ou retarder le feu à 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 aidé la fumée et la chaleur à se déplacer. 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 se sont activés à chaque niveau. Le BEA-RI a averti que la chronologie 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 de lutte contre l'incendie, 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'incendie disponible pour la première intervention était insuffisant pour l'événement en développement, selon l'enquête, et OVH n'avait ni sa propre réserve d'eau d'extinction ni 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 des centres 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 pendant une panne de service public ordinaire, 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. Un équipement dense 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 de suppression automatique ne violait pas une exigence réglementaire et que les orientations industrielles citées par l'enquête étaient postérieures à la conception de SBG2. Cela est pertinent pour l'analyse juridique et de conformité. Ce n'est pas la fin de 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 non équipés est elle-même 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 ressembler à plusieurs emplacements d'infrastructure. Pendant l'incident, ils formaient 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 dans les 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 Strasbourg d'OVHcloudrend 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, rack par rack 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 de SBG1 non connectée. 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 lu 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. Les rapports de récupération doivent séparer 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.

L'arrêt à l'échelle du site montre également pourquoi le mot « centre de données » peut être trop granulaire pour la planification des sinistres. Un domaine de défaillance est tout ce qu'un danger peut affecter ensemble. Pour la réponse à l'incendie à Strasbourg, le domaine pertinent comprenait les bâtiments voisins, les procédures d'isolation électrique, l'accès d'urgence, la capacité en eau, la fumée, les opérations partagées et l'autorité de sécurité contrôlant la réintégration. Plusieurs noms de bâtiments ne créaient pas une récupération indépendante si la même décision d'urgence pouvait tous les rendre indisponibles.

Compter l'impact nécessite plus qu'un seul chiffre

Lamesure externe de la panne par Netcrafta révélé environ 3,6 millions de sites web sur 464 000 domaines distincts hors ligne et plus de 18 % des adresses IP attribuées à OVH dans son récent sondage ne répondant pas pendant la fenêtre mesurée. C'est une vue à l'échelle d'Internet de la perte d'accessibilité. 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 des deux chiffres ne dit combien d'utilisateurs finaux n'ont pas pu atteindre 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 boutiques, 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 du 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 quand OVH rétablissait sa plateforme. Un client bare-metal attendant une inspection ou un déménagement physique pouvait rester indisponible pendant des semaines. Un client dont les seules données de production et sauvegardes étaient 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 externes inatteignables, tranches 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.

L'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 aux produits et des valeurs par défaut plus sûres sont pertinentes. Si un produit appelé sauvegarde a placé toutes les copies dans un seul bâtiment sans divulgation claire du domaine de défaillance, la conception du produit et les contrats sont centraux. 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 dans « certains clients n'avaient pas de sauvegarde » empêche une responsabilité précise.

Une sauvegarde est une affirmation sur une 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 ont 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 le courrier électronique, n'ont été que légèrement interrompus et n'ont pas perdu de données car OVH les a sauvegardés.

Ces divulgations réfutent deux histoires simples. Il est inexact de dire qu'OVH a sauvegardé chaque service 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 acheté 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 n'est pas définie simplement par une tâche de copie réussie. C'est une promesse contrôlée qu'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 accepté. Cette promesse contient au moins six propriétés:

1. Portée: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 de récupération:l'âge maximal acceptable des données restaurées, généralement exprimé comme un objectif de point de récupération, et l'historique de rétention nécessaire pour la corruption ou la découverte tardive.
3. Isolement:les défaillances physiques, logiques, administratives et du fournisseur qui ne peuvent pas détruire ou altérer chaque copie 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 pendant une crise.
5. Délai:la durée testée pour obtenir la capacité, transférer les données, reconstruire les dépendances, réconcilier les transactions et ramener une fonction métier à un état acceptable.
6. Preuves:la surveillance que la sauvegarde est terminée, 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 été principalement un test d'isolement physique et de délai de récupération, mais il 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 CNIL énonce maintenant la leçon physique clairement dans sesconseils de sécurité pour les 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. Lesconseils de sécurité cloud de la CNILindiquent aux clients de vérifier qu'un fournisseur cloud dispose d'emplacements de sauvegarde géographiquement éloignés de ses centres de données. Ces documents de 2024 sont des orientations ultérieures, pas une preuve de l'obligation contractuelle précise pour chaque service OVH en 2021. Ils constituent une référence claire pour la pratique actuelle.

L'affaire Bati Courtage a rendu le langage produit conséquent

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 car 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é.

Le résultat a changé en appel. Dans sonarrêt du 24 avril 2025, la cour d'appel de Douai a retenu une violation contractuelle car OVH ne pouvait pas laisser au client l'accès à la sauvegarde effectué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 lourde ou de violations graves de la sécurité incendie dans ce litige, a rejeté la défense de force majeure d'OVH, a confirmé les limitations de responsabilité pertinentes et a réduit l'indemnité à 1 800,48 EUR.

Cette décision est plus étroite et plus instructive que l'indemnité 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 une règle générale selon laquelle toute sauvegarde sur le même site est juridiquement défectueuse. Elle montre que la responsabilité ne peut pas être résolue en disant « le client était propriétaire 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 tels que « 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 panne de serveur. Une salle séparée peut être isolée d'un incendie de rack. 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 du périmètre. Une région séparée est plus forte, à 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, si l'emplacement est sélectionné par défaut ou par option, si l'emplacement peut changer, les dangers que 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 au moment de l'achat du service peuvent devenir plus tard des preuves centrales.

La limitation contractuelle et la responsabilité opérationnelle divergent également. L'indemnité d'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 spécifique pour fonctionner

Le terme « responsabilité partagée » est souvent utilisé 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 propriétaire de la probabilité qu'un événement électrique local se transforme en perte de bâtiment. Il a choisi la conception physique, la détection et la suppression d'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 de gicleurs dans SBG2 ou créer une coupure d'urgence électrique. Ce sont des contrôles du fournisseur même lorsque les contrats clients limitent les dommages.

OVH était également propriétaire de la vérité sur ses produits. Seul le fournisseur pouvait savoir où atterrissait une sauvegarde automatisée, quels services elle sauvegardait par défaut, quelles régions partageaient des systèmes et comment le plan de contrôle se comportait lors de la 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 éclairée sur les risques. Lorsque OVH entreprenait le service de sauvegarde, il était propriétaire de l'exécution du service promis et des preuves concernant la copie résultante.

Les clients étaient propriétaires du modèle de conséquence. Un fournisseur ne pouvait pas savoir, sans un arrangement géré spécifique, si un petit serveur virtuel hébergeait un site de test jetable ou la seule copie d'années de dossiers d'entreprise. 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 le devoir du client de décider combien de temps l'entreprise pouvait tolérer sa perte.

La frontière 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 généralement propriétaire 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 propriétaire de plus de la copie, de la rétention, de la cohérence et du chemin de restauration. Un revendeur de marketplace ou un fournisseur de services gérés introduit une autre couche: il peut sélectionner 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 actuels de la sauvegarde de l'ANSSItransforment ces devoirs en contrôles pratiques. Ils appellent à des objectifs de point et de délai de récupération, le modèle 3-2-1, au moins une copie hors ligne ou hors site protégée de manière appropriée, des tests de restauration réguliers, un ordre de restauration et une 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 délai 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 localité 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 inutile. Il a montré que la souveraineté n'est pas un substitut à l'ingénierie de la disponibilité.

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

• Localisation légale: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 corporatif:quelles sociétés mères, administrateurs, sous-traitants et demandes légales étrangères peuvent influencer le service.
• Localisation physique:quel bâtiment, zone inondable, réseau électrique, approvisionnement en eau, campus et risque régional contient chaque copie.
• Localisation logique:quelle région, zone, compte, locataire, système de clés et plan de contrôle doit fonctionner pour récupérer ou basculer les données.
• Distance opérationnelle:combien de latence, de bande passante, de personnel et de 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 à une partie de 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. Que cela soit suffisant dépend de la loi de l'organisation, du modèle de menace, de la sensibilité des données et de l'objectif de récupération.

L'explication de la Commission européenne sur lestransferts internationauxempê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 localité plus strictes en raison de la loi sectorielle, de la politique publique, des promesses contractuelles ou de l'exposition à une juridiction étrangère.

Lesorientations de qualification SecNumCloud de l'ANSSIillustrent le modèle de souveraineté plus riche. Elles traitent de l'emplacement dans l'UE non seulement pour les données des clients, mais aussi pour l'administration, la supervision, les sauvegardes, les annuaires et les données techniques, tout en tenant compte du contrôle corporatif et de l'exposition à des lois non européennes. 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 dans l'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é à l'intérieur du mot « local ».

La concentration est une propriété de l'application autant qu'une propriété du marché

La panne a affecté les portails gouvernementaux, le commerce, les médias, les jeux et les services publics en ligne parce que de nombreuses organisations ont choisi un seul fournisseur ou en ont hérité par l'intermédiaire d'un fournisseur. C'est la concentration du cloud au niveau du marché. Il y avait aussi une concentration à l'intérieur des applications individuelles: la production, les sauvegardes, le DNS, le courrier électronique, la gestion et l'outillage 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 cloud. Les équipes d'approvisionnement peuvent éviter une concentration non examinée sur un fournisseur 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 cloud dans son portefeuille tandis 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 matériels de récupération hors ligne.

La réglementation financière exprime de plus en plus cette responsabilité conservée du client. Lesorientations de 2019 sur l'externalisation de l'Autorité bancaire européenneexigent que les établissements couverts régissent les risques d'externalisation et restent capables de supervision plutôt que de devenir des coquilles vides. Le règlement européen ultérieur sur la résilience opérationnelle numérique, ou DORA, exige que les entités financières couvertes 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 en utilisant 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 de la pratique responsable: l'externalisation n'externalise pas la responsabilité de l'organe de gouvernance 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 de services 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-fournisseurs 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 à travers des zones indépendantes. Parfois, cela signifie une capacité préchauffée dans une autre région. Parfois, une sauvegarde protégée plus une infrastructure en tant que code et une reconstruction exercée répondent au besoin métier à 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 sont 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 réconcilier 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 semblant que la région principale est inaccessible, que les administrateurs normaux ne peuvent pas se connecter via son chemin d'identité et que le support du fournisseur est 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, construire 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 métier.

Les preuves doivent 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 magasin 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 de paiement, de messagerie et d'identité externes 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 quelle réconciliation restait-il?

La surveillance des sauvegardes seule ne peut pas répondre à ces questions. Un travail vert 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 des 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 deuxième cloud dédié. Elles ont besoin d'un chemin de sortie proportionné. 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 abordé la chaîne physique

La réponse d'OVH au BEA-RI a décrit un important programme « Hyper Resilience ». La société a déclaré qu'elle renforcerait la détection, généraliserait l'extinction automatique là où elle était absente, reconcevrait 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, lorsque cela est possible, sur les sites existants. Elle a prévu 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 a également indiqué que les services d'incendie locaux ont visité chaque site OVH dans les quatre mois suivant l'incident, que les documents d'urgence et les procédures de coupure de courant ont été révisés et qu'un nouveau département des risques industriels a été créé. À Strasbourg, OVH a installé un réservoir d'eau privé de 120 mètres cubes en collaboration avec le SIS67. Elle a déclaré que tous les sites ont reçu 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. La suppression aborde la croissance précoce. Des compartiments coupe-feu plus solides abordent la propagation verticale et entre bâtiments. Les salles d'énergie externes séparent les risques d'inflammation des salles de serveurs. Les coupures zonées abordent le retard et le rayon d'explosion de l'isolation électrique. Le stockage d'eau aborde la capacité de première intervention. Les visites et exercices des services d'incendie abordent la méconnaissance, 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 Hyper Resilience comme renforçant 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ôle: quels sites ont une suppression automatique dans chaque salle d'énergie et informatique pertinente; lesquels ont des compartiments de 120 minutes; quelles salles de batteries sont externes; quelles zones ont une isolation à distance; quels débits d'eau ont été testés; quels exercices de service d'incendie ont eu lieu; quelles conclusions restent ouvertes; et quelle partie indépendante a vérifié le fonctionnement. Un engagement politique est le début de la remédiation. La couverture et l'exercice adversaire montrent si cela fonctionne.

L'entreprise mérite également d'être créditée 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 reconstruire des décisions qui disparaîtraient autrement.

La conception des produits a évolué, mais la configuration décide toujours de la résilience

La documentation actuelle d'OVHcloud est plus explicite sur les domaines de défaillance que le langage d'avant 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 pannes 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 également que les clients recherchant une résilience plus élevée doivent sélectionner une région multi-zones 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 maintenant 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 reconstruire 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 localité et la résilience séparément? OVHcloud le fait maintenant dans ces guides de produits. La prochaine étape d'assurance est de rendre la distinction cohérente à travers les pages produits, les contrats, les valeurs par défaut du panneau de contrôle, les API, les factures et les réponses du support, y compris 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 valeurs par défaut graduées. Un service de développement à faible coût peut raisonnablement avoir une sauvegarde locale par défaut si l'interface l'étiquette comme une protection contre les pannes d'instance, pas contre les sinistres régionaux. Une base de données de production ou un produit de marque de sauvegarde pourrait exiger que le client affirme le domaine de défaillance, affiche un avertissement lorsque toutes les copies partagent un site et propose une destination distante dans la même région légale. L'objectif est une acceptation éclairée du risque, pas de 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 récupération du 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 des installations, la direction doit connaître la perte maximale probable sur chaque site, pas seulement la redondance de l'équipement. Les rapports doivent montrer la couverture de la suppression, 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 des services, 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 dans un seul site ou une seule région; combien de clients ont sélectionné une protection distante; le succès de la restauration par produit et par échelle; les dépendances de clés et d'identité; la distribution du temps de récupération; la dérive de la documentation; et les plaintes indiquant que les clients ont mal compris l'emplacement.

Le conseil 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 de suppression global 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 extrême fait partie de la gouvernance parce que Strasbourg était un événement extrême avec un impact concentré.

Une contestation indépendante devrait suivre 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 et refusez les chemins d'identité et de support normaux. Restaurez dans une destination qui satisfait les règles de localité du client. Comparez les résultats mesurés avec l'objectif de récupération promis. Toute rupture est une lacune actionable, qu'elle appartienne au produit, à l'infrastructure, au support ou au client.

Ce que les clients devraient exiger avant d'appeler un service 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 à la conséquence 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. Un rapport de résilience d'entreprise du fournisseur peut ne pas décrire le VPS économique, l'instantané local ou la base de données gérée en cours d'achat. Les certifications peuvent établir des contrôles utiles mais peuvent avoir des exclusions de portée. 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 devraient également vérifier la concentration sous les noms de revendeurs. Un fournisseur de sauvegarde géré 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 dessous. Le DNS, le courrier électronique, le code source, les secrets et les communications d'incident peuvent tous partager le même fournisseur. La diversité est mesurée par les chemins survivants, pas par le nombre de factures.

Enfin, un client doit décider combien de perte est acceptable. Zéro perte de données 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 hebdomadaire hors ligne 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'était pas seulement un allumage malheureux suivi d'un rappel de faire des sauvegardes. C'était une démonstration de la façon dont les abstractions échouent sous stress physique. Des bâtiments distincts formaient un seul site d'urgence. Des serveurs sains sont devenus indisponibles avec ceux 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'entreprise du client.

Le dossier public contient également une amélioration significative. La détection et le personnel de nuit ont protégé les vies. 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 multi-zones. Ce ne sont pas des changements cosmétiques.

La norme de responsabilité restante est la preuve dans le temps. 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 à de 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 risque principal, dans des limites légales approuvées, et que leurs équipes peuvent les restaurer dans le cadre de l'objectif métier.

Aucun fournisseur 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 localité seront explicites quant à la juridiction et au danger; et le mot « sauvegarde » sera soutenu par la seule preuve qui compte finalement, une restauration réussie dans les conditions pour lesquelles la copie a été achetée.