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. 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 »

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+)

​

Tailwind

​

Gelé (livré, maintenance uniquement)

​

À considérer (reporté indéfiniment)

​

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.