Acquisition vs exposition du contexte : le vrai écart de préparation à 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

Exposer le contexte est une commodité ; acquérir et gouverner un bon contexte est le moat durable.

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: Acquisition vs exposition du contexte : le vrai écart de préparation à 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

Tout le monde résout la moitié facile du problème

Il y a une ruée vers l'or pour rendre le contexte accessible aux agents IA. Chaque semaine, des éditeurs annoncent des serveurs MCP, des connecteurs et des démos « parlez à vos données ». Cela ressemble à du progrès, et au sens étroit c'en est. Mais c'est résoudre la moitié facile du problème.

Deux tâches distinctes se cachent sous le mot « contexte ». La première est l'exposition : rendre le contexte accessible à un agent via une interface standard. La seconde est l'acquisition : construire d'abord un contexte qui vaut la peine d'être atteint. L'industrie court sur la première parce qu'elle se démontre bien. La valeur durable, et la défendabilité, résident dans la seconde.

Cet article trace cette ligne clairement, explique pourquoi l'acquisition est le vrai écart de préparation à l'IA, et reste honnête sur qui d'autre joue ici et sur ce qui, de notre propre réflexion, est livré versus encore une direction.

L'exposition est une commodité

L'exposition consiste à ouvrir une source pour qu'un agent puisse l'interroger — typiquement via un serveur MCP, le « port USB » émergent de l'IA. C'est réellement utile et de plus en plus standard. Mais standard est justement le point : un protocole que tout le monde implémente de la même manière est, par définition, une commodité.

Un point d'accès MCP ne crée pas de connaissance. Il transporte ce qui se trouve derrière lui. Branchez-en un sur un tableur périmé, et l'agent raisonne sur un tableur périmé, avec aisance et assurance. Le protocole ajoute de la portée, pas de la vérité. Donc « nous supportons MCP » n'est jamais un avantage défendable — c'est un prérequis, et un prérequis mince.

• Un protocole standard implémenté pareil par tous ne peut pas différencier un produit
• L'exposition ajoute de la portée, pas de l'exactitude — elle révèle la qualité déjà présente
• Un serveur MCP sur une source médiocre produit des réponses fluides, assurées et fausses

L'acquisition est le problème difficile et précieux

La vérité dont un agent a besoin est dispersée. Elle vit dans ServiceNow et la CMDB, dans les tickets Jira, dans Azure et d'autres clouds, dans l'annuaire IAM, dans M365 et une longue traîne de documents et tableurs. Aucun de ces systèmes ne s'accorde sur le nommage, la granularité ou la fraîcheur, et aucun, seul, ne décrit comment le patrimoine s'articule réellement.

L'acquisition est le travail qui transforme cette dispersion en quelque chose sur quoi un agent peut raisonner. Cinq étapes distinctes, chacune relevant d'une vraie ingénierie : agréger les sources, les normaliser dans un vocabulaire partagé, relier les éléments en un graphe connecté, qualifier ce qui est fiable et à jour, et gouverner qui et quoi peut l'utiliser. C'est là que la préparation à l'IA se gagne ou se perd.

• Agréger — tirer de ServiceNow, Jira, Azure, CMDB, IAM, M365 et des documents
• Normaliser — réconcilier nommage, granularité et doublons en un vocabulaire unique
• Relier — connecter capacités, applications, dépendances, flux de données et risques
• Qualifier — marquer ce qui est à jour, sourcé et fiable, et ce qui est périmé
• Gouverner — contrôler l'accès en tenant compte des permissions et de la résidence des données

Pourquoi l'acquisition est défendable et l'exposition ne l'est pas

Un graphe de contexte bien acquis accumule de la connaissance. Chaque réconciliation, chaque relation qualifiée, chaque correction réinjectée rend le modèle un peu plus précis et un peu plus spécifique à l'organisation. Cette vérité accumulée et gouvernée est difficile à copier — un concurrent ne peut pas cloner deux ans de normalisation et de mise en relation soigneuses du jour au lendemain.

Une couche d'exposition a l'économie inverse. N'importe qui peut monter un serveur MCP en un sprint. Rien n'est accumulé, rien n'est spécifique à l'organisation, rien ne s'améliore avec l'usage. C'est la forme typique d'une commodité face à un actif : le rempart est le graphe que vous avez construit, pas le port que vous avez ouvert.

Soyons honnêtes : ServiceNow et SAP jouent aussi ici

Il serait malhonnête de prétendre que l'acquisition est un terrain vierge. ServiceNow a beaucoup investi dans une CMDB et un service graph ; SAP détient un contexte profond sur les processus et les données de référence. Dans leurs domaines, ils acquièrent du contexte à une échelle et une étendue qu'ArchiLU n'égale pas, et nous ne le masquerons pas.

Notre avantage n'est pas l'étendue brute — c'est l'angle. Nous nous concentrons sur le contexte d'architecture pour les institutions régulées FR/Lux/UE, sous une contrainte de souveraineté et de gouvernance autour de laquelle les grandes suites opérationnelles ne sont pas conçues : un contexte sur lequel on peut raisonner sans que le plan sensible quitte votre contrôle, apte à la scrutation DORA, NIS2, RGPD et EU AI Act. Un périmètre plus étroit, un fit plus net — pas un filet plus large.

• ServiceNow / SAP : acquisition de contexte opérationnel forte et large dans leurs domaines
• ArchiLU : contexte d'architecture sous un angle régulé, souverain, orienté gouvernance
• Nous nous battons sur le fit et le contrôle de la résidence des données, pas sur l'étendue

L'acquisition continue est le cap — et notre conviction

Une acquisition mature n'est jamais terminée, parce que le patrimoine ne cesse de changer. Des systèmes sont ajoutés, retirés, réorganisés ; ce qui était vrai au trimestre dernier dérive. L'objectif n'est donc pas un import ponctuel mais une acquisition continue — un modèle qui se réconcilie et se re-qualifie au fil de l'évolution du réel.

Nous sommes honnêtes sur l'écart entre la vision et le livré. Un serveur MCP souverain et conscient de la résidence des données est une conviction et une feuille de route, pas un produit achetable aujourd'hui. Ce qui existe est un modèle EA connecté — capacités, portefeuille applicatif et dépendances — hébergé en région UE ou on-premise sous votre contrôle, en français et anglais natifs, conçu autour des besoins de documentation DORA et CSSF. (Un outil aide à documenter et prouver la gouvernance ; il ne vous rend pas conforme à lui seul.)

Le point stratégique tient quel que soit le calendrier : construisez d'abord le contexte, gouvernez-le, et traitez l'exposition comme la dernière étape, la facile. Si vous ne retenez qu'une chose, retenez l'ordre — acquérir et qualifier la vérité avant de brancher le moindre agent dessus. Le moyen le plus rapide de voir où se situe votre organisation sur cette courbe est notre évaluation gratuite de maturité EA.

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