MCP fin ou natif : pourquoi le modèle derrière le serveur décide de tout

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

La profondeur native compte, mais pour la finance régulée elle est incomplète sans fraîcheur et gouvernance consciente de la résidence des données.

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 fin ou natif : pourquoi le modèle derrière le serveur décide de tout
• 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

Un serveur MCP ne vaut que le modèle qui se trouve derrière

Le Model Context Protocol vit son moment de gloire. Les éditeurs se précipitent pour annoncer que leur outil d'architecture d'entreprise « parle MCP », comme si le protocole était le produit. Il ne l'est pas. MCP est un connecteur — une commodité, le port USB de l'IA. La vraie question n'est jamais de savoir si un outil fait du MCP ; c'est de savoir sur quoi l'agent peut réellement raisonner une fois connecté.

Cela dépend entièrement du modèle que le serveur expose. Connectez un agent à une table plate d'applications et vous obtenez de la recherche. Connectez-le à un graphe sémantique gouverné et vous obtenez de l'analyse d'impact. Même protocole, deux mondes différents. C'est pourquoi la distinction entre un MCP fin et un MCP natif compte davantage que le label MCP sur la boîte.

MCP fin : un wrapper qui renvoie des lignes

Un MCP fin est un wrapper d'API léger posé sur les tables du référentiel. Il expose des lignes et des attributs, guère plus. Demandez-lui « montre-moi les applications taguées paiements » et il renvoie exactement cela : une liste plate d'enregistrements applicatifs, peut-être avec quelques colonnes.

Rien de mal à cela pour des recherches simples, et c'est rapide à construire. Mais l'agent à l'autre bout ignore ce que ces applications supportent, qui en est propriétaire, quels contrôles les couvrent, ou ce qui casse si l'une est décommissionnée. Le modèle derrière le serveur est en somme un tableur. L'agent peut lire ; il ne peut pas raisonner.

• Expose des lignes et des attributs, pas des relations
• Répond « qu'est-ce qui est tagué X » mais pas « qu'est-ce qui dépend de X »
• Aucune sémantique métier, aucun cycle de vie, aucun contexte de gouvernance
• Bon marché à livrer, mais l'agent hérite d'un monde superficiel

MCP natif : un serveur qui expose le métamodèle

Un MCP natif expose le métamodèle lui-même — la sémantique métier, les relations, les états de cycle de vie, les règles de gouvernance qui font d'un modèle EA bien plus qu'une liste. Posez la même question sur les paiements et un serveur natif peut tracer un chemin : de l'exigence réglementaire, au contrôle qui y répond, au processus métier qu'il protège, aux applications qui le font tourner, à l'infrastructure en dessous.

Le long de ce chemin, il fait apparaître ce qu'une liste plate ne peut pas : une application sans propriétaire nommé, un processus sans contrôle mappé, une dépendance qui pointe vers un composant obsolète. C'est la différence entre récupérer des données et raisonner sur un modèle. Il faut créditer Bizzdesign d'avoir soulevé publiquement ce cadrage fin-versus-natif ; c'est une façon réellement utile de séparer les connecteurs qui se contentent de répondre des connecteurs qui informent vraiment.

• Trace exigence → contrôle → processus → application → infrastructure
• Fait apparaître les trous de propriété et de couverture en raisonnant
• Porte du sens métier, pas seulement des valeurs de champs
• Transforme « connecté » en « capable d'analyse d'impact »

Mais le natif n'est pas non plus la ligne d'arrivée

C'est ici que la conversation du secteur tend à s'arrêter — et c'est ici qu'elle ne le devrait pas. Un MCP natif enrichit les réponses, mais riche ne veut pas dire digne de confiance. Deux modes de défaillance survivent même à un métamodèle parfait, et tous deux comptent davantage en finance régulée que l'écart fin-versus-natif lui-même.

Le premier est la fraîcheur. Un graphe natif qui reflète un instantané vieux de dix-huit mois raisonnera avec assurance sur une réalité qui n'existe plus — nommant des propriétaires partis, des contrôles retirés, des dépendances reroutées. La profondeur amplifie une donnée périmée ; elle ne la corrige pas. Le contexte doit être vivant pour mériter d'être interrogé, ce qui nous ramène à l'idée d'un référentiel agent-ready, rafraîchi en continu.

Le second est la souveraineté. Quand un agent interroge un graphe EA natif, il lit un plan quasi complet de l'organisation : l'inventaire complet des systèmes, les dépendances critiques, les composants obsolètes, parfois les mesures de sécurité. Si le modèle derrière la réponse tourne sur un LLM en cloud américain, ce plan quitte votre contrôle. Pour une institution régulée par DORA, la CSSF ou le règlement IA de l'UE, ce n'est pas un arbitrage de fonctionnalité — c'est un problème de résidence et de gouvernance. Un MCP réellement capable doit gouverner où vont les données, pas seulement qui a le droit de demander.

La profondeur qui compte vraiment pour la finance régulée

Empilez les exigences et une hiérarchie claire apparaît. La sémantique d'abord : le modèle doit porter du sens, pas seulement des lignes, sinon l'agent ne peut pas raisonner. La gouvernance ensuite : le modèle doit connaître ses propres règles, propriétaires et contrôles, sinon le raisonnement est sans ancrage. La fraîcheur en troisième : le modèle doit être vivant, sinon le raisonnement se trompe avec assurance. La souveraineté en dernier mais non négociable : le modèle doit garder le contexte sensible sous votre contrôle, sinon rien de ce qui précède n'est sûr à utiliser.

Fin contre natif est le coup d'ouverture de cet argument, pas la partie entière. Pour une banque ou un assureur dans l'UE, le vrai seuil c'est la sémantique plus la gouvernance plus la fraîcheur plus la souveraineté — les quatre. Un connecteur qui réussit les deux premières et ignore les deux dernières est un passif sûr de lui et beau parleur.

• Sémantique — raisonner sur un modèle, pas sur un tableur
• Gouvernance — propriétaires, contrôles et règles que le modèle connaît
• Fraîcheur — un référentiel vivant, pas un instantané vieillissant
• Souveraineté — un contexte qui reste dans l'UE et sous votre contrôle

Ce que cela signifie pour ArchiLU — et où nous sommes honnêtes

Disons-le clairement : ArchiLU ne livre pas de serveur MCP aujourd'hui. C'est une conviction et une direction de notre roadmap, pas une fonctionnalité que l'on active. Nous préférons être clairs là-dessus plutôt que de vendre un produit qui n'existe pas.

Ce que nous livrons, c'est la partie qui rend tout futur MCP digne d'intérêt. Un modèle EA connecté et gouverné — capacités, portefeuille applicatif, dépendances — qui porte de la sémantique plutôt que des lignes nues. Un hébergement en région UE ou on-premise sous votre contrôle, pour que le contexte n'ait jamais à quitter votre périmètre de souveraineté. Le français et l'anglais natifs, conçus autour des besoins de documentation DORA et CSSF. Et un prix publié, lisible avant même de parler aux ventes. Construisez le contexte correctement, gardez-le vivant, gardez-le souverain — alors le protocole posé dessus n'est qu'un détail. L'ordre, voilà le propos.

Une réserve honnête à garder en tête : un modèle EA et un MCP vous aident à documenter et à prouver votre architecture ; ils ne vous rendent pas conformes. La préparation réglementaire est une aide à la documentation et à la preuve, pas une garantie légale — traitez-la comme telle.

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