Incendie du datacenter de Strasbourg : cinq ans après, les mêmes erreurs

Dans la nuit du 10 mars 2021, un incendie détruit le datacenter SBG2 d'OVHcloud, dans le port du Rhin à Strasbourg, et endommage les bâtiments voisins. Environ 65 000 clients sont touchés, et pour une partie d'entre eux la perte est définitive : ni site, ni base de données, ni moyen de reconstruire.

Ce n'était pas un incident lointain. C'était ici, dans le Grand Est, à quelques kilomètres d'entreprises qui hébergeaient là leur site, leur messagerie, parfois leur ERP. Et la configuration qui a coûté le plus cher cette nuit-là — un seul hébergeur, un seul site géographique, aucune copie ailleurs — reste courante dans la région : la moitié des 41 sites que j'ai relevés sont hébergés chez le même fournisseur.

Voici ce que cet épisode a réellement enseigné — au-delà de l'émotion du moment et des captures d'écran de flammes qui ont tourné sur les réseaux.

Le modèle de responsabilité partagée n'est pas une clause de style

La leçon la plus coûteuse a été juridique autant que technique. Beaucoup d'entreprises pensaient sincèrement que leur hébergeur sauvegardait leurs données. Dans la plupart des offres d'infrastructure — serveur dédié, machine virtuelle, serveur privé — ce n'est pas le cas par défaut. L'hébergeur fournit et maintient le matériel, le réseau, l'alimentation, la climatisation. Les données, leur sauvegarde et leur restauration relèvent du client, sauf souscription explicite à une option dédiée.

Cette répartition figure dans les conditions générales de service de tous les fournisseurs, y compris les grands acteurs américains. Elle est rarement lue avant l'incident.

Action concrète, à faire cette semaine : ouvrez la console d'administration de votre hébergement et vérifiez, ligne par ligne, quelles options de sauvegarde sont réellement actives et facturées. Une case décochée ne coûte rien tous les mois, ce qui la rend parfaitement invisible sur une facture. C'est d'ailleurs l'un des postes que je détaille dans ce que le prix affiché d'un hébergement ne dit pas.

« Sauvegardé » et « sauvegardé ailleurs » sont deux choses différentes

Une partie des victimes disposait bien de sauvegardes. Elles étaient stockées dans le même datacenter, parfois dans le bâtiment mitoyen. L'incendie a emporté les deux.

La leçon dépasse largement le risque d'incendie. Un datacenter constitue un domaine de défaillance : il partage une alimentation, un refroidissement, une arrivée réseau, et un périmètre physique. Toute copie stockée à l'intérieur de ce périmètre partage le sort de l'original. C'est vrai pour le feu, mais aussi pour une inondation, une coupure électrique prolongée ou une erreur d'exploitation.

Une sauvegarde utile est stockée dans une région géographique distincte : chez le même fournisseur au minimum, chez un fournisseur différent dans l'idéal. Pour une PME, le surcoût se compte en quelques euros par mois. À comparer au coût de reconstruction d'un fichier clients de quinze ans.

La règle de référence tient en trois chiffres, 3-2-1 : trois copies des données, sur deux supports différents, dont une hors site. Elle a trente ans et elle n'a pas pris une ride.

Le test de restauration est le seul indicateur qui compte

Après l'incendie, plusieurs entreprises ont découvert que leurs sauvegardes existaient, mais étaient inexploitables : archives corrompues, dump de base incomplet, fichiers de configuration absents, ou tout simplement personne ne sachant remonter l'environnement — le prestataire qui l'avait installé n'était plus là depuis trois ans.

Une sauvegarde jamais restaurée est une hypothèse, pas une protection. Le test doit aller jusqu'au bout : repartir de l'archive, reconstruire un environnement fonctionnel, se connecter, effectuer une action métier réelle — passer une commande, éditer un bon, envoyer un e-mail transactionnel. Chronométrez. C'est votre délai de reprise réel, et il est généralement très éloigné de celui que vous imaginiez.

Les deux chiffres à écrire avant de dépenser un euro

Avant de discuter redondance, répondez à deux questions. Elles conditionnent tout le reste.

Combien de temps pouvez-vous rester à l'arrêt ? C'est votre RTO. Pour un site vitrine, quarante-huit heures sont souvent supportables. Pour un portail sur lequel vos transporteurs déposent leurs créneaux de quai, deux heures coûtent déjà des camions immobilisés.

Combien de données pouvez-vous perdre ? C'est votre RPO. Si votre dernière sauvegarde date de la nuit dernière, vous acceptez implicitement de perdre une journée entière de commandes et de messages clients.

Écrivez ces deux valeurs noir sur blanc. Elles transforment un débat d'opinion en décision d'investissement : une reprise en deux heures ne coûte pas le même prix qu'une reprise en deux jours, et c'est très bien ainsi.

Trois niveaux de redondance, par coût croissant

Il ne s'agit pas de conclure qu'il faut fuir tel ou tel hébergeur. L'incident aurait pu se produire chez n'importe qui, et la transparence dont l'entreprise a fait preuve pendant la crise a d'ailleurs été assez unanimement saluée. Il s'agit de dimensionner sa redondance en connaissance de cause.

Niveau 1 — sauvegarde hors région. Le minimum absolu, accessible à tous les budgets. Vous acceptez plusieurs heures, voire un ou deux jours d'indisponibilité, mais vous ne perdez pas les données.

Niveau 2 — infrastructure reproductible. Votre serveur est décrit dans du code — conteneurs, scripts de provisionnement, configuration versionnée — et non configuré à la main au fil des années. Reconstruire ailleurs devient une opération de quelques heures au lieu de plusieurs jours de tâtonnement archéologique.

Niveau 3 — répartition multi-zones. Votre application tourne simultanément dans deux zones de disponibilité, avec bascule automatique. C'est le niveau qui justifie un vrai budget, et il n'a de sens que si votre RTO se compte en minutes.

La plupart des PME ont besoin du premier niveau, gagnent énormément au deuxième, et n'ont aucun besoin du troisième. Payer pour le troisième sans avoir le premier est l'erreur classique — souvent parce qu'un commercial a vendu de la « haute disponibilité » sans jamais poser la question des sauvegardes.

Le mode dégradé, l'investissement le plus rentable

La reprise complète coûte cher. Le mode dégradé ne coûte presque rien et sauve la relation client.

Préparez à l'avance une page statique, hébergée ailleurs que votre production, indiquant que le service est perturbé, ce qui fonctionne encore, et comment vous joindre. Prévoyez aussi un canal de communication indépendant de votre infrastructure : si votre messagerie est hébergée sur le serveur en panne, vous ne pourrez pas prévenir vos clients de la panne. C'est exactement ce qui s'est produit en mars 2021 pour des dizaines d'entreprises.

Le test le plus simple

Posez cette question à votre prestataire ou à votre équipe technique, et écoutez la réponse :

« Si notre datacenter principal disparaît ce soir, quelles sont les étapes précises pour être de nouveau en ligne, et combien de temps prennent-elles ? »

Si la réponse est hésitante, vous connaissez votre prochain chantier. Si elle est précise, documentée et déjà testée, vous êtes dans le meilleur quart des entreprises françaises.

Et si vous vous demandez plus largement si votre plateforme actuelle mérite d'être réparée ou refaite, j'ai posé la grille de décision dans refaire son site ou le réparer. Le sujet de la résilience y pèse plus lourd que la plupart des dirigeants ne l'imaginent.