Commencer par les deux dates
Une sauvegarde de lundi contient la version saine de votre accueil. Mardi, la boutique a reçu des commandes et l’équipe a publié un article. Mercredi, vous découvrez que l’accueil a été écrasé. Si vous remettez en ligne la base de lundi, le visiteur retrouve l’ancienne page, mais les commandes et l’article arrivés ensuite disparaissent de la copie restaurée. Une commande plus ancienne peut aussi revenir à un statut dépassé, même si elle figure toujours dans la liste.
Appelez T0 l’heure exacte du point de sauvegarde et T1 l’heure de la capture de l’état actuel. Utilisez le même fuseau pour les exports, l’historique éditorial et les systèmes externes, avec la date et le décalage horaire dans vos notes. Si le panneau indique seulement « lundi », ouvrez les détails de l’archive et vérifiez l’heure de la base ainsi que celle des fichiers. Une archive générée à 02 h 00 et une base capturée à 01 h 47 peuvent correspondre à deux états différents.
Notez ensuite le premier symptôme connu et l’objet à récupérer. Par exemple, « le contenu de la page Accueil au lundi 02 h, avec le modèle, l’URL et les nouvelles commandes de mercredi ». Si l’administration répond et qu’une seule page est touchée, une révision de cette page ou une récupération ciblée sur copie suffit souvent. Si des données essentielles sont absentes dans plusieurs parties du site, vous aurez besoin d’une restauration plus large et d’un relevé des écritures à récupérer.
Sauvegarder ce qui existe aujourd’hui
Dans le panneau d’hébergement ou l’outil de sauvegarde déjà utilisé, créez un nouveau point à partir du site actuel avant d’essayer l’archive ancienne. Gardez les deux points sous des noms explicites, avec leur heure, leur fuseau et l’adresse de leur environnement. Pour WordPress auto-hébergé, vérifiez que vous avez la base complète et les fichiers nécessaires, dont les médias, les versions de thèmes et d’extensions ainsi que les éléments de configuration utiles à la reconstruction. Si les images ou les documents sont stockés à distance, vérifiez comment leurs objets et versions peuvent être récupérés et quels accès permettent de les lire depuis une copie. Sur WordPress.com, consultez les fonctions de sauvegarde et de restauration disponibles pour le site avant de choisir un point.
Avant de lancer la capture, notez si le site accepte encore des écritures. Une commande peut arriver pendant que les fichiers sont copiés. Suivez la méthode de capture cohérente proposée par l’hébergeur. Pour une boutique active, convenez avec l’équipe d’un bref gel des écritures si la méthode l’exige. Pendant une répétition où la boutique reste ouverte, traitez la capture comme provisoire et prévoyez un relevé final des écritures arrivées après T1.
Contrôlez l’accès à l’archive et la capacité à la restaurer ailleurs. Donnez à la capture actuelle une durée de conservation qui couvre le diagnostic et la vérification après reprise. Un export XML effectué dans Outils → Exporter peut compléter le relevé des contenus. Une archive complète reste nécessaire pour retrouver ensemble les données et les fichiers dont dépend le site.
Préparer deux copies qui ne reçoivent aucune écriture réelle
Créez deux environnements séparés de la production et l’un de l’autre. Restaurez T0 dans le premier et T1 dans le second. Dans le panneau ou l’assistant, contrôlez l’adresse et la base de destination avant de confirmer. Les deux adresses doivent ouvrir des installations différentes. Laissez les archives originales disponibles pour repartir de zéro si un essai a modifié une copie. Restreignez les accès à ces environnements, car une base de boutique peut contenir des coordonnées et un historique d’achats.
Avant le premier démarrage, neutralisez les sorties et entrées qui pourraient interagir avec la production. Sur l’environnement de test, coupez les courriels sortants et les tâches qui envoient des données. Utilisez des identifiants de paiement de test ou désactivez la passerelle et bloquez les appels sortants vers les intégrations réelles. Vérifiez les points de réception des webhooks, le logiciel de préparation des colis et les tâches programmées. Une préproduction protégée contre les visiteurs peut encore déclencher une action vers un autre service.
Sur chacune, ouvrez la page concernée en navigation privée et la liste des commandes dans l’administration si WooCommerce est installé. Relevez un repère propre à chaque point, comme le début de la page et le statut d’une commande. Si les deux copies montrent les mêmes données alors que la période est connue pour avoir été active, contrôlez d’abord la connexion à la base et l’adresse de chaque copie avant de conclure que l’archive ne contient rien d’utile.
Faire l’inventaire des créations et des modifications
Sur la copie actuelle, ouvrez Articles → Tous les articles, puis Pages → Toutes les pages. Repérez les contenus ajoutés depuis T0, mais aussi les contenus plus anciens qui ont été corrigés, dépubliés, programmés ou mis à la corbeille. Pour chaque objet à garder, relevez son type, son titre, son URL ou son identifiant, son état, et la modification à retrouver. Incluez les images ajoutées, les légendes, les fichiers liés, le modèle et les champs gérés par une extension si la page s’appuie dessus. Un article programmé peut être absent du site public tout en comptant dans la reprise.
Dans WooCommerce → Commandes, relevez les nouvelles commandes sur l’intervalle. Vérifiez aussi les commandes déjà présentes à T0 et modifiées depuis. Cherchez, selon l’activité, les paiements confirmés, remboursements, annulations, changements d’adresse et expéditions. Une sélection sur la date de création ne montre pas toutes ces transitions. Appuyez-vous sur les notes de commande et les événements de la passerelle ou du logiciel d’expédition pour repérer les commandes à contrôler individuellement.
Pour chacune, conservez dans un espace à accès limité le numéro affiché, la référence de transaction si elle existe, la date, le total et la devise, le statut attendu, et ce qui a déjà été fait côté paiement ou expédition. Faites de même pour les nouvelles inscriptions ou les formulaires si leur extension stocke les réponses dans WordPress. Identifiez le responsable de chaque vérification. Deux copies peuvent utiliser le même identifiant numérique pour des objets différents après une reprise, donc confirmez les références et le contexte avant tout rapprochement.
Récupérer une page dans la copie actuelle
Cette méthode convient si le site actuel reste utilisable et si l’ancienne copie vous donne l’élément sain. Elle nécessite l’accès aux deux environnements et le droit de modifier le contenu sur la copie actuelle. Pour une page éditoriale, ouvrez Pages → Toutes les pages puis la page touchée. Si son historique local contient la bonne version, ouvrez Révisions dans l’éditeur, comparez les versions et choisissez celle à rétablir. S’il faut conserver des ajouts réalisés sur la même page depuis cette révision, récupérez uniquement les blocs concernés depuis la copie ancienne.
Dans l’exemple de l’accueil, partez d’une nouvelle copie de T1. Ouvrez l’ancienne page et copiez les blocs sains dans l’éditeur de la page existante du candidat. Contrôlez les liens, les médias, les paramètres des blocs réutilisables et les champs de l’extension de mise en page avant d’enregistrer. En gardant la page existante, vous gardez son emplacement dans le site. Vérifiez néanmoins son URL, son modèle et les réglages d’accueil dans Réglages → Lecture si l’ancienne version affiche une autre page. Rouvrez également l’article publié après T0. Il doit être visible au même endroit qu’avant.
Si l’essai échoue, revenez à la révision prise avant la correction ou recréez le candidat à partir de T1. Après validation, répétez le changement ciblé dans la page du site actuel, après une dernière vérification de son état. Évitez de remettre en ligne la base du candidat si le site a reçu des écritures depuis la capture. En cas d’échec sur le site public, annulez la modification sur la seule page concernée avec le point de retour identifié lors de l’essai.
Lire les trois résultats de la répétition
Lors d’un essai local sur WordPress et WooCommerce avec HPOS actif, la sauvegarde T0 contenait un accueil sain et une commande fictive de 12,50 € au statut En attente de paiement. Après T0, l’accueil a été endommagé, un article a été publié, une commande de 23,40 € a été créée et la première commande est passée En attente. Les deux statuts WooCommerce correspondent respectivement à pending et on-hold dans les données de cet essai.
La copie restaurée depuis T0 a retrouvé l’accueil sain. La commande de 23,40 € et l’article récent y étaient absents. La commande de 12,50 € s’y trouvait toujours, avec son ancien statut. Dans une copie séparée de T1, la mise à jour du seul contenu de l’accueil a donné le même accueil sain, avec l’article et la nouvelle commande toujours présents. La première commande a conservé son statut plus récent. L’état courant utilisé comme source est resté identique sur ces points de contrôle.
Vous pouvez reproduire la comparaison avec une page, un article et des commandes de démonstration sur un environnement isolé. Relevez pour chaque état le début de l’accueil, l’URL de l’article, puis la référence, le montant et le statut des deux commandes. Commencez par vérifier vos résultats sur les deux copies, puis conservez la même liste pour le candidat. Si un résultat change sans que vous l’ayez prévu, reprenez l’essai depuis T1 avant d’intervenir sur le site public. Dans l’essai décrit ici, les contrôles ont été exécutés avec les API locales, sans paiement ni import de commandes.
Répéter une restauration complète si le périmètre l’exige
Envisagez cette voie si plusieurs composants essentiels sont perdus et si vous avez vérifié que T0 contient un site cohérent. Il vous faut l’accès à l’outil de restauration, la possibilité de suspendre les écritures et des personnes qui savent vérifier les commandes et les intégrations. Sur un candidat restauré depuis T0, établissez d’abord la liste des données que vous savez remettre avec une méthode testable. Pour un petit nombre de contenus, créez ou remettez à jour les pages depuis l’éditeur. Pour un lot éditorial, utilisez un export WordPress adapté au périmètre et essayez l’import dans Outils → Importer → WordPress. Si vous retrouvez un contenu déjà présent, décidez lequel garder avant de répéter l’import.
Pour les commandes, demandez à l’éditeur de l’outil de sauvegarde, de transfert ou d’import si la procédure sait reprendre votre mode de stockage et vos extensions de paiement, de facturation ou d’abonnement. Dans WooCommerce, consultez WooCommerce → Réglages → Avancé → Fonctionnalités pour identifier le stockage utilisé. Avec HPOS, WooCommerce peut utiliser ses tables dédiées comme stockage de référence, tandis que le mode de compatibilité entretient une autre représentation. Évitez de copier des tables de commandes entre deux bases. Les commandes doivent rester associées à leurs lignes, notes, références et objets liés, avec les relations attendues par les extensions.
Essayez la procédure prévue sur un nouveau candidat. Pour une commande existante modifiée, contrôlez que l’opération met à jour la bonne commande. Pour une commande nouvelle, vérifiez qu’une répétition de l’opération n’en crée pas une seconde. Un fichier de suivi ou un CSV de rapport peut servir à la comparaison. Vérifiez ce que l’outil restaure avant de considérer ce fichier comme une source de reprise. Si vous ne disposez pas d’une méthode vérifiée pour les écritures qui comptent, gardez le site actuel comme base de travail et poursuivez la récupération des composants nécessaires.
Réconcilier WooCommerce avec les opérations déjà réalisées
Dans le candidat, ouvrez quelques commandes témoins dans WooCommerce → Commandes, dont une déjà présente à T0, une commande créée après et toute commande dont l’état est incertain. Comparez numéro affiché, référence de transaction, lignes, quantités, frais, total, devise et notes pertinentes. Pour les remboursements, abonnements ou expéditions, contrôlez aussi les objets liés lorsqu’ils existent. Utilisez les systèmes de paiement et d’expédition pour vérifier ce qui s’est effectivement produit, avec la référence attendue de chaque côté.
Consignez la décision pour chaque écart. Par exemple, si le prestataire affiche une transaction validée mais que le candidat montre encore En attente de paiement, vérifiez qu’il s’agit de la même commande et de la même transaction avant de corriger sa représentation locale selon la procédure de la passerelle. Évitez une action qui demanderait un nouveau débit, enverrait un second courriel ou lancerait une seconde expédition. Essayez les effets des changements de statut sur le candidat isolé. Vérifiez aussi le stock lorsque des transitions ou des remboursements ont pu le modifier.
Quand plusieurs commandes sont à rapprocher, séparez dans votre relevé les objets présents et corrects, ceux à remettre, et ceux dont la référence ou l’état est à confirmer. Réattribuez chaque cas incertain à la personne qui dispose de l’information manquante. Un écart inexpliqué sur une commande payée suffit à interrompre le passage en production. Recréez le candidat depuis T0 si les tests d’import ont produit des doublons ou des effets locaux difficiles à annuler.
Suspendre les écritures avant le changement de site
Si la restauration complète a passé la répétition, préparez le passage avec les personnes qui gèrent la boutique, l’édition et les intégrations. Fixez une heure et indiquez qui peut suspendre et réactiver chaque entrée. Fermez la prise de commandes et arrêtez les modifications dans l’administration. Vérifiez aussi les applications utilisant l’API, les formulaires, les tâches planifiées et les systèmes qui envoient des notifications de paiement. Un écran de maintenance pour les visiteurs peut laisser ces chemins ouverts.
Convenez du traitement des événements reçus pendant la pause. Suivez le fonctionnement documenté de chaque intégration pour mettre en file, réessayer ou relever les événements. Faites apparaître dans le journal les transactions en cours et les opérations déjà reçues. Évitez de renvoyer une série d’événements en bloc tant que leur traitement et leur déduplication n’ont pas été vérifiés. Si vous ne maîtrisez pas un canal qui écrit encore, reportez la bascule et gardez la copie testée.
Quand le gel est effectif, prenez une dernière capture de la production, puis complétez le relevé avec les écritures arrivées depuis T1. Donnez à cette capture un nom et une heure distincts. Appliquez au candidat uniquement la procédure qui a été répétée, avec les données finalisées, puis refaites les contrôles. Pour un lot éditorial, vérifiez au moins la page récupérée, un contenu récent, un média et un lien interne. Pour une boutique, vérifiez la liste des commandes et chaque cas déjà signalé comme sensible avant d’autoriser le changement d’adresse ou de base.
Adapter le parcours à une restauration WordPress.com
Sur un site WordPress.com qui dispose des sauvegardes intégrées, ouvrez Jetpack → Sauvegarde dans le tableau de bord. Sélectionnez le point, puis affichez les éléments que l’outil propose de restaurer. Si la panne concerne uniquement des fichiers et que la sélection correspond bien aux fichiers en cause, vous pouvez laisser la base actuelle en place. Vérifiez sur la copie ou avec la méthode de préproduction disponible que le code restauré fonctionne avec la base actuelle. Gardez une capture de l’ensemble pour revenir en arrière si les versions sont incompatibles.
WordPress.com indique que son service de restauration maintient les commandes et produits WooCommerce à jour. Les contenus éditoriaux et les réglages peuvent en revanche revenir à l’état du point choisi. Le service distingue aussi les commandes des fiches d’abonnement. La restauration de la base peut faire revenir une fiche d’abonnement à un état antérieur à un renouvellement déjà payé. Si le site propose des renouvellements automatiques, faites suspendre ces renouvellements avant l’opération et rapprochez les fiches et les paiements avant de les relancer, selon la procédure WordPress.com et celle de l’extension concernée.
Vérifiez le périmètre indiqué dans votre propre panneau. Ce comportement concerne la restauration intégrée de WordPress.com. L’exemple local de ce guide remplace une base entière et illustre le comportement d’une copie brute. Dans les deux cas, relevez les articles et réglages à préserver et gardez un accès au point récent pendant la période de contrôle.
Rouvrir la boutique et préparer le retour
Une fois le candidat vérifié, basculez pendant que les écritures sont encore suspendues. Depuis une fenêtre privée, ouvrez l’accueil et les pages rétablies. Dans l’administration, retrouvez la commande récente, vérifiez la commande ancienne qui a changé de statut et confirmez que les fichiers liés sont accessibles. Contrôlez la file des événements en attente et les destinations des notifications avant de réactiver les tâches ou le traitement des notifications. Rouvrez la prise de commandes après les vérifications qui conditionnent la reprise, puis surveillez les premières écritures.
Si une vérification échoue avant la réouverture, gardez le gel et remettez le dernier état cohérent capturé en production ou rebasculez vers l’instance restée intacte. Vérifiez l’adresse, l’accueil et les commandes avant de réactiver les entrées. Si la boutique a déjà reçu de nouvelles commandes sur l’instance réouverte, faites une nouvelle pause. Relevez ces écritures et capturez ce nouvel état avant de décider du retour. Sinon, le retour lui-même risque de supprimer les commandes que vous venez d’accepter.
Pour transmettre le dossier, conservez les heures des deux points, le périmètre restauré, les contrôles réalisés, les écarts résolus et l’emplacement de la dernière capture. Un autre administrateur doit pouvoir retrouver dans ce journal l’état attendu d’une page et d’une commande sans relancer la procédure. Conservez aussi le contact qui peut vérifier un paiement, une livraison ou un formulaire si un événement différé apparaît après la reprise.
