Architecture IA

Planner & Agentic Planning

Dans une architecture agentique, le Planner est le composant qui transforme une demande utilisateur en plan d’exécution. C’est moins spectaculaire qu’un chatbot, mais c’est souvent là que se joue la robustesse d’une plateforme IA d’entreprise.

PlannerTool CallingLangGraphWorkflowsAudit

L’idée générale

Un LLM peut répondre directement à une question simple. Mais dès que la demande nécessite plusieurs étapes, plusieurs sources ou plusieurs outils, il faut lui éviter d’improviser. Le rôle du Planner est alors de produire une stratégie explicite : quoi chercher, dans quel ordre, avec quels outils, et avec quels contrôles.

Je le vois comme un chef d’orchestre : il ne remplace ni le retriever, ni le moteur SQL, ni le Knowledge Graph, ni le solveur de recherche opérationnelle. Il décide quand et comment les mobiliser.

Le bon Planner ne cherche pas à rendre l’IA autonome à tout prix. Il rend l’exécution lisible, bornée, traçable et contrôlable.

Niveaux de maturité

Niveau	Approche	Usage	Limite
1	Prompt unique	Qualification simple de la demande	Peu robuste, difficile à auditer
2	Planner JSON	Plan structuré exécuté par le backend	Nécessite validation stricte du schéma
3	Tool Calling	Appels contrôlés à des outils métiers	Peut devenir opaque si mal tracé
4	LangGraph / State Machine	Workflows complexes, reprises, branches	Demande un vrai design d’architecture
5	DSL métier	Plans lisibles, rejouables, auditables	Investissement initial plus élevé
6	Multi-Agent Planner	Coordination d’agents spécialisés	Risque de complexité et de coût

Schéma d’orchestration

flowchart TB U[Utilisateur] --> Q[Analyse de la demande] Q --> P[Agent Planner] P --> Plan[Plan d'exécution] Plan --> R[Tool Router] R --> RET[Hybrid Retriever] R --> SQL[SQL Agent] R --> KG[Knowledge Graph Agent] R --> API[API Agent] R --> OR[Optimization Agent / RO] RET --> M[Merge des résultats] SQL --> M KG --> M API --> M OR --> M M --> C[Critic / Reflection] C --> V[Validator] V --> A[Answer Composer] A --> L[LLM Gateway] L --> O[Réponse sourcée] P -. trace .-> OBS[Observabilité / Audit] R -. trace .-> OBS C -. trace .-> OBS V -. trace .-> OBS

Implémentation avec LangGraph

LangGraph est adapté lorsqu’on veut sortir d’une chaîne linéaire. Chaque étape devient un nœud : planner, router, retriever, SQL, graph, critic, validator, answer composer. Le graphe peut contenir des conditions, des boucles, des reprises et des points de validation humaine.

Cette approche est particulièrement intéressante en entreprise parce qu’elle permet de tracer les décisions. On sait pourquoi le système a choisi un outil, pourquoi il a relancé une recherche et pourquoi il a considéré le contexte suffisant.

Planner JSON / DSL

Une façon pragmatique de commencer consiste à demander au Planner de produire un plan JSON validé par le backend.

goal: Répondre à une question juridique avec sources
steps:
  - tool: query_analyzer
    input: question utilisateur
  - tool: hybrid_retriever
    query: concepts juridiques détectés
  - tool: knowledge_graph
    query: renvois, exceptions, jurisprudence
  - tool: reranker
    top_k: 8
  - tool: critic
    check: sources suffisantes
  - tool: answer_composer
    format: réponse sourcée

Pour des systèmes plus industriels, on peut aller vers un DSL métier. L’intérêt est de rendre les plans plus stables, testables et rejouables.

ANALYZE_INTENT()
SEARCH(corpus="legal", mode="hybrid")
EXPAND_GRAPH(relations=["RENVOI", "EXCEPTION", "JURISPRUDENCE"])
RERANK(top_k=8)
VALIDATE(criteria=["groundedness", "coverage", "citations"])
ANSWER(style="expert", sources=true)

Gouvernance et sécurité

Le planning agentique doit être gouverné comme un composant critique. Un plan d’exécution peut exposer des données, déclencher des actions ou produire une réponse utilisée dans un contexte métier sensible.

Sujet	Contrôle recommandé
Traçabilité	Journaliser le plan, les outils appelés, les paramètres et les résultats intermédiaires.
Sécurité	Appliquer RBAC / ABAC avant chaque appel outil, pas seulement au début de la session.
Coût	Limiter les boucles, fixer un budget token, utiliser cache et fallback modèle.
Qualité	Contrôler groundedness, complétude, citations, contradictions.
Conformité	Tracer les décisions, conserver les prompts et permettre le replay des exécutions.

Exemples de plans

Cas juridique

Question : “Un salarié licencié pour faute grave a-t-il droit à un préavis ?”

1. Identifier les concepts : licenciement, faute grave, préavis.
2. Rechercher les articles applicables.
3. Suivre les renvois juridiques et exceptions.
4. Ajouter jurisprudence et doctrine.
5. Vérifier que la réponse couvre règle générale + exception.
6. Produire une réponse sourcée.

Cas assurance

Question : “Ce sinistre est-il couvert par le contrat ?”

1. Identifier contrat, garantie, exclusion, franchise.
2. Interroger la base contrat via SQL.
3. Rechercher les clauses pertinentes via RAG.
4. Comparer faits déclarés et conditions de couverture.
5. Vérifier exclusions et plafonds.
6. Générer une décision explicable.

Cas recherche opérationnelle

Question : “Optimise les tournées des techniciens demain.”

1. Charger techniciens, compétences, disponibilités.
2. Charger interventions, lieux, SLA.
3. Construire le problème d’optimisation.
4. Appeler OR-Tools / Gurobi.
5. Vérifier contraintes non satisfaites.
6. Expliquer le planning et les arbitrages.

Position d’architecte

Dans une plateforme IA d’entreprise, je privilégie un planning explicite : le système produit un plan lisible, validable et rejouable avant d’exécuter les outils. Cela rend l’agentique compatible avec les contraintes de production : audit, sécurité, coût, qualité et gouvernance.

← Agentic AI Chunking →