MCP souverain : une ETI industrielle coupe le cordon avec les APIs américaines — et découvre ce que ça implique vraiment

# MCP souverain : une ETI industrielle coupe le cordon avec les APIs américaines — et découvre ce que ça implique vraiment

En 2026, la question n'est plus de savoir si les PME et ETI européennes vont déployer de l'IA. C'est déjà fait, souvent en ordre dispersé, souvent en dépendance invisible vis-à-vis d'infrastructures américaines. La vraie question, celle que peu de DSI osent poser à voix haute : à travers quelles tuyauteries circulent vos données quand vos assistants IA se parlent entre eux ?

Une ETI industrielle de 800 salariés, implantée en France avec des filiales en Allemagne et en Pologne, fabrique des composants pour l'automobile et l'aéronautique. Secteur sous pression réglementaire, données techniques sensibles, clients grands comptes qui exigent des audits de conformité. Son DSI — appelons-le Marc — n'est pas un idéologue de la souveraineté numérique. C'est un pragmatique. Et c'est précisément pour ça que son retour d'expérience sur le déploiement du protocole MCP de Positive mérite qu'on s'y attarde sans filtrer les aspérités.

Le problème de départ : l'archipel IA

Comme beaucoup d'ETI de sa taille, cette entreprise s'est retrouvée avec plusieurs briques d'IA déployées en ordre dispersé au fil des dix-huit derniers mois. Un assistant de rédaction pour les équipes commerciales, un outil de classification documentaire côté R&D, un copilote de maintenance prévisionnelle branché sur les données de production. Trois outils, trois silos, trois jeux d'API distincts — dont deux hébergés chez des opérateurs dont les conditions générales renvoient explicitement à une juridiction américaine.

"On avait construit sans plan d'ensemble", reconnaît Marc. "Chaque métier avait choisi son outil. Et personne n'avait posé la question de savoir comment ces outils allaient se coordonner, ni où partaient les données quand ils communiquaient."

C'est dans ce contexte que le projet MCP — Model Context Protocol, le standard d'interopérabilité promu par Positive — entre dans le tableau. L'idée du protocole : permettre à des assistants IA hétérogènes de partager du contexte, d'échanger des informations structurées, sans que chaque échange passe nécessairement par une API tierce centralisée — et donc sans que chaque requête soit potentiellement loguée, analysée ou soumise à une juridiction étrangère.

Sur le papier, c'est exactement ce que cherche Marc. Dans la pratique, c'est là que les questions qui dérangent commencent.

La promesse souverainiste : vraie, mais conditionnelle

Première chose que le DSI découvre rapidement : l'interopérabilité sans dépendance américaine, c'est une promesse conditionnelle. Elle tient — à condition que *tous* les maillons de la chaîne soient effectivement hébergés dans un environnement maîtrisé. Or dans l'archipel existant de cette ETI, ce n'est pas le cas.

L'un des trois assistants déployés s'appuie sur un modèle de fondation dont l'inférence est exécutée via une API externe — américaine. Brancher cet outil sur MCP ne change pas grand-chose à la trajectoire des données : elles continuent de transiter vers des serveurs soumis au Cloud Act. Le protocole d'interopérabilité, aussi vertueux soit-il, ne neutralise pas la dépendance en amont si le modèle lui-même est hébergé hors souveraineté.

"MCP ne fait pas de miracle", admet un interlocuteur chez un intégrateur européen ayant accompagné le projet. "C'est un protocole de coordination, pas un bouclier juridique. Si votre modèle est américain, vos données restent exposées au Cloud Act, que vous utilisiez MCP ou n'importe quel autre standard."

Ce point mérite d'être dit clairement, car le marketing autour des protocoles d'interopérabilité ouverts tends à laisser entendre que le simple fait de ne plus passer par des APIs propriétaires suffit à reprendre la main. Ce n'est pas exact. La couche de transport est une chose. La couche d'hébergement du modèle en est une autre. Les confondre, c'est s'exposer à un faux sentiment de contrôle.

NIS2, DORA et la question des flux inter-assistants

Deuxième point de friction : la traçabilité des échanges entre agents IA. Quand deux assistants se coordonnent via MCP pour traiter une requête complexe — disons, croiser des données de production avec un historique contractuel client — qui est responsable de quoi ? Qui logue quoi ? Qui peut auditer la chaîne de traitement ?

Pour une ETI comme celle-ci, soumise à NIS2 en tant qu'opérateur de secteur industriel critique, la question n'est pas abstraite. NIS2 impose une cartographie des flux d'information sensibles et une capacité à démontrer, en cas d'incident, que les mesures de sécurité adéquates étaient en place. Dans une architecture multi-agents coordonnée par MCP, cette traçabilité est techniquement faisable — mais elle doit être explicitement conçue. Elle ne vient pas par défaut.

Même logique côté RGPD : dès lors que les assistants échangent du contexte qui inclut des données à caractère personnel — un nom de contact commercial, un historique d'interaction client — chaque flux devient un traitement au sens du règlement. La base légale, la durée de conservation des contextes partagés, la capacité à répondre à un droit d'effacement : autant de questions que le déploiement de MCP ne résout pas en lui-même, et qui doivent être instruites en amont.

Marc le formule sans détour : "On a mis trois semaines de plus que prévu parce qu'on a dû rédiger une cartographie de flux qu'on n'avait pas. Le protocole était prêt. La documentation de conformité, non."

Ce que MCP change réellement — et ce qu'il ne change pas

Après plusieurs mois de fonctionnement, le bilan de Marc est nuancé — et c'est précisément pour ça qu'il est utile.

Ce que MCP a réellement changé pour cette ETI : la capacité à faire communiquer des assistants IA sans multiplier les contrats avec des tiers américains. Les deux outils qui étaient hébergés en environnement souverain européen ont pu être coordonnés via MCP sans créer de nouveau flux vers l'extérieur. Le gain de cohérence opérationnelle est réel. Les équipes métier rapportent moins de redondances, moins de copier-coller entre outils.

Ce que MCP n'a pas changé : la situation du troisième outil, dont le modèle reste hébergé hors UE. Il a été temporairement mis en quarantaine de l'architecture MCP, le temps d'identifier une alternative à inférence européenne. Ce choix a un coût opérationnel — certaines fonctionnalités sont moins fluides — mais il est assumé.

Surtout, MCP n'a pas dispensé l'ETI d'un travail de fond sur sa gouvernance IA : politique d'habilitation par rôle, définition de ce qui peut ou ne peut pas être partagé comme contexte entre agents, procédure de révocation en cas d'incident. Ce travail était nécessaire indépendamment du protocole choisi. MCP l'a simplement rendu impossible à différer.

La vraie question que les DSI évitent

Il y a une question que Marc n'avait pas posée avant de lancer ce projet, et qu'il conseille aujourd'hui à tous ses homologues de poser en premier : *Qui a accès aux contextes que vos agents IA s'échangent, et dans quelle juridiction ces échanges sont-ils traités ?*

C'est une question plus précise — et plus dérangeante — que le traditionnel "où sont mes données hébergées ?". Un agent IA qui opère sur des données hébergées en France peut parfaitement envoyer un résumé de ces données vers un service d'orchestration américain. Le contexte voyage. Et le contexte contient souvent l'essentiel.

Les protocoles ouverts comme MCP offrent une infrastructure pour reprendre la main sur cette couche d'orchestration. Mais ils ne constituent pas une réponse clé en main. Ils sont une condition nécessaire, pas suffisante.

Ce que retient le terrain

Pour les DSI et RSSI d'ETI qui regardent ces déploiements de loin, quelques conclusions transférables s'imposent.

D'abord, l'interopérabilité ouverte vaut ce que vaut l'environnement d'hébergement des modèles. Avant de déployer un protocole de coordination, cartographiez où s'exécutent vos inférences. C'est là que se joue l'exposition réelle au Cloud Act.

Ensuite, NIS2 et le RGPD s'appliquent aux flux entre agents comme à n'importe quel autre flux de données. La nouveauté technologique ne crée pas d'exception réglementaire. Les DPO et RSSI doivent être dans la boucle avant le déploiement, pas après.

Enfin, le passage à une architecture multi-agents souveraine est un projet de gouvernance autant que de technologie. Les ETI qui l'abordent uniquement comme un projet IT découvrent les angles morts réglementaires à leurs dépens.

Marc conclut avec une formule qui résume bien l'état d'esprit de 2026 : "On n'a pas résolu la souveraineté numérique. On a arrêté de l'ignorer." C'est peut-être le premier progrès honnête.

*Retour terrain réalisé sur la base d'entretiens anonymisés. Les noms et secteurs précis ont été modifiés pour préserver la confidentialité des interlocuteurs.*