Test de régression pour systèmes IA — mesurer les dérives d'un agent

En bref

Imaginez un cuisinier qui prépare un plat-signature à votre restaurant chaque semaine. Si vous ne le goûtez jamais, vous ne saurez pas s’il glisse vers le trop salé ou perd sa subtilité. Pour les systèmes IA, c’est pire : ils évoluent silencieusement à chaque mise à jour de modèle ou de prompt, sans notification, sans bug visible. Le test de régression pour systèmes IA, c’est le palais entraîné qu’on garde calibré sur une recette de référence — un corpus figé, exécuté régulièrement, comparé à une baseline historique. Sans cet instrument de mesure fixe, impossible de savoir si le système s’améliore ou se dégrade. Nos tests montrent qu’un corpus d’une cinquantaine de cas, décomposé par difficulté, suffit à détecter la plupart des dérives — et à révéler des biais comportementaux que les scores globaux masquent.

Pourquoi mesurer systématiquement

Un logiciel classique est déterministe : mêmes entrées, même sortie. Un test qui passe aujourd’hui passe demain, sauf si le code change. Le bug, quand il apparaît, est une régression évidente.

Un système IA ne fonctionne pas ainsi. Trois sources de variation coexistent :

• Stochasticité du modèle. Même à température basse, un LLM peut produire des sorties légèrement différentes sur le même prompt. L’effet devient significatif sur les cas limites. Lau (2026, arXiv:2603.04417) documente des variances substantielles entre appels répétés à temperature=0 selon les modèles.
• Évolution silencieuse. Les fournisseurs de modèles mettent à jour leurs endpoints sans toujours annoncer les changements. Un même identifiant de modèle peut couvrir plusieurs versions internes dans le temps.
• Dérive du pipeline. Un agent IA est rarement un appel unique : c’est une chaîne d’instructions, d’outils et de prompts. Une correction dans une brique peut dégrader le comportement ailleurs, sans que l’auteur du fix ne le voie.

Sans mesure répétée sur un jeu d’entrées figées, on navigue à vue. Le test de régression n’est pas une garantie — c’est l’instrument qui signale qu’une enquête est nécessaire.

En clair : un test classique vous dit “ça marche ou pas”. Un test de régression IA vous dit “où on en est par rapport à la dernière mesure”. Le delta — gain ou dégradation — est plus informatif que le score absolu, parce qu’un score brut de 0,90 peut être très bon ou catastrophique selon le score précédent (0,75 ou 0,98).

Construire un corpus de référence

Un corpus de référence utile respecte quatre principes.

Cas réels, pas synthétiques. Le corpus doit refléter les situations rencontrées en production. Un benchmark général type MMLU est utile pour classer des modèles entre eux, mais il ne dit rien sur la fiabilité d’un agent spécialisé face à ses propres entrées. Les cas sont extraits des logs, anonymisés si nécessaire, et fixés.

Décomposition par difficulté. Mélanger tous les cas dans une moyenne cache l’essentiel. Une décomposition utile : faciles (doivent toujours passer, régression claire), moyens (zone de travail normale, où l’amélioration se joue), difficiles (limites connues du système, pas toujours résolvables).

Cas piégés. Une catégorie spécifique mérite un traitement à part : les cas où la bonne réponse est de ne rien faire ou refuser. Un agent qui sur-agit coûte aussi cher qu’un agent qui sous-agit. Sans cas piégés, le corpus ne mesure que la production — pas la retenue.

Taille minimale. En dessous de ~50 cas, les scores sont trop bruités pour être comparables. Nos tests portent sur un corpus de 50 cas répartis sur trois opérations distinctes (18, 18 et 14 cas respectivement). La répartition par niveau est d’au moins 10 cas par niveau, avec 11 cas piégés explicites.

Une fois le corpus construit, il est figé. Modifier un cas après coup invalide la comparaison historique. Les ajouts vont dans une version numérotée distincte.

En clair : la décomposition par difficulté est ce qui rend le test informatif. Un score global de 90 % peut signifier “100 % faciles + 80 % moyens + 80 % difficiles” (régression sur les difficiles attendue, pas alarmante) OU “70 % faciles + 100 % moyens + 100 % difficiles” (régression critique sur les fondamentaux). Sans décomposition, ces deux situations ressemblent au même chiffre.

Faire tourner le test

L’exécution elle-même demande quelques précautions.

Masquer les réponses attendues avant exécution. Si la ground truth est accessible au système au moment de la prédiction — dans le même fichier, dans un cache, dans un prompt — les scores observés ne mesurent plus la capacité à résoudre, mais la capacité à copier. Le masquage se fait hors du périmètre du système : les attendus sont retirés du paquet envoyé, conservés séparément pour le scoring final.

Lancer à froid. Un système qui garde un historique de runs précédents n’est pas dans les mêmes conditions qu’un système neuf. Le protocole : relancer le système sans contexte préchargé, ne charger que les entrées du corpus, capturer les prédictions, puis scorer.

Scorer automatiquement. Le scoring doit être déterministe et indépendant du système mesuré. Pour une classification, c’est trivial. Pour une génération, on définit des critères mesurables (fidélité, présence de champs, contrainte format) et on écrit un scorer qui les évalue mécaniquement. L’évaluation par LLM est possible mais introduit ses propres biais — ce pattern est décrit dans l’article sur l’auto-évaluation.

Protocole en trois phases. Dans l’ordre : (1) préparation du paquet masqué, (2) prédiction par le système à froid, (3) scoring. La séparation garantit que chaque phase est auditable indépendamment.

Nos tests sur ce protocole donnent un score global de 0.938 sur 50 cas, comparé à une exécution antérieure qui culminait à 0.909 — un delta de +0.029 attribuable à la correction d’une contamination de ground truth dans la version précédente.

En clair : le masquage de ground truth n’est pas une précaution exagérée. Sans lui, le système peut “voir” la bonne réponse dans son contexte (cache, fichier voisin, prompt mal isolé) et la copier — vous mesurez alors la copie, pas la résolution. Tout protocole sans masquage explicite est suspect par défaut.

Ce que révèle le test

Le score global est le moins informatif des résultats. Les enseignements réels viennent de la décomposition.

Par opération. Un score global de 0.94 peut masquer une opération à 1.00 et une autre à 0.88. Nos tests observent exactement ce pattern : routage à 1.000, insertion à 0.889, propagation à 0.911. L’opération fragile — l’insertion — concentre l’attention des révisions ultérieures.

Par difficulté. Un système peut atteindre 100 % sur les cas faciles et chuter sur les cas difficiles. C’est attendu. Ce qui alarme, c’est l’inverse : un score moyen sur les faciles (régression sur ce qui passait avant) alors que les difficiles tiennent. Ce schéma signale une dégradation récente et ciblée, plus grave qu’une limite historique.

Cas piégés. Nos tests atteignent 100 % sur les 11 cas piégés. Un ratio inférieur à 90 % sur cette catégorie est un signal fort : le système sur-agit, produit quand il ne devrait pas, remplit quand il devrait se taire.

Surprise fréquente : découverte de biais comportementaux. Plus que le score, la liste des cas ratés raconte le comportement. Nos tests ont révélé une tendance spécifique sur les cas frontières d’insertion et de propagation : le système ajoute des éléments non demandés — un classifieur qui propose deux étiquettes là où une seule est attendue, un agent de propagation qui touche à un second périmètre non sollicité. Ce biais de sur-inclusion n’est pas visible sur le score global et n’apparaît pas sur les cas faciles. Sans décomposition, il resterait invisible jusqu’à la panne en production.

Ribeiro et al. (2020, ACL) théorisent cette approche sous le nom de behavioral testing : les tests ne mesurent pas un score, ils décrivent un comportement attendu sur des familles de cas. Amershi et al. (2019, ICSE-SEIP) recensent cette pratique comme une des neuf spécificités de l’ingénierie logicielle appliquée au machine learning.

Quel format de test pour quel besoin

Ce qu’il faut retenir

• Un système IA sans corpus de référence reproductible est invérifiable dans le temps. Le test de régression n’est pas une garantie, c’est l’instrument qui signale qu’une enquête est nécessaire.
• Un corpus utile comprend des cas réels, décomposés par difficulté, avec une catégorie explicite de cas où ne rien faire est la bonne réponse.
• Le protocole — masquage de la ground truth, exécution à froid, scoring indépendant — conditionne la validité du résultat. Un run sans masquage mesure la copie, pas la résolution.
• Décomposer le score par opération et par difficulté révèle ce que la moyenne cache : zones fragiles, régressions récentes, tendances comportementales.
• La découverte de biais latents — sur-inclusion, sur-confiance, dépendance à un format — fait partie du protocole, pas un échec. Le test existe pour les exposer.