La séquence est connue de tous ceux qui exploitent un site WordPress. Une notification signale une mise à jour disponible pour le constructeur de pages, quelqu'un clique un vendredi en fin de journée, et le tunnel de commande cesse de fonctionner. Personne ne s'en aperçoit avant le lundi, parce que le samedi les visiteurs abandonnent sans écrire. La perte n'est pas le coût de la réparation, c'est le week-end de commandes qui ne reviendra pas.
Un environnement de préproduction, souvent appelé staging ou recette, sert exactement à éviter cela. Il s'agit d'une copie complète du site, invisible du public, sur laquelle on applique les changements avant de les reproduire en ligne. Nous mettons cet environnement en place sur les sites que nous suivons en maintenance WordPress à 500 HT / an lorsque l'hébergement le permet, et sur un sous-domaine dédié dans le cas contraire.
Ce qu'est une copie de préproduction, et ce qu'elle n'est pas
Une préproduction reproduit fidèlement le site en ligne : mêmes fichiers, même base de données, même version de PHP, mêmes extensions et mêmes réglages. Cette fidélité est la condition de son utilité. Une copie qui tourne sur une version de PHP différente de la production ne vous apprend rien sur le comportement réel du site après mise à jour, et une copie dont on a désactivé la moitié des extensions pour l'alléger ne teste pas les conflits, qui sont pourtant la cause la plus fréquente des pannes.
Elle n'est en revanche pas un second site public. Elle ne doit apparaître ni dans les résultats de recherche, ni dans vos statistiques, ni dans les outils de suivi de la production. Un site de recette laissé accessible et indexé crée deux adresses proposant le même contenu, ce qui brouille l'évaluation de vos pages par les moteurs, un sujet que nous abordons dans votre site est en ligne, personne ne vous trouve.
Elle n'est pas non plus une sauvegarde. La préproduction est un terrain d'essai que l'on écrase régulièrement, et elle ne remplace en rien les copies conservées ailleurs dont nous parlons dans sauvegarder WordPress hors de l'hébergeur.
Les changements qui justifient un passage par la recette
Tout ne mérite pas ce détour. Corriger un mot dans une page, remplacer une photo ou publier un article se font directement en ligne, sans risque particulier. Quatre catégories de changements, en revanche, ne devraient jamais atteindre la production sans avoir été essayées.
- Le passage à une version majeure de WordPress modifie des comportements et casse parfois des extensions qui n'ont pas suivi. Une version majeure se teste, une version mineure de sécurité s'applique vite.
- Le changement de version de PHP est le plus sensible de tous, car une extension ancienne peut cesser de fonctionner sans message explicite. Ce sujet est développé dans PHP obsolète : le site tourne encore, la porte est ouverte.
- La mise à jour d'un constructeur de pages ou d'un module de boutique touche directement aux pages qui génèrent votre activité, c'est-à-dire l'accueil, les pages de vente et le tunnel de commande.
- L'installation d'une nouvelle extension, en particulier une extension de cache ou d'optimisation, produit des effets qui ne se voient pas sur la page d'accueil mais sur le panier ou l'espace client. Nous détaillons ce réglage dans notre article sur le cache bien paramétré.
Les modifications de structure du thème appartiennent à la même catégorie. Un ajustement d'en-tête ou de pied de page se prépare dans la recette, sur un thème enfant, puis se reporte une fois validé.
Isoler la copie pour qu'elle ne parle pas au monde extérieur
Créer le clone est la partie facile. L'isoler correctement demande quelques précautions que nous appliquons systématiquement.
Nous bloquons d'abord l'accès public, par un mot de passe au niveau du serveur plutôt qu'au niveau de WordPress, ce qui protège aussi les fichiers et les points d'entrée de l'administration. Nous ajoutons une instruction noindex pour que le contenu ne soit pas repris par les moteurs, et nous n'ajoutons jamais la recette aux outils de suivi de la production.
Nous neutralisons ensuite les envois de courrier. Un clone conserve les tâches planifiées de l'original, ce qui signifie qu'il peut relancer de vrais clients sur un panier abandonné ou renvoyer des notifications de commande. Nous coupons donc l'envoi sur la copie, ou nous le redirigeons vers une boîte de test. Le fonctionnement de ces envois et leurs pièges sont détaillés dans le formulaire dit merci, le mail n'arrive jamais.
Nous basculons enfin les connexions aux services externes en mode test : passerelle de paiement, service d'expédition, connecteur comptable. Une commande passée sur la recette ne doit produire ni débit réel, ni bon de préparation. Les identifiants d'administration de la copie sont distincts de ceux de la production, pour éviter qu'un accès partagé lors d'une prestation ponctuelle ne devienne un accès permanent au site en ligne.
Reporter en production sans écraser les commandes du jour
C'est l'étape que les outils automatisés gèrent le plus mal. Repousser intégralement la base de la recette vers la production écrase tout ce qui a été enregistré en ligne pendant les essais : commandes, comptes créés, commentaires, formulaires reçus. Sur un site vitrine, la conséquence est faible ; sur une boutique, elle est grave.
Notre règle est donc simple. Si la recette a servi à valider une mise à jour, nous ne recopions pas la base : nous rejouons la même opération en production, dans le même ordre, en connaissant désormais le résultat attendu et le point de blocage éventuel. Si la recette a servi à construire de nouvelles pages, nous ne transférons que ces pages et les réglages associés. Nous procédons toujours après avoir pris une sauvegarde fraîche de la production, de façon à disposer d'un retour arrière immédiat.
Les copies de recette qui ne servent plus à rien
Un environnement de préproduction se dégrade s'il n'est pas entretenu, et une copie inutile est pire qu'une absence de copie parce qu'elle donne une fausse assurance.
Le cas le plus courant est la recette figée depuis deux ans : elle ne contient ni les extensions ajoutées depuis, ni les contenus récents, et un test qui y réussit ne prouve plus rien sur la production actuelle. Nous rafraîchissons donc la copie à partir de la production au début de chaque intervention, plutôt que de reprendre l'ancienne. Le deuxième cas est l'empilement d'extensions de duplication : quand l'hébergeur propose nativement une fonction de clonage, comme le font plusieurs hébergeurs que nous utilisons régulièrement, nous l'employons plutôt que d'ajouter du code au site. Le troisième cas est la recette laissée accessible et oubliée, qui finit par devenir elle-même une installation obsolète et exposée.
Notre déroulé pour une mise à jour suivie
Nous rafraîchissons la copie à partir de la production, nous appliquons les mises à jour sur cette copie, puis nous parcourons une liste de contrôle définie avec vous : page d'accueil, deux pages internes, un formulaire, et sur une boutique le parcours complet jusqu'au paiement en mode test. Si tout se comporte correctement, nous prenons une sauvegarde de la production et nous rejouons l'opération en ligne, à un moment de faible affluence. Si un conflit apparaît, nous le traitons sur la copie et le site en ligne ne bouge pas.
L'opération ajoute une vingtaine de minutes à une mise à jour ordinaire. Elle évite en contrepartie de consacrer l'heure de modification incluse chaque trimestre dans le contrat à réparer ce qui vient d'être cassé. Nous intervenons à distance, en France et en Suisse.
Une préproduction n'est pas un raffinement d'agence, c'est le moyen de séparer l'essai du résultat. Si vos mises à jour se font encore directement sur le site en ligne, écrivez-nous : nous regarderons si votre hébergement permet un clone natif et nous poserons la recette avec vous.