Agents IA et MCP : sécuriser l'accès à vos données

D'un agent qui parle à un agent qui agit

Pendant longtemps, l'IA générative en entreprise s'est résumée à des assistants conversationnels : on pose une question, on obtient un texte. La donne change dès que l'agent peut agir : consulter une fiche client, créer un devis, interroger un historique de commandes ou planifier un rendez-vous. Pour y parvenir, il faut un pont entre le modèle de langage et les systèmes métier.

C'est le rôle du Model Context Protocol (MCP), un standard ouvert qui permet à un modèle d'IA d'accéder à des sources de données et à des outils externes de manière structurée. Au lieu de donner à l'IA un accès direct à une base de données, on expose des fonctions précises, décrites par un schéma, que l'agent peut appeler.

Un comparatif récent, intitulé « Top 10 MCP Implementation & Development Agencies in 2026 [Compared] » et publié sur le blog d'une agence spécialisée dans l'automatisation, consacre une large part de son analyse à une question que toute TPE ou PME devrait se poser avant de se lancer : comment brancher un agent sur ses données sans ouvrir une porte dérobée ? Nous en reprenons ici les enseignements pour les traduire en démarche concrète, à l'échelle d'une entreprise de taille humaine.

Le signal d'alarme : une vulnérabilité de conception

L'article source rapporte un événement marquant. En avril 2026, des chercheurs en sécurité d'OX Security ont révélé une vulnérabilité d'exécution de code à distance liée à la conception même des kits de développement officiels du protocole, dans l'ensemble des principaux langages de programmation. Selon la même source, Anthropic a indiqué qu'il s'agissait d'un comportement par défaut assumé et non d'un bogue, laissant la correction à la charge de chaque intégrateur.

Concrètement, le risque décrit est le suivant : une requête malveillante, glissée dans une conversation, peut être transmise par le modèle au serveur MCP et aboutir à l'exécution de commandes système arbitraires si les entrées ne sont pas validées et si l'environnement d'exécution n'est pas isolé.

La conclusion de l'auteur est sans ambiguïté : la question n'est plus de savoir si un prestataire sait relier un modèle de langage à une API, mais s'il traite l'authentification, le filtrage des entrées, l'isolation des environnements et la journalisation des actions comme des livrables à part entière, dès le premier jour. La gouvernance ne se rajoute pas après coup, une fois qu'un audit a mis au jour la faille.

Pour une PME, cette leçon est encore plus importante que pour un grand groupe : il n'y a généralement pas d'équipe sécurité dédiée pour rattraper une erreur de conception. L'architecture doit être saine dès le départ.

Une architecture en cinq couches pour sortir du prototype

L'article décrit une architecture de référence en cinq couches qui distingue une démonstration d'un système de production. C'est aussi la grille de lecture que nous utilisons chez comm.it pour cadrer un projet d'agent IA.

• Déclencheur : l'événement qui lance le traitement, qu'il s'agisse d'une question saisie dans une interface de discussion ou d'un appel automatique (webhook) émis par une application métier.
• Raisonnement : le modèle de langage analyse le contexte et choisit les outils nécessaires. Cette étape exige une ingénierie de prompt rigoureuse pour éviter les appels d'outils inventés (les fameuses hallucinations).
• Outils : c'est ici qu'intervient le serveur MCP. Il expose des fonctions validées par schéma ; l'agent appelle un point d'accès, jamais la base de données en direct.
• Mémoire : le contexte des échanges et l'historique des résultats sont stockés dans une base isolée et chiffrée, pour conserver l'état d'une session à l'autre.
• Garde-fous : authentification OAuth 2.1, contrôle d'accès par rôle (RBAC) et filtrage des entrées. Chaque appel d'outil est vérifié avant exécution.

Comme le résume la source, un prestataire incapable de rattacher sa méthode de livraison à ces cinq couches construit une démo, pas un système de production.

Ce que cela change pour une PME

Dans la pratique, cette architecture répond à des cas d'usage très concrets : un agent qui retrouve l'historique d'un client dans le CRM avant un appel, qui prépare une synthèse des ventes à partir de l'ERP, ou qui répond aux questions internes en s'appuyant sur la documentation de l'entreprise. Ce qui compte, ce n'est pas la sophistication du modèle, mais la qualité du pont entre le modèle et vos données.

C'est précisément le point de jonction entre les métiers de comm.it : le développement de logiciels cœur de métier (CRM, ERP), l'automatisation des processus et l'intégration de l'IA. Lorsque nous concevons un serveur MCP, nous ne partons pas d'une page blanche : nous partons de votre schéma de données, de vos règles de gestion et de vos droits d'accès existants.

Les fondations de sécurité, au cœur du livrable

Authentification OAuth 2.1 plutôt que clés statiques

L'article est clair : il ne faut pas utiliser de clés d'API statiques pour un serveur MCP en production. Le protocole OAuth 2.1 garantit que l'agent n'accède aux données qu'au nom de l'utilisateur authentifié, en respectant les droits déjà en place. Sans ce mécanisme, l'agent risque de fonctionner avec un compte de service « maître » et d'exposer à un collaborateur des données qu'il ne devrait jamais voir.

Pour une PME, c'est une question très terre à terre : le commercial ne doit pas voir les fiches de paie, le stagiaire ne doit pas pouvoir modifier les tarifs. L'agent doit hériter de ces mêmes limites.

Des outils définis, jamais un accès brut

Un serveur MCP de production n'expose pas la base de données : il expose des points d'accès définis et filtrés. L'auteur insiste sur un point : refuser toute configuration où le modèle génère des requêtes SQL brutes sans couche de validation intermédiaire. La validation par schéma JSON des arguments transmis à chaque outil constitue la première barrière contre l'injection de commandes.

Isolation et journalisation

L'isolation des environnements (séparation entre clients, entités ou services) et la journalisation d'audit permettent de savoir, à tout moment, qui a demandé quoi, par l'intermédiaire de quel outil, et avec quel résultat. Ce n'est pas un luxe réglementaire : c'est ce qui permet de diagnostiquer un incident et de rassurer la direction.

Le principe du moindre privilège

Chaque compte technique rattaché au serveur MCP doit disposer des droits strictement nécessaires, et pas un de plus. Ce principe, bien connu en administration réseau, prend une importance particulière lorsque l'utilisateur final est une IA capable d'enchaîner des actions à grande vitesse.

Garder l'humain dans la boucle

L'une des recommandations les plus utiles de l'article concerne les limites d'autonomie. Un système fonctionnant sans surveillance ne doit jamais exécuter d'opérations destructrices, comme la suppression d'enregistrements ou l'envoi de transactions financières non vérifiées. L'agent peut préparer l'opération ; un humain doit valider.

Cette logique de validation humaine à chaque changement d'état critique est au cœur de notre approche de l'automatisation. Un bon workflow ne supprime pas l'humain : il lui retire les tâches répétitives et lui réserve les décisions qui engagent l'entreprise.

Tester avant de faire confiance

La source propose trois scénarios de test que nous jugeons particulièrement pertinents pour la recette d'un projet :

1. Cas nominal : un utilisateur demande une synthèse analytique sur une période exprimée en langage naturel. On attend un appel propre au serveur MCP, et l'on vérifie dans les journaux que l'identifiant de l'entité est correctement associé et que les données renvoyées sont exactes.
2. Cas limite : à cause d'une demande imprécise, l'agent tente de récupérer des données appartenant à une autre entité. Le comportement attendu est un rejet immédiat au niveau de la passerelle. Le contrôle d'accès doit s'appliquer indépendamment du raisonnement du modèle.
3. Cas d'échec : un utilisateur tente une injection de commandes système via l'interface de discussion. Le filtre d'entrée doit bloquer totalement la requête et déclencher une alerte.

Le troisième scénario illustre directement le risque révélé en avril 2026. Le tester explicitement avant la mise en production n'est pas facultatif.

La check-list de mise en production

Avant de basculer un serveur MCP en production, l'article recommande un processus de validation formel. Nous l'appliquons sous la forme suivante :

• Tests d'intégration couvrant chaque outil exposé.
• Audit des identifiants : aucun secret écrit en dur, tout repose sur un coffre-fort de secrets et sur des flux OAuth 2.1.
• Alertes : les délais de connexion dépassés et les erreurs de validation de schéma remontent dans la supervision.
• Revue des droits : application stricte du moindre privilège sur les rôles associés au serveur.
• Limites d'autonomie vérifiées : le passage de relais à un humain fonctionne lorsque l'agent reçoit une demande non autorisée.
• Jeu d'évaluation : un ensemble de requêtes de référence est rejoué régulièrement pour détecter toute dérive du modèle vers des appels d'outils inventés.

Performance et coûts : penser l'échelle dès le départ

Un agent qui fonctionne bien en test peut devenir lent ou coûteux en usage réel. L'article évoque plusieurs leviers que nous intégrons dès la conception :

• Mutualisation des connexions à la base de données derrière le serveur MCP.
• Mise en cache des requêtes dont le résultat ne change pas, pour éviter que le modèle ne récupère sans cesse les mêmes informations.
• Regroupement des appels lorsque l'agent doit agréger beaucoup de données.
• Routage intelligent des modèles : inutile de solliciter un modèle de raisonnement coûteux pour une simple recherche dans une table. Les appels simples peuvent être confiés à des modèles plus rapides et moins chers.
• Gestion des erreurs avec nouvelles tentatives espacées progressivement en cas d'indisponibilité passagère d'une API.

Un autre conseil mérite d'être retenu : ne jamais autoriser de requête ouverte renvoyant une table entière. Une réponse non paginée peut saturer la fenêtre de contexte du modèle. La pagination obligatoire se décide au moment où l'on définit l'outil.

Les pannes à anticiper

La source détaille plusieurs incidents typiques. Les connaître permet de poser les bonnes questions à n'importe quel prestataire :

• Délai dépassé sur un transport local : le serveur n'a pas démarré à temps, souvent pour une question de permissions. La prévention recommandée consiste à privilégier en production des transports HTTP conteneurisés plutôt que des connexions locales.
• Échec d'authentification : jeton expiré ou périmètre demandé supérieur à celui autorisé. La parade est une gestion automatisée du cycle de vie des jetons.
• Appel rejeté par la politique de sécurité : une tentative d'injection a été bloquée. Il faut isoler la session, analyser les journaux et renforcer les consignes du modèle.
• Format de réponse invalide : le serveur a renvoyé une page d'erreur au lieu d'une structure attendue. Toutes les réponses, y compris les erreurs, doivent être sérialisées dans un format strict.

Comment comm.it accompagne ce type de projet

Pour une TPE ou une PME, le sujet MCP se heurte rarement à une difficulté purement technique. Il bute plutôt sur trois questions : quelles données exposer, à qui, et avec quelles garanties ? Notre démarche s'organise autour de ces questions.

1. Cartographier avant de connecter

L'article le rappelle : le prestataire construit le pont, mais c'est l'entreprise qui définit le territoire. Nous commençons donc par recenser avec vous les bases de données et les API auxquelles l'agent devra accéder, puis par rédiger une politique d'accès précisant ce qu'il peut lire et ce qu'il peut écrire.

2. Concevoir sur une base saine

Parce que nous développons aussi des CRM et des ERP sur mesure, nous connaissons la logique des données métier de l'intérieur. Nous concevons des outils MCP alignés sur vos règles de gestion, avec validation par schéma, authentification déléguée et journalisation intégrée.

3. S'appuyer sur une infrastructure maîtrisée

Un agent IA reste une application qui circule sur votre réseau. Notre expertise en infrastructure et en networking nous permet de traiter l'ensemble de la chaîne : segmentation, exposition des services, supervision et alertes. La sécurité d'un serveur MCP ne s'arrête pas à son code.

4. Démarrer petit, mesurer, étendre

La recommandation finale de la source rejoint notre pratique : commencer par un pilote au périmètre borné avant d'ouvrir l'accès à toute l'entreprise. Un premier cas d'usage bien choisi permet de valider l'architecture, de mesurer le gain réel et de former les équipes, avant d'élargir progressivement.

Les bonnes questions à poser à un prestataire

Que vous travailliez avec nous ou avec un autre partenaire, l'article fournit une grille d'évaluation utile. Avant de vous engager, demandez :

• Comment l'injection de commandes est-elle neutralisée sur les outils exposés ?
• L'authentification repose-t-elle sur OAuth 2.1 ou sur des clés statiques ?
• Comment l'isolation entre entités, services ou clients est-elle garantie ?
• Quelles actions exigent une validation humaine ?
• Quels journaux d'audit seront disponibles, et qui pourra les consulter ?
• Le projet peut-il démarrer par un pilote limité et mesurable ?

L'auteur du comparatif invite d'ailleurs à vérifier de manière indépendante toute affirmation d'un prestataire, y compris celles de son propre article. C'est un conseil de bon sens : demandez des schémas d'architecture et des explications concrètes plutôt que des promesses.

En résumé

Le Model Context Protocol ouvre une perspective très concrète : des agents IA capables d'agir sur vos outils métier, et pas seulement de rédiger du texte. Mais la vulnérabilité révélée en avril 2026 l'a rappelé avec force : connecter une IA à ses données devient un risque opérationnel majeur lorsque la conception est négligée. Authentification déléguée, filtrage des entrées, isolation, journalisation et validation humaine ne sont pas des options : ce sont les fondations.

Source : « Top 10 MCP Implementation & Development Agencies in 2026 [Compared] », article publié sur le blog d'une agence spécialisée en automatisation.

Prêt à transformer ces enjeux en avantage concurrentiel ? Contactez comm.it pour en discuter.

Source : Top 10 MCP Implementation & Development Agencies in 2026 Compared