Prompt chaining et orchestration multi-agents

Pourquoi décomposer les grandes tâches

Un seul prompt ne peut pas tout faire. Pour les projets complexes, essayer de tout demander en une fois produit des résultats superficiels : le code est incomplet, les cas limites sont ignorés, les tests sont absents.

Le prompt chaining est la solution : décomposer une tâche complexe en une séquence de prompts plus petits, où chaque étape s'appuie sur le résultat de la précédente. L'orchestration multi-agents pousse ce principe plus loin : plusieurs agents travaillent en parallèle sur différents aspects d'un même problème.

Le prompt chaining : les bases

Principe

Un pipeline de prompt chaining fonctionne ainsi :

1. Prompt 1 → Résultat A
2. Prompt 2 (qui utilise Résultat A) → Résultat B
3. Prompt 3 (qui utilise Résultats A et B) → Résultat C
4. ...

Chaque prompt est petit, ciblé, et validé avant de passer à la suite.

Règles d'or du prompt chaining

• Un objectif par étape : ne mélangez jamais deux responsabilités dans un seul prompt
• Validation explicite : vérifiez chaque résultat avant de passer à l'étape suivante
• Contexte explicite : ne supposez pas que Claude se souvient du contexte de l'étape précédente, soyez explicite
• Points de sortie : définissez à l'avance les critères qui permettent de passer à l'étape suivante

Exemple 1 : Implémenter une feature complète

Voici un pipeline complet pour implémenter une feature de bout en bout.

"Je veux implémenter une fonctionnalité de recherche full-text dans notre app
Next.js/TypeScript avec base PostgreSQL/Prisma.

Avant de coder :
1. Analyse les besoins (quels champs, quels modèles, volume estimé)
2. Compare les options techniques (pg_trgm vs tsvector vs Elasticsearch)
3. Recommande une approche avec justification
4. Génère un plan d'implémentation en phases

Attends ma validation avant de commencer."

"Le plan est validé. On utilise tsvector avec GIN index.

Phase 1 : migration de base de données.
Fichiers actuels : prisma/schema.prisma (je vais le coller)

Génère :
1. La migration Prisma pour ajouter les colonnes tsvector sur Product et Article
2. Le trigger PostgreSQL pour maintenir les vecteurs à jour automatiquement
3. L'index GIN pour les performances
4. Un script de backfill pour les données existantes

Ne touche pas encore au code applicatif.
[schema.prisma actuel]"

"Migration appliquée et validée. Phase 2 : le service de recherche.

Crée src/features/search/search.service.ts avec :
- Méthode searchProducts(query: string, filters: SearchFilters): Promise<SearchResult>
- Méthode searchArticles(query: string, pagination: Pagination): Promise<SearchResult>
- Gestion du ranking par pertinence (ts_rank)
- Support des opérateurs booléens (AND, OR, NOT)
- Sanitization des inputs

Utilise le pattern Repository du projet (comme dans src/features/products/product.repository.ts).
TypeScript strict, pas de any, gestion d'erreurs explicite."

"Service validé et testé. Phase 3 : l'API et l'UI.

Crée en parallèle :
1. Le route handler Next.js dans app/api/search/route.ts
   - Validation des query params avec Zod
   - Rate limiting (20 req/min par IP)
   - Format de réponse { success, data, meta }

2. Le composant SearchBar dans src/components/search/SearchBar.tsx
   - Debounce de 300ms
   - Affichage des suggestions en dropdown
   - Accessibilité WCAG 2.1 (aria-live, aria-expanded)
   - Dark mode"

"Implémentation terminée. Phase finale : tests et documentation.

1. Tests unitaires pour search.service.ts (Vitest + mock Prisma)
   - Tests des cas nominaux
   - Tests des edge cases (query vide, caractères spéciaux, résultats vides)
   - Tests des opérateurs booléens

2. Tests E2E pour le composant SearchBar (Playwright)
   - Saisie et affichage des suggestions
   - Sélection d'un résultat
   - Gestion des erreurs réseau

3. Mise à jour du CLAUDE.md avec la documentation du module search"

Exemple 2 : Pipeline de debugging systématique

Un pipeline structuré pour les bugs difficiles à localiser.

"Nous avons un bug de production sur notre API de commandes.
Symptômes :
- Erreur intermittente 500 sur POST /api/orders (environ 2% des requêtes)
- Apparaît sous charge (> 100 req/s) mais pas en dev
- Les logs montrent : 'Connection pool timeout' mais pas systématiquement
- Démarré après le déploiement v2.3.1

Logs bruts : [coller les logs]
Code de l'endpoint : [coller le code]
Configuration Prisma : [coller la config]

Étape 1 : analyse uniquement. Liste toutes les hypothèses possibles,
classées par probabilité. Ne propose pas encore de solution."

"Hypothèses reçues. Pour chaque hypothèse dans l'ordre de probabilité :
1. Indique comment la valider avec les outils disponibles (logs, métriques, code)
2. Estime le temps de validation
3. Identifie les prérequis

Commence par l'hypothèse la plus probable :
[hypothèse choisie par Claude]"

"L'hypothèse principale est : saturation du connection pool Prisma sous charge.

Génère :
1. Un script de load test (k6 ou autocannon) qui reproduit les conditions de production
2. Les métriques à capturer pendant le test (pool stats, latence, erreurs)
3. Les seuils qui confirment ou infirment l'hypothèse"

"Hypothèse confirmée par le load test. Le pool Prisma de 10 connexions
est saturé dès 80 req/s.

Propose :
1. La correction immédiate (augmenter le pool, optimiser les requêtes lentes)
2. La correction structurelle (connection pooling avec PgBouncer, optimisation des queries N+1)
3. Les changements de code précis avec fichiers et lignes concernés"

"Correction appliquée. Génère :
1. Le test de régression qui aurait détecté ce bug avant la mise en production
2. Les alertes à configurer pour détecter ce pattern à l'avenir
3. La post-mortem template pour documenter l'incident"

Exemple 3 : Migration de codebase

Un pipeline pour migrer progressivement sans casser la production.

# Étape 0 : Inventaire
"Analyse le codebase et génère un inventaire de migration JavaScript → TypeScript.
Pour chaque fichier : taille, complexité estimée (1-5), dépendances, risques.
Génère un tableau trié par priorité de migration (quick wins d'abord)."

# Étape 1 (après validation de l'inventaire) : Configuration
"Plan validé. Phase 1 : configuration TypeScript.
Génère :
1. tsconfig.json en mode progressif (allowJs: true, strict: false au départ)
2. Les scripts npm mis à jour
3. La configuration ESLint pour TypeScript
Ne touche à aucun fichier .js pour l'instant."

# Étape 2 : Migration module par module
"Phase 2 : migration du module utils/ (le plus simple selon l'inventaire).
Pour chaque fichier utils/*.js :
1. Convertis en TypeScript
2. Ajoute les types stricts
3. Génère les tests unitaires s'ils n'existent pas
Commence par utils/date.js. Montre-moi le résultat avant de passer au suivant."

# Étapes suivantes : répéter par module
"utils/date.ts validé. Passe à utils/validation.js."

Orchestration multi-agents

L'orchestration multi-agents va plus loin que le chaining séquentiel. Plusieurs agents travaillent en parallèle sur différents aspects d'un même problème, puis leurs résultats sont synthétisés.

Le Task Tool : lancer des agents en parallèle

Le Task Tool dans Claude Code permet de lancer plusieurs sous-agents en parallèle. Chaque sous-agent est une instance de Claude qui travaille de façon autonome sur une tâche spécifique.

"Lance 3 agents en parallèle pour analyser notre API de paiement :

Agent 1 (sécurité) :
Tu es un expert en sécurité applicative (OWASP Top 10 + PCI-DSS).
Analyse les fichiers src/payment/*.ts pour détecter :
- Vulnérabilités d'injection
- Exposition de données de carte
- Problèmes d'authentification
Format : tableau | Sévérité | Fichier | Ligne | Vulnérabilité | Correction |

Agent 2 (performance) :
Tu es un expert en performance Node.js.
Analyse les fichiers src/payment/*.ts pour détecter :
- Requêtes N+1
- Appels synchrones bloquants
- Manque de cache
- Memory leaks potentiels
Format : tableau | Type | Fichier | Ligne | Impact | Correction |

Agent 3 (tests) :
Tu es un expert TDD.
Analyse les fichiers src/payment/*.ts et src/payment/__tests__/*.ts pour :
- Identifier la couverture actuelle
- Lister les cas limites non testés
- Proposer les tests manquants critiques
Format : liste priorisée par importance

Attends les résultats des 3 agents, puis synthétise dans un rapport unifié
avec les 10 actions prioritaires."

Architecture fan-out / fan-in

L'architecture fan-out/fan-in est le pattern le plus courant pour l'orchestration parallèle :

Tâche principale
        │
        ├─── Agent 1 (spécialité A)
        ├─── Agent 2 (spécialité B)    } Fan-out
        └─── Agent 3 (spécialité C)

        │ (résultats A + B + C)
        ▼
  Synthèse / Agrégation                } Fan-in
        │
        ▼
  Résultat final enrichi

Exemple : revue de code complète

"Fan-out : lance en parallèle :
- Agent code-reviewer : qualité, patterns, maintenabilité
- Agent security-reviewer : OWASP, secrets, surface d'attaque
- Agent tdd-guide : couverture, cas limites, tests manquants
- Agent doc-updater : documentation manquante ou obsolète

Fan-in : synthétise les 4 rapports en une liste d'actions prioritaires
avec estimation d'effort pour chaque action."

Architecture pipeline séquentiel

Quand les étapes ont des dépendances, utilisez un pipeline séquentiel :

Agent 1 : Planification
    │ (plan validé)
    ▼
Agent 2 : Implémentation
    │ (code produit)
    ▼
Agent 3 : Tests
    │ (tests qui passent)
    ▼
Agent 4 : Documentation
    │ (docs à jour)
    ▼
Agent 5 : Revue finale

Exemple : feature complète en pipeline

"Pipeline séquentiel pour implémenter la feature d'export PDF :

Agent 1 (planner) : Analyse le besoin, propose un plan technique, liste les fichiers à créer
Condition de passage : plan validé par l'utilisateur

Agent 2 (implementer) : Implémente selon le plan
Input : plan de l'Agent 1
Condition de passage : code compile, lint passe

Agent 3 (tdd-guide) : Écrit les tests pour l'implémentation
Input : code de l'Agent 2
Condition de passage : couverture > 80%, tous les tests passent

Agent 4 (doc-updater) : Met à jour la documentation
Input : code final + tests de l'Agent 3
Output : CLAUDE.md mis à jour, README mis à jour"

Configuration d'agents dans ~/.claude/agents/

Pour les agents que vous utilisez régulièrement, créez des fichiers de configuration dans ~/.claude/agents/.

Structure d'un fichier d'agent

# ~/.claude/agents/security-reviewer.md

Tu es un expert en sécurité applicative spécialisé dans les API web.

## Ton rôle
Analyser le code pour détecter les vulnérabilités de sécurité avec un regard expert.

## Méthodologie
1. Commence par l'OWASP Top 10 (injection, auth cassée, exposition de données...)
2. Analyse les dépendances tierces (npm audit)
3. Vérifie la gestion des secrets et tokens
4. Examine la surface d'attaque de chaque endpoint public

## Format de sortie
Pour chaque vulnérabilité :
| Sévérité | Catégorie | Fichier | Ligne | Description | Correction |
Sévérités : CRITICAL / HIGH / MEDIUM / LOW / INFO

## Règles absolues
- CRITICAL et HIGH doivent être corrigés avant tout déploiement
- Ne jamais exposer des tokens ou clés API dans les exemples de correction
- Si tu trouves des secrets hardcodés, signale-les immédiatement

Invoquer un agent configuré

# Invoquer l'agent security-reviewer
"Lance l'agent security-reviewer sur le dossier src/api/
avec une attention particulière aux endpoints d'authentification."

Exemples d'agents utiles à configurer

planner : Décompose les features en plans techniques code-reviewer : Review de code avec sévérités tdd-guide : Aide à l'écriture de tests (RED-GREEN-REFACTOR) architect : Conseils d'architecture et design patterns security-reviewer : Analyse de sécurité OWASP build-error-resolver : Résolution des erreurs de build doc-updater : Mise à jour de la documentation refactor-cleaner : Nettoyage du code mort et refactoring

Prompts autonomes pour les sous-agents

Un point critique souvent négligé : chaque sous-agent démarre à froid, sans le contexte de la conversation principale. Vos prompts pour les sous-agents doivent être entièrement autonomes.

# Mauvais (suppose un contexte que le sous-agent n'a pas)
"Vérifie la sécurité du code qu'on vient de discuter"

# Bon (prompt autonome et complet)
"Tu es un expert en sécurité applicative.

Contexte : application Next.js 14 avec API Routes, authentification JWT,
base de données PostgreSQL via Prisma.

Analyse les fichiers suivants pour détecter des vulnérabilités :
- src/app/api/auth/route.ts
- src/lib/auth.ts
- src/middleware.ts

Vérifie spécifiquement :
1. Validation et sanitization des inputs
2. Gestion sécurisée des tokens JWT
3. Protection CSRF sur les mutations
4. Exposition de données sensibles dans les réponses
5. Headers de sécurité (CORS, CSP)

Format de sortie :
| Sévérité | Fichier | Ligne | Vulnérabilité | Correction |
|----------|---------|-------|---------------|------------|"

Checklist pour un pipeline efficace

Avant de lancer un pipeline de prompt chaining, vérifiez :

• Chaque étape a un objectif unique et mesurable
• Les critères de passage entre étapes sont définis
• Les prompts des sous-agents sont autonomes (pas de dépendance de contexte implicite)
• Les étapes indépendantes sont parallélisées
• Les étapes avec dépendances sont séquentielles
• Un point de validation humaine est prévu avant chaque étape irréversible

Prochaines étapes

Vous maîtrisez maintenant le prompt chaining et l'orchestration multi-agents. Approfondissez avec :

• Extended Thinking et Plan Mode : Amplifiez la qualité du raisonnement à chaque étape
• Gestion du contexte : Gérez efficacement le contexte dans les longues chaînes
• Orchestration avancée des agents : Patterns d'orchestration complexes avec worktrees et pipelines CI/CD
• Comprendre les agents : Approfondissez la compréhension des subagents Claude Code
• Créer un Skill custom : Encapsulez vos pipelines de prompts dans des Skills réutilisables
• Top MCP pour le développement : Outillez vos agents avec les MCP de développement
• Premiers pas avec Claude Code : Revenez aux bases pour bien configurer votre environnement
• Configurateur interactif : Choisissez le preset d'agents adapté à votre workflow