Dans un monde d'agents, qui possède la couche de contexte de l'entreprise ?

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

Quand les agents font les clics, l'interface cesse d'être le rempart

Pendant deux décennies, le logiciel d'entreprise s'est disputé sur la surface que regardait un humain : le tableau de bord, le workflow, le générateur de rapports. L'interface était le produit, et la plus belle, la plus rapide, emportait souvent l'affaire.

Les agents changent la géométrie de cette compétition. Quand un agent IA lit votre portefeuille applicatif, rédige l'analyse d'impact et réécrit la décision, moins d'humains naviguent dans les écrans. L'agent ne se soucie pas de l'élégance d'un graphique ; il se soucie de savoir si la donnée sous-jacente est correcte, complète et à jour. À mesure que la médiation passe des clics humains aux appels d'agents, la question glisse discrètement de « quelle interface est la meilleure ? » vers « à quel contexte l'agent peut-il se fier ? ».

Ce n'est pas une prédiction de disparition des écrans. C'est l'observation que le centre de gravité se déplace — de la présentation vers la substance que l'agent consulte.

Le vrai terrain disputé : la couche de contexte de l'entreprise

Les agents ont besoin d'un point d'où raisonner. À côté des systèmes de référence — l'ERP, le CRM, l'ITSM qui détiennent la vérité transactionnelle — une seconde couche émerge : un système de contexte, le modèle qui dit à un agent comment l'entreprise s'articule réellement.

L'architecture d'entreprise est le foyer naturel de cette couche. Elle détient déjà la carte vivante des capacités, applications, dépendances et flux de données — exactement ce dont un agent a besoin pour répondre à « qu'est-ce qui dépend de ce système ? » ou « que casse-t-on si on le retire ? ». La couche de contexte de l'entreprise n'est pas un nouveau mot à la mode pour un tableau de bord ; c'est le modèle connecté sur lequel les agents raisonnent.

Si les agents deviennent les premiers consommateurs de la connaissance de l'entreprise, alors celui qui possède la couche de contexte la plus fiable, complète et gouvernée tient une position plus forte que celui qui possède le plus beau front-end. C'est le déplacement qu'il faut prendre au sérieux.

Le piège : un MCP nu est une commodité

Il est tentant de conclure que la réponse est de « posséder le protocole » — de livrer un point d'accès Model Context Protocol et de crier victoire. C'est le piège, et il vaut la peine de le nommer clairement.

Le MCP est un protocole, pas un produit. La bonne analogie est HTTP. Personne n'a gagné le web en possédant HTTP ; le protocole était une commodité, et la valeur vivait dans ce qui transitait par-dessus — le contenu, les services, les données. Selon la même logique, un point d'accès MCP est un prérequis, pas un rempart. Une fois un protocole standard, le supporter est attendu, pas différenciant.

Nous tenons cette discipline pour notre propre travail aussi. ArchiLU ne livre pas de serveur MCP souverain aujourd'hui — nous le décrivons comme une conviction et une direction vers laquelle nous construisons, pas comme une fonctionnalité livrée. L'argument n'est jamais « nous faisons du MCP ». L'argument est ce qui se trouve derrière.

• Le protocole est le tuyau ; la valeur est ce qui y circule
• Supporter MCP est attendu, pas différenciant
• Un protocole au-dessus d'un référentiel obsolète ou superficiel ne vaut rien
• L'ordre de construction : contexte d'abord, gouvernance ensuite, protocole en dernier

Le rempart est le graphe de contexte gouverné, pas le protocole

Si le protocole est une commodité, l'actif défendable est le graphe de contexte gouverné qui se trouve derrière : le modèle connecté de l'entreprise, et les règles autour de qui peut le lire, le modifier et en répondre.

Trois propriétés décident si ce graphe est digne de confiance. La complétude — représente-t-il réellement le patrimoine, ou une fraction ? La fraîcheur — est-ce un modèle vivant, continuellement rafraîchi, ou un instantané vieux de dix-huit mois qui ment discrètement à chaque agent qui le lit ? La gouvernance — existe-t-il un chemin contrôlé, revu et auditable pour la maintenance du contexte ? Un beau protocole au-dessus d'un graphe obsolète ou partiel est pire qu'inutile, car les agents raisonneront avec assurance sur un contexte faux.

La possession ne se gagne donc pas par le protocole. Elle se gagne en étant la source la plus fiable, complète et gouvernée vers laquelle les agents convergent.

Pour les institutions régulées, souveraineté et gouvernance décident de la possession

Il y a une seconde raison pour laquelle la possession est disputée, et elle pèse surtout dans la finance régulée. Une carte d'architecture d'entreprise est proche d'un plan complet de l'organisation : l'inventaire des systèmes, les dépendances critiques, les composants obsolètes, les flux de données sensibles, parfois les mesures de sécurité elles-mêmes.

Laisser des agents raisonner dessus sans contrôler où vont les données n'est pas un choix d'UX — c'est une exposition DORA, NIS2, RGPD et règlement européen sur l'IA. Envoyer une carte quasi complète des systèmes d'une banque à un modèle hébergé sur un cloud américain est exactement le genre de décision qu'une équipe face à la CSSF ne peut pas laisser passer. Donc pour ces acheteurs, « qui possède la couche de contexte » est indissociable de « où vit le contexte et qui peut en répondre ».

C'est la couche de contexte souveraine : un contexte d'entreprise gouverné qu'une IA peut utiliser sans que les données quittent votre contrôle. Pour être clair, c'est une aide à l'outillage et à la documentation, pas une garantie de conformité légale — un outil aide à documenter et prouver, il ne vous rend pas conforme à lui seul. Pour les institutions régulées, souveraineté et gouvernance ne sont pas des cases sur une grille comparative ; ce sont les conditions sous lesquelles un agent est autorisé à approcher le contexte tout court.

• La carte d'architecture est un plan quasi complet de l'organisation
• Un accès agent non contrôlé est une exposition DORA/NIS2/RGPD/règlement IA
• La souveraineté, c'est un contexte utilisable par un agent sans que les données quittent votre contrôle
• L'outillage documente et prouve ; il ne vous rend pas conforme à lui seul

La curation ne meurt pas — elle devient gouvernance

Il serait malhonnête d'affirmer que l'artisanat humain de la modélisation s'évanouit simplement. Ce n'est pas le cas. À mesure que l'interface recule, le travail de décider ce qui est vrai, ce qui est à jour et ce qui est autorisé remonte en amont — de l'écran utilisateur vers la gouvernance.

Les acteurs en place le comprennent. ServiceNow, SAP et les plateformes EA établies détiennent des actifs réels et profonds — de vastes systèmes de référence, une modélisation mature, de larges bases installées — et ils sont bien placés pour exposer du contexte aux agents. Leur force est réelle. La question ouverte est l'intersection qu'ils servent moins naturellement pour la finance régulée européenne : contexte vivant, raisonnement réglementaire et souveraineté réunis. C'est la couture, pas une affirmation que les géants seraient absents.

Le takeaway orienté décision : cessez d'optimiser pour le plus bel écran et commencez à demander à qui l'on peut confier le contexte que vos agents consulteront. Si vous êtes une institution régulée, pesez cette question sur la souveraineté et la gouvernance, pas sur les tableaux de bord. Un point de départ concret est votre propre maturité — notre évaluation gratuite de maturité EA note dix dimensions en environ dix minutes et montre à quel point votre contexte est réellement prêt pour les agents.

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