Sauvegarde de site web et backup WordPress : la question n’est pas de savoir si vous en avez une

La plupart des propriétaires de sites dorment tranquilles : ils paient leur hébergement, et l’offre mentionnait des sauvegardes régulières. Le problème, c’est qu’au moment critique — après une attaque, une erreur de manipulation, une panne — la question n’est pas « avez-vous une sauvegarde ? ».

La vraie question est : qui a essayé de la restaurer en dernier, et combien de temps cela a-t-il pris ?

Une sauvegarde que personne n’a jamais restaurée ne procure qu’un sentiment de sécurité. Il prend fin le jour où l’on découvre que l’automate écrasait depuis des mois des fichiers endommagés, ou que la restauration se compte en jours et non en heures. C’est vrai pour n’importe quelle sauvegarde de site web, et plus encore pour un backup WordPress, où la moitié de ce qui fait fonctionner le site ne se trouve pas dans les fichiers.

Ce que l’on sauvegarde réellement — et pourquoi les fichiers ne suffisent pas

Restaurer un site, ce n’est pas copier-coller un seul répertoire. Un site en production est un système de vases communicants : restaurer les fichiers sans une base de données à jour ramène au mieux l’apparence — sans les contenus, sans l’historique des commandes, sans les comptes clients.

Pour qu’un site redémarre, il faut une copie cohérente de quatre couches.

Deux précisions, parce que ces points sont souvent confondus. Le certificat SSL ne fait généralement pas partie de la sauvegarde du site — c’est l’hébergeur qui l’émet et le renouvelle, et il revient tout seul après une restauration sur le même serveur ; ce qui se perd, en revanche, ce sont les réglages qui imposent la connexion chiffrée, et cela relève de la couche configuration. Et les mots de passe des administrateurs se trouvent dans la base de données, pas dans une couche à part — ce qui est conservé séparément, ce sont les clés des services externes, et ce sont elles qui, le plus souvent, ne reviennent pas avec la sauvegarde.

C’est particulièrement net avec WordPress, et c’est la raison pour laquelle un backup WordPress ne se résume jamais à « copier le site ». Une installation se compose de deux moitiés qui ne vivent pas au même endroit : la base de données, qui contient presque tout ce que vous avez écrit, et le répertoire des fichiers téléversés, des extensions et du thème. Une extension de sauvegarde bien réglée prend les deux ; une copie des seuls fichiers par FTP n’en prend qu’une. Et l’export de contenu proposé dans le tableau de bord n’est pas une sauvegarde : il extrait des textes, pas un site qui redémarre.

Conclusion pratique : la question à poser à votre hébergeur ou à votre prestataire est « que comprend exactement la sauvegarde ? », et non « y en a-t-il une ? ». « Les fichiers et la base de données » est une bonne réponse. « Tout le site » n’est pas une réponse.

Il existe une cinquième chose qui n’entre dans aucune couche, et sans laquelle aucune restauration ne commence : savoir où se trouve la sauvegarde et comment y accéder. Cela paraît trivial, jusqu’au jour où la personne qui l’a configurée a quitté l’entreprise et que les copies dorment sur un compte ouvert avec son adresse professionnelle. Nous avons vu ce cas plus souvent que des archives corrompues — et c’est le seul point de cette liste qui ne coûte rien, sinon une phrase notée à côté des accès à l’hébergement et au nom de domaine.

Où se trouve la copie — et contre quoi elle protège

« J’ai un backup chez mon hébergeur » décrit un emplacement, pas une protection. Et c’est l’emplacement qui décide de ce contre quoi la copie protège réellement.

Une copie sur le même serveur n’est pas une sauvegarde — c’est un deuxième fichier à côté du premier. Elle disparaît avec le disque, avec le compte, et avec le chiffrement des ressources.

Une copie dans le système de sauvegarde de l’hébergeur est déjà quelque chose de réel, parce qu’elle se trouve généralement sur un autre volume. Elle survit à une panne matérielle. Elle ne survit pas à la suppression du compte — que ce soit à cause d’un litige avec le fournisseur, d’une facture impayée ou d’une prise de contrôle du panneau par quelqu’un qui n’a rien à y faire.

Une copie hors du compte, chez un autre fournisseur, survit aux trois scénarios. Non parce qu’elle est plus chère ou techniquement meilleure — parce qu’elle ne partage pas le sort de ce qu’elle doit sauver. C’est tout le contenu de la règle souvent répétée de la copie « hors site », et la seule partie à retenir.

Le rançongiciel mérite une phrase à part, parce que c’est lui qui ruine le plus de plans : le logiciel malveillant chiffre non seulement les données, mais aussi les ressources réseau montées auxquelles le serveur a accès. Une copie branchée au même système comme disque réseau est chiffrée avec le reste. L’Office fédéral de la cybersécurité le rappelle dans son rapport semestriel 2026/1 : les rançongiciels visent presque exclusivement des organisations, et en Suisse leurs conséquences vont de l’absence de préjudice à la faillite.

D’où une distinction qui, en pratique, fait toute la différence, même si elle sonne technique : la sauvegarde doit être hors de portée du serveur en écriture. Autrement dit, c’est la sauvegarde qui va chercher les données, pas le serveur qui dépose ses archives. Si la configuration est inverse — le site pousse lui-même ses archives sur un disque monté — alors tout ce qui prend le contrôle du site prend aussi les archives. Avec une offre d’hébergement ordinaire, c’est une question d’une phrase au support technique : les sauvegardes sont-elles hors du compte, et peut-on les écraser depuis le serveur ?

Et dans quel pays ?

Un point pèse plus lourd ici qu’ailleurs. Beaucoup d’entreprises suisses promettent à leurs clients que leurs données restent en Suisse — c’est souvent la raison même du choix d’un hébergeur local. Cette promesse couvre aussi les sauvegardes, parce qu’une sauvegarde est une copie complète des mêmes données. Or c’est précisément la copie « hors site » qui a le plus de chances de partir ailleurs : chez un autre fournisseur, dans un autre centre de données, parfois dans un autre pays.

L’Office fédéral de la cybersécurité (OFCS) met cette question en tête de celles à poser à un prestataire informatique externe : où se trouvent exactement mes données, en Suisse, en Europe ou dans un État tiers, et comment le respect de la loi fédérale sur la protection des données est-il garanti ? La même question vaut pour la copie de secours. La réponse ne doit pas nommer une « région », mais un pays. Et si la copie se trouve hors de Suisse, cela peut devoir figurer dans ce que vous indiquez à vos clients sur la communication de leurs données à l’étranger — un point à régler avec votre juriste, pas à découvrir le jour de l’incident.

En droit suisse, une perte de données est une violation, pas seulement une panne

Cette partie est absente des guides sur les sauvegardes, et elle change la nature du problème.

La loi fédérale sur la protection des données (LPD) révisée, en vigueur depuis le 1er septembre 2023, définit à son art. 5, let. h, la violation de la sécurité des données comme toute violation de la sécurité entraînant, de manière accidentelle ou illicite, la perte de données personnelles, leur modification, leur effacement ou leur destruction, leur divulgation ou un accès non autorisé. Le mot important est « accidentelle » : une fuite n’est pas nécessaire. Une panne qui efface des données personnelles sans sauvegarde restaurable entre dans la définition.

Trois conséquences à connaître avant la panne.

L’annonce au PFPDT dépend du risque. L’art. 24, al. 1, oblige le responsable du traitement à annoncer au Préposé fédéral à la protection des données et à la transparence, « dans les meilleurs délais », les violations qui entraînent vraisemblablement un risque élevé pour la personnalité ou les droits fondamentaux des personnes concernées. La loi suisse ne fixe pas de délai en heures. L’annonce indique au moins la nature de la violation, ses conséquences et les mesures prises ou envisagées ; les personnes concernées sont informées lorsque cela est nécessaire à leur protection ou que le PFPDT l’exige.

Le RGPD ajoute son propre délai quand il s’applique. Si votre entreprise traite des données de personnes qui se trouvent dans l’Union européenne dans le cadre d’une offre de biens ou de services qui leur est destinée, le règlement européen peut s’appliquer (art. 3, par. 2). Son art. 33 impose alors de notifier l’autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance — sauf si la violation n’est pas susceptible d’engendrer un risque — et d’expliquer tout retard. Le chronomètre part du moment où l’on a connaissance de la violation, pas de sa résolution.

Une sauvegarde qui fonctionne change l’évaluation. Des données perdues mais restaurées en une heure ne présentent pas le même risque que des données qui ne reviennent jamais. Le rançongiciel est le cas typique : les données sont chiffrées sur place, rien n’est forcément copié à l’extérieur, et pourtant l’entreprise n’y a plus accès — parfois sauvegardes comprises. Savoir si un chiffrement réversible ou non constitue une « perte » au sens de la loi relève de l’appréciation juridique ; ce qui ne fait aucun doute, c’est qu’une copie intacte réduit à la fois le temps d’arrêt et l’ampleur de ce qu’il y aurait à annoncer.

Ce que cette section n’affirme pas : que chaque panne de site est une violation à annoncer. Si le site ne traite aucune donnée personnelle et n’a aucun formulaire, son indisponibilité est un problème commercial, pas juridique. Le seuil tient à une question : ce qui a été perdu contenait-il des données de personnes — demandes envoyées par formulaire, comptes clients, commandes, historique de correspondance ? Pour un site d’entreprise ordinaire, la réponse est « oui », et c’est pour cela que cette section figure ici.

Conséquence pratique, simple et peu intuitive : une sauvegarde qui fonctionne ne raccourcit pas seulement l’arrêt — elle change ce qu’il faut annoncer et avec quel niveau de risque. L’obligation d’informer et la manière de l’exercer sont décrites dans notre article sur la politique de confidentialité.

« L’hébergeur s’en occupe » — ce que dit la loi de cette phrase

C’est la phrase que nous entendons le plus souvent, et la LPD y répond de trois façons.

Premièrement, la sous-traitance ne transfère pas la responsabilité. L’art. 9 permet de confier un traitement à un sous-traitant — hébergeur, agence, service de sauvegarde — mais son al. 2 précise que le responsable du traitement doit en particulier s’assurer que le sous-traitant est en mesure de garantir la sécurité des données. Autrement dit, il ne suffit pas qu’un prestataire existe ; il vous appartient de savoir qu’il fait ce qu’il faut. Et l’art. 8 impose la sécurité adéquate aux deux, au responsable comme au sous-traitant.

Deuxièmement, le sous-traitant doit vous prévenir. L’art. 24, al. 3, oblige le sous-traitant à annoncer au responsable du traitement tout cas de violation de la sécurité des données, dans les meilleurs délais — pas seulement ceux à risque élevé. Si votre contrat avec l’hébergeur ou l’agence ne prévoit pas qui vous appelle et comment, cette obligation reste théorique jusqu’au jour où vous en avez besoin.

Troisièmement, les sanctions visent des personnes. Les amendes de la LPD — jusqu’à 250 000 CHF — frappent, sur plainte, les personnes privées qui agissent intentionnellement, notamment celles qui confient un traitement à un sous-traitant sans que les conditions de l’art. 9, al. 1 et 2, soient réunies, ou qui ne respectent pas les exigences minimales de sécurité édictées par le Conseil fédéral (art. 61, let. b et c). L’entreprise ne peut être condamnée à la place des personnes que lorsque l’amende n’excède pas 50 000 CHF et qu’identifier les responsables demanderait une enquête disproportionnée (art. 64). En clair, la loi regarde qui, dans l’entreprise, a décidé ou négligé — pas seulement quelle société a signé le contrat.

Rien de cela ne veut dire que votre hébergeur travaille mal. Il s’occupe de sa couche, et en général il le fait bien. Mais la responsabilité de savoir ce que couvre la sauvegarde, et si elle se restaure, reste chez vous — c’est exactement ce que la loi demande de vérifier, et c’est ce que le test ci-dessous permet de vérifier.

Le test qui tranche tout

Cinq questions. La réponse « nous avons un backup » ne répond à aucune d’elles.

Les plus importantes sont la première et la deuxième, ensemble : qui a restauré, et combien de temps cela a pris. Tant que personne n’a essayé, on ne sait pas si la copie est complète, si elle se décompresse ni si elle contient la base de données. Et la durée de restauration est votre temps d’arrêt réel — pas celui de l’offre du fournisseur, mais celui que vous donnerez à un client qui vous demande quand vous serez de retour.

L’OFCS pose la même question, presque mot pour mot, dans sa liste à l’intention des PME qui travaillent avec un prestataire informatique : quand la restauration des données a-t-elle été testée avec succès pour la dernière fois ? Copier des données ne suffit pas, écrit l’office ; il faut qu’un prestataire puisse garantir que les sauvegardes fonctionnent aussi en cas d’urgence. Une question d’une ligne, posée avant la signature ou au prochain renouvellement, qui en dit plus que n’importe quelle brochure.

Le test se fait sur une copie de l’environnement, pas sur le site en production, et de préférence quand rien ne brûle. C’est un après-midi par an qui transforme « je crois que nous en avons une » en un nombre d’heures.

Les trois découvertes les plus fréquentes lors d’un tel test : la sauvegarde ne contenait pas la base de données, seul le prestataire avait accès aux copies, ou la restauration exigeait un mot de passe dont plus personne ne se souvenait.

Ce qu’il faut noter après le test, pour ne pas repartir de zéro l’année suivante : la date, la durée de restauration, l’endroit d’où venait la copie, et ce qui manquait. Quatre lignes dans le document où vous gardez les accès à l’hébergement et au nom de domaine. Lors de la prochaine panne, c’est la première chose que cherchera n’importe qui — y compris le prestataire que vous appellerez au milieu de la nuit.

Il existe une version de ce test pour les entreprises qui n’ont nulle part où restaurer : demandez à votre hébergeur de restaurer une sauvegarde sur un environnement de test. La plupart proposent ce service, parfois gratuitement la première fois. Un refus, ou l’absence de cette possibilité, est aussi une information — et une information sérieuse.

Qui s’en charge, et ce que cela coûte

Honnêtement : pour un site d’entreprise, la sauvegarde est l’un des postes les moins chers de toute la maintenance, et l’un des rares où bon marché veut vraiment dire suffisant.

Trois niveaux, tels que nous les rencontrons :

Les sauvegardes incluses dans l’hébergement, activées et vérifiées. Elles font généralement partie de la formule, ou coûtent peu. Elles suffisent à un site vitrine, à condition que quelqu’un ait vérifié une fois ce qu’elles couvrent et combien de temps elles sont conservées.

Une extension ou un service qui envoie la copie hors du compte. C’est à ce niveau qu’apparaît une copie qui survit à la perte du compte — et pour la plupart des entreprises, c’est le bon choix. Pour un site WordPress, c’est typiquement une extension de backup WordPress réglée pour déposer ses archives chez un autre fournisseur, et non dans un répertoire du serveur.

Une sauvegarde gérée par un prestataire, avec un test de restauration inscrit au contrat. Pertinente pour une boutique et pour un site qui génère du chiffre d’affaires : vous ne payez alors pas la copie elle-même, mais le fait que quelqu’un réponde du délai de retour.

Nous n’avons pas relevé les prix de ces services sur le marché suisse et nous ne publions donc pas de fourchette. Nous publions en revanche les nôtres, tels qu’ils figurent dans notre calculateur de coût de maintenance : la sauvegarde hebdomadaire à 15 CHF par mois, quotidienne à 30 CHF, en temps réel à 60 CHF. Ce sont nos tarifs, hors taxes, pas un repère de marché — ils servent à situer l’ordre de grandeur de ce poste à côté du reste de la facture d’exploitation.

Ce qu’il ne vaut pas la peine d’acheter : des formules où le « backup » est la seule ligne, et qui coûtent plus que ce qui précède. Une seule question de contrôle, qui tranche en une phrase : dans ce service, quelqu’un restaure-t-il un jour la sauvegarde, ou se contente-t-il de la créer ?

Combien de copies, et à quelle fréquence

La règle « trois copies, deux supports, une hors site » se récite comme une litanie ; mieux vaut la décrire par ce contre quoi elle protège que par ses chiffres. L’OFCS la formule ainsi : trois copies, deux supports différents, une copie hors site et, dans l’idéal, hors ligne — ce dernier mot étant précisément la parade au rançongiciel.

Trois copies — parce que la deuxième peut être endommagée, et qu’on ne le découvre qu’au moment de restaurer.

Deux emplacements différents — parce qu’un seul emplacement, c’est une seule panne.

Une hors de l’infrastructure — parce que c’est la seule qui survit à la perte du compte et au chiffrement des ressources.

La fréquence se déduit d’une seule question : combien de travail êtes-vous prêt à perdre ? Un site d’entreprise sur lequel rien ne change pendant des semaines supporte très bien une copie quotidienne. Une boutique qui reçoit des commandes a besoin de copies plus fréquentes, parce que chaque heure représente des commandes qu’aucune autre source ne permet de reconstituer.

Combien de temps conserver : assez longtemps pour pouvoir revenir avant le moment où quelque chose a mal tourné. C’est un argument pratique, pas juridique — les infections et les corruptions sont parfois découvertes après plusieurs semaines, et la copie de la veille est alors celle d’un état déjà abîmé.

En pratique, cela donne généralement une rotation : quelques copies quotidiennes, quelques hebdomadaires et une mensuelle. Non parce qu’une norme l’exige — parce que cela couvre trois scénarios différents. La quotidienne sauve d’une erreur commise quelques heures plus tôt, l’hebdomadaire d’une mise à jour ratée remarquée le lundi, la mensuelle d’une infection restée silencieuse, découverte à la plainte d’un client ou par un message du moteur de recherche. Les réglages par défaut de la plupart des offres d’hébergement couvrent le premier scénario et parfois le deuxième — presque jamais le troisième, et c’est la seule chose de cette section qu’il vaut la peine d’ajouter consciemment.

Ce que cet article laisse volontairement de côté

• Le RTO, le RPO et les solutions de niveau entreprise. C’est le langage d’un service informatique et une autre échelle de problème ; pour un site d’entreprise, la question « combien de temps a pris la restauration ? » les remplace.
• La comparaison d’outils et de fournisseurs précis. Ils changent plus vite qu’on ne peut tenir un texte à jour.
• Les durées de conservation par branche. C’est une question juridique, pas technique, et elle dépend des données que vous conservez.
• Le contrôle des accès et les comptes du panneau — comment sécuriser un site internet.
• Les mises à jour logicielles — traitées à part ; un logiciel non corrigé est l’une des portes d’entrée classiques des rançongiciels que les sauvegardes doivent ensuite rattraper.

Quatre phrases que nous entendons le plus souvent

« L’hébergeur fait des sauvegardes, donc c’est réglé. » Il en fait — et c’est bien. Mais il ne sait pas ce que contient votre base, il ne la restaurera pas à votre place, et ses copies ne survivront pas à la suppression du compte. La phrase est vraie et insuffisante à la fois, et la différence ne se révèle que le jour de la panne.

« Nous avons une extension de backup WordPress. » L’extension crée des archives. La question est de savoir où elle les dépose : si c’est dans un répertoire du même serveur, c’est un deuxième fichier à côté du premier — et un fichier qui grossit, capable de saturer l’espace de l’hébergement et de faire tomber le site sans la moindre attaque.

« Nous vérifierons quand il le faudra. » C’est alors le pire moment possible : sous pression, sans savoir combien de temps cela prendra, et sans endroit où essayer sans risque. Un test fait au calme coûte un après-midi ; le même test fait pendant une panne coûte une journée et quelques mauvaises décisions.

« C’est un site vitrine, pas une boutique — il n’y a rien à perdre. » Il y a : les demandes reçues par formulaire, des contenus écrits au fil des années, des positions acquises sur des adresses précises. Refaire l’apparence prend des jours, refaire les textes des semaines, et une partie ne peut pas être refaite du tout, parce que personne n’en a de copie ailleurs.

Une boutique, c’est une autre catégorie

Tout ce qui précède concerne un site d’entreprise. Pour une boutique en ligne, trois choses changent, et elles méritent d’être nommées à part, parce qu’elles changent aussi les choix.

Les commandes ne se reconstituent à partir de rien d’autre. Le contenu d’un site existe dans les têtes et dans des fichiers ; la commande d’hier n’existe que dans la base. Cela fait passer la fréquence de quotidienne à horaire, et c’est le seul endroit de cet article où nous recommandons plus que le minimum.

La restauration doit inclure l’état des paiements. Une boutique ramenée à l’état de la veille affiche comme impayées les commandes réglées après cette heure — et c’est pire qu’une boutique fermée pendant une heure. Pour une boutique, on planifie la restauration en même temps que le traitement de ce trou dans le temps, et non à sa place.

Les données des clients élèvent l’enjeu juridique. La base d’une boutique contient des adresses, un historique d’achats, parfois des données de paiement — l’évaluation du risque après une perte n’a donc rien à voir avec celle d’un site doté d’un simple formulaire de contact, et la question de l’annonce au PFPDT se pose beaucoup plus vite.

Par où commencer

Si vous partez de zéro : cinq étapes et un après-midi.

1. Établissez ce que couvre la sauvegarde actuelle. Une question à l’hébergeur ou au prestataire : fichiers, base, fréquence, durée de conservation, emplacement — pays compris.
2. Vérifiez qu’au moins une copie se trouve hors du compte d’hébergement. Sinon, c’est la première chose à ajouter, et généralement la moins chère.
3. Restaurez-la sur un environnement de test et chronométrez.
4. Notez quatre lignes : date, durée, source, ce qui manquait.
5. Ajoutez-y les accès — qui peut entrer dans la sauvegarde, à côté de qui peut entrer dans l’hébergement et le nom de domaine.

Les étapes un à trois se font une fois. Les étapes quatre et cinq font que, dans un an, vous ne repartez pas de zéro — et ce sont les seules dont personne ne se souvient jamais, parce que rien ne casse à cause d’elles jusqu’au jour où tout casse en même temps.

Le résumé le plus court : une sauvegarde commence à exister au moment où quelqu’un l’a restaurée. Avant, c’est une ligne dans l’offre de l’hébergeur — et une ligne dans une offre ne raccourcit pas un arrêt et ne change rien à l’évaluation du risque le jour où il faut décider s’il y a quelque chose à annoncer.