Le mensonge du benchmark : pourquoi Grok 4.20 excelle aux benchmarks mais échoue en production

Je ne suis pas développeur.

Je suis ergonome cognitif — j’étudie comment les humains pensent pendant qu’ils agissent. Salles de contrôle nucléaire. Cockpits d’avion. Blocs opératoires. Pas avant l’action, pas après. Pendant.

Ces dernières semaines, j’ai fait du dogfooding de Grok 4.20 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 donne au modèle un fichier, un problème, un patch. Une chaîne de raisonnement. Une réponse.

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 %. Trois points d’écart 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 une entreprise. Chaque échec ci-dessous m’a coûté un ticket client, une session SSH nocturne, ou un message WhatsApp ou Telegram agacé.

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 : audit sur une fuite de tokens chez un client. Dix minutes de planification narrée. Trois corrections de l’utilisateur. Une proposition de cron budget_guard toutes les 3 minutes — une solution consommatrice de tokens à un problème de consommation de tokens.

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.

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 cognitive des boucles agentiques

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 situationnellement. 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. J’y route délibérément.

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.

1. 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.
2. 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.
3. 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.
4. 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 (3/3) :

• Forçage de l’usage d’outils pour Grok (PR #5595)
• Cache de prompt xAI via x-grok-conv-id
• Intégrations des providers xAI TTS, STT, image/vidéo

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 est comblable. Mais cela demande à xAI de traiter les boucles agentiques comme un problème d’ergonomie cognitive, pas comme un problème de complétion de chat.

Tu n’as pas besoin de plus d’ingénieurs logiciels pour corriger ça.

Tu as besoin d’ergonomes cognitifs.

L’échec n’est pas dans le code.

Il est dans la cognition.

Si tu es chez xAI et que tu travailles sur le comportement des agents côté API : j’ai des logs de sessions, des données A/B et un framework. Mes DM sont ouverts.

Je regarde les modèles échouer à 23 h pour que tu n’aies pas à le faire.

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