Les évals sont la spec d’une fonction IA

Une fonction bâtie sur un modèle de langage répond différemment à chaque fois qu’on l’interroge. Cela casse la phrase sur laquelle repose tout document d’exigences : « ça marche ». Cet article porte sur ce qui la remplace, sur qui écrit le remplacement, et sur ce que le studio a appris en spécifiant huit environnements IA dans un même produit.

Pourquoi « ça marche » ne suffit-il pas pour une fonction IA ?

Parce qu’il n’y a pas une sortie unique à vérifier. Une fonction déterministe est recettée une fois ; une fonction adossée à un modèle doit être recettée statistiquement, sur les cas qui comptent, et à nouveau à chaque changement de prompt ou de modèle. Hamel Husain, consultant IA qui livre ces systèmes depuis 2023, écrivait le 29 mars 2024 que les produits IA qui échouent « almost always share a common root cause: a failure to create robust evaluation systems ». Les équipes qui échouent jouent à la taupe : on corrige une réponse, on en casse une autre, et on ne sait jamais où l’on en est.

Qu’est-ce qu’une éval, en termes produit ?

Une spécification en trois parties, écrite dans la langue du lecteur et détenue par le rôle produit.

• Les cas qu’elle doit traiter : des entrées réelles, idéalement issues de vrais utilisateurs ou de journaux, chacune avec ce que contient une bonne réponse.
• Les cas où elle doit refuser : les questions hors périmètre, les données qu’elle ne doit jamais révéler, les actions qu’elle ne doit jamais prétendre avoir faites.
• La tolérance : combien de fois elle peut rater sur chaque ensemble avant que la fonction soit retirée, exprimée par un chiffre qu’une personne a signé.

Husain décrit trois niveaux de test qui correspondent à ces parties : des assertions peu coûteuses exécutées à chaque changement, une revue humaine et par modèle des traces journalisées, et des tests A/B avec de vrais utilisateurs. Les deux premiers sont l’éval. La spec est une liste de cas et un chiffre, et le chiffre est une décision produit parce qu’il échange de la qualité contre de la livraison.

Qui l’écrit ?

La personne qui écrirait sinon les critères d’acceptation. Un ingénieur peut écrire le banc de test ; seul le rôle produit peut dire quels vingt cas comptent, quels refus sont non négociables et quel taux de raté l’entreprise tolère. Le guide d’Anthropic sur la conception d’agents, publié le 19 décembre 2024, fait le même point côté architecture : trouver « the simplest solution possible, and only increasing complexity when needed », et préférer un workflow prédéfini à un agent autonome partout où les étapes peuvent être connues d’avance. Ce choix est une décision de spec, et c’est celui qui possède les cas qui la prend.

Qu’a appris le studio en le faisant ?

Torn Studio a tenu le rôle produit chez Changemkr, une plateforme IA de conduite du changement dont le studio est copropriétaire, jusqu’en juin 2026. À la limite de juin, huit environnements IA tournaient sur un seul service, chacun avec son modèle, ses outils et son versionnage de prompts avec retour arrière en un clic, comptables dans le registre de prompts. Chaque changement de prompt était une livraison, et chaque livraison était recettée contre ses cas.

En juin 2026, un cabinet de conseil externe a testé l’assistant IA du planificateur et l’a signalé comme peu fiable. Le studio a transformé le rapport en 27 constats numérotés, les a groupés par cause racine avant de toucher au code, et a trouvé que 4 des 27 étaient des décisions produit sans aucune correction de code : la fonction faisait ce qu’on lui avait dit, et ce qu’on lui avait dit était faux. Cette séparation, bug ou décision, est ce qu’une éval rend visible avant qu’un testeur ne le fasse.

La vérification est là où se trouve la limite honnête. Les corrections ont été exécutées contre la pile complète en conteneurs avec des tests navigateur : 11 réussis, 1 ignoré, et les trois grands flux génératifs n’ont jamais été vérifiés de bout en bout, parce que leurs sorties varient d’une exécution à l’autre et qu’un test attendant la même sortie à chaque fois ne peut pas les porter. Le rapport le dit par constat, et c’est l’essentiel : une vérification qui se déclare entièrement verte est une vérification à laquelle personne ne fera confiance la fois suivante.

Où intervient la confiance ?

Une éval couvre l’exactitude ; les cas de refus et d’information couvrent la confiance, et ils appartiennent au même document. Le People + AI Guidebook de Google PAIR demande aux équipes de calibrer la confiance — « tell the user when a lack of data might mean they’ll need to use their own judgment » — et d’afficher la certitude par catégories. La page de la Commission européenne sur l’AI Act indique que les chatbots doivent faire savoir aux personnes qu’elles interagissent avec une machine, avec des règles de transparence applicables à partir d’août 2026, et renvoie au texte. Comment une fonction gagne cette confiance est un article à part ; l’éval est l’endroit où les cas sont écrits en premier.

Où le modèle se place dans un système existant — la tâche bornée avec une vérification autour — est traité dans l’IA dans vos systèmes existants. Les cas d’une éval se choisissent comme on priorise un backlog, et cette méthode est dans décider quoi construire ensuite.

Comment le studio spécifie une fonction IA

Le Product Management chez Torn Studio est tarifé par mission, le prix fixé avant le début du travail, et une fonction IA dans le périmètre reçoit son éval avant son prompt : les cas, les refus, la tolérance, signés par la personne qui lira le chiffre. Le studio construit ensuite contre elle, de sorte que la fonction est livrée avec le document qui dit ce qu’elle peut faire et où elle doit refuser.