Pourquoi la plupart des référentiels EA sont trop périmés pour nourrir un agent 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

Un agent sur un référentiel mort ne vaut rien : contexte pourri en entrée, absurdités confiantes en sortie — la bataille est l'acquisition, pas l'exposition.

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: Pourquoi la plupart des référentiels EA sont trop périmés pour nourrir un agent 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 se rue pour exposer le référentiel. Presque personne ne vérifie s'il est vivant.

Le discours est partout désormais : « parlez à votre architecture ». Ardoq, Bizzdesign et une dizaine d'autres branchent des agents IA sur le référentiel d'architecture d'entreprise pour qu'un RSSI ou un DSI puisse poser une question en langage naturel et recevoir une réponse sur l'ensemble du patrimoine. C'est une bonne idée — et elle repose sur une hypothèse que presque personne n'énonce à voix haute.

L'hypothèse est qu'il existe, à l'autre bout de cette connexion, un référentiel peuplé, exact et à jour. Dans la plupart des organisations, ce n'est pas le cas. Et cet unique écart fait toute la différence entre un agent IA utile et un agent silencieusement, et avec assurance, dangereux.

Cet article parle de cet écart. L'argument est simple et inconfortable : un serveur MCP au-dessus d'un référentiel périmé ne vaut rien. Le marché se bat sur l'exposition du contexte — le protocole, l'intégration, la démo « parlez à ». Le vrai combat, c'est l'acquisition du contexte : garder le modèle vivant. C'est le problème le plus difficile, et c'est celui qui décide si tout cela fonctionne.

Le secret gênant du marché : la plupart des référentiels sont déjà trop périmés

Entrez dans une entreprise typique et regardez honnêtement son référentiel EA. Selon la plupart des estimations du secteur, la grande majorité d'entre eux — un chiffre souvent avancé autour de neuf sur dix — se trouvent dans un ou plusieurs de ces états : incomplets, vieux de douze à dix-huit mois, maintenus à la main par une ou deux personnes, et déconnectés des systèmes qui décrivent réellement le patrimoine en service. Ce n'est pas une statistique précise et auditée et nous ne la présenterons pas comme telle ; c'est le schéma constant et observé dans les commentaires d'analystes et l'expérience de terrain. À prendre comme une vérité directionnelle, pas comme une citation.

Les causes sont structurelles, pas l'échec d'une équipe en particulier. Les référentiels sont peuplés lors d'un projet intense, puis la maintenance retombe sur des mises à jour manuelles qui rivalisent avec le quotidien de chacun. Le patrimoine, lui, bouge sans cesse — migrations cloud, décommissionnements, shadow IT, fusions — pendant que le modèle reste figé. La dérive est l'état par défaut d'un référentiel d'architecture, et elle s'installe vite.

Pour un usage humain, cela a toujours été tolérable. Un architecte qui lit un schéma vieux de deux ans sait s'en méfier, recoupe avec l'équipe, comble les trous de mémoire. Le référentiel était un point de départ pour une conversation, pas le dernier mot. C'est précisément cette tolérance qui se brise quand on met un agent dans la boucle.

Pourquoi les agents n'héritent pas seulement de la péremption — ils l'amplifient

Un modèle de langage n'a aucun instinct de la fraîcheur. Donnez-lui un enregistrement et il raisonnera dessus comme s'il était vrai, puis exprimera la conclusion dans une prose fluide et assurée. Il ne nuance pas parce que la donnée est ancienne ; il ne sait pas qu'elle est ancienne. La péremption qu'un humain escompte silencieusement, un agent la blanchit silencieusement en une réponse nette et qui sonne juste.

C'est cela, l'amplification. Un fait erroné enfoui dans un tableur oublié est inerte. Le même fait erroné, récupéré par un agent et livré sous la forme « cette application n'a pas de dépendance amont sur le cœur de paiement historique, donc le décommissionnement est peu risqué », devient l'entrée d'une décision — formulé avec exactement l'assurance qui dissuade de revérifier. Contexte erroné en entrée, absurdités assurées en sortie.

Le danger croît avec la qualité de l'agent. Mieux il écrit, mieux le problème de fraîcheur se cache derrière. Une réponse maladroite invite à l'examen ; une réponse soignée invite à la confiance. Plus la fraîcheur de votre référentiel est mauvaise, plus un agent éloquent joue contre vous — pas pour vous.

« Parlez à votre architecture » suppose un référentiel peuplé et frais qui existe rarement

Regardez attentivement les démos des acteurs établis et vous remarquerez qu'elles tournent toutes sur un modèle magnifiquement complet et à jour — le jeu de données de référence de l'éditeur, ou un environnement client soigné spécialement pour la démo. La cartographie des capacités est pleine. Les dépendances sont câblées. Le portefeuille applicatif est à jour. Évidemment que l'agent donne une réponse brillante ; il raisonne sur un référentiel dans un état où presque aucune production ne se trouve réellement.

Une démo propre n'a rien de malhonnête. Le problème est le saut silencieux de « l'agent répond bien ici » à « l'agent répondra bien sur votre référentiel ». Ce saut n'est valide que si votre référentiel est aussi vivant que celui de la démo — et tout le propos de la section précédente est qu'il ne l'est généralement pas.

La bonne question à poser à tout éditeur qui vous vend « parlez à votre architecture » n'est donc pas la qualité de la conversation. C'est : qu'est-ce qui maintient vrai le modèle derrière cette conversation ? Si la réponse est « votre équipe le maintient », vous avez acheté une interface plus rapide vers votre propre péremption.

Ce qu'exige réellement un référentiel vivant et agent-ready

« Contexte vivant » et « référentiel agent-ready » ne sont pas des slogans — ils décrivent un standard concret et exigeant. Trois choses séparent un référentiel vivant d'un instantané, et un référentiel auquel il en manque une seule n'est pas prêt à servir de vérité de référence à un agent.

Premièrement, la réconciliation continue avec les sources de vérité. Le modèle doit être confronté, automatiquement et souvent, aux systèmes qui décrivent le patrimoine réel — la CMDB, l'inventaire cloud, les pipelines de déploiement, le terrain. La réconciliation n'est pas un import ponctuel ; c'est un processus permanent qui fait apparaître les divergences entre le modèle et la réalité pour qu'on les corrige au lieu de les oublier.

Deuxièmement, l'appropriation. Chaque élément — chaque capacité, application, dépendance — a besoin d'un responsable de son exactitude, et non d'une vague responsabilité collective qui fait que personne ne regarde. L'appropriation est ce qui transforme une dérive détectée en un fait corrigé.

Troisièmement, les signaux de fraîcheur. Le référentiel doit porter, élément par élément, la date et la source de sa dernière vérification. C'est le super-pouvoir discret pour les agents : un modèle qui connaît sa propre fraîcheur permet à un agent de dire « cette dépendance a été confirmée il y a six jours » ou, tout aussi important, « ceci n'a pas été vérifié depuis plus d'un an — à manier avec prudence ». Un agent capable de signaler sa propre incertitude vaut bien plus qu'un agent qui a toujours l'air sûr.

• Réconciliation continue avec les systèmes sources — dérive détectée et corrigée, pas accumulée
• Appropriation claire par élément — responsabilité de l'exactitude, pas négligence collective
• Signaux de fraîcheur par élément — pour que l'agent sache, et puisse dire, à quel point se fier à chaque fait
• Une structure conçue pour être réconciliée, plutôt qu'un document peuplé une fois et qui se dégrade

L'acquisition est la partie difficile ; l'exposition est le dernier kilomètre facile

Prenez du recul et le tableau concurrentiel s'inverse. Ajouter MCP — exposer le référentiel pour qu'un agent l'interroge — est la partie facile, en voie de banalisation. C'est un protocole ; ce sera une case à cocher sur chaque outil EA d'ici un an. L'exposition est le dernier kilomètre, et les derniers kilomètres ne sont pas là où vivent les avantages durables.

L'acquisition du contexte — peupler, réconcilier en continu et gouverner le modèle pour qu'il reste vrai — est la partie difficile, la partie lente, celle qui détermine vraiment si « parlez à votre architecture » produit de la lucidité ou de l'hallucination. C'est là que se trouvent l'ingénierie réelle et la valeur réelle. C'est ingrat : intégrations, logique de réconciliation, flux d'appropriation, suivi de fraîcheur. Cela démontre moins bien qu'une fenêtre de chat. C'est aussi la seule chose qui rende cette fenêtre de chat digne de confiance.

Nous serons honnêtes sur notre propre position, par discipline. ArchiLU construit vers un contexte continu et souverain — c'est notre conviction et notre direction, pas un bouton magique déjà livré. Nous ne revendiquons pas un auto-peuplement qui garde votre référentiel frais pendant que vous dormez ; quiconque le revendique vend la version facile. Ce à quoi nous nous engageons, c'est la version difficile : une couche de contexte d'entreprise acquise et maintenue vivante sous votre contrôle et en résidence de données UE, structurée pour rendre la réconciliation possible plutôt que de la laisser à l'héroïsme manuel. C'est du travail. Nous préférons vous dire que c'est du travail plutôt que de faire croire à de la magie.

Comment évaluer la maturité de votre référentiel avant de brancher un agent

Avant de connecter le moindre agent à votre architecture, faites un test d'honnêteté de cinq minutes. Choisissez cinq applications critiques pour l'activité. Pour chacune, répondez à trois questions : à quand remonte la dernière confrontation de cet élément à la réalité ? Qui est responsable de son exactitude ? Son graphe de dépendances enregistré correspond-il encore à ce que fait réellement la production aujourd'hui ?

Si vous savez répondre aux trois pour la plupart des cinq, vous avez les prémices d'un référentiel agent-ready — et l'exposer à un agent créera probablement de la valeur. Si vous ne savez pas répondre à la première question pour la plupart, arrêtez-vous. Vous n'avez pas une couche de contexte vivante ; vous avez un document. Y connecter un agent ne fera pas apparaître ce problème — il le cachera derrière une prose assurée, ce qui est le pire résultat possible pour une institution régulée qui doit défendre ses décisions.

Le geste constructif est de traiter la maturité comme le projet, l'exposition étant la récompense au bout. Définissez ce que « vérifié » signifie dans votre contexte, attribuez les responsabilités, montez la réconciliation avec vos sources réelles, et alors seulement activez l'agent. L'ordre de construction compte : le contexte d'abord, la conversation ensuite. Pour un point de départ structuré, notre évaluation gratuite de maturité EA note dix dimensions en une dizaine de minutes et vous dira, honnêtement, à quelle distance votre référentiel se trouve d'être quelque chose qu'un agent IA peut sereinement croire.

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