Skip to main content

Copilot vs Hub

L’architecture prend en charge deux échelles d’intégration : Copilot s’intègre dans l’interface utilisateur d’un système hôte. Les utilisateurs interagissent avec l’IA sans quitter leur interface familière. Il peut utiliser plusieurs connecteurs (DB hôte + service de notification, etc.). Hub est un portail autonome qui connecte tous les systèmes. Il n’est intégré dans aucun système unique — c’est la couche d’intelligence centrale où les systèmes rencontrent l’IA. Même architecture de connecteur, livraison différente. Un Copilot utilise le même ConnectorToolAdapter qu’un Hub.

Principe fondamental

Le client ne change aucun code. FIM One s’intègre proactivement dans leurs systèmes — en lisant leurs bases de données, en appelant leurs API, en poussant vers leur bus de messages. Le client fournit uniquement les identifiants et l’accès réseau.

Architecture à trois couches

Chaque couche a une responsabilité distincte :

Pourquoi MCP comme couche de transport

Les adaptateurs sont implémentés en tant que Serveurs MCP. Il s’agit d’un choix architectural délibéré :
  • Réutilisabilité : FIM One est déjà livré avec un Client MCP (v0.3). L’ajout d’un adaptateur de système hérité réutilise la même infrastructure que l’ajout de n’importe quel outil MCP.
  • Protocole standard : MCP est une norme ouverte. Aucun protocole propriétaire à inventer ou maintenir.
  • Écosystème : Les serveurs MCP tiers (bases de données, API, outils SaaS) fonctionnent immédiatement.
  • Isolation des processus : Chaque serveur MCP s’exécute en tant que processus distinct. Un adaptateur défaillant ne peut pas faire planter la plateforme.

Ce que MCP seul ne fournit pas

La Couche de gouvernance des connecteurs ajoute la gouvernance d’entreprise que MCP brut ne possède pas :

Pourquoi ne pas inventer un protocole personnalisé

Le protocole est une commodité. La valeur technique réside dans les adaptateurs eux-mêmes (connaissance du domaine, mappage de schéma, gestion des cas limites) et la couche de gouvernance (audit, authentification, sécurité). Inventer un protocole de transport ajouterait un coût de maintenance sans ajouter de capacité. Stripe utilise HTTPS ; Docker utilise cgroups ; FIM One utilise MCP.

Modèle de déploiement

Tout s’exécute dans un seul déploiement Docker Compose. Le client n’installe rien.
Tous fournis par FIM One. Le client fournit uniquement :
  • Les identifiants de base de données (compte en lecture seule recommandé)
  • Les points de terminaison API et les clés (si disponibles)
  • L’accès à la liste blanche du réseau
Hiérarchie d’accès : FIM One s’adapte à l’accès que le client peut fournir :

Découplage Agent-Connecteur

L’agent voit les connecteurs comme des outils ordinaires. Il ne sait pas et ne se soucie pas de savoir si un outil est intégré, un serveur MCP tiers ou un connecteur de système hérité. Cela signifie :
  • Ajouter un nouveau système = ajouter une configuration de connecteur. Le code de l’agent ne change pas.
  • Supprimer un connecteur = supprimer la configuration. Aucune modification de code.
  • Le même agent peut utiliser des outils intégrés et des connecteurs dans une seule tâche.

Évolution du Hot-Plug

Les déploiements d’entreprise sont « implémenter une fois, exécuter pendant des mois » — le hot-plug est une commodité de v1.0, pas une exigence de v0.6.

Exemple de flux de données

Utilisateur : « Vérifier tous les contrats en retard du système financier et envoyer un résumé à Lark. »

Niveaux de standardisation des connecteurs

Relation avec l’écosystème MCP existant

Le Client MCP de FIM One (livré en v0.3) supporte déjà les serveurs MCP tiers. Les adaptateurs de systèmes hérités sont simplement des serveurs MCP spécifiques au domaine construits avec la couche de gouvernance des connecteurs pour la gouvernance d’entreprise. La couche de gouvernance des connecteurs ne remplace pas MCP — elle étend MCP avec la couche de gouvernance que l’intégration des systèmes hérités d’entreprise nécessite.