36 combinaisons de versions PHP et WordPress, exécutées à chaque pull request, pour une extension qui affiche officiellement une compatibilité de PHP 7.4 à 8.2 et de WordPress 6.0 à la dernière version stable. Chaque nouvelle version supportée ajoute une ligne et une colonne à cette matrice, et le temps total d’exécution de la CI double parfois en quelques mois sans qu’aucun bug supplémentaire n’ait été détecté par les combinaisons ajoutées.
Sur une extension de gestion de licences vendue à plusieurs centaines de clients, cette dérive a fini par transformer chaque pull request en une attente de plus de vingt minutes avant retour, ce qui a poussé l’équipe à repenser entièrement la matrice plutôt que d’ajouter des machines.
Pourquoi tester toutes les combinaisons est une fausse sécurité
Une matrice complète donne l’illusion d’une couverture exhaustive, mais la plupart des combinaisons intermédiaires ne testent rien que les combinaisons aux bornes ne testent déjà. Un bug de compatibilité PHP 8.2 se manifeste presque toujours de la même façon quelle que soit la version de WordPress associée, parce qu’il porte sur le langage lui-même (typage strict, dépréciations, changements de signature des fonctions natives), pas sur l’intégration avec le cœur WordPress.
À l’inverse, un bug d’intégration WordPress (changement d’API, dépréciation d’un hook) dépend rarement de la version PHP utilisée. Tester le produit cartésien des deux axes revient donc à payer un coût qui croît en m × n pour une couverture réelle qui croît en m + n.
La méthode : bornes, versions dominantes, et croisements ciblés
La matrice réduite retenue s’appuie sur trois catégories de combinaisons, choisies en fonction des statistiques d’installation réelles de l’extension plutôt que par principe :
Matrice retenue (9 combinaisons au lieu de 36) :
PHP 7.4 x WordPress 6.0 (borne basse absolue, encore ~15 % du parc client)
PHP 7.4 x WordPress LTS (version dominante côté client historique)
PHP 8.0 x WordPress LTS (transition PHP la plus fréquente chez nos clients)
PHP 8.1 x WordPress LTS (version dominante côté hébergeurs mutualisés)
PHP 8.2 x WordPress LTS (version recommandée dans notre documentation)
PHP 8.2 x WordPress LTS (borne haute PHP, dépréciations les plus récentes)
PHP 8.2 x WordPress dernière stable (borne haute des deux axes croisée)
PHP 8.1 x WordPress dernière stable (version hébergeur la plus fréquente x dernière stable)
PHP 7.4 x WordPress dernière stable (borne basse PHP x borne haute WordPress, croisement à risque)
Les combinaisons intermédiaires (PHP 8.0 avec une version de WordPress autre que la LTS, par exemple) sont retirées, sur l’hypothèse que les bugs qu’elles révéleraient seraient déjà couverts par une autre ligne de la matrice réduite.
Vérifier l’hypothèse avant de l’appliquer
Avant de couper la matrice, l’équipe a analysé l’historique des échecs de CI des douze derniers mois : sur 47 échecs liés à une incompatibilité de version, 44 concernaient une borne (PHP 7.4 ou 8.2, WordPress la plus ancienne ou la plus récente supportée), et seulement 3 concernaient une combinaison intermédiaire, elle-même déjà couverte indirectement par un autre axe testé isolément. Cette vérification rétrospective a donné la confiance nécessaire pour réduire la matrice sans attendre qu’un bug la valide a posteriori.
Ce qui reste hors matrice automatisée
- Les combinaisons retirées restent documentées dans un fichier
MATRICE.mddu dépôt, avec la justification du retrait, pour qu’une régression future puisse être investiguée en connaissance de cause. - Une combinaison signalée par un client (via un ticket de support) est ajoutée temporairement à la matrice de la branche concernée, le temps de qualifier le correctif.
- La matrice est révisée tous les six mois, au moment où l’extension officialise le support d’une nouvelle version PHP ou WordPress.
Une matrice de compatibilité n’a pas vocation à tout tester, elle a vocation à représenter fidèlement le parc réel de vos utilisateurs.
Notre verdict
Réduire une matrice de 36 à 9 combinaisons a divisé par plus de trois le temps de CI par pull request, sans qu’aucune régression de compatibilité n’ait échappé à la nouvelle matrice sur les six mois suivants. La condition de réussite n’est pas la réduction elle-même, mais l’analyse préalable des échecs passés qui justifie objectivement quelles combinaisons peuvent disparaître sans risque.
