Plan-and-Solve Prompting

1. Vue d'ensemble du concept et problème systémique

Lorsqu'un développeur confie une tâche d'ingénierie complexe à une IA (par exemple, « réécrire le module d'authentification de JWT vers des sessions en base de données »), la réaction impulsive de l'agent consiste souvent à modifier immédiatement un fichier au hasard.

Cette approche purement réactive engendre des dysfonctionnements critiques :

1. Violation de l'ordre des dépendances : L'agent modifie un composant d'interface avant d'avoir mis à jour le schéma de la base de données ou créé les types TypeScript nécessaires.
2. Corrections cycliques : Le modèle corrige une erreur, ce qui casse un autre fichier lié, et se retrouve piégé dans un cycle infini de corrections syntaxiques sans comprendre la vue d'ensemble.
3. Perte de l'objectif initial : Après 10 étapes de débogage, le contexte est saturé par les messages du compilateur, et le modèle oublie la demande initiale de l'utilisateur.

Plan-and-Solve résout ce problème grâce au principe classique d'ingénierie : la séparation entre la conception stratégique (Planning) et la réalisation tactique (Execution).

2. Taxonomie architecturale et modèle mental

Le pattern s'articule autour de trois phases complémentaires :

• 1. Phase de découverte et de planification (Discovery & Planner Phase) : L'agent analyse la requête, effectue une lecture préalable du système de fichiers (Read-Only) et génère un graphe d'actions clairement structuré : un tableau d'étapes spécifiant les objectifs, les critères de succès et les fichiers requis.
• 2. Phase d'exécution des étapes (Solver / Execution Phase) : Un exécutant spécialisé prend en charge le premier point ouvert du plan, appelle les outils nécessaires (édition de fichiers, lancement de builds), vérifie la sous-tâche accomplie et marque le point comme terminé.
• 3. Phase de replanification dynamique (Replanning & Feedback Phase) : Si une erreur survient lors de l'exécution d'une étape et qu'elle ne peut être résolue par une simple répétition (par exemple, détection d'un module manquant dans le système), le replanner révise les points restants du plan en ajoutant une étape pour installer les dépendances manquantes.

3. Pipeline technique et mécanique interne

Le cycle de vie selon le pattern Plan-and-Solve :

1. Plan Generation (Génération d'un plan structuré) : Le modèle produit un objet JSON valide contenant un tableau de tâches : tasks: [{ id: 1, title: "DB Schema", status: "pending" }, { id: 2, title: "API Route", status: "pending" }].
2. State Injection (Initialisation du tracker) : Le plan est injecté dans l'état de l'agent. L'utilisateur visualise la progression via une checklist interactive.
3. Execution Loop (Itération séquentielle) : L'orchestrateur sélectionne la prochaine tâche avec le statut pending. Le contexte est nettoyé des détails obsolètes de débogage, se concentrant uniquement sur la tâche courante et l'objectif final.
4. Invariant Check & Status Transition (Contrôle des invariants) : À la fin d'une étape, un linter ou un test unitaire est lancé. Si la vérification réussit, le statut passe à completed. Sinon, la méthode replan() est appelée pour ajuster les étapes non réalisées.

4. Scénarios d'ingénierie pratiques en production

01. Migration complexe de la base de code

Passage d'un projet Next.js Pages Router à App Router :

• Étape 1 : Audit de la structure du dossier pages/ et identification des Layouts communs.
• Étape 2 : Création du app/layout.tsx racine et des styles de base.
• Étape 3 : Transfert progressif des pages statiques.
• Étape 4 : Réécriture des routes dynamiques et des API Routes dans route.ts.
• Étape 5 : Build complet du projet et suppression des fichiers obsolètes.

02. Développement piloté par spécifications (Spec-Driven Development)

L'agent reçoit une exigence métier. Il rédige d'abord la documentation et les schémas Zod, les valide avec l'utilisateur, puis génère par étapes le backend, les hooks clients et les composants UI uniquement après approbation.

03. Déploiement infrastructure serveur

Durcissement progressif d'un VPS Linux :

• Génération d'un plan en 6 étapes (clés SSH, firewall UFW, fail2ban, mise à jour des paquets, création d'un utilisateur non-root, désactivation de l'accès par mot de passe).
• Chaque point est exécuté individuellement avec une vérification obligatoire de l'état du port avant de couper la méthode de connexion précédente.

5. Pièges, erreurs courantes et sécurité

• Planification prématurée (Premature Planning) : Élaborer un plan sans analyse préalable des fichiers du repository. Le modèle risque de prévoir l'utilisation de bibliothèques absentes du projet. Solution : imposer une phase « Discovery » avant le lancement du planificateur.
• Rigidité excessive du plan (Plan Rigidity) : L'agent tente obstinément d'exécuter l'Étape 3 alors que l'Étape 1 a révélé que l'architecture nécessite une approche fondamentalement différente. Implémentez impérativement des hooks de replanification dynamique.
• Micro-management sur 30 étapes : Des étapes trop granulaires (par exemple, une étape distincte pour chaque import de type) consomment temps et ressources financières inutilement. Maintenez le niveau d'abstraction au niveau des blocs fonctionnels logiques.