Vous avez écrit un plugin pour Claude Code, ou une skill (un paquet d’instructions que l’agent charge pour une tâche précise). Il semble aider. Mais comment le savoir autrement qu’à l’impression, après trois essais heureux ?
Anthropic apporte depuis le 11 septembre une réponse outillée : la commande claude plugin eval. Le principe emprunte au test logiciel classique, avec une particularité qui change la nature de l’exercice : Claude propose les tests, les exécute et note une bonne partie des copies.
Un bon résumé existe sous dix formulations
Une fonction se teste simplement : pour telle entrée, telle sortie attendue, au caractère près. Un plugin d’agent ne produit rien de comparable. Il modifie le comportement d’un modèle de langage dont la réponse varie d’une exécution à l’autre, et dont la qualité se juge rarement par une égalité stricte. Deux résumés corrects peuvent ne partager presque aucun mot.
Faute d’outil, l’évaluation se faisait donc à l’œil. On lance l’agent sur quelques demandes, on lit, on ajuste le prompt (les instructions données au modèle), on relance. Méthode honnête mais fragile : une retouche qui améliore un cas peut en dégrader un autre sans que personne ne s’en aperçoive.
L’annonce publiée par le compte officiel ClaudeDevs sur X fixe l’objectif en ces termes : découvrir la valeur ajoutée par un plugin, ou constater qu’il demande encore du travail.
De claude plugin eval init au premier score
Tout part du dossier du plugin, avec la commande claude plugin eval init. Les rôles se répartissent ensuite ainsi.
- Vous décrivez à Claude à quoi ressemble une bonne sortie, et à quoi ressemble une mauvaise.
- Vous fournissez quelques requêtes réelles, tirées de l’usage concret du plugin.
- Claude propose les cas de test et les vérifications associées, que la documentation appelle des graders : un motif de texte recherché dans la réponse, l’appel attendu d’un outil, ou une grille de critères qu’un second modèle applique à la réponse.
- Il pilote la suite : il exécute le plugin ou la skill sur chaque cas, puis évalue ces exécutions.
- Chaque cas est rejoué sans le plugin, pour comparer les deux résultats.
- Le cycle se relance à volonté, ce qui permet de mesurer l’effet d’une retouche. Chaque exécution et chaque jugement restent de vrais appels au modèle, décomptés de votre forfait ou de votre facture API (l’interface de programmation facturée à l’usage).
Le dispositif ressemble à un examen. Vous tenez le rôle de l’autorité qui arrête le programme et le barème. Claude cumule celui du concepteur du sujet, du surveillant et, pour une large part, du correcteur. Et le candidat ? Encore Claude, équipé de votre plugin.
Un agent qui corrige la copie d’un agent
Cette architecture porte un nom dans la recherche : le LLM-as-a-judge, où un grand modèle de langage (LLM) sert d’évaluateur aux réponses d’un autre. Elle règle un problème concret, puisqu’aucun humain n’a le temps de relire des dizaines d’exécutions à chaque modification. Elle installe aussi une boucle qu’il faut savoir lire.
Quand la même famille de modèles écrit les critères, produit la réponse et la note, ses angles morts se retrouvent aux trois étages. Un cas limite qu’elle n’imagine pas ne figurera pas dans la suite. Une formulation qu’elle trouve naturelle risque d’être jugée favorablement, parce qu’elle lui ressemble. Un taux de réussite élevé peut alors refléter la cohérence du modèle avec lui-même autant que la qualité du plugin. Les vérifications mécaniques, comme la présence d’un motif ou l’appel d’un outil, échappent à ce biais, mais elles ne couvrent pas la qualité d’une réponse rédigée.
Le dispositif garde pourtant deux ancres extérieures, et elles viennent de vous : la définition du bon et du mauvais résultat, et les requêtes réelles. Toute la solidité de l’évaluation repose sur ces deux apports.
Les demandes mal formulées valent plus que les cas faciles
Puisque Claude se charge de l’intendance, votre travail se déplace vers ce qu’il ne peut pas inventer à votre place.
- Des requêtes réelles et variées, y compris les demandes ambiguës, mal formulées ou hors périmètre qui arrivent en usage courant. Trois cas faciles fabriqueront une suite complaisante.
- Une description de la mauvaise sortie aussi précise que celle de la bonne. Elle distingue souvent un plugin utile d’un plugin qui se contente de ne rien casser.
- Une relecture des cas de test et des vérifications générés avant de croire le score. Un critère vague ou trop indulgent se repère en quelques minutes.
- Un contrôle manuel de quelques exécutions notées, pour vérifier que le jugement de Claude rejoint le vôtre.
L’annonce parle de valeur ajoutée, et une valeur ajoutée se mesure par différence : d’où le passage de chaque cas sans le plugin. Un plugin qui décroche de bonnes notes sur des tâches que Claude réussit déjà seul n’apporte rien, et cet écart nul se lit directement dans les résultats.
Les skills passent du document au composant testé
Jusqu’ici, un plugin d’agent vivait comme un texte : on le rédigeait, on le partageait, on espérait qu’il tienne. Avec une suite d’évaluation rejouable, il se rapproche d’un composant logiciel, accompagné d’un filet qui signale quand une modification fait reculer un comportement. Une équipe qui entretient une vingtaine de skills internes peut enfin retoucher un prompt sans travailler à l’aveugle.
Anthropic avance à rebours d’OpenAI sur ce terrain. OpenAI a annoncé en juin la fermeture de sa plateforme Evals, qui passera en lecture seule le 31 octobre avant son arrêt le 30 novembre 2026, et oriente ses développeurs vers l’outil open source Promptfoo.
La limite tient à la construction même de l’outil. Une évaluation écrite et notée par l’IA indique si le plugin satisfait les critères que l’IA a tirés de vos consignes. Elle ne dit pas si ces critères sont les bons. Le score s’obtient en quelques commandes ; ce qu’il vaut se décide dans les quelques lignes où vous aurez décrit, avant tout le reste, ce qu’est une réponse ratée.
