En bref
Avant une mise à jour importante, restaurez une copie récente de WordPress dans un environnement séparé. Vérifiez que les pages, les médias et les fonctions indispensables marchent sur cette copie. Puis identifiez ce qui serait perdu entre la date de la sauvegarde et le moment du retour arrière. Pour une boutique, ce dernier point peut changer la décision.
1. Définir ce qu’il faut pouvoir récupérer
Écrivez d’abord ce que votre site doit continuer à faire. Un cabinet reçoit des demandes via un formulaire. Un hôtel renvoie vers un moteur de réservation. Une boutique enregistre des commandes et leurs paiements. Même si les trois utilisent WordPress, la vérification finale sera différente. Choisissez deux ou trois parcours représentatifs et notez pour chacun le résultat attendu, du point de vue du visiteur et du côté de l’équipe.
Recensez ensuite ce qui change quotidiennement. Les pages peuvent rester stables pendant des semaines alors que les demandes, les inscriptions ou les comptes clients évoluent plusieurs fois par jour. La date d’une copie indique jusqu’où elle peut vous ramener. Elle ne suffit pas à dire si ce retour en arrière est acceptable. En cas de doute, prenez le test avant mise à jour et utilisez les points bloquants comme ordre du jour avec la personne qui maintient votre site.
2. Vérifier que la copie couvre les fichiers et les données
Une sauvegarde WordPress associe généralement les fichiers du site et la base de données. Les fichiers incluent entre autres le thème, les extensions et les médias téléversés. La base contient notamment les pages, les réglages et les données enregistrées par certaines extensions. L’emplacement exact varie selon l’hébergeur et les modules utilisés. Un formulaire peut conserver ses demandes dans WordPress, les transmettre à un outil externe ou simplement déclencher un email.
Repérez qui contrôle l’accès à la sauvegarde. Si vous devez attendre l’ancienne agence pour ouvrir un compte d’hébergement, demandez les accès et vérifiez-les avant d’intervenir. Vérifiez aussi que la récupération reste possible si le compte ou l’espace de production est indisponible. Conservez la référence de l’archive, son horodatage et ce qu’elle contient. La documentation WordPress sur les sauvegardes détaille la distinction entre fichiers et base.
3. Restaurer dans un environnement séparé
Prévoyez une copie hors production et réservez son accès aux personnes qui effectuent le test. Avant d’ouvrir la copie, neutralisez les envois d’emails et les intégrations susceptibles de créer de vraies commandes, de modifier des stocks ou de relancer des contacts. Utilisez des comptes de test et les environnements de simulation prévus par les prestataires. Lorsque c’est possible, travaillez avec des données de test ou des données personnelles réduites au strict nécessaire.
Reconstituez le site à partir de l’archive choisie. L’objectif est de vérifier le chemin réel, depuis l’accès aux fichiers jusqu’à l’ouverture du site restauré. Si l’archive est protégée, vérifiez que l’équipe sait où obtenir le secret de récupération sans l’inscrire dans le compte rendu. Vérifiez ensuite la connexion au tableau de bord, les permaliens et les fichiers médias. Notez les difficultés rencontrées. Par exemple, si les liens des documents pointent encore vers la production, le test ne prouve pas que les fichiers ont été récupérés.
- Copie complète accessible ? Sinon, récupérer ou créer une sauvegarde avant de planifier.
- Copie restaurée et vérifiée ? Sinon, résoudre l’écart sur la copie séparée.
- Données récentes et reprise prévues ? Si oui, choisir un créneau, appliquer la mise à jour et rejouer les parcours.
4. Rejouer les parcours qui comptent
Commencez par un parcours public sur mobile, puis passez au tableau de bord. Sur un site vitrine, ouvrez la page de contact, soumettez une demande fictive et confirmez qu’elle apparaît là où l’équipe la retrouve. Si vous utilisez un outil comme Form Monitor, comparez ce que dit le journal avec ce que vous avez reçu. Un journal renseigne sur une étape du chemin. Il ne prouve pas que la boîte du destinataire a bien reçu le message.
| Parcours | Contrôle à faire | Trace utile |
|---|---|---|
| Pages et médias | Ouvrir une page, une image et un PDF depuis la copie. | Adresse de test et éléments effectivement chargés. |
| Demande de contact | Envoyer une demande fictive vers un destinataire de test. | Entrée du journal et réception vérifiée. |
| Commande | Suivre le panier et un paiement de simulation jusqu’à la confirmation. | Référence du test et état de la commande. |
| Administration | Se connecter et modifier un brouillon sur la copie. | Compte de rôle adapté et action terminée. |
Sur une boutique, contrôlez aussi la fiche produit, les variantes et le calcul des frais de livraison. Ajoutez au panier un produit dont le stock est connu dans l’environnement de test. Suivez la commande jusqu’à la confirmation, puis comparez le statut enregistré dans WordPress et celui du prestataire de paiement de test. Un parcours qui s’interrompt à l’affichage du panier n’a pas encore vérifié le fonctionnement de la vente.
5. Décider quand revenir en arrière
Prenez un cas fictif. Une boutique effectue une sauvegarde avant l’ouverture. Plusieurs commandes arrivent ensuite. L’extension de paiement est mise à jour dans l’après-midi et le paiement devient indisponible. Restaurer immédiatement la sauvegarde complète du matin peut remettre en place l’ancienne version, tout en ramenant la base à un état antérieur aux ventes. Les clients peuvent avoir été débités alors que les commandes ne figurent plus dans WordPress. Le suivi des paiements et la réconciliation des commandes doivent alors faire partie de la décision.
Avant de remplacer une base, identifiez les données intervenues depuis la copie et les opérations possibles avec votre hébergeur ou votre prestataire. Selon le changement, il peut être préférable de corriger le composant en cause ou de rétablir une version précise. Un retour ciblé peut aussi être incompatible avec une migration de base. Faites déterminer le périmètre par la personne qui a accès au journal des changements et à l’environnement de test. Les prestations de suivi et de sauvegarde doivent préciser qui prend cette décision et qui l’exécute.
Que mettre dans le compte rendu ?
Notez la sauvegarde utilisée, la date du test, les résultats attendus et observés, les difficultés, la personne responsable et l’action suivante. Conservez une distinction entre « testé », « échec » et « à vérifier ». Ajoutez la durée réellement constatée si vous l’avez mesurée, en précisant qu’elle correspond à la copie et aux conditions de cet essai. Reprenez cette fiche après un changement d’hébergeur, une évolution du parcours de commande ou une modification de la manière dont vos sauvegardes sont produites.
Si vous suivez aussi la vitesse, conservez un relevé de la même URL sur le même appareil avant et après. L’outil Performance permet de retrouver ce comparatif dans le navigateur. Pour organiser le reste des vérifications et garder une trace des actions, consultez l’exemple de suivi WordPress ou la page maintenance web.