Incendie d'OVHcloud, pannes d'AWS et de Cloudflare : aucun site n'est à l'abri. Voici les trois étapes pour limiter la durée d'une panne web et ne pas perdre vos données.
On ne peut pas empêcher toutes les pannes web, mais on peut en limiter la durée et les dégâts. Trois étapes suffisent pour la plupart des entreprises : des sauvegardes externalisées et testées (règle 3-2-1), une surveillance qui vous alerte avant vos clients, et un plan de reprise écrit qui dit qui fait quoi et en combien de temps. La haute disponibilité multi-sites ne se justifie que si chaque heure d’arrêt coûte cher.
L’incendie du centre de données d’OVHcloud à Strasbourg en mars 2021 a rappelé brutalement qu’un site « dans le cloud » reste hébergé dans un bâtiment, sur des machines. Depuis, d’autres pannes de grande ampleur ont touché les plus gros acteurs du web. Voici ce qu’on en retient, et comment protéger concrètement votre site et vos données selon votre taille et vos enjeux.
- Qu’est-ce qu’une panne web et d’où vient-elle ?
- Que nous apprennent les grandes pannes récentes ?
- Combien de temps d’arrêt et de perte de données pouvez-vous accepter ?
- Étape 1 : comment sauvegarder vos données correctement ?
- Étape 2 : comment détecter une panne avant vos clients ?
- Étape 3 : comment préparer la reprise d’activité ?
- Faut-il une infrastructure haute disponibilité ?
- Quelles erreurs éviter ?
- Questions fréquentes
- Sources
Qu’est-ce qu’une panne web et d’où vient-elle ?
On parle de panne web quand un site, une boutique en ligne, une application ou un service en ligne (messagerie, paiement, API) devient inaccessible ou inutilisable. Pour l’entreprise, le résultat est le même quelle que soit la cause : des ventes perdues, des clients qui ne peuvent pas vous joindre, une image dégradée.
Les causes se rangent en quelques familles :
- Incident physique chez l’hébergeur : incendie, coupure électrique, panne matérielle.
- Erreur de configuration ou de mise à jour : chez vous (une extension WordPress incompatible, une migration ratée) ou chez un prestataire dont vous dépendez.
- Attaque : déni de service (DDoS), piratage, rançongiciel qui chiffre les données.
- Dépendance tierce : le site fonctionne, mais le CDN, le service de paiement, le serveur DNS ou le fournisseur d’e-mails est en panne.
- Oubli administratif : nom de domaine ou certificat HTTPS expiré, abonnement d’hébergement non renouvelé.
La dernière catégorie est la plus banale et la plus évitable. Les deux précédentes sont celles que l’on sous-estime le plus.
Que nous apprennent les grandes pannes récentes ?
L’incendie d’OVHcloud à Strasbourg (mars 2021)
Dans la nuit du 9 au 10 mars 2021, un incendie a entièrement détruit le centre de données SBG2 d’OVHcloud et endommagé en partie SBG1. Les deux autres bâtiments du site ont dû être arrêtés. Selon Netcraft, environ 3,6 millions de serveurs web, représentant 464 000 noms de domaine, ne répondaient plus le matin même. Les données stockées uniquement sur les serveurs détruits, sans copie ailleurs, ont été perdues.
Deux enseignements. D’abord, le rapport du Bureau d’enquêtes et d’analyses sur les risques industriels (BEA-RI), publié en mai 2022, pointe la conception du bâtiment, l’absence de système d’extinction automatique et la difficulté à couper l’alimentation électrique : des facteurs sur lesquels un client n’a aucune prise. Ensuite, le tribunal de commerce de Lille a jugé en janvier 2023 qu’OVHcloud avait commis un manquement contractuel en stockant les sauvegardes d’un client au même endroit que ses données principales. Autrement dit : une sauvegarde située dans le même bâtiment ne protège pas d’un sinistre sur ce bâtiment.
AWS en octobre 2025 et Cloudflare en novembre 2025
Les géants ne sont pas épargnés. Les 19 et 20 octobre 2025, Amazon Web Services a connu une panne dans sa région de Virginie du Nord (us-east-1), partie de son service de base de données DynamoDB puis étendue au lancement de nouvelles machines et aux répartiteurs de charge, pendant plus de quatorze heures au total selon le compte rendu d’AWS. Le 18 novembre 2025, c’est Cloudflare qui a vu son réseau renvoyer des erreurs à partir de 11 h 20 UTC ; l’essentiel du trafic est revenu vers 14 h 30 et tous les systèmes à 17 h 06. Cloudflare précise que la cause n’était pas une attaque, mais un fichier de configuration devenu trop gros après une modification de droits sur une base de données.
La leçon est différente : même un site parfaitement hébergé peut tomber parce qu’un maillon dont il dépend tombe. Il faut donc savoir de quels services votre site dépend, et ce qui se passe si l’un d’eux s’arrête.
Combien de temps d’arrêt et de perte de données pouvez-vous accepter ?
Avant de choisir des solutions, il faut répondre à deux questions, que les informaticiens appellent RTO et RPO :
- RTO (durée maximale d’interruption admissible) : combien de temps votre site peut-il rester hors ligne avant que cela devienne grave ? Une heure, une journée, une semaine ?
- RPO (perte de données maximale admissible) : combien de données pouvez-vous perdre ? Les commandes de la dernière heure, de la dernière journée ?
Un site vitrine mis à jour une fois par mois supporte une sauvegarde quotidienne et une remise en ligne en une journée. Une boutique qui prend des commandes en continu, ou une application métier utilisée par vos équipes toute la journée, exige des sauvegardes bien plus fréquentes et une reprise en quelques heures. Plus les objectifs sont serrés, plus la solution coûte cher : c’est pourquoi il faut les fixer par écrit, au regard de ce que coûte réellement une heure d’arrêt.
| Type de site | Objectif réaliste | Dispositif adapté |
|---|---|---|
| Site vitrine | Reprise en 24 h, perte d’un jour au plus | Sauvegarde quotidienne externalisée, surveillance, procédure de restauration |
| Boutique en ligne | Reprise en quelques heures, perte minimale des commandes | Sauvegardes fréquentes de la base, serveur de secours prêt à démarrer, plan de reprise testé |
| Application critique | Reprise en minutes | Haute disponibilité, réplication de la base sur un autre site, basculement automatique |
Étape 1 : comment sauvegarder vos données correctement ?
La règle la plus répandue est la règle 3-2-1 :
- 3 copies de vos données : les données en service et deux sauvegardes ;
- 2 supports ou technologies différents (par exemple le disque du serveur et un stockage objet) ;
- 1 copie hors site, dans un autre lieu géographique, idéalement chez un autre prestataire.
Face aux rançongiciels, on y ajoute une copie déconnectée ou non modifiable. Le site gouvernemental Cybermalveillance.gouv.fr le rappelle : une sauvegarde reliée en permanence à votre ordinateur ou à votre réseau peut être chiffrée ou détruite par le programme malveillant en même temps que le reste.
Pour un site web, une sauvegarde complète comprend :
- la base de données (contenus, commandes, comptes clients) ;
- les fichiers (thème, extensions, images et documents envoyés) ;
- la configuration (serveur, DNS, variables d’environnement) et les accès, rangés dans un gestionnaire de mots de passe.
Enfin, et c’est le point le plus négligé : testez la restauration. Une sauvegarde qu’on n’a jamais restaurée n’offre aucune garantie. Planifiez une restauration d’essai sur un serveur de test à intervalle régulier, et chronométrez-la : c’est votre vrai délai de reprise. Pour une base PostgreSQL, notre article sur l’export et la restauration avec pg_dump détaille les commandes.
Étape 2 : comment détecter une panne avant vos clients ?
Beaucoup d’entreprises apprennent que leur site est en panne par un client. Un outil de surveillance interroge votre site depuis l’extérieur toutes les minutes et vous alerte par e-mail ou SMS dès qu’il ne répond plus. Surveillez au minimum :
- la disponibilité de la page d’accueil et d’une page clé (panier, formulaire de contact) ;
- la date d’expiration du certificat HTTPS et du nom de domaine ;
- le bon déroulement des sauvegardes (une sauvegarde qui échoue en silence est un classique) ;
- l’espace disque et la charge du serveur ;
- les pages d’état de vos prestataires critiques (hébergeur, CDN, paiement).
Nous détaillons les outils et réglages dans notre article sur le monitoring de site web.
La surveillance couvre aussi la sécurité, car une partie des pannes vient d’attaques. Les mesures de base restent les plus efficaces : mises à jour régulières du CMS et des extensions, comptes nominatifs, double authentification, et mots de passe robustes. La CNIL considère par exemple comme équivalents un mot de passe d’au moins 12 caractères mêlant majuscules, minuscules, chiffres et caractères spéciaux, ou un mot de passe d’au moins 14 caractères avec majuscules, minuscules et chiffres. Pour le reste, voyez notre guide pour sécuriser un site web. Pour une application sensible, des tests d’intrusion menés par un spécialiste permettent de trouver les failles avant les attaquants.
Étape 3 : comment préparer la reprise d’activité ?
Le jour de la panne, il est trop tard pour chercher les accès de l’hébergeur ou se demander qui prévenir. Un plan de reprise d’activité (PRA) est simplement un document qui répond à l’avance à ces questions. Pour une PME, quelques pages suffisent :
- L’inventaire : quels services (site, boutique, e-mails, outils métier), hébergés où, dépendant de quels prestataires.
- Les objectifs : RTO et RPO pour chaque service.
- Les contacts : qui décide, qui intervient, le support de chaque prestataire.
- Les accès : où sont les identifiants (registrar du nom de domaine, DNS, hébergeur, sauvegardes), stockés hors de l’infrastructure qu’ils servent à réparer.
- La procédure de restauration pas à pas, y compris vers un autre hébergeur si le premier est indisponible.
- La communication : page de maintenance, message sur les réseaux sociaux, information des clients.
- Le test : une simulation au moins une fois par an, et une mise à jour du document après chaque changement important.
On distingue souvent deux modes de reprise. Le redémarrage à chaud : un serveur de secours, déjà prêt avec une copie récente des données, prend le relais rapidement. Le redémarrage à froid : on reconstruit l’environnement puis on restaure la dernière sauvegarde, ce qui est moins coûteux mais plus lent. Le choix découle directement de votre RTO.
Un point souvent oublié : le nom de domaine et la zone DNS. Si votre DNS est géré par l’hébergeur en panne, vous ne pourrez pas rediriger votre site vers un serveur de secours. Garder le DNS chez un prestataire distinct de l’hébergement donne cette marge de manœuvre. Pensez aussi à une durée de vie (TTL) des enregistrements DNS raisonnable, expliquée dans notre article sur le TTL DNS, pour qu’une bascule soit prise en compte rapidement.
Faut-il une infrastructure haute disponibilité ?
La haute disponibilité consiste à éliminer les points de défaillance uniques pour que le service continue de fonctionner quand un élément tombe. Elle repose sur quatre briques :
- Équilibrage de charge : un répartiteur distribue les visites entre plusieurs serveurs et retire automatiquement celui qui ne répond plus.
- Réplication des données : la base de données est copiée en continu sur un second serveur, prêt à prendre le relais.
- Diversité géographique : les serveurs sont répartis dans plusieurs centres de données, voire plusieurs régions, pour résister à un sinistre local comme celui de Strasbourg.
- Sauvegarde et restauration : la haute disponibilité ne dispense pas des sauvegardes. Une erreur ou une suppression accidentelle est répliquée instantanément sur tous les serveurs.
À qui ça ne sert pas : pour un site vitrine ou un petit site WordPress, une architecture multi-régions coûte bien plus cher que ce qu’une journée d’interruption ferait perdre. Des sauvegardes externalisées, une surveillance et une procédure de restauration testée offrent un bien meilleur rapport coût/protection. La haute disponibilité se justifie pour les plateformes où chaque minute d’arrêt se chiffre : e-commerce à fort volume, applications utilisées en continu, services vendus avec un engagement de disponibilité.
Pour la plupart de nos clients, la bonne réponse est un contrat d’hébergement et de maintenance qui inclut sauvegardes, mises à jour et surveillance : nos formules mensuelles sont détaillées dans nos tarifs indicatifs. Si vous comparez les hébergeurs, notre sélection des meilleurs hébergeurs web peut vous aider.
Quelles erreurs éviter ?
- Croire que l’hébergeur sauvegarde tout. Vérifiez votre contrat : certaines offres n’incluent aucune sauvegarde, ou les stockent au même endroit que le serveur.
- Tout confier à un seul prestataire : hébergement, sauvegardes, DNS et e-mails chez le même fournisseur, c’est un point de défaillance unique.
- Ne jamais tester une restauration, et découvrir le jour J qu’un fichier manque ou que la procédure prend trois jours.
- Stocker les accès de secours sur le serveur qu’ils servent à réparer.
- Oublier les renouvellements du nom de domaine et des certificats.
Questions fréquentes
Qu’est-ce qu’un plan de reprise d’activité (PRA) ?
C’est un document qui décrit comment remettre en service votre système informatique après un sinistre : objectifs de délai et de perte de données, contacts, accès, procédures de restauration et tests. Il se distingue du plan de continuité d’activité (PCA), qui vise à ne pas interrompre le service du tout.
Mon hébergeur fait des sauvegardes, est-ce suffisant ?
Rarement. Ces sauvegardes sont souvent conservées peu de temps, parfois dans le même centre de données que le serveur. Gardez au moins une copie chez un autre prestataire, sous votre contrôle.
À quelle fréquence sauvegarder un site ?
Elle dépend de la quantité de données que vous acceptez de perdre. Une sauvegarde quotidienne convient à un site vitrine ; une boutique ou une application qui enregistre des données en continu demande des sauvegardes de la base plusieurs fois par jour, voire une réplication.
Comment savoir si mon site est en panne ou si c’est seulement chez moi ?
Testez depuis un autre réseau (votre téléphone en 4G ou 5G, sans Wi-Fi), consultez la page d’état de votre hébergeur, ou utilisez un service de vérification de disponibilité en ligne. Un outil de monitoring vous évite cette question en vous alertant automatiquement.
L’hébergeur est-il responsable en cas de perte de données ?
Cela dépend du contrat et des faits. Après l’incendie de Strasbourg, la justice a retenu un manquement d’OVHcloud dans une affaire où les sauvegardes du client étaient stockées au même endroit que les données. Mais une indemnisation ne restaure pas vos données : la protection passe d’abord par vos propres copies.
Sources
- Netcraft : 3.6 million websites taken offline after fire at OVH datacenters (10 mars 2021)
- BEA-RI : rapport d’enquête sur l’incendie du centre de données OVH de Strasbourg (mai 2022)
- Wikipédia : Incendie du centre de données d’OVHcloud à Strasbourg (chronologie et décisions de justice)
- AWS : résumé de l’interruption de service des 19 et 20 octobre 2025 (us-east-1)
- Cloudflare : compte rendu de la panne du 18 novembre 2025
- Cybermalveillance.gouv.fr : les sauvegardes, 10 bonnes pratiques
- CNIL : mots de passe, recommandations de sécurité minimales
