Il existe un schéma que nous observons dans presque chaque système à base d'agents IA en production depuis plus de six mois : un dossier nommé evals/ contenant 40 scénarios écrits avec enthousiasme en deuxième semaine, et un last_run.json antérieur au dernier changement de prompt.
Ce n'est pas une suite d'evals. C'est une capture d'écran d'une réunion de mars.
Le problème des deux missions
Quand une suite d'evals vit en dehors de la CI, elle finit par servir deux missions qui tirent dans des directions opposées :
- Se convaincre soi-même que le système marche (lancer une fois, démontrer, archiver)
- Attraper les régressions avant les utilisateurs (tourner à chaque changement, bloquer les releases)
La première mission récompense l'exhaustivité — écrire 200 cas couvrant chaque coin. La seconde récompense la rapidité — tourner en moins de cinq minutes ou personne n'attendra.
Hors CI, la suite tend à dériver vers la première mission, parce que la seconde n'a aucune contrainte. Le résultat : une suite impressionnante en démo et inutile en pratique.
Ce que « dans la CI » signifie vraiment
Trois choses concrètes, par ordre de coût :
- Un sous-ensemble tourne sur chaque PR. Sélectionnez 20 à 40 cas rapides et à forte couverture. Ils doivent finir en moins de 90 secondes et bloquer le merge en cas d'échec.
- La suite complète tourne chaque nuit sur la branche main. Les échecs paginent quelqu'un — pas la rotation on-call, mais le propriétaire du prompt.
- Les deltas de score sont suivis dans le temps. Pas seulement pass/fail. Une régression de 4 % sur la précision des citations qui ne déclenche pas un hard gate reste une régression.
Le deuxième point — les échecs paginent un propriétaire — c'est la partie que les équipes sautent, puis se demandent pourquoi la dérive s'accumule.
Ce que nous livrons avec chaque système
Une cible pnpm eval (ou équivalent) qui lance le sous-ensemble rapide en local en moins de deux minutes. Une GitHub Action qui fait pareil sur PR. Un nightly qui lance l'ensemble complet contre les prompts de prod. Et un tableau de bord avec deux graphiques : taux de réussite par tag, et taux de réussite dans le temps.
C'est tout. Rien de nouveau dans cette liste. La nouveauté, c'est que c'est branché dès le premier jour et que ça reste branché après notre départ.
Pourquoi ça marche
Les ingénieurs n'écriront pas d'evals pour des systèmes qui ne les imposent pas. La suite d'evals n'est pas un artefact moral, c'est une pièce porteuse de la pyramide de tests. Mettez-la là où vivent les autres tests.