--- title: "Les évals sont la spec d’une fonction IA" description: "Comment spécifier une fonction bâtie sur un modèle qui répond différemment à chaque fois : cas de test, tolérance et qui les écrit, avec les chiffres du studio." url: https://torn.studio/fr/articles/les-evals-sont-la-spec locale: fr published: 2026-09-07 --- # Les évals sont la spec d’une fonction IA > **Réponse courte:** Une fonction IA se spécifie comme une éval : les cas qu’elle doit traiter, les cas où elle doit refuser, et une tolérance sur la fréquence des ratés, convenus avant le premier prompt. Le constat de Hamel Husain en mars 2024 : les produits IA qui échouent partagent presque toujours une cause, l’absence d’évaluation robuste. Le rôle produit écrit l’éval. 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](https://torn.studio/fr/articles/ia-dans-vos-systemes-existants). Les cas d’une éval se choisissent comme on priorise un backlog, et cette méthode est dans [décider quoi construire ensuite](https://torn.studio/fr/articles/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. **À lire ensuite** - [Product Management chez Torn Studio](https://torn.studio/fr/prestations/product-management) ## Questions fréquentes ### Qu’est-ce qu’une éval pour une fonction IA ? Un ensemble écrit de cas de test et une tolérance : les entrées que la fonction doit traiter avec ce que contient une bonne réponse, les entrées qu’elle doit refuser, et combien de fois elle peut rater avant d’être retirée. Elle remplace « ça marche » comme critère d’acceptation pour une fonction dont la sortie varie. ### Qui doit écrire les évals, les ingénieurs ou le product manager ? Le rôle produit écrit les cas et la tolérance ; l’ingénierie écrit le banc qui les exécute. Seul le rôle produit peut dire quels cas comptent et quel taux de raté l’entreprise tolère, et ce chiffre est une décision produit. ### De combien de cas de test une fonction IA a-t-elle besoin ? Commencez par les échecs déjà visibles dans les journaux et les traces, là où l’essai de Husain de mars 2024 dit que va le travail, et ajoutez des cas à mesure qu’ils apparaissent. Vingt cas réels avec une tolérance signée valent mieux que deux cents cas générés que personne ne possède. ### Peut-on seulement tester une fonction dont la sortie varie ? Oui, statistiquement. La propre vérification du studio en juin 2026 a exécuté 11 tests navigateur contre une pile complète, avec 1 ignoré, et a laissé les trois grands flux génératifs non vérifiés de bout en bout parce que leurs sorties varient. Le rapport l’a dit par constat, et c’est ce qui rend la fois suivante digne de confiance. ### Que se passe-t-il quand le prompt change ? Un changement de prompt est une livraison : il passe contre l’éval avant de sortir, et il peut être annulé. Dans la plateforme Changemkr, chacun des huit environnements IA portait son propre versionnage de prompts avec retour arrière en un clic à la limite de juin 2026. ### Comment Torn Studio traite-t-il une fonction IA dans une mission produit ? L’éval est écrite avant le prompt, dans une mission au prix fixé à l’avance : des cas, des refus et une tolérance signée par la personne qui lira le chiffre. La construction est recettée contre elle, et la fonction est livrée avec le document qui dit ce qu’elle peut faire. ## Sources - [Your AI Product Needs Evals — Hamel Husain](https://hamel.dev/blog/posts/evals/) — Source pour le constat du 29 mars 2024 sur la cause racine des produits IA qui échouent, les trois niveaux de test et là où va réellement le travail. - [Building Effective AI Agents — Anthropic](https://www.anthropic.com/engineering/building-effective-agents) — Source pour le conseil du 19 décembre 2024 de chercher la solution la plus simple et de préférer un workflow prédéfini là où les étapes peuvent être connues d’avance. - [Explainability + Trust — People + AI Guidebook — Google PAIR](https://pair.withgoogle.com/chapter/explainability-trust/) — Source pour les recommandations sur le calibrage de la confiance, l’avertissement en cas de données manquantes et l’affichage de la certitude par catégories. - [AI Act — Shaping Europe’s digital future — European Commission](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) — Source pour l’obligation des chatbots de faire savoir aux personnes qu’elles interagissent avec une machine, et pour l’application des règles de transparence à partir d’août 2026.