Votre site tombe un lundi matin : sauvegarde, restauration et plan de reprise, ce qui sépare une heure d'arrêt d'une semaine

Une sauvegarde n'est pas un plan de reprise : la distinction qui évite les mauvaises surprises

Une sauvegarde est une copie de vos données, un plan de reprise est la démonstration que vous savez remettre votre site en ligne avec cette copie, dans un délai connu. Beaucoup de sites possèdent la première et ignorent tout de la seconde, ce qui ne se voit qu'au pire moment : le jour de la panne.

La nuance paraît scolaire, elle est pourtant au cœur de presque tous les incidents graves que rencontrent les PME et les grands comptes. Le dirigeant pense « nous avons des sauvegardes » parce que son hébergeur ou son prestataire le lui a dit, ou parce qu'une case est cochée dans un tableau de bord. Au moment où le site affiche une page blanche, une erreur 500 ou un message de rançon, la vraie question devient : combien de temps faut-il pour que le site fonctionne de nouveau, et quelle quantité de contenu, de commandes ou de demandes de contact aura disparu entre la dernière copie et l'incident ?

Ces deux questions n'ont de réponse que si quelqu'un a fait l'exercice avant. Une sauvegarde jamais restaurée reste une hypothèse. Elle peut être vide parce qu'une tâche planifiée s'est arrêtée après une mise à jour de PHP, incomplète parce que la base de données dépasse une limite de temps, inexploitable parce que l'archive a été téléchargée en mode texte plutôt qu'en mode binaire, ou tout simplement stockée au même endroit que le site qu'elle est censée protéger. Chacun de ces cas est documenté et chacun se rencontre régulièrement.

Ce billet propose une méthode concrète, adaptée à un site vitrine ou institutionnel géré sous Joomla, WordPress, Drupal ou PrestaShop : distinguer ce que l'on sauvegarde, où on le range, comment on prouve que cela se restaure, et ce que l'on doit exiger d'un contrat de maintenance. Il s'appuie sur un fait judiciaire daté, sur les recommandations publiques de Cybermalveillance.gouv.fr, sur la documentation d'Akeeba, sur les calendriers de PHP publiés par php.net et sur les tarifs de marché français relevés en 2026.

L'actualité s'y prête : chaque mois d'octobre, le Cybermois, coordonné par Cybermalveillance.gouv.fr dans le cadre du mois européen de la cybersécurité, remet la protection des données au premier plan, y compris pour les PME et les collectivités. C'est le bon moment pour vérifier que vos copies sont réelles, et pas seulement planifiées.

L'incendie d'OVHcloud à Strasbourg : ce que le jugement du 26 janvier 2023 enseigne aux propriétaires de sites

Dans la nuit du 9 au 10 mars 2021, un incendie a détruit le datacenter SBG2 d'OVHcloud à Strasbourg. Le 26 janvier 2023, le tribunal de commerce de Lille Métropole a condamné l'hébergeur à verser plus de 100 000 euros à l'un de ses clients, au motif que les sauvegardes se trouvaient dans le même bâtiment que le serveur détruit.

Le client en question, Bati Courtage, un courtier en travaux animant un réseau d'indépendants, avait vu ses sites internet devenir inaccessibles, avec des conséquences directes sur l'activité de ses clients et de ses franchisés. Selon le compte rendu publié par la presse spécialisée, le tribunal a relevé que les trois réplications de sauvegarde étaient conservées sur le même site physique que les données principales, alors que le contrat laissait entendre une séparation. L'indemnisation totale s'élève à 101 102 euros, répartis entre préjudice financier, perte d'actifs immatériels, atteinte à la réputation, frais de remise en état du site et indemnité de procédure.

Il faut lire cette décision avec nuance. Elle porte sur les termes d'un contrat précis et sur ce que l'hébergeur avait promis. Elle ne signifie pas que tout hébergeur sera condamné dans toute situation, et une procédure collective liée à l'incendie était encore mentionnée comme en cours au moment de la publication. En revanche, elle illustre un point que les juristes comme les techniciens connaissent bien : la présence de plusieurs copies ne protège de rien si elles partagent le même point de défaillance.

Pour un propriétaire de site, trois enseignements pratiques se dégagent. Le premier : savoir où se trouvent réellement vos sauvegardes, c'est-à-dire chez quel fournisseur, dans quel bâtiment, sous quel compte d'accès. Le deuxième : lire le contrat d'hébergement et le contrat de maintenance pour distinguer ce qui est promis de ce qui est simplement possible. Le troisième : ne jamais déléguer entièrement la copie de secours à celui qui héberge la production, car l'incident qui frappe l'un frappe alors l'autre.

Cet événement a aussi fait évoluer les pratiques de nombreux prestataires français. Beaucoup proposent désormais des sauvegardes externalisées chez un second acteur, parfois dans un autre pays européen. Si votre prestataire ne peut pas vous dire en une phrase où se trouve la copie hors site, c'est qu'elle n'existe peut-être pas.

RPO et RTO : les deux durées que vous devez connaître avant la panne

Le RPO (Recovery Point Objective) est la quantité de données que vous acceptez de perdre, exprimée en temps, et le RTO (Recovery Time Objective) est la durée maximale d'indisponibilité que vous tolérez. Fixer ces deux chiffres transforme la sauvegarde d'un réflexe technique en décision de gestion.

Prenons un site institutionnel dont le contenu change une fois par semaine : une sauvegarde quotidienne offre un RPO de vingt-quatre heures, très largement suffisant. Prenons maintenant une boutique PrestaShop qui encaisse des commandes en continu : une sauvegarde nocturne signifie qu'une panne à seize heures peut effacer toute une journée de commandes, de comptes clients et de paiements réconciliés. Le même mécanisme, deux niveaux de risque opposés.

Le RTO suit la même logique. Remettre un site statique en ligne depuis une archive peut prendre une à deux heures si tout est prêt. Reconstruire un site sous Drupal avec des modules sur mesure, une base volumineuse et une configuration serveur particulière peut prendre une journée, surtout si personne n'a documenté la pile technique. La différence entre ces deux situations n'est pas la complexité du site, c'est la préparation.

La bonne méthode consiste à poser trois questions à la direction, et non au prestataire. Combien de temps le site peut-il rester indisponible avant que l'activité ne soit réellement touchée : une heure, une demi-journée, trois jours ? Quelle perte de données est supportable : une journée de modifications éditoriales, une heure de commandes, aucune ? Quel est le coût d'une heure d'arrêt pour votre entreprise, en chiffre d'affaires, en demandes commerciales manquées et en image ? Les réponses, même approximatives, guident ensuite les choix techniques : fréquence des sauvegardes, type d'hébergement, supervision, astreinte.

Un contrat de maintenance sérieux traduit ces réponses en engagements écrits : fréquence de sauvegarde, durée de conservation, localisation, délai de prise en charge d'un incident, et idéalement un test de restauration périodique. Sans ces éléments, la formule « sauvegardes incluses » ne vous dit rien de ce que vous recevrez réellement.

Ce qu'une sauvegarde de site doit réellement contenir

Une sauvegarde de site complète comprend les fichiers du CMS, la base de données, la configuration du serveur et les éléments de contexte nécessaires à la remise en route : version de PHP, modules activés, tâches planifiées, certificats et accès DNS. Copier uniquement le dossier du site, ou uniquement la base, ne permet pas de restaurer.

Les fichiers regroupent le cœur du CMS, le thème, les extensions et surtout les contenus téléversés : images, documents PDF, médias. Ce dossier de médias est souvent le plus lourd, et c'est celui que les sauvegardes allégées excluent parfois pour gagner du temps, avec des effets désagréables à la restauration.

La base de données contient les articles, les pages, les utilisateurs, les paramètres, les formulaires reçus et, pour une boutique, les commandes. C'est la partie la plus sensible, car elle évolue en permanence et doit être copiée de façon cohérente. Une exportation lancée pendant une écriture peut produire une copie incohérente, d'où l'intérêt d'outils éprouvés. Sous Joomla, Akeeba Backup embarque fichiers et base dans une seule archive et dispose d'un outil de restauration associé, Kickstart. Sous WordPress, il existe plusieurs extensions comparables, et les hébergeurs proposent souvent leur propre mécanisme.

Le contexte serveur est l'angle mort habituel. Un site restauré sur un serveur dont la version de PHP ou de la base de données diffère de l'original peut afficher des erreurs que la copie n'explique pas. À ce sujet, le calendrier de PHP compte : selon php.net, PHP 8.2 reçoit des correctifs de sécurité jusqu'au 31 décembre 2026, PHP 8.3 jusqu'au 31 décembre 2027, PHP 8.4 jusqu'au 31 décembre 2028 et PHP 8.5 jusqu'au 31 décembre 2029. WordPress recommande aujourd'hui PHP 8.3 ou supérieur, avec MariaDB 10.11 ou MySQL 8.0 au minimum conseillé, d'après la page officielle des prérequis. Un serveur de secours doit donc être aligné sur ces versions, sans quoi la restauration réussit techniquement et échoue fonctionnellement.

Il faut enfin conserver, à part, les éléments qui ne sont pas dans le site : l'accès au registrar du nom de domaine, la zone DNS, les identifiants de l'hébergeur, les clés des services tiers (messagerie, paiement, analytics). Lors d'un incident, le temps perdu à retrouver qui détient le compte du nom de domaine dépasse parfois celui de la restauration elle-même.

Appliquer la règle des trois copies à un site vitrine ou institutionnel

La règle 3-2-1 recommande trois copies de vos données, sur deux supports différents, dont une conservée hors site. Appliquée à un site web, elle signifie : la production, une sauvegarde sur l'hébergement et une copie chez un autre fournisseur, isolée de l'accès qui administre le site.

Cybermalveillance.gouv.fr, dans ses conseils sur les sauvegardes, formule l'esprit de cette règle sans la nommer ainsi : planifier des sauvegardes régulières, stocker des copies dans un lieu différent de celui des données d'origine pour résister à un sinistre physique, déconnecter le support une fois la copie terminée pour qu'un logiciel malveillant ne la chiffre pas à son tour, et tester régulièrement que la copie fonctionne en la restaurant. Quatre gestes, tous transposables au web.

Pour un site, la traduction concrète tient en quelques choix. Les sauvegardes d'hébergement, celles que propose votre hébergeur, couvrent les incidents courants comme une mauvaise manipulation ou une mise à jour ratée. Elles ne couvrent ni la destruction de l'infrastructure, ni la compromission du compte d'hébergement, ni la faillite du fournisseur. La copie hors site doit donc se situer chez un autre acteur, avec un accès distinct, idéalement en écriture seule : le serveur de production peut y déposer une archive, mais ne peut pas la supprimer.

Cette dernière précaution répond aux attaques les plus coûteuses. Un attaquant qui prend le contrôle du site cherche souvent l'accès aux sauvegardes pour les effacer ou les chiffrer avant de lancer son action. Une copie que le site compromis peut atteindre et modifier n'est pas une copie de secours. C'est la raison pour laquelle on parle aujourd'hui de sauvegarde immuable ou hors ligne.

La durée de conservation compte tout autant. Une compromission silencieuse, par exemple un code malveillant injecté il y a trois semaines, contamine les sauvegardes récentes. Il faut pouvoir remonter à une version saine, d'où l'intérêt d'une rétention étagée : quotidiennes sur sept jours, hebdomadaires sur un mois, mensuelles sur plusieurs mois. Ce dispositif se pilote dans le cadre d'un dispositif de sécurité de site web cohérent, et pas comme un réglage isolé.

Tester la restauration : le geste que presque personne ne programme

Un test de restauration consiste à reconstruire le site à partir de la sauvegarde sur un environnement distinct de la production, puis à vérifier qu'il fonctionne. C'est la seule preuve qu'une sauvegarde est exploitable, et elle devrait être planifiée au moins deux fois par an, et après tout changement d'hébergement ou de version de PHP.

La documentation officielle d'Akeeba décrit la procédure de restauration avec Kickstart. On copie le fichier kickstart.php à la racine de l'emplacement cible, on y dépose l'archive de sauvegarde (au format .jpa, .jps ou .zip) et, si elle est découpée en plusieurs parties, absolument toutes ses parties. L'extraction se lance ensuite depuis le navigateur, le mode « hybride » étant recommandé, puis le script de restauration intégré termine l'opération en reconstituant la base de données.

Deux points d'attention, soulignés par la documentation, expliquent à eux seuls nombre d'échecs. D'abord, le transfert par FTP doit se faire en mode binaire : l'archive et toutes ses parties transférées en mode texte sont corrompues, et l'erreur n'apparaît qu'à l'extraction. Ensuite, sur certains mutualisés sans suPHP, il faut créer un dossier temporaire dédié avec les bons droits ou basculer en mode FTP pour que l'extraction aboutisse. Ce sont des détails que l'on découvre en répétant l'exercice un mardi après-midi, pas en pleine crise.

Un bon test ne s'arrête pas à l'affichage de la page d'accueil. Il doit vérifier que les pages internes répondent, que les images apparaissent, que le formulaire de contact envoie réellement un message, que l'espace d'administration est accessible, que les URL réécrites fonctionnent, et pour une boutique que le parcours de commande va jusqu'à la confirmation en mode test. Il doit aussi mesurer la durée totale, du début de la restauration à la mise en ligne, car cette durée est votre RTO réel, à comparer à celui que vous visiez.

Chaque test mérite une trace écrite : date, personne, version restaurée, durée, anomalies rencontrées, correctifs apportés. Ce compte rendu transforme un savoir-faire individuel en procédure, et il rassure aussi vos assureurs, vos clients et, le cas échéant, vos auditeurs. Un audit de site web inclut utilement cette vérification, car il révèle en une fois les sauvegardes absentes, trop anciennes ou jamais éprouvées.

Quand le site tombe : les soixante premières minutes

Face à une panne, la priorité est de qualifier l'incident avant d'agir : panne d'hébergement, erreur de mise à jour, base saturée, certificat expiré, attaque ou compromission. Restaurer trop vite sur une compromission non traitée réinstalle la faille et fait perdre la preuve de ce qui s'est passé.

La première étape consiste à constater et à communiquer. Vérifier depuis un autre réseau que le site est bien inaccessible, regarder l'état de l'hébergeur, contrôler l'expiration du certificat HTTPS et du nom de domaine, consulter les journaux d'erreurs. Ces vérifications simples écartent une partie des fausses alertes, et prennent dix minutes quand on sait où regarder. En parallèle, prévenir en interne : le standard, le service commercial et la communication doivent savoir quoi répondre aux clients.

La deuxième étape est de préserver. Avant toute restauration, faire une copie de l'état actuel du serveur, même dégradé. Cette copie permettra d'analyser une éventuelle intrusion, de récupérer des données écrites après la dernière sauvegarde et, si nécessaire, de documenter l'incident pour votre assurance ou pour la CNIL en cas de violation de données personnelles. Dans un contexte d'attaque, on isole aussi le site : maintenance activée, accès restreint, changement des mots de passe et des clés après nettoyage.

La troisième étape est de choisir le point de restauration. Si la panne vient d'une mise à jour, on revient à la sauvegarde précédente. Si elle vient d'une compromission, on remonte à une version dont on est certain qu'elle précède l'intrusion, puis on applique les correctifs avant de remettre en ligne. Restaurer, c'est aussi décider de ce que l'on accepte de perdre, d'où l'importance du RPO défini plus haut.

La quatrième étape est la remise en ligne contrôlée, avec les mêmes vérifications que lors du test, puis une surveillance renforcée pendant quarante-huit heures. Un incident se clôt par un retour d'expérience : cause, durée, impact, mesures correctives. C'est le rôle d'un dépannage de site internet mené par une équipe qui connaît déjà votre site, car la première heure se joue sur la connaissance préalable de l'architecture, des accès et des habitudes de l'hébergeur.

Combien coûte la continuité d'un site : fourchettes de marché et critères de comparaison

En France, selon une étude tarifaire publiée en 2026 par l'agence Kolonell, une maintenance de site se situe entre 80 et 250 euros par mois pour un petit site vitrine avec sauvegardes hebdomadaires, entre 250 et 650 euros pour un site de dix à trente pages avec sauvegardes quotidiennes, et entre 650 et 2 500 euros pour un site critique avec sauvegardes très fréquentes et support d'urgence.

Ces fourchettes sont des repères de marché, pas des devis, et elles varient selon la complexité du site, le CMS, l'hébergement et le niveau de service. Elles montrent surtout une logique : la fréquence des sauvegardes, la rapidité d'intervention et les heures de modification incluses progressent avec le budget. Le premier niveau décrit dans cette étude prévoit des sauvegardes hebdomadaires et une réponse sous quarante-huit heures ouvrées, le deuxième des sauvegardes quotidiennes et une réponse sous vingt-quatre heures, le troisième des sauvegardes horaires ou en temps réel avec un engagement de quatre heures sur les incidents critiques.

Pour comparer des offres, ne vous arrêtez pas au prix mensuel. Cinq questions font apparaître les vraies différences. Où est stockée la copie, et chez qui ? Pendant combien de temps conserve-t-on les versions ? Un test de restauration est-il prévu, à quelle fréquence, avec quel compte rendu ? Quel est le délai de prise en charge contractuel d'un incident, et dans quelles plages horaires ? La restauration est-elle comprise dans le forfait, ou facturée à l'heure en cas de sinistre ?

Ce dernier point surprend souvent. Certaines offres incluent la création des sauvegardes mais facturent la restauration comme une prestation distincte, au tarif horaire, à un moment où vous n'avez aucun pouvoir de négociation. Le contrat doit le dire clairement. Il est de même utile de vérifier que les accès aux sauvegardes vous appartiennent : en cas de changement de prestataire, vous devez pouvoir récupérer vos archives sans dépendre de lui. C'est un des critères d'un bon contrat de maintenance web.

Il reste à rapprocher ces montants du coût d'une indisponibilité. Pour une entreprise dont le site génère des demandes de devis ou des commandes, quelques heures d'arrêt se chiffrent en prospects perdus, en confiance entamée et en temps interne mobilisé. Cette arithmétique, propre à chaque structure, justifie ou non le palier supérieur. Il n'existe pas de règle universelle, mais il existe une méthode : estimer le coût d'une journée d'arrêt, le comparer à la différence de prix entre deux niveaux de service, et décider en connaissance de cause.

Plusieurs sites, plusieurs hébergeurs : la continuité à l'échelle d'un parc

Dès qu'une organisation gère plusieurs sites, la continuité cesse d'être une affaire de technique pour devenir une affaire d'inventaire. Il faut savoir quels sites existent, quel CMS et quelle version de PHP chacun utilise, où ils sont hébergés, et lesquels disposent d'une sauvegarde testée.

C'est un cas fréquent chez les grands comptes, les groupes, les réseaux d'agences et les collectivités : un site institutionnel, des sites de marque, des micro-sites de campagne, un ancien portail oublié sur un serveur que personne ne surveille. Chacun a été créé à un moment différent, par un prestataire différent, avec des pratiques différentes. Le résultat est un parc hétérogène où l'on découvre, lors d'un incident, que tel site n'a jamais été sauvegardé ou que tel autre dépend d'un compte d'hébergement ouvert au nom d'un ancien salarié.

La démarche la plus efficace consiste à dresser un tableau simple, une ligne par site, avec huit colonnes : nom de domaine et propriétaire du compte registrar, CMS et version, version de PHP, hébergeur, fréquence et lieu de la sauvegarde, date du dernier test de restauration, RPO et RTO visés, contact d'urgence. Ce tableau, mis à jour à chaque changement, est l'outil le plus rentable de toute la gouvernance numérique. Il fait ressortir immédiatement les sites exposés : ceux qui tournent sur une version de PHP qui n'aura bientôt plus de correctifs, ceux sans copie hors site, ceux dont personne ne sait qui les administre.

Mutualiser les pratiques fait aussi baisser les coûts : une procédure de restauration commune, un même outil de sauvegarde pour tous les sites Joomla, un même stockage externalisé, un même calendrier de tests. C'est précisément l'objet d'une infogérance de parc digital, qui apporte à plusieurs sites un niveau de service homogène, plutôt que de laisser chaque site réinventer sa propre sécurité.

Un plan d'action en trente jours pour fiabiliser la reprise de votre site

Un mois suffit pour passer de sauvegardes supposées à une reprise démontrée : une semaine pour inventorier, une semaine pour corriger les écarts, une semaine pour tester, une semaine pour documenter. Le plan ci-dessous convient à un site isolé comme à un petit parc.

La première semaine est consacrée à l'état des lieux. Listez vos sites et leur hébergeur, retrouvez les accès au registrar et au DNS, identifiez où sont réellement stockées les sauvegardes, depuis quand elles existent, et combien de versions sont conservées. Demandez par écrit à votre prestataire et à votre hébergeur de confirmer fréquence, localisation et durée de conservation. Posez les questions de RPO et de RTO à votre direction et notez les réponses.

La deuxième semaine corrige les écarts les plus graves. Si aucune copie n'existe hors de l'hébergement, mettez-en une en place chez un second fournisseur, avec un accès distinct. Si la rétention est de trois jours, étendez-la. Si l'outil de sauvegarde est configuré mais inactif depuis une mise à jour, réparez-le. Vérifiez enfin que le serveur de production tourne sur une version de PHP encore supportée, en tenant compte de l'échéance du 31 décembre 2026 pour PHP 8.2.

La troisième semaine est celle du test. Restaurez la dernière sauvegarde sur un environnement de recette, chronométrez, vérifiez les fonctions critiques, notez tout ce qui s'est mal passé. Faites participer au moins une personne qui n'a pas fait la sauvegarde, car c'est elle qui révèlera les étapes implicites.

La quatrième semaine documente. Rédigez une procédure d'une à deux pages : qui prévenir, où sont les accès, quelle sauvegarde choisir, dans quel ordre restaurer, comment vérifier. Rangez-la à un endroit accessible même si votre messagerie ou votre site sont en panne. Planifiez le prochain test dans six mois. Pour faire cet exercice avec un regard extérieur, un audit de site web pose un diagnostic chiffré et priorisé en quelques jours.

Questions fréquentes sur la sauvegarde et la reprise d'un site web

À quelle fréquence faut-il sauvegarder un site web ?

La fréquence dépend de la vitesse à laquelle votre contenu change. Un site vitrine mis à jour chaque semaine peut se contenter d'une sauvegarde quotidienne, tandis qu'une boutique en ligne qui enregistre des commandes en continu doit viser plusieurs copies par jour. Fixez-la à partir de la perte de données que vous acceptez, c'est-à-dire votre RPO, et conservez plusieurs générations de versions.

Les sauvegardes de mon hébergeur suffisent-elles ?

Non, elles protègent des erreurs courantes mais pas d'un sinistre sur l'infrastructure ni d'une compromission de votre compte d'hébergement. L'affaire de l'incendie d'OVHcloud à Strasbourg, jugée à Lille le 26 janvier 2023, a montré qu'une copie stockée dans le même bâtiment que la production disparaît avec elle. Ajoutez toujours une copie hors site, chez un autre fournisseur.

Comment savoir si ma sauvegarde est exploitable ?

Une seule méthode le prouve : la restaurer sur un environnement de test, puis contrôler les pages, les médias, les formulaires et l'accès à l'administration. Planifiez ce test au moins deux fois par an et après chaque changement d'hébergement ou de version de PHP. Chronométrez-le pour connaître votre délai réel de remise en ligne.

Que faire si mon site WordPress ou Joomla est piraté ?

Commencez par préserver une copie de l'état actuel, isoler le site et changer les accès, puis restaurez une version antérieure à l'intrusion et appliquez les mises à jour de sécurité avant la remise en ligne. Restaurer sans corriger la faille la réintroduit. Si des données personnelles sont concernées, une notification à la CNIL peut être nécessaire.

Qui doit conserver les accès aux sauvegardes ?

Vous, en tant que propriétaire du site, même si votre prestataire les gère au quotidien. Le contrat doit prévoir que vous pouvez récupérer vos archives, vos accès hébergeur et votre nom de domaine à tout moment, notamment en cas de changement d'agence. C'est une condition de réversibilité, qui évite de dépendre d'un seul acteur.

Faire vérifier votre dispositif de reprise avant le prochain incident

Depuis 2005, Pulsar Agency assure l'infogérance, la maintenance et la TMA de sites existants, depuis Luzarches en Île-de-France et Lamorlaye dans les Hauts-de-France. Si vous voulez savoir si vos sauvegardes se restaurent vraiment, où elles sont stockées et en combien de temps votre site reviendrait en ligne, commencez par un audit de votre site web : vous repartirez avec un état des lieux clair, des priorités et un plan d'action réaliste. Pour un site déjà en panne, le dépannage de site internet est le point d'entrée le plus rapide.