Test de non-régression (TNR) : définition, méthode et quand l'automatiser
Ce qu'est vraiment un TNR, ce qui le distingue d'un retest, la méthode en 5 étapes pour bâtir un référentiel qui tient dans la durée, et un calcul simple pour savoir si l'automatiser sera rentable chez vous.
Un test de non-régression (TNR) vérifie qu'une modification du logiciel n'a rien cassé dans ce qui fonctionnait déjà. Il se lance après chaque correction, nouvelle fonctionnalité, mise à jour de dépendance ou changement d'environnement, et c'est le premier candidat à l'automatisation parce qu'il se rejoue à chaque livraison.
- TNR et retest ne sont pas la même chose : le retest vérifie qu'un bug est corrigé, le TNR vérifie que la correction n'a rien cassé ailleurs.
- La méthode tient en 5 étapes : cartographier les parcours critiques, constituer le référentiel, choisir la stratégie d'exécution, automatiser par paliers, mesurer.
- Tout automatiser n'est pas rentable : les parcours critiques rejoués à chaque livraison passent en premier, les scénarios rares restent manuels.
- L'IA rend le TNR plus sélectif : chez Meta, la sélection prédictive des tests détecte plus de 99,9 % des régressions en exécutant un tiers des tests concernés.
En combien de mois l'automatisation de votre TNR serait-elle rentabilisée ?
Cinq chiffres que vous connaissez déjà. Le calcul compare le coût de vos campagnes manuelles à celui de l'automatisation, maintenance comprise.
Calcul indicatif : il ne compte que le temps de test économisé. Les gains sur les incidents évités et la fréquence de livraison viennent en plus.
Test de non-régression : la définition
Le glossaire ISTQB, référence internationale des testeurs, définit le test de régression comme un test lié aux changements, qui vérifie si des défauts ont été introduits ou révélés dans les parties non modifiées du logiciel. La norme ISO/IEC/IEEE 29119 retient la même idée.
En France, l'usage a imposé « test de non-régression » et son sigle TNR : on teste pour prouver l'absence de régression. Les deux expressions désignent exactement la même pratique. Une régression, c'est une fonctionnalité qui marchait dans la version précédente et qui ne marche plus dans la nouvelle.
Le TNR n'est pas un niveau de test, c'est un objectif. Il peut s'appuyer sur des tests unitaires, d'API ou d'interface. Leur bonne répartition est détaillée dans notre guide sur la pyramide des tests.
Retest, smoke test, TNR : quatre vérifications qui ne se remplacent pas
Le retest prouve qu'un bug est corrigé ; le TNR prouve que la correction n'a rien cassé ailleurs. Une équipe qui ne fait que des retests laisse passer exactement les défauts qui surprennent le plus ses utilisateurs.
| Vérification | Question posée | Périmètre | Moment |
|---|---|---|---|
| Retest (test de confirmation) | Le bug signalé est-il bien corrigé ? | Le seul scénario qui a révélé le défaut | Après chaque correction |
| Smoke test | L'application démarre-t-elle et ses fonctions vitales répondent-elles ? | Une poignée de vérifications rapides | À chaque déploiement, en quelques minutes |
| TNR ciblé | Les zones touchées par la modification fonctionnent-elles toujours ? | Les tests liés au code modifié et à ses dépendances | À chaque demande de fusion (pull request) |
| TNR complet | Tout ce qui marchait avant marche-t-il encore ? | L'ensemble du référentiel de non-régression | Chaque nuit ou avant une mise en production |
Six modifications qui doivent déclencher un TNR
Une régression ne vient pas seulement du code de l'équipe. Trois déclencheurs sur six n'impliquent aucune ligne modifiée dans votre application.
Une correction de bug
Corriger un défaut modifie du code partagé. Le retest vérifie la correction, le TNR vérifie qu'elle n'a rien cassé ailleurs.
Une nouvelle fonctionnalité
Elle s'appuie presque toujours sur des composants existants : formulaires, règles de calcul, droits d'accès.
Une mise à jour de dépendance
Framework, bibliothèque, navigateur ou version de langage : le code de l'équipe n'a pas bougé, son comportement si.
Un changement d'environnement
Nouvelle configuration, migration de base de données, changement d'hébergeur ou de version de système.
Un refactoring
Par définition, il ne doit rien changer au comportement visible. Seul un TNR permet de le prouver.
Une intégration externe modifiée
Une API de paiement, d'identification ou de logistique qui évolue peut casser un parcours sans aucune ligne modifiée chez vous.
La méthode en 5 étapes pour un TNR qui tient dans la durée
Un bon référentiel de non-régression se construit à partir du risque métier, pas à partir de la liste des fonctionnalités. Tester tout avec le même soin revient à ne rien prioriser.
-
1
Cartographier les parcours critiques
Listez les parcours dont la panne coûte de l'argent ou de la confiance : inscription, paiement, calculs réglementaires, exports. Notez pour chacun l'impact d'une panne et la fréquence d'usage. C'est cette note de risque qui fixe l'ordre de tout le reste.
-
2
Constituer le référentiel de non-régression
Pour chaque parcours retenu, gardez les scénarios qui couvrent le cas nominal et les cas limites qui ont déjà cassé. Ajoutez systématiquement un test à chaque défaut trouvé en production : le référentiel apprend de vos incidents.
-
3
Choisir la stratégie d'exécution
Tout relancer, sélectionner, prioriser ou réduire : la littérature de référence distingue ces quatre options (voir le tableau ci-dessous). Une équipe qui livre souvent combine en général une sélection à chaque modification et un passage complet la nuit.
-
4
Automatiser par paliers et brancher la CI
Automatisez d'abord les parcours les mieux notés, au niveau le plus bas possible de la pyramide (unitaire et API avant l'interface). Branchez chaque palier au pipeline : smoke test à chaque déploiement, TNR ciblé à chaque pull request, TNR complet chaque nuit.
-
5
Maintenir et mesurer
Un référentiel qui n'est pas entretenu se dégrade à chaque livraison. Suivez trois indicateurs : la durée d'exécution, la part de tests instables et le nombre de régressions qui atteignent malgré tout la production.
Quatre stratégies d'exécution, quatre compromis
La revue de référence de Shin Yoo et Mark Harman sur le test de régression classe les approches en trois familles (minimisation, sélection, priorisation), auxquelles s'ajoute la solution par défaut : tout relancer.
| Stratégie | Principe | Quand l'utiliser | Limite |
|---|---|---|---|
| Tout relancer (retest all) | Exécuter l'intégralité du référentiel à chaque modification | Petit référentiel rapide, ou avant une mise en production majeure | Le temps d'exécution croît avec chaque test ajouté |
| Sélection | N'exécuter que les tests liés au code modifié | Intégration continue avec des modifications fréquentes | Une dépendance mal tracée laisse passer une régression |
| Priorisation | Tout exécuter, mais dans l'ordre du risque, pour obtenir les échecs importants en premier | Référentiel long dont on veut un retour rapide | Ne réduit pas la durée totale |
| Minimisation | Supprimer les tests redondants qui couvrent la même chose | Référentiel ancien, gonflé au fil des années | Risque de retirer un test qui détectait un cas rare |
Brancher ces paliers au pipeline est le cœur du continuous testing. Pour le séquencement mois par mois, voyez notre stratégie pour passer de 0 à 80 % de tests automatisés.
Checklist : votre TNR est-il fiable ?
Cochez ce qui est vrai aujourd'hui dans votre équipe. En dessous de 7 sur 10, votre référentiel protège moins qu'il n'y paraît.
0 sur 10
Quand automatiser le TNR : d'abord ce qui se rejoue à chaque livraison
Un test automatisé est rentable quand le temps qu'il fait gagner à chaque exécution dépasse ce qu'il coûte à écrire et à maintenir. La fréquence d'exécution est donc le premier critère, avant même la complexité du scénario.
| Cas | Choix | Pourquoi |
|---|---|---|
| Parcours critique exécuté à chaque livraison | Automatiser en priorité | C'est là que le coût de la campagne manuelle se répète le plus |
| Règles de calcul, contrôles de données, API | Automatiser | Résultats déterministes, tests rapides et stables |
| Fonctionnalité dont l'interface change chaque sprint | Attendre qu'elle se stabilise | Le script coûterait plus en maintenance qu'il ne ferait gagner |
| Ergonomie, rendu visuel, ressenti utilisateur | Garder une part manuelle ou exploratoire | Un script vérifie ce qu'on lui dit de vérifier, pas ce qui gêne un humain |
| Scénario rare, joué une fois par an | Garder en manuel, avec un mode opératoire écrit | L'automatisation ne serait jamais amortie |
Ce que coûte une non-régression restée manuelle ne se limite pas aux heures de campagne : incidents en production, livraisons repoussées, équipes en mode pompier. Nous détaillons ces postes dans combien coûte le manque d'automatisation des tests, et la formule complète, maintenance comprise, dans le guide pour calculer le ROI de l'automatisation des tests.
Ce que l'IA change au TNR : exécuter moins de tests, mais les bons
Le principal apport de l'apprentissage automatique au TNR n'est pas d'écrire des tests, c'est de choisir lesquels exécuter. Les grands éditeurs de logiciels l'ont publié en premier, parce que leurs référentiels sont trop volumineux pour être relancés en entier à chaque modification.
des régressions détectées par la sélection prédictive de Meta avant d'atteindre les autres ingénieurs
seulement des tests dépendant du code modifié sont exécutés pour obtenir ce résultat
des passages de « réussi » à « échoué » observés chez Google impliquent un test instable
Ce que l'IA apporte au TNR
- Sélectionner les tests les plus susceptibles d'échouer pour une modification donnée, à partir de l'historique des exécutions.
- Prioriser l'ordre d'exécution pour obtenir les échecs importants dans les premières minutes.
- Repérer les tests instables et distinguer un faux échec d'une vraie régression.
- Réparer des sélecteurs cassés après une modification de l'interface, ce qui allège la maintenance.
Ce qui reste une décision humaine
- Définir les parcours critiques : l'historique des tests ne dit pas quel parcours fait perdre de l'argent quand il tombe.
- Accepter le risque résiduel : une sélection qui rate 0,1 % des régressions est un choix, à assumer pour les parcours les plus sensibles.
- Qualifier un échec et décider de bloquer ou non une mise en production.
- Vérifier qu'une réparation automatique n'a pas masqué un vrai changement de comportement.
C'est ce que nous appelons l'automatisation intelligente des tests : protéger en priorité ce qui porte la valeur, s'appuyer sur l'IA là où elle est fiable, et mesurer l'effet sur la livraison. Les autres usages de l'IA qui tiennent leurs promesses sont détaillés dans IA générative dans les tests : ce qui marche vraiment. Côté outillage, le guide Playwright 2026 montre comment paralléliser une suite de non-régression en CI.
Cinq erreurs qui rendent un TNR inutile
Un référentiel de non-régression peut tourner tous les jours et ne protéger presque rien. Ces erreurs en sont les causes les plus fréquentes.
- Rejouer tout le référentiel à la main avant chaque mise en production : la campagne s'allonge à chaque version, jusqu'à devenir le goulot de la livraison.
- Confondre retest et non-régression : vérifier que le bug est corrigé ne dit rien de ce que la correction a pu casser ailleurs.
- Automatiser le TNR uniquement par l'interface : la suite devient lente et fragile, alors qu'une grande partie des régressions se détecte plus bas, sur les API et les règles métier.
- Laisser les tests instables en place et relancer jusqu'au vert : l'équipe apprend à ignorer les échecs, y compris les vrais.
- Ne jamais retirer de tests : un référentiel qui ne fait que grossir finit par prendre plus de temps qu'il n'en fait gagner.
La protection contre la régression est l'une des six missions du testeur, détaillées dans notre guide QA : définition, rôle du testeur et Quality Engineering.
Questions fréquentes sur le test de non-régression
Qu'est-ce qu'un test de non-régression ?
Un test de non-régression (TNR) vérifie qu'une modification du logiciel n'a pas introduit de défaut dans les parties qui n'ont pas été modifiées. Le glossaire ISTQB le classe parmi les tests liés aux changements. En français, on dit indifféremment test de régression ou test de non-régression : les deux désignent la même pratique.
Quelle est la différence entre un retest et un test de non-régression ?
Le retest, ou test de confirmation, rejoue le scénario qui a révélé un bug pour vérifier qu'il est corrigé. Le test de non-régression vérifie que cette correction, ou toute autre modification, n'a rien cassé ailleurs. Une correction validée par un retest peut parfaitement provoquer une régression sur un autre parcours.
Quand faut-il lancer des tests de non-régression ?
Après toute modification susceptible de changer le comportement du logiciel : correction de bug, nouvelle fonctionnalité, mise à jour d'une dépendance, changement d'environnement, refactoring ou évolution d'une API externe. Dans une équipe qui pratique l'intégration continue, un TNR ciblé tourne à chaque pull request et un TNR complet chaque nuit.
Faut-il automatiser tous les tests de non-régression ?
Non. Il faut automatiser en priorité les parcours critiques rejoués à chaque livraison, les règles de calcul et les API, dont les résultats sont stables. Les vérifications d'ergonomie, les fonctionnalités dont l'interface change encore chaque sprint et les scénarios joués une fois par an restent souvent plus rentables en manuel.
Comment réduire la durée d'une campagne de non-régression ?
Quatre leviers existent : sélectionner les tests liés au code modifié, prioriser les tests les plus risqués pour obtenir les échecs importants en premier, supprimer les tests redondants, et paralléliser l'exécution sur plusieurs machines. Descendre les vérifications au niveau API ou unitaire, plus rapide que l'interface, est souvent le gain le plus important.
Que faire des tests instables dans un référentiel de non-régression ?
Les isoler rapidement, en chercher la cause (attente mal gérée, données partagées, dépendance externe) et les corriger. Chez Google, environ 1,5 % des exécutions de tests donnent un résultat instable et près de 16 % des tests présentent une forme d'instabilité. Un test instable laissé en place apprend à l'équipe à ignorer les échecs.
L'IA peut-elle gérer les tests de non-régression ?
Elle aide sur des tâches précises : choisir les tests à exécuter selon la modification, réparer des sélecteurs cassés, trier les échecs. Meta indique que son système de sélection prédictive détecte plus de 99,9 % des régressions en n'exécutant qu'un tiers des tests concernés. Le choix des parcours critiques et la décision de bloquer une livraison restent humains.
Pour aller plus loin
Sources
- ISTQB Glossary, définitions de regression testing et confirmation testing
- ISO/IEC/IEEE 29119-1:2022, Software and systems engineering, Software testing, Part 1: General concepts
- Shin Yoo et Mark Harman, Regression testing minimization, selection and prioritization: a survey, Software Testing, Verification and Reliability, 2012
- Meta Engineering, Predictive test selection, 21 novembre 2018
- John Micco, Flaky Tests at Google and How We Mitigate Them, Google Testing Blog, 27 mai 2016
Le calculateur de rentabilité est un outil indicatif : il compare uniquement le temps de campagne manuelle au coût d'automatisation et de maintenance saisis. Les valeurs proposées par défaut sont des exemples à remplacer par les vôtres.
Votre TNR protège-t-il vraiment vos livraisons ?
Automate Score évalue la maturité de votre automatisation des tests sur cinq dimensions et vous indique les chantiers qui auront le plus d'impact sur vos livraisons.
Des recommandations priorisées, exprimées en langage business