Paysage de planification

​

Graph engineering (2026) et FIM One

Les discussions sectorielles encadrent souvent un passage du loop engineering (un seul agent pensant et agissant de manière répétée) au graph engineering (faire de la topologie multi-nœuds un objet d’ingénierie explicite). L’étiquette est nouvelle ; la pratique ne l’est pas. Les systèmes de style LangGraph et les organisations multi-agents utilisent les graphes depuis des années. Ce qui importe pour FIM One, c’est le type de graphe dont les gens parlent, et comment cela s’inscrit dans nos trois couches d’exécution.

​

Ce que l’ingénierie de graphe signifie généralement

Consensus sur ce cadre : le graphe ne remplace pas la boucle. Les designs de graphe conçoivent les relations entre processus ; chaque nœud agentique peut toujours exécuter une boucle complète. « Graph » est surchargé en pratique. Trois usages se mélangent : Cette page traite des deux premiers (orchestration).

​

Pas « Dify Workflow avec un nouveau nom »

Les workflows visuels de style Dify et l’ingénierie de graphes partagent une origine commune (topologie explicite) mais ce ne sont pas le même produit. Forme courte : le Workflow classique est un tuyau déterministe (ou semi-déterministe) avec des étapes LLM occasionnelles. L’ingénierie de graphes est une topologie système multi-nœuds, où les postes critiques peuvent toujours être des agents autonomes.

​

Comment la carte industrielle s’inscrit dans FIM One

FIM One couvre déjà l’ensemble du spectre de contrôle ; le mode « Planner » du chat n’en est qu’une tranche.

​

Ingénierie de graphe vs DAG FIM One (Planner de chat)

Même famille (topologie multi-étapes explicite). Espèces différentes. Implication : la chaleur industrielle autour de l’ingénierie de graphe valide le maintien d’un moteur de graphe/planification. Elle ne nécessite pas un défaut de chat qui force les utilisateurs à choisir « Planner » à chaque tour. La plupart des tâches veulent toujours une boucle forte ; les graphes se justifient sur les branches parallèles, les chemins de conformité fixes et l’orchestration multi-rôles.

​

Ce que FIM One peut apprendre (renforcer ReAct, DAG, Workflow)

Des enseignements concrets, pas des slogans. Ordonnés par impact. Anti-motifs à éviter lors de « l’utilisation de graphe » :

• Utiliser un graphe de dépendances pour simuler une machine d’état humaine (« attendre les réponses » multi-étapes sans primitive d’attente).
• Assimiler update_plan ReAct (mémoire de liste de contrôle) à l’ingénierie de graphe (topologie de planification).
• Livrer la chaleur du graphe comme une deuxième personnalité de chat au lieu de comme composition de moteur (boucle à l’extérieur, planification à l’intérieur si nécessaire).
• Décrire les étapes DAG de FIM One comme « appels LLM peu profonds » : cela sous-estime le moteur et induit les décisions produit en erreur.

​

Cinq types de « planification » dans le paysage des outils IA

Le mot « planification » est surchargé. Au moins cinq approches distinctes existent aujourd’hui, et elles résolvent des problèmes différents : Les deux premiers sont une planification au moment de la conception — ils produisent un plan avant que le travail ne commence, et un humain (ou le modèle lui-même) le suit étape par étape. Les trois derniers introduisent une planification à l’exécution — les graphes d’exécution sont générés et planifiés par programmation, avec des branches indépendantes s’exécutant en parallèle. La différence réside dans qui exécute : Claude Code Teams lance des agents autonomes ; FIM One DAG distribue les étapes au sein d’un orchestrateur unique. Ces approches ne sont pas des concurrentes ; ce sont des couches complémentaires. Une spec de style Kiro peut définir quoi construire, tandis qu’un DAG FIM One peut planifier comment exécuter les sous-tâches en concurrence. Le mode plan de Claude Code garantit qu’un humain accepte l’approche ; PlanAnalyzer de FIM One vérifie le résultat automatiquement.

​

Three-Layer Nesting: The Full-Power Architecture

Both Claude Code Teams and FIM One DAG, at full capacity, exhibit a three-layer nested architecture:

• Layer 1 — Human gate: User reviews the plan and approves before execution begins.
• Layer 2 — DAG orchestration: The approved plan is decomposed into tasks with dependency edges. Independent tasks run in parallel; downstream tasks wait for their blockers to resolve.
• Layer 3 — ReAct inner loop: Each task is executed by an agent running a full ReAct cycle (Perceive → Reason → Act → Observe), capable of multi-step reasoning, tool use, and autonomous retry.

The key insight: Claude Code Teams and FIM One DAG implement the same three layers, just with different Layer 2 mechanics — message-passing vs dependency-edge resolution.

​

Full-Power Runtime: FIM One vs Claude Code Teams

Both are genuine Agents — the core loop is identical: Perceive → Reason → Act → Feedback. The difference lies in how they orchestrate parallel work at full capacity.

​

Benchmark réel : Système RAG v0.5

Claude Code Teams a construit l’intégralité du sous-système RAG v0.5 de FIM One en une seule session :

• 8 phases : Embedding → Reranker → Loaders → Chunking → VectorStore → Retrieval → KB Backend → Frontend + Docs
• 46 tests réussis, build frontend propre
• Temps écoulé : ~5 minutes
• Coût en tokens : ~100k tokens par tâche agent × 8+ tâches ≈ 800k+ tokens au total
• Arêtes de dépendance : Phase 5 dépend de Phase 4 + 1b ; Phase 6 dépend de Phase 5 + 2 + 3 — un véritable DAG

Cela démontre le compromis fondamental : parallélisme temporel au prix d’une multiplication de tokens. Claude Code Teams échange des dollars de calcul contre des heures de développeur.

​

Converger, pas concurrencer

La frontière entre « collaboration d’équipe » et « ordonnancement de pipeline » s’estompe :

• Les blockedBy/blocks de Claude Code Teams SONT un DAG — les tâches ont des arêtes de dépendance explicites, et le leader distribue les tâches nouvellement débloquées à mesure que les prédécesseurs se terminent. C’est de l’ordonnancement topologique avec des étapes supplémentaires (messages).
• Les étapes DAG de FIM One sont déjà des agents ReAct complets — la couche 3 n’est pas aspirationnelle. Chaque étape exécute agent.run() avec des outils et des boucles multi-itérations ; les différences par rapport à un tour de chat ReAct de haut niveau sont délibérées (pas de tableau de plan par étape, pas d’attente ask_user_question au niveau du chat, modèle choisi par model_hint / défaut général).

Conclusion : Même essence d’agent, philosophies parallèles convergeant. Claude Code suit un modèle de collaboration d’équipe — un Leader délègue aux Workers qui communiquent via des messages. FIM One suit un modèle de ordonnancement de pipeline — un Exécuteur DAG distribue des étapes ReAct basées sur la résolution des dépendances. En pratique, les deux implémentent l’exécution parallèle pilotée par les dépendances ; la différence réside dans la surcharge de coordination (messages vs arêtes), l’isolation (agents pairs vs tâche + résultats de dépendance), et l’économie de tokens. L’écart produit est moins « transformer les nœuds en agents » et plus quand ordonnancer un graphe vs rester dans une boucle de chat unique, plus les arêtes d’attente humaine où le graphe ne peut pas se mettre en pause.

​

Structured Output Degradation

All structured LLM call sites in the DAG pipeline (Planner, Analyzer, Tool Selection) use a unified structured_llm_call() utility that implements a 3-level degradation chain: Each text-based level retries once with a reformat prompt before falling to the next. The result is a StructuredCallResult containing the parsed value, which extraction level succeeded, and accumulated token usage. This design means the same prompt works reliably across GPT-4 (native FC), Claude (JSON mode), and local models (plain text), with consistent error handling and retry logic in one place instead of scattered across four call sites.

​

Three Execution Layers: Control Spectrum

Les cinq approches de planification ci-dessus décrivent le paysage. Au sein de FIM One lui-même, trois couches d’exécution offrent un spectre de contrôle allant du contrôle humain total à l’autonomie complète de l’IA. Par rapport à l’ingénierie de graphes : Workflow est le produit de graphe au moment de la conception ; DAGPlanner est un graphe de tâches à l’exécution ; ReAct est l’ingénierie de boucles (avec mémoire optionnelle du plan-board, pas un graphe d’ordonnancement). Le principe de conception : donner aux utilisateurs exactement autant de contrôle qu’ils le souhaitent.

• Besoin de prouver que chaque approbation de prêt passe par cinq étapes spécifiques ? → Workflow.
• Besoin de rechercher trois sujets en parallèle puis synthétiser ? → DAG.
• Besoin de rédiger, affiner ou poser des questions structurées en cours d’exécution ? → ReAct.
• Pas sûr ? → execution_mode: "auto" classe la requête et l’achemine vers DAG ou ReAct à l’exécution (préférer ReAct quand l’objectif est principalement la clarification ou l’exploration courte).

Cette stratification est ce qui distingue FIM One des outils monolithiques :

• Dify met l’accent sur la couche Workflow (graphes visuels statiques ou semi-statiques).
• LangGraph met l’accent sur un DSL de graphe de flux de contrôle au niveau du code (topologie définie par le développeur, routage dynamique, points de contrôle). Structurellement lié aux workflows visuels, exprimé sous forme de logiciel.
• Les agents de classe Manus mettent l’accent sur la couche Agent/boucle (exécution autonome, peu de structure définie par l’utilisateur).

FIM One couvre les trois couches, plus le routage automatique entre les moteurs de chat. La progression graphe défini par l’utilisateur → graphe de tâches généré par LLM → pas de graphe d’ordonnancement correspond à une honnêteté plus large de l’industrie : à mesure que les modèles s’améliorent, la topologie explicite devient optionnelle pour la plupart des tours, pas obligatoire dans l’interface utilisateur. La chaleur de l’ingénierie de graphes est une raison d’investir dans les moteurs et la composition, pas de forcer chaque chat à travers un planificateur.

​

Documentation connexe

• Moteur ReAct — boucle, outils, tableau de planification, questions de clarification
• Moteur DAG — planificateur, exécuteur, analyseur, replanification
• Paysage concurrentiel — positionnement de Dify / Manus / Coze