Pourquoi la planification dynamique est le juste milieu difficile
Le paysage des agents IA s’est divisé en deux camps, et les deux ont choisi la voie facile. Les moteurs de workflow traditionnels — Dify, n8n, Coze — ont opté pour l’orchestration statique : des organigrammes visuels glisser-déposer avec des chemins d’exécution fixes. Ce n’était pas de l’ignorance ; les clients d’entreprise exigent du déterminisme (même entrée, sortie stable), et les graphes statiques le garantissent. À l’extrême opposé, les agents entièrement autonomes (AutoGPT et ses descendants) promettaient une autonomie de bout en bout mais se sont avérés impraticables : décomposition des tâches peu fiable, coûts en tokens qui s’envolent, et comportement que personne ne pouvait prédire ou déboguer. Le juste milieu est étroit mais réel. Les tâches simples n’ont pas besoin de planificateur. Les tâches suffisamment complexes pour nécessiter des dizaines d’étapes interdépendantes submergent les LLM actuels. Mais entre les deux se trouve une riche classe de problèmes — des tâches avec des sous-tâches parallèles claires qui sont fastidieuses à coder en dur mais tractables pour qu’un LLM les décompose. La planification DAG dynamique cible exactement cette zone : le modèle propose le graphe d’exécution à l’exécution, le framework valide la structure et l’exécute avec une concurrence maximale. Pas de glisser-déposer, pas d’autonomie YOLO.Le pari sur l’amélioration des modèles
Tous les quelques mois, les fondations se déplacent — GPT-4, function calling, Claude 3, le protocole MCP. Construire une abstraction rigide sur un terrain mouvant est risqué ; la sur-abstraction de LangChain est l’histoire édifiante que tout le monde dans cet espace a intériorisée. FIM One adopte l’approche opposée : abstraction minimale, extensibilité maximale. Le framework gère l’orchestration, la concurrence et l’observabilité. L’intelligence provient du modèle, et le modèle s’améliore constamment. Aujourd’hui, la précision de la décomposition des tâches LLM se situe autour de 70-80% pour des objectifs non triviaux. Quand cela atteindra 90%+, la « zone optimale » pour la planification dynamique s’élargira considérablement — les problèmes qui étaient trop complexes hier deviennent tractables demain. Le framework DAG de FIM One est conçu pour capturer cette valeur croissante sans réécrire l’infrastructure.ReAct et la planification DAG deviendront-elles obsolètes ?
ReAct ne disparaîtra pas — il s’intégrera au modèle. Considérez l’analogie : vous n’écrivez pas manuellement les poignées de main TCP, mais TCP n’a pas disparu ; il a été absorbé par le système d’exploitation. Lorsque les modèles sont suffisamment puissants, la boucle penser-agir-observer devient un comportement implicite à l’intérieur du modèle, et non un code de framework explicite. C’est déjà en cours : Claude Code est essentiellement un agent ReAct où la boucle est pilotée par le modèle lui-même, et non par un harnais externe. La valeur durable de la planification DAG n’est pas « aider les modèles peu performants à décomposer les tâches » — c’est l’ordonnancement concurrent. Même avec des modèles infiniment capables, la physique impose une latence : une chaîne série de 10 appels LLM prend 10 fois plus de temps que 3 vagues parallèles. DAG est un problème d’ingénierie (comment exécuter les choses rapidement et de manière fiable), pas un problème d’intelligence (comment décider quoi exécuter). La logique de nouvelle tentative, le contrôle des coûts, la gestion des délais d’expiration, l’observabilité — ces éléments ne disparaissent pas lorsque les modèles deviennent plus intelligents. L’endgame : les modèles possèdent le « quoi » (l’intelligence de planification s’internalise dans le modèle), les frameworks possèdent le « comment » (concurrence, nouvelle tentative, surveillance, gouvernance des coûts). La valeur durable d’un framework n’est pas l’intelligence — c’est la gouvernance.Pourquoi ne pas reproduire l’éditeur de flux de travail de Dify
Une question naturelle : si DAG couvre le cas flexible, ne devrions-nous pas aussi construire un éditeur de flux de travail statique pour le cas déterministe ? Non. Les raisons :- Les flux de travail existent déjà ailleurs. Les processus fixes des clients gouvernementaux et d’entreprise vivent dans leurs systèmes OA, ERP et hérités. Ils ne veulent pas reconstruire ces flux dans encore une autre plateforme — ils veulent une IA qui peut se connecter aux systèmes où ces flux s’exécutent déjà. La Plateforme de Connecteurs (v0.6) résout cela directement.
- Les capacités existantes se composent en pipelines fixes. Les Tâches Planifiées (v1.0) déclenchent un agent DAG avec une invite fixe ; le DAG planifie dynamiquement les étapes ; les Connecteurs (v0.6) se connectent aux systèmes cibles. La combinaison équivaut à un pipeline statique — mais plus flexible, car le LLM peut ajuster son plan en fonction des données qu’il rencontre. Aucun DSL de pipeline séparé nécessaire.
- Décalage d’investissement. Un éditeur de flux de travail visuel de qualité production (canevas, types de nœuds, passage de variables, débogage/relecture) représente des mois d’effort dédié. Le résultat serait une copie de faible fidélité de ce que la communauté de 120K étoiles de Dify maintient déjà. Cet effort est mieux dépensé sur l’architecture des Connecteurs — une capacité qu’aucun concurrent n’offre.
Où FIM One se positionne
FIM One n’est pas un “planificateur de tâches AGI” et pas un moteur de flux de travail statique. Il occupe le juste milieu : capacité de planification avec contraintes, concurrence avec observabilité.- Comparé à Dify : plus flexible — génération de DAG à l’exécution par rapport aux organigrammes au moment de la conception. Vous n’avez pas besoin d’anticiper chaque chemin d’exécution à l’avance. Ne concurrence pas sur l’édition visuelle de flux de travail ; concurrence sur l’intégration des systèmes existants.
- Comparé à AutoGPT : plus contrôlé — itérations bornées, limites de re-planification, avec l’intervention humaine sur la feuille de route. Autonomie dans des garde-fous.
Où FIM One se situe : Spectre Planification × Exécution
Le paysage de l’exécution IA peut être cartographié sur deux axes — comment les plans sont créés (statique vs dynamique) et comment ils sont exécutés (rigide vs adaptatif) : Pourquoi Dify/n8n sont Planification Statique + Exécution Statique : Le DAG est dessiné par un humain sur un canevas visuel au moment de la conception. Chaque nœud exécute une opération fixe (un appel LLM avec une invite fixe, une requête HTTP, un bloc de code). Il n’y a pas de replanification à l’exécution — si une étape échoue, le flux de travail échoue ou suit une branche d’erreur pré-câblée. C’est structurellement identique à BPM, juste avec des nœuds IA dans le graphe. Position de FIM One : Planification Dynamique + Exécution Dynamique- La topologie du DAG est générée par LLM à l’exécution (planification dynamique) — aucun humain ne conçoit le graphe
- Chaque nœud du DAG exécute une boucle ReAct complète (exécution dynamique) — les nœuds raisonnent, utilisent des outils et s’adaptent
- Mécanisme de replanification (exécuter → analyser → replanifier si insatisfait)
- Mais borné : maximum 3 cycles de replanification, budgets de tokens, portes de confirmation humaine
Glossaire des concepts
Pour les lecteurs non familiers avec la terminologie utilisée dans ce document :| Terme | Explication en une ligne | Relation avec FIM One |
|---|---|---|
| BPM (Business Process Management) | Processus entièrement fixés au moment de la conception, exécutés de manière rigide. Camunda, Activiti. | FIM One n’est pas BPM. Pas de moteur de processus fixe. |
| FSM (Finite State Machine) | Le système est dans exactement un état à tout moment ; les événements déclenchent des transitions. Supporte les boucles (rejet → renvoi). | Les systèmes cibles (ERP, systèmes de contrats) utilisent FSM en interne. FIM One n’a pas besoin de son propre FSM — il appelle l’API du système cible. |
| ACM (Adaptive Case Management) | Squelette statique, branches dynamiques. Flux principal prédéfini, chaque nœud s’adapte à l’exécution. | Le DAG + ReAct de FIM One s’inscrit naturellement dans ce quadrant. |
| HTN (Hierarchical Task Network) | Décomposition récursive des tâches : haut niveau → sous-tâches → opérations atomiques. | La replanification DAG couvre la plupart des scénarios ; HTN complet pas encore nécessaire. |
| iPaaS (Integration Platform as a Service) | Plateforme d’intégration cloud connectant plusieurs systèmes SaaS/on-prem. MuleSoft, Zapier. | Le Mode Hub de FIM One est comme une iPaaS native IA — le langage naturel pilote l’intégration entre systèmes. |
Limite architecturale : FIM One ne réplique pas la logique de flux de travail
Les processus métier complexes (chaînes d’approbation, transferts, rejets, escalade, cosignature, contresignature) sont la responsabilité du système cible. Ces systèmes ont passé des années à construire cette logique — les ERP, les systèmes OA, les systèmes de gestion de contrats ont tous des machines d’état matures. Du point de vue du Connecteur :| Opération | Ce que fait le Connecteur |
|---|---|
| Transfert | Appeler une API, passer la personne cible |
| Rejet | Appeler une API, passer la raison du rejet |
| Escalade | Appeler une API, passer la liste des personnes d’escalade |
| Cosignature | Appeler une API, passer la liste des cosignataires |
- Une charge de maintenance (deux machines d’état à maintenir synchronisées)
- Des modes de défaillance supplémentaires (et si elles ne concordaient pas ?)
- Aucune valeur supplémentaire (le système cible le fait déjà correctement)