Comment tester un outil d’IA sur vos propres tâches avant de lui faire confiance?

Une démonstration vous montre le meilleur cas. Un test vous montre le cas habituel et les mauvais. Avant qu’un outil d’IA rédige les courriels à vos clients, trie vos factures ou réponde à votre clientèle, il mérite le même genre d’essai qu’une nouvelle recrue : du vrai travail, vérifié selon une norme claire, assez de fois pour que la chance ne décide pas du résultat.

Le guide d’évaluation d’OpenAI a un nom pour ce que la plupart des gens font à la place : les vibe-based evals (les évaluations « au feeling »), qui consistent à juger qu’un outil « a l’air de marcher » après quelques essais. La solution n’est pas compliquée. C’est un petit ensemble fixe de vos propres tâches, que vous faites passer chaque fois que vous envisagez un outil, un modèle ou un changement de réglages.

Ce qui est différent quand on teste un outil en 2026

Si vous avez déjà bâti un jeu de tests pour des prompts, trois choses sont différentes maintenant.

• Vous testez souvent un produit, pas un modèle. Un assistant doté de connecteurs, d’une mémoire et d’un mode agent peut échouer dans sa recherche, dans son utilisation des outils ou dans sa réponse finale. Notez le résultat final, mais indiquez où ça a mal tourné.
• Les agents agissent, alors testez leurs actions. Pour un agent, un cas doit préciser ce qu’il a le droit de faire et ce qu’il ne doit pas faire. « N’a pas écrit au client » peut faire partie d’une réussite.
• Les résultats varient d’un essai à l’autre. La même entrée peut donner des sorties différentes; faites donc passer les cas importants plus d’une fois, surtout pour les agents.

Bâtir le test en quatre étapes

1. Choisissez 30 vraies tâches. Tirez-les du travail du mois dernier, pas de votre imagination. Anthropic et OpenAI insistent tous deux pour qu’on reproduise la vraie répartition des tâches; incluez donc les tâches typiques et ennuyeuses, quelques difficiles et quelques étranges : fautes de frappe, renseignements manquants, une demande que l’outil devrait refuser.

2. Écrivez les critères de réussite avant de lancer quoi que ce soit. Pour chaque tâche, énumérez de deux à quatre choses qu’un bon résultat doit contenir ou éviter. Rendez-les vérifiables : « indique un délai de remboursement de 30 jours », pas « est exact ».

3. Décidez comment chaque cas sera noté. Certains se vérifient exactement (un nombre, une date, une catégorie). D’autres exigent une grille. Un modèle peut noter selon la grille, ce qui est plus rapide, mais OpenAI signale que les modèles correcteurs favorisent les réponses plus longues et celle qui vient en premier; vérifiez donc un échantillon de leurs notes par rapport aux vôtres avant de vous y fier.

4. Lancez, notez à l’aveugle et consignez. Si vous comparez deux outils, cachez quelle sortie vient de quel outil. Notez réussite ou échec pour chaque cas, avec un mot sur la raison.

Voici un prompt de correction réutilisable :

Tu notes la sortie d’un outil d’IA selon une liste de contrôle. Tu verras la tâche, la liste de contrôle et la sortie.
Pour chaque élément de la liste, réponds RÉUSSI ou ÉCHEC, avec une courte raison qui cite la sortie.
Donne ensuite un RÉUSSI global seulement si tous les éléments réussissent. Ne récompense ni la longueur ni le style; juge seulement selon la liste.
Tâche : [coller]
Liste de contrôle : [coller]
Sortie : [coller]

Lire les résultats honnêtement

Un score de 24 sur 30 ressemble à « 80 % », mais les petits tests sont flous. La recherche d’Anthropic sur l’évaluation recommande d’accompagner chaque score d’une marge d’erreur. Pour 30 cas, une fourchette approximative à 95 % autour de 80 % va d’environ 66 % à 94 %. L’outil est probablement correct; vous ne pouvez guère en dire plus.

Les comparaisons sont plus nettes quand les deux outils affrontent les mêmes cas. Anthropic souligne qu’examiner les écarts question par question donne une réponse plus précise que comparer deux scores globaux. En pratique : comptez les cas où A a réussi et B a échoué, et l’inverse. Si c’est 9 contre 2, la différence est réelle. Si c’est 5 contre 4, elle ne l’est pas.

Regardez aussi les échecs eux-mêmes, pas seulement leur nombre. Un échec qui envoie une information fausse à un client peut compter plus que cinq formulations maladroites.

Combien d’exemples faut-il pour un test utile?

Cela dépend de la décision. Pour écarter un outil nettement inadéquat, de 20 à 30 cas bien choisis suffisent, parce que les gros problèmes se voient vite. Pour choisir entre deux outils qui semblent bons tous les deux, il en faut davantage : environ 100 cas ramènent la fourchette autour d’un score à environ plus ou moins 8 points, et une comparaison appariée sur les mêmes cas aide plus que l’ajout de cas.

La documentation d’Anthropic préfère plus de cas avec de simples vérifications automatisées à quelques cas notés à la main avec soin, et c’est un bon conseil une fois votre jeu stabilisé. Commencez avec 30, enrichissez-le de chaque vrai échec que vous rencontrez, et refaites passer tout le jeu chaque fois que l’outil, le modèle qui le fait tourner ou vos instructions changent. Un jeu de tests qui grandit vaut plus qu’un jeu parfait que vous avez lancé une seule fois.