L'incendie 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 à 0h35 le 10 mars 2021. L’incendie a débuté dans les salles énergétiques du rez-de-chaussée du SBG2, a détruit ce bâtiment, endommagé quatre des douze salles du SBG1, et forcé la coupure d’électricité sur l’ensemble du 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, de l’inspection de sécurité, du nettoyage et du redémarrage progressif. Personne n’a été tué ni blessé.
• L’enquête de sécurité industrielle française n’a pas déterminé la cause précise des défauts électriques quasi simultanés observés sur un onduleur et 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 les cinq bâtiments de Strasbourg, propagation rapide de la fumée due à la conception ouverte et refroidissante du SBG2, capacité d’eau d’incendie limitée et arrêt électrique difficile à l’échelle du site. Une détection fonctionnelle, un personnel de nuit, une séparation coupe-feu protégeant SBG3 et l’arrivée d’un bateau-pompe franco-allemand à haute capacité ont limité les conséquences les plus graves.
• La perte de disponibilité et la perte permanente de données étaient des résultats différents. OVHcloud a signalé que 65 000 clients et 120 000 services avaient été perturbés, tandis que Netcraft a observé qu’environ 3,6 millions de sites web répartis sur 464 000 domaines étaient hors ligne. OVHcloud a déclaré que de nombreux clients ayant perdu des données n’avaient pas sélectionné de sauvegarde optionnelle. Cela ne clôt pas la question de la responsabilité: le 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 centre différent, 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 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 interchangeables. Garder des 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 reprise 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é des changements substantiels après l’incendie, notamment une suppression automatique étendue, un compartimentage renforcé, des salles énergétiques séparées, des coupures électriques à distance, des audits de site, un travail avec les services d’incendie, et de nouvelles options multizones et de sauvegarde distante. Une conclusion responsable nécessite 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 déclarés des sauvegardes, tests de restauration réussis, et preuve que la reprise du client ne dépend pas de la région endommagé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 à traiter l’emplacement, l’alimentation et le feu comme des détails appartenant à quelqu’un d’autre. Chaque serveur virtuel repose dans une salle. Chaque réplica de stockage occupe un équipement connecté à des systèmes électriques et de refroidissement. Chaque flux de reprise dépend de personnes, de réseaux, d’identifiants, de catalogues et d’un lieu à partir duquel une capacité de remplacement peut être obtenue.

Strasbourg a rendu cette chaîne physique visible. Aux premières heures du 10 mars 2021, un 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 dans les 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. Une suppression automatique et un 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 tandis qu’un site est indisponible. Une sauvegarde distante vérifiée peut soutenir la reconstruction après la destruction des données. Une page de statut peut guider les clients à travers ces options. Appeler tout cela « redondance » cache qui contrôle chaque couche et quel événement elle peut survivre.

La reconstruction 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 (BEA-RI). 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 constatation judiciaire que chaque faiblesse identifiée était négligente ou qu’une faiblesse a légalement causé la perte d’un client particulier.

L’analyse de responsabilité pose une question connexe mais plus large: quels acteurs avaient autorité sur les conditions qui ont permis à un événement nocturne d’équipement de devenir une panne multi-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 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 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 place la première alarme à 0h35. Un garde a atteint une salle énergétique du SBG2 à 0h37 et a trouvé une épaisse fumée noire. Le bâtiment a été évacué à 0h39, le service d’incendie et de secours du Bas-Rhin a été appelé à 0h42, et les premiers équipages sont arrivés à 0h59. La page d’incident publique d’OVH utilisait 0h47 comme heure du début de l’incendie. La différence doit être préservée plutôt que forcée en un seul horodatage: l’enquête de sécurité avait accès aux alarmes et aux registres opérationnels, tandis que la page de l’entreprise fournissait un marqueur d’incident public.

L’alimentation d’urgence du SBG2 a été coupée à 1h13 et celle du SBG1, SBG3 et SBG4 à 1h28. Les pompiers avaient vu des arcs électriques et ont retenu le déploiement d’eau jusqu’à ce que le risque soit contrôlé. Vers 1h42, l’incendie s’était propagé au premier étage. Vers 2h00, les pompiers ont signalé une implication généralisée du SBG2. Le bateau-pompe à haute capacité EUROPA est arrivé vers 3h00, puisant dans la voie navigable adjacente. L’incendie a été éteint à 10h02 et l’intervention a été considérée comme terminée à 18h13.

L’enquête a localisé l’origine de l’incendie dans des salles contenant des batteries et des équipements d’alimentation sans interruption. Les enregistrements vidéo et de surveillance ont montré un défaut électrique presque simultané au niveau de l’onduleur ASI2 et de ses batteries associées, qui se trouvaient dans des salles séparées. Une maintenance avait eu lieu sur l’onduleur ce matin-là et des mesures d’humidité inhabituelles avaient é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 en dehors des conditions attendues. Ils ont explicitement déclaré que les preuves étaient insuffisantes pour choisir une cause initiale précise.

Cette retenue a souvent été perdue dans les récits qui disent qu’un système de refroidissement qui fuit ou un onduleur récemment entretenu a « causé » l’incendie. Le dossier d’accident ARIA français officiel est 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 récit 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 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. Elle 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 un allumage.

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

Le site strasbourgeois a bien rempli une mission de sécurité des personnes. La détection optique et par aspiration de fumée a fonctionné. Le 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 eu aucune blessure. Le rapport BEA-RI salue ces contrôles. La responsabilité devrait retenir les barrières réussies aussi soigneusement que les échecs, car la conception future dépend de la connaissance de ce qui a réellement fait gagner du temps.

La détection n’a pas été assortie 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 automatique de protection contre l’incendie. Les salles de batteries et d’onduleurs du SBG2 étaient surveillées, mais il n’y avait pas de 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 l’arrêt électrique complet et sans exposer les pompiers à des équipements sous tension. Il n’aurait pas garanti l’extinction, notamment dans une salle électrique, mais il aurait pu modifier la courbe de croissance de l’incendie.

Le bâtiment a ensuite facilité le déplacement de la fumée et de la chaleur. SBG2 utilisait une conception ouverte en forme de tour refroidissante, 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 à tous les niveaux. Le BEA-RI a prévenu que le moment des détecteurs indiquait la fumée, pas nécessairement la flamme, mais a conclu que la construction permettait une propagation rapide de la fumée. En environ quatre-vingt-dix minutes, le 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’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’alimentation publique en eau d’incendie disponible pour les premiers intervenants était inadéquate 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 de l’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 réseau, des générateurs et de grands systèmes de batteries.

Le service d’incendie ne pouvait pas appliquer en toute sécurité de grands jets d’eau 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 le calcul en cas de panne de courant ordinaire, mais devient une autre source d’énergie à gérer en cas d’incendie. Le flux d’air ouvert peut réduire les coûts de refroidissement et améliorer l’efficacité opérationnelle, mais peut affaiblir le confinement de la fumée et de la chaleur. La densité des équipements et les services publics partagés du site peuvent améliorer l’économie d’échelle, mais concentrent les conséquences. Chaque optimisation crée un risque qui doit être contrôlé par une barrière différente.

La réponse formelle d’OVH aux recommandations du BEA-RI a fait valoir que l’absence de suppression automatique ne violait pas une exigence réglementaire et que les directives de l’industrie citées par l’enquête étaient postérieures à la conception du 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 à fortes conséquences.

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 la preuve que le traitement des risques 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 le brasier initial. Pourtant, l’électricité a été coupée pour 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.

Le journal de mise à jour contemporain de Strasbourg d’OVHcloud rend le caractère physique de la reprise 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 vers une usine à Croix pour un travail spécialisé. Les machines récupérables du SBG1 ont été transférées vers d’autres centres de données. Des spécialistes en récupération de données ont tenté de récupérer les disques des salles endommagées.

La première reprise n’a pas été linéaire. SBG3 est devenu opérationnel le 18 mars. Dans la soirée du 19 mars, de la fumée a été détectée dans une salle de batteries non connectée du SBG1. OVH a arrêté à nouveau 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 nus de SBG4 étaient accessibles et les services de SBG3 revenaient en pourcentages, tandis que l’équipement du SBG1 était encore nettoyé, réparé et relocalisé.

Le document d’enregistrement d’OVH a déclaré plus tard que la plupart des services clients sont revenus en trois à quatre semaines et que le service a été complètement rétabli pour les quelque 65 000 clients affectés, utilisant environ 120 000 services, début mai. « Service rétabli » ne peut pas être lu comme « toutes les données rétablies ». Un serveur de remplacement peut être provisionné tandis que les anciens disques et enregistrements du client restent détruits.

Les rapports de reprise doivent séparer la disponibilité de l’infrastructure, le démarrage des applications, la restauration des données, l’actualité des données et l’acceptation métier.

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 aléa 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éentrée. De multiples noms de bâtiments n’ont pas créé une reprise indépendante si la même décision d’urgence pouvait les rendre tous indisponibles.

Compter l’impact nécessite plus d’un nombre

La mesure externe de la panne par Netcraft a trouvé 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 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 arrangements d’hébergement en aval, ce qui explique pourquoi elle dépasse largement le nombre de clients d’OVH.

Les 65 000 clients affectés et 120 000 services d’OVH décrivent des relations commerciales et de produit. Aucun de ces nombres ne dit combien d’utilisateurs finaux ne pouvaient pas atteindre un service, combien d’entreprises ont perdu un canal de revenus, ou combien d’ensembles de données étaient irrécupérables. Un reportage contemporain de Reuters a identifié des portails gouvernementaux, des banques, des magasins, des sites d’actualité 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 heures. Un service géré avec des données de reprise détenues par le fournisseur pouvait revenir lorsqu’OVH aurait restauré sa plateforme. Un client nue attendant l’inspection ou le déplacement physique pouvait rester indisponible pendant des semaines. Un client dont les seules données de production et les sauvegardes étaient détruites faisait face à une perte permanente, indépendamment de 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 extérieures inaccessibles, fourchettes de durée, restaurations réussies par le fournisseur, reconstructions initiées par le client et cas de perte permanente de données. 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 copie dans 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 devrait suivre le mécanisme de perte. Si les clients n’ont pas sélectionné une sauvegarde distante clairement proposée, une meilleure éducation sur le produit et des valeurs par défaut plus sûres sont pertinentes. Si un produit appelé sauvegarde plaçait toutes les copies dans un seul bâtiment sans divulgation claire du domaine de défaillance, la conception du produit et le contrat 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 reprise est le problème. Agréger ces cas en « certains clients n’avaient pas de sauvegarde » empêche une responsabilité précise.

Une sauvegarde est une affirmation sur une future restauration

Le document d’enregistrement 2021 d’OVHcloud indiquait 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 permanente de données. 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, notamment la messagerie, n’ont été que légèrement interrompus et n’ont pas perdu de données car OVH les sauvegardait.

Ces divulgations contredisent deux histoires simples. Il est inexact de dire qu’OVH a sauvegardé tous les services et n’a pas réussi à préserver toutes les copies. Il est également insuffisant de dire que tous les clients ayant perdu des données n’ont 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 reprise.

Une sauvegarde n’est pas définie uniquement par un travail de copie réussi. 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. Périmètre:les données, l’état du système, les configurations, les magasins d’identité, les clés, les logiciels et les dépendances externes inclus ou intentionnellement exclus.
2. Point:l’âge maximum acceptable des données restaurées, généralement exprimé comme un objectif de point de reprise, et l’historique de rétention nécessaire en cas de corruption ou de découverte tardive.
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 identifiants, clés de chiffrement, catalogues, outils, chemins réseau et personnes autorisées nécessaires pour récupérer la copie pendant une crise.
5. Temps: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. Preuve:la surveillance que la sauvegarde s’est terminée, les vérifications 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’isolation physique et de temps de reprise, 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 multi-téraoctets qui prend des jours à récupérer peut manquer un objectif métier 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 ses directives de sécurité des sauvegardes: conserver au moins une copie dans un site géographiquement distinct, isoler au moins une copie hors ligne, protéger les sauvegardes au même niveau de sécurité que la production, et tester l’intégrité et la restauration. Les directives de sécurité cloud de la CNIL indiquent 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 sont un référencement clair pour la pratique actuelle.

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

Le litige d’un client donne à la frontière de la sauvegarde une spécificité juridique. 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 primaire. Le client a demandé des millions d’euros pour perte de données et prétendu préjudice commercial en aval.

Le résultat a changé en appel. Dans son arrêt du 24 avril 2025, la Cour d’appel de Douai a retenu une violation contractuelle car OVH ne pouvait pas laisser le client accéder à la sauvegarde terminée et la conserver pour récupération. Elle n’a pas confirmé 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 retenu 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é applicables et a réduit l’indemnisation à 1 800,48 EUR.

Cette décision est plus étroite et plus instructive que l’indemnisation largement rapportée en première instance. 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 possédait 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 « isolé physiquement », « infrastructure », « local », « région » et « distant » peuvent avoir des significations différentes. Un tableau de disques séparé est isolé d’une panne 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 périmétrique.

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

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 aléas que la conception est censée survivre, l’objectif de reprise et les devoirs restants du client. Les fournisseurs devraient conserver la version historique de ces représentations car l’interface et la documentation disponibles lors de l’achat du service peuvent devenir des preuves centrales ultérieurement.

La limitation contractuelle et la responsabilité opérationnelle divergent également. L’indemnisation en appel était faible car le tribunal a appliqué les limitations convenues après avoir évalué les réclamations et les clauses devant lui. Un plafond de responsabilité ne rend pas la perte permanente de données 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 allouent l’exposition financière. Ils ne restaurent pas les informations ni ne prouvent qu’un contrôle était correctement conçu.

La responsabilité partagée doit être suffisamment spécifique pour être opérationnelle

« Responsabilité partagée » est souvent utilisée comme une manière 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’assigner des contrôles avant. Strasbourg soutient une division plus exacte.

OVH possédait 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 sprinklers dans SBG2 ni créer une coupure électrique d’urgence. Ce sont des contrôles du fournisseur même lorsque les contrats clients limitent les dommages.

OVH possédait également 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 pendant 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 de risque. Là où OVH entreprenait le service de sauvegarde, il possédait la performance du service promis et les preuves concernant la copie résultante.

Les clients possédaient le modèle de conséquence. Un fournisseur ne pouvait pas savoir, sans arrangement géré spécifique, si un petit serveur virtuel contenait un site de test jetable ou la seule copie d’années d’enregistrements commerciaux. Le client devait classer les données, fixer des objectifs de reprise, sélectionner une architecture proportionnée à l’impact, conserver des copies en dehors du domaine de défaillance primaire et tester la reconstruction. Acheter une 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 nu métallique ou l’infrastructure en tant que service, le client possède généralement la sauvegarde et le basculement cohérents avec l’application. Dans une base de données gérée, un produit de messagerie hébergé ou un service de sauvegarde explicite, le fournisseur possède davantage de la copie, de la rétention, de la cohérence et du chemin de restauration.

Un revendeur sur le marché 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.

Les fondamentaux actuels de sauvegarde de l’agence française de cybersécurité ANSSI transforment ces devoirs en contrôles pratiques. Ils préconisent des objectifs de point et de temps de reprise, le schéma 3-2-1, au moins une copie hors ligne ou protégée de manière appropriée hors site, 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 met en avant 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’isolation cyber, la souveraineté et la récupérabilité doivent être conçues ensemble.

La localité répond à plusieurs questions différentes

L’identité européenne d’OVHcloud importait en 2021 et importe 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 hors de propos. Il a montré que la souveraineté n’est pas un substitut à l’ingénierie de disponibilité.

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

• Emplacement juridique:quel pays’s règles de protection des données, de divulgation, d’insolvabilité et sectorielles 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 juridiques étrangères peuvent influencer le service.
• Emplacement physique:quel bâtiment, plaine inondable, réseau électrique, approvisionnement en eau, campus et risque 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:combien de latence, de bande passante, de personnel et de temps de reprise séparent la production de ses utilisateurs et de la copie de reprise.

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 encore plus de diversité géographique tout en préservant un périmètre juridique européen. Que cela soit suffisant dépend de la loi de l’organisation, de son modèle de menace, de la sensibilité des données et de son objectif de reprise.

L’explication de la Commission européenne sur les transferts internationaux empê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 du droit sectoriel, de la politique publique, d’engagements contractuels ou de l’exposition à des juridictions étrangères.

Les directives de qualification SecNumCloud de l’ANSSI illustrent le modèle de souveraineté plus riche. Elles traitent 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 considérant le contrôle d’entreprise et l’exposition au droit non européen. Ce cadre concerne le contrôle du service et des données, pas seulement 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 une production sensible dans un environnement européen qualifié, maintenir une copie de reprise géographiquement distincte dans l’UE, utiliser un chiffrement et des 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 attentif. Le compromis doit être explicite plutôt que caché derrière le mot « local ».

La concentration est une propriété d’application ainsi qu’une propriété de marché

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

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 de fournisseurs non examinée entre les départements. Les propriétaires d’application doivent cartographier les dépendances qui déterminent si leur propre service peut se rétablir. Une entreprise peut utiliser trois fournisseurs cloud dans son portefeuille tandis qu’un seul 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 reprise hors ligne.

La réglementation financière exprime de plus en plus cette responsabilité client retenue. Les lignes directrices 2019 de l’Autorité bancaire européenne sur l’externalisation exigent que les institutions couvertes gouvernent les risques d’externalisation et restent capables de supervision plutôt que de devenir des coquilles vides. Le règlement ultérieur de l’UE sur la résilience opérationnelle numérique (DORA) exige que les entités financières couvertes maintiennent et testent périodiquement les dispositions de sauvegarde, de restauration et de reprise.

Ses exigences à l’article 12 incluent 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 périmètres 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 directeur pour la continuité.

Le cadre de mise en œuvre détaillé de DORA va plus loin. Le règlement délégué 2024 sur la gestion des risques liés aux TIC inclut des scénarios impliquant une perte partielle ou totale des locaux et centres de données, une défaillance de service tiers, des basculements vers une capacité redondante et des pannes électriques généralisées. Strasbourg est exactement le type d’événement physique et fournisseur combiné 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 reprise portable et testable pour les fonctions importantes, pas un slogan architectural. Parfois, cela signifie un service actif sur des zones indépendantes. Parfois, une capacité tiède 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 reprise 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 métier. 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’est produit après la dernière copie utilisable.

Un exercice de reprise mature commence par une perte présumée, pas une exportation pratique. L’équipe devrait faire semblant que la région primaire est inaccessible, que les administrateurs normaux ne peuvent pas se connecter via son chemin d’identité et que le support fournisseur est saturé. Elle devrait obtenir la sauvegarde en utilisant des identifiants et des clés stockés 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 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 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 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 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 sous la défaillance présumée. Chacun est utile; aucun ne devrait être représenté comme le suivant.

C’est particulièrement important pour les petites organisations. Elles peuvent ne pas avoir besoin d’infrastructure active-active ou d’un deuxième cloud dédié. Elles ont besoin d’un chemin 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 son domaine et ses identifiants de déploiement indépendamment, documenter une reconstruction propre et tester un échantillon de restauration. Le contrôle devrait 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 a décrit un programme substantiel « Hyper Resilience ». L’entreprise 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 60 à 120 minutes, et placerait les salles énergétiques et de batteries à l’extérieur des bâtiments des centres de données pour les nouveaux sites et, là où possible, pour 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 a également indiqué que les services d’incendie locaux ont visité tous les sites OVH dans les quatre mois suivant l’incident, que les documents d’urgence et les procédures de coupure électrique 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é lorsque les travaux seraient 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 répond à la croissance précoce. Des compartiments coupe-feu plus solides répondent à la propagation verticale et entre bâtiments. Des salles énergétiques externes séparent les risques d’allumage des salles de serveurs. Des coupures zonées répondent au retard et au rayon d’explosion de l’isolation électrique. Le stockage d’eau répond à la capacité de première intervention. Les visites et exercices des services d’incendie répondent à la méconnaissance, aux plans et aux décisions de commandement.

Le document d’enregistrement universel 2025 d’OVHcloud indique que le groupe a poursuivi la cartographie des risques de site au cours de l’année 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 conclusion 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 énergétique et informatique pertinente; lesquels ont des compartiments de 120 minutes; quelles salles de batteries sont externes; quelles zones ont une isolation actionnée à distance; quels besoins en débit d’eau ont été testés; quels exercices des services d’incendie ont eu lieu; quelles constatations 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 contradictoire montrent si cela fonctionne.

L’entreprise mérite également du crédit pour avoir conservé un journal de mise à jour public détaillé pendant une reprise difficile, mobilisé une capacité de nettoyage et de récupération spécialisée, remplacé l’infrastructure, communiqué des progrès spécifiques au produit 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 autrement disparaîtraient.

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. Son guide des modes de déploiement distingue 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 qu’une architecture 3-AZ utilise des zones indépendantes pour les cas de production et de reprise après sinistre plus exigeants.

L’aperçu de la région et de la zone de disponibilité de l’entreprise indique également que les clients recherchant une résilience plus élevée devraient 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 distribuer les ressources et l’état de l’application entre elles. Lancer simplement dans une région 3-AZ ne garantit pas qu’une machine virtuelle, une base de données ou un volume placé manuellement s’étend sur plusieurs zones.

La documentation actuelle sur la sauvegarde d’instance distingue 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 partie du contrôle.

La documentation actuelle ne doit pas être utilisée pour reconstruire ce qui était offert à chaque client en mars 2021. Elle est pertinente pour la question actuelle de responsabilité: le marché a-t-il appris à exposer séparément la localité et la résilience? OVHcloud le fait maintenant dans ces guides produits. La prochaine étape d’assurance consiste à rendre la distinction cohérente sur 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 progressives. Un service de développement à faible coût peut raisonnablement par défaut à la sauvegarde locale si l’interface l’étiquette comme une protection contre la défaillance d’instance, pas une catastrophe régionale. Une base de données de production ou un produit marqué sauvegarde pourrait exiger que le client confirme le domaine de défaillance, afficher un avertissement lorsque toutes les copies partagent un seul site et proposer une destination distante dans la même région juridique.

L’objectif est une acceptation éclairée du risque, pas 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 reprise 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 un revenu de stockage.

Pour la couche installation, la direction devrait connaître la perte maximale probable sur chaque site, pas seulement la redondance des équipements. Les rapports devraient montrer la couverture de suppression, l’intégrité du compartimentage, la séparation des salles énergétiques, 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 devraient 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 devrait savoir comment les domaines de défaillance des produits sont représentés et testés. Les rapports devraient montrer combien de services commercialisés avec un langage de sauvegarde ou de haute disponibilité stockent chaque copie dans un seul site ou 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 des temps de reprise; la dérive de la documentation; et les plaintes indiquant que les clients ont mal compris l’emplacement.

Le conseil devrait également recevoir des exceptions, pas seulement des moyennes. Un taux de réussite de 99,99 % des travaux de sauvegarde peut coexister avec des milliers de copies dans un seul domaine physique. Un pourcentage global de suppression peut cacher un vieux bâtiment à haute densité. Un temps de restauration moyen peut cacher les ensembles de données les plus volumineux et les plus conséquents. L’exposition des extrêmes appartient à la gouvernance car Strasbourg était un événement extrême avec un impact concentré.

Un défi indépendant devrait tracer 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 primaire de l’exercice. 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 reprise 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 à la conséquence de la 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 budgétaire, l’instantané local ou la base de données gérée achetée. 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 un seuil manqué; il ne décrit pas en soi la durabilité des données ni ne garantit la reprise.

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

Enfin, un client doit décider combien 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 hebdomadaire hors ligne peut être adéquate pour une archive statique et catastrophique pour les transactions. La responsabilité n’exige pas le même contrôle partout. Elle exige une relation consciente entre la conséquence, la reprise 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 la contrainte physique. Des bâtiments séparés formaient un seul site d’urgence. Des serveurs sains sont devenus indisponibles avec les 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 reprise 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 monozone du déploiement multizone. 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 aux réels domaines de défaillance; et que la reprise 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 primaire, dans les limites juridiques approuvées, et que leurs personnes peuvent les restaurer dans 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 consommera pas silencieusement la production, la reprise et le moyen de comprendre ce qui a été perdu; les choix de localité seront explicites tant sur la juridiction que sur le risque; et le mot « sauvegarde » sera soutenu 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.