Meilleurs modèles LLM, pires outils : le paradoxe du fine-tuning propriétaire

Les LLM progressent vite, mais cette progression a un coût caché. Armin Ronacher, créateur de Flask et Jinja2, vient de documenter un cas concret et dérangeant : les modèles Anthropic les plus récents sont moins fiables que leurs prédécesseurs sur certains schémas d’outils tiers. Voilà qui mérite qu’on s’y arrête sérieusement.

Le problème : des modèles LLM qui régressent sur l’interopérabilité des outils

Ronacher travaillait sur Pi, son outil de développement personnel, quand il a repéré une anomalie. Claude Opus 4.8 et Sonnet 5 inventaient des champs supplémentaires lors des appels à l’outil d’édition de Pi. Des clés fantaisistes comme requireUnique, matchCase, forceMatchCount ou encore oldText2 apparaissaient dans les arguments, alors que le schéma de Pi n’en attend aucune. Pi rejetait l’appel, le modèle devait recommencer.

Ce qui est frappant : les anciens modèles Anthropic ne montraient pas ce comportement. Opus 4.5 s’adaptait très bien aux schémas d’outils alternatifs. Avec Opus 4.8 et Sonnet 5, le taux d’échec atteignait 20 % sur certaines sessions agentiques prolongées.

Pourquoi ça arrive : le couplage post-training / harness

Pour comprendre le mécanisme, il faut savoir comment fonctionnent les appels d’outils dans les LLM. Ce ne sont pas des appels de fonction classiques. Le modèle reçoit une transcription avec les outils disponibles, génère du texte structuré selon un format appris, et le serveur interprète ce texte comme un appel d’outil. Tout repose sur une convention apprise, pas sur une contrainte mécanique.

Ronacher avance une hypothèse solide : les nouveaux modèles Anthropic ont été entraînés, via du renforcement, dans un environnement très proche de Claude Code. Or Claude Code utilise un schéma d’édition plat (old_string, new_string, file_path), très différent du schéma imbriqué de Pi (edits[] avec oldText / newText).

Le résultat est prévisible une fois qu’on y pense : le modèle a un prior très fort sur la forme canonique de Claude Code. Face à un schéma sémantiquement similaire mais structurellement différent, il est hors distribution. Et comme son prior est plus fort qu’avant, il résiste davantage.

La tolérance aux erreurs comme vecteur de dégradation

Il y a un deuxième facteur, encore plus subtil. Claude Code est un harness très indulgent. Ronacher a inspecté le code minifié et listé ce que Claude Code tolère silencieusement :

• Des champs inconnus, filtrés sans erreur
• Des alias de paramètres (old_str, old_string, path pour file_path)
• Des séquences Unicode malformées, réparées automatiquement
• Des blocs <invoke> qui fuient dans le texte visible, avec retry automatique

Conséquence directe : pendant le renforcement, un appel légèrement malformé pouvait quand même réussir dans cet environnement et recevoir une récompense. Le gradient contre l’invention de champs supplémentaires était faible ou nul. Le modèle a appris qu’un champ en trop ne pose pas de problème, parce que dans son environnement d’entraînement, ça n’en posait pas.

Ce que ça change pour les harnesses tiers

La conclusion de Ronacher est inconfortable pour quiconque construit des agents ou des outils sur les API Anthropic. Quelques points clés :

• Le mode strict (strict: true dans la définition de l’outil) élimine le problème, car le serveur contraint alors l’échantillonnage aux clés autorisées. Mais Anthropic impose des limites de complexité sur les schémas en mode strict, ce qui peut bloquer certains cas d’usage.
• Les modèles Codex testés par Ronacher ne montrent pas cette régression, probablement parce que le harness OpenAI (notamment le format Harmony avec contrainte JSON en-bande) offre plus de visibilité sur le pipeline.
• Plus le post-training se concentre sur un harness propriétaire fermé, plus les harnesses tiers hériteront de ses quirks implicites, qu’ils le sachent ou non.
• Adapter son schéma d’outil pour coller à la forme canonique de Claude Code peut être une solution de court terme, mais ce n’est pas une solution d’architecture pérenne.

Ronacher note aussi que les échecs sont très sensibles au contexte : sur un prompt simple à un tour, le problème ne se reproduit pas. C’est dans les sessions agentiques longues, avec historique de lecture de fichiers, blocs de réflexion accumulés et éditions multi-lignes, que le modèle déraille. Supprimer les blocs thinking de l’historique réduisait le taux d’échec de moitié dans ses tests.

Ce qu’il faut retenir

• Un modèle LLM plus puissant peut être plus rigide sur l’interopérabilité des outils, pas moins. C’est un paradoxe documenté, pas une hypothèse.
• Le post-training sur un harness propriétaire fermé (comme Claude Code) crée une dette d’interopérabilité invisible pour les développeurs tiers.
• La tolérance aux erreurs d’un harness d’entraînement se retrouve encodée dans le comportement du modèle, même dans des contextes où cette tolérance n’existe pas.
• Le mode strict Anthropic est une parade efficace mais contrainte. Il faut l’évaluer selon la complexité de votre schéma.
• La surveillance des régressions sur les appels d’outils doit devenir une partie normale du monitoring de vos agents, au même titre que la qualité des sorties texte.

Si vous construisez des agents sur des API LLM, ce type de régression silencieuse est exactement ce que les benchmarks classiques ne capturent pas. C’est le genre de sujet dont j’aime discuter, n’hésitez pas à me contacter ou à suivre le blog pour les prochaines analyses.

Sources

• Armin Ronacher, « Better Models: Worse Tools », lucumr.pocoo.org, 4 juillet 2026 : https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/
• Documentation Anthropic sur le mode strict et les appels d’outils : https://docs.anthropic.com/en/docs/build-with-claude/tool-use