Claude Haiku vs Opus : quel modèle pour corriger ?
Claude Haiku obtient 52 corrections propres contre 54 pour Opus, pour un coût inférieur de 95 %. Découvrez les résultats et choisissez selon vos bugs.
Pour corriger du code, Haiku peut-il vraiment remplacer Opus ?
Un modèle d'IA plus puissant est-il forcément meilleur pour corriger un bug ? Sur le papier, la réponse paraît simple. En production, tout dépend surtout de la difficulté du problème, de la qualité des tests disponibles et du coût de ce qu'on laisse derrière quand quelque chose se trompe.
Un test sur 25 bugs réels (issus de projets open source) donne un premier ordre de grandeur. Sur 75 exécutions par modèle, Claude Haiku 5.5 produit 52 corrections propres, contre 54 pour Opus 5.5. L'écart est faible, et le coût cumulé d'Haiku est d'environ 95 % inférieur. Mais non, ça ne veut pas dire que les deux modèles se valent partout : Opus gère mieux certains bugs difficiles et casse moins souvent des tests existants.
Pour une équipe technique, la question n'est donc pas « qui gagne ? ». Elle est plutôt : à quel moment un modèle moins cher suffit, quand un modèle plus prudent devient utile, et pourquoi aucun modèle ne peut compenser un rapport de bug incomplet. Voici ce que ce protocole éclaire - et ce qu'il ne permet pas de conclure - puis comment en tirer une règle de décision utilisable.
Les résultats : presque autant de corrections pour Haiku
L'expérience compare Claude Haiku 5.5, Sonnet 5.5 et Opus 5.5 sur 25 bugs déjà corrigés en amont dans 13 projets open source. Les dépôts couvrent des bibliothèques JavaScript et Python, notamment js-yaml, markdown-it, zod, cachetools et Python-Markdown.
Pour chaque bug, l'agent repartait du commit qui précède la correction. Il pouvait lire le code, le modifier et exécuter les tests du projet. En revanche, il n'avait ni l'historique Git ni accès au réseau. Le prompt donnait le symptôme, les étapes de reproduction et le résultat attendu, mais retirait l'analyse de la cause et la solution proposée par les mainteneurs.
Chaque modèle a effectué trois tentatives par bug. Au total, cela fait 75 exécutions par modèle, soit 225 au global. Une correction était dite « propre » si elle réussissait les tests des mainteneurs associés au bug sans faire échouer d'autres tests du projet.
| Mesure | Haiku 5.5 | Sonnet 5.5 | Opus 5.5 |
|---|---|---|---|
| Corrections propres, bugs faciles | 40/45 | 35/45 | 38/45 |
| Corrections propres, bugs difficiles | 12/30 | 14/30 | 16/30 |
| Corrections propres, total | 52/75 | 49/75 | 54/75 |
| Exécutions difficiles ayant cassé d'autres tests | 10 | 7 | 5 |
| Coût moyen d'une exécution, selon les tarifs API utilisés | 0,019 $ | 0,14 $ | 0,38 $ |
| Coût des 75 exécutions | 1,41 $ | 10,83 $ | 28,53 $ |
Un écart minime sur les bugs faciles
Sur les 15 bugs classés « faciles », les symptômes et causes étaient assez proches. Haiku obtient 40 corrections propres sur 45, contre 38 pour Opus et 35 pour Sonnet. Ce n'est pas une preuve qu'Haiku soit « meilleur » : avec seulement trois essais par bug, les écarts restent fragiles. Mais ça suggère qu'un modèle plus petit peut suffire quand le problème est bien cadré et bien reproductible.
Le coût apporte une autre lecture. Dans ce protocole, une exécution Haiku coûte environ 0,019 $, contre 0,38 $ pour Opus. À quantité d'appels égale, on est sur un ordre de grandeur d'environ 95 % de moins. Pour une équipe qui lance des dizaines (voire des centaines) d'analyses ou de corrections assistées, ce différentiel mérite d'être regardé de près, pas rangé au « détails ».
Opus prend l'avantage sur les cas difficiles
Les dix bugs « difficiles » reposaient souvent sur un symptôme plus éloigné de la cause, ou touchaient plusieurs parties du code. Haiku obtient 12 corrections propres sur 30 tentatives ; Opus en obtient 16.
Et surtout, quand ça dérape, ça dérape pour de vrai : Haiku casse d'autres tests dans 10 exécutions difficiles, contre 5 pour Opus.
Trois exemples montrent bien ces différences, sans que ça suffise à établir une règle générale :
- Dans marked, un lien placé dans le texte d'un autre lien a été corrigé proprement deux fois sur trois par Opus, mais jamais par Haiku. Les trois tentatives de Haiku échouent au test de spécification correspondant.
- Dans markdown-it, Opus réussit les trois tentatives. Haiku n'en réussit qu'une ; deux autres corrigent le cas rapporté en faisant échouer des tests voisins.
- Dans js-yaml, Haiku réussit les trois tentatives sur un bloc scalaire dont le contenu ne comportait que des espaces, alors qu'Opus n'en réussit qu'une.
Le tableau n'est donc pas « petit modèle contre grand modèle » de façon brute. Il décrit plutôt un compromis : un résultat agrégé proche, mais une meilleure marge de sécurité pour Opus sur certains cas plus complexes.
Ce que les chiffres disent - et ne disent pas
La comparaison directe - 52 corrections propres pour Haiku contre 54 pour Opus - est utile, mais elle ne suffit pas à conclure que tout se vaut. Les bugs ne sont pas des observations indépendantes : trois tentatives sur le même problème restent trois tentatives sur le même problème. Et l'échantillon (25 bugs) reste petit.
Le test statistique présenté pour l'ensemble des bugs ne met pas en évidence de différence détectable entre Haiku et Opus : le test exact de Fisher donne p = 0,86. En rééchantillonnant les bugs, l'intervalle de confiance à 95 % pour l'écart (Haiku moins Opus) va de −11 à +5 points. Autrement dit : on n'a pas assez d'éléments solides pour dire qu'Opus corrige plus de bugs au total. À l'inverse, ça ne prouve pas non plus l'égalité, puisqu'un écart d'environ dix points reste compatible avec les données.
Sur les seuls bugs difficiles, l'intervalle devient encore plus large, de −33 à 0 points. Avec dix bugs, impossible de trancher proprement. Enfin, Sonnet valide une part plus faible des cas « réussis » que Opus sur l'ensemble de l'expérience : la différence ressort comme significative (p = 0,006). Mais cette mesure porte sur les cas de test réussis, pas sur toutes les tâches de développement prises ensemble.
Le problème du rapport incomplet
Le point le plus « actionnable » pour les équipes n'est peut-être même pas l'écart Haiku vs Opus. Sur trois bugs difficiles, les trois modèles corrigent bien le cas décrit... tout en ratant le même cas supplémentaire, celui que le rapport de bug ne mentionnait pas.
Dans cachetools, le signalement parle d'une manière d'appeler une méthode mise en cache depuis sa classe, alors que les tests des mainteneurs couvrent plusieurs variantes du décorateur. Dans js-yaml, le rapport cible un marqueur BOM en début de fichier, mais pas le même marqueur avant chaque document d'un flux multi-document. Dans Python-Markdown, les modèles corrigent le commentaire HTML signalé, mais font échouer plusieurs tests concernant des commentaires placés après d'autres éléments HTML en ligne.
Ça se résume à une idée assez simple : un agent ne peut pas déduire de façon fiable toutes les attentes implicites d'un projet à partir d'un symptôme isolé. Et payer plus cher ne remplace ni la lecture des tests existants, ni l'effort de clarification du ticket. Souvent, la meilleure dépense n'est pas « plus de puissance » : c'est une meilleure spécification.
Un exemple zod va dans le même sens. Il fallait gérer des clés numériques de records à plusieurs endroits de la sortie JSON Schema. Aucun modèle n'a tout couvert : Opus réussit 14 des 24 tests associés sur ses trois tentatives, Haiku en réussit 9 et Sonnet 5. Même le meilleur score ici ne donne donc pas une correction complète.
Quel modèle choisir dans un contexte professionnel ?
Pour une équipe produit ou une entreprise en France, la bonne question n'est presque jamais « quel modèle est le meilleur ? ». Elle est plutôt : « quel niveau de risque et de coût est acceptable pour ce type de tâches ? »
Un modèle moins cher peut réduire le coût d'un premier essai. Mais une correction imparfaite peut coûter ensuite en temps de revue, voire provoquer des régressions. Le prix de l'appel API n'est qu'une partie du budget.
Utiliser Haiku pour les corrections bien délimitées
Haiku est un choix raisonnable quand le bug est reproductible, localisé et accompagné de tests pertinents. Typiquement : une validation qui accepte une valeur interdite, une branche conditionnelle oubliée, ou un comportement déterministe décrit clairement.
Le schéma qui marche bien consiste à laisser le modèle proposer un correctif, puis à exécuter automatiquement les tests ciblés et le reste du projet. Si tout passe, la revue humaine se concentre sur le diff, les effets de bord et la cohérence avec le style du dépôt. L'idée est de profiter du faible coût d'Haiku sans confondre « tests verts » et « code sûr à 100 % ».
Réserver Opus aux cas à forte incertitude
Opus se justifie quand la cause est plus éloignée du symptôme, quand plusieurs composants sont impliqués, ou quand une première tentative risque de casser des comportements voisins. Dans l'expérience, il obtient plus de corrections propres sur les bugs difficiles, et il casse moins de tests dans cette catégorie.
Rien ne garantit pour autant qu'Opus réussira votre cas : on parle d'un échantillon précis, avec un protocole donné. Mais si le coût d'une régression est élevé - par exemple dans une bibliothèque centrale, un traitement de données ou une fonctionnalité utilisée par plusieurs équipes - privilégier le modèle qui a montré moins de régressions sur les cas complexes peut être un choix rationnel.
Mettre en place une escalade plutôt qu'un choix unique
Pour éviter de faire tourner le modèle le plus cher sur chaque ticket, une équipe peut suivre un parcours en étapes :
- Qualifier le ticket. Le bug est-il local et reproductible, ou le symptôme peut-il venir de plusieurs couches ?
- Améliorer les informations d'entrée. Ajouter un cas minimal, le résultat attendu, les versions concernées et les tests voisins utiles.
- Commencer par le modèle économique sur les cas simples, puis exécuter les tests pertinents.
- Escalader vers un modèle plus capable si les tests échouent, si le correctif touche plusieurs composants, ou si l'agent ne sait pas expliquer ce qu'il a changé.
- Relire le diff et vérifier les cas non couverts avant toute fusion.
Cette approche est plus solide qu'une règle fixe basée sur le nom du modèle ou sa taille. Elle permet aussi de mesurer les coûts « réels » : appels, temps de revue, corrections reprises, régressions détectées après livraison. À terme, ces données internes pèsent plus lourd qu'un classement général : elles reflètent votre code, vos standards et votre organisation.
Protocole et limites de l'expérience
Les résultats doivent être pris comme un signal, pas comme un benchmark définitif. Chaque bug a été tenté trois fois par modèle et l'ensemble ne couvre que 25 bugs. Les performances peuvent varier selon le langage, le dépôt, la qualité des tests et le type de tâche. Pour démontrer une équivalence « à dix points près », il faudrait plusieurs centaines d'exécutions par modèle sur des bugs différents.
D'autres limites comptent aussi :
- Par rapport à une expérience antérieure de l'auteur, ici chaque agent pouvait exécuter les tests du projet. Le contexte d'évaluation n'est donc pas identique.
- Le rapport relatif à tomlkit a été rédigé par l'auteur à partir du ticket amont, qui ne fournissait pas de reproduction. Tous les modèles ont toutefois réussi les mêmes 20 cas sur 29.
- Sous Windows, le fichier CLAUDE.md de zod, qui était un lien symbolique, n'a pas été extrait. Les agents n'ont donc pas reçu les instructions spécifiques au projet.
- Les tests de durée n'ont pas été comptabilisés comme régressions, car ils échouaient de manière aléatoire sous charge.
- Les dépôts étant publics, il est possible que certains modèles aient déjà rencontré du code similaire pendant l'entraînement, même si les corrections étudiées datent d'août à octobre 2026.
Enfin, les prix indiqués servent à calculer le coût de cette expérience. Ils ne reflètent pas un coût complet de production : ils ne comptent pas le temps humain, l'infrastructure, l'intégration, la supervision, ni le traitement des erreurs après livraison. L'auteur indique aussi diriger TokenSave, qui publie ces mesures, et ne pas avoir reçu de soutien ou de crédits d'Anthropic. Cette précision aide à situer l'étude, sans remplacer une réplication indépendante.
Les données des 225 exécutions - cas réussis, tests cassés, durée et coût - sont disponibles en CSV et JSON, sous licence CC BY 4.0. Le protocole et l'article d'origine permettent de consulter les détails.
Conclusion : payer plus seulement quand le risque le justifie
Sur des bugs bien localisés et bien décrits, Haiku peut donner un bon rapport coût-résultat : dans ce test, le nombre de corrections propres reste proche de celui d'Opus pour un coût API nettement inférieur. Sur les cas plus difficiles, Opus paraît plus prudent, mais l'échantillon ne permet pas d'en faire une règle générale.
La façon la plus solide de décider : classer les tâches par difficulté, faire passer les correctifs par les tests du dépôt, et escalader quand l'incertitude ou le coût d'une régression augmente. Et avant de changer de modèle, vérifiez la qualité du ticket et des tests : aucun modèle ne « voit » un cas que le signalement et le protocole ne lui permettent pas de couvrir.
Comparez cette approche à vos propres tickets : mesurez le coût total, le taux de corrections acceptées et les régressions, puis choisissez le modèle selon vos résultats plutôt que sur une promesse générale.