Claude automatise les evals et le hill-climbing

Deux commandes ferment la boucle d’évaluation et d’amélioration

Le changement essentiel est simple : Claude réunit la conception des evals et l’optimisation d’une application dans une même boucle reproductible. Le billet officiel de Claude, Automating eval design and hillclimbing with Claude, décrit deux commandes : /claude-api build-eval et /claude-api hillclimb.

La première crée une suite d’évaluations dans la base de code. La documentation de Claude cite des vérifications de correspondance exacte, des contrôles par code et une évaluation par LLM, ainsi que des réponses de référence et des métriques telles que la précision et la latence. L’eval n’est donc plus une feuille séparée que l’on consulte avant la mise en production, mais une partie du projet actif.

La seconde commande modifie l’application de manière itérative et mesure le résultat à l’aide des tests déjà créés. Selon les ressources Claude Platform, la recherche peut porter sur les prompts système, le choix du modèle, le niveau d’effort et d’autres paramètres d’API. Il ne s’agit pas d’entraîner les poids du modèle, mais d’automatiser la recherche de configuration autour de lui.

Un détail est déterminant : les données sont séparées entre train et test, et le résultat final est vérifié sur un échantillon retenu. Sans cette protection, le hill-climbing pourrait rapidement apprendre à gagner sur certains exemples sans améliorer le comportement global du système.

Au 30 septembre 2026, je considère cette publication comme l’explication d’une méthode d’ingénierie plutôt que comme une annonce datée, car la description d’origine ne donne aucune date de lancement. L’idée reste néanmoins déjà très concrète au niveau de l’architecture des processus.

L’optimisation des prompts devient un problème de recherche

La conséquence principale est que l’amélioration d’une application d’IA peut passer d’une série de retouches subjectives à un cycle mesurable. L’approche convient particulièrement aux tâches avec des entrées reproductibles, des résultats vérifiables et une fonction d’évaluation stable.

Je vérifierais d’abord trois points : les fuites d’exemples entre train et test, l’instabilité du juge LLM et l’adéquation entre la métrique et la qualité réelle. Si la grille est faible, le hill-climbing optimisera très rigoureusement la mauvaise cible. Il faut aussi intégrer le coût, la latence et les erreurs à l’évaluation, sinon la configuration gagnante ne sera bonne que sur un seul indicateur.

Ce n’est pas un bouton magique pour améliorer Claude, mais un moyen de rendre les expérimentations reproductibles et moins dépendantes du goût de l’auteur du prompt. Le composant le plus difficile reste le même : le système n’est intelligent qu’à la hauteur de l’honnêteté de son eval.

Nous avons précédemment expliqué comment mesurer la fiabilité de LLM-as-a-Judge avec des métriques IRT. Ce cadre aide à vérifier que les améliorations d’evals automatisés reflètent une qualité constante plutôt qu’une notation bruitée.