design pattern planning
Le pattern Planning (Planification) permet à un agent IA de décomposer un objectif complexe en un plan d’étapes ordonnées avant de commencer à agir. Au lieu d’improviser au fil de l’eau, l’agent génère d’abord une feuille de route structurée, puis exécute chaque étape séquentiellement — en adaptant le plan si nécessaire. Résultat : des tâches multi-étapes résolues avec méthode, traçabilité et un taux de réussite nettement supérieur au mode « réponse directe ».
Voir la table des matières complète
1. Le Concept en Une Phrase
📐 Principe
Séparer la réflexion stratégique (quoi faire et dans quel ordre) de l’exécution tactique (faire chaque étape). Le LLM produit un plan explicite au format structuré (JSON/liste), puis un orchestrateur exécute ce plan étape par étape.
🚀 Bénéfice
Divise un problème insoluble en une seule passe en sous-tâches maîtrisables. Le plan offre traçabilité (chaque étape est loggée), contrôle (on peut valider/modifier le plan) et résilience (re-planification en cas d’échec).
2. Quand Utiliser vs NE PAS Utiliser
✅ Cas d’Usage Idéaux
| Situation | Pourquoi le Planning excelle |
|---|---|
| Tâches multi-étapes avec dépendances | L’ordre compte : l’étape 3 dépend du résultat de l’étape 1 |
| Objectifs vagues à concrétiser | Le plan force la décomposition en actions concrètes et vérifiables |
| Workflows nécessitant des outils externes | Chaque étape peut appeler une API, une base de données, un fichier |
| Tâches où l’utilisateur veut valider avant exécution | Le plan peut être présenté et modifié avant lancement |
| Projets de recherche / analyse en profondeur | Structurer une investigation en phases logiques évite les oublis |
❌ Quand NE PAS Utiliser
| Situation | Pourquoi éviter |
|---|---|
| Questions simples / réponses factuelles | Surcoût inutile : planifier « Quelle est la capitale de la France ? » est absurde |
| Latence critique (< 1s) | La phase de planification ajoute 1-3s minimum |
| Tâches sans structure séquentielle | Si tout peut se faire en parallèle → utilisez plutôt la Parallélisation |
| Contexte insuffisant pour planifier | Un plan basé sur des hypothèses fausses fait plus de mal que de bien |
3. Trois Exemples Concrets
📦 Exemple 1 : Migration de Base de Données SaaS
Contexte : Un agent doit orchestrer la migration d’un schéma de base de données avec transformation de données, sans interruption de service.
Types de requêtes :- « Migre la table users vers le nouveau schéma v3 »
- « Ajoute la colonne subscription_tier et remplis-la à partir des données Stripe »
- « Restructure les relations orders ↔ invoices »
Gains mesurés :
- Fiabilité 95% des migrations réussies du premier coup (vs 60% en mode ad-hoc)
- Traçabilité Chaque étape loggée avec timestamp et résultat
- Temps 4 min en moyenne (vs 15 min d’aller-retour humain)
💬 Exemple 2 : Agent de Support Client Multi-Canaux
Contexte : Un agent reçoit une réclamation complexe impliquant plusieurs systèmes (commande, livraison, facturation) et doit résoudre le problème de bout en bout.
Types de requêtes :- « Ma commande #4521 n’est jamais arrivée, j’ai été facturé deux fois, et le chat m’a dit de rappeler »
- « Je veux annuler mon abonnement, récupérer mon solde et transférer mes données »
Gains mesurés :
- Résolution 82% des réclamations complexes résolues sans escalade humaine
- Satisfaction NPS +18 pts grâce à la réponse structurée
- Coût -65% sur le traitement des tickets multi-systèmes
🛡️ Exemple 3 : Audit de Sécurité Automatisé
Contexte : Un agent planifie et exécute un audit de sécurité complet sur une application web, en enchaînant différents types de vérifications.
Types de requêtes :- « Audite la sécurité de l’application déployée sur api.example.com »
- « Vérifie la conformité RGPD de notre pipeline de données »
Gains mesurés :
- Couverture 40+ vérifications vs 12 en mode check-list manuelle
- Précision 91% de vrais positifs (faux positifs filtrés par la phase de validation)
- Temps 8 min pour un audit complet (vs 2h en manuel)
4. Prompt Prêt à l’Emploi
💡 Prompt Prêt à l’Emploi : Agent de Planification Adaptative
Contexte :
Ce système en 4 étapes configure un agent capable de planifier, exécuter séquentiellement, et re-planifier si nécessaire. Il illustre le mécanisme complet du pattern Planning : génération du plan → exécution étape par étape → vérification → adaptation.
Étape 1 — Génération du Plan :
Tu es un planificateur stratégique.
**Objectif à atteindre :**
[OBJECTIF]
**Contexte disponible :**
[CONTEXTE]
**Outils disponibles :**
[LISTE_OUTILS]
**Instructions :**
1. Décompose cet objectif en étapes SÉQUENTIELLES et CONCRÈTES
2. Pour chaque étape, définis :
- Un ID unique (step_1, step_2, ...)
- Une action précise (verbe + objet)
- Les dépendances (quelles étapes précédentes sont nécessaires)
- L'outil à utiliser (si applicable)
- Le critère de succès (comment savoir que l'étape est réussie)
3. Ordonne les étapes selon leurs dépendances
4. Limite le plan à 8 étapes maximum
**Format de sortie (JSON) :**
{
"objectif": "...",
"nb_etapes": 5,
"plan": [
{
"id": "step_1",
"action": "Récupérer les données du client depuis le CRM",
"dependances": [],
"outil": "api_crm",
"critere_succes": "Objet client avec email et historique non vide",
"timeout_ms": 5000
},
{
"id": "step_2",
"action": "Analyser l'historique des commandes",
"dependances": ["step_1"],
"outil": null,
"critere_succes": "Liste des anomalies identifiées",
"timeout_ms": 10000
}
]
}Étape 2 — Exécution Séquentielle (pseudo-code) :
const plan = await appelLLM(promptPlanification);
const resultats = {};
for (const etape of plan.plan) {
// Vérifier que toutes les dépendances sont résolues
const dependancesOK = etape.dependances.every(
dep => resultats[dep]?.succes === true
);
if (!dependancesOK) {
// → Déclencher la re-planification (Étape 4)
return await rePlanifier(plan, resultats, etape);
}
// Construire le contexte avec les résultats précédents
const contexteEtape = etape.dependances.map(
dep => `Résultat de ${dep}: ${JSON.stringify(resultats[dep].donnees)}`
).join('\n');
// Exécuter l'étape
const resultat = await executerEtape(etape, contexteEtape);
resultats[etape.id] = resultat;
// Vérifier le critère de succès
if (!resultat.succes) {
return await rePlanifier(plan, resultats, etape);
}
}
return syntheseFinale(resultats);Étape 3 — Prompt d’Exécution par Étape :
Tu exécutes UNE SEULE étape d'un plan.
**Étape à exécuter :**
[ETAPE_COURANTE]
**Résultats des étapes précédentes :**
[RESULTATS_PRECEDENTS]
**Instructions :**
1. Réalise UNIQUEMENT l'action décrite dans cette étape
2. Utilise l'outil spécifié si applicable
3. Vérifie toi-même le critère de succès
4. Si tu ne peux PAS réussir cette étape, explique pourquoi
**Format de sortie (JSON) :**
{
"etape_id": "step_2",
"succes": true,
"donnees": { ... },
"critere_verifie": true,
"notes": "Anomalie détectée : double facturation sur commande #4521"
}Étape 4 — Re-planification Adaptative :
Tu es un re-planificateur.
**Plan initial :**
[PLAN_INITIAL]
**Étapes déjà réalisées :**
[RESULTATS_OBTENUS]
**Étape en échec :**
[ETAPE_ECHOUEE]
**Raison de l'échec :**
[RAISON_ECHEC]
**Instructions :**
1. Analyse pourquoi l'étape a échoué
2. Propose un plan RÉVISÉ qui :
- Conserve les étapes réussies
- Remplace ou contourne l'étape en échec
- Ajoute des étapes correctives si nécessaire
3. Si l'objectif est inatteignable, explique pourquoi et propose un objectif alternatif
**Format de sortie (JSON) :**
{
"plan_revise": [...],
"modifications": "Ajout d'une étape de vérification manuelle avant step_3",
"objectif_atteignable": true
}Flux complet :
Variables à personnaliser :
[OBJECTIF]: L’objectif final en langage naturel (ex : « Migrer la table users vers le schéma v3 »)[CONTEXTE]: Informations de contexte utiles (état actuel du système, contraintes, etc.)[LISTE_OUTILS]: Les outils/API disponibles (ex : « api_crm, api_stripe, base_postgres, envoi_email »)[ETAPE_COURANTE]: L’objet JSON de l’étape en cours d’exécution[RESULTATS_PRECEDENTS]: Les résultats JSON des étapes déjà exécutées[PLAN_INITIAL]: Le plan JSON complet généré à l’étape 1[ETAPE_ECHOUEE]: L’étape qui a échoué avec ses détails[RAISON_ECHEC]: Le message d’erreur ou la raison de l’échec
Résultat attendu :
Exécution complète et tracée de l’objectif, avec un log de chaque étape (succès/échec + données). En cas d’échec partiel, un plan révisé est automatiquement généré et exécuté. Temps total ≈ somme des étapes + 1-2s de planification.
5. Patterns et Anti-Patterns
✅ Patterns Efficaces
📋 Plan Avant Exécution
Toujours générer le plan complet avant la première action. Permet à l’utilisateur de valider et au système de détecter les incohérences.
🔄 Re-planification Conditionnelle
Prévoir un mécanisme de re-planification déclenché par l’échec d’une étape ou par un résultat inattendu. Ne pas boucler indéfiniment : limite à 2-3 re-planifications.
🧩 Granularité Adaptée
Chaque étape doit être atomique et vérifiable. Si une étape est trop vague (« résoudre le problème »), elle doit être re-décomposée.
📊 Critères de Succès Explicites
Chaque étape du plan inclut un critère de succès mesurable. Sans critère, impossible de savoir si l’étape est réussie ou si la re-planification est nécessaire.
❌ Anti-Patterns à Éviter
| Anti-Pattern | Conséquence | Solution |
|---|---|---|
| Plan Fantôme : planifier mentalement sans produire de plan explicite | Aucune traçabilité, impossible de débuguer ou de reprendre | Forcer la sortie JSON du plan avant toute exécution |
| Sur-planification : 20+ étapes pour une tâche simple | Latence explosive, coût LLM x10, perte de contexte | Limiter à 8 étapes max, fusionner les micro-étapes |
| Plan Rigide : aucune adaptation possible en cours d’exécution | Blocage total au premier imprévu | Implémenter la re-planification adaptative (Étape 4 du prompt) |
| Boucle Infinie : re-planifier sans fin après chaque échec | Coût et latence incontrôlables, résultat jamais atteint | Compteur de tentatives (max 3), puis escalade ou abandon |
6. Propriétés Essentielles
🎯 Décomposition Explicite
Le plan est un artefact structuré (JSON, liste), pas une réflexion implicite cachée dans la réponse.
Pourquoi : permet la validation, le logging et la reprise.🔗 Gestion des Dépendances
Chaque étape déclare ses dépendances. L’orchestrateur vérifie qu’elles sont satisfaites avant de lancer l’étape.
Pourquoi : évite les exécutions dans le désordre.⟲ Adaptabilité
Le plan n’est pas figé. Le système peut insérer, supprimer ou modifier des étapes en fonction des résultats intermédiaires.
Pourquoi : le monde réel ne suit jamais le plan initial.✅ Critères de Succès
Chaque étape a un critère de succès vérifiable. Sans cela, pas de boucle d’exécution fiable.
Pourquoi : distinguer « exécuté » de « réussi ».📝 Traçabilité Complète
Chaque étape loggue son résultat, son temps d’exécution et son statut. Le plan complet est conservé.
Pourquoi : débugage, audit, et amélioration continue.🛑 Limites de Sécurité
Nombre max d’étapes, nombre max de re-planifications, timeout global. L’agent ne peut pas tourner indéfiniment.
Pourquoi : maîtriser le coût et la latence.7. Métriques de Succès
| Métrique | Cible | Alerte si | Signification |
|---|---|---|---|
| Taux de plans exécutés sans re-planification | ≥ 75% | < 50% | La qualité de la planification initiale est insuffisante |
| Nombre moyen d’étapes par plan | 3-7 | > 10 | Sur-planification → fusionner des étapes ou simplifier l’objectif |
| Taux de réussite final (objectif atteint) | ≥ 85% | < 70% | Le pattern n’est pas adapté au cas d’usage ou les outils sont défaillants |
| Temps total moyen (planification + exécution) | < 30s | > 60s | Étapes trop nombreuses ou outils trop lents |
| Nombre de re-planifications par exécution | ≤ 1 | ≥ 3 | Le planificateur ne tient pas compte du contexte réel |
| Coût LLM moyen par plan complet | Variable | > 3x le coût d’un appel unique | Trop d’étapes ou modèle trop puissant utilisé pour des étapes simples |
8. Récapitulatif
- Planifier avant d’agir — Le LLM génère un plan structuré (JSON) avec étapes ordonnées, dépendances et critères de succès. Ce plan est un artefact vérifiable, pas une réflexion cachée.
- Exécuter étape par étape — Un orchestrateur (code) exécute le plan séquentiellement, en injectant les résultats des étapes précédentes dans le contexte de chaque nouvelle étape.
- S’adapter en cours de route — Si une étape échoue, le système déclenche une re-planification qui conserve les acquis et propose un chemin alternatif. Avec des limites : max 2-3 tentatives.
✅ Quand Utiliser
- Tâches multi-étapes avec dépendances
- Objectifs complexes à décomposer
- Workflows avec outils/API externes
- Besoin de traçabilité et d’audit
- Validation humaine avant exécution
❌ Quand NE PAS Utiliser
- Questions simples / factuelles
- Latence critique (< 1s)
- Tâches parallélisables sans dépendances
- Contexte trop flou pour planifier
- Tâches triviales en une seule passe



