Intégration au SI existant

Bienvenue

Un système d'information d'entreprise n'est jamais un terrain vierge. Il porte l'historique de vingt ans de décisions : une API REST récente à côté d'un service SOAP qu'on n'ose plus toucher, une base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire de référence interrogée par des dizaines d'applications, un outil de ticketing qui structure le travail de plusieurs équipes, des dépôts Git qui font foi sur l'état du code. Introduire MCPMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire dans cet environnement ne consiste pas à remplacer quoi que ce soit — c'est une erreur de méthode fréquente chez les équipes qui découvrent le protocole. Il s'agit d'ajouter une couche d'accès pilotable par un modèle, par-dessus des systèmes qui continuent de fonctionner exactement comme avant.

Ce chapitre couvre la partie la plus concrète de l'adoption de MCP en entreprise : comment envelopper l'existant sans le réécrire, comment faire en sorte que chaque appel d'outil reste attribuable à une personne ou à un compte de service identifié, et comment organiser plusieurs serveurs MCP dans plusieurs environnements sans perdre le contrôle du catalogue.

Un serveur MCP n'est presque jamais un nouveau système. C'est un adaptateur qui traduit le vocabulaire des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire MCP (des fonctions nommées, avec des paramètres typés) vers le vocabulaire du système existant qu'il enveloppe (endpoints REST, opérations SOAP, requêtes SQL, appels d'API de ticketing).

Le serveur MCP comme wrapper, pas comme remplacement

La tentation, face à un SI hétérogène, est de vouloir « moderniser » avant de connecter. C'est une impasse pour deux raisons pratiques. D'abord, la réécriture d'un service SOAP vieux de quinze ans est un projet en soi, indépendant de MCP, et le coupler à l'adoption du protocole ne fait que retarder les deux. Ensuite, et c'est le point le plus important, un wrapper MCP a une responsabilité étroite et bien définie : exposer un sous-ensemble contrôlé des capacités d'un système sous forme d'outils, avec validation des paramètres et gestion des erreurs — pas reproduire l'intégralité de l'API sous-jacente.

Envelopper une API REST

C'est le cas le plus direct. Un serveur MCP qui enveloppe une API REST interne traduit un appel d'outil en une requête HTTP, avec généralement :

• un mapping explicite entre le nom de l'outil MCP et l'endpoint réel (get_customer_orders → GET /api/v2/customers/{id}/orders) ;
• une validation des paramètres en entrée, plus stricte que ce que l'API elle-même tolère parfois ;
• une transformation de la réponse JSON brute vers un format plus digeste pour le modèle (élagage des champs inutiles, aplatissement de structures imbriquées) ;
• une gestion homogène des erreurs HTTP, pour que le modèle reçoive un message exploitable plutôt qu'un code 500 nu.

Envelopper un service SOAP hérité

Les services SOAP posent un problème différent : le format d'échange (XML, enveloppes, espaces de noms, WSDL) est éloigné du monde JSON dans lequel MCP opère nativement. Le wrapper assume ici un travail de traduction plus lourd — construire l'enveloppe SOAP à partir de paramètres simples, parser la réponse XML, et surtout absorber les particularités d'un service qui n'a pas été pensé pour être appelé par un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire (sessions avec état, séquences d'appels obligatoires, formats de date exotiques).

Un service SOAP de gestion des stocks n'accepte les requêtes que dans un ordre précis : une opération OpenSession, puis QueryStock, puis CloseSession. Le serveur MCP peut masquer entièrement cette mécanique et n'exposer qu'un seul outil check_stock(sku), qui orchestre en interne les trois appels SOAP sans jamais exposer cette complexité au modèle.

Accès en lecture aux bases SQL

Les bases de données de référence — CRM, ERP, entrepôt de données — sont souvent la ressource la plus utile à exposer et la plus sensible à mal exposer. La règle de base, largement partagée dans les déploiements en production, est de limiter cet accès en lecture seule, via un compte de base de données dédié dont les droits GRANT excluent explicitement INSERT, UPDATE, DELETE et toute opération de schéma (DDL).

Un outil run_query(sql) qui accepte n'importe quelle chaîne SQL reste dangereux même si l'intention est la lecture, car rien n'empêche techniquement une requête DELETE ou une procédure stockée d'écriture — sauf si les droits du compte de base de données l'interdisent réellement au niveau du moteur. La restriction doit être appliquée par le système de droits de la base, pas seulement par une convention côté serveur MCP.

En pratique, deux approches coexistent :

1. Requêtes prédéfinies paramétrées : le serveur expose des outils comme get_orders_by_customer(customer_id), chacun adossé à une requête SQL fixe avec des paramètres liés (bind parameters). C'est l'option la plus sûre, car la structure de la requête ne varie jamais, seuls les paramètres changent.
2. SQL généré avec contrainte au niveau base : le modèle peut composer des requêtes plus flexibles, mais le compte de base utilisé est configuré en lecture seule stricte, avec accès limité à des vues (jamais aux tables sources) qui masquent déjà les colonnes sensibles.

La première option est préférable dès que les cas d'usage sont prévisibles ; la seconde apporte de la flexibilité mais déplace une partie de la sécurité vers la configuration de la base, ce qui exige une vigilance accrue sur les vues et les droits.

Ticketing et Git

Les outils de ticketing (gestion d'incidents, de tâches) et les dépôts Git sont des cas un peu différents : ce sont déjà des systèmes conçus pour être appelés par API, avec leurs propres modèles de permissions. Le travail du wrapper MCP consiste surtout à réduire la surface exposée à ce qui est pertinent pour la tâche — lire l'état d'un ticket, en créer un, commenter une pull request, lire l'historique d'un fichier — plutôt qu'à exposer l'API complète du fournisseur, qui inclut souvent des opérations administratives (suppression de projet, gestion des webhooks, modification des permissions d'équipe) sans rapport avec l'usage prévu.

Un outil create_ticket(title, description, priority) est plus sûr et plus lisible pour le modèle qu'un outil générique call_api(method, path, body) qui reproduirait toute la surface de l'API de ticketing. Le nommage par intention limite mécaniquement ce que l'outil peut faire.

Propagation d'identité : OIDC et comptes de service

La question la plus mal traitée dans les premiers déploiements MCP en entreprise n'est pas technique mais organisationnelle : au nom de qui le serveur agit-il ? Deux modèles répondent à deux besoins différents.

Identité utilisateur via OIDC

Quand un serveur MCP agit pour le compte d'une personne précise — un développeur qui interroge un ticket, un analyste qui consulte une base — la bonne pratique consiste à propager l'identité de cette personne jusqu'au système final, via un jeton OIDC (OpenID Connect) transmis depuis le client MCP. Le serveur ne doit pas s'authentifier lui-même auprès du système cible avec un compte générique tout-puissant ; il doit relayer ou échanger le jeton de l'utilisateur, de sorte que :

• les droits appliqués sont ceux de l'utilisateur réel, pas un sur-ensemble générique ;
• les journaux du système cible (base, API, ticketing) enregistrent l'identité réelle de la personne, pas un compte technique anonyme ;
• une révocation d'accès côté annuaire d'entreprise se répercute immédiatement, sans intervention sur le serveur MCP lui-même.

Un serveur MCP peut être authentifié de façon fiable (certificat, jeton de service) tout en agissant au nom d'un utilisateur dont les droits doivent rester la référence pour ce qu'il est autorisé à voir ou modifier. Confondre les deux revient à donner à chaque utilisateur les droits du compte technique du serveur — presque toujours plus larges que les siens.

Comptes de service pour les tâches autonomes

À l'inverse, un agent qui tourne en tâche de fond — surveillance planifiée, synchronisation périodique, traitement par lot sans utilisateur humain derrière — ne peut pas porter l'identité d'une personne physique. Il s'appuie sur un compte de service dédié, avec :

• un périmètre de droits explicitement documenté et limité aux tâches prévues ;
• une identité clairement distincte de tout compte humain, pour que les journaux distinguent sans ambiguïté une action automatisée d'une action manuelle ;
• un cycle de vie propre (création, revue périodique, désactivation) indépendant du cycle de vie d'un compte employé.

Réutiliser un même compte de service pour plusieurs serveurs MCP ou plusieurs pipelines d'automatisation casse la traçabilité : si une action anormale est détectée, il devient impossible de savoir quel serveur ou quel processus l'a déclenchée. Un compte de service par usage clairement délimité, même si cela multiplie le nombre de comptes à gérer, reste la pratique la plus sûre.

Séparation des environnements dev, staging, prod

Un serveur MCP n'échappe pas à la discipline classique de séparation des environnements — elle est même plus critique ici, parce qu'un modèle peut composer des appels de façon moins prévisible qu'un code écrit à la main.

Ce qui doit changer entre environnements

• Les identifiants et jetons : chaque environnement dispose de ses propres secrets, jamais partagés d'un environnement à l'autre. Un jeton de production ne doit jamais transiter, même temporairement, par un poste de développement.
• Les cibles réseau : un serveur MCP configuré pour le staging ne doit techniquement pas pouvoir atteindre les bases ou API de production, même en cas d'erreur de configuration — l'isolation réseau doit l'empêcher, pas seulement la convention.
• Le volume et la nature des données : le staging s'appuie idéalement sur des données anonymisées ou synthétiques, pour que les expérimentations avec un modèle — par nature moins prévisibles qu'un test unitaire classique — ne risquent jamais d'exposer des données réelles.
• Les niveaux de confirmation humaine : il est raisonnable d'assouplir certaines confirmations en développement pour itérer plus vite, à condition de les restaurer strictement en staging et en production.

Le staging n'a de valeur que s'il ressemble suffisamment à la production pour révéler les mêmes problèmes : mêmes schémas d'API, mêmes contraintes de latence, mêmes types de données (même anonymisées). Un staging trop simplifié ne teste rien d'utile sur le comportement réel d'un agent face à des données de forme réaliste.

Configuration par environnement, pas par branche de code

La tentation de dupliquer le code du serveur MCP par environnement (une branche « prod », une branche « staging ») introduit une dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire inévitable entre les versions. La pratique plus robuste consiste à garder un seul code de serveur, paramétré à l'exécution par des variables d'environnement ou un fichier de configuration externe (URL des systèmes cibles, jetons, niveau de confirmation requis) — exactement le même principe qu'une application classique à douze facteurs.

Gouvernance du catalogue MCP d'entreprise

Dès qu'une deuxième équipe commence à publier son propre serveur MCP, la question du catalogue se pose : qui sait que ce serveur existe, qui l'a approuvé, qui le maintient si son auteur d'origine change de poste ?

Ce qu'un catalogue d'entreprise doit couvrir

1. Un registre central des serveurs MCP approuvés, avec propriétaire nommé, description des outils exposés, et systèmes cibles enveloppés.
2. Un processus d'approbation avant mise à disposition large — revue de sécurité minimale (cf. le chapitre précédent), vérification des scopes de jetons utilisés, validation de la séparation des environnements.
3. Une politique de dépréciation : un serveur qui enveloppe une API elle-même en fin de vie doit être retiré du catalogue en même temps, pas laissé actif après que le système sous-jacent a changé de comportement.
4. Une visibilité sur l'usage réel : quelles équipes utilisent quel serveur, avec quelle fréquence, permet de prioriser la maintenance et de repérer les serveurs orphelins.

Un serveur MCP qui touche des systèmes réels mérite le même niveau de rigueur qu'un microservice interne classique : propriétaire identifié, documentation à jour, alerte en cas de panne, revue périodique. Le traiter comme un script personnel non maintenu est la cause la plus fréquente de dérive de sécurité observée après quelques mois d'usage.

Éviter la prolifération non coordonnée

Sans gouvernance, le risque le plus courant n'est pas une attaque spectaculaire mais une prolifération lente : chaque équipe écrit son propre wrapper pour la même API interne, avec des niveaux de validation différents, des jetons aux scopes incohérents, et aucune vue d'ensemble de qui a accès à quoi. Un catalogue central, même léger au départ — une simple liste tenue à jour avec les points de contact — évite cette dispersion et permet de réutiliser un serveur déjà audité plutôt que d'en écrire un nouveau à chaque projet.

Ce qu'il faut retenir avant de connecter MCP à l'existant

• Un serveur MCP enveloppe l'existant, il ne le remplace pas — la modernisation d'un système hérité est un projet séparé.
• L'accès aux bases SQL doit être restreint en lecture seule au niveau du moteur de base, pas seulement par convention dans le code du serveur.
• L'identité de l'appelant doit être propagée jusqu'au système cible — OIDC pour un utilisateur, compte de service dédié et scopé pour un agent autonome.
• Les environnements dev, staging et production doivent rester isolés au niveau réseau et des secrets, avec un code de serveur unique paramétré à l'exécution.
• Un catalogue d'entreprise, même modeste, évite la prolifération de wrappers redondants et garde une trace claire de qui possède, approuve et maintient chaque serveur MCP en circulation.

Ces principes ne sont pas propres à MCP — ils reprennent des pratiques déjà connues d'intégration système et de gestion des identités. Ce qui change, c'est l'urgence de les appliquer dès le premier serveur : parce qu'un modèle compose ses propres séquences d'appels, les angles morts laissés par une intégration bâclée se révèlent plus vite, et souvent de façon moins prévisible, que dans une intégration classique écrite entièrement à la main.