Statut : Accepté (mars 2026) Contexte : Alors que les capacités des LLM évoluent rapidement, nous avons besoin d’un cadre pour décider où investir nos 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 |
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é
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 5 étapes que nous avons construit ajoute une valeur décroissante. |
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
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
- Ne pas revenir aux fonctionnalités de v0.5. Les corrections de bugs oui, les nouvelles capacités non.
- La plateforme de connecteurs est l’investissement principal. Les versions v0.6–v0.8 doivent recevoir la majorité du temps d’ingénierie.
- L’ingénierie d’entreprise (RBAC, audit, sécurité, déploiement) est l’avantage concurrentiel. Ce sont des domaines peu attrayants mais défendables.
- 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.