Tests au vert, fonctionnalité cassée
Une équipe que je connais a livré un résumeur de support IA avec une suite de tests entièrement au vert, et l'a vu la couvrir de honte en production en une semaine. Les tests unitaires passaient tous, parce qu'ils vérifiaient le code autour du modèle — l'appel d'API, le parsing, l'écriture en base. Ce qu'aucun test ne vérifiait, c'était si le résumé était réellement correct, parce que le même ticket pouvait produire un bon résumé lundi et un résumé subtilement faux mardi.
Tout le problème tient dans cette phrase. Les tests traditionnels reposent sur le déterminisme : une même entrée donne une même sortie, donc on assertionne sur la sortie. Un modèle de langage rompt ce contrat. La sortie est une distribution, pas une valeur. On ne peut pas écrire assertEquals contre un paragraphe qui change à chaque exécution, et c'est pourquoi un build vert ne dit presque rien sur le bon fonctionnement de votre fonctionnalité IA.
Ce qu'est réellement une éval
Une éval est un test dont l'assertion est un jugement sur la qualité, pas une égalité exacte. Au lieu de « la sortie vaut-elle X », elle demande « cette sortie est-elle assez bonne, assez souvent, sur les cas qui comptent ». On assemble un jeu d'entrées représentatives, on définit à quoi ressemble une bonne réponse, on exécute le modèle dessus et on note les résultats — parfois avec des règles, parfois avec un modèle plus fort en juge, parfois avec un humain dans la boucle.
Ce n'est pas une idée marginale. OpenAI a mis en open source son framework Evals(lien externe, nouvel onglet) précisément pour que les équipes puissent codifier cela, et des travaux académiques comme le benchmark HELM(lien externe, nouvel onglet) de Stanford ont formalisé la pratique consistant à noter les modèles sur de nombreuses dimensions plutôt que sur un seul chiffre de précision. Le changement, c'est que les évals sortent des labos de recherche pour entrer dans les équipes produit ordinaires, comme les tests automatisés sont passés d'une affaire de spécialistes à un défaut dans les années 2000.
Pourquoi c'est plus urgent que l'an dernier
Les évals sont devenues urgentes dès que les fonctionnalités IA se sont mises à décider au lieu de simplement générer du texte. Quand un modèle rédige un message qu'un humain relira, une mauvaise sortie est agaçante. Quand un agent déclenche un remboursement, met à jour un enregistrement ou route un ticket tout seul, une mauvaise sortie est un incident. Le rayon d'impact a grandi, et la seule défense qui passe à l'échelle, c'est de mesurer la qualité systématiquement avant la mise en prod et en continu après.
Il y a aussi un angle livraison. Je soutenais dans l'IA écrit plus de code mais livre moins de logiciel que le goulot n'est pas la production brute, c'est la confiance. Les évals, c'est la manière de fabriquer cette confiance. Sans elles, chaque montée de modèle, ajustement de prompt ou nouvelle source de données est un changement à l'aveugle. Avec elles, on répond à la seule question qui compte : ce changement a-t-il rendu le produit meilleur ou pire, et de combien ?
Évals et observabilité sont deux moitiés d'une même chose
Les évals attrapent les problèmes de qualité avant la sortie ; l'observabilité les attrape après — et il faut les deux. Je défendais dans l'observabilité est la gouvernance IA que vous connaissez déjà que les logs, le tracing et le monitoring sont la manière de gouverner l'IA en production. Les évals en sont le pendant pré-production. L'une est votre suite de tests, l'autre votre surveillance. Les équipes qui ont l'observabilité mais pas d'évals apprennent les régressions par leurs utilisateurs. Celles qui ont des évals mais pas d'observabilité livrent en confiance puis deviennent aveugles dès que le trafic réel arrive.
Les meilleurs dispositifs bouclent la boucle : les traces de production font remonter les cas où le modèle a peiné, ces cas deviennent de nouveaux exemples d'éval, et le jeu d'évals grandit pour refléter la réalité plutôt que ce que l'équipe imaginait au lancement. Cette boucle de rétroaction fait la différence entre une fonctionnalité IA qui s'améliore avec le temps et une qui pourrit en silence.
Comment démarrer sans vouloir tout couvrir
Construire un jeu d'évals est moins intimidant qu'il n'y paraît si l'on part des vraies pannes plutôt que de viser l'exhaustivité. Rassemblez vingt à cinquante entrées réelles, en incluant idéalement les cas limites moches qui vous ont déjà brûlé. Notez, en clair, à quoi ressemble une bonne et une mauvaise réponse pour chacune. Exécutez votre configuration actuelle, notez-la, et vous avez une référence. Désormais chaque changement se mesure contre cette référence au lieu du ressenti — exactement la discipline qui manque quand on livre au feeling, le piège que je décrivais dans le vibe coding ne sauvera pas votre produit.
Commencez petit, branchez-le dans la CI pour qu'il tourne à chaque changement de prompt ou de modèle, et faites grandir le jeu à partir des pannes de production. L'objectif n'est pas un benchmark parfait. C'est une réponse répétable à « est-ce mieux ou moins bien qu'avant ».
Le Takeaway
Si vous avez une fonctionnalité IA en production et aucun jeu d'évals, vous livrez sur la foi. Prenez votre fonctionnalité IA la plus risquée, rassemblez trente entrées réelles, définissez le bon et le mauvais, et notez votre version actuelle cette semaine. Ce chiffre est votre référence — et la première fois qu'une mise à jour de modèle le dégradera en silence, vous serez content de l'avoir.
