Philosophie

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.

​

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 :

1. 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.
2. 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.
3. 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.

Le pari stratégique : ne pas concurrencer sur la visualisation de flux de travail ; concurrencer en étant le hub où les systèmes rencontrent l’IA. Laissez Dify posséder « construire des flux de travail IA visuellement ». FIM One possède « le hub où vos systèmes rencontrent l’IA ».

​

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.

La stratégie est simple : construire le cadre d’orchestration maintenant, et laisser les modèles en amélioration le remplir de capacités au fil du temps.

​

Où FIM One se situe : Spectre Planification x 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 workflow é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 limité : max 3 rounds de replanification, budgets de tokens, portes de confirmation humaine

Cela place FIM One dans le même quadrant qu’AutoGPT, mais avec des contraintes d’ingénierie qui préviennent les comportements incontrôlés. Plus flexible que BPM/Dify, plus contrôlé qu’AutoGPT.

​

Glossaire des concepts

Pour les lecteurs peu familiers avec la terminologie utilisée dans ce document :

​

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, escalades, 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 : Chaque opération de flux de travail complexe se réduit à une requête HTTP avec des paramètres. FIM One appelle l’API ; le système cible gère la machine d’état. C’est une limite architecturale délibérée, pas une lacune en matière de capacités. Dupliquer la logique de flux de travail qui existe déjà dans les systèmes cibles entraînerait :

1. Une charge de maintenance (deux machines d’état à maintenir synchronisées)
2. Des modes de défaillance supplémentaires (et si elles ne concordaient pas ?)
3. Aucune valeur ajoutée (le système cible le fait déjà correctement)

Le modèle de connecteur est simple par conception : une opération = un appel API.

​

Architecture Boundary: Connector Layer, Not Context Layer

Enterprise AI is converging on a layered architecture for agent context: FIM One operates at the data connectivity layer. It does not attempt to build the entity context layer above it. This is a deliberate choice, not a gap.

​

Contexte industriel : la consolidation 2025-2026

Deux acquisitions majeures ont remodelé le paysage des données d’IA d’entreprise et ont fait de la couche de contexte un enjeu stratégique :

• Salesforce a acquis Informatica (novembre 2025) — ajoutant la gestion des données de référence d’entreprise et la gouvernance des données à sa pile Data Cloud + Agentforce. L’objectif : rendre les agents Agentforce fiables en les ancrant dans les enregistrements de référence d’Informatica.
• SAP a annoncé l’acquisition de Reltio (mars 2026) — ajoutant la résolution d’entités native à l’IA et les graphes de relations à son Business Data Cloud (BDC). L’objectif : créer un « Système de Contexte » qui s’étend aux environnements SAP et non-SAP, servant de fondation fiable pour les Agents Joule.

Ces mouvements signalent que les plus grandes plates-formes d’entreprise du monde considèrent désormais le contexte d’entité unifié comme un prérequis pour des agents d’IA fiables — pas seulement un plus.

​

Spectre de propriété des données × profondeur du contexte

Lecture du graphique :

• Bas-gauche (Connecteur léger) : propriété minimale des données, connectivité API brute. Dify, n8n et les serveurs MCP de base se situent ici — ils se connectent aux systèmes mais ne comprennent pas les entités. FIM One se trouve dans ce quadrant mais plus haut sur l’axe des y en raison des méta-outils à divulgation progressive, de l’agrégation de contexte basée sur les compétences et de l’escalade consciente du domaine.
• Haut-gauche (Hub conscient du contexte) : accès fédéré avec compréhension au niveau des entités. Salesforce Data Cloud en est un exemple — fédération sans copie avec résolution d’entités à la demande. DataHub fournit un contexte au niveau des métadonnées (schéma, lignage, propriété) sans posséder les données métier.
• Haut-droit (Plateforme ontologie profonde) : ingestion complète des données avec intelligence d’entités profonde. SAP BDC + Reltio construit des enregistrements maîtres multi-domaines persistants avec des graphiques de relations. Palantir va le plus loin — ontologie à trois niveaux avec lignage des décisions.
• Bas-droit (Entrepôt de données / Lac) : stockage centralisé des données sans sémantique d’entités. Les plateformes de données traditionnelles qui ingèrent tout mais manquent de résolution d’entités ou de modélisation des relations.

La position de FIM One reflète un choix délibéré : rester fédéré et léger, mais investir dans l’accessibilité du contexte d’entités en amont (de tout MDM) aux agents.

​

Trois modèles pour le contexte d’entité

SAP : dossier unique multi-domaines (copie + gouvernance) SAP construit une architecture d’entreprise à trois niveaux : Reltio se situe au cœur de la couche intelligence. Son rôle : ingérer les données d’entités provenant de systèmes SAP et non-SAP, résoudre les doublons via un appariement basé sur l’IA, et produire des dossiers uniques multi-domaines (client, fournisseur, produit, patient, actif) avec des graphes de relations. L’adoption précoce du protocole MCP par Reltio est stratégiquement significative — elle positionne les dossiers uniques comme directement appelables par n’importe quel agent compatible MCP, pas seulement par Joule, le propre agent de SAP. Le pari de SAP : les agents ont besoin d’une « source unique de vérité » persistante, gouvernée et inter-domaines pour fonctionner de manière fiable dans les processus d’entreprise critiques. Salesforce : fédération sans copie (fédérer + résoudre à la demande) Salesforce adopte une approche plus légère. Data Cloud ne nécessite pas de mouvement physique de données ; au lieu de cela, il utilise des partenariats sans copie (Databricks, Snowflake, BigQuery) pour fédérer les données sur place. La résolution d’entités se fait à la demande dans Data Cloud, créant des profils clients unifiés sans magasin de dossier unique persistant. Chiffres clés (Q3 FY2026) : Data Cloud a ingéré 32 billions d’enregistrements, dont 15 billions via une approche sans copie (croissance de 341 % en glissement annuel). Cette échelle valide le modèle de fédération pour les cas d’usage centrés sur la CRM. Les agents Agentforce sont ancrés dans ce contexte fédéré : ils raisonnent sur l’ensemble distribué de données sans nécessiter que toutes les données arrivent dans un seul système. Pour les scénarios front-office (ventes, service, marketing), c’est flexible et rapide à déployer. Le pari de Salesforce : les agents n’ont pas besoin d’un magasin de dossier unique lourd — ils ont besoin d’un accès en temps réel à un contexte fédéré et résolu là où il existe déjà. Palantir : ontologie approfondie (la référence lourde) À l’extrême, Palantir Foundry ingère toutes les données et construit une ontologie à trois niveaux (objets sémantiques + actions cinétiques + règles dynamiques) avec une traçabilité complète des décisions. C’est le système de contexte le plus complet en production, mais à des contrats de 10 M$ et plus et des déploiements de 6 à 18 mois. Il sert de architecture de référence, pas de modèle réaliste pour la plupart des organisations.

​

Où FIM One s’inscrit

FIM One s’aligne le plus étroitement avec la philosophie Salesforce (ne pas posséder les données, s’y connecter) mais sans la dépendance à l’écosystème Salesforce. La position stratégique : être agnostique des fournisseurs au niveau de la couche de connectivité, et laisser n’importe quel MDM — qu’il s’agisse de SAP/Reltio, Salesforce/Informatica, Tamr, ou une solution personnalisée — servir de source de contexte d’entité.

​

Pourquoi FIM One reste à la couche connecteur

Construire une couche de contexte d’entité nécessite un stockage de données persistant, une résolution d’entité basée sur le ML, des règles de survivance, des moteurs de graphe de relations et des cadres de gouvernance. C’est une catégorie de produit distincte (MDM) avec une concurrence approfondie depuis une décennie (Reltio, Informatica, Tamr). Tenter de le faire :

1. Transformerait FIM One d’un connecteur en plateforme de données — produit, équipe et stratégie de mise sur le marché fondamentalement différents
2. Dupliquerait les capacités que les systèmes en amont fournissent déjà — le même anti-pattern que nous évitons avec la logique de flux de travail
3. Augmenterait le verrouillage — une fois que les utilisateurs stockent les enregistrements de référence dans FIM One, les coûts de changement augmentent considérablement

La stratégie correcte : être le meilleur point d’entrée pour tout système MDM, pas un remplacement pour un. FIM One devrait rendre trivial pour Reltio, Informatica, Tamr ou un MDM personnalisé de servir le contexte d’entité aux agents — via MCP Resources, les APIs de connecteur ou l’injection de base de connaissances.

​

Approche actuelle : les compétences comme agrégation de contexte légère

Pour les scénarios nécessitant un contexte multi-connecteur (par exemple, un examen de contrat nécessitant des données de fournisseur + historique de paiement + indicateurs de risque), les compétences fournissent déjà une solution pragmatique. Le SOP d’une compétence peut orchestrer plusieurs actions de connecteur en séquence, agréger les résultats et présenter un contexte structuré à l’agent — sans construire une couche d’entité persistante. Cela couvre le cas à 80%. Si la demande émerge pour une résolution d’entité en temps réel au niveau du connecteur, l’architecture laisse de la place pour un futur type de connecteur ContextSource qui s’intègre avec des systèmes MDM externes — mais c’est une considération future, pas un engagement actuel.

​

L’analogie

La relation de FIM One à la couche de contexte est comme la relation de SQLAlchemy à la base de données : elle ne stocke ni ne gère les données, mais elle rend n’importe quelle source de données accessible à la couche application. Laissez les plateformes MDM posséder la résolution d’entités ; laissez FIM One posséder la connexion.

​

Où FIM One s’inscrit dans la pile IA

​

Le Modèle en Couches

Un modèle mental utile (crédit Phil Schmid) mappe les systèmes d’IA à une pile à quatre couches analogue au matériel informatique : FIM One opère au niveau du harnais — il ne concurrence pas les modèles ; il les rend productifs en fournissant les bons outils, contraintes et boucles de rétroaction. Le modèle fournit l’intelligence ; le harnais fournit la gouvernance, la concurrence et la fiabilité.

​

Trois ères de l’ingénierie de l’IA

La discipline a évolué à travers des phases distinctes : l’ingénierie des prompts s’est concentrée sur la formulation de meilleures instructions pour obtenir le comportement correct d’un modèle fixe. L’ingénierie du contexte a déplacé l’attention vers l’assemblage des bonnes informations — récupération de documents, injection de résultats d’outils, gestion de la mémoire — afin que le modèle dispose de ce dont il a besoin pour raisonner correctement. L’ingénierie de l’orchestration va plus loin : concevoir l’environnement d’exécution complet autour du modèle, y compris les garde-fous déterministes, l’orchestration des outils, les boucles de rétroaction et les contrôles de coûts. L’architecture de FIM One incarne les principes de l’ingénierie de l’orchestration. Le Hook System exécute le code de la plateforme en dehors de la boucle LLM à des points de cycle de vie bien définis — aujourd’hui FeishuGateHook intercepte les appels d’outils sensibles et achemine l’approbation via un canal IM, et la même abstraction est le foyer prévu pour la journalisation d’audit, l’application du mode lecture seule, les limites de débit et la troncature des résultats en v0.9. ContextGuard gère ce qui entre dans la fenêtre de contexte et quand. La sélection dynamique des outils (méta-outils à divulgation progressive) maintient la surface des outils traitable à mesure que le nombre de connecteurs augmente. Le mécanisme d’auto-réflexion de la boucle ReAct et le cycle de re-planification du planificateur DAG fournissent des retours structurés qui améliorent la qualité de l’exécution sans nécessiter un modèle plus capable.