Le mensonge du benchmark : pourquoi Grok 4.20 excelle aux benchmarks mais échoue en production
Un ergonome cognitif teste Grok 4.20 sur 12+ agents en production. Ce que 40 ans de recherche en facteurs humains disent de ce que les benchmarks ratent.
Je ne suis pas développeur.
Je suis ergonome cognitif — j’étudie comment les humains pensent pendant qu’ils agissent. Les facteurs humains étudient ces situations : salles de contrôle nucléaire, cockpits, blocs opératoires. Pas avant l’action, pas après. Pendant.
Ces dernières semaines, j’ai utilisé Grok 4.20 en conditions réelles sur plus de 12 instances Hermes Agent en production, par Nous Research. Ce que 40 ans de recherche en facteurs humains disent de ce que j’ai observé : le benchmark ne mesure pas ce qui compte.
Le benchmark ne mesure pas ce qui compte
SWE-bench Verified part d’une description de problème et du code d’un dépôt. Le système produit un patch, jugé par des tests. Le benchmark juge le résultat final, pas la conduite de la boucle qui y mène.
Une boucle d’agent, c’est 20 à 50 tours d’appels d’outils, de reprise d’erreur et de révision de plan, où le modèle doit maintenir sa conscience de la situation tout en agissant en continu (Endsley, 1995).
Les ergonomes ont un nom pour cette distinction : cognition hors-situation vs cognition en-situation.
C’est pourquoi les tests de QI ne prédisent pas la performance d’un pilote.
C’est pourquoi SWE-bench ne prédit pas la performance d’un agent.
Grok 4.20 : 76,7 %. Claude Opus 4.6 : 80,8 %. Un écart de 4,1 points au benchmark.
Dans mes boucles, l’écart ressemble à trente.
Cinq modes d’échec cognitifs
Je n’ai pas fait tourner un harnais. J’ai fait tourner des agents en usage réel. Les échecs ci-dessous y ont été observés, dans des boucles Hermes Agent.
1. Gouffre de l’exécution (Norman, 1986)
Grok dit « je vais vérifier les logs maintenant » — puis n’appelle pas l’outil.
L’opérateur formule l’intention mais ne fait jamais le pont vers l’action. Le système cognitif est actif. Le système exécutif ne l’est pas. Norman a nommé cela le gouffre de l’exécution : la distance entre ce que l’opérateur veut faire et ce que le système fait.
Cas réel : un audit décrit sans être exécuté. Dix minutes de planification narrée. Trois corrections de l’utilisateur.
Correctif : GROK_EXECUTION_GUIDANCE, un bloc système balisé en XML interdisant les phrases d’intention. Même tâche, même session, même modèle. Résultat : 33,9 s, zéro correction, 2 appels API.
2. Effondrement de la conscience de la situation (Endsley, 1995 ; Salas et al., 1995)
Grok émet des tokens de raisonnement avec zéro contenu textuel. La boucle se fige. Pas d’erreur. Pas de crash. Silence.
Dans une salle de contrôle, c’est l’opérateur qui fixe un écran pendant que le superviseur n’a aucune idée s’il analyse ou s’il est figé. La conscience de situation de l’équipe s’effondre.
Correctif : détection de réponse vide avec relance de récupération en un coup.
3. Feedforward absent
Taux de « texte + appels d’outils dans le même tour » sur mon corpus de sessions :
Claude : ~20,7 %
Grok : ~6,9 %
Grok renvoie du raisonnement pur là où Claude enchaîne read_file → terminal → patch dans une seule réponse. Le feedforward est absent. L’observateur ne peut pas faire équipe avec l’opérateur.
Texte et appels d’outils dans le même tour
Corpus de sessions cité dans l’article Texte et appels d’outils dans le même tour
4. Sur-confiance dans la mémoire de travail (Baddeley, 1986 ; Reason, 1990)
Grok produit des analyses crédibles à partir d’un raisonnement purement interne.
« Le problème est probablement une question de permission sur le cron job. » — n’a jamais vérifié le cron.
L’expert saute la checklist externe parce qu’il « sait ». Reason (1990) a classé cela comme une erreur basée sur des règles : la confiance dans le modèle interne l’emporte sur la vérification de l’état réel.
Dangereux quand l’analyse paraît complète.
5. Erreur de continuation de plan (Reason, 1990)
Timeout SSH ? Mauvais JSON ? Grok réessaie exactement le même appel ou se fige.
Reason a documenté ce motif dans les accidents d’aviation : l’opérateur ne peut pas dévier de la procédure standard quand l’environnement change. Dans les systèmes à haut risque, cela tue des gens. Dans les boucles d’agents, cela tue des tâches.
L’ergonomie des agents IA en boucle
Trois semaines de dogfooding, traduites dans les construits que les ergonomes utilisent pour évaluer tout système cognitif conjoint (Hollnagel & Woods, 2005) :
- Auto-régulation — planification spontanée, points de contrôle, auto-surveillance
- Couplage perception–action (Gibson, 1979) — vitesse de traduction de la perception en exécution d’outil
- Feedforward — signaler l’intention et la progression pendant l’action
- Gestion des perturbations — s’adapter quand la procédure standard échoue
Sur ces quatre dimensions, Grok sous-performe Claude et GLM-5.1 dans mon corpus de production. GLM-5.1 n’est pas plus intelligent que Grok. Il est mieux conçu pour agir en situation. Comme un cockpit bien conçu, son architecture soutient des boucles perception–action continues sans surcharger la mémoire de travail.
Pourquoi j’utilise encore Grok
Pour des tâches complexes uniques — revue d’architecture, analyse de sécurité, conception de framework — Grok est le meilleur raisonneur hors-situation auquel j’ai accès. Je lui confie délibérément ces tâches.
Le problème, c’est la boucle.
Grok est conçu pour penser profondément. Un agent a besoin de penser superficiellement tout en agissant profondément.
Ce n’est pas un problème de code. C’est un problème d’architecture cognitive.
Ce que xAI devrait corriger
Pas des correctifs côté client à maintenir pour toujours. Des décisions de conception ergonomique.
- reasoning_effort=low devrait supprimer la narration interne. Séparer le flux de raisonnement du flux de communication. Le monologue interne ne devrait pas fuir dans le canal que l’opérateur utilise pour agir.
- Mode natif tool-call-first. Un drapeau API qui force le couplage perception–action : exécution d’outil avant le texte descriptif sur les prompts impliquant du travail.
- Injection automatique du contexte d’erreur. Ne pas faire mémoriser le dernier échec par le framework. L’injecter dans la mémoire de travail du modèle comme une alarme de cockpit qu’on ne peut pas ignorer.
- Un protocole partagé de conscience de situation. Un standard léger pour que les modèles émettent des signaux de statut pendant les longues boucles, afin que les observateurs et les frameworks sachent que l’opérateur est toujours dans la boucle.
Ce que j’ai livré
Mergé dans hermes-agent, avec mon nom conservé :
- Cache de prompt xAI (PR #5604)
- Fournisseur xAI natif (PR #7372)
- Effort de raisonnement transmis à l’API xAI (PR #22807)
En production, en attente de discussion :
- GROK_EXECUTION_GUIDANCE — 47 sessions, 124 tests passants, données A/B prêtes.
Le verdict
Grok 4.20 est le meilleur raisonneur hors-situation auquel j’ai accès.
Ce n’est pas encore le meilleur opérateur en-situation.
L’écart peut être comblé. Mais cela demande à xAI de traiter les boucles d’agents comme un problème d’ergonomie des agents IA, pas comme un problème de complétion de chat.
Vous n’avez pas besoin de plus d’ingénieurs logiciels pour corriger ça.
Vous avez besoin d’ergonomes cognitifs.
L’échec n’est pas dans le code.
Il est dans la cognition.
Cinq modes d’échec cognitifs décrits dans l’article, avec le correctif associé quand il est nommé.
À retenir
Grok 4.20 reste, dans ce corpus, le meilleur raisonneur hors-situation cité. Il n’est pas encore le meilleur opérateur en-situation.
Grok : ~6,9 %Si vous êtes chez xAI et que vous travaillez sur le comportement des agents côté API : j’ai des logs de sessions, des données A/B et un framework. Mes messages privés sont ouverts.
Je regarde les modèles échouer à 23 h pour que vous n’ayez pas à le faire.
Le diagnostic IA reprend cette question côté entreprise : ce que l’agent fait vraiment dans le travail.
Références
Norman (1986) ; Endsley (1995) ; Baddeley (1986) ; Reason (1990) ; Gibson (1979) ; Hollnagel & Woods (2005) ; Salas et al. (1995). Corpus de dogfooding : 150+ sessions, 12+ instances clients, avril 2026.
— Julien Talbot
Retrouvez mes contributions documentées à Hermes et Treg, ainsi que les possibilités de revue de fonctionnalités humain–agent, dans Labs.
Vous voulez savoir ce que l’IA changerait dans votre travail ?
Premier échange : 30 minutes, en visio ou par téléphone, gratuit et sans engagement. Réponse sous 48 h ouvrées.