Sauvegarde WordPress : le guide complet pour les agences (2026)

Posez-vous une seule question concernant le site de votre plus gros client : êtes-vous capable de le restaurer à l'état où il se trouvait hier à 8 heures du matin, en moins d'une heure, sans avoir à contacter l'hébergeur ? Si la réponse est « probablement », vous n'avez pas de stratégie de sauvegarde. Vous avez un plugin de sauvegarde et un peu d'espoir.

Une sauvegarde WordPress n'est pas un plugin que l'on installe.

C'est une infrastructure que vous gérez. Elle comporte une fréquence cible, un délai de restauration cible, une topologie de stockage, un modèle de chiffrement, une politique de conservation et un calendrier de vérification. Si l'un de ces éléments fait défaut, votre sauvegarde n'existe pas, quoi qu'en dise votre tableau de bord.

Ce guide s'adresse aux dirigeants d'agences et aux techniciens expérimentés qui gèrent entre 20 et 500 sites clients. Il met en avant les incitations là où elles comptent (périodes de fidélisation des hébergeurs, barrières de paiement des plugins, solutions SaaS d'Automattic) sans critiquer les fournisseurs.

L'objectif est de mettre en place un cadre que vous pourrez justifier auprès de votre équipe, de vos clients et de vous-même, même à 3 heures du matin, en pleine restauration. À la fin, vous serez en mesure d'évaluer les sauvegardes comme un ingénieur en infrastructure, et non comme un simple acheteur de plugins.

Qu'est-ce qu'une sauvegarde WordPress, en réalité (et ce qu'elle n'est pas)

Ce que contient une sauvegarde complète de WordPress

Une sauvegarde WordPress est une copie complète et restaurable des fichiers, de la base de données et de la configuration d'exécution qui, ensemble, vous permettent de reconstruire un site WordPress de production sur un nouveau serveur à partir d'un instant précis. Un site WordPress, c'est bien plus que /wp-content/ et une sauvegarde MySQL. Une sauvegarde n'est complète que si elle permet à elle seule de restaurer un serveur vierge sur le site de production actuel.

Cette liste de contrôle :

• L'intégralité /wp-content/ répertoire, y compris les fichiers téléchargés, les thèmes, les extensions et tout autre mu-plugins.
• La base de données complète, comprenant tous les éléments non-wp_ table (commandes WooCommerce, relations ACF, tables de plugins personnalisés).
• wp-config.php, en indiquant le préfixe de table, les valeurs de décalage et les identifiants de connexion à la base de données appropriés.
• .htaccess ou nginx.conf règles de réécriture, ainsi que toute .user.ini Remplacements PHP.
• Certificats SSL, enregistrements DNS (notamment MX, SPF, DKIM, DMARC) et clés d'API tierces (Stripe, Mailgun, jetons CDN).

La plupart des plugins de sauvegarde prennent en charge les deux premiers points. Une véritable reprise après sinistre couvre les cinq. La documentation officielle de WordPress sur les sauvegardes aborde la couche des fichiers et de la base de données ; le reste vous incombe.

Sauvegarde, migration, mise en production progressive et gestion des versions

Ces quatre éléments ne sont pas interchangeables. Les packages de migration permettent de déplacer des serveurs. L'environnement de préproduction sert aux tests. Le contrôle de version s'applique au code, et non à la base de données, aux téléchargements ou à la configuration d'exécution. Une sauvegarde répond à une seule question : « Puis-je restaurer l'environnement de production tel qu'il était à un moment T ? » Si votre réponse est l'une des autres, vous n'avez pas de stratégie de sauvegarde.

Pourquoi les sauvegardes WordPress échouent plus souvent que vous ne le pensez

Les sauvegardes WordPress échouent pour quatre raisons récurrentes : la corruption silencieuse des archives passe inaperçue jusqu'à la restauration ; les tâches batch liées à PHP manquent de mémoire ou de temps sur les sites volumineux ; la sauvegarde se trouve dans la même zone d'impact que le site ; et les délais de conservation des hébergeurs correspondent rarement au SLA d'une agence.

Chacun de ces points est abordé ci-dessous.

Le problème des pannes silencieuses

On parle d'échec silencieux de la sauvegarde lorsqu'un processus de sauvegarde indique que l'opération s'est déroulée avec succès, mais que l'archive obtenue est irrécupérable. C'est ce type de problème qui cause la perte de la plupart des agences WordPress.

Le journal de sauvegarde indique que l'opération a réussi. Le fichier ZIP est bien présent. Sa taille correspond à peu près à ce qu'elle devrait être. Personne n'a essayé de le restaurer. Quelques mois plus tard, lors d'un incident réel, la restauration échoue parce que l'archive a été tronquée en raison d'une limite de mémoire PHP, ou parce que l'exportation de la base de données s'est arrêtée en cours de route, ou encore parce que le fichier ZIP téléchargé a été corrompu pendant le transfert et qu'aucune vérification de hachage n'a été effectuée.

La seule solution consiste à effectuer régulièrement des exercices de restauration (voir ci-dessous). Une sauvegarde qui n'a jamais été restaurée n'est qu'un vœu pieux, pas une véritable sauvegarde.

Avant de rédiger cet article, nous avons testé la plupart des plugins de sauvegarde disponibles sur le marché. Seuls quelques-uns sont fiables (WP Umbrella, ManageWP, Blogvault), tandis que d'autres vous décevront et méritent que vous les examiniez de toute urgence (ModularDS, UpdraftPlus, WP Vivid, BackWPup).

Le problème de défaillance côté serveur

La plupart des plugins de sauvegarde WordPress s'exécutent directement sur le site. Ils allouent de la mémoire PHP, compressent les fichiers au format ZIP et transfèrent cette archive hors du serveur. Sur un site vitrine de 500 Mo, cela fonctionne. Sur une boutique WooCommerce de 12 Go hébergée sur un serveur mutualisé avec une limite de mémoire PHP de 256 Mo, cela échoue silencieusement, souvent pendant des mois, avant que quiconque ne s'en aperçoive. La solution architecturale (streaming vs traitement par lots) fait l'objet d'une section distincte ci-dessous. C'est le facteur le plus déterminant pour la fiabilité des sauvegardes à grande échelle en conditions réelles.

Le problème du rayon d'action

Si votre plugin de sauvegarde stocke les archives dans /wp-content/uploads/backups/, et si un pirate, une mise à jour défectueuse d'un plugin ou un cron incontrôlable dispose d'un accès en écriture au système de fichiers, votre sauvegarde disparaîtra au moment même où votre site sera compromis. Si votre destination hors site utilise une seule clé API stockée dans wp-config.php, les mêmes identifiants qui permettent au site d'effectuer des sauvegardes permettent également à n'importe quel élément du site de les supprimer.

Une sauvegarde située dans le même domaine de défaillance que le site n'est pas une sauvegarde. Il s'agit d'une deuxième copie exposée au même risque.

Le décalage dans la rétention des hôtes

Les hébergeurs gérés conservent les sauvegardes pendant une période déterminée — généralement de 14 à 30 jours, selon la formule et le fournisseur. Cette période correspond rarement au SLA d'un contrat de maintenance d'agence qui promet la récupération des données des « 60 derniers jours ». Elle disparaît en outre complètement si l'hébergeur suspend le compte en raison d'un litige de paiement, d'une violation des conditions d'utilisation ou d'un événement lié à une acquisition ou à la cessation d'activité. Les sauvegardes de l'hébergeur constituent un moyen pratique de restauration rapide, mais ne constituent pas une stratégie.

Pourquoi les pirates s'intéressent à vos sauvegardes (et pourquoi cela a moins d'importance que vous ne le pensez)

Les stratégies actuelles des ransomwares visent d'abord les sauvegardes : détruire le point de restauration est la première étape, chiffrer l'environnement de production est la deuxième. Pour les agences WordPress, cela met en évidence une chose concernant l'emplacement idéal des sauvegardes : elles doivent se trouver hors de la zone de défaillance de l'environnement de production, protégées par des identifiants que le site lui-même ne détient pas. Il s'agit là d'une contrainte de conception, et non d'un cadre applicable à l'ensemble du guide. Si vous mettez en place une architecture adéquate (hors site, identifiants distincts, immuable dans la mesure du possible), la surface d'attaque se réduit à un simple point.

La règle du 3-2-1, appliquée à WordPress

3 exemplaires, 2 supports, 1 hors site

La règle de sauvegarde « 3-2-1 » est une stratégie de stockage qui prévoit trois copies de vos données, stockées sur deux types de supports différents, dont au moins une copie conservée hors site. Elle est recommandée par la CISA et la communauté américaine de la cybersécurité, et constitue le point de départ de toute stratégie de stockage sérieuse.

Traduit dans le contexte de WordPress :

• Copie 1 : le site de production en ligne proprement dit. Il s'agit de votre site principal, et non d'une sauvegarde.
• Copie 2 : un instantané récent conservé par l'hébergeur (Kinsta, WP Engine, Pressable, Cloudways). Permet une restauration rapide, mais sur la même infrastructure que l'environnement de production.
• Copie 3 : une destination de stockage cryptée indépendante et hors site, gérée par vous-même ou par votre plateforme de gestion. Dans la mesure du possible, il convient de choisir un fournisseur différent, des identifiants différents et une zone géographique différente.

Dans le contexte de WordPress natif au cloud, l'expression « deux supports » désigne généralement deux backends de stockage distincts (un stockage objet et un stockage secondaire répliqué), et non pas une bande magnétique et un disque. L'objectif est d'assurer l'indépendance des domaines de défaillance.

Une architecture 3-2-1 concrète pour un portefeuille de 50 à 100 sites

À l'échelle du portefeuille, la structure ne change pas. Ce sont les coûts d'exploitation qui évoluent. La structure 3-2-1 répartie sur 50 à 100 sites se présente comme suit :

1. Conserver des instantanés par site, utilisés uniquement pour des restaurations rapides.
2. Une plateforme unique et centralisée couvrant tous les sites, avec des sauvegardes quotidiennes ou toutes les heures selon le type de site, une gestion centralisée des identifiants et des durées de conservation adaptées à chaque site.
3. Au moins deux fois par an, organiser un exercice de restauration par site
4. Un guide d'intervention que tout membre de l'équipe peut suivre sans avoir à consulter l'ingénieur en chef.

Sans centralisation, 50 tableaux de bord d'hôte multipliés par 50 tableaux de bord de plug-in multipliés par 50 comptes de stockage deviendraient ingérables avant même la fin de la première année.

RTO et RPO : les deux chiffres qui déterminent la fréquence de vos sauvegardes

Que signifient les termes RTO et RPO en termes simples ?

RTO (Recovery Time Objective) : délai dans lequel le site doit être remis en ligne après un incident. Si un site est hors service et que le RTO est d'une heure, tout le monde (vous, votre équipe, votre client) s'est mis d'accord pour que le site soit rétabli dans les 60 minutes.

RPO (Recovery Point Objective) : quantité de données que vous êtes prêt à perdre, exprimée en temps. Un RPO de 24 heures signifie que vous acceptez de perdre jusqu'à une journée de modifications. Un RPO d'une heure signifie que vous ne l'acceptez pas.

Le RTO détermine vos outils de restauration et la surveillance de la disponibilité. Le RPO détermine la fréquence de vos sauvegardes. Un RPO d'une heure avec des sauvegardes nocturnes est mathématiquement impossible, quelle que soit la qualité du plugin.

Correspondance entre les types de sites RTO/RPO et WordPress

Type de site	Objectif RTO	Objectif RPO	Fréquence	Fidélisation
Brochure statique	6 heures	24 heures	Quotidiennement	50 jours
Blog de contenu	4 heures	24 heures	Quotidiennement	50 jours
Site réservé aux membres	1 heure	6 heures	Toutes les 6 à 12 heures	50 jours
WooCommerce, faible volume	1 heure	1 heure	horaire	50 jours
WooCommerce, gros volumes	30 minutes	1 heure	À l'heure	50 jours
SaaS / application sur mesure	15 minutes	15 minutes	En continu / au niveau des blocs	90 jours et plus

Chaque ligne correspond à un modèle économique, et non à un paramètre de plugin. Remplissez la ligne pour chaque client avant de choisir un outil.

Méthodes de sauvegarde de WordPress (avec une analyse honnête des avantages et des inconvénients de chacune)

Sauvegardes au niveau de l'hôte

Une sauvegarde WordPress au niveau de l'hébergeur est un instantané côté serveur réalisé par l'hébergeur géré (Kinsta, WP Engine, Pressable, Cloudways, etc.) et stocké sur la même infrastructure que l'environnement de production. La durée de conservation est généralement de 7 à 14 jours, pouvant parfois aller jusqu'à 60 jours pour les formules haut de gamme.

Les sauvegardes sur l'hébergeur sont idéales pour effectuer une restauration rapide après un déploiement raté. Elles ne constituent toutefois pas une stratégie de sauvegarde à part entière. Si l'hébergeur suspend le compte, les instantanés sont également supprimés. La localisation des données dépend entièrement du choix de l'hébergeur. Les délais de conservation correspondent rarement aux engagements de votre contrat de niveau de service (SLA), et le stockage n'est pas à l'abri d'une panne de production.

Cela vous oblige également à tenir à jour une liste sécurisée des identifiants afin de pouvoir restaurer les sites web, ce qui rend le processus de restauration plus lent qu'avec les outils de gestion WordPress.

Sauvegardes via des plugins

Le marché des extensions est saturé et très concurrentiel. Voici un petit tour d'horizon en toute franchise :

• UpdraftPlus : l'option la plus installée. La page de comparaison des versions indique que les sauvegardes incrémentielles, le chiffrement et de nombreuses destinations hors site ne sont disponibles qu'avec la version Premium. Si vous n'avez pas souscrit à la version Premium, votre archive hors site est une copie en clair des données de production de votre client.
• BlogVault : une solution SaaS gérée et fiable, avec une tarification par site et un stockage hors site.
• Solid Backups : anciennement BackupBuddy, rebaptisé à la suite de la fusion entre iThemes, SolidWP et StellarWP. Bon à savoir si vous consultez d'anciennes critiques publiées sous l'ancien nom.
• Duplicator : largement utilisé pour les migrations, il est souvent utilisé comme outil de sauvegarde. Son point fort réside dans sa portabilité, et non dans sa résilience planifiée.

Les sauvegardes via plugin fonctionnent tant qu'elles ne rencontrent pas de problème. Lorsqu'elles échouent, cela est généralement dû à une limite de mémoire ou à un délai d'expiration, deux cas abordés ci-dessous. Si vous souhaitez une comparaison plus approfondie, consultez notre comparatif détaillé des plugins pour une analyse complète.

Sauvegardes manuelles via phpMyAdmin + SFTP

Une exportation via phpMyAdmin ainsi qu'un téléchargement via SFTP de /wp-content/ C'est le dernier recours à 2 heures du matin. Cela n'est pas viable à grande échelle, mais cela s'avère utile pour vérifier concrètement ce que votre « automatisation » a réellement remplacé.

Nous avons rédigé un article complet sur la manière d'effectuer une sauvegarde et une restauration manuelles.

Sauvegardes via SSH / WP-CLI

Scénarisé wp db export en plus rsync est une fonction de base fiable pour les pipelines personnalisés. WP-CLI db check est indispensable pour garantir la cohérence. Le prix à payer, c'est la gestion : vous devez vous occuper du script, de la tâche cron, du stockage, du chiffrement, de la conservation des données, des alertes et des outils de restauration.

Pour une agence, c'est un passe-temps à plein temps, pas un produit.

Sauvegardes sur plateforme gérée (SaaS)

C'est cette catégorie qui fait la différence à l'échelle du portefeuille. Les plateformes gérées effectuent la sauvegarde hors serveur, la stockent de manière indépendante et proposent un tableau de bord unique pour l'ensemble des sites clients. Exemples de noms :

• WP Umbrella: architecture de streaming, chiffrement AES natif, stockage dans l'UE conforme au RGPD, conservation des données pendant 50 jours, surveillance de l'intégrité des sauvegardes, tarification forfaitaire par site.
• BlogVault : architecture en streaming, offre SaaS gérée performante.
• VaultPress / Jetpack Backup : propriété d'Automattic et intégré à Jetpack. La volonté d'ancrer davantage les sites dans l'écosystème Jetpack est d'ordre structurel et mérite d'être signalée.

Compromis au niveau de la catégorie : vous troquez le contrôle direct contre un effet de levier opérationnel. À partir de 50 sites, l'effet de levier l'emporte à chaque fois.

Incrémental, différentiel ou complet : la réalité technique

Une sauvegarde complète copie tous les fichiers et toutes les lignes de la base de données à chaque fois. Une sauvegarde différentielle copie tout ce qui a été modifié depuis la dernière sauvegarde complète. Une sauvegarde incrémentielle ne copie que ce qui a été modifié depuis la dernière sauvegarde, quel que soit son type.

Les sauvegardes incrémentielles sont plus légères, moins coûteuses et plus rapides, mais elles introduisent une fragilité de la chaîne : si un maillon de la chaîne est corrompu, toutes les sauvegardes situées en aval deviennent inutilisables. C'est pourquoi les systèmes incrémentiels performants, tels que WP Umbrella , génèrent WP Umbrella une nouvelle sauvegarde complète et vérifient l'intégrité de la chaîne lors de l'écriture.

Un plugin qui propose l'option « incrémental » sous forme de case à cocher sans vérification en chaîne vous vend de la rapidité, pas de la sécurité.

À quelle fréquence faut-il sauvegarder WordPress ? Un cadre décisionnel

La fréquence à laquelle vous devez sauvegarder votre site WordPress dépend de votre RPO : quotidiennement pour les sites de présentation et de contenu, toutes les 12 heures pour les sites d'adhésion, toutes les heures pour les sites WooCommerce. Le tableau ci-dessous met en correspondance le type de site avec la fréquence, la durée de conservation et la méthode recommandée.

Type de site	Fréquence	Fidélisation	Méthode recommandée
Brochure statique	Quotidiennement	50 jours	Plateforme gérée au quotidien
Blog de contenu	Quotidiennement	50 jours	Plateforme gérée au quotidien
Adhésion	Deux fois par jour	50 jours	Plateforme gérée, module complémentaire « deux fois par jour »
WooCommerce	À l'heure	50 jours	Plateforme gérée, facturation à l'heure + instantanés de l'hôte
SaaS / application sur mesure	En continu / au niveau des blocs	plus de 90 jours	Infrastructure sur mesure + plateforme gérée pour la couche applicative

Pourquoi la sauvegarde nocturne ne suffit pas pour WooCommerce

Une sauvegarde nocturne de WooCommerce signifie que si le site est piraté à 23 h 30 et que le problème est détecté à 9 h, vous perdez toutes les commandes passées au cours d'une journée complète d'activité, ainsi que les comptes clients et les mouvements de stock. Reconstituer tout cela à partir des journaux Stripe, des exportations des prestataires de livraison et des e-mails de confirmation représente, en réalité, une semaine de travail pour une agence, même avec Claude Code.

Une sauvegarde toutes les heures limite les pertes à une heure de commandes. Le tout peut être rattrapé en l'espace d'un après-midi.

Si vous souhaitez effectuer des sauvegardes toutes les heures sur un portefeuille de 50 sites sans avoir à reconfigurer vous-même votre infrastructure, c'est exactement WP Umbrella cela WP Umbrella nous avons créé WP Umbrella . Commencez votre essai gratuit de 14 jours. Aucune carte bancaire requise.

Technologies de sauvegarde : traitement en continu ou par lots (pourquoi la plupart des sauvegardes échouent au moment où on en a le plus besoin)

Les sauvegardes en continu transmettent les modifications de fichiers et les blocs de base de données hors serveur par petits paquets, sans créer d'archive sur le serveur source. Les sauvegardes par lots compressent l'intégralité du site dans un fichier ZIP sur le serveur source, puis transfèrent l'archive finale vers un stockage hors site. Le streaming élimine les limites de mémoire PHP et de temps d'exécution qui empêchent le traitement par lots à grande échelle.

Il s'agit de la partie principale de ce guide.

Architecture par lots (ZIP) : ce que font la plupart des plugins

UpdraftPlus, BackWPup, Duplicator, ModularDS et Solid Backups reposent tous sur le même principe de base. Ces plugins compressent l'intégralité du site dans une archive ZIP sur votre propre serveur, puis transfèrent l'archive finale vers une destination hors site.

Cela nécessite suffisamment de mémoire vive pour gérer les tampons de compression, suffisamment d'espace disque pour stocker l'archive en cours de création, et suffisamment de temps d'exécution PHP pour terminer l'opération avant que le processus ne soit interrompu. Sur un hébergement mutualisé, dans les boutiques WooCommerce ou avec des bibliothèques multimédias de plus de 5 Go, l'une de ces trois ressources vient à manquer. Le processus PHP est interrompu, l'archive est corrompue ou incomplète, et le journal de sauvegarde indique soit que l'opération a réussi, soit une erreur vague que personne ne lit.

L'architecture par lots laisse également des fichiers ZIP sur le serveur entre deux exécutions. Ceux-ci s'accumulent, occupent de l'espace disque et finissent parfois par être accessibles au public dans /wp-content/uploads/, ce qui pose un problème en soi.

Architecture de streaming : le rôle des plateformes gérées

WP Umbrella, BlogVault et ManageWP transfèrent les modifications de fichiers et les blocs de base de données hors du serveur, par petits morceaux. Aucune archive n'est créée sur le serveur source. Aucun processus ne doit s'achever avant la fin de la fenêtre d'exécution de PHP. Il n'y a pas de limite de mémoire à atteindre. Il ne reste aucun fichier.

Les mises à jour incrémentielles sont calculées au niveau des blocs ; ainsi, seule la partie modifiée d'un répertoire de 4 Go est transmise, et non l'intégralité de celui-ci. La vérification peut s'effectuer côté destinataire, indépendamment de l'état du serveur source.

Pourquoi cela détermine la fiabilité à grande échelle

Une méthode de sauvegarde qui échoue systématiquement en cours d'exécution sur un site de 5 Go n'est pas une stratégie, c'est un vœu pieux. Sur un seul site, la différence est insignifiante. Mais sur un portefeuille de 50 sites, cela se traduit par le nombre de fois où l'on est réveillé par une alerte indiquant que « la sauvegarde de la nuit dernière n'a pas abouti ». Sur 500 sites, le modèle par lots devient intenable sur le plan opérationnel.

C'est pourquoi les plateformes gérées peuvent proposer la « sauvegarde en continu » dans le cadre d'un accord de niveau de service (SLA) plutôt que comme une simple probabilité. L'architecture élimine les types de défaillances auxquels les sauvegardes par lots sont constamment confrontées.

Hors site, cryptée, indépendante : les trois caractéristiques qui font d'une sauvegarde un outil indispensable en cas de crise

Immuabilité, gestion des versions et isolation physique

Une sauvegarde à laquelle n'importe quel élément du site de votre client peut accéder et supprimer ne résistera pas à un incident réel. Trois caractéristiques pratiques garantissent la sécurité de la copie stockée :

• Stockage à écriture unique (immuabilité) : une fois qu'une sauvegarde a été enregistrée, elle ne peut être ni supprimée ni écrasée pendant une période de conservation définie (par exemple 50 jours), même par le système qui l'a créée. Si un pirate s'empare des identifiants utilisés par votre site pour télécharger les sauvegardes, il ne pourra pas pour autant supprimer ce qui s'y trouve déjà.
• Historique des versions (gestion des versions) : chaque modification apportée à un fichier enregistré crée une nouvelle version. « Supprimer » signifie « masquer la version actuelle », et non « détruire les données ». Vous pouvez toujours revenir à la version de mardi dernier, même si quelqu'un a tenté d'effacer le stockage ce matin.
• Compte distinct (isolation physique) : le stockage des sauvegardes est protégé par des identifiants et se trouve sur un réseau auquel votre installation WordPress n'a pas accès. Votre site dispose d'une clé permettant d'écrire les sauvegardes ; seul un utilisateur disposant d'un identifiant distinct peut les supprimer. Même en cas de compromission totale du site, les copies stockées restent inaccessibles.

Dans le cas des piles à configurer soi-même, il s'agit de fonctionnalités que vous configurez vous-même chez le fournisseur de stockage. Sur les plateformes gérées, l'opérateur s'en est déjà chargé : vous bénéficiez de la garantie, vous n'avez pas à la mettre en place. C'est principalement pour cette raison qu'il vaut la peine de payer pour un service « géré » à l'échelle d'un portefeuille.

Que signifie « chiffrement au repos » et qui propose réellement cette solution ?

Votre sauvegarde est une copie intégrale du site de votre client. Chaque e-mail client, chaque commande, chaque mot de passe, chaque fichier téléchargé.

Cette copie doit être sécurisée à deux niveaux : pendant son transfert vers le serveur de stockage et pendant qu'elle y est stockée. Si l'une de ces étapes n'est pas sécurisée et qu'une copie tombe entre de mauvaises mains, la personne qui en dispose pourra lire tout le contenu du site de votre client sans jamais avoir à accéder directement au site lui-même.

Ce mécanisme s'appelle le chiffrement. Voici deux questions à poser à tout outil de sauvegarde :

1. La sauvegarde est-elle verrouillée pendant son téléchargement ? Ainsi, quiconque surveille la connexion ne voit rien d'utile.
2. La sauvegarde est-elle verrouillée une fois stockée ? Ainsi, si le fournisseur de stockage subit une intrusion ou si un disque dur venait à disparaître, le fichier serait illisible.

La réponse devrait être « oui » dans les deux cas pour tout site qui stocke des données clients. Il y a toutefois un bémol à connaître : pratiquement aucun produit de sauvegarde ne vous fournit une copie que vous seul pouvez déverrouiller.

Le fournisseur de sauvegarde détient lui aussi toujours une clé. Cela signifie que lui-même, ou toute personne qui parviendrait à s'introduire dans ses systèmes, pourrait en théorie consulter vos données. C'est le compromis que vous acceptez en optant pour un service géré plutôt que de gérer votre propre stockage, et pour la plupart des agences, cela en vaut la peine, car les données sont tout de même mieux protégées dans un service SaaS géré qui consacre du temps et de l'argent à la sécurité, plutôt que dans une solution auto-hébergée par une personne ayant des connaissances limitées en matière de sécurité.

Un examen impartial des options possibles :

• UpdraftPlus : le chiffrement de la base de données est une fonctionnalité Premium qui n'est pas incluse dans la version gratuite du plugin. Si vous utilisez la version gratuite d'UpdraftPlus pour transférer vos sauvegardes vers Dropbox ou Google Drive, ces fichiers y sont stockés en texte clair.
• Sauvegarde VaultPress / Jetpack : le chiffrement au repos est mentionné dans la documentation du service.
• BlogVault : chiffrement au repos et en transit.
• WP Umbrella: chiffrement au repos, chiffrement en transit, stockage dans l'UE, aucune formule payante requise pour l'activer.

En pratique, cela signifie que si la fonctionnalité de chiffrement de votre plugin est réservée à une formule payante et que vous ne l'avez jamais achetée, votre sauvegarde hors site n'est qu'une copie en clair du site de votre client : e-mails des clients, mots de passe hachés, détails des commandes, etc.

Si cette copie venait à être divulguée, vous seriez tenu, en vertu du RGPD, d'en informer toutes les personnes concernées. C'est une après-midi dont vous vous passeriez bien.

Vérifiez vos sauvegardes, sinon autant ne pas en faire

Pour vérifier une sauvegarde WordPress, il faut la télécharger ou la restaurer dans un environnement de test vierge, effectuer des contrôles d'intégrité sur la base de données et les fichiers du cœur du système, puis tester les chemins critiques. Une sauvegarde qui n'a jamais été restaurée n'est qu'un espoir, pas une véritable sauvegarde.

L'exercice de restauration

La procédure de restauration de WordPress est un processus de vérification en 8 étapes :

1. Mettez en place un environnement de test vierge (base de données vide, configuration PHP par défaut).
2. Récupérez la sauvegarde la plus récente à partir de la destination hors site.
3. Restaurer les fichiers et la base de données dans l'environnement de test.
4. Courir wp db check pour garantir l'intégrité de la table.
5. Courir wp core verify-checksums pour vérifier que les fichiers du cœur de WordPress correspondent à la distribution officielle.
6. Testez les chemins critiques : connexion, paiement, envoi de formulaires, recherche.
7. Consignez le temps écoulé entre le moment où la restauration s'est avérée nécessaire et celui où le système a été remis en service.
8. Consignez le résultat par rapport à l'objectif RTO du site.

Répartissez les opérations de forage sur l'ensemble du portefeuille de manière à ce que chaque site soit foré dans un délai de 30 à 60 jours. Avec 50 sites, cela représente environ deux forages par jour ouvré, une tâche automatisable sur n'importe quelle plateforme gérée dotée d'une API de restauration.

Ce qu'un journal de sauvegarde « réussi » ne prouve pas

Une entrée de journal de couleur verte prouve que le processus de sauvegarde s'est terminé sans exception non gérée. Elle ne prouve pas que l'archive soit lisible. Elle ne prouve pas que le dump de la base de données soit cohérent. Elle ne prouve pas que le répertoire « uploads » soit complet. Elle ne prouve pas que le stockage de destination contienne toujours l'objet. La seule chose qui prouve qu'une sauvegarde fonctionne, c'est de la restaurer.

Chez WP Umbrella effectuons quotidiennement des contrôles d'intégrité sur la base de données et les dossiers afin de garantir la fiabilité de votre sauvegarde.

Délais de restauration réalistes

Les chiffres à retenir :

• Importation via phpMyAdmin d'une base de données de 2 Go : 20 à 60 minutes, en supposant que l'hôte max_execution_time et upload_max_filesize Ne fermez pas le processus au préalable.
• Restauration d'un site de 5 Go avec UpdraftPlus : entre 30 et 90 minutes dans le meilleur des cas, avec de fréquentes défaillances sur un hébergement mutualisé.
• Restauration en un clic sur la plateforme gérée : 5 à 15 minutes, en fonction de la taille du réseau et de la base de données.
• Restauration de l'hôte à partir d'un instantané : 2 à 10 minutes, option la plus rapide mais l'hôte reste bloqué.

Définissez votre SLA de restauration en vous basant sur la valeur médiane de ces fourchettes, et non sur le scénario le plus favorable.

Résolution des trois problèmes qui compromettent la plupart des sauvegardes WordPress

Limites de mémoire et délais d'expiration en PHP

Les sauvegardes par lots échouent le plus souvent parce que PHP a manqué de mémoire ou de temps. Augmenter WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT dans wp-config.php aide jusqu'à ce que l'hôte php.ini le plafond entre en jeu.

Si votre sauvegarde nécessite 512 Mo pour s'exécuter et que la limite maximale de l'hébergeur est de 256 Mo, aucune modification de la configuration de WordPress ne pourra y remédier. La solution structurelle réside dans l'architecture de streaming, qui ne nécessite pas que le serveur source conserve l'archive en mémoire.

Pannes sur les sites de grande taille (bibliothèques multimédias de plus de 20 Go, sites multisites)

Dès que le volume des fichiers à sauvegarder dépasse 20 Go, les sauvegardes par lots échouent presque systématiquement. Dans le cas d'un site multisite, ce volume est multiplié par le nombre de sous-sites. Pour remédier à cela, on peut soit opter pour des sauvegardes incrémentielles au niveau des fichiers, de type rsync (via WP-CLI + rsync ou une plateforme gérée), soit exclure délibérément les fichiers multimédias volumineux de la sauvegarde WordPress et les sauvegarder séparément, par exemple sur un serveur d'origine CDN, un compartiment S3 avec gestion des versions ou une archive multimédia dédiée.

Cohérence de la base de données sur les sites en production

Un naïf mysqldump sur une base de données WooCommerce en production, on obtiendra des tables correspondant à différents moments. Les commandes de la table A, les enregistrements de paiement de la table B et les fiches clients de la table C peuvent présenter des divergences.

La solution est mysqldump --single-transaction pour les tables InnoDB, qui effectue un instantané cohérent au cours d'une seule transaction. Toute méthode de sauvegarde qui ne respecte pas ce principe sur un site WooCommerce à fort trafic entraîne, sans que l'on s'en rende compte, la corruption des bases de données.

Quand le correctif est à l'origine du problème : le retour en arrière de Really Simple Security

En novembre 2024, Wordfence a signalé une faille permettant de contourner l'authentification dans Really Simple Security, qui a touché 4 millions d'installations. WordPress.org a déployé une mise à jour automatique obligatoire afin de remédier au problème à grande échelle. La plupart des sites ont été corrigés sans encombre. Certains sites, notamment ceux utilisant des flux d'authentification à deux facteurs (2FA) personnalisés ou des plugins de sécurité s'appuyant sur les mêmes filtres, ont rencontré des problèmes de connexion et ont dû revenir à une version antérieure.

Voici le scénario de sauvegarde souvent négligé.

Ce n'est pas un pirate qui crypte votre site.

Il s'agit d'un correctif légitime et nécessaire qui s'est trouvé entrer en conflit avec du code personnalisé un vendredi après-midi.

La seule solution permettant de rétablir le service dans les délais prévus par le SLA du client consiste à utiliser une sauvegarde effectuée avant la mise à jour, datant de quelques heures, qui a été vérifiée et qui peut être restaurée sans avoir à contacter l'hébergeur.

La solution préconisée par les agences face à ce type de situation consiste à effectuer des sauvegardes avant la mise à jour, accompagnées d'un contrôle de régression visuelle. C'est également la raison pour laquelle la fréquence de vos sauvegardes ne peut pas se limiter à une fois par nuit pour tout site dont vous ne pouvez pas vous permettre qu'il soit indisponible pendant dix heures, le temps d'attendre la prochaine sauvegarde programmée.

Le RGPD, la localisation des données et le lieu de stockage légal de vos sauvegardes

Schrems II et l'importance du lieu de stockage

L'arrêt Schrems II, rendu en 2020 par la CJUE, a invalidé le bouclier de protection des données UE-États-Unis et impose des mesures supplémentaires pour les données à caractère personnel transférées hors de l'UE lorsque le pays de destination n'offre pas un niveau de protection équivalent. Pour les agences WordPress ayant des clients dans l'UE, le fait de sauvegarder leurs données auprès d'un fournisseur dont le siège social se trouve aux États-Unis sans ces mesures constitue un risque en matière de conformité. Et ce, même si les données sont hébergées sur des serveurs situés dans l'UE et appartenant à ce fournisseur.

Pour une agence de l'UE, la position la plus défendable consiste à faire appel à un prestataire de services de sauvegarde établi dans l'UE, disposant d'un espace de stockage dans l'UE et proposant des contrats qui excluent le transit des données à caractère personnel par des sous-traitants américains. Il est facile d'utiliser l'expression « conforme au RGPD » à des fins marketing. C'est la chaîne sous-jacente entre le responsable du traitement et le sous-traitant qui importe réellement.

Droit à l'effacement (article 17) et conservation des sauvegardes

L'article 17 du RGPD confère aux personnes concernées le droit de faire effacer leurs données à caractère personnel. Cela entre immédiatement en conflit avec les sauvegardes immuables et à longue durée de conservation.

La position pragmatique, acceptée par les autorités de contrôle, est que l'effacement s'applique immédiatement aux systèmes en service, tandis que les délais de conservation des sauvegardes sont documentés, limités dans le temps et font l'objet d'un effacement selon leur propre cycle. Les termes de votre plan de gestion doivent mentionner explicitement le délai de conservation des sauvegardes. Une durée de 50 jours constitue un compromis défendable entre les obligations de restauration et d'effacement.

Les sauvegardes à l'échelle d'une agence : un exemple concret

Le guide pratique pour 50 sites

Prenons l'exemple d'un portefeuille de 50 sites : 30 sites de présentation ou de contenu, 15 sites d'adhésion et 5 sites WooCommerce à fort trafic.

• Fréquence par niveau : quotidienne pour les brochures et le contenu, deux fois par jour pour les adhésions, toutes les heures pour les sites WooCommerce à fort trafic.
• Conservation par niveaux : 50 jours.
• Objectif hors site : plateforme unique gérée, stockage au sein de l'UE, données chiffrées au repos selon la norme AES, protocole TLS pour les données en transit.
• Rapports destinés aux clients : fichier PDF mensuel en marque blanche comprenant le taux de réussite des sauvegardes et des informations sur l'emplacement de stockage des sauvegardes.

Il s'agit d'une infrastructure axée sur l'agence, et non d'un plugin de sauvegarde par site.

Quels changements sur plus de 200 sites ?

Avec 200 sites, ce n’est pas la sauvegarde qui fait la différence, mais l’équipe. La gestion centralisée des identifiants n’est plus un simple atout. L’accès des équipes basé sur les rôles devient une obligation légale dès lors que vous intégrez de nouveaux techniciens. Dans Bitwarden, l’accès administrateur en un clic remplace les identifiants partagés. Les rapports clients en marque blanche cessent d’être un facteur de différenciation pour devenir un levier de fidélisation. La plupart des agences atteignent ce point d’inflexion entre 120 et 180 sites.

WP Umbrella en matière d'infrastructure de sauvegarde

WP Umbrella le leader incontesté en matière de fiabilité des sauvegardes WordPress grâce à son architecture, et non à son marketing. La plateforme utilise des sauvegardes en continu : aucune création d'archives côté serveur, rien ne reste sur le serveur de votre client entre deux cycles, aucune limite de mémoire à atteindre, aucun délai d'expiration PHP à respecter.

En 2025, nous avons effectué plus de 8 500 000 sauvegardes sur plus de 60 000 sites. Ce chiffre n'est pas une simple affirmation, mais une référence opérationnelle.

En plus de cette architecture :

• Sauvegardes incrémentielles chiffrées en AES intégrées, sans frais supplémentaires.
• Des forfaits journaliers, hebdomadaires et mensuels, ainsi qu'une option horaire pour les sites à forte activité d'écriture.
• Une durée de conservation de 50 jours pour tous les forfaits.
• Restauration en un clic des fichiers et de la base de données.
• Stockage européen conforme au RGPD, basé en France.
• Tableau de bord multi-sites avec accès aux équipes basé sur les rôles.
• Tarif forfaitaire par site.

Ce prix forfaitaire par site comprend les mises à jour, la surveillance de la disponibilité, la détection des vulnérabilités et les rapports en marque blanche ; la solution de sauvegarde s'inscrit donc dans une infrastructure globale de gestion des services, et non pas comme un fournisseur distinct.