L’AI interne et le MCP externe comme environnements distincts
Les mêmes données métier n’imposent pas le même canal d’accès
Lorsqu’une entreprise adopte l’AI, la tentation apparaît vite de tout réunir derrière une passerelle universelle : agent interne, assistants externes, outils pour développeurs et intégrations de partenaires. Cette représentation simplifie une présentation, mais brouille les limites de confiance. Sapphire I.C.D.S. suit une autre approche. L’AI intégrée et le MCP externe constituent des environnements différents, même lorsqu’ils utilisent ponctuellement la même opération native d’un module métier.
Cette séparation répond à une question concrète : qui déclenche l’action, dans quel contexte cette personne ou ce client agit, et quelles données doivent être visibles pour cette catégorie de client. Un utilisateur interne de la plateforme et un client d’AI externe ne deviennent pas équivalents simplement parce que tous deux peuvent demander une liste d’articles.
L’AI interne travaille dans la plateforme
L’agent d’AI intégré s’exécute dans le contexte autorisé de Sapphire I.C.D.S. La plateforme détermine le propriétaire de la session, l’espace disponible, le profil de modèle choisi et les outils autorisés. L’agent peut employer des instructions d’entreprise, une mémoire et une base de connaissances si la politique interne le permet. Ses tâches, son historique et ses actions restent dans l’environnement d’AI gouverné.
L’accès aux outils résulte de l’état global, des droits du groupe et des paramètres de la session. Une demande utilisateur ne peut ni s’attribuer un nouveau rôle ni activer une commande interdite. L’agent interne convient ainsi au travail quotidien des collaborateurs : préparation de contenu, analyse de données, tenue de plans et exécution d’opérations permises dans les modules installés.
Le MCP externe s’adresse à d’autres clients
Le MCP externe de Sapphire I.C.D.S. est en developer alpha. Le seul environnement actuellement vérifié est la connexion de ChatGPT à https://sapphire-project.com/mcp. Les autres hôtes, clients et fonctions de politique ou de renforcement non finalisées nécessitent une validation distincte.
MCP est une interface standard par laquelle des clients d’AI externes compatibles peuvent découvrir et appeler des outils publiés. Dans Sapphire I.C.D.S., cet accès passe par une surface HTTPS séparée, sa propre authentification et des portées explicites. Avec OAuth, l’autorisation initiale utilise mcp.basic ; lorsqu’une opération exige davantage d’autorité, le serveur impose un step-up explicite pour portée insuffisante. Le bearer personnel conserve en parallèle des portées de developer alpha fixes et définies par le serveur : l’utilisateur ne dispose d’aucune sélection granulaire des portées.
Le client externe ne reçoit pas tout le catalogue interne. Chaque module publie une liste autorisée distincte d’outils MCP. L’existence d’une commande d’AI interne ne la rend pas externe. Le serveur contrôle de nouveau les portées accordées et les droits actuels du compte lors de chaque utilisation. Si un droit est révoqué, une autorisation antérieure ne doit pas devenir une dérogation permanente à la politique.
| Critère | AI interne | MCP externe |
|---|---|---|
| Utilisateur principal | Collaborateur dans Sapphire I.C.D.S. | Client d’AI externe compatible |
| Contexte | Session interne, profil et sources d’entreprise autorisées | Uniquement les données et outils publiés dans l’environnement externe |
| Politique des outils | Politique d’AI, droits du groupe et choix de la session | Publication explicite, portées d’accès et droits actuels |
| Objectif | Travail de l’agent dans la plateforme | Intégration de clients externes compatibles |
La mémoire interne n’est pas publiée à l’extérieur
La limite la plus importante concerne le contexte de l’entreprise. Les instructions, la mémoire interne et la base de connaissances appartiennent à l’AI intégrée. Elles ne doivent pas figurer dans la liste externe des outils ni être renvoyées à un client externe au seul motif qu’il a réussi son authentification. Celle-ci confirme une identité et des droits accordés, mais n’annule pas le principe de publication minimale.
Ce choix réduit le risque d’exposer accidentellement des règles de gestion, un contexte accumulé et des documents internes. Si l’organisation a réellement besoin d’un scénario externe fondé sur un ensemble précis de données, elle doit concevoir un outil distinct avec un schéma, des contrôles et une portée compréhensibles, plutôt que d’ouvrir une source interne générale.
La logique métier commune peut être réutilisée
Des environnements différents n’imposent pas de dupliquer l’implémentation. Un module peut orienter l’appel interne et l’appel externe vers la même opération métier validée, tout en conservant transactions, validations et restrictions de domaine. Au préalable, l’adaptateur externe filtre les commandes, contrôle les arguments, associe l’appel à une identité confirmée et applique des limites de publication supplémentaires.
Cette organisation offre un équilibre essentiel. L’entreprise n’entretient pas deux versions divergentes d’une opération de mise à jour d’article ou d’élément du Roadmap, mais elle ne considère pas non plus qu’une fonction interne est automatiquement sûre à l’extérieur. La logique est réutilisée, pas la confiance.
Les erreurs et les résultats ont aussi leurs limites
Le MCP externe renvoie les résultats comme des données de confiance minimale. Même une réponse correcte du serveur ne transforme pas le texte qu’elle contient en instruction destinée à l’agent externe. L’échec d’un outil reste isolé comme résultat de cet appel et n’ouvre aucun accès aux opérations voisines. Les modifications utilisent des autorisations séparées, et les actions particulièrement sensibles peuvent ne jamais être publiées.
Dans l’environnement interne, le modèle reçoit également des résultats structurés, mais l’interface du collaborateur peut n’afficher qu’une projection sûre de l’activité. Les arguments détaillés et les données techniques exigent un droit spécifique. Les deux environnements sont donc observables, chacun ne révélant que le niveau d’information nécessaire à son public.
Quand employer chaque option
- L’AI interne convient aux collaborateurs travaillant dans les espaces administratifs et opérationnels de Sapphire I.C.D.S. qui ont besoin du contexte de la plateforme.
- Le MCP externe sert à connecter des clients d’AI compatibles et des environnements de travail automatisés dans le périmètre vérifié.
- Les deux environnements peuvent coexister : l’organisation n’a pas à remplacer l’agent intégré par un service externe, ni l’inverse.
- L’intégration facultative avec ChatGPT est un exemple vérifié de client externe, et non un transfert de l’AI interne vers un système tiers.
Une règle d’architecture pratique
Avant de publier une opération, la direction technique doit répondre à quatre questions : nécessite-t-elle un contexte interne, qui possède la session, quel est le minimum de données requis et comment l’accès est-il révoqué ? Si l’opération dépend d’une mémoire fermée ou d’instructions internes, elle reste dans l’AI intégrée. Si le scénario externe est justifié, un contrat MCP explicite est créé avec un schéma limité et une politique distincte.
Pour le propriétaire de l’entreprise, cette séparation permet d’utiliser des services d’AI externes sans renoncer à l’indépendance de Sapphire I.C.D.S. Pour la sécurité, elle établit des limites de publication claires. Pour l’équipe technique, elle permet de réutiliser la logique métier native sans mélanger les contextes. L’AI interne et le MCP externe se complètent donc, mais ne doivent pas se transformer en un canal unique et indifférencié.