TDD, revue de code automatisée, refactoring structuré, audit de sécurité — comment orchestrer un workflow de développement où chaque ligne de code passe plusieurs gates de qualité avant d’atteindre la production.
Claude Code × Qualité · Temps de lecture : 20 min · Niveau : Intermédiaire–Avancé
6 gates, zéro raccourci, zéro régression…
Je m’appelle Philippe, fondateur d’AutomatisIA.fr. Après avoir partagé ma configuration multi-agents pour développer avec 3 IA en parallèle, la question qui revenait le plus souvent était : « Comment tu garantis la qualité du code produit par les agents ? »
La réponse courte : je ne fais pas confiance. Je vérifie. À chaque étape.
La réponse longue, c’est cet article. J’y détaille le pipeline qualité complet que j’ai mis en place avec Claude Code CLI — un système de 6 gates successives qui transforment chaque idée en code vérifié, testé, reviewé, sécurisé et documenté avant qu’il n’atteigne la production. Le tout orchestré par des skills, des plugins et un framework de spécification open-source.
Ce n’est pas de la théorie. C’est le workflow que j’utilise au quotidien sur mes projets, et les résultats parlent d’eux-mêmes : zéro bug en production sur les dernières features livrées.
Sommaire
- Introduction : pourquoi la qualité ne peut pas être une étape à la fin
- Outillage : tout ce qu’il faut installer
- Vue d’ensemble : le pipeline qualité
- Phase 1 : Spécification structurée (superpowers + spec-kit)
- Phase 2 : Implémentation TDD (Test-Driven Development)
- Phase 3 : Revue de code (double review automatisée)
- Phase 4 : Refactoring structuré (safety-first)
- Phase 5 : Audit de sécurité
- Phase 6 : Vérification avant complétion
- Bonus : le debugging systématique
- Comment tout s’assemble : un exemple concret
- Conclusion : la qualité comme système, pas comme intention
Introduction : pourquoi la qualité ne peut pas être une étape à la fin
Dans un workflow classique, la qualité est souvent un contrôle de sortie : on code, on teste, on review, on déploie. Le problème ? Plus un défaut est détecté tard, plus il coûte cher à corriger. Un bug attrapé par un test unitaire coûte quelques minutes. Le même bug découvert en production coûte des heures — voire de la confiance client.
L’approche que je vais décrire ici inverse la logique : la qualité est intégrée à chaque étape, pas ajoutée à la fin. C’est possible grâce à un écosystème de skills (des instructions structurées que Claude Code suit systématiquement) qui forment ensemble un pipeline complet.
Voici le flow, de l’idée au déploiement.
Outillage : tout ce qu’il faut installer
Avant de plonger dans le pipeline, voici la liste complète des outils utilisés dans cet article et comment les installer. Tout est compatible avec Claude Code CLI.
Plugins (installés via le marketplace Claude Code)
Les plugins ajoutent des hooks, des agents, des skills et des serveurs MCP à Claude Code. Installation en une commande chacun :
# Orchestration et discipline de développement (TDD, debugging, worktrees, reviews...)
/plugin install superpowers
# Revue de code automatisée de PR avec scoring de confiance
/plugin install code-review
# Détection de vulnérabilités en temps réel (bloque les patterns dangereux à l'écriture)
/plugin install security-guidance
# (Optionnel) Création et itération de skills personnalisés
/plugin install skill-creator
Après installation, relancer : /reload-plugins
Ce que chaque plugin apporte :
| Plugin | Type | Ce qu’il fait |
|---|---|---|
| superpowers | 14 skills + agents | TDD, debugging systématique, vérification, worktrees, code review, finishing branch, subagent-driven development |
| code-review | 1 commande | /code-review lance 5 agents en parallèle sur une PR avec scoring 0-100 |
| security-guidance | 1 hook PreToolUse | Scanne chaque écriture de fichier pour 9 patterns de vulnérabilité (XSS, injection, désérialization…) |
| skill-creator | 1 skill + scripts | Créer, tester et itérer sur des skills personnalisés |
Spec-kit : le framework de spécification (github/spec-kit)
Spec-kit est un toolkit open-source de Spec-Driven Development créé par GitHub. C’est lui qui fournit la méthodologie et les templates pour les phases specify, clarify, plan, tasks, analyze et implement.
Repo : https://github.com/github/spec-kit
Installation avec le CLI specify :
# Installer le CLI specify via uv (gestionnaire de packages Python)
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
# Initialiser un projet avec les skills Claude Code
specify init mon-projet --ai claude --ai-skills
La commande specify init --ai claude --ai-skills crée un dossier .specify/ dans votre projet avec les templates de commandes que Claude Code détecte automatiquement comme des slash commands (/speckit.specify, /speckit.clarify, etc.).
Alternative : installation manuelle comme skills globaux
Si vous préférez avoir les skills disponibles dans tous vos projets (pas seulement dans un projet initialisé avec specify init), vous pouvez les installer comme skills globaux dans ~/.claude/skills/. Les templates se trouvent dans le repo spec-kit sous templates/commands/ :
~/.claude/skills/
├── speckit-specify/SKILL.md # Créer des specs structurées
├── speckit-clarify/SKILL.md # Résoudre les ambiguïtés
├── speckit-plan/SKILL.md # Design technique
├── speckit-tasks/SKILL.md # Découpage en tâches
├── speckit-analyze/SKILL.md # Cohérence cross-artifacts
├── speckit-implement/SKILL.md # Exécution TDD
├── speckit-constitution/SKILL.md # Principes directeurs du projet
├── speckit-checklist/SKILL.md # Checklists qualité pour les specs
└── speckit-taskstoissues/SKILL.md # Conversion tasks vers GitHub Issues
Chaque fichier SKILL.md contient un frontmatter YAML (name, description) suivi des instructions en markdown. Ils sont dérivés des templates du repo github/spec-kit.
Installation du skill de refactoring :
~/.claude/skills/
└── refactoring-skill/
├── SKILL.md # Protocole de refactoring safety-first
└── references/
└── special-modes.md # Modes legacy, architecture, migration, ultra-conservative
Le skill d’intégration superpowers-speckit
C’est le skill qui fait le lien entre superpowers et spec-kit. Il remplace les phases brainstorming et writing-plans par le workflow spec-kit.
~/.claude/skills/
└── superpowers-speckit/SKILL.md
Contenu du frontmatter :
---
name: superpowers-speckit
description: "Replaces superpowers brainstorming and planning phases with
the spec-kit workflow (specify, clarify, plan, tasks, analyze, implement).
Use this skill INSTEAD OF brainstorming and writing-plans whenever
developing a feature, building a project, or implementing any multi-step change."
---
Le fichier CLAUDE.md global
Le fichier ~/.claude/CLAUDE.md s’applique à toutes les sessions Claude Code. Il définit les priorités entre skills :
# Global Instructions
## Skill Priority
- Pour tout nouveau développement (feature, projet, composant) :
utiliser le skill superpowers-speckit au lieu de
superpowers:brainstorming et superpowers:writing-plans.
- Les autres skills superpowers restent actifs normalement
(TDD, debugging, worktrees, code review, finishing-branch, verification).
Sans ce fichier, superpowers:brainstorming (qui dit « MUST use before any creative work ») et superpowers-speckit pourraient entrer en conflit. Le CLAUDE.md tranche en faveur de spec-kit.
Résumé de l’installation complète
# 1. Installer les plugins Claude Code
/plugin install superpowers
/plugin install code-review
/plugin install security-guidance
/reload-plugins
# 2. Installer spec-kit (le framework de spécification)
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
# Puis au choix :
# - Par projet : specify init mon-projet --ai claude --ai-skills
# - Global : copier les templates dans ~/.claude/skills/speckit-*/
# 3. Installer le skill de refactoring dans ~/.claude/skills/
# (copier refactoring-skill/ avec SKILL.md + references/)
# 4. Créer le skill d'intégration superpowers-speckit
# (créer ~/.claude/skills/superpowers-speckit/SKILL.md)
# 5. Créer le CLAUDE.md global
# (créer ~/.claude/CLAUDE.md avec la priorité spec-kit)
Vérification : dans une nouvelle session Claude Code, les skills apparaissent dans la liste des skills disponibles. Taper / et vérifier que speckit-specify, superpowers-speckit, refactoring-skill et les skills superpowers sont tous présents.
Cartographie : quel outil pour quelle phase
| Phase | Outil principal | Type | Installé via |
|---|---|---|---|
| 1. Spécification | speckit-specify, clarify, plan, tasks, analyze | Skills | ~/.claude/skills/ |
| 1bis. Intégration | superpowers-speckit | Skill | ~/.claude/skills/ |
| 2. TDD | superpowers:test-driven-development | Skill (plugin) | /plugin install superpowers |
| 3a. Review par tâche | superpowers:subagent-driven-development | Skill (plugin) | /plugin install superpowers |
| 3b. Review de PR | /code-review | Commande (plugin) | /plugin install code-review |
| 3c. Recevoir une review | superpowers:receiving-code-review | Skill (plugin) | /plugin install superpowers |
| 4. Refactoring | refactoring-skill | Skill | ~/.claude/skills/ |
| 5. Sécurité auto | security-guidance | Hook (plugin) | /plugin install security-guidance |
| 5bis. Sécurité manuelle | Audit humain | Process | Aucune installation |
| 6. Vérification | superpowers:verification-before-completion | Skill (plugin) | /plugin install superpowers |
| Bonus. Debugging | superpowers:systematic-debugging | Skill (plugin) | /plugin install superpowers |
| Bonus. Worktrees | superpowers:using-git-worktrees | Skill (plugin) | /plugin install superpowers |
| Bonus. Finish | superpowers:finishing-a-development-branch | Skill (plugin) | /plugin install superpowers |
| Config. Priorités | CLAUDE.md global | Fichier | ~/.claude/CLAUDE.md |
Vue d’ensemble : le pipeline qualité
Idée / Besoin
|
v
+---------------------------------------------+
| PHASE 1 — Spécification (spec-kit) |
| specify > clarify > plan > tasks > analyze |
| Gate : cohérence cross-artifacts |
+---------------------------------------------+
|
v
+---------------------------------------------+
| PHASE 2 — Implémentation (TDD strict) |
| RED > verify RED > GREEN > verify GREEN |
| > REFACTOR |
| Gate : chaque test échoue avant de passer |
+---------------------------------------------+
|
v
+---------------------------------------------+
| PHASE 3 — Revue de code (double review) |
| Conformité spec > Qualité code |
| Gate : score de confiance > 80/100 |
+---------------------------------------------+
|
v
+---------------------------------------------+
| PHASE 4 — Refactoring (safety-first) |
| Analyse > Contrat > Tests > Exécution |
| Gate : API publique inchangée, tests verts |
+---------------------------------------------+
|
v
+---------------------------------------------+
| PHASE 5 — Audit de sécurité |
| 9 patterns détectés automatiquement |
| + revue manuelle des chemins critiques |
| Gate : zéro warning bloquant |
+---------------------------------------------+
|
v
+---------------------------------------------+
| PHASE 6 — Vérification finale |
| Preuve avant affirmation |
| Gate : évidence concrète (pas "ça devrait |
| marcher") |
+---------------------------------------------+
|
v
Push / PR / Déploiement
Chaque phase a ses propres gates — des points de contrôle obligatoires qui empêchent de passer à la suite si les critères ne sont pas remplis. Détaillons-les.
Phase 1 : Spécification structurée (superpowers + spec-kit)
Le problème qu’on résout
La plupart des bugs ne viennent pas du code. Ils viennent de spécifications floues. « Ajoute des notifications » — quelles notifications ? Déclenchées par quoi ? Avec quelles préférences utilisateur ? Quel provider email ? Quelle conformité RGPD ?
Le workflow en 6 étapes
L’intégration superpowers-speckit remplace la phase de brainstorming classique par un workflow document-driven :
1. SPECIFY — Transformer le besoin en spécification structurée (spec.md)
– User stories avec priorités (P1, P2, P3)
– Exigences fonctionnelles et non-fonctionnelles
– Critères d’acceptation mesurables et testables
– Cas limites et gestion d’erreurs
2. CLARIFY — Scanner les ambiguïtés (max 5 questions)
– Analyse systématique dans 8 catégories (scope fonctionnel, modèle de données, UX, performance, intégrations, cas limites, compromis, terminologie)
– Questions à choix multiples avec recommandation
– Chaque réponse intégrée directement dans le spec
3. PLAN — Design technique détaillé (plan.md)
– Architecture, stack, modèle de données, contrats d’API
– Phase de recherche pour les inconnues
– Validation contre la constitution du projet (principes non-négociables)
4. TASKS — Découpage en tâches actionnables (tasks.md)
– Ordonnées par dépendance
– Marquées [P] quand parallélisables
– Format strict : « – [ ] T001 [P] [US1] Description avec chemin de fichier »
5. ANALYZE — Vérification de cohérence cross-artifacts
– Chaque exigence du spec a-t-elle une tâche correspondante ?
– Le modèle de données supporte-t-il tous les contrats d’API ?
– Les tâches respectent-elles l’ordre de dépendance ?
– Sévérité : CRITICAL (bloque), HIGH, MEDIUM, LOW
6. IMPLEMENT — Exécution avec TDD
La gate de cette phase
Aucune ligne de code n’est écrite tant que l’analyse de cohérence (étape 5) n’a pas été validée. Si des issues CRITICAL sont trouvées, on corrige les specs/plans avant de coder.
Ce que ça change en pratique
Sans spec-kit : « on avait pas pensé à ça » découverte en milieu d’implémentation.
Avec spec-kit : les ambiguïtés sont résolues au coût le plus bas — avant d’avoir écrit une seule ligne de code.
Phase 2 : Implémentation TDD (Test-Driven Development)
La loi d’airain
Aucun code de production sans test échouant préalable.
Ce n’est pas une recommandation. C’est un gate obligatoire que le skill TDD de superpowers impose à chaque tâche.
Le cycle Red-Green-Refactor
- RED — Écrire un test minimal qui montre ce qui devrait fonctionner
- VERIFY RED — Exécuter le test. Confirmer qu’il échoue pour la bonne raison (feature manquante, pas une typo)
- GREEN — Écrire le code le plus simple pour que le test passe
- VERIFY GREEN — Exécuter le test. Confirmer qu’il passe. Les autres tests aussi.
- REFACTOR — Nettoyer, supprimer la duplication, améliorer les noms (seulement après le vert)
Puis on recommence pour le prochain comportement.
Les règles dures
- Code écrit avant le test ? Supprimer. Recommencer. Pas de « copie de référence ».
- Le test passe immédiatement ? Vous testez un comportement existant. Corriger le test.
- Le test est compliqué ? Le design est trop compliqué. Simplifier l’interface.
- Tout mocker ? Le code est trop couplé. Utiliser l’injection de dépendances.
La table des rationalisations
Le skill identifie et bloque systématiquement les excuses classiques :
| Rationalisation | Réalité |
|---|---|
| « Trop simple pour tester » | Le code simple casse. Le test prend 30 secondes. |
| « Je testerai après » | Un test qui passe immédiatement ne prouve rien. |
| « J’ai déjà testé manuellement » | Le test manuel n’est pas reproductible ni automatisable. |
| « Supprimer X heures de travail, c’est du gâchis » | Biais des coûts irrécupérables. Le code non-vérifié est de la dette technique. |
| « Le TDD est dogmatique, je suis pragmatique » | Le TDD EST pragmatique : bugs trouvés avant commit, régressions évitées, comportement documenté. |
Ce que ça change
Chaque fonction a un test. Chaque test a échoué avant de passer. Les cas limites et erreurs sont couverts. La sortie de test est propre — zéro erreur, zéro warning.
Phase 3 : Revue de code (double review automatisée)
Première couche : la double review par tâche
Quand on utilise le mode subagent-driven development de superpowers, chaque tâche passe par deux revues successives :
Étape 1 — Revue de conformité spec : un agent indépendant vérifie que le code correspond exactement à ce que le spec demande. Pas plus, pas moins. Il détecte le sur-engineering (« on a ajouté un système de cache qui n’était pas dans le spec ») et le sous-engineering (« la gestion d’erreur du spec n’est pas implémentée »).
Étape 2 — Revue de qualité code : un second agent examine la qualité technique — nommage, structure, patterns, performance, lisibilité. Cette revue ne commence que quand la revue de conformité est validée.
La boucle : si un reviewer trouve des problèmes, l’implémenteur corrige, puis le reviewer réexamine. On boucle jusqu’à approbation. Pas de « close enough ».
Deuxième couche : la review automatisée de PR
Le plugin code-review lance 5 agents spécialisés en parallèle sur chaque pull request :
| Agent | Focus |
|---|---|
| 1 | Conformité aux règles CLAUDE.md du projet |
| 2 | Scan de bugs évidents dans les changements |
| 3 | Analyse historique (git blame) pour bugs contextuels |
| 4 | Revue des PRs précédentes qui touchaient ces fichiers |
| 5 | Vérification des commentaires de code dans les fichiers modifiés |
Le système de confiance : chaque issue trouvée est scorée de 0 à 100.
| Score | Signification |
|---|---|
| 0 | Faux positif, ne résiste pas à un examen minimal |
| 25 | Possible mais non-vérifié, possiblement stylistique |
| 50 | Issue réelle mais mineure ou peu fréquente en pratique |
| 75 | Issue vérifiée, impacte directement le fonctionnement |
| 100 | Certitude absolue, confirmée par des preuves directes |
Seules les issues à 80+ sont remontées. Ce seuil élimine le bruit des faux positifs — un problème chronique des reviews automatisées qui finissent par être ignorées quand elles crient au loup trop souvent.
La discipline du reviewer humain
Le skill « receiving-code-review » impose une discipline stricte quand on reçoit du feedback :
- Lire complètement avant de réagir
- Comprendre — reformuler l’exigence dans ses propres mots
- Vérifier — confronter à la réalité du codebase
- Évaluer — techniquement valide pour CE projet ?
- Répondre — acknowledgment technique ou pushback argumenté
- Implémenter — un item à la fois, tester chaque correction
Interdit : l’accord performatif. « Tu as tout à fait raison ! » est explicitement banni. À la place : constater le fix, montrer le code, passer à la suite. Les actions parlent plus que les compliments.
Pushback obligatoire quand :
– La suggestion casse une fonctionnalité existante
– Le reviewer n’a pas le contexte complet
– Ça viole YAGNI (feature non-utilisée)
– Ça contredit une décision architecturale validée
Phase 4 : Refactoring structuré (safety-first)
Quand ça intervient
Après l’implémentation et la revue de code, avant le push en production. L’objectif : nettoyer la dette technique accumulée pendant le dev, consolider les patterns, améliorer la lisibilité — sans casser le comportement.
Le protocole en 5 phases
Phase 0 — Détection de contexte
Identifier le goal (lisibilité ? performance ? découpage ? migration de pattern ?), le langage, le framework, et surtout : est-ce qu’il y a une suite de tests ?
Phase 1 — Analyse (aucun code écrit)
Mapper les dépendances avant de toucher quoi que ce soit :
– Quels fichiers importent le code cible ?
– Quels sont les effets de bord (state partagé, I/O, events) ?
– Quel est le « surface publique » (exports utilisés ailleurs) ?
Classification des risques :
– 🔴 Rouge : Effets de bord, I/O, chemins critiques (auth, paiements)
– 🟡 Jaune : Contrats implicites (comportement non-testé mais utilisé)
– 🟢 Vert : Fonctions pures (refactoring libre)
Phase 2 — Définition du contrat
Pour chaque fonction publique : documenter entrées, sorties, invariants. Puis déclarer le scope exact : quels fichiers SERONT modifiés, lesquels NE DOIVENT PAS l’être.
Le plan de refactoring est décomposé en étapes atomiques, chacune indépendamment testable et committable.
Phase 3 — Test Guard
Si la couverture est inférieure à 60% ou si le code est critique (auth, paiements), générer des tests AVANT de refactorer. On ne refactore pas du code cassé — on le stabilise d’abord.
Phase 4 — Exécution par couches
| Couche | Action | Gate |
|---|---|---|
| 1 | Renommage uniquement (variables, fonctions, fichiers) | Tests verts |
| 2 | Extraction de fonctions / décomposition logique | Tests verts |
| 3 | Réorganisation de structure (déplacer fichiers, modules) | Tests verts |
| 4 | Optimisation (algorithmes, patterns, performance) | Tests verts |
Règle absolue : une couche complète avant la suivante. Si les tests échouent à une couche, STOP — diagnostiquer et corriger avant de continuer.
Les 8 règles dures du refactoring
- Jamais de code refactoré avant d’avoir terminé l’analyse + le contrat
- Jamais sans test guard — si pas de tests, en générer d’abord
- Jamais mélanger refactoring et ajout de feature dans le même pass
- Jamais modifier de fichiers hors du scope déclaré
- Jamais continuer après un test échoué
- Jamais d' »améliorations évidentes » hors du plan approuvé
- Jamais renommer une API publique sans approbation explicite
- Toujours présenter le plan et attendre validation avant d’exécuter
Modes spéciaux
- Legacy mode : code sans tests, sans docs, à haut risque — protocole ultra-conservateur
- Architecture mode : refactoring cross-modules ou full-system
- Migration mode : changement de langage/framework/pattern
- Ultra-conservative mode : auth, paiements, sécurité — chaque changement validé individuellement
Phase 5 : Audit de sécurité
La détection automatique (plugin security-guidance)
Le plugin security-guidance d’Anthropic intercepte chaque écriture de fichier (Edit, Write, MultiEdit) et scanne le contenu pour 9 patterns de vulnérabilité :
Côté JavaScript/TypeScript :
– Injection via processus enfant (exec) — suggère des alternatives sans interprétation shell
– Construction dynamique de fonctions — bloque la génération de code à la volée
– Évaluation dynamique de code — suggère JSON.parse ou des alternatives
– Injection HTML directe (innerHTML, dangerouslySetInnerHTML, document.write) — suggère textContent, DOMPurify, ou createElement
Côté Python :
– Désérialization non-sécurisée (pickle) — suggère JSON ou des formats sécurisés
– Exécution de commandes système (os.system) — suggère subprocess avec arguments séparés
Côté Infrastructure :
– Injection dans les workflows GitHub Actions via variables d’événement non-échappées
Comportement :
– Première occurrence : bloque l’écriture et affiche un warning détaillé avec la correction recommandée
– Occurrences suivantes (même session) : laisse passer (évite la fatigue d’alerte)
– Nouvelle session : les warnings réapparaissent
Ce que ça ne couvre pas (et qu’il faut vérifier manuellement)
Le plugin est un filet de sécurité de premier niveau. Il ne détecte pas :
– Les injections SQL
– Les traversées de chemin (path traversal)
– La cryptographie faible
– Les failles CSRF
– Les problèmes d’authentification/autorisation
– Les vulnérabilités de dépendances
La passe manuelle pré-production
Pour ces aspects, une revue manuelle reste indispensable avant la mise en production :
- Revue des entrées utilisateur : chaque point d’entrée (API, formulaire, paramètre URL) est-il validé et sanitizé ?
- Revue des requêtes base de données : paramétrées ? ORM correctement utilisé ?
- Revue des secrets : aucun token/clé/mot de passe commité ? .env dans le .gitignore ?
- Revue des dépendances : audit des packages — vulnérabilités connues ?
- Revue des headers HTTP : CORS, CSP, HSTS, X-Frame-Options configurés ?
- Revue RLS (si Supabase/Postgres) : chaque table a-t-elle des policies row-level security ?
L’audit de sécurité complet par Claude
Le plugin security-guidance et la checklist manuelle forment un premier filet. Mais ils restent ciblés — le plugin détecte des patterns connus, la checklist couvre les points classiques. Pour les failles de conception, de logique métier ou les vecteurs d’attaque spécifiques à votre architecture, il faut aller plus loin.
En pratique, avant chaque mise en production, je demande à Claude de réaliser un audit de sécurité complet de l’application, avec un focus particulier sur les changements qui viennent d’être développés. L’instruction est explicite : « Fais un audit de sécurité complet. Concentre-toi sur ce qu’on vient de développer, mais vérifie aussi les interactions avec le reste de l’app. »
Claude va alors :
– Scanner les nouvelles routes et vérifier la validation des entrées
– Vérifier que les middlewares d’authentification et d’autorisation couvrent tous les endpoints
– Analyser les requêtes base de données pour les injections potentielles
– Vérifier la gestion des sessions et des tokens
– Examiner les flux de données sensibles (PII, données de paiement)
– Checker les configurations de sécurité (CORS, CSP, rate limiting)
– Identifier les scénarios d’escalade de privilèges
– Vérifier que les erreurs ne leakent pas d’informations sensibles
C’est un audit en profondeur qui va au-delà des patterns détectés automatiquement. Claude lit le code, comprend la logique métier, et peut identifier des failles contextuelles qu’un scanner statique manquerait.
Le second regard : audit croisé par un autre modèle
Pour les features critiques (authentification, paiements, données sensibles), j’ajoute une couche supplémentaire : un audit complémentaire par Codex (OpenAI). L’idée est simple — un second modèle IA, avec un entraînement et des biais différents, va voir des choses que le premier a manquées.
En pratique :
# Lancer un audit Codex sur le diff de la feature
codex "Fais un audit de sécurité complet du code modifié
dans cette branche par rapport à main. Concentre-toi
sur les vulnérabilités OWASP Top 10, les failles de
logique métier, et les problèmes d'autorisation."
Ce n’est pas de la méfiance envers Claude — c’est le même principe que la double review de code. Deux paires d’yeux valent mieux qu’une, même quand ces yeux sont ceux de modèles IA. Chaque modèle a ses angles morts. L’intersection de leurs analyses couvre un spectre beaucoup plus large.
Le pipeline sécurité complet ressemble donc à :
security-guidance (automatique, temps réel)
Attrape les patterns dangereux à l'écriture
|
v
Audit complet par Claude (à la demande, pré-production)
Analyse en profondeur du code et de la logique métier
|
v
Audit croisé par Codex (optionnel, features critiques)
Second regard avec un modèle différent
|
v
Revue humaine finale
Validation des findings, décision go/no-go
C’est cette combinaison détection automatique + audit IA en profondeur + second regard croisé + validation humaine qui forme un filet de sécurité complet. Chaque couche attrape ce que la précédente a manqué.
Phase 6 : Vérification avant complétion
Le principe : preuve avant affirmation
C’est la dernière gate, et peut-être la plus importante. Le skill « verification-before-completion » impose une règle simple :
Aucune affirmation de succès sans évidence concrète fraîche.
Le protocole en 5 étapes
- IDENTIFIER — Quelle commande prouve cette affirmation ?
- EXÉCUTER — Lancer la commande complète (pas partielle, pas ancienne)
- LIRE — Sortie complète, code de retour, nombre d’échecs
- VÉRIFIER — La sortie confirme-t-elle l’affirmation ?
- SEULEMENT ALORS — Affirmer avec la preuve
Ce que chaque affirmation exige
| Affirmation | Preuve requise | Insuffisant |
|---|---|---|
| « Les tests passent » | Sortie de commande : 0 échecs | « Ça devrait passer » |
| « Le linter est propre » | Sortie linter : 0 erreurs | Vérification partielle |
| « Le build réussit » | Commande build : exit 0 | « Le linter passe » |
| « Le bug est corrigé » | Test du symptôme original : passe | « Le code a changé » |
| « Les requirements sont remplis » | Checklist ligne par ligne | « Les tests passent » |
Les mots interdits
Si vous vous surprenez à dire « devrait », « probablement », « semble », « je suis confiant » — c’est un signal d’arrêt. La confiance n’est pas une preuve. Seule la sortie d’une commande exécutée dans le message courant compte.
Bonus : le debugging systématique (quand ça casse malgré tout)
Même avec toutes ces gates, des bugs arrivent. Le skill « systematic-debugging » impose un protocole en 4 phases obligatoires :
Phase 1 — Investigation de la cause racine
- Lire les messages d’erreur complètement (stack traces, codes, chemins)
- Reproduire de manière fiable (si non-reproductible, collecter plus de données — pas deviner)
- Checker les changements récents (git diff, commits, dépendances, config)
- Tracer le flux de données : où apparaît la mauvaise valeur ? Qui l’a passée ? Remonter jusqu’à la source.
Phase 2 — Analyse de patterns
- Trouver des exemples fonctionnels similaires dans le codebase
- Comparer exhaustivement — lister chaque différence, même celles qui « ne peuvent pas compter »
- Comprendre les dépendances (config, environnement, assumptions implicites)
Phase 3 — Hypothèse et test
- Formuler UNE hypothèse : « je pense que X est la cause racine parce que Y »
- Tester avec le plus petit changement possible — une variable à la fois
- Ça a marché ? Passer à la phase 4. Non ? Nouvelle hypothèse. Pas d’empilage de corrections.
Phase 4 — Implémentation
- Créer un test qui échoue (reproduisant le bug)
- Implémenter un seul fix (la cause racine, pas le symptôme)
- Vérifier : le test passe ? Les autres tests aussi ?
Le signal d’arrêt architectural
Si 3+ tentatives de fix échouent : stop. Ce n’est plus un bug isolé — c’est un problème architectural. Chaque fix qui révèle un nouveau problème ailleurs indique du couplage excessif ou de l’état partagé. À ce stade, il faut questionner les fondamentaux, pas tenter un 4e patch.
Comment tout s’assemble : un exemple concret
Prenons un cas réel : « Ajouter un système de notifications email à NeuralPro ».
1. SPECIFY — spec.md avec 12 user stories, 8 exigences fonctionnelles, critères d’acceptation
2. CLARIFY — 5 ambiguïtés résolues (triggers, préférences, provider, compliance, in-app vs email)
3. PLAN — plan.md avec architecture event-driven, modèle de données (3 tables + RLS), contrats API
4. TASKS — tasks.md avec 24 tâches ordonnées en 6 phases, 8 parallélisables
5. ANALYZE — 1 issue MEDIUM trouvée (« weekly digest mentionné dans le spec, aucune tâche de cron ») — corrigée
6. IMPLEMENT — Chaque tâche en TDD (red-green-refactor), revue spec + qualité par tâche
7. REVIEW PR — 5 agents, 2 issues à 85+ de confiance, corrigées
8. REFACTORING — Extraction de notification.service.ts depuis email.service.ts, 4 couches, tests verts à chaque couche
9. SÉCURITÉ — Plugin bloque un pattern XSS dans le template de préférences, corrigé avec textContent. Audit manuel : RLS sur les 3 nouvelles tables, secrets en .env, dépendances propres
10. VÉRIFICATION — npm test : 487/487 pass. npm run build : exit 0. npm run lint : 0 errors
11. PUSH — PR créée, mergée après review équipe
Résultat : zéro bug en production. Feature livrée en une session de travail. Chaque décision tracée dans les artifacts spec-kit.
Conclusion : la qualité comme système, pas comme intention
La différence entre « on fait attention à la qualité » et un pipeline qualité structuré, c’est la différence entre l’intention et le système. L’intention est fragile — elle cède sous la pression du temps, de la fatigue, de la complexité. Le système tient parce qu’il a des gates.
Le pipeline décrit ici a 6 gates successives :
- Gate spec : cohérence cross-artifacts avant de coder
- Gate TDD : test échouant avant chaque implémentation
- Gate review : double revue (spec + qualité) avec seuil de confiance
- Gate refactoring : contrat comportemental + exécution par couches
- Gate sécurité : détection automatique + audit manuel
- Gate vérification : preuve concrète avant toute affirmation
Chaque gate est indépendante. Chaque gate a ses propres conditions de passage. Et surtout, chaque gate est explicitement conçue pour résister aux rationalisations — ces petites voix qui disent « juste cette fois », « c’est trop simple pour tester », « je suis confiant que ça marche ».
Le code qui passe toutes ces gates n’est pas parfait. Mais il est vérifié, testé, reviewé, sécurisé, et documenté. Et ça fait toute la différence.
Pour aller plus loin
- Ma configuration multi-agents Claude Code — l’article complémentaire sur l’orchestration 3 IA
- Documentation officielle Claude Code
- Spec-Kit sur GitHub — le framework de spécification
- Plugin superpowers — les skills qualité
- OWASP Top 10 — référence sécurité
Philippe Cohen — AutomatisIA.fr
Mars 2026
Cet article fait partie de la série Actualités IA.