L’angle mort de l’évaluation des LLM : pourquoi ne regardons-nous que la « connaissance » et non le « comportement » ?

• L’évaluation des LLM en est encore au stade du « score au SAT » — MMLU, HumanEval et SWE-bench restent tous dans un paradigme de session unique et de réponse unique. Un véritable agent de code travaille sur plusieurs sessions, apprend de ses erreurs et lit les conventions existantes. Ce n’est pas une question de connaissance, mais de comportement.

• Quand nous recrutons des humains, nous regardons davantage « comment ils réfléchissent » que leurs notes — pourquoi ne faisons-nous pas la même chose pour l’évaluation des LLM ? Aujourd’hui, nous sommes bloqués à l’étape de la « vérification du GPA », où tous les modèles atteignent le 90e percentile.

• Même pour corriger le même bug, les approches peuvent être totalement différentes — le modèle A fait un grep en 30 secondes puis applique un patch (profil prototypage), le modèle B décompose en sous-tâches avant d’adopter une approche systématique (profil architecture), le modèle C apprend à partir de précédents dans le git log puis corrige (profil maintenance). Tous corrigent le bug. Le score est identique. L’adéquation au rôle, elle, est totalement différente.

• Proposition de 4 dimensions d’observation du comportement — Decomposition (décompose-t-il ou exécute-t-il immédiatement), Approach (cherche-t-il des patterns ou raisonne-t-il à partir des principes), Recovery (change-t-il de stratégie quand il est bloqué ou insiste-t-il), Consistency (adopte-t-il la même approche face à des problèmes similaires).

Évaluation de la connaissance vs évaluation du comportement

Benchmark existant	Ce qu’il mesure	Ce qu’il manque
MMLU	Quantité de connaissances mémorisées	Jugement dans l’application, « conscience de ce qu’il ne sait pas »
HumanEval	Taux de réussite à la première tentative	Débogage, itération, processus d’adaptation
SWE-bench	Le patch passe ou non	Cheminement d’approche, compréhension de l’architecture, apprentissage intersession

2026 : les vraies questions à poser

Maintenant que les agents de code ne sont plus des démos mais de véritables outils d’équipe, la question à poser n’est pas « combien de points ? » :

• « Quel modèle convient à la maintenance de legacy ? »
• « Quel style de débogage se prête bien au pair programming avec un junior ? »
• « Quel modèle présente le comportement le plus prévisible sur plusieurs semaines ? »

Ce sont des questions de role fit. Des questions de recrutement. Et nous continuons à y répondre avec des scores de SAT.

L’auteur ne présente pas ce cadre comme une version achevée. Il laisse explicitement ouvertes quatre hypothèses, avec une attitude de « corrigez-moi si je me trompe », afin de susciter la discussion dans les commentaires. L’article de Tang et al., « In-Situ Behavioral Evaluation for LLM Fairness », publié en avril 2026, va dans une direction similaire.