> ## 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. # Stratégie d'orthogonalité > Architecture Decision Record — classifier les fonctionnalités selon leur relation à la progression du LLM. > Alors que les capacités des LLM évoluent rapidement, nous avons besoin d'un cadre pour décider où investir les efforts d'ingénierie et où rester stable. ## Décision Nous classons chaque fonctionnalité selon sa relation avec la progression des LLM et allouons les efforts en conséquence. | Catégorie | Stratégie | Investissement | Exemples | | ---------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------- | | **Orthogonal** | L'amélioration des modèles ne diminue pas ces éléments — problèmes purs d'ingénierie/intégration | Investissement complet | Connecteurs, identifiants, OAuth, audit, RBAC, sécurité, déploiement | | **Tailwind** | L'amélioration des modèles rend ces éléments *meilleurs*, non redondants — relation symbiotique | Investir (les bénéfices se composent) | Générateur de connecteurs IA (modèle plus intelligent = sortie de connecteur de meilleure qualité) | | **Figé** | Déjà livré, fonctionnant bien — mais les modèles absorbent ces capacités | Maintenir uniquement, pas de nouvelles fonctionnalités | Boucle ReAct, planification DAG, pipeline RAG, Mémoire, Génération ancrée | | **À considérer** | Fournisseurs construisant nativement au niveau de la plateforme — risque élevé de redondance | Reporté indéfiniment | Orchestration multi-agents, mémoire sémantique, cycle de vie de la mémoire | **Règle empirique** : Si une fonctionnalité résout *« comment rendre le modèle plus intelligent »*, elle est en cours d'absorption. Si elle résout *« comment connecter le modèle au monde réel en toute sécurité »*, elle est orthogonale. # Analyse ### Pourquoi la plateforme de connecteurs est complètement orthogonale Les modèles ne feront jamais nativement : * Stocker et chiffrer les identifiants API (AES-GCM) * Gérer les flux OAuth (page d'autorisation → rappel → jeton d'actualisation) * Se connecter à la base de données ERP Kingdee/金蝶 d'un client * Envoyer des notifications à Lark/飞书 ou WeCom/企微 * Appliquer le RBAC pour contrôler qui peut utiliser quel connecteur * Enregistrer chaque appel d'outil à des fins d'audit de conformité Ce sont des problèmes d'ingénierie, pas des problèmes d'intelligence. Un modèle 10 fois plus intelligent ne peut toujours pas faire ces choses sans infrastructure. ### Pourquoi le Générateur de Connecteur IA est « en croissance » et non « en cours d'absorption » Le Générateur d'Agent utilise l'intelligence du modèle pour créer des **entités de Connecteur gérées et persistantes** — stockées en base de données, réutilisables entre agents, avec gestion des identifiants et pistes d'audit. La compréhension croissante des API du modèle fait que le Générateur produit des *meilleurs* connecteurs, et non que le Générateur devienne inutile. Analogie : Cursor utilise Claude pour écrire du code. Claude devenant plus intelligent rend Cursor *meilleur*, non *redondant*, car Cursor fournit une valeur d'ingénierie (gestion de projet, organisation des fichiers, contrôle de version) que le modèle ne remplace pas. ### Pourquoi les fonctionnalités v0.1–v0.5 sont « gelées » | Fonctionnalité | Ce qui se passe dans l'industrie | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Boucle ReAct | Les modèles ont l'appel d'outils natif (OpenAI, Anthropic). La boucle de raisonnement externe ajoute moins de valeur à mesure que les modèles l'internalisent. | | Planification DAG | Les capacités de raisonnement des modèles s'améliorent rapidement. La décomposition de tâches complexes qui nécessitait des planificateurs externes devient une capacité en une seule étape. | | Gestion de la mémoire | Les fenêtres de contexte augmentent rapidement (Gemini 2M+, Claude 200K+). Le besoin de gestion externe des fenêtres, de résumé et de compaction diminue. | | Pipeline RAG | Les fournisseurs intègrent la récupération dans leurs plateformes (OpenAI file\_search, Google NotebookLM, Gemini Search Grounding). Pour les connaissances publiques, le pipeline traditionnel chunk-embed-retrieve est remplacé. | | Génération ancrée | Les modèles s'améliorent pour citer les sources nativement. Le pipeline de grounding en 3 étapes que nous avons construit ajoute une valeur décroissante. | **Ces fonctionnalités ne sont pas mauvaises** — elles ont été livrées, elles fonctionnent, elles rendent le produit fonctionnel aujourd'hui. La décision est simplement d'arrêter de les améliorer et de rediriger les efforts. ### Pourquoi l'orchestration multi-agents a été reportée Les fournisseurs de LLM construisent l'orchestration nativement : * **OpenAI Swarm** : Framework multi-agents avec protocoles de transfert * **Anthropic Claude Code Teams** : Pools d'agents Leader/Worker avec graphes de tâches * **Google A2A (Agent-to-Agent)** : Protocole de communication inter-agents Construire une couche d'orchestration concurrente signifierait faire la course contre des implémentations propriétaires avec une intégration de modèle plus profonde. Ce n'est pas un différenciateur durable. ### Pourquoi la mémoire sémantique et le cycle de vie de la mémoire ont été reportés * Les fenêtres de contexte augmentent rapidement, réduisant le besoin de récupération de mémoire entre sessions * Les fournisseurs ajoutent des fonctionnalités de mémoire natives (ChatGPT Memory, Claude Projects) * Le coût d'ingénierie de la construction d'un système de mémoire fiable (TTL, notation d'importance, récupération sémantique) est élevé par rapport à l'écart décroissant qu'il comble ## Classification au niveau des fonctionnalités ### Orthogonal (v0.6+) | Fonctionnalité | Version | Pourquoi orthogonal | | -------------------------------------- | ------- | ----------------------------------------------------- | | Entité connecteur + CRUD | v0.6.1 | Intégration d'entreprise, ingénierie pure | | Identifiants par utilisateur (AES-GCM) | v0.6.2 | Infrastructure de sécurité | | Porte de confirmation | v0.6.2 | Mécanisme de sécurité pour les opérations d'écriture | | Export/Import/Fork de connecteur | v0.7 | Mécanisme de distribution | | OAuth 2.0 | v0.7 | Implémentation de protocole | | Export de serveur MCP | v0.7 | Interopérabilité (dépend de l'adoption de MCP) | | Connecteur de base de données | v0.8 | Accès direct à la base de données, pools de connexion | | Notification Push | v0.8 | Canaux de notification | | RBAC | v0.8 | Contrôle d'accès, gouvernance | | Journal d'audit des opérations | v0.8 | Conformité | | Renforcement du bac à sable | v0.9 | Isolation de sécurité | | Observabilité (OTel, disjoncteur) | v0.9 | Opérations de production | | Analytique des connecteurs | v0.9 | Suivi d'utilisation | | Docker Compose | v0.9 | Déploiement | | Tableau de bord administrateur | v1.0 | Interface de gestion | | Tâches planifiées / Webhooks | v1.0 | Déclencheurs d'automatisation | | Exécution par lot | v1.0 | Traitement à l'échelle de l'entreprise | | Widget intégrable / iframe | v1.0 | Mode de livraison | | Sécurité d'entreprise | v1.0 | Conformité (chiffrement, liste blanche IP) | ### Tailwind | Fonctionnalité | Version | Relation | | ------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------ | | Générateur de connecteur IA | v0.6.3 | Modèles plus intelligents → meilleure sortie du générateur | | Génération de connecteur IA (OpenAPI) | v1.0 | Identique — les modèles comprennent mieux les spécifications API → génération automatique plus précise | ### Gelé (livré, maintenance uniquement) | Fonctionnalité | Version | Statut | | --------------------------------------------------------------------------- | ---------- | ------------------ | | Agent ReAct | v0.1 | Livré, fonctionnel | | Planification / Re-planification DAG | v0.1, v0.5 | Livré, fonctionnel | | Mémoire (Fenêtre, Résumé, Compact) | v0.2, v0.5 | Livré, fonctionnel | | Pipeline RAG (embedding, magasin vectoriel, chunking, récupération hybride) | v0.5 | Livré, fonctionnel | | Génération ancrée | v0.5 | Livré, fonctionnel | | ContextGuard / Messages épinglés | v0.5 | Livré, fonctionnel | ### À considérer (reporté indéfiniment) | Fonctionnalité | Version d'origine | Raison du report | | ----------------------------- | ----------------- | --------------------------------------------------------------------------------- | | Orchestration multi-agents | v1.0 | Les fournisseurs construisent nativement | | Magasin de mémoire sémantique | Backlog | Les fenêtres de contexte augmentent ; les fournisseurs ajoutent la mémoire native | | Cycle de vie de la mémoire | Backlog | Même raison que ci-dessus | ## Implications 1. **Ne pas revenir aux fonctionnalités de v0.5.** Les corrections de bugs oui, les nouvelles capacités non. 2. **La plateforme de connecteurs est l'investissement principal.** Les versions v0.6–v0.8 doivent recevoir la majorité du temps d'ingénierie. 3. **L'ingénierie d'entreprise (RBAC, audit, sécurité, déploiement) est l'avantage concurrentiel.** Ce sont des domaines peu attrayants mais défendables. 4. **Réévaluer annuellement.** Si les progrès des modèles stagnent ou qu'une fonctionnalité « gelée » s'avère avoir encore des lacunes importantes, reconsidérer.