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