MCP et architecture d'entreprise : 6 cas d'usage que les agents IA ouvrent

Perspective métier pour ce sujet

Chaque cas d'usage n'est fiable que dans la mesure de la fraîcheur et de la gouvernance du contexte d'architecture derrière la requête.

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 : 6 cas d'usage que les agents IA ouvrent
• 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

D'une carte statique à un système de contexte

La plupart des référentiels d'architecture d'entreprise sont lus par des humains, lentement, un diagramme à la fois. Le changement en cours n'est pas que quelqu'un a ajouté un protocole nommé MCP — MCP est de la tuyauterie, le port USB de l'IA, et personne n'achète un produit parce qu'il le parle. Le changement, c'est que le modèle EA peut devenir un système de contexte : une couche gouvernée que les agents IA interrogent directement, aux côtés des systèmes de référence comme votre CRM, votre ERP et votre catalogue de services.

Quand cela arrive, une question en langage naturel remplace une semaine de recoupement de tableurs. Les six cas d'usage ci-dessous sont ceux qui comptent le plus pour une entreprise régulée. Pour chacun, nous donnons la question que vous poseriez réellement, ce que la réponse débloque et — tout aussi important — la limite honnête de ce qu'un agent peut faire. Gardez un principe d'un bout à l'autre : la valeur n'est pas le protocole, c'est la qualité, la fraîcheur et la gouvernance du contexte sur lequel l'agent raisonne.

1. Rationalisation applicative — trouver et justifier le recouvrement

La requête : « Où avons-nous des applications qui se recouvrent, et lesquelles faut-il retirer et pourquoi ? » Un agent parcourt la cartographie des capacités, trouve les capacités servies par plus d'une application, et recoupe coût, propriété, nombre d'utilisateurs et cycle de vie pour proposer des candidats au retrait avec un argumentaire.

Ce qu'elle débloque : une liste courte défendable plutôt qu'un débat politique. La rationalisation cale souvent parce que personne ne peut prouver le recouvrement rapidement ; un agent qui raisonne sur un portefeuille vivant le fait remonter en une phrase et montre les dépendances qu'il faudrait dénouer d'abord.

La limite honnête : l'agent classe et explique, il ne décide pas. Savoir si un doublon est un vrai gaspillage ou une redondance volontaire pour la résilience est un jugement humain, et la liste courte ne vaut que ce que valent les attributs de coût et d'usage du modèle.

2. Analyse d'impact — savoir ce qui casse avant d'y toucher

La requête : « Quels sont les effets en aval d'une migration du CRM ? » L'agent traverse le graphe de dépendances depuis le CRM vers l'extérieur — intégrations, flux de données, capacités et processus métier qui le consomment — et renvoie le rayon d'impact sous forme de liste classée plutôt que d'un diagramme à décoder à la main.

Ce qu'elle débloque : une planification du changement qui part des faits. Le risque de migration et de décommissionnement se cache dans les dépendances de second et troisième ordre que personne ne se rappelle ; un agent qui raisonne sur le graphe les rend explicites avant le comité de changement, pas pendant la revue d'incident.

La limite honnête : il ne peut tracer que les dépendances modélisées. Une intégration non documentée ou un consommateur de shadow IT est invisible pour l'agent. L'analyse d'impact est un multiplicateur sur un graphe complet et un faux réconfort sur un graphe lacunaire.

3. Reporting de conformité — cadrer la réglementation, plus vite

La requête : « Quels systèmes entrent dans le périmètre DORA ? » L'agent identifie les applications et l'infrastructure soutenant vos fonctions critiques et importantes, fait remonter les prestataires tiers derrière elles, et assemble une première liste de périmètre avec les preuves de dépendance attachées.

Ce qu'elle débloque : la passe de cadrage fastidieuse et sujette aux erreurs devient un brouillon en quelques minutes, laissant à votre équipe le travail de jugement — confirmer quelles fonctions sont réellement critiques, où se situent les frontières, quelles preuves un régulateur acceptera.

La limite honnête, dite clairement : c'est une aide à la documentation et à la preuve, pas un verdict de conformité. Un agent aide à documenter et à prouver ; il ne vous rend pas conforme. L'interprétation des attentes DORA, NIS2 ou CSSF, et la position face au régulateur, restent à un humain qui en répond.

4. Risque et vulnérabilités — concentrer l'attention là où ça compte

La requête : « Montre-moi les applications à criticité élevée, hébergées on-premise, avec des vulnérabilités connues. » L'agent filtre le portefeuille sur plusieurs attributs à la fois — criticité métier, modèle d'hébergement, statut de vulnérabilité, propriété — et renvoie une surface de risque ciblée plutôt qu'un tableur de 400 lignes.

Ce qu'elle débloque : un tri par intersection. Les systèmes dangereux sont rarement ceux signalés sur une seule dimension ; ils se trouvent au croisement d'une criticité élevée, d'une posture d'hébergement faible et d'une vulnérabilité ouverte. Un agent exprime cette intersection en une question.

La limite honnête : l'agent reflète les données de vulnérabilité et de criticité que vous lui fournissez. C'est une loupe sur le modèle, pas un scanner — il ne découvre pas les vulnérabilités, il corrèle celles déjà enregistrées. Gardez ces données à jour ou la loupe déforme.

5. Alignement stratégique — relier les initiatives aux objectifs

La requête : « Quelles initiatives correspondent à nos objectifs finance, et quels objectifs n'ont aucune initiative derrière eux ? » L'agent trace la chaîne des objectifs stratégiques jusqu'aux capacités dont ils dépendent puis aux projets et applications qui les portent, exposant à la fois la couverture et les manques.

Ce qu'elle débloque : une conversation portefeuille ancrée dans le modèle plutôt que dans des slides. L'architecture gagne sa place à la table de la stratégie quand elle peut montrer, à la demande, où l'investissement se concentre et où un objectif affiché n'a rien derrière lui.

La limite honnête : l'alignement n'est réel que dans la mesure des liens du modèle. Si objectifs, capacités et initiatives ne sont pas connectés, l'agent n'a rien à traverser. Ce cas d'usage récompense les organisations qui entretiennent ces relations et expose celles qui ne le font pas.

6. Fin de vie et obsolescence — voir la falaise avant de l'atteindre

La requête : « Quelles unités métier dépendent de systèmes proches de la fin de vie ? » L'agent joint les données de cycle de vie technologique à la cartographie des capacités et des unités métier, et renvoie qui est exposé à quel risque d'obsolescence, classé selon la criticité de la fonction dépendante.

Ce qu'elle débloque : une remédiation proactive. Le risque de fin de vie est généralement découvert tard, quand une annonce fournisseur percute un processus critique. Un agent qui raisonne sur les attributs de cycle de vie transforme cette surprise en un backlog planifié et priorisé.

La limite honnête : cela dépend entièrement d'attributs de cycle de vie renseignés et exacts. Des dates de fin de support fausses ou manquantes produisent un faux sentiment de sécurité. Le cas d'usage ne vaut que la discipline derrière les données de cycle de vie.

Le caveat qui fait ou défait les six : la souveraineté

Relisez ces six requêtes et remarquez ce qu'elles ont en commun. Chacune fait raisonner l'agent sur un plan quasi complet de l'organisation : l'inventaire complet des systèmes, les dépendances critiques, les composants obsolètes, les vulnérabilités connues, les flux de données sensibles. C'est précisément l'actif qu'une institution régulée ne peut pas se permettre de laisser fuir.

Ardoq et Bizzdesign se précipitent pour s'approprier « MCP × EA », mais leur course repose sur une hypothèse non dite — que connecter Claude, ChatGPT, Gemini ou Copilot à votre référentiel EA est acceptable. Pour la finance régulée, ce ne l'est souvent pas : envoyer ce plan à un LLM en cloud américain est une exposition DORA, CSSF, RGPD et règlement IA de l'UE. La question sans réponse n'est pas « l'IA peut-elle parler à mon architecture ? » mais « peut-elle le faire sans que l'architecture ne quitte mon contrôle ? »

C'est la conviction vers laquelle ArchiLU construit — une couche de contexte souveraine où l'IA raisonne sur la carte sans que la carte ne quitte l'UE ou votre contrôle. Pour être précis sur la discipline de revendication : le serveur MCP d'ArchiLU n'est pas livré. Ces six cas d'usage décrivent la direction d'une couche de contexte souveraine et de qualité réglementaire, pas un interrupteur que vous actionnez aujourd'hui. Ce qui existe maintenant, c'est le modèle EA connecté, le français et l'anglais natifs, un prix publié, et un hébergement en région UE ou on-premise sous votre contrôle — le contexte qui doit venir en premier.

Pourquoi le profil régulé s'accorde à cette approche

Un RSSI, un DPO ou un responsable de l'architecture dans une institution régulée de l'UE n'a pas besoin d'une IA plus tape-à-l'œil ; il a besoin d'une IA qu'il peut présenter à un auditeur. L'ordre de construction compte ici : contexte d'abord, puis intelligence réglementaire, puis le protocole. Un MCP au-dessus d'un référentiel figé ou superficiel est sans valeur — la valeur est le contexte vivant et gouverné en dessous, et l'assurance que l'interroger ne déplace pas de données sensibles au-delà d'une frontière.

Si ces cas d'usage décrivent des questions que votre équipe pose lentement aujourd'hui, le premier geste n'est pas de courir après un protocole. C'est de rendre le contexte en dessous agent-ready : à jour, gouverné et souverain. Commencez par voir où en est réellement votre pratique d'architecture avec notre évaluation gratuite de maturité EA — dix dimensions, un plan d'action priorisé, environ dix minutes — et lisez le hub du cluster sur MCP et le système de contexte pour voir comment les pièces s'assemblent.

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