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

🎯 Essence : L’agent réfléchit d’abord (plan), agit ensuite (exécution), et corrige en cours de route (re-planification adaptative).
[OBJECTIF COMPLEXE] │ ▼ ┌─────────────────┐ │ PLANIFICATEUR │ ── Génère un plan en N étapes └────────┬────────┘ │ ▼ ┌─────────────────┐ ┌──────────────────┐ │ Étape 1 │────▶│ Résultat 1 │ └────────┬────────┘ └──────┬───────────┘ │ │ ▼ ▼ ┌─────────────────┐ ┌──────────────────┐ │ Étape 2 │────▶│ Résultat 2 │ └────────┬────────┘ └──────┬───────────┘ │ │ ▼ ▼ ┌───────────┐ ┌─────────────┐ │ Étape N │────────▶│ RÉSULTAT │ └───────────┘ │ FINAL │ └─────────────┘⟲ Re-planification si une étape échoue ou dévie

📐 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

SituationPourquoi le Planning excelle
Tâches multi-étapes avec dépendancesL’ordre compte : l’étape 3 dépend du résultat de l’étape 1
Objectifs vagues à concrétiserLe plan force la décomposition en actions concrètes et vérifiables
Workflows nécessitant des outils externesChaque étape peut appeler une API, une base de données, un fichier
Tâches où l’utilisateur veut valider avant exécutionLe plan peut être présenté et modifié avant lancement
Projets de recherche / analyse en profondeurStructurer une investigation en phases logiques évite les oublis

❌ Quand NE PAS Utiliser

SituationPourquoi éviter
Questions simples / réponses factuellesSurcoû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équentielleSi tout peut se faire en parallèle → utilisez plutôt la Parallélisation
Contexte insuffisant pour planifierUn plan basé sur des hypothèses fausses fait plus de mal que de bien
💡 Test Simple : Si vous pouvez résoudre la tâche en un seul appel LLM avec un résultat satisfaisant, vous n’avez pas besoin de Planning. Posez-vous la question : « Cette tâche nécessite-t-elle plus de 2 étapes séquentielles distinctes ? » Si oui → Planning.

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 »
[Objectif : « Migre users vers schéma v3 »] │ ▼ PLANIFICATEUR │ ▼ Plan généré : 1. Analyser le schéma actuel (lecture DB) 2. Générer le script de migration DDL 3. Créer une table temporaire de backup 4. Exécuter la migration sur un environnement de test 5. Valider l’intégrité des données (checksums) 6. Appliquer en production avec rollback préparé │ ▼ EXÉCUTION SÉQUENTIELLE (chaque étape valide avant la suivante) │ ▼ ⟲ Si étape 5 échoue → re-planification (rollback + correction)

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 »
[Réclamation complexe multi-systèmes] │ ▼ PLANIFICATEUR │ ▼ Plan généré : 1. Extraire le numéro de commande et l’historique client (CRM) 2. Vérifier le statut de livraison (API transporteur) 3. Auditer les transactions (système facturation) 4. Identifier la double facturation 5. Générer le remboursement + avoir 6. Rédiger un email récapitulatif au client │ ▼ EXÉCUTION SÉQUENTIELLE (résultat de l’étape 2 alimente l’étape 4)

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 »
[Objectif : « Audit sécurité api.example.com »] │ ▼ PLANIFICATEUR │ ▼ Plan généré : 1. Scanner les ports ouverts et services exposés 2. Vérifier les certificats SSL/TLS 3. Tester les en-têtes de sécurité HTTP 4. Analyser les dépendances (CVE connues) 5. Vérifier la configuration d’authentification 6. Tester les endpoints pour injections SQL/XSS 7. Générer le rapport consolidé avec score de risque │ ▼ EXÉCUTION SÉQUENTIELLE (l’étape 1 détermine la surface d’attaque pour les étapes 5-6) │ ▼ ⟲ Si étape 4 trouve une CVE critique → re-planification : ajouter « vérifier l’exploitabilité »

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 :
[OBJECTIF] │ ▼ ┌──────────────┐ │ PLANIFICATEUR │─────────────────────────────┐ │ (Étape 1) │ │ └──────┬───────┘ │ │ Plan JSON │ ▼ │ ┌──────────────┐ │ │ BOUCLE FOR │ │ │ (Étape 2) │ │ └──────┬───────┘ │ │ │ ▼ │ ┌──────────────┐ Succès ┌──────────────┐ │ │ EXÉCUTEUR │───────────▶│ Étape suiv. │ │ │ (Étape 3) │ └──────────────┘ │ └──────┬───────┘ │ │ Échec │ ▼ │ ┌──────────────┐ Plan révisé │ │ RE-PLANIF. │──────────────────────────────┘ │ (Étape 4) │ └──────────────┘
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-PatternConséquenceSolution
Plan Fantôme : planifier mentalement sans produire de plan expliciteAucune traçabilité, impossible de débuguer ou de reprendreForcer la sortie JSON du plan avant toute exécution
Sur-planification : 20+ étapes pour une tâche simpleLatence explosive, coût LLM x10, perte de contexteLimiter à 8 étapes max, fusionner les micro-étapes
Plan Rigide : aucune adaptation possible en cours d’exécutionBlocage total au premier imprévuImplémenter la re-planification adaptative (Étape 4 du prompt)
Boucle Infinie : re-planifier sans fin après chaque échecCoût et latence incontrôlables, résultat jamais atteintCompteur 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étriqueCibleAlerte siSignification
Taux de plans exécutés sans re-planification≥ 75%< 50%La qualité de la planification initiale est insuffisante
Nombre moyen d’étapes par plan3-7> 10Sur-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≥ 3Le planificateur ne tient pas compte du contexte réel
Coût LLM moyen par plan completVariable> 3x le coût d’un appel uniqueTrop d’étapes ou modèle trop puissant utilisé pour des étapes simples
⚠️ Alerte critique : Si le taux de re-planification dépasse 40%, le problème n’est pas dans l’exécution mais dans la qualité du prompt de planification (Étape 1). Investissez dans un meilleur contexte et des exemples de plans réussis plutôt que dans une meilleure re-planification.

8. Récapitulatif

📌 En 3 Points Clés :
  1. 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.
  2. 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.
  3. 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
⚠️ Erreur Fréquente : Confondre « penser étape par étape » (chain-of-thought) avec le pattern Planning. Le chain-of-thought est un raisonnement interne en une seule passe. Le Planning produit un plan explicite et structuré, exécuté par un orchestrateur externe, avec possibilité de re-planification. Ce sont deux mécanismes fondamentalement différents.

Publications similaires