Les evals pour un PM : savoir si ton IA fait vraiment le job, sans coder
Monter un jeu de tests répétable, 10 à 20 cas réels avec des critères de réussite, pour vérifier qu'une feature IA tient la route et mesurer la régression avant de shipper. Le réflexe evals expliqué pour un PM, sans une ligne de code.
Tu promptes bien. Mais comment tu prouves que la sortie tient la route à chaque fois, pas juste sur l'exemple que tu viens de tester ? Voilà comment monter un jeu de tests répétable, sans écrire une ligne de code.
Tu ajustes un prompt. Tu le relances sur ton exemple habituel. La réponse est meilleure. Tu shippes. Trois jours plus tard, un cas que tu avais réglé le mois dernier ressort cassé. Tu ne l'avais pas revu, parce que tu ne testes qu'un seul cas à la fois, à la main, au feeling.
C'est l'angle mort de tout PM qui pilote une feature IA. Tu vois la sortie sur l'input que tu as sous les yeux. Tu ne vois pas les dix autres que ton changement vient de dégrader. Le réflexe qui ferme cet angle mort porte un nom dans le métier : les evals. Et contrairement à ce que le mot laisse croire, tu n'as pas besoin de coder pour t'y mettre.
C'est quoi une eval, en clair
Une eval, c'est un test répétable pour une sortie d'IA. Tu figes une liste de cas réels. Pour chacun, tu écris ce qu'une bonne réponse doit contenir. Puis tu fais tourner ton prompt sur toute la liste d'un coup et tu comptes combien de cas passent.
Rien de plus. Un jeu d'exemples attendus, un critère de réussite, un score. Là où tu validais une réponse au jugé, tu mesures un taux de réussite sur un panel figé. Le même panel, à chaque changement.
C'est le chaînon qui manque entre prompter au niveau d'après et décider. Le brief solide te donne une bonne sortie une fois. L'eval te dit si cette sortie tient encore après ta prochaine retouche, le prochain modèle, le prochain cas tordu.
Pourquoi valider au feeling ne tient pas
Le test à la main a trois angles morts, et ils coûtent cher.
Tu testes toujours les mêmes cas. Ceux qui te viennent en tête sont ceux qui marchent déjà. Les cas qui cassent, tu les découvres en production, par un utilisateur.
Tu ne vois pas la régression. Tu améliores la sortie sur le cas A. Tu ne remarques pas que la même retouche a cassé les cas B et C, parce que tu ne les as pas rejoués. Une feature IA qui régresse ne plante pas bruyamment comme un bug de code. Elle se dégrade en silence.
Tu ne peux pas trancher un désaccord. Un dev jure que son changement de prompt est propre. Un ticket support dit le contraire. Sans chiffre, tu arbitres à l'intuition. Avec un jeu de tests, la conversation change : le nouveau prompt passe 15 cas sur 20 contre 18 avant, donc il régresse. Fin du débat.
Valider au feeling, c'est tester une feature IA sur un échantillon de un, choisi par toi, et changeant à chaque fois. Une eval, c'est le même panel, figé, rejoué à chaque modification. Tu passes d'une impression à une mesure.
Monter ton jeu de tests : 10 à 20 cas réels
La bonne nouvelle : tu n'as pas besoin d'un labo. La doc d'Anthropic sur les agents est nette là-dessus. Commence avec 20 à 50 tâches simples tirées de vrais échecs, pas des centaines. Tôt dans un projet, chaque changement a un effet visible, donc un petit panel suffit à le détecter. Pour une première feature de PM, 10 à 20 cas suffisent à démarrer.
- Collecter les cas réels. Ne les invente pas. Prends les vraies demandes de tes utilisateurs, surtout celles où l'IA s'est plantée. Un bug remonté par le support, une sortie que tu as dû corriger à la main : chacun devient un cas de test.
- Figer l'entrée et la sortie attendue. Pour chaque cas, note l'input exact et ce qu'une bonne réponse doit contenir. Pas la réponse mot pour mot, mais le critère : "cite le bon montant", "ne mentionne aucune donnée perso", "reste sous cinq lignes".
- Rendre le critère mesurable. "Bonne réponse" n'est pas un critère. "Classe le ticket dans la bonne catégorie" en est un. Anthropic donne le contraste net : "sorties sûres" ne veut rien dire, "moins de 0,1 % des sorties signalées toxiques sur 10 000 essais" se mesure. Vise le second.
- Inclure les cas tordus. C'est là que ça régresse. Input vide, question à rallonge, ton agressif, faute de frappe, sujet hors périmètre. Ce sont ces cas que le test au feeling n'atteint jamais.
Un bon cas de test a une propriété simple : deux personnes qui connaissent le sujet donnent le même verdict, passé ou échoué. Si toi et un collègue n'êtes pas d'accord sur ce qui compte comme réussite, le critère est trop flou. Tu le resserres avant d'aller plus loin.
Le faire sans coder : l'outil d'évaluation de la console
Voilà où le "sans une ligne de code" devient concret. La console Claude a un onglet Évaluer, à côté de l'éditeur de prompt. Tout se passe dans le navigateur.
Tu écris ton prompt avec une variable entre doubles accolades, par exemple {{ticket}}. Puis tu remplis ton panel de cas de trois façons : bouton "Add Row" pour taper un cas à la main, "Generate Test Case" pour que Claude t'en propose un, ou import d'un fichier CSV si tu as déjà une liste. Tu lances, et le prompt tourne sur tous les cas d'un coup.
Aucun terminal, aucune installation. Tu tapes un prompt, tu remplis des lignes, tu lis des colonnes. Si tu sais utiliser un tableur, tu sais utiliser cet outil.
Noter les sorties sans y passer la nuit
Reste à donner un score à chaque sortie. Deux façons de faire, selon le cas.
Le critère net se note tout seul. "La bonne catégorie", "le bon montant", "moins de cinq lignes" : c'est passé ou échoué, sans discussion. Ce sont tes cas les plus solides, garde-les majoritaires.
Le critère de qualité se note à l'échelle. Le ton, la clarté, l'empathie d'une réponse client ne sont pas binaires. Là, tu notes de 1 à 5. Tu peux le faire toi, ou demander à un second modèle de juger la sortie du premier sur un critère précis. C'est ce qu'on appelle le modèle juge, et l'outil de la console gère cette note à cinq points nativement.
La règle contre-intuitive d'Anthropic : privilégie le volume à la finesse. Beaucoup de cas notés automatiquement, même avec un signal un peu moins fin, valent mieux que trois cas notés à la main avec un soin de joaillier. Ce qui compte, c'est de rejouer souvent, pas de noter parfaitement.
Mesurer la régression avant de shipper
C'est le moment qui justifie tout le reste. Tu as une feature IA en prod. Tu veux changer le prompt, ou passer au dernier modèle. Avant, tu ajustais et tu croisais les doigts.
Maintenant, tu crées une nouvelle version de ton prompt et tu rejoues le panel entier. La console met les deux versions côte à côte, cas par cas. Tu lis le delta d'un coup d'œil.
| Sans jeu de tests | Avec jeu de tests |
|---|---|
| "Ça a l'air mieux sur mon exemple." | "18 cas sur 20 passent, contre 15 avant. Je shippe." |
| La régression se découvre en prod, par un utilisateur. | La régression se voit avant, sur les deux cas qui basculent au rouge. |
| Le débat sur la qualité se tranche à l'intuition. | Le débat se tranche sur un chiffre que tout le monde voit. |
Si le nouveau prompt passe moins de cas que l'ancien, tu ne shippes pas. Tu tiens la preuve, pas l'impression. C'est le geste qui manque à la plupart des équipes. Hamel Husain, qui a formé des centaines d'équipes produit à ce réflexe, résume la cause des features IA ratées en une phrase : l'absence d'un système d'évaluation solide.
Trois pièges à éviter
La réponse doit être bonne.
Personne ne sait trancher. Deux relecteurs donnent deux verdicts opposés, et ton score ne veut plus rien dire.
La réponse cite le bon numéro de commande et ne dépasse pas cinq lignes.
Passé ou échoué, sans discussion possible.
10 cas propres, bien formulés, que le prompt gère déjà.
Ton score frôle les 100 %. Il te rassure et ne t'apprend rien.
Les cas où ça s'est planté : input vide, ton agressif, faute de frappe, hors sujet.
Le panel reflète tes vrais utilisateurs, pas ton meilleur jour.
Tu montes le panel, tu le lances une fois, tu l'oublies.
Six semaines plus tard, personne ne sait si la feature a dérivé.
Tu rejoues le panel à chaque retouche de prompt et à chaque changement de modèle.
La régression se voit le jour où elle apparaît.
Par où commencer
1. Rassemble dix cas réels
Ouvre les dernières demandes où ton IA s'est plantée. Copie l'input de chacune. Tu as ton premier panel, sans rien inventer.
2. Écris un critère net par cas
Une phrase qui se tranche en passé ou échoué. Si un collègue ne noterait pas comme toi, resserre-la.
3. Rejoue avant chaque changement
Dans l'onglet Évaluer de la console, compare la nouvelle version à l'ancienne. Le score monte, tu shippes. Il baisse, tu corriges.
Tu n'as pas besoin d'un outil de plus ni d'un dev à côté. Dix cas, un critère par cas, un panel rejoué à chaque retouche. Le jour où tu shippes une feature IA sur un chiffre au lieu d'une impression, tu as arrêté de valider au feeling. Tu es passé du PM qui espère au PM qui mesure.
