Dans le développement classique, une régression se détecte par un test qui échoue. Dans les systèmes d’IA, la même situation est bien plus floue : on change un prompt, on passe à un nouveau modèle, et la réponse devient légèrement moins bonne, sans que rien ne signale l’échec. Le système continue de répondre, mais il répond moins juste, et personne ne le voit. C’est une régression silencieuse, et c’est la plus dangereuse.
La difficulté vient de ce que la sortie d’un modèle n’est pas déterministe et n’est pas binaire. On ne peut pas écrire un test qui affirme « la réponse doit être exactement ceci ». En revanche, on peut écrire un test qui vérifie des propriétés : la réponse contient la bonne information, elle respecte le format attendu, elle ne produit pas d’erreur connue. C’est le principe des tests de non-régression pour l’IA.
Cet article explique comment construire ce filet, à partir d’un jeu de cas de référence, en le branchant sur votre intégration continue, et en mesurant ce qui compte réellement. L’objectif : rendre chaque changement de prompt ou de modèle aussi sûr qu’un changement de code classique. Si la notion d’évaluation est nouvelle pour vous, commencez par les evals expliquées : les tests de non-régression en sont l’usage le plus quotidien.
Le jeu de cas de référence, la fondation
Tout repose sur un jeu de cas de référence : un ensemble de questions ou de situations, accompagnées de ce qu’on attend du système. Ce jeu n’a pas besoin d’être énorme pour être utile. Une cinquantaine de cas bien choisis, couvrant les usages les plus fréquents et les échecs les plus coûteux, détecte déjà la grande majorité des régressions.
La qualité du jeu compte plus que sa taille. Les cas doivent être réels, pas inventés : des questions posées par de vrais utilisateurs, des tickets de support, des situations observées en production. Un cas réel porte avec lui le piège qui a réellement fait échouer le système, et c’est exactement ce qu’un cas fabriqué ne capture pas.
Pour chaque cas, il faut définir ce qu’on vérifie. La forme la plus robuste est l’assertion sur le contenu : la réponse doit mentionner telle information, ne doit pas affirmer telle erreur, doit respecter tel format. C’est ce qui permet d’automatiser la vérification sans dépendre d’une correspondance exacte.
Ce qu’on peut vérifier automatiquement
Toutes les propriétés ne se vérifient pas de la même façon. Les plus faciles à automatiser sont les propriétés structurelles : le format de sortie, la présence de champs obligatoires, le respect d’un schéma JSON, l’absence de contenu interdit. Ces tests sont déterministes et fiables, et ils détectent une classe entière de régressions liées aux changements de format. Un schéma Pydantic ou Zod, validé à chaque réponse, en couvre une bonne partie.
Viennent ensuite les propriétés de contenu, vérifiées par des règles ou par des modèles. On peut vérifier qu’une réponse contient une information précise par une simple recherche de motif, ou qu’elle n’affirme pas un fait connu comme faux. Pour les cas plus nuancés, on recourt à un modèle qui juge : un second modèle, différent de celui qui génère, évalue si la réponse répond correctement au cas de référence. Ce « juge » introduit une part d’aléa, mais il reste utile tant qu’on le combine à des vérifications déterministes. Promptfoo combine les deux dans un même fichier de test (assertions sur le contenu et grille d’évaluation par LLM), DeepEval s’utilise comme une suite de tests Python, et Ragas apporte des métriques dédiées au RAG comme la fidélité aux sources. Plusieurs outils outillent cette démarche, comparés dans notre comparatif des outils d’évaluation d’agents.
La règle est de privilégier le déterministe quand c’est possible, et de réserver le jugement par modèle aux propriétés qu’on ne peut pas exprimer autrement. Un test de non-régression qui échoue de façon aléatoire perd sa valeur, parce qu’on finit par ne plus l’écouter.
Brancher les tests sur l’intégration continue
Un jeu de cas ne sert à rien s’il n’est pas exécuté. Il faut le brancher sur l’intégration continue, pour que chaque changement de prompt, de modèle ou de code déclenche l’exécution de la jauge et compare les résultats à la référence. C’est ce qui transforme des tests ponctuels en filet permanent. Concrètement, un job GitHub Actions ou GitLab CI lance Promptfoo ou DeepEval sur chaque pull request et publie le score. La mise en place du pipeline lui-même est détaillée dans CI/CD pour agents IA.
Le fonctionnement est simple en principe : à chaque modification, on rejoue les cas de référence, on mesure le taux de réussite, et on compare au taux précédent. Si le taux baisse de façon significative, la modification est bloquée ou signalée. Le seuil de tolérance se règle : une petite variation d’un cas non déterministe est acceptable, une chute nette sur plusieurs cas ne l’est pas.
Le point délicat est le coût d’exécution. Rejouer cinquante cas à chaque changement consomme des tokens et du temps. On peut réduire ce coût en n’exécutant qu’une partie du jeu sur chaque changement de prompt, et le jeu complet sur les changements plus structurants, comme un changement de modèle. L’important est que le filet existe et qu’il tourne, pas qu’il soit exhaustif à chaque commit.
Mesurer la justesse, pas seulement l’absence d’échec
Un test de non-régression classique vérifie que rien ne casse. Pour l’IA, il faut aussi vérifier que la qualité ne glisse pas, et cela demande une métrique qui ne soit pas binaire. La plus simple est le taux de réussite sur le jeu de référence : la proportion de cas où la réponse vérifiée est correcte.
Cette métrique a une limite : elle dépend de la qualité des vérifications. Si le juge est indulgent, le taux grimpe sans que la qualité réelle s’améliore. C’est pourquoi il faut périodiquement contrôler le juge lui-même, en vérifiant qu’il note correctement un échantillon de cas, et le recalibrer si nécessaire.
Une seconde métrique utile est le coût par réponse correcte. Deux systèmes peuvent avoir le même taux de réussite, l’un avec un modèle léger, l’autre avec un modèle dix fois plus cher. Mesurer le coût par réponse juste évite d’accepter une « amélioration » qui coûte plus cher sans apporter de gain réel.
Le cycle vertueux : échec, cas, correction, test
Les tests de non-régression pour l’IA ne se construisent pas d’un coup, ils se nourrissent des échecs. À chaque régression constatée en production, repérée dans les traces Langfuse ou LangSmith, on ajoute le cas au jeu de référence, puis on corrige, puis on vérifie que le nouveau cas passe. C’est le même cycle que dans le développement classique : chaque bug devient un test qui empêche sa réapparition.
Ce cycle a une vertu particulière pour l’IA : il transforme un système fragile, où chaque changement est un pari, en un système maîtrisé, où chaque changement est mesuré. L’équipe qui vit ce cycle pendant quelques semaines ne revient jamais à l’ajustement de prompt à l’aveugle, parce qu’elle a constaté la différence entre deviner et savoir.
Le résultat concret est un gain de temps massif. On ne passe plus des heures à re-tester manuellement après chaque changement, on lit le résultat de la jauge. Et surtout, on détecte les régressions avant les utilisateurs, ce qui est la définition même d’un test qui remplit son rôle.
Les tests automatisés ne remplacent pas toute la recette : la QA fonctionnelle sans laisser passer de bugs en production rappelle ce qui reste à vérifier à la main.
Le premier pas pour poser votre filet de tests
Le premier pas est modeste : prenez vingt à trente cas réels dans vos logs ou votre support, écrivez pour chacun deux ou trois assertions, et faites-les tourner avant chaque mise en production, même à la main au début. Le branchement sur la CI, le juge par modèle et le suivi du coût par réponse correcte viennent ensuite, une fois que l’équipe a pris l’habitude de regarder le score avant de livrer.
Sur les agents qu’on construit, ce filet est en place avant la première mise en ligne : c’est l’un des piliers de notre méthode, avec la CI/CD et les garde-fous.
