Fable 5, Opus 4.8 et Sonnet 4.6 : comment comparer honnêtement des LLM sur son propre code

Quand un nouveau modèle sort, l'annonce répond à la question « à quel point est-il meilleur sur les benchmarks » — et ne répond pas à la seule question qui m'intéresse : qu'est-ce qu'il changera dans mon travail. J'ai mené une expérience contrôlée : trois modèles Claude — Fable 5, Opus 4.8 et Sonnet 4.6 — ont reçu mot pour mot la même tâche d'audit de la base de code de ce blog, chacun dans une copie isolée du dépôt, avec une grille d'évaluation convenue à l'avance. Dans l'article : la méthodologie elle-même, reproductible sur n'importe quel projet, les résultats, et séparément — comment l'expérience a échoué deux fois et ce que cela m'a appris.

Pourquoi les benchmarks ne répondent pas à ma question

Les benchmarks publics ont deux problèmes, tous deux fondamentaux. Le premier est la contamination des données : les exemples de test s'infiltrent dans les ensembles d'entraînement, et le modèle « se souvient » partiellement des réponses au lieu de résoudre la tâche. Ce n'est pas une suspicion marginale, mais l'objet de tout un pan de recherche : la revue de Xu et coauteurs (2024) systématise les recherches sur la contamination des benchmarks, et la revue EMNLP 2025 acte la réponse de l'industrie — passer de tests statiques à des tests générés dynamiquement.

Le second problème est plus simple : le benchmark ne mesure pas ma tâche. Je n'ai pas besoin d'un modèle qui résout le mieux les problèmes d'olympiades. J'ai besoin d'un modèle qui trouve de vrais bugs dans mon blog Laravel, n'invente pas de problèmes inexistants et prouve que son correctif fonctionne.

Il en découle une idée simple : le meilleur banc d'essai pour comparer des modèles, c'est son propre projet. Son code, dans une telle combinaison, n'est pas dans les ensembles d'entraînement, les tâches qu'on y trouve sont exactement celles pour lesquelles je paie, et je peux vérifier les résultats à la main parce que je connais ce code.

Conception de l'expérience : un prompt, trois mondes isolés

La tâche était mot pour mot identique pour les trois modèles — seuls le nom de branche et le dossier de résultats différaient. Quatre phases : audit du système bilingue d'articles du blog avec preuve de chaque constat sous forme de файл:строка avec citation du code ; choix de solutions pour les trois principaux constats avec description des compromis ; implémentation d'un correctif avec auto-vérification ; note sur les résultats en russe et en anglais. Un cycle complet de travail d'ingénierie, et non une « question-réponse » isolée — une approche que recommande aussi Anthropic: évaluer les agents sur des tâches issues d'un produit réel, selon une grille convenue avant le lancement.

Trois règles ont rendu la comparaison honnête :

Isolation. Chaque modèle travaillait dans un git worktree séparé — sa propre copie du répertoire de travail avec sa propre branche. Les modèles ne pouvaient physiquement pas voir les résultats des autres ni se gêner mutuellement.

Protection contre les hallucinations — dans le prompt lui-même. La ligne clé de la tâche : « un constat inventé (code inexistant, mauvaise ligne) est pire que l'absence de constat ». Sans cet incitatif, un modèle à qui l'on demande de trouver des problèmes a tendance à en « trouver » dans tous les cas. Avec lui — chaque constat doit survivre à une vérification manuelle.

Exclusion des indices du décompte. Le dépôt contient un CLAUDE.md qui décrit les pièges connus du projet — par exemple, les chemins relatifs vers les assets, qui cassent sur les URL avec préfixe de langue. Les trois modèles lisent ce fichier, donc ces constats sont « gratuits » : ils comptent pour la rigueur, mais pas pour la profondeur.

Grille : n'évaluer que ce qui peut être vérifié à la main

Avant le lancement, j'ai fixé six axes sur cinq points : exactitude de l'audit (vérification manuelle d'un échantillon de constats via файл:строка), profondeur (constats confirmés absents des indices), qualité du raisonnement sur les compromis, code et réalité de l'auto-vérification, qualité des textes russe et anglais, discipline (zéro question à l'humain, aucune violation des contraintes). Le principe est le même que pour une bonne revue de code : moins un axe repose sur le goût et plus il repose sur un fait vérifiable, plus on peut lui faire confiance.

Comment tout a échoué la première fois

J'ai fait le premier lancement de manière incorrecte — et c'est devenu la partie la plus transférable de l'expérience. J'ai ouvert trois sessions interactives en parallèle dans un même dossier du dépôt. Quelques minutes plus tard, l'arbre de travail contenait des modifications non commitées impossibles à attribuer : un checkout commun signifie que quand une session fait git checkout -b, la branche change pour les trois, et leurs modifications et commits se mélangent. L'une des sessions a en plus fait git stash et y a tout balayé — y compris mes propres fichiers sans rapport avec l'expérience.

« Des agents IA parallèles dans un même dossier, ce n'est pas une expérience parallèle. C'est un seul grand conflit avec trois auteurs. »

– la conclusion qui m'a coûté un redémarrage

Les résultats de deux sessions ont dû être jugés inutilisables : même s'ils avaient été menés jusqu'au bout, je n'aurais pas pu dire honnêtement dont j'évaluais les corrections. Le deuxième lancement — déjà dans des worktrees isolés — s'est heurté aux limites du forfait : deux agents sont morts au démarrage, et le troisième s'est figé tout en continuant d'apparaître « en cours » dans l'interface. Le diagnostic a été posé par le système de fichiers, pas par l'indicateur de statut : en vingt minutes, aucun fichier n'est apparu dans sa copie de travail. C'est la deuxième leçon transférable : la vivacité d'un agent se vérifie par les changements sur le disque. Après redémarrage, les trois modèles ont suivi le cycle complet dans des conditions égales.

Résultats : où les modèles se ressemblent et où ils diffèrent

Le résultat le plus important est ce qui ne s'est pas produit : aucune hallucination chez aucun modèle. J'ai vérifié manuellement au moins trois trouvailles de chacun — toutes les citations et tous les numéros de ligne sont exacts au caractère près. Pour les tâches d'audit, c'est le principal seuil de confiance, et les trois l'ont franchi.

Ensuite commencent les différences :

	Fable 5	Opus 4.8	Sonnet 4.6
Trouvailles confirmées	11	5	9
Uniques non triviales	3	1	2
Auto-vérification du correctif	rendu d'intégration sur une base temporaire, xmllint, attribution d'un test échoué d'autrui	linter + rendu ; a attrapé son propre bug	seulement le linter et la liste des routes
Tokens / temps	164k / 21 min	101k / 12 min	131k / 12 min
Total selon la grille (sur 30)	30	24	25,5

Les différences qualitatives sont plus informatives que les points. Opus 4.8 est le seul à ne pas avoir remarqué le titre cassé Content-Type dans le sitemap (les deux autres l'ont trouvé) et l'a laissé dans son propre correctif ; et un mot anglais s'est glissé dans son texte russe — « и even путь к картинке ». Sonnet 4.6 a fait un correctif correct, mais son auto-vérification était déclarative : le linter au lieu d'une exécution. Fable 5 s'est distinguée précisément sur l'auto-vérification : elle a découvert que php sur ma machine est un wrapper autour d'un conteneur docker monté sur le répertoire principal, a reconstruit toutes les vérifications via des conteneurs jetables et a fait tourner son correctif en intégration sur une base temporaire. La différence entre « je l'ai fait » et « j'ai prouvé que je l'ai fait » — c'est justement l'axe le plus discriminant pour les tâches agentiques.

Un autre signal utile est la convergence : les trois modèles ont indépendamment désigné comme trouvaille principale le même problème de sitemap. Quand des auditeurs indépendants convergent sur la trouvaille principale, c'est un substitut peu coûteux de l'accord inter-experts : le problème est presque certainement réel.

Un juge parmi les participants

L'évaluation selon la grille a été réalisée par Fable 5 — le même modèle qui participait à la comparaison. C'est un trou méthodologique, et il faut en parler directement : les juges LLM surestiment systématiquement leurs propres textes, et cette tendance est d'autant plus forte que le modèle reconnaît mieux ses textes — cela est montré dans le travail de Panickssery et coauteurs à NeurIPS 2024. On peut atténuer le biais de deux manières, et j'ai utilisé les deux : premièrement, déplacer autant que possible la grille des axes de goût vers des faits vérifiables — l'exactitude des lignes, la complétude du correctif, un mot étranger échappé ne dépendent pas des sympathies du juge ; deuxièmement, déclarer explicitement le conflit et confier les axes litigieux à une vérification croisée par un autre modèle ou un humain. Les axes subjectifs de mon total — la qualité du texte, la qualité du raisonnement — doivent être lus avec cette correction.

Limites d'honnêteté

Un seul passage par modèle, c'est n=1 : les différences d'un ou deux points ne signifient rien, seuls les écarts qualitatifs méritent confiance — un bug manqué, la profondeur de l'auto-vérification. L'expérience mesure trois modèles sur une tâche dans un domaine ; «Fable 5 est meilleur en général » n'en découle pas. Et il faut garder en tête le coût : le modèle de tête a dépensé 1,6 fois plus de tokens et presque deux fois plus de temps que le participant le plus économe, et son token au tarif est en plus plus cher en soi — pour des tâches régulières, c'est un argument de poids en faveur de modèles plus simples.

Ce que je retiens pour moi

La méthodologie s'est réduite à une courte checklist qui fonctionne pour n'importe quel projet et n'importe quels modèles :

• Une épreuve de test — le cycle complet d'un travail réel sur son propre code, pas un petit exercice synthétique.
• Un seul prompt pour tous, isolation via des worktrees séparés, résultats dans des branches séparées.
• Dans le prompt — un prix explicite de l'hallucination : une trouvaille inventée est pire que l'absence de trouvaille.
• Les indices accessibles à tous (documentation, notes dans le dépôt) sont exclus du décompte de profondeur.
• La grille est fixée avant le lancement et s'appuie sur des faits vérifiables, pas sur une impression.
• Vérifier à la main un échantillon des trouvailles ; la concordance des trouvailles principales entre modèles indépendants est un signal de leur réalité.
• Un juge participant — un conflit déclaré : confier les axes litigieux à une évaluation croisée.
• Vérifier la vivacité de l'agent par le disque, pas par l'indicateur dans l'interface.

Bonus qui n'était pas prévu : l'expérience s'est rentabilisée d'elle-même. Trois audits indépendants ont trouvé dans le blog de vrais problèmes — d'un sitemap sans pages anglaises à des requêtes mortes dans le contrôleur — et deux correctifs prêts sont déjà dans les branches, en attente de passage en prod. Comparer des modèles sur son propre code, contrairement à la lecture de benchmarks, ne laisse pas seulement une opinion.

Sources et repères

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — une systématisation du problème de la contamination des benchmarks ; l'argument principal en faveur de tests sur son propre code.
• Benchmarking LLMs Under Data Contamination: From Static to Dynamic Evaluation (EMNLP 2025) — comment l'industrie passe des tests statiques aux tests dynamiques ; mon expérience est un cas particulier de test dynamique.
• Demystifying evals for AI agents (Anthropic Engineering, 2026) — la pratique de l'évaluation des agents : tâches issues d'un produit réel, rubriques vérifiables, distinction entre trajectoire et résultat.
• LLM Evaluators Recognize and Favor Their Own Generations (NeurIPS 2024) — pourquoi le modèle-juge surestime ses propres réponses et que faire à ce sujet.
• Run parallel sessions with worktrees (Claude Code Docs) — le mécanisme standard d'isolation des sessions d'agents parallèles, sans lequel le premier lancement de l'expérience s'est effondré.