MCP et architecture d'entreprise : bâtir une couche de contexte souveraine pour l'IA

Modèle opératoire du contexte souverain

Un agent IA ne vaut que le contexte qu'il peut atteindre. Pour une entreprise régulée, ce contexte — le référentiel d'architecture — est aussi l'un de ses actifs les plus sensibles.

Le modèle opératoire qui compte n'est pas « exposer le référentiel via MCP » ; c'est « gouverner quel contexte sort, vers qui, et sous quelles contraintes de résidence et d'audit ».

• Décider quels types d'objets sont interrogeables, et lesquels ne sont jamais exposés
• Garder le contexte frais : réconcilier le référentiel avec les sources vivantes, pas un snapshot annuel
• Rendre chaque réponse traçable vers une source gouvernée que l'utilisateur a le droit de voir

Perspective métier pour ce sujet

Traitez le MCP comme un port-commodité ; investissez dans le contexte souverain gouverné derrière — c'est là qu'est la défendabilité.

Utilisez cette page comme un support de décision: alignez les parties prenantes, validez les trade-offs et reliez les choix d'architecture à des outcomes business mesurables.

• Requete principale: MCP et architecture d'entreprise : bâtir une couche de contexte souveraine pour l'IA
• Périmètre de décision: stratégie, gouvernance, modèle opératoire et contraintes d'exécution
• Livrable attendu: prochaines actions claires avec ownership et indicateurs mesurables

MCP est le port, pas le produit

Le Model Context Protocol (MCP) est devenu la manière standard de connecter un agent IA à un système externe. C'est, de fait, le port USB de l'IA : une interface propre et structurée qu'un agent peut utiliser pour lire et agir sur des données qu'il ne détient pas nativement. Les éditeurs se précipitent pour annoncer que leur outil « supporte MCP », et les éditeurs d'architecture d'entreprise ne font pas exception.

Voici la vérité inconfortable pour les acheteurs : MCP est une commodité. Personne ne choisit une plateforme parce qu'elle parle un protocole — on la choisit pour ce qu'il y a derrière le port. Dans cet article, MCP n'est donc jamais l'argument. L'argument, c'est le contexte que le protocole expose, et la question de savoir si ce contexte est frais, gouverné et seulement sûr à exposer.

Ardoq et Bizzdesign disent, en substance, « parlez à votre architecture ». Nous partons d'une question plus tranchante : comment laisser l'IA raisonner sur votre architecture sans en perdre le contrôle ? C'est là que se rencontrent architecture d'entreprise, réglementation et souveraineté — et c'est le sujet de ce hub.

L'EA comme système de contexte de l'entreprise

Pendant deux décennies, les entreprises ont investi dans des systèmes de référence — Salesforce, SAP, ServiceNow — les sources autoritatives de qui est le client, ce qui a été vendu, quel ticket est ouvert. Les agents IA ont désormais besoin de ce que ces systèmes n'ont jamais été conçus pour fournir : une image cohérente et interrogeable de la façon dont tout le patrimoine s'articule. C'est une nouvelle couche. Nous l'appelons le système de contexte.

L'architecture d'entreprise est le foyer naturel de cette couche. Un modèle EA encode déjà les capacités métier, le portefeuille applicatif, la pile technologique et — surtout — les dépendances entre eux. Quand un agent doit répondre à « qu'est-ce qui casse si cette application est retirée ? », la réponse n'est dans aucun système de référence isolé ; elle est dans l'architecture. Le système de contexte se place à côté des systèmes de référence, pas au-dessus.

Ce recadrage compte parce qu'il change la finalité d'un référentiel EA. Il cesse d'être une archive documentaire que quelques architectes consultent pour devenir le substrat vivant sur lequel les agents raisonnent. Ce qui relève la barre : un système de contexte n'est utile que s'il est à jour, gouverné et digne de confiance.

Six questions EA auxquelles les agents devraient répondre en langage naturel

La promesse d'une architecture agent-ready, c'est que les questions qu'un DSI, un RSSI ou un auditeur posent réellement deviennent des requêtes en langage naturel sur le modèle — pas une analyse manuelle d'une semaine. Six cas d'usage récurrents de l'architecture d'entreprise s'y prêtent directement :

• Rationalisation : « Quelles applications sont redondantes ou se chevauchent entre business units, et que coûterait une consolidation ? »
• Analyse d'impact : « Si nous décommissionnons ce système central, quelles capacités, intégrations et processus aval sont touchés ? »
• Documentation de conformité : « Montre toute application traitant des données personnelles et où ces données sont hébergées » — une preuve, pas un verdict.
• Risque et vulnérabilités : « Quelles fonctions métier critiques dépendent de composants à vulnérabilités connues ou en fin de support ? »
• Alignement stratégique : « Quelles initiatives de la roadmap soutiennent cet objectif stratégique, et quelles capacités touchent-elles ? »
• Planification de fin de vie : « Quelles technologies arrivent en fin de support dans les 18 prochains mois, et qu'est-ce qui en dépend ? »

MCP léger vs MCP natif — et pourquoi la profondeur l'emporte

Toutes les intégrations MCP ne se valent pas. Un MCP léger enveloppe le protocole autour d'un endpoint de recherche ou d'export existant : l'agent obtient un accès par mots-clés à des documents ou une liste plate d'objets. Ça démontre bien et se livre vite. Mais cela traite le référentiel EA comme un tas de texte, pas comme un modèle connecté.

Un MCP natif expose l'architecture telle qu'elle est réellement — un graphe de capacités, d'applications, de technologies et des relations entre elles — pour que l'agent puisse parcourir les dépendances plutôt que de les deviner. La différence apparaît précisément sur les questions difficiles : l'analyse d'impact et la rationalisation ont besoin des relations, pas seulement des nœuds. Bizzdesign a posé publiquement cette distinction léger-versus-natif, et elle est réelle.

Notre position : la profondeur est nécessaire mais pas suffisante. Un MCP natif sur un référentiel obsolète ou superficiel reste sans valeur, et un MCP natif qui exfiltre du contexte sensible est pire que rien pour une institution régulée. L'ordre de construction compte : le contexte d'abord, puis l'intelligence réglementaire, puis le protocole.

Le risque de souveraineté que les acteurs en place laissent de côté

Ardoq (premier sur le marché avec un MCP en disponibilité générale) et Bizzdesign se disputent « MCP × EA » et l'« ingénierie de contexte ». Tous deux reposent sur un postulat tacite : que connecter Claude, ChatGPT, Gemini ou Copilot à votre référentiel EA est acceptable. Pour la finance régulée, ça ne l'est souvent pas.

Songez à ce que contient réellement une cartographie EA : un inventaire quasi complet de vos systèmes, vos dépendances critiques, vos composants obsolètes et non corrigés, vos vulnérabilités connues, vos flux de données sensibles, et parfois vos mesures de sécurité. C'est, littéralement, un plan des points de fragilité de l'organisation. L'envoyer à un LLM en cloud américain est une mine pour DORA, la CSSF, le RGPD et le règlement IA européen — la description la plus sensible de votre institution qui quitte votre juridiction en un seul appel d'API.

Personne ne s'empare du versant souveraineté de cette conversation. Les acteurs en place possèdent le récit « parlez à votre architecture » ; la question de gouvernance — ce contexte doit-il seulement quitter votre contrôle, et sous quelles conditions — est l'espace blanc. C'est la conversation que nous voulons avoir.

Ce qu'exige réellement un cadre régulé

La plupart des implémentations MCP s'arrêtent à la conscience des permissions : elles vérifient qui a le droit d'interroger quoi. C'est nécessaire mais incomplet. Un cadre adapté à la finance régulée doit gouverner deux choses à la fois.

Il doit être conscient des permissions — garantir qu'un agent agissant pour un utilisateur donné ne peut atteindre que le contexte auquel cet utilisateur a droit. Et il doit être conscient de la résidence des données — gouverner où la réponse est calculée et où les données sous-jacentes vont physiquement, pour que la description la plus sensible de l'institution ne franchisse pas une frontière ni n'atterrisse dans un modèle non maîtrisé. Le marché traite surtout le premier point et ignore le second.

C'est ce que nous entendons par MCP conscient de la résidence des données et ingénierie de contexte souveraine : faire de l'ingénierie de contexte sous contraintes de résidence et de gouvernance, et non malgré elles. Le résultat que veulent à la fois un RSSI et un auditeur est le même : l'IA peut raisonner sur l'architecture, et l'institution peut prouver que ce raisonnement n'a jamais compromis la souveraineté.

• Conscient des permissions : chaque requête respecte les droits réels de l'utilisateur demandeur.
• Conscient de la résidence : où vont les données est gouverné, pas seulement qui interroge.
• Auditable : chaque accès est journalisé comme une preuve qu'un auditeur acceptera.
• Hébergeable en UE : le contexte peut être servi depuis une région et une infrastructure que vous contrôlez.

Où va ArchiLU (vision, étiquetée honnêtement)

Soyons précis sur ce qui existe et ce qui n'existe pas. ArchiLU ne propose pas de serveur MCP aujourd'hui. Un MCP souverain, gouverné et conscient de la résidence des données est la direction que nous construisons — une conviction sur l'endroit où le contexte IA régulé doit aller, pas une fonctionnalité que l'on active cet après-midi.

Ce qui existe aujourd'hui, c'est le socle qui rend cette destination crédible : un modèle EA connecté (capacités, portefeuille applicatif, dépendances), un hébergement en région UE ou on-premise sous votre contrôle, le français et l'anglais natifs, un prix publié avec utilisateurs illimités, et une évaluation de maturité EA gratuite. Nous construisons d'abord le contexte vivant et l'intelligence réglementaire, car un MCP souverain ne vaut que le contexte gouverné qui le porte.

Si un éditeur vous dit que son serveur MCP vous rend conforme, soyez sceptique. Une couche de contexte aide à documenter et à prouver — c'est une aide à la preuve et à la documentation, pas une conformité juridique ni un substitut à votre propre jugement réglementaire. Nous nous tenons au même standard : convaincre en étant honnête sur la limite, pas en la brouillant.

Partez de votre maturité, pas du buzz

MCP, les agents et le système de contexte ne valent la peine d'être construits que sur une architecture à jour et digne de confiance. Avant de courir après le protocole, mieux vaut savoir où en est réellement votre pratique — à quel point votre référentiel est frais, vos dépendances complètes, vos accès déjà gouvernés.

L'évaluation gratuite de maturité EA d'ArchiLU note dix dimensions et renvoie un plan d'action priorisé en une dizaine de minutes. C'est une manière concrète et sans buzz de voir si votre architecture est prête à devenir un système de contexte auquel les agents — et les auditeurs — peuvent faire confiance.

KPIs du contexte IA régulé

Mesurez si votre contexte est fiable et gouverné, pas le nombre de requêtes de l'agent.

• Fraîcheur du contexte : âge médian des objets d'architecture vs réalité vivante
• Part des réponses traçables vers une source gouvernée et à périmètre de permission
• Types d'objets sensibles couverts par une politique de redaction/résidence
• Couverture d'audit : prompts et réponses loggés et revus

Common mistakes

La plupart des initiatives MCP-pour-EA échouent sur la qualité du contexte et la gouvernance bien avant d'échouer sur le protocole.

• Exposer tout le référentiel d'architecture à des LLM externes sans contrôle de résidence des données
• Traiter le MCP comme le différenciateur au lieu du contexte gouverné derrière
• Brancher un référentiel maintenu à la main vieux de 18 mois auquel l'agent ne peut pas se fier
• Aucune permission-awareness, aucun logging, aucune redaction des objets sensibles

Practical checklist

À faire avant de connecter un agent IA à votre référentiel d'architecture.

• Confirmer où vont prompts et réponses, et si la donnée reste dans votre région
• Imposer un accès permission-aware : l'agent ne voit que ce que l'utilisateur peut voir
• Classer et masquer les types d'objets sensibles (vulnérabilités, flux de données, contrôles)
• Logger prompts et réponses pour l'audit, et garder un humain dans la boucle pour tout changement