LLM local ou Claude Code : le mauvais benchmark

Contexte

Un article publié sur dev.to par rudratosh, repris ensuite par Buzzing AI, pose une question directe : un grand modèle de langage exécuté en local peut-il remplacer un agent de programmation en terminal comme Claude Code ? Selon l'auteur, le benchmark que tout le monde cite dans ce débat est le mauvais. Il ne mesure pas ce qu'un agent de code doit réellement accomplir dans un dépôt réel.

Les sources disponibles se limitent au titre et au résumé de l'article. Elles ne disent pas quels modèles ont été testés ni quels scores ont été comparés, et cette analyse n'en invente aucun. Elle repose sur l'argument énoncé par l'auteur et sur l'écart bien connu entre les tests au niveau du modèle et le travail au niveau de l'agent.

L'article ne s'arrête pas à la question de savoir quel score est le plus élevé. Il se déplace vers une interrogation plus utile : que doit vérifier un développeur qui évalue un modèle local pour un usage d'agent ? Ce déplacement constitue l'apport principal du texte.

Analyse approfondie

Pourquoi le benchmark au cœur du débat entre LLM local et Claude Code est-il trompeur ? Parce que la plupart des benchmarks de code testent un modèle, alors que Claude Code est un agent. Un benchmark classique propose au modèle un problème assez isolé, lui demande une fonction ou une complétion en un seul tour, puis note le résultat avec des tests unitaires. Cela mesure la compétence de codage sur un contexte court et des frontières nettes. Claude Code fonctionne autrement. Il lit les répertoires et les fichiers, décide où chercher, appelle des outils de recherche, d'édition et de commandes shell, puis corrige son travail après chaque erreur jusqu'à ce que les tests passent. Une seule tâche peut mobiliser des dizaines d'appels d'outils, et le contexte grossit à chaque sortie. Le succès dépend donc de bien plus que de la qualité d'un extrait généré. Le résumé de l'article désigne quatre mesures mieux adaptées à ce travail : la stabilité des appels d'outils, le comportement en contexte long, le taux d'achèvement des tâches en plusieurs étapes et la vitesse d'inférence. La stabilité des appels d'outils suppose que le modèle émette chaque appel dans le format convenu. Un faible taux d'échec par étape s'accumule sur une longue session. Deux modèles aux scores proches sur des problèmes isolés peuvent ainsi se comporter très différemment dans une boucle d'agent.

Le contexte long et la vitesse pèsent encore plus en local. Un historique plus long consomme davantage de mémoire GPU et ralentit le préremplissage, car l'historique croissant est retraité à chaque tour. L'utilisateur le ressent comme une attente, pas comme un manque d'intelligence. La quantification permet de faire tenir un modèle sur du matériel grand public, mais elle peut dégrader le format des appels d'outils et le raisonnement à long terme. Un benchmark à problème unique révèle rarement cette perte.

Impact sur l'industrie

Pour les développeurs individuels, le risque est concret. Résilier un abonnement cloud parce qu'un modèle local affiche un bon score peut se retourner contre soi. Le modèle semble suffisant dans un classement, puis bute sur des appels d'outils ratés, des consignes oubliées ou des réponses trop lentes dans un vrai projet. L'erreur inverse existe aussi : juger les modèles locaux inutiles sur la seule expérience d'agent masque des usages légitimes, comme les réseaux d'entreprise isolés, le code sensible, le travail hors ligne et les tâches plus légères telles que la complétion, l'explication ou les petits remaniements.

Pour les éditeurs de modèles et d'outils, l'argument déplace la concurrence du score de classement vers le système d'agent complet. Les questions deviennent : quel modèle utilise les outils le plus fiablement, qui gère le mieux le contexte et le cache, dont le client maîtrise le mieux les nouvelles tentatives, les permissions et le découpage des tâches. Une grande part de la force de Claude Code vient de l'ajustement conjoint du modèle et de son enveloppe d'outils. Des poids ouverts seuls ne peuvent pas facilement le reproduire.

Pour les communautés open source et les frameworks d'inférence locale, l'article trace une voie d'amélioration claire. Ces projets peuvent renforcer la compatibilité des appels d'outils, accélérer l'inférence en contexte long et publier des évaluations plus proches de la réalité des agents : correction de bout en bout de tickets dans de vrais dépôts, avec taux de réussite, durée écoulée et causes d'échec consignées.

Perspectives

Plusieurs signaux méritent d'être suivis. Le premier est l'évolution des habitudes d'évaluation. Si davantage de rapports présentent des taux d'achèvement multi-étapes, des taux d'erreur d'appels d'outils, des courbes de dégradation en contexte long, ainsi que le temps et le coût totaux par tâche, la communauté comble la lacune décrite par l'article.

Le deuxième est l'entraînement spécifique des modèles locaux pour les agents. Si les modèles ouverts sont optimisés pour l'usage d'outils et la planification à long terme, l'écart avec les agents cloud pourrait se réduire plus vite que ne le suggèrent les scores sur problème isolé. Le troisième est le progrès du matériel et des logiciels d'inférence : meilleure réutilisation du cache, quantification améliorée, mémoire grand public plus généreuse. Ces éléments décident si un agent local à contexte long reste agréable à utiliser.

Une approche hybride paraît plus réaliste qu'un choix exclusif : un modèle local traite les étapes sensibles ou peu complexes, tandis qu'un modèle cloud plus puissant prend la planification et les problèmes difficiles. Le conseil le plus pratique reste de ne se fier à aucun score isolé. Faites passer chaque modèle candidat sur vos propres tâches réelles, plusieurs fois, notez le taux de réussite, les reprises et le temps d'attente, puis décidez.