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.
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
Converger, non concurrencer
La frontière entre « collaboration d’équipe » et « planification de pipeline » s’estompe :- Les
blockedBy/blocksde 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.
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 le 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 d’erreur cohérente et une logique de nouvelle tentative au même endroit au lieu d’être dispersées sur quatre sites d’appel.