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.
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.
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.
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.
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, 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.
L’accompagnement Agenticiel pour poser votre filet de tests
Construire un jeu de cas de référence et le brancher sur l’intégration continue demande une méthode et un peu de pratique, deux choses qu’une équipe qui découvre l’IA n’a pas encore. Agenticiel aide les PME et les éditeurs à poser ce filet de tests, à partir de leurs cas réels, et à l’intégrer dans leur cycle de développement.
Nous commençons par extraire les cas de référence de vos usages réels, puis nous mettons en place les vérifications adaptées, des assertions déterministes au jugement par modèle, avec le calibrage nécessaire. Nous branchons ensuite l’ensemble sur votre intégration continue, pour que chaque changement soit mesuré avant d’atteindre vos utilisateurs. Le travail est mené par une équipe de développeurs offshore francophones, basée à Madagascar, qui échange avec vous dans votre langue et sur vos horaires. La sous-traitance de développement vous apporte cette rigueur sans que vous ayez à la construire seuls.
Notre approche consiste à transformer chaque changement en décision mesurée : on pose les cas de référence, on automatise la vérification, et vos itérations deviennent sûres au lieu d’être un pari.