Système de contexte vs système d'enregistrement : la couche qui manque à l'ère des agents

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

Les agents interrogent une nouvelle couche — le System of Context — et qui la gouverne devient stratégique ; l'EA en est le foyer naturel.

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: Système de contexte vs système d'enregistrement : la couche qui manque à l'ère des agents
• 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

Pendant 20 ans, la valeur a vécu dans le système d'enregistrement

Pendant deux décennies, le logiciel le plus précieux de l'entreprise a été le système d'enregistrement. Salesforce est devenu le référentiel faisant autorité sur les clients, SAP sur la finance et la supply chain, ServiceNow sur les opérations IT, Workday sur les RH. Chacun a gagné en devenant l'unique lieu de confiance où s'écrivaient les transactions d'un domaine. Le marché a richement récompensé ce rôle : un système d'enregistrement est collant, audité et impossible à arracher à la légère.

Mais un système d'enregistrement est bâti pour bien répondre à une seule question : ce qui s'est passé, dans ce domaine. Salesforce connaît votre pipeline. SAP connaît votre grand livre. ServiceNow connaît vos tickets. Aucun ne sait comment ces systèmes se connectent entre eux, quelle capacité métier chacun sert, ni ce qui casserait si vous en éteigniez un. Cette connaissance transversale n'a jamais été leur métier — et pendant vingt ans, elle n'avait pas à l'être.

Les agents ont besoin d'une autre question : le système de contexte

Les agents IA changent la question. Demandez à un agent d'évaluer l'impact du décommissionnement d'un module de core banking, ou de signaler quels systèmes touchent des données personnelles avant une migration, et il a immédiatement besoin d'une connaissance qu'aucun système d'enregistrement ne détient. Il doit savoir ce qui existe, qui en est responsable, quelles données sont touchées, quelle réglementation s'applique et ce qui dépend de quoi.

C'est une couche différente. Appelons-la le système de contexte : la carte gouvernée de la façon dont le patrimoine s'assemble, située au-dessus des enregistrements plutôt que dans l'un d'eux. Un système d'enregistrement répond à « ce qui s'est passé ». Un système de contexte répond à « qu'est-ce qui casse si… », « qu'est-ce qui est redondant » et « qu'est-ce qui est à risque ». Le premier est un grand livre ; le second est un graphe de relations — et c'est précisément un graphe qu'un agent doit parcourir pour raisonner sur tout ce qui dépasse un seul système.

• Ce qui existe — l'inventaire complet des systèmes, pas la tranche d'un domaine
• Qui en est responsable — une redevabilité vers laquelle un agent peut router une décision
• Quelles données sont touchées — les flux sensibles qui déclenchent la réglementation
• Quelle réglementation s'applique — périmètre DORA, NIS2, RGPD, EU AI Act par système
• Ce qui dépend de quoi — le graphe de dépendances qui transforme un changement en rayon d'impact

Aujourd'hui ce contexte est dispersé — et c'est là l'opportunité

Si personne n'a encore gagné le système de contexte, c'est qu'il ne réside nulle part de propre. Il est étalé entre un schéma Visio de l'an dernier, trois tableurs, une page Confluence que personne ne met à jour, une CMDB qui a dérivé, et la mémoire de deux architectes sur le point de partir à la retraite. Un agent pointé sur ce désordre produit des absurdités assurées, car le contexte sur lequel il raisonne est partiel, périmé et contradictoire.

Cette dispersion est précisément l'ouverture. Qui consolide ce contexte en un seul endroit — et, surtout, le maintient vivant et gouverne qui peut l'utiliser — transforme une connaissance tribale dispersée en actif stratégique. Il devient la couche par laquelle passent chaque agent, chaque analyse d'impact et chaque décision de transformation. Les systèmes d'enregistrement ont mis vingt ans à devenir indispensables en possédant la vérité d'un domaine. L'équivalent de la décennie à venir, c'est posséder la vérité sur la façon dont les domaines se relient.

L'architecture d'entreprise est le foyer naturel du système de contexte

Voici ce que la plupart des discussions ratent : le système de contexte n'est pas une nouvelle catégorie à inventer de zéro. Une discipline a passé toute son existence à modéliser exactement cela. L'architecture d'entreprise décrit les capacités, les applications, les technologies, les flux de données et les dépendances entre eux. Sa raison d'être est de décrire comment le patrimoine s'assemble — pas ce qu'un système isolé a enregistré.

Un modèle EA bien tenu est donc ce que la plupart des organisations possèdent déjà de plus proche d'un système de contexte. L'écart n'est pas conceptuel ; il est opérationnel. Trop de référentiels EA ont été bâtis comme un exercice de documentation — exacts le jour de leur achèvement, puis figés en instantané de dix-huit mois. Un agent ne peut pas raisonner sur un instantané. Le travail consiste donc à traiter le modèle EA comme un référentiel vivant et agent-ready : continuellement rafraîchi, possédé et interrogeable — du contexte, pas de l'archéologie.

• L'EA modélise déjà capacités, applications, technologie et flux de données
• L'EA encode déjà les dépendances — le graphe que les agents doivent parcourir
• Ce qui manque, c'est la fraîcheur et la gouvernance, pas un nouveau modèle de données
• Un modèle EA vivant est un système de contexte ; un modèle périmé est un musée

Pour la finance régulée, la couche de contexte doit être souveraine

Consolider le contexte est puissant, et c'est exactement pour cela que cela élève les enjeux. Un système de contexte complet est un plan quasi complet de l'organisation : son inventaire intégral de systèmes, ses dépendances critiques, ses composants obsolètes, ses flux de données sensibles. Le geste commode — brancher Claude, ChatGPT, Gemini ou Copilot directement dessus — suppose discrètement qu'envoyer ce plan à un LLM en cloud américain est acceptable. Pour une banque ou un assureur européen régulé, ce n'est souvent pas le cas. C'est une question DORA, CSSF, RGPD et EU AI Act, pas un interrupteur de fonctionnalité.

Le système de contexte défendable est donc gouverné : conscient des permissions sur qui peut l'interroger, et conscient de la résidence des données sur où vont ces données. L'enjeu n'est pas qui pose la question ; c'est de savoir si la réponse peut être produite sans que le contexte quitte votre contrôle. C'est la conviction vers laquelle construit ArchiLU — une couche de contexte souveraine, hébergée en UE ou on-premise, à laquelle les agents d'une institution peuvent se fier et qu'un auditeur acceptera. Soyons clairs : le modèle EA connecté existe aujourd'hui ; la couche souveraine pleinement interrogeable par des agents relève de la feuille de route, et nous ne prétendrons jamais le contraire.

Partez de votre contexte, pas du battage

La catégorie se nomme alors qu'elle est encore à prendre. Les systèmes d'enregistrement ne disparaîtront pas — ils restent la source faisant autorité sur leurs domaines. Mais la question stratégique de la décennie à venir est de savoir qui possède le système de contexte, et pour les institutions régulées, la réponse doit être souveraine par construction.

Le premier pas concret est peu glamour : découvrir à quel point votre contexte est réellement vivant. Si votre architecture est un instantané, aucun agent ni aucune stratégie de consolidation ne la sauvera. L'évaluation gratuite de maturité EA d'ArchiLU note dix dimensions et renvoie un plan d'action priorisé en environ dix minutes — un moyen rapide de voir si votre organisation possède un système de contexte digne d'être gouverné, ou une archive à rafraîchir d'abord.

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