Tester Opus 5.5 comme référence de code review

TL;DR

J’évaluerais un reviewer Opus 5.5 à effort explicite avant de construire une flotte plus grande. Cette référence est candidate à la prochaine comparaison contrôlée, avec corpus qualifié et acceptation indépendante ; le pilote précédent n’en a pas fait un modèle gagnant.

Décision	Point de départ pour Opus 5.5
Premier reviewer à évaluer	1 reviewer Opus 5.5 borné sur des changements de repository figés
Effort	medium explicite, puis comparaison mesurée avec high
Escalade à tester	Fable 5.2 sur les cas manqués par Opus 5.5 à effort supérieur
Reviewers supplémentaires	Les garder s’ils détectent des défauts vérifiés manqués par la référence
Migration du harnais	Mapper blocs de thinking, refus, appels d’outils forcés et replis dans l’adaptateur
Mesure de réussite	Défauts vérifiés, fausses alertes, temps de review et coût de toutes les tentatives

La boucle de review des parties 1 à 7 a besoin d’un modèle concret comme point de départ. Pour la prochaine évaluation, c’est Opus 5.5, testé comme 1 reviewer borné avant tout ajout d’un deuxième. Cet article explique ce que les preuves de lancement soutiennent ou non, les changements de harnais nécessaires et ce que l’évaluation doit consigner.

Anthropic a sorti Opus 5.5 le 22 septembre 2026. Sa page de lancement rapporte 66,4 % sur Terminal-Bench 4.0 à effort xhigh, contre 55,8 % pour Fable 5.1 à max. Elle rapporte une réduction de coût de 40 % face à Opus 5 aux réglages par défaut sur ses charges habituelles. Le catalogue d’Anthropic, vérifié le 10 novembre 2026, recommande maintenant Fable 5.2 pour les cas où Opus 5.5 à effort supérieur reste insuffisant.

La page présente aussi un témoignage Deloitte affirmant qu’Opus 5.5 à faible effort a détecté 72 % des bugs connus dans ses reviews, contre 56 % pour Opus 5 à effort élevé. Le corpus et le compte rendu des arbitrages n’y sont pas fournis : c’est donc une déclaration client relayée par le fournisseur, pas une comparaison de review reproductible indépendamment. Ces sources justifient des candidats à tester ; elles ne tranchent pas la configuration adaptée à notre repository. Fable 5.2 reste candidat à l’escalade sous réserve d’accès et d’évaluation.

Commencer avec 1 reviewer et une question utile

Références modèles

La présentation actuelle des modèles Claude liste claude-opus-5-5, claude-fable-5-2, claude-sonnet-5-5 et claude-haiku-5-5. Elle donne à Opus 5.5 un effort par défaut medium et à Fable 5.2 high. Sonnet et Haiku sont disponibles dans la famille, mais cet article ne les évalue pas comme reviewers. La présence chez un fournisseur ne prouve pas l’accès via notre compte ou notre circuit de déploiement.

Les noms Opus 4.8 et Sonnet 5 du pilote de septembre ci-dessous restent historiques. Actualiser une liste de candidats ne change pas les modèles ayant produit un résultat antérieur.

Un système de review peut accumuler les agents sans accumuler les preuves. Un agent cherche des bugs, un autre refait la recherche, un troisième résume leurs recoupements et un développeur décide toujours quels commentaires comptent. Un modèle plus capable donne une raison de tester si une partie de cette mécanique peut disparaître.

La première question est de savoir si 1 reviewer Opus 5.5 trouve les défauts requis, les explique assez bien pour agir et termine le périmètre déclaré dans le budget. La seconde porte sur l’apport d’un reviewer séparé sur les cas manqués. Un spécialiste sécurité, un contrôle déterministe et un autre reviewer généraliste sont des interventions différentes : attribuez donc à chacun une propriété définie à examiner.

La partie 7 montre pourquoi cela compte : sur 1 repository avec 5 reviewers IA, 4,5 % des commentaires inline ont reçu une réponse humaine visible. Avant la comparaison, établissez les défauts de référence avant toute lecture des sorties, comme décrit en partie 7, et incluez aussi des changements sans défaut connu : un reviewer qui trouve toujours quelque chose à dire crée du travail, même si ses constats positifs impressionnent.

Calibrer l’effort avant d’ajouter des agents

Les conseils de prompting Opus 5.5 d’Anthropic recommandent de commencer à medium, sa valeur par défaut, de la définir explicitement et de tester d’autres niveaux avec vos évaluations. Ils avertissent aussi que les noms d’effort ne correspondent pas à la même quantité de thinking entre modèles : dans les tests d’Anthropic, Opus 5.5 à medium égale ou dépasse Opus 5 à high sur les évaluations de code et de travail intellectuel. Reconduire un ancien réglage high ou max peut changer le coût et la durée de chaque review.

Utilisez les mêmes changements qualifiés dans ces conditions :

Gardez prompt, outils autorisés, état initial de l’application et corpus fixes entre niveaux d’effort. Pour la dernière condition, comptez les deux reviewers et le travail d’agrégation. Un système qui dépense deux fois plus doit montrer ce que cette dépense achète.

Rendre l’adaptateur compatible avec Opus 5.5

Le guide de migration, vérifié le 14 octobre 2026, liste les changements pour un client Messages API personnalisé :

• le thinking adaptatif est toujours actif, et max_tokens couvre thinking et texte de réponse
• les types forcés tool_choice any et tool renvoient une erreur 400 ; utiliser auto et valider les entrées d’outils
• le texte du thinking est omis par défaut ; demander thinking.display: "summarized" si une progression visible est nécessaire
• renvoyer le message de l’assistant complet et inchangé, blocs de thinking compris, lors de la fourniture des résultats d’outils
• un refus peut renvoyer HTTP 200 avec stop_reason: "refusal" et une catégorie dans stop_details
• un repli côté serveur configuré peut changer le modèle qui répond à une demande refusée

La prise en charge des outils stricts et des sorties structurées diffère selon la plateforme ; le parcours Bedrock documenté utilise auto sans strict. Analysez les blocs de contenu par type au lieu de supposer que content[0] contient du texte. Ce sont des contrats API documentés, pas un adaptateur que j’ai testé dans cet article.

Claude Code gère sa propre intégration. Un client personnalisé nécessite les correspondances ci-dessous, qui traduisent ces comportements vers les états d’exécution et causes d’arrêt de la partie 3 :

Donnez à l’adaptateur des fixtures pour une liste de constats vide valide, des constats mal formés, un refus, un budget épuisé et une séquence d’outils interrompue. Cet article propose ces contrôles d’acceptation ; il n’affirme pas qu’un adaptateur les a réussis. Un repli pris en charge reste soumis à la politique d’autorisation du workflow.

Un tour terminé nécessite encore un résultat de tâche

Un reviewer peut décrire son travail et annoncer son étape suivante sans la terminer. L’orchestrateur a besoin d’une checklist conservée du travail requis, pas d’une supposition fondée sur le ton du dernier paragraphe.

À la fin d’un tour, examinez obligations restantes et travail en arrière-plan. Si les contrôles sont terminés, validez le rapport terminal. Si du travail reste et que l’exécution peut continuer, nommez ce travail dans une continuation bornée. Refus, permissions manquantes et budgets épuisés restent des causes d’arrêt explicites ; une politique de continuation ne doit pas inviter à contourner ces frontières.

Pour la conception initiale, j’autoriserais au plus 2 continuations automatiques dans une passe de review, avec de nouvelles preuves de progression entre elles. C’est une limite opérationnelle proposée, pas un optimum mesuré. Elle arrête l’exécution avec un résultat défendable ou assez d’informations pour résoudre le blocage.

Ce qu’enseigne encore le pilote précédent

Un pilote antérieur, que j’ai exécuté en septembre sur Opus 4.8 et Sonnet 5 et que je n’ai pas publié, a effectué 48 tentatives sur 12 pull requests. Il a révélé 5 frontières de diff incorrectes. Dans 1 cas, une review avait reçu 1 996 fichiers modifiés là où la base corrigée en produisait 16. La préparation omettait aussi certains fichiers sources pertinents. Aucun résultat ne se transfère à Opus 5.5.

La leçon à conserver est un contrôle de préparation. Consignez base et head sélectionnés, fichiers modifiés attendus, fichiers réels du diff, sources complètes disponibles et contexte manquant, puis arrêtez sur tout écart inexpliqué. Un reviewer plus puissant pourrait trouver un vrai bug dans un paquet surdimensionné, mais ce constat nécessite un traitement séparé et ne dit rien de la couverture du changement prévu.

Mesurer ce qui atteint un changement accepté

Chaque dossier de review identifie claude-opus-5-5, le fournisseur de déploiement, la version du client, l’effort et le modèle ayant réellement répondu à chaque tentative. Un repli change le traitement : rapportez donc les exécutions mixtes séparément de la condition Opus 5.5.

Pour chaque condition, conservez défauts vérifiés, fausses alertes, omissions face à la référence cachée, résultats complets et partiels, temps écoulé, coût de toutes les tentatives et temps humain passé à résoudre les constats. Un deuxième reviewer qui détecte 1 omission grave peut valoir son coût ; un autre qui produit 20 commentaires en doublon dégrade le workflow.

Inspect AI, maintenu par l’AI Security Institute britannique, offre une structure d’évaluation documentée avec datasets, solvers et scorers séparés, et des logs pour examiner les exécutions individuelles. C’est une implémentation à examiner si la comparaison proposée grandit. Choisir un scorer fondé sur un modèle nécessite encore de vérifier ses jugements contre une référence indépendante. Je n’ai pas intégré Inspect à la préparation Luna/Astra, et ses fonctions disponibles ne valident pas notre corpus ni ne fournissent de résultats Opus 5.5.

La grille tarifaire de l’API Claude, revérifiée le 10 novembre 2026, liste Opus 5.5 à 4 $ par million de tokens d’entrée hors cache, 20 $ en sortie, 0,20 $ en lecture de cache, 5 $ pour la création de cache de cinq minutes et 8 $ pour celle d’une heure. Appliquez les tarifs du circuit de déploiement réel et des classes de tokens. La consommation de quota d’abonnement reste distincte d’une estimation équivalente API ; la partie 5 du Vrai coût de l’IA donne l’instantané actuel entre fournisseurs.

La décision de déploiement vient de ces résultats conservés. Le rôle d’Opus 5.5 dans la flotte, son effort et ses actions autorisées suivent ce que montre le corpus qualifié, et la partie 1 reste valable : un meilleur reviewer n’est utile que si le travail est en attente à l’étape où il intervient.

Séparer préparation et résultats des modèles

État de préparation, 14 octobre 2026.

Un pilote de code séparé est préparé pour Codex : 3 tâches figées, chacune attribuée une fois à 4 configurations, soit 12 tentatives prévues. Les identifiants de modèles viennent du catalogue du client installé :

La préparation a réussi 31 tests locaux et 6 contrôles d’isolation du système d’exploitation. Quatre sessions ont testé le client Codex installé avec un serveur local renvoyant des réponses fixes. Elles ont vérifié les champs de requête et compteurs synthétiques de tokens ; interrompre une réponse maintenue ouverte déconnectait son flux TCP local, et une continuation ultérieure était refusée. Douze évaluations confinées utilisaient des soumissions de contrôle écrites par l’opérateur, dont des contrôles rejetant 3 implémentations délibérément défectueuses. Ce sont des contrôles de préparation, sans sortie générée par un modèle.

Aucun modèle de benchmark n’a été appelé et aucun budget d’exécution n’est approuvé. Accès réel aux modèles, effort appliqué par le fournisseur, consommation d’abonnement, facturation, usage final après interruption, plafond strict de consommation pendant une réponse et plafond mémoire restent non vérifiés. Le protocole app-server de Codex décrit l’interface client ; réussir une simulation locale ne qualifie pas un fournisseur réel.

Ce pilote de code ne teste pas le rappel des reviewers, ne reproduit pas l’expérience de construction de services de Jain et n’évalue pas l’adaptateur Opus 5.5 ci-dessus. Une tentative par tâche et configuration serait un pilote, pas assez de preuves pour classer les modèles. Approbation du budget et admission technique précèdent toujours toute exécution réelle.

---

YSNK

(Ce que vous devriez maintenant savoir)

• Opus 5.5 est la référence à tester dans ce workflow de review, avec Fable 5.2 comme condition d’escalade
• Les benchmarks de lancement sont des évaluations de tâches de code réalisées par le fournisseur, pas des mesures du rappel en code review
• Comparez les niveaux d’effort avant de payer une flotte plus grande
• L’adaptateur API doit mapper explicitement blocs de thinking, refus, appels d’outils forcés et replis
• Une décision actuelle nécessite des exécutions actuelles sur un corpus qualifié