> ## Documentation Index > Fetch the complete documentation index at: https://docs.fim.ai/llms.txt > Use this file to discover all available pages before exploring further. # Paysage de la planification > Cinq types de planification dans le paysage des outils d'IA et où FIM One s'inscrit. ## 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 : | Approche | Format du plan | Exécution | Approbation | Valeur centrale | | -------------------------------------- | ------------------------------------------------ | -------------------------------------- | ---------------------------------------- | ------------------------------------------------- | | **Planification implicite du modèle** | Chaîne de pensée interne | Passe d'inférence unique | Aucune | Le modèle réfléchit aux étapes de lui-même | | **Mode plan Claude Code** | Document Markdown | Série | L'humain examine avant l'exécution | S'aligner sur l'approche avant de toucher au code | | **Claude Code Teams** | Liste de tâches avec arêtes de dépendance | **Concurrence** (multi-agent) | L'humain approuve le plan, puis autonome | Pool d'agents dynamique + exécution parallèle | | **Développement piloté par spec Kiro** | Spec structuré (exigences + conception + tâches) | Série | L'humain examine la spec | Exigences traçables, critères d'acceptation | | **FIM One DAG** | Graphe de dépendances JSON | **Concurrence** (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** : ```mermaid theme={null} flowchart TB subgraph L1["Layer 1: Human-in-the-Loop"] direction TB H["User approves plan / confirms direction"] subgraph L2["Layer 2: DAG Orchestration"] direction TB D1["Task graph with dependency edges"] D2["Parallel dispatch of independent branches"] D1 --> D2 subgraph L3A["Layer 3: ReAct Loop"] R1["Perceive → Reason → Act → Observe"] end subgraph L3B["Layer 3: ReAct Loop"] R2["Perceive → Reason → Act → Observe"] end subgraph L3C["Layer 3: ReAct Loop"] R3["Perceive → Reason → Act → Observe"] end D2 --> L3A & L3B & L3C end H --> L2 end ``` * **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é. | Dimension | Claude Code Teams | FIM One DAG | | -------------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | **Modèle parallèle** | Le Leader crée des SubAgents, assigne les tâches via messages | Tri topologique auto-parallélise les étapes indépendantes | | **Graphe de tâches** | TaskList avec arêtes `blockedBy` / `blocks` (DAG dynamique) | DAG JSON statique avec arêtes `depends_on` | | **Coordination** | Passage de messages explicite (SendMessage / Broadcast) | Arêtes de dépendance implicites — pas de messages, juste flux de données | | **Cycle de vie de l'Agent** | Pool dynamique — agents créés à la demande, arrêtés une fois terminés | Exécuteurs d'étapes fixes — un appel LLM par étape | | **Retour d'information et correction** | Chaque SubAgent réessaie de manière autonome ; le Leader réassigne en cas d'échec | PlanAnalyzer évalue les résultats → Boucle de Re-Planification (jusqu'à 3 tours) | | **Implication humaine** | Approbation du mode Plan, puis exécution autonome | Entièrement automatique — PlanAnalyzer décide de l'approbation/re-planification | | **Gestion du contexte** | Chaque 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 tokens** | `N 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'échelle** | Ajouter plus de SubAgents (horizontal, couplage par messages) | Ajouter plus de branches DAG (horizontal, couplage par dépendances) | | **Mieux adapté pour** | Tâ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 : | Niveau | Condition | Fonctionnement | | -------------- | ---------------------------- | --------------------------------------------------------------------------------- | | **FC natif** | `llm.abilities["tool_call"]` | Force un appel d'outil virtuel ; extrait de `tool_calls[0].arguments` | | **Mode JSON** | `llm.abilities["json_mode"]` | Définit `response_format={"type":"json_object"}`; analyse avec `extract_json()` | | **Texte brut** | toujours disponible | Analyse 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 : | Couche | Graphe défini par | Graphe existe quand ? | Idéal pour | | ----------------------------- | --------------------------------------------- | ---------------------- | ----------------------------------------------------------------------------------------------------------- | | **Moteur de flux de travail** | Utilisateur (canevas visuel / blueprint JSON) | Temps de conception | Processus déterministes, pistes d'audit/conformité, automatisation planifiée par cron, orchestration non-IA | | **DAGPlanner** | LLM (décompose automatiquement l'objectif) | Temps d'exécution | Tâches multi-étapes décomposables avec des limites de sous-tâches claires | | **Agent ReAct** | Aucun (boucle itérative) | Jamais — pas de graphe | Tâ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.