Pourquoi les tests de régression sont critiques aujourd’hui

Ce que sont réellement les tests de régression

Un test de régression vérifie à nouveau, après un changement, un comportement qui fonctionnait déjà. C’est l’inverse du test d’une nouvelle fonctionnalité : personne n’a demandé que la commande change, donc si elle se comporte autrement après la livraison du jour, cette différence est le résultat.

Ce n’est pas non plus la même chose qu’un nouveau test de correction. Retester confirme qu’un bogue précis est corrigé. Le test de régression pose la question plus large que soulève la correction : qu’est-ce que ce changement a touché d’autre ? Une correction d’une ligne dans une règle de livraison peut déplacer un total, une modification de gabarit peut supprimer un champ de formulaire, et une montée de version de dépendance peut changer l’analyse d’une date.

Le déclencheur est n’importe quel changement, pas seulement votre code : la mise à jour d’une extension ou d’un paquet, un changement de configuration ou d’environnement, un basculement de CDN ou de DNS, un script tiers qui se met à jour tout seul, du contenu modifié dans un CMS. Chacun peut altérer un comportement que vous n’avez jamais touché : voilà pourquoi les tests de régression sont une habitude continue et non un rituel du jour de livraison.

Pourquoi ils comptent davantage aujourd’hui

L’IA générative a changé l’économie de l’écriture de code. Une fonctionnalité qui prenait une journée prend une heure ; une refonte pour laquelle personne n’avait de temps se fait sur un coup de tête. Ce qui n’a pas changé, c’est l’exigence que le résultat soit correct — et le mode de défaillance d’un assistant d’IA ne ressemble pas à celui d’un humain. Il n’hésite pas, ne bloque pas, ne laisse pas de TODO. Il produit quelque chose de plausible, complet et fluide, que ce soit juste ou non.

Cela se traduit par des faits concrets. Les modèles inventent ce qui n’existe pas : une étude sur les hallucinations de paquets a constaté qu’environ un paquet sur cinq recommandé par des modèles générateurs de code n’existait pas — à la fois un bogue et un risque pour la chaîne d’approvisionnement, puisqu’un attaquant peut enregistrer le nom inventé. Ils réécrivent aussi plus que demandé : l’analyse de GitClear sur des centaines de millions de lignes modifiées décrit une duplication en hausse et une refonte en baisse, la signature d’un code qu’on ajoute au lieu de le réorganiser.

Le plus dangereux est l’écart de perception. Dans un essai randomisé de METR, des développeurs open source expérimentés travaillant sur leurs propres dépôts ont été mesurablement plus lents avec l’assistance de l’IA — tout en croyant avoir été nettement plus rapides. C’est exactement quand on se sent rapide que l’on saute la vérification, et les travaux DORA de Google associent l’adoption croissante de l’IA à une stabilité de livraison en baisse. La vitesse sans filet, c’est ainsi qu’une régression silencieuse atteint les clients.

Il existe un effet de second ordre : une part croissante du code de votre dépôt n’a été écrite de zéro par personne dans l’équipe, et elle est relue dans des diffs plus gros que ce que quiconque lit attentivement. La mémoire collective — « attention, cette fonction porte la moitié du système » — s’amenuise. Les tests de régression automatisés sont ce qui remplace cette mémoire.

Les types de tests de régression

Le test de régression n’est pas une technique unique. Les types classiques décrivent l’ampleur de ce que l’on rejoue : la régression unitaire rejoue uniquement les tests autour de l’unité modifiée, en isolation. La régression partielle (sélective) rejoue l’unité modifiée et ce qui en dépend, choisi par analyse d’impact — le réglage par défaut habituel, car il est assez rapide pour chaque commit. La régression complète rejoue tout et se réserve à un changement important ou risqué : montée de version d’un framework, migration de plateforme, branche de longue durée enfin fusionnée. Le retest intégral est la version force brute : lancer toute la suite, avec ou sans changement, en général selon un calendrier plutôt qu’à chaque commit.

Deux autres décrivent la nature du changement que vous protégez : la régression corrective rejoue les tests existants sans les modifier, parce que le code a changé mais pas la spécification. La régression progressive met d’abord les tests à jour, parce que la spécification elle-même a bougé : un nouveau comportement est attendu, et l’enjeu est de confirmer que rien d’autre n’a bougé avec lui.

Viennent ensuite les couches, qui comptent plus que les étiquettes. La régression fonctionnelle et de bout en bout parcourt de vrais parcours utilisateur — ajouter au panier, commander, payer, recevoir la confirmation — et c’est la seule couche qui prouve que l’activité fonctionne encore. La régression d’API et de contrat fige la forme d’une réponse, pour qu’un champ qui change discrètement de type soit repéré avant de casser ses consommateurs. La régression visuelle compare les pixels rendus à une référence approuvée et détecte ce qu’une assertion sur le DOM ne verra jamais : une mise en page qui s’effondre, une police qui échoue, une image qui disparaît. La dérive de structure travaille une couche plus bas, sur le DOM, et détecte ce que les pixels manquent, comme un script de suivi ou un champ de formulaire disparu sans changer l’image. La régression de performance compare des temps à une référence, car une page qui fonctionne encore mais met désormais quatre secondes est une vraie régression. La régression de données et de schéma revérifie migrations et rapports avec des entrées connues. La régression d’accessibilité et de SEO attrape les ruptures invisibles pour vous : une étiquette perdue, une règle noindex partie en production avec une configuration de préproduction.

Là où s’arrête votre suite de tests

Tous les types ci-dessus testent le code que vous maîtrisez, au moment où vous le changez. Votre site en production est assemblé à partir de bien plus : mises à jour automatiques d’extensions et de paquets, mise à jour d’un thème, prestataire de paiement qui change son intégration, script tiers qui se met à jour la nuit, règle de CDN, changement de version de PHP ou de Node par l’hébergeur, contenu modifié dans l’urgence.

Rien de tout cela ne touche votre dépôt, donc rien de tout cela ne déclenche vos tests — et tout cela a déjà cassé des sites en production. La panne la plus fréquente que nous voyons n’est pas un mauvais déploiement : c’est une extension WordPress ou WooCommerce qui se met à jour à trois heures du matin et modifie la commande, sur un site dont le code n’a pas changé cette semaine-là. Un pipeline d’intégration continue au vert ne dit rien de tout cela.

C’est le vide que comblent les vérifications continues en production : la même discipline de test de régression, pointée sur le site en fonctionnement plutôt que sur la compilation. La référence, c’est ce que votre site faisait hier ; le résultat, c’est ce qui a changé aujourd’hui, quel qu’en soit l’auteur — y compris les personnes et les robots qui n’ont jamais ouvert votre dépôt.

Quoi surveiller en continu, dans l’ordre

Commencez par le chemin de l’argent. Une vérification de bout en bout du parcours qui paie les factures — ajouter au panier, commander, commande passée, e-mail de confirmation reçu — vaut mieux que cent tests unitaires, car c’est la panne qui coûte de l’argent à l’heure. Relvato l’exécute comme un parcours de surveillance de la commande sur la vraie boutique, selon un calendrier et après chaque mise à jour.

Ensuite les deux couches de rendu, qui détectent des moitiés différentes d’un déploiement cassé : la régression visuelle pour l’apparence de la page et la dérive de structure pour sa construction. Ajoutez les Core Web Vitals pour traiter une régression de vitesse comme ce qu’elle est, et une analyse d’exposition pour qu’une clé ou une sauvegarde apparue dans une compilation soit trouvée le jour même, et non par quelqu’un d’autre.

Le principe d’ordre est simple : protégez d’abord ce qui casse le plus bruyamment, puis élargissez. Un petit ensemble de vérifications qui tournent vraiment vaut mieux qu’une suite exhaustive que personne n’entretient — et contrairement à une suite de tests, les vérifications en production gardent leur valeur même quand le changement vient de l’extérieur de votre dépôt.

Si vous n’avez aucune suite de tests

Beaucoup de sites qui gagnent réellement de l’argent n’ont aucun test automatisé, et le conseil « écrivez d’abord une suite de tests » est précisément ce qui maintient cet état une année de plus. Il existe un raccourci : commencez par l’extérieur. Une poignée de parcours en production peut tourner dès aujourd’hui sans toucher à votre code, et vous signalera en quelques minutes qu’un changement a cassé quelque chose dont un client dépend.

De là, descendez vers l’intérieur. Quand une vérification en production attrape une régression, c’est ce comportement qui mérite d’être figé par un test unitaire ou d’intégration, écrit avec la panne sous les yeux. Votre suite grandit alors à partir d’incidents réels plutôt que de suppositions sur ce qui pourrait casser — et c’est aussi la façon la moins coûteuse de la construire.

La vérité inconfortable de l’ère de l’IA, c’est que produire du code n’est plus le goulet d’étranglement ; savoir s’il fonctionne l’est. Les tests de régression sont la manière de l’apprendre exprès, plutôt que de l’apprendre d’un client.