Chaque montée de version majeure de WordPress ravive la même question côté équipe front : est-ce que l’API REST que consomme le site va continuer de répondre exactement comme avant ? La réponse ne se devine pas, elle se vérifie. Cet article décrit la méthode appliquée avant chaque montée de version majeure sur les projets découplés que nous maintenons, sans revenir sur les nouveautés de gouvernance déjà traitées séparément.
Commencer par l’inventaire réel des routes consommées
Avant toute chose, il faut savoir précisément quelles routes le front interroge réellement, pas celles qu’il pourrait théoriquement utiliser. Sur un projet mature, cet inventaire dépasse souvent les routes évidentes : certaines routes de taxonomie ou de médias, appelées uniquement sur des pages peu visitées, se font facilement oublier si l’inventaire repose sur la mémoire plutôt que sur les journaux d’accès réels du serveur.
Comparer le schéma avant et après
Chaque route REST de WordPress expose son propre schéma, accessible via une requête OPTIONS ou via l’index général de l’API à la racine /wp-json/. Comparer ce schéma entre l’ancienne et la nouvelle version, route par route, permet de repérer un champ renommé, un type modifié ou un champ disparu avant même d’avoir touché au code du front :
OPTIONS /wp-json/wp/v2/posts
curl -s -X OPTIONS https://staging.exemple.fr/wp-json/wp/v2/posts \
-H "Accept: application/json" | jq '.schema.properties | keys'
Construire des tests de contrat, pas seulement des tests manuels
Un test de non-régression sur l’API REST vérifie qu’une route donnée, appelée avec des paramètres représentatifs, continue de renvoyer une structure conforme à ce que le front attend, indépendamment de la version de WordPress sous-jacente :
- Un test par route réellement utilisée par le front, pas une couverture exhaustive de toute l’API.
- Une vérification de la présence des champs consommés, pas de l’intégralité de la réponse, pour rester robuste à l’ajout de nouveaux champs qui ne cassent rien côté front.
- Une exécution systématique de cette suite sur l’environnement de préproduction dès la montée de version appliquée, avant toute bascule en production.
Points de vigilance particuliers à une montée majeure
- Vérifier que les mécanismes d’authentification utilisés par le front (mots de passe d’application, jetons personnalisés) continuent de fonctionner sans changement de comportement inattendu.
- Vérifier le comportement des paramètres
_fieldset_embedsur les routes concernées, particulièrement sensibles à toute réorganisation interne du schéma. - Relire le journal de modifications officiel de la version pour toute mention explicite de changement dans la couche REST, plutôt que de se fier uniquement aux tests automatisés.
Automatiser cette revue plutôt que la refaire à la main
Sur les projets suivis dans la durée, cette comparaison de schéma tourne désormais dans une tâche planifiée qui compare automatiquement l’environnement de préproduction fraîchement mis à jour avec une capture de référence de la version précédente, et envoie une alerte dès qu’une différence de structure apparaît sur une route surveillée. Cette automatisation évite de dépendre de la mémoire d’une personne pour se souvenir qu’une comparaison manuelle doit être relancée à chaque montée de version.
Et si une régression est détectée
Une route dont la réponse a changé ne signifie pas nécessairement une régression du cœur de WordPress : il arrive qu’une extension tierce du projet, elle-même non encore mise à jour pour la nouvelle version, soit la véritable origine du changement observé. Isoler la cause avant de rapporter un bogue au cœur du projet évite de perdre du temps sur une fausse piste.
Une montée de version majeure qui se passe sans incident n’est jamais un coup de chance : c’est le résultat d’une suite de tests de contrat exécutée systématiquement avant chaque bascule en production, jamais après.
En résumé
Un front découplé n’a aucune visibilité directe sur les changements internes d’une nouvelle version majeure de WordPress : sa seule protection reste la vérification systématique du contrat que représente chaque route REST consommée. Cette discipline, appliquée à chaque montée de version depuis plusieurs cycles majeurs, continue de nous éviter les régressions découvertes en production plutôt qu’en préproduction.
