Votre site est hors ligne : combien de temps pouvez-vous le rester ?

Mardi, neuf heures. Un client vous envoie une capture d'écran : à la place de votre site, une page presque vide et une ligne de texte que personne autour de vous ne comprend. Vous appelez la personne qui s'en occupe habituellement. Elle ne répond pas. Et vous vous apercevez, en trente secondes, que vous ignorez trois choses : chez qui votre site est hébergé, où se trouve la dernière copie, et qui a le droit de la remettre en place.

La panne, elle, se réparera. Retrouver qui détient quoi est un autre travail, et il commence au pire moment.

Ce qui suit ne demande pas de budget, mais de la méthode. Les premiers éléments se réunissent en une soirée ; le reste se construit ensuite, à froid. Rien, en revanche, ne se prépare pendant la panne.

Une précision avant d'entrer dans le sujet : l'essentiel ne porte pas sur la fréquence des copies. Il porte sur deux questions qui commandent tout le reste, et qui se tranchent avant la panne, jamais pendant.

Deux questions décident de tout, et aucune des deux n'est technique

Première question : combien de temps votre activité tient-elle sans votre site ?

Deuxième question : quelle quantité de travail acceptez-vous de refaire à la main ?

Prenez le temps de répondre, en heures. Ces deux durées portent des noms dans les documents de référence sur la continuité d'activité, et ces noms reviendront un jour dans une proposition qu'on vous soumettra. Le guide de planification de continuité publié par l'institut américain de normalisation et de technologie, le NIST, définit la première comme la durée maximale pendant laquelle une ressource peut rester indisponible avant que l'impact devienne inacceptable ; les prestataires l'appellent l'objectif de temps de rétablissement. La seconde désigne le point du passé auquel vos données peuvent être ramenées, compte tenu de la dernière copie disponible : l'objectif de point de reprise. Retenez surtout la forme que doit prendre votre réponse. Une durée, en heures. Pas une intention.

Traduisez maintenant dans votre métier.

Si votre site est une carte de visite qui présente votre entreprise, vous survivez sans doute à une journée d'absence, et refaire une demi-journée de modifications de contenu ne vous coûtera qu'un agacement. Si votre site prend des réservations, encaisse des acomptes ou enregistre des demandes de devis, la réponse n'est plus la même : chaque heure d'indisponibilité vous coûte des demandes que vous ne verrez jamais, et perdre les enregistrements de la journée signifie appeler des clients pour leur demander de recommencer.

Ce sont deux plans différents. Pas deux versions du même plan.

Écrivez vos deux durées sur une feuille. Tant qu'elles n'existent pas, aucune discussion sur les sauvegardes ne peut aboutir : personne ne sait à quoi il compare. Une fois qu'elles existent, tout le reste se déduit — la fréquence des copies, l'endroit où elles vivent, et le nombre de personnes capables de les remettre en service.

Ce que votre hébergeur sauvegarde ne couvre pas ce que vous imaginez

Vient alors l'objection : mon hébergeur sauvegarde.

C'est vrai, et cela ne veut pas dire ce que vous croyez. Regardons ce que trois acteurs très différents écrivent explicitement dans leur propre documentation.

Chez OVHcloud, une formule d'hébergement où votre site partage une machine avec d'autres donne accès à cinq points de restauration seulement, dont le plus ancien remonte à deux semaines. La documentation ajoute deux réserves décisives. Aucune période antérieure ne peut vous être fournie. Et ces sauvegardes sont explicitement présentées comme non contractuelles, avec la recommandation d'effectuer régulièrement les vôtres. Autre limite, moins visible : cette restauration porte sur les fichiers. La base de données, où sont enregistrés vos commandes, vos comptes clients et vos formulaires, s'exporte séparément.

Chez Squarespace, une page ou un article supprimé se récupère pendant trente jours. En revanche, la documentation nomme des contenus qui ne se restaurent pas du tout : les produits, les événements et les images de galerie en font partie. Le code ajouté à la main sur le site, par vous ou par votre prestataire, n'est pas récupérable non plus.

Du côté de WordPress, la documentation officielle est plus explicite encore sur le point décisif : une sauvegarde complète, ce sont les fichiers et la base de données. Deux choses distinctes, à deux endroits distincts.

Retenez la logique commune. La sauvegarde de votre hébergeur existe d'abord pour ses incidents à lui. Elle est calibrée sur ses besoins, pas sur les deux durées que vous venez d'écrire. Et une copie qui vit sur la même machine que votre site ne vous protège ni de la perte de cette machine, ni d'une suspension de votre compte pour une facture impayée.

Le geste, ce soir : ouvrez la page de documentation de votre hébergeur consacrée aux sauvegardes, et notez trois lignes. Ce qui est couvert. Jusqu'à quelle date on peut remonter. Qui peut déclencher la restauration.

Quatre éléments ne figurent dans aucune sauvegarde de site

Voici le point aveugle. Même une sauvegarde parfaite de votre site laisse dehors quatre éléments dont l'absence produit exactement le même symptôme pour votre client : une entreprise injoignable.

Votre nom de domaine. C'est l'adresse que l'on tape, et elle ne vous appartient pas : elle vous est confiée pour une durée déterminée. L'Afnic, qui gère les adresses en .fr, l'écrit explicitement : sans nouvelle de votre part au moment de l'échéance, votre prestataire d'enregistrement demande la suppression du nom. Une période de rachat de trente jours suit, pendant laquelle vous pouvez encore revenir en arrière, et au terme de laquelle le nom retourne au public. Chaque extension applique ses propres délais : vérifiez ceux de la vôtre auprès de votre prestataire. Le corollaire, lui, ne change pas — l'adresse e-mail associée à ce contrat doit être une adresse que quelqu'un lit réellement.

Vos boîtes mail. Elles ne dépendent pas de votre hébergeur de site, mais de votre fournisseur de messagerie, et leurs règles sont les siennes. Google indique par exemple qu'un compte utilisateur supprimé se restaure pendant vingt jours ; passé ce délai, les données ne sont plus récupérables. Vingt jours, c'est court quand un salarié part en litige et que personne ne pense à récupérer sa boîte.

Le certificat qui rend votre adresse sûre aux yeux du navigateur. Ce fichier prouve que l'adresse consultée est bien la vôtre ; c'est lui qui fait apparaître le cadenas. Les certificats délivrés par Let's Encrypt, une autorité de certification gratuite, sont valables quatre-vingt-dix jours et se renouvellent automatiquement avant l'échéance. Le jour où ce renouvellement s'interrompt sans que personne ne le remarque, votre site est intact — et le navigateur affiche à vos visiteurs un avertissement de sécurité pleine page.

Tout ce qui vit chez des tiers. Votre moteur de réservation, votre outil de formulaires, votre fiche Google, votre outil de facturation. Chacun a ses propres règles de conservation, ses propres accès, et son propre bouton d'export — quand il en a un.

CE QUI PEUT TOMBER · OÙ CELA VIT RÉELLEMENT · CE QUE LA SAUVEGARDE DU SITE EN CONTIENT · CE QUE VOUS VÉRIFIEZ CE SOIR

Ce qui peut tomber	Où cela vit réellement	Ce que la sauvegarde du site en contient	Ce que vous vérifiez ce soir
Pages, textes, images	Chez l'hébergeur ou l'éditeur du site	L'essentiel, mais avec des exclusions écrites dans sa documentation	Jusqu'à quelle date remonte la copie la plus ancienne
Base de données : commandes, comptes, demandes	Sur un serveur de base de données, souvent distinct des fichiers	Pas systématiquement	Qu'un export de base figure bien dans votre copie
Nom de domaine	Chez le prestataire d'enregistrement	Rien	La date d'échéance et l'adresse e-mail de contact
Boîtes mail	Chez le fournisseur de messagerie	Rien	Qui est administrateur, et qui l'est en second
Certificat de sécurité	Renouvelé automatiquement sur le serveur	Rien	La date d'expiration : cliquez sur l'icône placée à gauche de l'adresse, puis sur « Connexion sécurisée », puis sur le certificat
Réservations, avis, demandes dans les outils tiers	Chez chaque éditeur	Rien	Si un export existe, et qui sait le déclencher
Les accès eux-mêmes	Dans une tête, un carnet ou un téléphone	Rien	Qu'ils existent ailleurs que dans une seule tête

Une sauvegarde jamais restaurée n'est qu'une hypothèse

Vous pouvez avoir une copie quotidienne, correctement stockée, et découvrir le jour de l'incident qu'elle ne se remet pas en service. Le fichier existe, il n'est simplement pas exploitable, ou il lui manque la moitié.

La seule façon de le savoir consiste à faire une fois, à froid, ce que vous feriez dans l'urgence : reprendre la copie et la remettre en service ailleurs que sur le site que vos clients consultent, pour vérifier qu'elle fonctionne réellement. Cette manœuvre porte un nom, la restauration test, et elle change la nature de votre sauvegarde : elle cesse d'être une intention pour devenir une capacité.

Trois précautions.

Ne restaurez jamais par-dessus votre site en fonctionnement. Utilisez un espace séparé : une adresse de test qui ne sert qu'à cela, ou un hébergement provisoire ouvert pour l'occasion. Si vous ne savez pas en créer un, c'est précisément la demande à adresser à votre prestataire, et elle est légitime.

Chronométrez. Notez l'heure de départ et l'heure à laquelle le site restauré affiche une page correcte. Nous ne pouvons pas vous dire combien de temps cela devrait prendre : cela dépend de votre site, de votre hébergeur et de la personne qui opère. Ce qui compte, c'est que ce soit votre chiffre, mesuré une fois, et non une estimation.

Notez ce qui a manqué. Un mot de passe que personne ne détenait. Une base de données absente de la copie. Des images stockées ailleurs. Une manipulation que seul votre prestataire pouvait faire, et sous conditions. Cette liste vaut à elle seule l'exercice.

Comparez ensuite votre chiffre à la première durée que vous aviez écrite. S'il est plus long, vous savez quoi changer, et l'arbitrage devient concret au lieu d'être théorique.

Refaites l'exercice une fois par an, et après chaque changement de prestataire, d'hébergeur ou de version majeure.

La panne la plus coûteuse est humaine, et elle se règle avec un document

Une panne technique se répare. Une panne d'accès attend que quelqu'un se réveille, rentre de vacances, ou réponde à un courrier recommandé.

Constituez un document — un seul — qui recense huit lignes.

Le prestataire chez qui votre nom de domaine est enregistré. L'hébergeur ou l'éditeur de votre site. L'endroit où se règlent les paramètres techniques du nom, c'est-à-dire la table qui indique quel serveur répond pour votre adresse. L'administration du site. La messagerie professionnelle. L'outil de paiement ou de réservation. La mesure d'audience. Et l'endroit où vit le code, si votre site a été développé sur mesure.

Pour chacune de ces huit lignes, quatre informations : le nom du prestataire, l'adresse e-mail qui sert d'identifiant au compte, la personne qui détient l'accès aujourd'hui, et la personne qui l'obtiendrait si la première était injoignable demain.

Cette dernière colonne est la plus facile à laisser vide, et c'est la seule qui vous servira le jour venu.

Deux points méritent une attention particulière.

Le code reçu sur un seul téléphone. De nombreux comptes réclament, après le mot de passe, un code envoyé par message : c'est ce qu'on appelle la double authentification. Lorsque ce code n'arrive que sur un appareil, cet appareil devient un point de rupture. Perdu ou remplacé, il verrouille le compte pour tous. Les services sérieux fournissent, au moment de l'activation, une liste de codes de secours à usage unique : conservez-la ailleurs que dans le téléphone.

Le nom enregistré au nom d'un autre. Il arrive qu'un nom de domaine ait été enregistré par un prestataire, sur son propre compte, avec ses propres coordonnées. Cela ne se découvre qu'au moment où il faut agir. Vérifiez ce que dit votre contrat sur la titularité du nom et sur les conditions de restitution des accès. Si le point n'y figure pas, faites-le préciser par écrit lors du prochain avenant. Nous ne trancherons pas ici ce qui relève du droit applicable : sur ce terrain, adressez-vous à un professionnel du droit, en lui remettant vos contrats.

Rangez ce document dans un gestionnaire de mots de passe muni d'un contact d'urgence, ou sur un papier dans un coffre. Pas dans une pièce jointe d'e-mail, qui est justement l'un des accès susceptibles de tomber.

Toutes les pannes ne se ressemblent pas, et le premier geste change

Avant d'appeler qui que ce soit, une question de tri : est-ce le site, le nom, ou la messagerie ? Elle se tranche en deux minutes en envoyant un message à votre propre adresse depuis une autre boîte. Si ce message part et arrive, votre nom fonctionne, et le problème est ailleurs.

Une page d'erreur s'affiche à la place du site. L'incident est du côté de l'hébergement ou de l'application. Deux vérifications avant tout appel : la page d'état de votre hébergeur, qui signale les incidents en cours, et l'état de vos règlements.

Le navigateur affiche un avertissement de sécurité. Votre site est intact. C'est le certificat qui a expiré, parce que le renouvellement automatique s'est interrompu. La correction est rapide pour qui a les accès au serveur.

Rien ne répond, et vos e-mails ne partent plus non plus. Le problème porte sur le nom lui-même : échéance dépassée, ou paramètres techniques modifiés. Site et messagerie dépendent du même nom, c'est pourquoi ils tombent ensemble.

Le site répond, mais son contenu a changé, ou il redirige ailleurs. Modification malencontreuse, ou intrusion. Réflexe contre-intuitif mais essentiel : conservez une copie de l'état actuel avant de restaurer quoi que ce soit, et changez les mots de passe avant de remettre la version saine en ligne. Sinon, le site redevient propre, et la porte par laquelle on est entré reste ouverte.

Il existe une cinquième panne, la plus discrète : le site fonctionne, mais les demandes n'arrivent plus. Un formulaire cassé ne produit aucune alerte. Envoyez-vous une demande test le premier de chaque mois.

Ce qui ne marche pas

Stocker la copie au même endroit que le site. Une sauvegarde qui vit sur le serveur du site disparaît avec lui, et disparaît aussi lorsque le compte est suspendu.

Considérer qu'une sauvegarde existe parce qu'un outil affiche une coche verte. Tant qu'elle n'a pas été remise en service une fois, vous avez une intention, pas une capacité.

Laisser un seul détenteur des accès. Y compris vous-même. Surtout vous-même.

Confondre l'engagement de disponibilité de votre hébergeur avec un plan de reprise. Le premier concerne ses machines. Le second concerne votre activité, et il n'existe que si vous l'écrivez.

Questions fréquentes

À quelle fréquence faut-il sauvegarder ?

La question se déduit de la deuxième durée que vous avez écrite. Si perdre une semaine de modifications ne vous coûte rien, une copie hebdomadaire suffit. Si perdre les demandes d'une journée vous oblige à rappeler des clients, il vous faut une copie quotidienne au minimum, et un export séparé de la base de données.

Mon site est chez un éditeur en ligne. Suis-je dispensé ?

Non, vous êtes exposé différemment. L'infrastructure est prise en charge, mais la documentation de ces éditeurs délimite précisément ce qui se récupère et ce qui ne se récupère pas — chez Squarespace, une page supprimée revient pendant trente jours, un produit ou une image de galerie ne revient pas. Et vos données commerciales restent votre affaire : identifiez le bouton d'export et servez-vous-en périodiquement.

Mon prestataire dit qu'il sauvegarde. Cela suffit-il ?

Cela devient suffisant lorsque vous pouvez répondre à quatre questions : que contient la copie, où est-elle stockée, en combien de temps la remet-il en service, et comment y accédez-vous si votre relation prend fin. Demandez ces quatre réponses par écrit, puis faites l'exercice de restauration avec lui une fois.

Le nom de domaine est enregistré au nom de mon ancien prestataire. Que faire ?

Commencez par établir les faits : quel prestataire d'enregistrement gère le nom, quelle date d'échéance, quelle adresse de contact. Reprenez ensuite le contrat qui vous liait. Les modalités de transfert appartiennent à ce contrat et aux règles du prestataire d'enregistrement concerné. Pour la suite, faites-vous accompagner par un professionnel du droit plutôt que d'improviser.

Combien de copies conserver, et à quels endroits ?

La documentation de WordPress recommande trois à cinq copies récentes réparties à des emplacements différents. Le principe vaut au-delà de cet outil : une copie chez l'hébergeur, une copie dans un espace de stockage en ligne distinct, une copie hors ligne.

Faut-il prévenir ses clients pendant une panne ?

Oui, et cela se prépare aussi. Une page d'information hébergée ailleurs que sur votre site, un message court sur vos réseaux, une réponse automatique sur la messagerie si elle fonctionne encore. Le silence laisse chacun libre d'imaginer le pire ; deux lignes referment la question.

Pour aller plus loin

• Ce que recouvre un agent « formé sur vos données » — la base de documents qu'il relit à chaque question est un actif de plus à porter dans votre inventaire de sauvegarde.

• Ce que vérifie un destinataire avant de vous répondre — la même exigence vue de l'extérieur : ce que trouve quelqu'un qui tape votre nom pendant que votre site est indisponible.

• Les huit décisions d'un lancement, et les trois qui ne se défont pas — le nom de domaine et l'hébergement se tranchent au démarrage, et c'est là que se joue votre capacité à reprendre la main.

Ce soir, vingt minutes

Trois gestes, dans cet ordre.

Connectez-vous au compte qui gère votre nom de domaine, et ouvrez la fiche du nom : la date d'échéance y figure, et l'adresse e-mail de contact se trouve dans la rubrique des contacts, parfois nommée « titulaire » ou « propriétaire ». Si vous ne parvenez pas à vous connecter, vous venez de trouver votre première faille, et elle est plus urgente que toutes les autres. Si vous ignorez chez qui le nom est enregistré, votre dernière facture de renouvellement porte le nom du prestataire.

Ouvrez la page de documentation de votre hébergeur consacrée aux sauvegardes, et notez jusqu'à quelle date vous pouvez remonter.

Ouvrez une note vide, reportez les huit lignes énumérées plus haut, et remplissez d'abord la dernière colonne : qui obtient l'accès si la personne qui le détient est injoignable demain.

Vous n'aurez pas de plan de reprise complet ce soir. Vous aurez sous la main les trois informations qu'il faudrait chercher en pleine panne.

Sources

Les règles et les durées citées ici sont celles publiées par les éditeurs et organismes concernés. Elles ont été reformulées, non recopiées, et ces documents évoluent : ce qui suit vaut à la date de consultation et se revérifie à la source.

• NIST, *Contingency Planning Guide for Federal Information Systems*, Special Publication 800-34 Rev. 1, mai 2010, mise à jour de novembre 2010 — chapitre 3 et annexe B, définitions de la durée maximale d'interruption tolérable, de l'objectif de temps de rétablissement et de l'objectif de point de reprise. Consulté le 11 août 2026.

• OVHcloud, Documentation, « Restaurer l'espace de stockage de son hébergement web », docs.ovhcloud.com/en/guides/web-cloud/web-hosting/ftp-save-and-backup — points de restauration disponibles, périmètre limité aux fichiers, caractère non contractuel des sauvegardes. Consulté le 11 août 2026.

• Squarespace Help Center, « Restoring deleted pages and blog posts », support.squarespace.com/hc/en-us/articles/205826038 — délai de trente jours et liste des contenus non restaurables. Consulté le 11 août 2026.

• WordPress, documentation d'administration avancée, « Backing Up Your WordPress Site », developer.wordpress.org/advanced-administration/security/backup/ — composition d'une sauvegarde complète, nombre et emplacement des copies. Consulté le 11 août 2026.

• Afnic, « Pensez à renouveler votre nom de domaine », afnic.fr — responsabilité du renouvellement, demande de suppression en l'absence de réponse, période de rachat de trente jours, coordonnées de contact à jour. Consulté le 11 août 2026.

• Google Workspace, Aide administrateur, « Restaurer un utilisateur récemment supprimé » — délai de vingt jours au-delà duquel les données ne sont plus restaurables. Consulté le 11 août 2026.

• Let's Encrypt, FAQ officielle, letsencrypt.org/docs/faq — durée de validité de quatre-vingt-dix jours, renouvellement automatique avant l'échéance. Consulté le 11 août 2026.

INSEN STUDIO

On regarde votre situation ensemble ?

Vous repartez avec une lecture claire, avec ou sans nous.

Demander un audit digital ↗