Ce qui déraille quand on se passe d’un environnement de préproduction : trois histoires vraies

Les environnements de préproduction (staging) font partie de ces bonnes pratiques qui ressemblent à une corvée jusqu’au jour où elles vous sauvent. « Ce n’est qu’une petite modification », se dit-on. « Je modifie le site en production, j’actualise et c’est réglé. » La plupart du temps, ça marche. Les rares fois où ça ne marche pas, le coût se compte en heures de récupération, en clients perdus ou en un samedi entier passé à réparer ce qui aurait dû être une modification du mardi.

Trois situations réelles des deux dernières années chez Defyn, anonymisées mais légèrement romancées. Dans chaque cas, une modification de cinq minutes effectuée sur le site en production a coûté entre une demi-journée et une semaine complète. Dans chaque cas, un environnement de préproduction aurait détecté le problème avant qu’il n’atteigne un client.

Histoire 1 : la mise à jour d’extension qui a dévoré le paiement

Un site e-commerce sous WooCommerce a appliqué une mise à jour d’extension de routine un samedi après-midi, directement en production. Une passerelle de paiement a reçu une montée de version mineure. Le propriétaire a cliqué sur « mettre à jour », le tableau de bord est passé au vert, et il est parti dîner.

Ce qu’il ignorait, c’est que la nouvelle version avait introduit un petit changement dans la façon d’assainir le format des champs de carte bancaire. Le site fonctionnait très bien avec la version de PHP de l’agence. Sur la version de PHP plus ancienne de l’hébergeur, la passerelle renvoyait une erreur silencieuse à chaque transaction. Les paiements ont commencé à échouer immédiatement.

Le dimanche matin, quand le propriétaire a vérifié, 31 clients s’étaient heurtés au paiement défaillant et avaient abandonné. L’extension a été rétablie en moins d’une heure, mais ces 31 clients n’ont jamais été récupérés. Un environnement de préproduction avec une seule transaction de test l’aurait détecté avant la perte d’une seule vraie commande.

Histoire 2 : le réglage CSS qui a cassé le mobile

Un site de services B2B avait besoin d’une petite modification visuelle. Un bouton de la page d’accueil devait être un peu plus grand et d’une nuance de rouge différente. La responsable marketing a ouvert le personnalisateur, fait la modification, enregistré et considéré que c’était terminé.

La modification a cassé la mise en page mobile. Le bouton débordait désormais du conteneur sur les écrans de moins de 400 pixels de large, poussant le reste de la page sur le côté et faisant passer le menu de navigation à la ligne de façon disgracieuse. La responsable marketing n’a jamais ouvert le site sur un téléphone, elle ne l’a donc pas remarqué.

L’agence l’a repéré trois semaines plus tard, lors d’une revue trimestrielle. Entre-temps, trois semaines de trafic mobile (soit 60 pour cent de l’audience du site) avaient vu une page d’accueil cassée. Le taux de rebond sur mobile avait discrètement grimpé de 18 pour cent sur cette période.

Histoire 3 : la mise à jour de thème qui a perdu la page d’accueil

Le thème WordPress d’un client proposait une version majeure. Les notes de version promettaient des améliorations de performance et quelques nouvelles fonctionnalités. Le client a appliqué la mise à jour un vendredi après-midi. Le site s’est reconstruit, et toute la mise en page de la page d’accueil avait disparu. Remplacée par un modèle par défaut livré avec la nouvelle version du thème.

La version majeure avait changé la manière dont le thème stockait les données de mise en page, et le script de migration s’est exécuté de façon imparfaite sur la base de données en production. La récupération a exigé de restaurer la version précédente du thème, de réimporter manuellement la mise en page de la page d’accueil depuis une sauvegarde et de réappliquer trois semaines de modifications successives. Temps total de récupération : 11 heures sur un week-end prolongé.

Sur une copie de préproduction, la casse aurait été visible en 30 secondes. L’agence aurait signalé cette version du thème comme risquée et recommandé une autre voie de mise à jour. Zéro interruption visible pour le client, zéro week-end perdu.

Ce qu’est réellement un environnement de préproduction

Un environnement de préproduction est une copie privée du site en production, hébergée sur une URL différente, qui reproduit la production d’aussi près que possible. La version du thème correspond, les versions des extensions correspondent, le contenu est récent et la base de données est raisonnablement à jour. L’équipe y effectue les modifications, les teste, et ne les pousse en production qu’une fois confirmé qu’elles fonctionnent.

Les hébergeurs WordPress infogérés modernes (Pantheon, WP Engine, Kinsta, SiteHost) proposent tous une préproduction en un clic. La plupart des hébergeurs de qualité l’incluent dans leurs offres. La configurer pour la première fois sur un hébergement infogéré prend 10 minutes, après quoi elle reste là indéfiniment comme une assurance bon marché.

La question de la discipline

La configuration technique est facile. Le plus dur, c’est l’habitude. « Ce n’est qu’une petite modification » doit disparaître du vocabulaire de l’équipe. Chaque mise à jour d’extension, chaque mise à jour de thème et chaque changement structurel de CSS passe d’abord par la préproduction. Point.

Les modifications de contenu (changements de texte, remplacement d’une image à la une, publication d’un nouvel article de blog) peuvent généralement se passer de préproduction sans risque. Les changements structurels et d’infrastructure, non.

Si votre site n’a pas d’environnement de préproduction, ou en a un que personne n’utilise vraiment, l’équipe de développement WordPress de Defyn peut le mettre en place et instaurer un flux de travail sensé. Une fois qu’une équipe dispose d’un processus de préproduction fonctionnel depuis trois mois, plus personne ne veut modifier le site en production directement.