Quand le site tombe, la première question n'est pas technique
Un mardi matin, 8h10. Le téléphone sonne : « Notre site ne s'affiche plus. » Le dirigeant appelle son agence web, qui répond que le problème vient de l'hébergeur. L'hébergeur, lui, indique que l'infrastructure fonctionne parfaitement et renvoie vers « le prestataire applicatif ». Trois heures plus tard, le site est toujours hors ligne et personne n'a encore restauré quoi que ce soit. On a juste échangé des mails.
Ce scénario n'a rien d'exceptionnel. Il est même la norme.
Parce qu'un site web en production n'appartient jamais à un seul intervenant. Il repose sur une chaîne de maillons qui se connaissent mal, se parlent rarement, et dont aucun n'a signé pour la remise en ligne complète. Chacun restaure son périmètre. Le reste flotte.
La vraie question, celle qui devrait être tranchée bien avant l'incident, tient en une phrase : qui est contractuellement responsable de remettre votre site en ligne, dans quel délai, et à partir de quelles sauvegardes ? La réponse, dans la majorité des dossiers, n'est écrite nulle part.
Ce texte propose d'y voir clair. Identifier le responsable réel de la reprise, mesurer le délai que l'on subit vraiment, corriger les contrats avant qu'ils ne servent d'alibi, et traiter le volet SEO que personne ne regarde pendant la crise. Un site remis en ligne mais désindexé n'est pas un site sauvé.
Cartographier la chaîne avant que l'incident n'arrive
Cinq maillons, cinq périmètres qui ne se recouvrent pas
Avant de savoir qui remonte le site, il faut savoir qui détient quoi. Cette cartographie prend deux heures. Elle en fait gagner vingt le jour du sinistre.
Le registrar
Il détient le nom de domaine et, très souvent, la zone DNS. C'est lui qui décide vers quelle adresse IP pointe votre site. Si vous devez basculer vers un serveur de secours, tout passe par là. Et si personne dans l'entreprise n'a les accès au registrar, la bascule est impossible, même avec une sauvegarde parfaite sous le bras.
L'hébergeur
Serveur, réseau, alimentation électrique, stockage. Il garantit que la machine tourne. Il ne garantit pas que votre site fonctionne dessus. La nuance paraît subtile, elle est en réalité le cœur de la plupart des malentendus contractuels.
L'infogéreur ou le prestataire d'exploitation
Système d'exploitation, correctifs de sécurité, supervision, sauvegardes, parfois pare-feu applicatif. C'est le maillon le plus souvent absent chez les TPE et PME : personne ne l'occupe, et tout le monde suppose que l'hébergeur s'en charge. Il ne s'en charge pas.
L'agence ou le développeur
Le code applicatif, le thème, les extensions, les développements spécifiques. Il connaît le site fonctionnellement. Il n'a pas forcément la main sur le serveur, ni les accès pour restaurer une sauvegarde d'infrastructure.
Les services tiers
CDN, messagerie transactionnelle, module de paiement, CRM, connecteur comptable, outil de réservation. Chacun a ses propres clés d'API, ses propres webhooks, sa propre configuration. Rien de tout cela ne se trouve dans une sauvegarde de base de données. Et quand le site revient, ces connexions restent souvent muettes pendant des jours avant que quelqu'un ne s'en aperçoive.
Pourquoi ce découpage décide de tout le reste
Chaque intervenant restaure ce qu'il détient. Uniquement ce qu'il détient. L'hébergeur remet le serveur debout, l'agence redéploie le code, le prestataire système réinstalle les correctifs. Personne ne vérifie que l'ensemble refonctionne bout en bout, parce que ce contrôle-là n'appartient à aucun d'entre eux.
C'est là que le temps se perd. Pas dans la restauration technique, qui prend souvent moins d'une heure, mais dans la coordination entre des acteurs qui attendent chacun que l'autre finisse.
L'exercice à faire dès cette semaine
Un tableau, cinq colonnes, une page. Pour chaque maillon : qui est-ce, quel est le contact direct (nom, téléphone, pas une adresse générique), quel périmètre il couvre, quel délai il s'engage à tenir, et qui détient les accès. Imprimez-le. Oui, sur papier. Le jour où l'intranet est chiffré et la messagerie inaccessible, le fichier PDF stocké sur le serveur compromis ne vous sera d'aucun secours.
Ransomware et panne d'hébergeur : deux sinistres, deux réponses
On les confond souvent parce que le symptôme est identique : le site ne répond plus. Mais l'un se subit, l'autre se combat. Et les traiter de la même façon, c'est prendre le risque d'aggraver le second.
La panne d'hébergeur : indisponible, mais sain
Les cas classiques
Incendie de datacenter, panne matérielle sur une baie de stockage, saturation réseau, erreur humaine lors d'une opération de maintenance. L'infrastructure tombe. Vos données ne sont ni volées ni altérées, elles sont simplement inaccessibles.
Ce que l'hébergeur restaure, et ce qu'il ne restaurera jamais
Il restaure sa propre infrastructure : le serveur, le réseau, éventuellement une image système de sa configuration. Il ne restaure pas votre base de données à un point précis dans le temps, ne vérifie pas que votre module de paiement refonctionne, et ne prend aucun engagement sur la cohérence de vos fichiers médias. Sur du mutualisé, les sauvegardes proposées sont souvent qualifiées de « courtoisie » dans les conditions générales. Le mot est important : une courtoisie ne s'exige pas.
Le délai n'est pas négociable
C'est le point le plus dur à accepter. Pendant une panne d'hébergeur, vous ne pilotez rien. Vous rafraîchissez une page de statut. Les grands incidents de datacenter des dernières années l'ont montré : certains clients ont attendu des semaines, et ceux qui sont revenus vite sont ceux qui disposaient d'une sauvegarde externe et d'un plan de bascule chez un autre opérateur. Les autres ont attendu.
Le ransomware : indisponible et corrompu
Ce que fait réellement l'attaque
Les fichiers sont chiffrés, la base est parfois altérée, et surtout des accès persistants sont installés : comptes administrateurs créés discrètement, tâches planifiées, portes dérobées dans le code applicatif. Le chiffrement est la partie visible. Le reste est conçu pour survivre à votre réaction.
Pourquoi restaurer vite peut tout rejouer
Voilà le piège qui coûte le plus cher. On restaure la sauvegarde de la veille, le site remonte, tout le monde souffle. Sauf que la compromission datait de trois semaines et que la sauvegarde de la veille contient la porte dérobée. Quinze jours plus tard, rechiffrement. On repart pour un tour, avec cette fois moins de sauvegardes propres disponibles.
Une restauration après compromission commence par une question désagréable : à quelle date le site était-il encore sain ? Sans journaux d'accès conservés, personne ne sait y répondre.
Le déclencheur juridique
Si des données personnelles sont concernées, et elles le sont presque toujours dès qu'il y a des comptes clients ou un formulaire de contact, une notification à la CNIL doit intervenir sous 72 heures après la prise de connaissance de la violation. Ce délai court pendant que vos équipes tentent de remonter le site. Il ne se suspend pas parce que la crise technique n'est pas terminée.
Préserver avant de manipuler
Si un dépôt de plainte ou une déclaration à l'assurance cyber est envisagé, et il devrait l'être, il faut figer l'état du système avant toute intervention. Un instantané du disque, une copie des journaux, un horodatage. Reformater le serveur en urgence détruit les preuves. Beaucoup de dossiers d'assurance se règlent mal pour cette seule raison.
Le cas intermédiaire, le plus courant en réalité
Le site répond. Il s'affiche normalement. Mais des pages de spam ont été injectées par centaines, des redirections envoient une partie du trafic vers des sites tiers, et Google commence à afficher un avertissement dans les résultats. Techniquement, il n'y a pas de panne. Commercialement, c'est parfois pire qu'une coupure franche : la coupure se voit et se répare, la compromission silencieuse s'installe et détruit la visibilité pendant des mois.
Comparaison des deux scénarios
| Critère | Panne d'hébergeur | Ransomware / compromission |
|---|---|---|
| Origine | Matérielle, réseau, humaine côté opérateur | Intrusion, souvent via une extension ou un accès faible |
| Périmètre | Infrastructure | Fichiers, base, comptes, parfois postes internes |
| Données | Intactes mais inaccessibles | Chiffrées, altérées ou exfiltrées |
| Responsable naturel | Hébergeur | Personne, sauf contrat d'infogérance explicite |
| Première action | Attendre, préparer une bascule | Isoler, couper, préserver les preuves |
| Restauration | Sur l'existant | Sur un environnement neuf, jamais sur l'existant |
| Obligation légale | Aucune en général | Notification CNIL sous 72 h si données personnelles |
| Durée réaliste | Quelques heures à plusieurs semaines | 3 à 15 jours, plus le nettoyage SEO |
Les sauvegardes, ou l'endroit précis où les dossiers se cassent
La confusion qui fonde presque toutes les mauvaises surprises
Une sauvegarde d'infrastructure et une sauvegarde applicative ne servent pas la même chose. Et pourtant, dans neuf entretiens sur dix, le dirigeant croit être couvert parce qu'il a coché une option « sauvegarde » sur son offre d'hébergement.
L'instantané serveur
L'hébergeur photographie l'état de la machine à un instant donné. C'est fait pour son exploitation à lui : reconstruire un serveur défaillant, revenir en arrière après une opération de maintenance. Rétention courte, souvent sept jours, parfois moins. Et il n'existe aucune garantie de cohérence entre les fichiers et la base au moment de la photo, si celle-ci a été prise pendant une écriture.
La sauvegarde applicative
Elle vise votre site, pas la machine. Fichiers, base de données, médias, fichiers de configuration. Surtout, elle garantit la cohérence entre la base et les fichiers : une base qui référence des images absentes du dossier restauré, ça donne un catalogue produit à trous, et on ne s'en rend compte qu'après la remise en ligne.
Quatre questions, et les réponses qui doivent vous alerter
Quelle fréquence ?
Une sauvegarde quotidienne signifie qu'en cas d'incident à 18 h, vous perdez la journée entière. Pour un site vitrine, personne ne s'en apercevra. Pour une boutique qui encaisse quarante commandes par jour, c'est une journée de chiffre d'affaires à reconstituer à la main depuis les mails de confirmation. Si tant est qu'ils existent encore.
Quelle profondeur ?
Sept jours de rétention suffisent pour une erreur de manipulation. C'est très insuffisant contre un ransomware, où le délai entre l'intrusion initiale et le déclenchement du chiffrement se compte fréquemment en semaines. Une profondeur de trente jours minimum, avec des points mensuels conservés plus longtemps, change complètement la donne.
Où sont-elles stockées ?
La question qui fait le plus de dégâts. Si les sauvegardes se trouvent sur le même serveur, ou sur un espace monté et accessible depuis ce serveur, un rançongiciel les chiffre en même temps que le reste. Il est même conçu pour ça : chercher les sauvegardes et les détruire en priorité.
Quand la dernière restauration a-t-elle été testée ?
Si la réponse est un silence gêné, ou « elles tournent tous les jours », vous n'avez pas de sauvegarde. Vous avez un processus qui produit des fichiers dont personne n'a jamais vérifié qu'ils étaient exploitables. Une sauvegarde non testée est une hypothèse, pas une garantie.
La règle 3-2-1, et sa version durcie
Trois copies des données. Sur deux supports différents. Dont une hors site. C'est le socle, et il tient en une ligne.
Face au chiffrement, il faut ajouter un étage : au moins une copie immuable ou déconnectée. Immuable signifie qu'elle ne peut être ni modifiée ni supprimée pendant une durée définie, y compris par un administrateur disposant de tous les droits. C'est précisément ce qui la protège d'un attaquant ayant volé ces mêmes droits.
Trois pièges silencieux
La sauvegarde locale
Le dossier /backup à la racine du site. Pratique, rapide, et anéanti en même temps que le reste. Il arrive même qu'il soit accessible publiquement, offrant à l'attaquant une copie complète de votre base et de vos identifiants.
La sauvegarde qui tourne dans le vide
Le script s'exécute chaque nuit, mais l'espace de destination est plein depuis quatre mois. Aucune alerte n'a été configurée. Personne n'a regardé. Le jour de l'incident, la sauvegarde la plus récente date de l'hiver dernier.
La sauvegarde valide mais inutilisable
Elle existe, elle est complète, elle est saine. Mais elle est chiffrée avec une clé que seul l'ancien prestataire détient, ou stockée sur un compte dont le mot de passe est parti avec un salarié. Techniquement, elle est parfaite. Concrètement, elle ne vaut rien.
Ce qu'aucune sauvegarde ne contient
Et pourtant, sans ces éléments, vous ne remettez rien en ligne : les accès au registrar, les certificats TLS et leurs clés privées, les clés d'API des services tiers, la configuration DNS complète, les identifiants des comptes de messagerie transactionnelle, les webhooks du prestataire de paiement, les accès à Search Console et aux outils de mesure.
Tout cela se documente à part, dans un gestionnaire de mots de passe d'entreprise, avec un export chiffré conservé hors ligne. Ce n'est pas de la paranoïa, c'est la différence entre quatre heures et quatre jours de reprise.
Le plan de reprise : le sortir du tiroir et le rendre utilisable
PRA, PCA : la distinction en une phrase
Le plan de continuité vise à ne jamais s'arrêter. Le plan de reprise vise à repartir vite après un arrêt. Le premier coûte cher et se justifie quand chaque heure d'indisponibilité se chiffre en milliers d'euros. Le second suffit largement dans la grande majorité des cas, y compris pour beaucoup de sites marchands.
Un site vitrine peut viser une reprise en 24 heures sans que cela pose problème. Une boutique en pleine période de soldes n'a pas le même arbitrage à faire. Ce ne sont pas les mêmes budgets, et c'est très bien ainsi.
Deux indicateurs, et rien d'autre à négocier
Le RTO, ou délai de remise en ligne
Combien de temps le site peut-il rester hors ligne avant que ce soit intenable ? Quatre heures ? Vingt-quatre ? Trois jours ? Cette valeur détermine l'architecture nécessaire et le budget associé. Elle doit figurer dans le contrat, chiffrée.
Le RPO, ou perte de données acceptable
Combien de temps de données acceptez-vous de perdre ? Une heure ? Une journée ? Cette valeur détermine la fréquence des sauvegardes, et rien d'autre.
Comment fixer ces valeurs sans se raconter d'histoires
Une méthode simple : calculez le chiffre d'affaires horaire moyen généré par le site, ajoutez le coût de la gestion de crise (temps interne, prestataires, communication), et le coût commercial différé (clients partis chez le concurrent, réputation). Confrontez le total au surcoût d'une architecture plus résiliente. Le calcul se fait en une demi-journée et il tranche des débats qui traînent depuis des années.
Le chemin de reprise, dans l'ordre exact
1. Constater, isoler, couper
Avant tout, empêcher la propagation. Couper l'accès public, isoler le serveur du réseau, révoquer les sessions actives. Oui, le site sera hors ligne. Il l'est déjà.
2. Qualifier
Panne ou compromission ? Cette question conditionne tout ce qui suit. Journaux d'accès, fichiers modifiés récemment, comptes administrateurs inconnus, tâches planifiées suspectes. Une demi-heure d'analyse évite trois jours d'errance.
3. Restaurer ailleurs
Sur un environnement neuf, jamais sur le serveur touché. Instance fraîche, système à jour, restauration de la sauvegarde antérieure à la date estimée de compromission. Le serveur d'origine reste figé, disponible pour l'analyse et les preuves.
4. Nettoyer et changer tous les secrets
Tous. Mots de passe administrateurs, comptes de base de données, clés d'API, accès FTP et SSH, jetons des services tiers. Un seul secret oublié suffit à rouvrir la porte. C'est fastidieux, c'est indispensable.
5. Rebasculer et vérifier le fonctionnel
Le DNS pointe vers le nouvel environnement. Puis on teste réellement : un parcours d'achat complet, un formulaire de contact, une inscription, l'envoi des mails transactionnels. Un site qui s'affiche n'est pas un site qui fonctionne. Combien de boutiques sont restées trois jours en ligne avec un tunnel de paiement muet ?
6. Surveiller les jours suivants
Après un ransomware, la récidive n'est pas un risque théorique, c'est le scénario le plus probable. Supervision renforcée, revue des journaux, alertes sur les créations de comptes et les modifications de fichiers. Pendant au moins un mois.
Le PRA tient sur une page
Pas un document de quarante pages que personne ne relit. Une page : la liste des contacts avec numéros directs, l'ordre d'appel, l'emplacement exact des sauvegardes et la procédure pour y accéder, les étapes de bascule DNS, l'environnement de secours prévu. Imprimée, affichée, connue de deux personnes au minimum.
Le test annuel, et ce qu'il révèle toujours
Une restauration à blanc sur un environnement de test, une fois par an, une demi-journée. Ce qu'elle met au jour est invariablement le même : un accès expiré, une dépendance non documentée, une version de PHP incompatible, un fichier de configuration absent de la sauvegarde. Mieux vaut le découvrir un jeudi tranquille que le jour où le chiffre d'affaires s'est arrêté.
Un plan de reprise jamais testé reste une intention. Une belle intention, mais une intention.
Le volet SEO : ce que le prestataire technique ne regarde pas
Le site est remonté, l'équipe technique referme le dossier. Six semaines plus tard, le trafic organique n'est jamais revenu à son niveau d'avant. Personne ne fait le lien, ou trop tard.
Ce que fait Google pendant une indisponibilité
Quelques heures
Le robot rencontre une erreur, il repasse plus tard. L'impact sur les positions est négligeable. Ce cas ne mérite pas d'inquiétude particulière.
Plusieurs jours
La logique change. Les pages commencent à sortir de l'index, les positions se dégradent, et surtout la remontée n'est pas symétrique : perdre trois semaines de visibilité peut demander deux à trois mois de reconquête. Le trafic ne revient pas parce que le serveur est revenu.
Le code 503, la seule réponse correcte
Pendant une coupure maîtrisée, le serveur doit renvoyer un code 503 accompagné d'un en-tête Retry-After. Ce couple dit explicitement au robot : c'est temporaire, reviens dans X secondes, ne touche pas à l'index. C'est deux lignes de configuration, et cela protège plusieurs mois de travail.
Les deux erreurs qui coûtent le plus
Renvoyer un code 200 sur une page vide ou une page de maintenance : Google enregistre alors des pages sans contenu et les traite comme telles. Ou renvoyer un 404 sur l'ensemble du site : là, le message est « ces pages n'existent plus », et la désindexation devient explicite et rapide. Ces deux configurations se rencontrent régulièrement, y compris chez des prestataires sérieux, parce que le SEO n'est pas leur métier et que personne ne le leur a demandé.
Les dégâts propres à une compromission
Pages parasites et injections
Un site piraté se voit greffer des centaines, parfois des milliers d'URL de spam. Elles sont indexées. Elles restent indexées bien après le nettoyage, et elles portent des thématiques qui n'ont aucun rapport avec votre activité. L'effet sur la perception globale du site par le moteur n'est pas anodin.
Le cloaking
Le plus vicieux. Le visiteur humain voit un site parfaitement normal. Le robot, identifié par son agent utilisateur, reçoit un contenu tout autre. Le dirigeant navigue sur son site, tout va bien, et pendant ce temps l'index se remplit de pages qu'il ne verra jamais. Ce type de compromission passe inaperçu pendant des mois. La seule façon de le détecter est d'inspecter l'URL comme le fait le moteur, pas comme le fait un navigateur.
L'avertissement de sécurité
Search Console signale le problème, et un bandeau rouge peut apparaître dans les résultats de recherche ou dans le navigateur. À ce stade, le trafic ne baisse pas : il s'effondre. La levée demande un nettoyage réel puis une demande d'examen, avec un délai de traitement de quelques jours. Une demande faite sur un site encore infecté est refusée, et les refus successifs n'accélèrent rien.
Nettoyer l'index correctement
Supprimer les fichiers de spam ne suffit pas : les URL restent dans l'index et y traînent longtemps. La bonne pratique est de répondre en 410 sur ces adresses, code qui signifie « supprimé définitivement », plutôt qu'en 404. Le retrait est nettement plus rapide. Sur un site ayant subi une injection massive, c'est parfois la différence entre trois semaines et six mois.
La checklist des 48 heures qui suivent le retour
Contrôler le rendu, pas le code HTTP
Une page peut répondre 200 et ne contenir que trois lignes de HTML. Il faut vérifier le contenu réellement servi, page type par page type : accueil, catégorie, fiche produit, article. Le code de retour ne dit rien de ce que voit le moteur.
Vérifier robots.txt, noindex, canoniques et sitemap
Une restauration ramène parfois un fichier robots.txt de préproduction qui bloque tout le site, ou une case « décourager les moteurs » restée cochée. Le sitemap, lui, peut être revenu dans un état vieux de plusieurs mois, avec des URL disparues et sans les pages récentes. Ce contrôle prend vingt minutes et évite des semaines de perte.
Comparer l'index avant et après
Si un relevé existait avant l'incident, la comparaison est immédiate. Sinon, il faut lister les URL indexées et repérer manuellement les intruses. Long, mais nécessaire.
Demander la levée de l'avertissement
Une fois le site réellement propre, et seulement à ce moment-là. Avec une description honnête de ce qui a été corrigé : le formulaire est lu.
Suivre positions et couverture sur plusieurs semaines
C'est ce suivi qui permet de dater précisément la perte, de mesurer la remontée, et le cas échéant d'appuyer une réclamation auprès d'un prestataire ou d'un assureur.
Le point de méthode qui change tout
Sans relevé de positions antérieur à l'incident, l'ampleur du sinistre SEO est tout simplement indémontrable. On ne peut ni chiffrer la perte, ni prouver la responsabilité, ni objectiver la reconquête. Un suivi de positions coûte quelques dizaines d'euros par mois. Il devient inestimable le jour où il faut établir un préjudice.
Autrement dit : le meilleur moment pour mettre en place ce suivi, c'est aujourd'hui, pendant que tout va bien.
Contrats et responsabilités : lire ce qui vous engage vraiment
L'hébergement mutualisé
Obligation de moyens, pas de résultat. Sauvegardes présentées comme un service annexe sans engagement ferme. Responsabilité plafonnée, souvent à quelques mois d'abonnement. Pour un hébergement à 8 euros par mois, l'indemnisation maximale se compte en dizaines d'euros. Face à une semaine d'arrêt d'une boutique, l'ordre de grandeur parle de lui-même.
Ce n'est pas un scandale, c'est le modèle économique. Le problème naît quand on croit avoir acheté autre chose.
L'infogérance
Là, un vrai engagement est possible. Encore faut-il lire le périmètre : le contrat couvre-t-il le système seulement, ou aussi l'applicatif ? Y a-t-il une astreinte hors heures ouvrées, ou une panne du vendredi soir attend-elle le lundi matin ? Beaucoup de contrats se limitent aux heures ouvrées sans que le client en ait conscience.
Le contrat d'agence
La maintenance applicative couvre en général les mises à jour du cœur et des extensions, parfois la sauvegarde. Presque toujours, une clause exclut les conséquences d'une intrusion. On comprend la logique : l'agence ne maîtrise pas les pratiques de sécurité du client. Mais il faut le savoir avant, pas pendant.
Les clauses à lire ligne à ligne
Le SLA et sa base de calcul
99,9 % de disponibilité annuelle, cela représente près de neuf heures d'indisponibilité tolérée par an. 99,99 % descend à environ cinquante minutes. L'écart de prix entre les deux est considérable. Et le calcul se fait souvent sur l'année entière : une coupure de six heures d'affilée peut rester dans les clous contractuels tout en ruinant votre journée.
Intervention n'est pas rétablissement
La distinction la plus lourde de conséquences. « Intervention sous 2 heures » signifie que quelqu'un prend le dossier en main. Pas que le site revient. Un contrat sans délai de rétablissement chiffré est un contrat qui n'engage à peu près rien.
Les exclusions
Force majeure, faute du client, extensions tierces, mots de passe compromis, modifications non autorisées. Une extension défaillante est presque toujours exclue. Et un ransomware entré par un identifiant volé bascule dans la catégorie « faute du client » plus souvent qu'on ne l'imagine.
La réversibilité
Pouvez-vous récupérer vos données, vos accès et votre code sans dépendre de la bonne volonté du prestataire ? Sous quel format, dans quel délai, à quel coût ? Cette clause paraît théorique tant que la relation est bonne. Elle devient centrale le jour où elle se dégrade, ou quand le prestataire cesse son activité.
La propriété des accès
Le point le plus simple à corriger, et le plus souvent négligé. Nom de domaine, hébergement, Search Console, outils de mesure : tout doit être au nom du client, avec le prestataire en accès délégué. Jamais l'inverse. Un domaine déposé au nom de l'agence est une dépendance dont on ne mesure la gravité qu'au moment de la rupture.
Assurance cyber et responsabilité civile
Une assurance cyber peut couvrir les frais de réponse à incident, la perte d'exploitation, l'assistance juridique et la notification aux personnes concernées. En contrepartie, les contrats exigent de plus en plus un socle : sauvegardes testées, authentification renforcée, correctifs à jour. Un assureur peut réduire ou refuser sa garantie si ces conditions n'étaient pas remplies.
Et pour être indemnisé, il faut produire des preuves : journaux, horodatages, dépôt de plainte, chiffrage de la perte. D'où l'importance de préserver l'état du système avant de tout reformater dans l'urgence.
Quand le prestataire est défaillant ou injoignable
Cela arrive : cessation d'activité, litige, ou simplement absence prolongée. Si les accès sont au nom du client, la reprise en main est pénible mais possible. S'ils ne le sont pas, il faut passer par les procédures de récupération du registrar et de l'hébergeur, avec justificatifs de propriété, et compter des jours voire des semaines. Pendant lesquelles le site reste tel quel.
Une raison de plus de vérifier la ligne « propriété des accès » dès maintenant.
Prévenir : le socle minimal, hors période de crise
Détenir ses accès et les documenter
Un gestionnaire de mots de passe d'entreprise, un inventaire à jour, un export chiffré conservé hors ligne. Deux personnes au moins doivent savoir y accéder. Une demi-journée de mise en place, et le bénéfice est immédiat le jour J.
Être alerté avant ses clients
Une surveillance de disponibilité coûte quelques euros par mois et prévient en quelques minutes. Sans elle, l'alerte vient d'un client mécontent, avec plusieurs heures de retard. Idéalement, surveiller aussi le contenu d'une page clé : cela détecte un défacement ou une injection que le simple contrôle de disponibilité ne verrait jamais.
Séparer les environnements et durcir les entrées
Un environnement de préproduction distinct, protégé et non indexé. L'authentification à deux facteurs sur tous les comptes d'administration. La suppression des comptes inutilisés, qui sont la porte d'entrée la plus banale. Et le retrait des extensions installées « pour tester » puis oubliées : elles ne sont plus mises à jour et personne ne les surveille.
Tenir un inventaire technique
Versions du langage et du CMS, liste des extensions avec leur version, connecteurs actifs, dépendances externes, dates de fin de support. Une page qui se met à jour en dix minutes par trimestre et qui, le jour de la restauration, dit exactement quoi réinstaller et dans quelle version.
Formaliser le plan et le tester
Une page, une restauration à blanc annuelle, même sommaire. Ce n'est pas une démarche de grand groupe. C'est une demi-journée par an, et c'est ce qui distingue une entreprise qui repart en quatre heures d'une entreprise qui repart en quatre jours.
Choisir son prestataire sur sa capacité à remonter, pas seulement à construire
On choisit une agence sur son portfolio. On la juge, un jour, sur sa capacité à remettre les choses debout. Ce sont deux compétences différentes, et le portfolio ne dit rien de la seconde.
Les questions à poser avant de signer
Elles sont peu nombreuses et le niveau de réponse renseigne immédiatement. Où sont stockées mes sauvegardes, et sont-elles hors de portée du serveur ? Quelle est leur profondeur de rétention ? Quand avez-vous testé une restauration pour la dernière fois, et pouvez-vous me montrer le compte-rendu ? Quel délai vous engagez-vous à tenir pour un rétablissement, pas pour une prise en compte ? Que se passe-t-il un samedi à 3 h du matin ? Qui coordonne si le problème implique aussi l'hébergeur ? Et enfin : les accès sont-ils à mon nom ?
Un prestataire solide répond sans hésiter et propose souvent de vous montrer. Un prestataire qui botte en touche vous a déjà répondu.
Le récapitulatif en dix points
- Cartographier les cinq maillons de la chaîne, sur une page imprimée.
- Détenir tous les accès en propre, prestataires en délégation.
- Vérifier que les sauvegardes sont hors du serveur et immuables ou déconnectées.
- Exiger 30 jours de rétention minimum, pas 7.
- Tester une restauration une fois par an, au minimum.
- Chiffrer un RTO et un RPO, et les inscrire au contrat.
- Distinguer dans le contrat délai d'intervention et délai de rétablissement.
- Documenter à part ce qu'aucune sauvegarde ne contient : DNS, certificats, clés d'API, comptes tiers.
- Mettre en place un suivi de positions dès aujourd'hui, pour pouvoir mesurer demain.
- Prévoir le 503 avec
Retry-Afterpour toute coupure maîtrisée, et le 410 pour nettoyer un index pollué.
Auditer sa chaîne de reprise avant le sinistre
La plupart des entreprises découvrent les failles de leur dispositif le jour où elles en ont besoin. C'est le pire moment : sous pression, sans recul, avec des interlocuteurs qui se renvoient la responsabilité.
Un audit de la chaîne de reprise et de l'exposition SEO tient en quelques jours. Il vérifie qui détient quoi, si les sauvegardes sont réellement exploitables, ce que disent vraiment les contrats, et quel serait le coût d'une indisponibilité de trois jours. Il ne supprime pas le risque, aucun dispositif ne le fait. Il transforme une panique en procédure.
Et le jour où le téléphone sonne à 8h10, ça change tout.
