Skip to main content

​
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 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é.

​
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 : 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 : 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.