Évaluations dans le Workbench
Mis à jour le 28 juillet 2026
Le Workbench Anthropic
Le Workbench, accessible sur console.anthropic.com, est l’outil graphique d’Anthropic pour tester et itérer sur vos prompts. Vous y écrivez et modifiez un prompt visuellement, vous le testez avec différents modèles et différents paramètres, et vous exécutez des évaluations sans écrire une ligne de code. C’est le point d’entrée naturel pour quiconque n’est pas développeur, ou pour un développeur qui veut voir rapidement si une idée tient debout avant d’investir dans un script.
L’intérêt de commencer ici est pédagogique autant que pratique. Toute la mécanique décrite dans la leçon précédente — cas de test, réponses de référence, comparaison, itération — devient visible à l’écran. Vous voyez littéralement la colonne des sorties du modèle face à la colonne des réponses attendues, ce qui rend le concept d’évaluation beaucoup plus concret qu’une explication abstraite.
Monter une évaluation, étape par étape
La procédure se déroule en quatre temps. Vous préparez d’abord les cas de test, sous la forme d’un fichier CSV ou d’un jeu de données qui réunit les variables d’entrée — ce qui change à chaque test — et les réponses attendues, autrement dit la ground truth. Vous configurez ensuite le prompt dans le Workbench, en y plaçant des variables (placeholders), en choisissant le modèle et les paramètres, et en définissant le prompt système si votre cas d’usage en demande un. Vient l’exécution proprement dite : le Workbench applique le prompt à chaque cas de test et affiche les résultats côte à côte avec les réponses attendues. Reste enfin l’analyse, c’est-à-dire l’examen des cas où le modèle échoue.
Prenons un exemple pour rendre cela tangible. Vous voulez extraire la date d’échéance d’une facture. Votre CSV contient une colonne facture avec le texte brut de vingt factures et une colonne attendue avec les vingt dates au format JJ/MM/AAAA. Votre prompt contient un placeholder {{facture}}. Vous lancez, et le Workbench remplit vingt lignes.
L’étape d’analyse mérite qu’on s’y arrête, car c’est là que se joue la valeur de l’exercice. La première question à poser devant un échec est de savoir si la réponse est réellement fausse ou simplement mal formatée. Une date correcte rendue en « 3 mars 2027 » au lieu de « 03/03/2027 » n’est pas une erreur de compréhension, c’est une consigne de format manquante, et la correction ne porte pas sur la même partie du prompt.
Vient ensuite la recherche d’un motif récurrent : si les six erreurs concernent des factures rédigées en anglais, vous tenez votre cause et vous savez quoi ajouter à la consigne. La dernière question est de savoir si le problème vient du prompt ou du modèle. Reformuler la consigne coûte quelques minutes et règle la majorité des cas ; changer de modèle est la réponse de dernier recours.
Ce que le Workbench apporte
Son premier atout est l’absence de code, ce qui autorise des itérations très rapides : vous modifiez une phrase du prompt, vous relancez, vous comparez, le tout en quelques secondes. Son deuxième atout est l’affichage visuel, la comparaison côte à côte des sorties et des références rendant les écarts immédiatement lisibles. Le troisième est le partage : vous pouvez transmettre vos prompts et vos résultats à votre équipe, ce qui évite les allers-retours de captures d’écran et permet à un expert métier de vérifier lui-même la qualité des réponses.
Ce qu’il ne fait pas
Trois limites apparaissent dès que le projet grandit. La scalabilité d’abord : sur des centaines de cas de test, l’interface graphique atteint ses limites et le code devient plus adapté. L’automatisation ensuite, car seules des évaluations programmatiques s’intègrent proprement dans un pipeline CI/CD qui bloquerait un déploiement en cas de régression. La notation enfin : dès que la logique de vérification devient complexe — normaliser une sortie, valider une structure imbriquée, calculer un score partiel — il faut du code pour l’exprimer.
Trouver la bonne place
Le Workbench excelle dans trois moments du projet. En phase exploratoire, quand vous testez plusieurs idées de prompts sans savoir encore laquelle tient la route. Lors des itérations rapides, quand vous ajustez une formulation en temps réel et voulez voir l’effet immédiatement. Et en démonstration, pour montrer à une équipe ce que le modèle sait faire sur des données qu’elle reconnaît.
Pour la production, passez aux évaluations par code, qui font l’objet des leçons suivantes. Le passage de l’un à l’autre n’a rien d’un reniement : les cas de test que vous avez constitués dans le Workbench se réutilisent tels quels dans un script.
Points clés à retenir
- Le Workbench permet d’évaluer un prompt sans écrire de code, avec une comparaison visuelle sortie / référence.
- La procédure tient en quatre temps : cas de test, configuration du prompt, exécution, analyse des échecs.
- Face à un échec, distinguez toujours une erreur de fond d’un simple problème de format.
- L’outil montre ses limites sur le volume, l’automatisation CI/CD et les logiques de notation complexes.
- Réservez-le à l’exploration, aux itérations rapides et aux démonstrations ; passez au code pour la production.