Un déploiement WordPress peut modifier davantage que les fichiers d’une version. Une mise à jour de plugin ou un développement sur mesure peut également créer des tables, modifier des options, transformer des enregistrements ou changer la façon dont les données existantes sont interprétées. Si le code et la base de données se retrouvent dans des états incompatibles, le site peut tomber en panne même si la copie des fichiers semble complète.
Gérer un déploiement WordPress avec modifications de base de données exige de traiter chaque modification en fonction de son impact et de sa réversibilité. L’objectif n’est pas seulement de publier du code : il s’agit d’assurer une transition maîtrisée, de vérifier les flux critiques et de savoir quoi faire si la nouvelle version ne fonctionne pas comme prévu.
Pourquoi restaurer les fichiers ne suffit pas toujours à récupérer le site
Le code effectue des opérations sur la base de données, mais il ne reflète pas nécessairement l’état actuel de celle-ci. Si une nouvelle version crée une table ou modifie le format d’une valeur, revenir aux fichiers précédents n’annule pas ces changements. L’ancien code peut ne pas reconnaître le nouveau schéma, ou le site peut avoir reçu des données que la version précédente ne sait pas traiter.
L’inverse peut également se produire : restaurer une ancienne base de données tout en conservant les nouveaux fichiers peut laisser le système dans un état incohérent. Dans WooCommerce, par exemple, les commandes et d’autres données opérationnelles peuvent continuer à évoluer pendant et après le déploiement. Restaurer une sauvegarde antérieure de la base de données pourrait supprimer des opérations légitimes effectuées depuis sa création.
Il est donc utile de distinguer le retour à une version précédente du code, qui remet les fichiers dans une version antérieure ; la réparation des données, qui corrige des changements précis ; et la restauration, qui récupère une sauvegarde. Ces actions ne sont pas équivalentes et n’ont ni le même coût ni le même impact.
Inventorier les changements et les dépendances avant la publication
Avant le déploiement, consignez ce qui change et où cela se trouve. Une liste utile distingue quatre catégories :
- Code : thèmes, plugins, code sur mesure, tâches planifiées et dépendances.
- Schéma : tables, colonnes, index ou autres structures créés, modifiés ou supprimés.
- Données : enregistrements insérés, mis à jour, transformés ou supprimés, y compris les options et les métadonnées.
- Configuration et contenu : valeurs propres à chaque environnement, identifiants, règles, pages ou réglages gérés depuis le tableau de bord.
Documentez qui exécute chaque migration, à quel moment et si elle peut être répétée sans risque. Vérifiez si elle est déclenchée automatiquement lors de la mise à jour d’un plugin ou si elle nécessite une commande, une tâche manuelle ou une action administrative. Identifiez également les dépendances : quelle version du code nécessite la nouvelle structure et quels processus écrivent dans les tables concernées.
Dans WordPress, une partie de la configuration peut se trouver dans la base de données et différer entre la production et les environnements de test. Ne partez pas du principe que copier une base de données d’un environnement à un autre est sans risque. De même, les données sérialisées ou stockées sous forme d’options peuvent nécessiter une transformation compatible avec leur format, et non un remplacement textuel indiscriminé.
Concevoir une séquence compatible et progressive
Lorsque la nature du changement le permet, utilisez une stratégie d’expansion et de contraction. Commencez par ajouter des structures compatibles avec la version actuelle ; déployez ensuite du code capable de fonctionner avec l’ancien et le nouvel état ; migrez alors les données et validez le résultat. Ce n’est qu’une fois la nouvelle version stabilisée que vous supprimez les anciennes colonnes, routes ou structures devenues inutiles.
Cette séquence réduit le risque qu’un retour aux fichiers précédents laisse le site sans une structure attendue par l’ancien code. Toutes les modifications ne peuvent pas suivre cette approche : une transformation destructive ou un changement incompatible peut nécessiter une fenêtre de maintenance, le blocage des écritures ou des étapes spécifiques au fournisseur du plugin. La décision dépend de l’opération, du volume de données, de la durée prévue et de la capacité à maintenir le service.
Évitez de regrouper dans une seule opération les changements de code, les migrations et le nettoyage irréversible sans points de contrôle. Si une tâche prend du temps ou échoue en cours d’exécution, il doit être possible de savoir quelles étapes sont terminées. Définissez comment la reprendre sans risque, comment éviter les exécutions en double et qui autorise la poursuite. Dans les déploiements progressifs, confirmez que les versions qui coexistent peuvent fonctionner sur la base de données partagée.
Tester dans un environnement représentatif
Un environnement de test est utile s’il reproduit les conditions pertinentes : versions de PHP et de WordPress, plugins, intégrations, configuration et types de données. Il n’a pas besoin de reprendre toutes les données réelles, mais doit permettre de tester les parcours concernés. Si vous utilisez des données de production, protégez les informations personnelles et limitez les accès ; traitez la copie avec les mêmes précautions que les données d’origine.
Répétez la migration et mesurez sa durée avec une quantité de données raisonnablement représentative. Vérifiez ce qui se passe en cas d’interruption et si l’opération peut être répétée sans créer de doublons ni perdre d’informations. Validez ensuite au minimum la lecture et l’écriture des données concernées ainsi que les flux métier pertinents : achat, paiement, confirmation, gestion des commandes ou synchronisation avec des systèmes externes, selon le cas.
Incluez des tests de compatibilité, d’autorisations, de tâches planifiées et d’erreurs d’intégration. Le chargement d’une page d’accueil ne prouve pas que le parcours d’achat fonctionne. Si vous ne pouvez pas reproduire une intégration dans l’environnement de test, définissez une vérification de remplacement et désignez la personne qui l’effectuera après la publication.
Définir les indicateurs à surveiller après le déploiement
Avant de commencer, établissez les critères de réussite du déploiement et la durée de la période d’observation. Les indicateurs doivent correspondre aux risques identifiés et ne pas se limiter à vérifier que le serveur répond. Ils peuvent inclure :
- Erreurs PHP, journaux de l’application et échecs des tâches planifiées.
- Résultats de la migration : structure attendue, décomptes ou cohérence des enregistrements concernés.
- Opérations de lecture et d’écriture et exécution des flux critiques.
- État des paiements, webhooks, synchronisations et autres intégrations concernées.
- Indicateurs métier habituels, comparés au comportement attendu dans ce contexte.
Désignez les responsables chargés d’examiner ces indicateurs et de fixer les seuils de pause ou de retour à une version précédente du code. Si une erreur augmente, déterminez d’abord si elle concerne l’application, l’intégration ou les données ; une alerte sans procédure de réponse ne suffit pas à maîtriser le risque.
Préparer la récupération et décider si le déploiement peut être autorisé
Le plan doit préciser ce qui peut être annulé sans risque en revenant à une version précédente du code et ce qui nécessite une réparation ou une restauration. Vérifiez que les sauvegardes existent et qu’elles peuvent être récupérées ; une sauvegarde qui n’a pas été testée ne constitue pas une garantie opérationnelle. Définissez le point de récupération, les dépendances de la procédure et les conséquences de la suppression des changements légitimes effectués après la sauvegarde. Pour une boutique en activité, évaluez comment préserver les commandes et les opérations reçues pendant l’intervention.
Avant la publication, convenez de qui prend la décision, qui exécute l’opération et qui la valide. N’autorisez le déploiement que si la migration a été testée, si les dépendances sont identifiées, si les vérifications ont des responsables et si la récupération est réalisable. Mettez l’opération en pause en cas de doute sur la compatibilité entre les versions, d’échec d’un test critique ou d’impossibilité de protéger l’activité en cours. Revenez à la version précédente du code lorsque cela suffit à rétablir la compatibilité ; réparez les données lorsque le problème est circonscrit ; ne restaurez qu’en sachant quels changements ultérieurs seraient perdus.
Liste de contrôle avant la mise en production : inventaire complet ; sauvegarde vérifiée ; séquence et fenêtre définies ; tests réussis ; indicateurs et responsables désignés ; critères explicites pour poursuivre, mettre en pause ou récupérer. Cette discipline transforme une modification de base de données en une opération maîtrisée, plutôt qu’en un pari sur la capacité des anciens fichiers à suffire.
