Passer au contenu principal

​
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 :
ApprocheFormat du planExécutionApprobationValeur centrale
Planification implicite du modèleChaîne de pensée internePasse d’inférence uniqueAucuneLe modèle réfléchit aux étapes de lui-même
Mode plan Claude CodeDocument MarkdownSérieL’humain examine avant l’exécutionS’aligner sur l’approche avant de toucher au code
Claude Code TeamsListe de tâches avec arêtes de dépendanceConcurrence (multi-agent)L’humain approuve le plan, puis autonomePool d’agents dynamique + exécution parallèle
Développement piloté par spec KiroSpec structuré (exigences + conception + tâches)SérieL’humain examine la specExigences traçables, critères d’acceptation
FIM One DAGGraphe de dépendances JSONConcurrence (orchestrateur unique)Automatique (PlanAnalyzer)Exécution parallèle + planification à l’exécution
Les deux premiers sont de la 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 de la 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 est 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 FIM One DAG peut planifier comment exécuter les sous-tâches en concurrence. Le mode plan de Claude Code garantit qu’un humain est d’accord avec l’approche ; le PlanAnalyzer de FIM One vérifie le résultat automatiquement.

​
Architecture à trois niveaux : L’architecture à pleine puissance

Claude Code Teams et FIM One DAG, à pleine capacité, présentent une architecture imbriquée à trois niveaux :
  • Niveau 1 — Contrôle humain : L’utilisateur examine le plan et l’approuve avant le début de l’exécution.
  • Niveau 2 — Orchestration DAG : Le plan approuvé est décomposé en tâches avec des arêtes de dépendance. Les tâches indépendantes s’exécutent en parallèle ; les tâches en aval attendent que leurs bloqueurs se résolvent.
  • Niveau 3 — Boucle ReAct interne : Chaque tâche est exécutée par un agent exécutant un cycle ReAct complet (Percevoir → Raisonner → Agir → Observer), capable de raisonnement multi-étapes, d’utilisation d’outils et de nouvelles tentatives autonomes.
L’idée clé : Claude Code Teams et FIM One DAG implémentent les trois mêmes niveaux, simplement avec des mécaniques de niveau 2 différentes — passage de messages vs résolution d’arêtes de dépendance.

​
Runtime Complet : FIM One vs Claude Code Teams

Les deux sont de véritables Agents — la boucle centrale est identique : Percevoir → Raisonner → Agir → Retour d’information. La différence réside dans la façon dont ils orchestrent le travail parallèle à pleine capacité.
DimensionClaude Code TeamsFIM One DAG
Modèle parallèleLe Leader crée des SubAgents, assigne les tâches via messagesTri topologique auto-parallélise les étapes indépendantes
Graphe de tâchesTaskList avec arêtes blockedBy / blocks (DAG dynamique)DAG JSON statique avec arêtes depends_on
CoordinationPassage de messages explicite (SendMessage / Broadcast)Arêtes de dépendance implicites — pas de messages, juste flux de données
Cycle de vie de l’AgentPool dynamique — agents créés à la demande, arrêtés une fois terminésExécuteurs d’étapes fixes — un appel LLM par étape
Retour d’information et correctionChaque SubAgent réessaie de manière autonome ; le Leader réassigne en cas d’échecPlanAnalyzer évalue les résultats → Boucle de Re-Planification (jusqu’à 3 tours)
Implication humaineApprobation du mode Plan, puis exécution autonomeEntièrement automatique — PlanAnalyzer décide de l’approbation/re-planification
Gestion du contexteChaque SubAgent obtient une fenêtre de contexte isolée (pas de contamination croisée)DbMemory partagée + LLM Compact sur toutes les étapes
Économie de tokensN agents × tokens par agent — temps↓ tokens↑ (coût multiplicatif)Séquentiel ou parallélisme peu profond — tokens totaux plus bas
Modèle de mise à l’échelleAjouter plus de SubAgents (horizontal, couplage par messages)Ajouter plus de branches DAG (horizontal, couplage par dépendances)
Mieux adapté pourTâches diverses et peu liées (recherche + code + test)Flux de travail structurés avec dépendances de données claires

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

Claude Code Teams a construit l’ensemble 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 d’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 des tokens. Claude Code Teams échange des dollars de calcul contre des heures de développeur.

​
Converger, non concurrencer

La frontière entre « collaboration d’équipe » et « planification 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 la planification topologique avec des étapes supplémentaires (messages).
  • Le DAG de FIM One pourrait bénéficier de l’autonomie des agents — au lieu d’appels LLM uniques par étape, laisser chaque étape exécuter une boucle ReAct complète gérerait mieux les sous-tâches complexes.
Conclusion : Même essence d’agent, philosophies parallèles convergentes. 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 planification de pipeline — un DAG Executor distribue les étapes en fonction de 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 les frais généraux de coordination (messages vs arêtes) et l’économie des tokens (contextes isolés vs mémoire partagée). L’architecture optimale combine probablement les deux : planification DAG pour les pipelines structurés, pools d’agents pour les tâches qui nécessitent un raisonnement multi-étapes autonome.

​
Dégradation de la sortie structurée

Tous les sites d’appel LLM structurés dans le pipeline DAG (Planificateur, Analyseur, Sélection d’outils) utilisent un utilitaire unifié structured_llm_call() qui implémente une chaîne de dégradation à 3 niveaux :
NiveauConditionFonctionnement
FC natifllm.abilities["tool_call"]Force un appel d’outil virtuel ; extrait de tool_calls[0].arguments
Mode JSONllm.abilities["json_mode"]Définit response_format={"type":"json_object"}; analyse avec extract_json()
Texte bruttoujours disponibleAnalyse le contenu libre avec extract_json(), puis regex_fallback() optionnel
Chaque niveau basé sur le texte réessaie une fois avec une invite de reformatage avant de passer au suivant. Le résultat est un StructuredCallResult contenant la valeur analysée, le niveau d’extraction qui a réussi et l’utilisation accumulée des jetons. Cette conception signifie que la même invite fonctionne de manière fiable sur GPT-4 (FC natif), Claude (mode JSON) et les modèles locaux (texte brut), avec une gestion des erreurs cohérente et une logique de nouvelle tentative en un seul endroit au lieu d’être dispersées sur quatre sites d’appel.

​
Trois couches d’exécution : Spectre de contrôle

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 — du contrôle humain total à l’autonomie complète de l’IA :
CoucheGraphe défini parGraphe existe quand ?Idéal pour
Moteur de flux de travailUtilisateur (canevas visuel / blueprint JSON)Temps de conceptionProcessus déterministes, pistes d’audit/conformité, automatisation planifiée par cron, orchestration non-IA
DAGPlannerLLM (décompose automatiquement l’objectif)Temps d’exécutionTâches multi-étapes décomposables avec des limites de sous-tâches claires
Agent ReActAucun (boucle itérative)Jamais — pas de grapheTâches exploratoires, conversationnelles ou d’affinement itératif
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 ? → Flux de travail.
  • Besoin de rechercher trois sujets en parallèle puis synthétiser ? → DAG.
  • Besoin de rédiger et affiner jusqu’à satisfaction ? → Agent.
  • Pas sûr ? → execution_mode: "auto" permet au LLM de classifier la requête et de router vers DAG ou ReAct à l’exécution.
Cette stratification est ce qui distingue FIM One des outils à paradigme unique :
  • Dify offre uniquement la couche Flux de travail (DAGs visuels statiques).
  • LangGraph offre uniquement un DSL de graphe au niveau du code (topologie définie par le développeur, routage dynamique — structurellement équivalent aux flux de travail visuels mais nécessitant Python).
  • Manus offre uniquement la couche Agent (exécution autonome, pas de structure définie par l’utilisateur).
FIM One couvre les trois couches, plus le routage automatique entre elles. La progression d’abstraction — graphe défini par l’utilisateur → graphe généré par LLM → pas de graphe du tout — reflète une tendance plus large de l’industrie : à mesure que les modèles deviennent plus capables, les structures d’orchestration explicites deviennent optionnelles plutôt que obligatoires.