MCP et souveraineté des données : trois architectures IA sous le prisme européen

# MCP et souveraineté des données : trois architectures IA sous le prisme européen

*Par la rédaction RiffLab Media — Format comparatif technique*

En 2026, le protocole MCP — Model Context Protocol — est devenu le terrain de jeu favori des éditeurs IA. L'idée est simple, presque séduisante dans sa formulation : permettre à un assistant IA de se connecter à vos outils métier, vos bases de données, vos flux documentaires, via un protocole standardisé. Plus besoin d'intégrations artisanales. L'assistant *comprend* le contexte de votre entreprise.

Quand Positive, éditeur européen de solutions de gestion documentaire, annonce le lancement de ses propres MCP pour connecter ses assistants IA au SI de ses clients PME/ETI, il faut résister à la tentation de lire l'événement comme une simple news produit. C'est un signal. Un signal que l'espace des protocoles d'intégration IA est en train de devenir le prochain champ de bataille de la dépendance technologique — et que des acteurs européens commencent à s'y positionner sérieusement.

Il faut donc poser la vraie question, celle que tout DSI devrait se poser avant de signer quoi que ce soit : qui contrôle le protocole, qui héberge le contexte, et qui décide demain de le couper ?

Comparons trois approches architecturales concrètes.

Ce qu'est réellement un MCP — et pourquoi ça compte

Avant d'entrer dans le comparatif, un rappel technique s'impose. Un MCP (Model Context Protocol) est une couche d'abstraction qui permet à un modèle de langage de récupérer du contexte structuré depuis des sources tierces : un ERP, un CRM, une GED, un outil de ticketing. C'est Anthropic qui a formalisé la spécification initiale du protocole. Ce détail n'est pas anodin : nous parlons d'un protocole dont la gouvernance de référence est américaine, même s'il est ouvert.

La standardisation est une bonne nouvelle pour l'interopérabilité. Elle peut aussi devenir un vecteur de lock-in si l'écosystème se referme autour d'un seul éditeur de modèle ou d'une seule plateforme cloud. C'est exactement ce que l'Europe doit surveiller.

Approche 1 — Le MCP natif cloud américain (acteur dominant US)

Architecture : Le modèle de langage est hébergé chez un acteur américain (pensez aux offres intégrées des grandes suites bureautiques ou des hyper-scalers). Les connecteurs MCP sont proposés en mode SaaS, directement branchés aux API propriétaires de l'éditeur. Le contexte métier transite par l'infrastructure de l'acteur US.

Intégration : Fluide, quasi immédiate si vous êtes déjà dans l'écosystème. C'est précisément là le piège. L'intégration est pensée pour être addictive : chaque connecteur supplémentaire renforce l'adhérence à la plateforme mère.

Gouvernance des données : Contractuellement, les données contextuelles transmises via MCP peuvent alimenter des processus d'amélioration du modèle, selon les conditions générales en vigueur — souvent révisables unilatéralement. La localisation des données est rarement garantie dans l'UE de manière contraignante. Le Cloud Act américain reste applicable.

Vecteur de dépendance : Maximum. Vous ne contrôlez ni le modèle, ni le protocole d'implémentation, ni l'infrastructure. Si l'acteur US décide demain de monétiser différemment l'accès aux connecteurs, de restreindre certains cas d'usage, ou simplement de modifier son API, votre SI métier est exposé. Sans alternative rapide à activer.

> Je le dis clairement : adopter cette architecture sans plan de sortie, c'est signer un bail emphytéotique avec un propriétaire qui n'est soumis à aucune obligation de réciprocité envers vous.

Approche 2 — Le MCP open source autodéployé (approche souveraine DIY)

Architecture : Vous déployez vous-même un serveur MCP open source (plusieurs implémentations communautaires existent depuis la publication de la spécification). Le modèle de langage peut être un modèle ouvert hébergé on-premise ou chez un cloud provider européen. Tout reste dans votre périmètre d'infrastructure.

Intégration : C'est ici que le bât blesse pour les PME/ETI. Cette approche demande une expertise DevOps et MLOps réelle. Maintenir un serveur MCP, gérer les versions, assurer la sécurité des endpoints, orchestrer les mises à jour : c'est un travail d'ingénierie à plein temps. Ce n'est pas une critique de l'open source — c'est une réalité opérationnelle que beaucoup de directions informatiques de taille intermédiaire ne peuvent pas absorber sans renfort.

Gouvernance des données : Excellente sur le papier. Totale maîtrise si l'hébergement est réalisé en Europe, chez un opérateur soumis au droit européen. C'est la promesse maximale en matière de souveraineté.

Vecteur de dépendance : Faible vis-à-vis des éditeurs tiers, mais fort vis-à-vis des compétences internes ou du prestataire qui déploie. Si votre intégrateur disparaît ou change de priorités, vous héritez d'un système à maintenir seul. La dépendance change de nature, elle ne disparaît pas.

> Cette approche est juste dans ses principes. Elle est honnête sur la complexité. Elle convient aux ETI disposant d'équipes techniques solides ou à celles qui s'entourent d'intégrateurs européens capables d'assumer la durée.

Approche 3 — Le MCP intégré chez un éditeur européen (l'apport de Positive)

Architecture : C'est le positionnement que Positive matérialise avec ses MCP natifs. L'éditeur propose des connecteurs préconstruits, pensés pour son propre écosystème de gestion documentaire, mais déployables dans l'infrastructure du client ou chez un hébergeur européen certifié. Le modèle de langage peut rester choisi par le client — la couche MCP est agnostique au modèle.

C'est là l'intérêt structurel : la dissociation entre le protocole d'intégration et le modèle d'inférence. Vous n'êtes pas obligé de prendre le modèle de l'éditeur. Vous pouvez y brancher un modèle ouvert hébergé souverainement.

Intégration : Nettement plus accessible que le DIY. L'éditeur maintient la couche de connecteurs, assure les mises à jour de compatibilité, et reste interlocuteur contractuel unique sur cette brique. Pour une PME ou une ETI sans équipe IA dédiée, c'est une différence opérationnelle considérable.

Gouvernance des données : Elle dépend du contrat passé avec Positive et des choix d'hébergement. Mais contrairement à l'acteur américain dominant, la négociation contractuelle est possible, le droit applicable est européen, et la question de la portabilité des données peut être traitée sérieusement. Aucun Cloud Act ne plane au-dessus de l'échange.

Vecteur de dépendance : Il existe — ne nous voilons pas la face. Tout éditeur crée une forme de dépendance. Mais il faut distinguer une dépendance *négociable* dans un cadre juridique européen, d'une dépendance *structurelle* soumise à un droit étranger. Ce n'est pas le même risque.

Tableau comparatif

| Critère | MCP natif US | MCP open source DIY | MCP éditeur européen (ex. Positive) |

|---|---|---|---|

| Maîtrise de l'architecture | Faible | Totale | Partagée (client + éditeur) |

| Complexité d'intégration | Faible | Élevée | Modérée |

| Gouvernance des données | Hors juridiction UE | Totalement maîtrisable | Négociable, droit UE applicable |

| Risque de lock-in | Élevé (multi-couches) | Faible (éditeur) / Moyen (compétences) | Modéré, réversibilité possible |

| Agnosticisme modèle IA | Non (lié à l'écosystème) | Oui | Oui (selon implémentation) |

| Applicabilité PME/ETI | Immédiate mais risquée | Conditionnelle | Adaptée avec accompagnement |

Ce que ça change — et ce qu'il faut exiger

L'annonce de Positive n'est pas une révolution. C'est un pas dans la bonne direction, et il faut savoir lire les pas sans les transformer en bouleversements.

Ce qu'elle révèle en revanche, c'est que le niveau de maturité des éditeurs européens sur la couche d'intégration IA monte. Pendant trop longtemps, la souveraineté numérique était un argument de vente sans substance technique derrière. Proposer des MCP maintenus, agnostiques au modèle, déployables en infrastructure européenne : c'est mettre de la chair sur l'os.

Mais je pense que les DSI et CTO de PME/ETI doivent aller plus loin dans leurs exigences. Il faut désormais systématiquement poser trois questions à tout éditeur IA qui frappe à votre porte :

Premièrement : Où transite le contexte métier que mon assistant IA va consommer ? Nommez les datacenters, nommez les sous-traitants.

Deuxièmement : Votre implémentation MCP me permet-elle de changer de modèle de langage sans refonte de mon architecture ? Si la réponse est non, c'est un lock-in modèle camouflé en intégration.

Troisièmement : Quelle est la procédure de portabilité de mes connecteurs et de mes données contextuelles si je résilie ? Elle doit être contractualisée avant la signature, pas découverte au moment du départ.

Les MCP sont une opportunité réelle de reprendre la main sur l'architecture IA de votre organisation. Mais un protocole ouvert entre les mains d'un acteur fermé reste un vecteur de dépendance. La standardisation n'est pas synonyme de liberté — elle peut aussi devenir le langage commun d'une nouvelle captivité.

En 2026, l'Europe a assez d'acteurs compétents pour ne plus subir cette captivité par défaut. Encore faut-il que nos organisations aient le réflexe de les chercher.

*RiffLab Media est un média B2B indépendant européen. Aucune relation commerciale avec les acteurs cités dans cet article.*