Tutoriel API Claude Opus 5.5 : créer un enquêteur d’incident IA

Suivez ce tutoriel sur l’API Claude Opus 5.5 pour créer en Python un enquêteur d’incident avec vision, appels d’outils programmatiques, relecture contrefactuelle, budgets de tâche, sorties structurées et suivi des coûts.

Actualisé 28 sept. 2026 · 12 min lire

Explorer avec l’IA

ChatGPT Claude Perplexity

Dans ce tutoriel, je vais tester un scénario : quelques minutes après une mise à jour logicielle, HarborCart — une boutique fictive utilisée pour l’exemple — commence à enregistrer des échecs au paiement. Certains clients attendent plus de 30 secondes ; d’autres voient une erreur serveur et ne peuvent pas payer. Le prestataire de paiement subit également une courte panne, ce qui semble être la cause évidente.

Mais cette panne n’explique pas pourquoi les pages du panier et de commande échouent aussi. Pour trouver le chaînon manquant, il faut consulter les journaux applicatifs, les graphiques, les traces de requêtes et la dernière modification de code. Ce tutoriel vérifie si Claude Opus 5.5 peut suivre ces indices, éprouver son explication dans des conditions contrôlées et ne rapporter que ce que les preuves étayent.

Contexte : Claude Opus 5.5 est sorti plus tôt cette semaine, juste avant le démarrage de ce projet. Notre aperçu de Claude Opus 5.5 couvre le lancement et les benchmarks ; ce tutoriel se concentre donc sur l’API et construit un agent d’investigation, de la première requête jusqu’au rapport vérifié.

Nous verrons comment :

Effectuer votre premier appel à Claude Opus 5.5 et lire ses blocs de contenu par type
Donner à l’agent des outils en lecture seule avec des schémas stricts
Laisser le code de Claude filtrer journaux et traces grâce aux appels d’outils programmatiques
Considérer les captures d’écran comme des hypothèses et les confronter aux métriques
Tester une cause racine avec une relecture contrefactuelle (counterfactual replay)
Comparer les niveaux d’effort face aux mêmes éléments de preuve
Rendre un rapport structuré autorisé à conclure "inconclusif"
Calculer le coût de l’investigation à partir des relevés d’usage de l’API

TL;DR

L’enquêteur d’HarborCart a distingué l’explosion d’erreurs du prestataire de paiement de la politique de retry qui l’a amplifiée, puis a testé cette explication avant de rendre un rapport.

La défaillance du prestataire est le déclencheur, pas la cause racine complète. Les tentatives de débit réessayées retiennent des connexions à la base assez longtemps pour faire tomber des endpoints qui n’appellent jamais la passerelle de paiement.
Investigation et reporting utilisent des requêtes séparées. La recherche web et les citations sont disponibles pendant l’enquête ; une seconde requête met en forme les preuves vérifiées en JSON.
Les appels d’outils programmatiques ont réduit de 98,8 % les preuves sérialisées. Sur trois investigations, 142,8 KB de résultats d’outils sont devenus 1,7 KB de synthèses renvoyées au modèle.
Un effort plus élevé n’a pas changé le plan de relecture central. Les niveaux moyen et élevé ont retenu la même hypothèse et les mêmes tests causaux principaux.
Les trois investigations complètes mesurées ont coûté en moyenne 0,2737 $ et environ deux minutes.

Qu’est-ce que l’API Claude Opus 5.5 ?

Vous accédez à Claude Opus 5.5 via l’API Messages d’Anthropic avec l’identifiant de modèle claude-opus-5-5. D’après la présentation du modèle, il accepte texte et images, avec une fenêtre de contexte d’1 million de tokens et une sortie maximale de 128K. Le raisonnement adaptatif est toujours activé, et l’effort par défaut est medium.

La tarification standard est de 4 $ par million de tokens en entrée et 20 $ par million de tokens en sortie. Les écritures dans le cache 5 minutes coûtent 5 $ par million et les lectures de cache 0,20 $. Une fois le cache de prompt actif, les préfixes correspondants sont facturés au tarif de lecture du cache.

Qu’est-ce qui a changé par rapport à Claude Opus 5 ?

Quatre points du guide de migration se manifestent directement dans ce projet.

L’usage forcé de tool_choice avec any ou un outil nommé renvoie une erreur 400.
L’effort par défaut est passé de high sur Claude Opus 5 à medium.
Le raisonnement ne peut pas être désactivé, et les blocs thinking doivent être renvoyés inchangés dans une boucle d’outils.
Les notes que le modèle écrit entre des appels d’outils arrivent dans des blocs thinking, vides par défaut.

Que va-t-on construire avec Claude Opus 5.5 ?

L’agent ne fait qu’enquêter. Il dispose d’outils de collecte de preuves en lecture seule et d’aucun identifiant de production. Après la collecte, des requêtes de planification séparées proposent des tests contrefactuels, et Python valide puis exécute le plan à effort moyen.

Le code complet, générateur de preuves et application web inclus, se trouve dans ce dépôt GitHub.

Que s’est-il passé lors du paiement HarborCart ?

HarborCart est une boutique fictive. Son checkout-api sert les pages de panier, le statut de commande et POST /checkout, qui déclenche un débit via une passerelle de paiement tierce. Tous ces endpoints partagent un pool PostgreSQL de 15 connexions par instance.

Un déploiement a lieu, et cinq minutes plus tard, la passerelle renvoie des 503 pendant environ 90 secondes. La latence de checkout dépasse 30 secondes tandis que le pool est saturé à 15/15. Accuser le prestataire de paiement est tentant, et la passerelle a bel et bien échoué.

La cause cachée se situe un cran plus loin. Le déploiement a permis de réessayer les débits POST jusqu’à trois fois (soit quatre tentatives au total), sans pause, tandis que le gestionnaire conserve la connexion à la base. Des échecs lents retiennent désormais des connexions pendant 30 secondes ou plus, jusqu’à épuiser le pool, et les pages de panier qui n’appellent jamais la passerelle échouent aussi.

J’emploie trois termes de façon cohérente. Ici, le déclencheur est la panne temporaire de la passerelle. Le réessai des POST de paiement tout en retenant des connexions rares constitue le mécanisme d’amplification ; l’épuisement du pool partagé est la défaillance du système.

Quelles preuves l’agent peut-il examiner ?

L’agent démarre avec l’alerte, une capture de monitoring et un schéma d’architecture. Tout le reste passe par des outils : journaux, traces, cinq métriques, métadonnées de déploiement, diff Git et runbook. Trois explications concurrentes sont semées dans les preuves : un avertissement d’inventaire, un avertissement frontend et une possible saturation CPU.

Chemin de checkout HarborCart et pool partagé. Image de l’auteur.

Le schéma indique que la connexion est conservée pendant toute la requête. Il ne dit pas que c’est un problème ; l’enquête doit l’établir.

Comment saurons-nous que le diagnostic est correct ?

Définissez le succès avant de construire l’agent. Un rapport correct doit :

Nommer la modification de retry ayant autorisé des POST réessayés
Indiquer que la connexion à la base reste tenue pendant l’appel à la passerelle
Expliquer comment des rétentions plus longues épuisent le pool
Considérer l’explosion d’erreurs de la passerelle comme le déclencheur, pas le mécanisme d’amplification
Rejeter au moins deux des trois explications alternatives
Citer des preuves concrètes, dont le diff et une métrique
Inclure une relecture contrefactuelle dont le résultat confirme le verdict

Comment utiliser l’API Claude Opus 5.5 en Python

Vous avez besoin de Python 3.10 ou plus et d’une clé API Anthropic avec accès à claude-opus-5-5. Ces commandes PowerShell clonent le projet et installent ses dépendances épinglées, dont anthropic 1.8.0. Si vous êtes sur Amazon Bedrock, lisez d’abord la FAQ, car plusieurs fonctionnalités ne sont pas portables.

git clone https://github.com/KhalidAbdelaty/opus-5-5-api-tutorial.git
cd opus-5-5-api-tutorial
python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt
Copy-Item .env.example .env

Sur macOS ou Linux, activez avec source .venv/bin/activate et copiez avec cp .env.example .env. Ajoutez votre clé dans .env, et python-dotenv la charge pour le SDK ; notre guide sur les variables d’environnement détaille le procédé. Si vous avez déjà appelé Claude depuis Python, passez la sous-section suivante, elle ne fait que valider l’installation.

Effectuer votre premier appel à l’API Claude Opus 5.5

La requête minimale utile confirme la clé et montre ce qui est renvoyé.

import anthropic
from dotenv import load_dotenv

load_dotenv()
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=2048,
    messages=[{"role": "user", "content": "A checkout API returns HTTP 503 right after a deploy. Name the first two things to check."}],
)
print([block.type for block in response.content])
text = "".join(block.text for block in response.content if block.type == "text")

Dans cette requête, la réponse contient des blocs thinking et text. Sélectionnez les blocs par type au lieu de lire response.content[0].

Construire un agent Claude Opus 5.5 avec appels d’outils

Les agents à appels d’outils associent l’API Messages de Claude à des fonctions Python qui contrôlent l’accès aux données. Une règle gouverne l’application : Claude décide des preuves nécessaires, Python décide de ce qui est accessible.

Notre guide d’ingénierie des harnais d’agent couvre les limites d’outils et les boucles plus larges ; HarborCart maintient ses outils en lecture seule et limités à cet incident.

Définir des outils d’incident en lecture seule

Chaque outil lit un jeu fixe de preuves et renvoie un JSON restreint. Les requêtes de logs et de traces retournent au plus 200 lignes plus un total, et les requêtes de métriques au plus 60 points.

Les appels d’outils programmatiques ne prennent pas en charge strict: true, donc séparez les outils en deux. Conservez stricts et en appel direct uniquement les contrôles de preuve et l’outil d’arrêt d’enquête. Les logs, traces et métriques utilisent uniquement l’exécution de code, offrant à Claude une voie claire pour les requêtes de grande volumétrie.

{"name": "finish_investigation", "strict": True,
 "allowed_callers": ["direct"],
 "input_schema": {"type": "object",
                  "properties": {"summary": {"type": "string"}},
                  "required": ["summary"],
                  "additionalProperties": False}},
{"name": "query_traces",
 "allowed_callers": ["code_execution_20260120"],
 "input_schema": {...}},

allowed_callers guide le modèle mais n’est pas une barrière de sécurité. Python vérifie l’appelant avant chaque exécution d’outil et rejette un appel direct aux requêtes. Les appels programmatiques contournent aussi la validation stricte, les fonctions de requête valident donc toujours leurs propres arguments.

L’application marque chaque résultat d’outil accepté, rejette les conclusions citant des preuves manquantes, et n’accepte des URL de documentation que lorsqu’elles proviennent d’une recherche web. C’est Python, pas le modèle, qui enregistre les sorties de relecture.

Préférer des schémas stricts plutôt qu’un choix d’outil forcé

Comme noté dans la section migration, laissez tool_choice à auto. Indiquez dans le prompt quand un outil s’applique et utilisez des schémas stricts lorsque les arguments doivent être exacts.

Construire la boucle d’enquête multi-tours

La boucle envoie la conversation, exécute les blocs tool_use, ajoute les résultats et répète. Ajoutez les blocs de l’assistant inchangés, y compris le thinking, et pendant la pause du code programmatique, renvoyez l’identifiant container uniquement avec des blocs tool_result.

La requête d’enquête inclut la vision, les outils, la recherche web, l’effort et le budget de tâche, mais aucun schéma de sortie. Cela évite de mélanger des résultats cités provenant de la recherche avec une sortie JSON structurée, tout en conservant un préfixe de requête stable pour profiter du cache de prompt :

request = dict(
    model="claude-opus-5-5",
    max_tokens=16_000,
    system=[{"type": "text", "text": SYSTEM_PROMPT, "cache_control": {"type": "ephemeral"}}],
    tools=investigation_tools,
    cache_control={"type": "ephemeral"},
    thinking={"type": "adaptive", "display": "updates"},
    output_config={
        "effort": "medium",
        "task_budget": {"type": "tokens", "total": 20_000},
    },
    betas=["task-budgets-2026-03-13", "thinking-display-updates-2026-08-18"],
)

Comment envoyer des images à l’API Claude Opus 5.5

Joignez le tableau de bord et le schéma d’architecture au premier message utilisateur sous forme de PNG encodés en base64. Indiquez à Claude de traiter toute information lue d’une image comme une hypothèse et de la confirmer via query_metrics.

Le tableau de bord montre la saturation du pool, CPU stable. Image de l’auteur.

Le tableau de bord et les requêtes de métriques utilisent la même source de données. Le CPU reste proche de 30 % alors que le pool est plein, ce qui va à l’encontre de l’explication "l’hôte est surchargé" avant même de lancer une requête.

Recouper les observations visuelles avec les métriques brutes

La capture d’écran suggère où regarder, mais la série numérique tranche si l’observation tient. La vision génère une hypothèse ; les métriques la testent.

Pour des workflows image-first, consultez notre tutoriel sur la vision agentique. HarborCart n’utilise la vision que pour choisir la prochaine métrique.

Comment fonctionnent les appels d’outils programmatiques de Claude Opus 5.5 ?

Les appels d’outils programmatiques permettent à Claude d’écrire du Python exécuté dans un conteneur et d’appeler vos outils comme des fonctions. Les résultats bruts restent dans le bac à sable, et seul le texte imprimé par le code est renvoyé au modèle.

Élargir la collecte sur journaux et traces

L’agent écrit de courts scripts qui extraient les traces en échec et n’impriment que les comptes par endpoint. Lors d’une enquête complète, les appels programmatiques ont réduit de 98,8 % les preuves sérialisées renvoyées au modèle. Les résultats d’outils pesaient 42,9 KB et les synthèses 0,5 KB : une mesure en octets, plus qu’une économie de tokens facturés en entrée.

Les appels d’outil resserrent les preuves de l’incident. Image de l’auteur.

Ajouter une recherche documentaire en cas d’incertitude sur une dépendance

L’application expose une recherche web restreinte pour les sémantiques de bibliothèques de retry. Claude ne l’a pas utilisée lors de l’évaluation finale, le diagnostic mesuré repose donc sur le diff, les métriques, les logs et les traces. La référence urllib3 confirme indépendamment que allowed_methods=None réessaie n’importe quel verbe et que backoff_factor=0 supprime l’attente, mais cette page ne fait pas partie des preuves mesurées.

Vérifier une cause racine par relecture contrefactuelle

Une relecture contrefactuelle rejoue le trafic de l’incident en retirant une cause suspectée et vérifie si la panne disparaît. Elle transforme "ces courbes montent ensemble" en test.

Garder la relecture honnête

La relecture réutilise le même profil de trafic. Pour la comparaison ci-dessous, chaque scénario ne change qu’une condition, et l’application contrôle les changements autorisés.

Le récapitulatif sépare les 503 de la passerelle des timeouts du pool, et les 503 de checkout des lectures panier/commande. Cette séparation permet au modèle de distinguer déclencheur et amplificateur.

Chaque relecture change exactement un paramètre. Image de l’auteur.

La relecture de référence a produit 124 réponses 503 : 105 timeouts du pool, dont 68 échecs sur des endpoints de lecture, et 19 erreurs de passerelle. Revenir sur la politique de retry a supprimé tous les timeouts du pool et les échecs de lecture mais a fait apparaître 93 503 de passerelle sur checkout. Libérer la connexion avant l’appel à la passerelle a également éliminé les échecs de pool tout en laissant 33 503 de passerelle, et supprimer l’explosion de la passerelle n’a produit aucune erreur.

La relecture met en lumière le compromis : un rollback protège le pool partagé mais laisse passer plus d’échecs de checkout. Utilisez-le en mesure d’urgence. Ajoutez ensuite une clé d’idempotence pour éviter un double débit et cessez de retenir la connexion pendant l’appel à la passerelle.

Faire de la vérification une règle dans le code

Le prompt système demande une relecture, mais un prompt n’est pas un mécanisme d’application. La boucle vérifie l’existence de preuves de relecture et rejette un diagnostic non testé.

Conservez ce contrôle dans Python. Un prompt plus strict peut améliorer la conformité, sans la garantir.

Utiliser l’effort et les budgets de tâche avec Claude Opus 5.5

L’effort détermine la quantité de raisonnement par étape et un budget de tâche fixe la quantité de travail pour l’ensemble de la boucle. Notre tutoriel Claude Opus 5 API compare les cinq niveaux d’effort ; ici, moyen et élevé reçoivent les mêmes preuves avant relecture.

Comparer medium et high sur les mêmes preuves

La production reste en medium. Avant la relecture, l’application demande aux efforts moyen et élevé de concevoir un test causal à partir des mêmes preuves. Elle n’exécute que la recommandation en moyen ; la réponse en élevé sert de comparaison.

La requête en élevé utilise un changement output_config.effort par message, via mid-conversation-output-config-2026-07-01. Elle ne voit pas la réponse en moyen.

Les deux niveaux ont choisi la même hypothèse et les trois mêmes scénarios de relecture centraux. En moyenne, élevé a utilisé 2 631 tokens de sortie contre 2 307 en moyen, soit environ 11 % de coût supplémentaire sans changer le test causal.

Fixer un budget de tâche pour toute la boucle

Choisissez un budget de tâche d’après l’usage observé plutôt qu’au doigt mouillé. L’enquête non bornée la plus volumineuse d’HarborCart a consommé 13 322 tokens comptés, incluant les sorties du modèle et le texte des résultats d’outils vus par Claude. En ajoutant 25 % de marge, on obtient 16 653, sous le minimum de 20 000 d’Anthropic, le budget configuré est donc 20 000.

Conservez des limites d’applications en nombre de tours et temps écoulé. L’exécuteur d’expériences cessait de lancer de nouveaux travaux après 2,50 $ dépensés. Ce n’est pas un plafond dur, une requête en cours pouvant terminer au-dessus.

Utiliser les sorties structurées de Claude Opus 5.5

La réponse finale utilise des sorties structurées. Son schéma plat couvre le verdict, la cause, les hypothèses rejetées, les preuves et le correctif. Coût et latence restent hors du schéma car mesurés par l’application.

Séparer l’enquête du reporting

Les citations de recherche web et output_config.format ne peuvent pas partager une même requête : les citations exigent des blocs intercalés, tandis que le schéma impose du JSON. HarborCart enquête donc sans schéma de sortie. Il stocke les constats avec leurs sources et les résultats de relecture, puis n’envoie que ces preuves vérifiées à une seconde requête, sans outils ni recherche web.

import json

report_response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=16_000,
    system=report_instructions,
    messages=[{"role": "user", "content": json.dumps(verified_evidence)}],
    output_config={
        "effort": "medium",
        "format": {"type": "json_schema", "schema": report_schema},
    },
)

La seconde requête n’a besoin que des preuves vérifiées, il est donc inutile de préserver le cache complet de l’enquête.

Autorisez "inconclusive" dans le champ verdict. Un rapport ne doit pas forcer un diagnostic vérifié si la relecture contredit l’explication.

Conforme au schéma ne veut pas dire correct

Le schéma valide la forme du rapport, tandis que la relecture valide le diagnostic. Un refus renvoie aussi HTTP 200 avec stop_reason: "refusal" et peut ne pas correspondre à votre schéma, vérifiez donc la raison d’arrêt avant le parsing.

Claude Opus 5.5 a-t-il trouvé la vraie cause racine ?

Les trois rapports finaux ont identifié le mécanisme causal central et écarté les trois explications alternatives. Deux ont satisfait aux huit vérifications ; le troisième a obtenu 6/8 car il a omis la configuration explicite de retry sur POST et n’a pas cité le diff de déploiement. D’où l’intérêt de dissocier la notation hors ligne de la validation de schéma : un JSON valide et un bon diagnostic peuvent aboutir à un rapport incomplet.

Les rapports pointent aussi un second risque : réessayer un débit peut facturer deux fois un client. RFC 9110 ne définit pas POST comme intrinsèquement idempotent et déconseille les retries automatiques sauf si le client sait que l’opération est sans risque. Une clé d’idempotence supportée par le prestataire est un moyen courant de sécuriser ces retries.

Notre tutoriel Streamlit explique la mise en place de l’interface. Celle d’HarborCart affiche les événements d’enquête, les plans de relecture moyen et élevé, les résultats de relecture, le rapport final et le coût. Pour le statut entre appels d’outils, le guide de prompting Claude Opus 5.5 décrit display: "updates" ; l’appli affiche aussi des événements d’outils quand un bloc de mise à jour est vide.

Streamlit affiche l’enquête et le rapport. Vidéo de l’auteur.

Combien a coûté l’enquête Claude Opus 5.5 ?

Une enquête complète a coûté entre 0,2582 $ et 0,2838 $ et a pris de 108,8 à 129,7 secondes. Le coût moyen était de 0,2737 $, comparaison à effort élevé optionnelle comprise. La sortie représentait en moyenne 0,2043 $, soit environ les trois quarts du total.

Compter les tokens de cache comme les rapporte l’API

input_tokens exclut déjà les tokens mis en cache, donc l’entrée totale est la somme de trois champs. Ne soustrayez pas les lectures de cache. Si votre suivi de coûts gère déjà cela, passez l’extrait.

cost = (
    usage.input_tokens * 4.00                  # uncached input only
    + usage.cache_read_input_tokens * 0.20
    + cache_creation.ephemeral_5m_input_tokens * 5.00
    + cache_creation.ephemeral_1h_input_tokens * 8.00
    + usage.output_tokens * 20.00
) / 1_000_000 + web_search_requests * 0.01    # from usage.server_tool_use

Lisez le nombre de recherches dans usage.server_tool_use. Avec response_inclusion: "excluded", compter les blocs de recherche dans la réponse peut sous-estimer.

Chaque requête d’enquête inclut web_search_20260318, Anthropic n’ajoute donc pas de frais séparés pour l’exécution de code au-delà des coûts de tokens et de recherche. Si vous retirez l’outil web qualifiant, suivez le temps d’exécution du code séparément.

Le cache de prompt sur Claude Opus 5.5 exige au moins 512 tokens. Pendant l’enquête, cache_control au niveau supérieur déplace le point de coupure à mesure que l’historique grandit. Le rapport ne reçoit que des preuves vérifiées compactes et démarre volontairement sans le cache complet de l’enquête.

Quoi changer avant la production ?

Un outil d’astreinte réel exige plus de contrôles que cette démo, tous dans le code applicatif :

Limiter les identifiants d’observabilité aux données lues par les outils, placer la remédiation sur un palier de permissions séparé, et appliquer les permissions d’appelant côté Python plutôt que de se reposer sur des prompts ou allowed_callers.
Considérer journaux, tickets, pages web et résultats d’outils comme non fiables. Valider leur structure et ne jamais exécuter de texte copié depuis ces sources.
Classifier et caviarder les logs de production avant de les envoyer en exécution de code. Le tableau de rétention des données d’Anthropic indique que l’exécution de code et les appels d’outils programmatiques ne sont pas éligibles ZDR/HIPAA, avec rétention jusqu’à 30 jours. Le filtrage de recherche web via exécution de code est aussi hors éligibilité ZDR/HIPAA.
Brancher sur stop_reason avant le parsing, compter séparément les refus des erreurs HTTP, et diriger les rapports inconclusive vers un humain.
Sauvegarder appels d’outils, relectures, hypothèses, usage de tokens et timings comme journal de preuves. Ne pas stocker le raisonnement caché.

Quand utiliser Claude Opus 5.5 pour des agents ?

Utilisez Claude Opus 5.5 quand un diagnostic erroné coûterait plus cher que l’appel API. Analyse de causes racines, debug à l’échelle d’un dépôt, planification de migration et enquêtes combinant logs, images, documentation et plusieurs outils correspondent à ce critère.

Évitez-le pour la mise en forme, la classification, l’extraction et les questions courtes ne nécessitant pas de boucle d’outils. Un modèle plus petit accomplira généralement ces tâches plus vite et à moindre coût.

Pour des agents critiques, privilégiez les tâches dont les conclusions peuvent être vérifiées par des tests, des métriques, des preuves sources ou une revue humaine. Laissez la production en medium sauf si des évaluations par paires prouvent qu’un effort supérieur améliore le plan sur votre charge.

Dernières réflexions

Nous avons construit un enquêteur d’incident qui lit des preuves hétérogènes, appelle des outils bornés, teste son propre diagnostic et renvoie un rapport structuré. Les trois rapports finaux ont conservé la distinction déclencheur / cause racine évoquée plus haut, mais Python devait tout de même exiger la relecture.

Je ne généraliserais pas ce résultat à tout incident ou codebase. Ce qui se transpose, c’est la méthode : limiter l’accès aux données, filtrer les gros résultats d’outils avant qu’ils n’atteignent le modèle, autoriser un verdict "inconclusive" et vérifier l’explication hors du modèle. La relecture est la partie que je garderais même dans une version allégée.

En modifiant les outils de preuve et l’étape de vérification, le même schéma peut servir un investigateur d’échec CI, un relecteur de pull request ou un contrôleur de migration. Ma première extension serait un routeur qui envoie les incidents simples à un modèle moins cher et réserve Claude Opus 5.5 aux cas nécessitant plusieurs sources de preuves. Pour une vue d’ensemble du modèle, consultez la présentation Claude Opus 5.5 liée en introduction.