---
title: Workflow — Patterns : Général
domain: workflow
bucket: patterns
tags: [review, adversarial, git, chantier, agent]
applies_to: [analysis, implementation, review]
severity: high
validated_on: 2026-04-27
source_projects: [RL799_V2]
---

# Workflow — Patterns : Général

> Extrait de la base de connaissance Lead_tech. Voir `knowledge/workflow/patterns/README.md` pour l'index complet.

---

<a id="pattern-review-adversarial-chemin-critique"></a>
## Pattern : Review adversarial obligatoire sur chemin critique

- Objectif : détecter avant commit les race conditions, assertions trop molles et dépendances cachées qui ne sont pas visibles à la lecture du spec mais le sont à la lecture du code écrit.
- Contexte : chantier qui touche un chemin critique (atomicité, audit, sécurité, intégrité financière, lifecycle d'entité métier) — même petit (< 100 lignes).
- Quand l'utiliser : systématique sur les chemins critiques, indépendamment de la taille du chantier.
- Quand l'éviter : refactor cosmétique, polish UX, documentation, tests d'un chemin déjà couvert.
- Avantage :
  - capture les défauts post-spec (l'intention est cadrée, l'implémentation peut diverger)
  - moins coûteuse à corriger avant commit qu'en post-prod (incident, debug, rollback)
- Limites / vigilance :
  - pas un substitut à la code review classique (posture différente : "qu'est-ce qui casse" vs "est-ce conforme au spec")
  - pas un substitut aux tests qui passent (les tests valident ce qu'on a pensé tester)
- Validé le : 27-04-2026
- Contexte technique : workflow agent / BMAD — RL799_V2

### Identifier un chemin critique

Au moins **une** des conditions :
- mutation atomique d'une entité métier (close, cancel, lock, archive)
- émission d'audit log (la traçabilité est non-négociable)
- émission de notification (mauvais target = bug visible utilisateur)
- logique d'autorisation, RBAC, gates de permission
- calculs financiers (paiements, soldes, totaux)
- intégrité référentielle (FK, soft-delete)
- concurrence : plusieurs process peuvent toucher la même entité

### Format de review efficace

Posture : œil fâché, on cherche à casser ce qu'on vient de livrer.

Pour chaque finding :
- **Sévérité** : HIGH / MEDIUM / LOW / NIT
- **Localisation** : `file:line`
- **Problème** : ce qui peut casser, dans quel scénario
- **Mitigation possible** : 1-3 options
- **Verdict** : fix dans le scope, dette explicite, ignorer

Sortie : tableau synthétique. Si > 0 HIGH ou > 2 MEDIUM, on fixe avant commit.

### Anti-règle

- Confondre review adversarial et code review classique
- Confondre "tests verts" et "implémentation correcte"
- Lire son propre code en attendant de le valider (biais cognitif fort)

---

<a id="pattern-isolation-hunk-git-apply-cached"></a>
## Pattern : Isolation chirurgicale d'un hunk via `git apply --cached <patch>`

- Objectif : commiter uniquement les hunks d'un chantier A dans un fichier également modifié par un chantier B, sans interaction `git add -p`.
- Contexte : plusieurs chantiers parallèles touchent le même fichier central (catalog audit, schema partagé, fichier d'enums).
- Quand l'utiliser : agent IA en environnement non-interactif qui prépare un commit avec sélection de hunks.
- Quand l'éviter : si on commit la totalité du fichier (`git add <file>` direct suffit), ou si les hunks sont logiquement indissociables.
- Avantage :
  - non-interactif, scriptable
  - le worktree garde tous les changements (mes hunks A commités + hunks B unstaged pour le chantier B)
- Limites / vigilance :
  - en interactif humain, `git add -p` reste plus rapide
  - le patch filtré doit rester valide (en-têtes `diff --git`, `index`, `@@` cohérents)
- Validé le : 27-04-2026
- Contexte technique : git / chantiers parallèles — RL799_V2

### Recette

```bash
# 1. Capturer le diff du fichier mixte
git diff <file> > /tmp/mixed.patch

# 2. Éditer le patch pour ne garder que les hunks à commiter
#    (un agent peut le faire via Read + Write — c'est un fichier texte)

# 3. Appliquer le patch filtré uniquement à l'index (pas au worktree)
git apply --cached /tmp/mine_only.patch

# 4. Vérifier le staged
git diff --cached <file>

# 5. Commit
git commit ...

# 6. Le worktree garde TOUS les changements
git diff <file>  # affiche les hunks de l'autre chantier
```

### Format minimal d'un hunk

```diff
diff --git a/<file> b/<file>
index <hash_old>..<hash_new> 100644
--- a/<file>
+++ b/<file>
@@ -<line>,<count> +<line>,<count> @@ <context>
 <ligne contexte avant>
+<ligne ajoutée>
 <ligne contexte après>
```

Les `index` et `@@` viennent du `git diff` original — pas besoin de recalculer les hashes.

---

<a id="pattern-sub-agents-trianguler-localisations"></a>
## Pattern : Trianguler par grep les localisations rapportées par un sub-agent

- Objectif : ne jamais agir directement sur les localisations précises rapportées par un sub-agent d'analyse — toujours vérifier avant de patcher.
- Contexte : workflow multi-agent où un sub-agent (Explore, audit BMAD, lecture de code) retourne un rapport avec findings.
- Quand l'utiliser : à la réception de tout rapport de sub-agent qui cite des fichiers, lignes, ou snippets.
- Quand l'éviter : pour les comptages globaux et tendances — fiables même sans triangulation.
- Avantage :
  - évite de "corriger" du code déjà correct (pollution de commit, perte de confiance)
  - distingue les findings actionables des extrapolations
- Limites / vigilance :
  - ajoute ~15-20 % de temps à la phase d'action — largement compensé par les commits évités
- Validé le : 24-04-2026
- Contexte technique : workflow multi-agent / BMAD — RL799_V2

### Règle

> Ne jamais agir sur les **localisations précises** d'un sub-agent sans vérification.
> - Sub-agent dit "fichier X ligne Y a pattern Z" → `grep Z fichier X` doit confirmer
> - Sub-agent dit "fichiers A, B, C, D ont pattern Z" → grep chaque fichier
> - Si un finding s'effondre à la vérif, relire critiquement les autres findings du même sub-agent

### Ce qui reste fiable chez un sub-agent

- Comptages globaux (X fichiers sur Y ont le pattern Z — l'ordre de grandeur est généralement juste)
- Tendances (ex: "le projet a un problème de cleanup" — juste, même si les fichiers cités sont faux)
- Patterns de risque identifiés (`vi.stubEnv` sans restauration est un vrai pattern à risque)

### Ce qui est peu fiable

- Numéros de ligne précis (peuvent être hallucinés)
- Listes de fichiers exhaustives pour un pattern rare
- Snippets de code cités (peuvent être reconstruits de mémoire plutôt que lus)

### Communication au user

> *"Sub-agent X signale 4 fichiers, j'ai validé 1/4 et invalidé 3/4. Voici le plan d'action corrigé."*