Architecture vivante : garder un référentiel EA prêt pour les agents 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 hérite de la fraîcheur du modèle qu'il lit — gardez le référentiel vivant avant d'y brancher quoi que ce soit.

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: Architecture vivante : garder un référentiel EA prêt pour les agents 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

Un agent hérite de la fraîcheur du modèle qu'il lit

La plupart des référentiels d'architecture d'entreprise ont été construits pour des lecteurs humains qui savent déjà quelles parties croire. Un architecte regarde un schéma, note silencieusement que la couche d'intégration n'a pas bougé depuis deux réorganisations, et la pondère. Cette correction tacite est invisible — et elle ne survit pas au contact d'un agent IA.

Un agent lit le modèle tel qu'il est écrit. Il ne sait pas que la dépendance qu'il vient d'utiliser pour répondre à « qu'est-ce qui casse si on retire cette base ? » a été saisie il y a dix-huit mois et accuse trois migrations de retard. Il répond avec la même assurance que les données soient fraîches ou fossilisées. La fraîcheur de votre référentiel cesse alors d'être un sujet discret de qualité pour devenir le plafond de confiance de toute réponse d'agent.

C'est pourquoi « l'architecture vivante » n'est pas un slogan. C'est la condition préalable. Avant de connecter le moindre agent à votre architecture — avant MCP, avant l'ingénierie de contexte — le modèle doit être assez vivant pour qu'une réponse qui en est tirée mérite qu'on agisse dessus.

L'instantané annuel est l'anti-pattern

Le modèle opérationnel par défaut, dans beaucoup d'organisations, est l'instantané annuel : un effort héroïque, une fois par an, pour rafraîchir le référentiel avant un comité ou un audit, après quoi il dérive intact pendant onze mois. Il paraît complet le jour de sa livraison et se dégrade dès le lendemain matin.

L'instantané échoue face à un agent de trois manières précises. Il n'a pas de propriétaires : personne n'est responsable quand un objet devient obsolète entre deux rafraîchissements. Il n'a pas de signal de fraîcheur : chaque objet paraît également à jour alors que la moitié est fossile. Et il n'a pas de discipline de décommission : les systèmes retirés persistent dans le graphe, et un agent raisonne joyeusement sur des choses qui n'existent plus.

Le contexte vivant est la posture inverse : la fraîcheur comme propriété continue du modèle, entretenue par les personnes les plus proches de chaque objet, plutôt qu'un projet qu'on mène une fois par an en espérant qu'il tienne.

• Pas de propriété — l'obsolescence n'est le travail de personne entre deux rafraîchissements
• Pas de signal de fraîcheur — objets fossiles et frais se ressemblent
• Pas de discipline de décommission — les systèmes retirés polluent chaque requête
• Pas de réconciliation — le modèle dérive du patrimoine réel par construction

Propriété par objet : l'unité de responsabilité

Le premier pas de l'instantané vers le vivant consiste à attribuer un propriétaire à chaque classe d'objet — applications, capacités, dépendances critiques, flux de données — et idéalement aux objets à forte criticité au sein de chacune. La propriété n'est pas un nom dans un champ de métadonnée pour la forme ; c'est la réponse à « qui remarque et corrige cela quand ça dérive ? ».

Une propriété opérationnelle est bornée. Le propriétaire d'une application est responsable de la véracité de la fiche de cette application : son statut de cycle de vie, ses dépendances, son hébergement et sa résidence de données. On ne lui demande pas de maintenir tout le modèle, seulement sa portion. Cette borne est ce qui rend la discipline tenable — et c'est exactement la granularité dont un agent a besoin, car une réponse consciente des permissions ne vaut que la propriété au niveau de l'objet qui la sous-tend.

• Attribuez des propriétaires par classe d'objet, puis par criticité au sein de la classe
• Rendez le propriétaire responsable de la vérité de cet objet, pas du modèle entier
• Enregistrez la propriété dans le modèle pour qu'elle soit interrogeable, pas dans un tableur annexe
• Traitez les absences de propriétaire comme un signal de premier ordre : un objet critique sans propriétaire est un risque, pas une case vide

Réconciliation et signaux de fraîcheur : prouver que le modèle est à jour

La propriété rend les objets responsables ; la réconciliation les rend vrais. Réconcilier, c'est comparer le référentiel aux sources vivantes qui connaissent déjà la réponse — la CMDB pour ce qui est réellement déployé, le compte cloud pour ce qui tourne réellement, le système d'identité pour qui possède réellement quoi — et résoudre les écarts selon une cadence connue. La modélisation manuelle seule dérive toujours ; c'est la réconciliation contre des sources autoritaires qui la rappelle à l'ordre.

Ensuite, rendez la fraîcheur visible. Chaque objet devrait porter une date de dernière vérification et, idéalement, un SLA de fraîcheur calibré sur sa volatilité : une cadence serrée pour le portefeuille applicatif et les dépendances critiques qui alimentent le reporting réglementaire, plus lâche pour une cartographie de capacités stable. Le but n'est pas de faire croire que tout est à jour — c'est d'être honnête sur ce qui l'est, pour qu'un agent (et un auditeur) voie la confiance derrière chaque fait au lieu de la présumer.

• Réconciliez contre des sources de vérité vivantes (CMDB, cloud, identité), pas la mémoire
• Fixez un SLA de fraîcheur par classe d'objet, dimensionné sur sa volatilité et sa criticité
• Affichez une date de dernière vérification et un indicateur d'obsolescence sur chaque objet
• Gouvernez par exception : agissez sur ce qui dépasse le SLA au lieu de tout revalider

Discipline de décommission : retirer est aussi important qu'ajouter

Les référentiels grossissent facilement et rétrécissent à contrecœur. Les nouveaux systèmes sont ajoutés avec un certain entrain ; les systèmes retirés ne sont presque jamais supprimés, parce que la suppression paraît risquée et que personne ne possède le nettoyage. Le résultat est un graphe peuplé de fantômes — applications éteintes depuis des années, dépendances vers des systèmes qui n'existent plus.

Pour un humain, c'est un encombrement bénin. Pour un agent, c'est un piège : il inclura volontiers un système décommissionné dans une analyse d'impact ou une chaîne de dépendances, produisant une réponse précise et fausse. L'architecture vivante traite la décommission comme un événement de premier ordre, avec son propre propriétaire et son propre déclencheur — quand un système est retiré du patrimoine réel, il est retiré du modèle, le changement étant tracé plutôt qu'abandonné en silence. Retirer le mort fait partie de garder le vivant digne de confiance.

Une gouvernance légère qui ne pourrit pas — et pourquoi c'est la condition préalable à l'IA

La gouvernance lourde est son propre mode d'échec : un cadre de revue exhaustif si exigeant qu'il est exécuté une fois, admiré, puis jamais répété. La discipline qui survit est la légère — un rituel de réconciliation court et récurrent que les propriétaires peuvent réellement tenir, centré sur les exceptions plutôt que sur la revalidation de tout le modèle à chaque cycle. Gouvernez les écarts : ce qui est obsolète, ce qui est sans propriétaire, ce qui a été retiré mais jamais supprimé.

Fait honnêtement, ce n'est pas de la magie et nous ne prétendrons pas le contraire. C'est de la discipline opérationnelle plus le bon outillage pour rendre la propriété, la réconciliation et la fraîcheur peu coûteuses à maintenir. Chez ArchiLU, nous sommes convaincus que ce contexte vivant et gouverné est la fondation dont une organisation régulée a besoin avant qu'un agent IA ne touche son architecture — souverain, continuellement rafraîchi, auditable. Cette direction de contexte continu est celle que nous construisons ; la discipline de fraîcheur de cet article paie de toute façon dès aujourd'hui, car un modèle digne de la confiance d'un agent est d'abord un modèle digne de la vôtre.

Pour savoir où se situe votre référentiel sur ce spectre, notre évaluation gratuite de maturité EA note dix dimensions — dont l'actualité et la gouvernance de votre modèle — et renvoie un plan d'action priorisé en environ dix minutes. C'est un moyen concret de voir à quel point votre architecture est réellement prête pour les agents avant d'y connecter quoi que ce soit.

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