Après une version publiée en urgence un vendredi soir, qui a cassé la compatibilité avec une extension tierce très répandue chez nos clients, l’équipe a formalisé une checklist unique, suivie sans exception avant chaque publication, quelle que soit l’ampleur de la version. Ce n’est pas un document théorique rangé dans un wiki que personne ne rouvre : c’est une liste vivante, cochée à chaque fois dans le gestionnaire de tickets, avec un nom et une date en face de chaque case.
Voici cette liste, dans l’ordre où nous la suivons réellement, avec la logique derrière chaque étape plutôt qu’une simple énumération.
1. Lint et analyse statique, en premier, sans exception
Avant même de lancer les tests fonctionnels, on vérifie que le code respecte les standards de style et ne contient pas d’erreur de type détectable statiquement. Cette étape est volontairement placée en premier : un code qui échoue ici n’a pas besoin qu’on perde du temps à faire tourner une suite de tests plus longue derrière.
composer run lint # PHPCS avec WordPress-Extra
composer run phpstan # Analyse statique, niveau configuré du projet
npm run lint # ESLint et Stylelint sur les assets JS/CSS2. Suite de tests complète, pas seulement les tests rapides
La suite complète inclut les tests unitaires PHPUnit, les tests d’intégration avec la base WordPress, et la suite E2E, même si celle-ci prend plusieurs minutes de plus. On a appris à nos dépens qu’exécuter seulement les tests unitaires « rapides » avant une publication urgente laisse passer exactement le type de régression qui compte le plus, celle qui touche à l’intégration réelle avec le cœur ou avec une extension tierce.
3. Matrice de compatibilité PHP et WordPress
On rejoue la suite de tests sur la matrice de versions officiellement supportées par l’extension, déclarée dans son en-tête (Requires PHP, Requires at least, Tested up to). Une régression qui n’apparaît que sur la version minimale de PHP supportée, ou sur l’avant-dernière version majeure de WordPress encore couverte, est un classique qui échappe à toute exécution locale unique.
4. Plugin Check et vérification de sécurité ciblée
On fait tourner l’outil officiel Plugin Check sur l’ensemble de l’extension, pas seulement sur les fichiers modifiés depuis la dernière version, car certaines erreurs de sécurité ou de performance peuvent apparaître par interaction entre du code ancien et du code nouveau. En complément, une revue manuelle ciblée porte spécifiquement sur les points d’entrée modifiés dans la version : tout nouveau traitement de formulaire, toute nouvelle route AJAX ou REST, reçoit une relecture dédiée pour l’échappement de sortie et la vérification des capacités utilisateur.
5. Vérifications manuelles que l’automatisation ne couvre pas
Certains aspects résistent mal à l’automatisation complète et méritent un passage manuel court mais systématique :
- Activation et désactivation de l’extension sur une installation neuve, pour vérifier l’absence d’erreur fatale au premier chargement
- Test de mise à jour depuis la version précédente publiée, pas seulement depuis une installation neuve, en particulier si la version introduit une migration de données
- Vérification visuelle rapide des écrans d’administration modifiés, l’automatisation E2E ne détectant pas toujours un problème purement visuel sans rupture fonctionnelle
- Test avec un thème différent du thème de développement habituel, pour repérer un conflit de style CSS passé inaperçu
6. Rédaction précise du changelog
Un changelog qui se contente de « corrections diverses et améliorations de performance » ne sert à rien, ni aux utilisateurs, ni à l’équipe de support qui devra plus tard identifier dans quelle version un comportement a changé. Chaque entrée du changelog nomme précisément la fonctionnalité ou la correction concernée, avec assez de détail pour qu’un utilisateur qui rencontre un problème puisse relier son symptôme à l’entrée correspondante :
= 4.2.0 =
* Ajout : export CSV des commandes filtrées par plage de dates personnalisée
* Correction : le calcul de la TVA appliquait deux fois la remise sur les commandes multi-devises
* Modification : le hook `mon_extension_avant_export` reçoit désormais un troisième paramètre $format
La dernière ligne de cet exemple illustre un point important : tout changement de signature de hook, même a priori mineur, doit apparaître explicitement dans le changelog, car il peut casser silencieusement une extension tierce qui s’y accroche.
7. Vérification des chaînes de traduction et du fichier .pot
On régénère le fichier .pot et on vérifie qu’aucune nouvelle chaîne n’a été ajoutée sans passer par les fonctions de traduction standard, un contrôle qui rejoint celui décrit dans un article dédié à l’internationalisation continue, mais qu’on recoche explicitement ici, dans le contexte spécifique d’une publication.
Une checklist qu’on peut cocher de mémoire sans jamais s’y référer n’en est plus une : elle finit par sauter une étape le jour où la pression du calendrier est la plus forte, précisément le jour où l’omettre coûte le plus cher.
8. Fenêtre d’observation après publication
La checklist ne s’arrête pas à la publication elle-même : on programme une vérification des journaux d’erreurs et des retours de support dans les 48 heures suivant une mise à jour majeure, avant de considérer la publication comme définitivement close. C’est cette étape, ajoutée après l’incident du vendredi soir évoqué en introduction, qui a permis de détecter et corriger un problème de compatibilité dans les six heures suivant une publication récente, plutôt qu’en plusieurs jours via les retours clients.
En résumé
Aucune étape de cette checklist n’est individuellement spectaculaire ; c’est leur enchaînement systématique, dans un ordre qui élimine d’abord les problèmes les moins coûteux à détecter, qui fait la différence. La discipline qui compte n’est pas de connaître ces étapes, la plupart des équipes les connaissent déjà, mais de les suivre identiquement que la version soit mineure ou majeure, publiée un mardi matin tranquille ou sous la pression d’un correctif urgent.
