Audit de code avec Claude Opus 5.5 : vérifiez chaque constat avant la fusion

Vous laissez Claude Opus 5.5 examiner un dépôt pendant plusieurs heures et récupérez des dizaines de constats « critiques », parfois accompagnés d’un énorme correctif. Le vrai travail commence alors : déterminer quels défauts existent réellement, quelles propositions respectent l’architecture et quels changements peuvent être fusionnés sans danger.

Cette méthode traite les réponses du modèle comme des hypothèses d’audit à prouver, pas comme des conclusions. Vous figez d’abord un état de référence reproductible, puis chaque constat doit franchir les portes de reproduction, de risque, d’architecture, de correction et de régression.

Utilisez Opus 5.5 pour élargir l’audit, pas pour approuver la fusion

Le modèle convient aux audits vastes et longs, mais ce n’est pas un réviseur indépendant. Dans son annonce du 22 septembre 2026, Anthropic cite les migrations et audits à l’échelle d’un dépôt parmi ses points forts et publie des résultats internes et de testeurs précoces. Ces données du fournisseur ne garantissent rien pour votre code. Lire l’annonce d’Opus 5.5.

Kent C. Dodds a aussi publié une consigne couvrant sécurité, performances, accessibilité, maintenabilité, évolutivité, architecture, documentation, tests et automatisation. Il affirme qu’Opus 5.5 a trouvé un problème de sécurité important manqué par d’autres modèles, sans publier la faille, sa reproduction ni une comparaison contrôlée. Ce retour justifie un essai, pas l’abandon des contrôles. Lire la publication.

L’objectif doit donc être d’obtenir des constats reproductibles, classés et vérifiables indépendamment, et non le plus grand nombre d’alertes.

Définissez la réussite par des commandes avant l’audit

Sans état de référence propre, impossible de savoir si un échec existait déjà ou a été introduit pendant le travail du modèle. Enregistrez le SHA, l’environnement, les versions importantes, chaque commande exacte et son code de sortie.

Remplacez les marqueurs par les commandes du projet. Si un contrôle ne s’applique pas, notez-le au lieu d’en inventer un.

git status --short
<install-command>
<lint-command>
<type-check-command>
<unit-test-command>
<integration-test-command>
<build-command>

Conservez au minimum :

• SHA du commit, runtime, gestionnaire de paquets et versions sensibles ;
• commande, répertoire, code de sortie et résumé de l’erreur ;
• échecs connus, tests instables et dérogations temporaires ;
• répertoires inclus et fichiers interdits, tels que code généré, anciennes migrations, lockfiles ou code tiers ;
• parcours critiques : authentification, autorisation, facturation, migrations de données et contrats d’API.

Si l’état initial est déjà rouge, corrigez, isolez ou consignez le problème. Un ancien échec ne doit pas devenir une « nouvelle découverte ».

Demandez d’abord un audit sans modification

L’enquête et la correction doivent être séparées. Si le modèle modifie le code pendant qu’il cherche, un nouvel échec peut venir du code initial, du premier patch ou d’une interaction entre plusieurs patchs.

Commencez par cette consigne, adaptée à votre dépôt :

Effectue un audit long de ce dépôt. Pendant cette phase, enquête et rends compte uniquement ; ne modifie aucun fichier.

Périmètre : <répertoires, services, langages et flux critiques>
Exclusions : <fichiers générés, code tiers, migrations historiques et systèmes inaccessibles>
Référence : <commandes exécutées, codes de sortie et échecs connus>

Examine :
1. sécurité et limites d’autorisation ;
2. exactitude, concurrence, transactions et gestion des erreurs ;
3. performances et ressources ;
4. accessibilité si pertinente ;
5. maintenabilité et évolutivité ;
6. architecture et frontières des modules ;
7. lacunes de documentation, de tests et d’automatisation.

Pour chaque constat, fournis :
- un ID unique et un titre court ;
- la gravité et la justification de l’impact ;
- les fichiers, symboles et lignes exactes ;
- le déclencheur, le comportement attendu et observé ;
- une commande reproductible ou un test minimal ;
- un résumé de sortie et le code de fin ;
- une explication possible de faux positif ;
- la plus petite piste de correction ;
- les vérifications obligatoires après correction ;
- un niveau de confiance élevé, moyen ou faible.

Règles :
- Marque NON EXÉCUTÉE toute commande non lancée.
- Si tu ne reproduis pas un constat, marque-le NON VÉRIFIÉ.
- Ne supprime, n’ignore ou n’affaiblis jamais un test pour obtenir du vert.
- Arrête-toi et liste les identifiants, services ou dépendances manquants.
- Mets à jour le tableau d’état à la fin de chaque phase et attends la revue.

La consigne ne garantit pas le respect des règles. Contrôlez l’historique du terminal, les diffs et les sorties réelles. Elle sert à empêcher une remarque vague de passer directement en correction.

Découpez le travail long en quatre phases contrôlées

Une exécution longue ne doit pas avoir des droits et un périmètre illimités. Interrompez-vous à chaque frontière de phase.

Phase 1 : cartographier le système

Le modèle lit le code, la configuration, les tests et les documents. Il livre les points d’entrée, limites de confiance, flux de données, dépendances et chemins à fort impact. Aucun quota de bogues et aucune modification.

Phase 2 : produire des candidats

Chaque candidat doit viser un emplacement et une condition précis. Un conseil général sans déclencheur va dans une liste d’améliorations, pas dans le compte des défauts.

Phase 3 : reproduire un constat à la fois

Commencez par les risques élevés faciles à tester. Une expérience vérifie une hypothèse. Gardez la sortie brute et les paramètres d’environnement.

Phase 4 : préparer le plan de correction

Seuls les défauts reproduits y entrent. Pour chacun : changement minimal, compatibilité, risque de migration, retour arrière et contrôles obligatoires. Les désaccords d’architecture passent d’abord par le propriétaire du code.

Suivez l’état dans audit-plan.md ou dans des tickets :

ID	État	Risque	Preuve	Décision d’architecture	Branche	Approbateur
AUD-001	À reproduire	Élevé	Aucune pour l’instant	Non revue	—	—

Le chemin doit être explicite : candidat → à reproduire → reproduit → architecture revue → corrigé → accepté. Le ton assuré du modèle ne change pas l’état.

Porte de risque : séparez gravité et confiance

La gravité mesure le dommage possible ; la confiance mesure la qualité des preuves. Un possible contournement d’autorisation peut être grave mais peu confirmé. Une faute mineure de journal peut être parfaitement reproduite et rester peu grave.

Gravité	Quand l’utiliser	Preuve minimale avant correction
Critique	Élévation large de privilèges, fuite sensible, corruption irréversible ou panne centrale	Reproduction contrôlée, périmètre d’impact et revue immédiate du responsable
Élevée	Flux essentiel touché ou entrée réaliste déclenchant régulièrement l’échec	Reproduction minimale, test en échec ou sortie de commande, confirmation du responsable
Moyenne	Impact limité, contournement disponible ou conditions inhabituelles	Preuve répétable et décision de priorité
Faible	Qualité locale, documentation, maintenabilité ou performance non critique	Code précis et bénéfice supérieur au risque de régression

Le modèle peut suivre le code, mais il ne connaît pas seul la sensibilité des données, les engagements clients ou la tolérance à l’arrêt. Ces éléments relèvent d’un responsable humain.

Porte de reproduction : transformez le constat en contrôle en échec

Un code suspect ne suffit pas. Il faut un contrôle qui échoue avant le correctif et réussit après. Pour chaque constat, répondez :

1. Dans quel commit et environnement apparaît-il ?
2. Quelle entrée minimale le déclenche ?
3. Quelle source définit l’attendu : test, spécification, contrat ou règle métier ?
4. Quel est le résultat réel et où se trouve la sortie brute ?
5. Pourquoi les tests existants ne l’ont-ils pas vu ?
6. Une décision de conception valide ou une différence d’environnement peut-elle l’expliquer ?

La meilleure preuve est un test de régression minimal. Si l’automatisation est impossible, documentez des étapes manuelles déterministes, les observations et le nettoyage. Reproduisez une question de sécurité uniquement sur un système possédé ou autorisé, idéalement local, isolé ou de préproduction.

Quand le modèle dit avoir lancé une commande, exigez la commande complète, le répertoire, le code de sortie et la sortie pertinente. Un résumé ne prouve pas l’exécution.

Porte d’architecture : comprenez pourquoi l’ancien code existe

Une solution plus élégante peut casser la compatibilité, l’ordre de déploiement ou une frontière voulue. Avant une grande refonte, consultez ADR, documents de conception, contrats, contraintes de migration et historique.

Si l’historique Git est exploitable :

git log -- <path>
git blame -L <start>,<end> <file>
git show <commit> -- <path>

Exigez des réponses :

• Quelle contrainte la conception actuelle protège-t-elle ?
• Quels appelants, formats ou déploiements en dépendent ?
• La proposition corrige-t-elle un défaut ou change-t-elle le produit ?
• Un changement local plus petit suffit-il ?
• Le retour arrière exige-t-il de restaurer code, configuration ou données ?

L’historique apporte des indices, pas l’intention parfaite. Sans justification, marquez « intention architecturale inconnue » et demandez à un mainteneur.

Porte de correction : un défaut reproduit, un petit patch

Refusez le megapatch qui mélange de nombreux sujets. Ajoutez d’abord un test qui échoue sur l’ancienne version, puis appliquez le changement minimal.

Porte	Exigence	En cas d’échec
Périmètre	Le diff ne couvre que le constat approuvé	Séparer les changements étrangers
Régression	Échec avant, réussite après	Corriger le test ou revoir le constat
Statique	Format, lint et types passent	Ne pas masquer par une exclusion globale
Projet	Tests unitaires, intégration et build pertinents passent	Étudier le premier nouvel échec avant d’empiler
Architecture	Le responsable confirme limites et compatibilité	Réduire le périmètre ou ouvrir une revue de conception
Revue humaine	Erreurs, droits, données et suppressions sont contrôlés	Expliquer chaque différence suspecte

Refusez les faux succès : suppression d’assertions, tests ignorés, exceptions avalées, validation affaiblie, retries augmentés pour masquer une course ou refonte qui rend le défaut introuvable.

Porte de régression : lancez les contrôles définis par le projet

L’acceptation finale utilise les scripts existants ou la CI, pas seulement les tests choisis par le modèle. Comparez l’ensemble initial et final et vérifiez que le nouveau test échoue sur la version sans patch.

Inspectez aussi lockfiles, migrations, API publiques et valeurs par défaut. Une amélioration de performance exige le même environnement et la même entrée. Pour un test instable, ne relancez pas jusqu’au vert : mesurez le motif, isolez la cause et vérifiez que le patch ne l’aggrave pas.

Rejetez le résultat dès qu’un de ces signaux apparaît

• Pas d’emplacement exact, de déclencheur ou de preuve inspectable.
• Une commande non exécutée est annoncée comme réussie.
• La gravité n’a aucun chemin d’impact.
• Le patch dépasse le périmètre ou redessine l’architecture sans accord.
• Des tests sont supprimés, ignorés ou affaiblis, ou des erreurs sont cachées.
• Le changement contredit un ADR, un contrat ou une migration sans approbation.
• Seul un résumé final existe, sans commandes ni diff révisable.
• Une affirmation de sécurité repose uniquement sur l’accord d’un autre modèle.

Un second modèle peut chercher des contre-exemples, mais un consensus de modèles n’est pas une preuve indépendante. La validation vient des tests, de l’exécution, de l’historique, des spécifications et des responsables humains.

Checklist finale avant la fusion

• Périmètre, exclusions et commit de référence sont figés.
• Commandes de référence et codes de sortie sont conservés.
• Chaque constat accepté a un ID et un emplacement exact.
• Gravité et confiance sont enregistrées séparément.
• Le défaut est reproduit par un test ou une procédure déterministe.
• Intention architecturale, compatibilité et retour arrière sont revus.
• Chaque constat correspond à un petit patch révisable.
• Le test de régression échoue avant et réussit après.
• Tous les contrôles passent par les scripts existants ou la CI.
• Un responsable relit le diff final et l’approuve explicitement.

Les retours publics font d’Opus 5.5 un candidat crédible pour de vastes audits et suggèrent qu’il peut faire ressortir des problèmes manqués ailleurs. Ils ne suppriment pas la vérification. La prochaine étape minimale est de sauvegarder une référence propre et de lancer une phase « audit uniquement, aucune modification ».