DORA et la traçabilité d'architecture à l'ère des 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

DORA vous demandait déjà de rendre l'architecture traçable

Bien avant l'arrivée des agents IA, DORA a posé une attente claire pour la finance régulée : connaître vos dépendances IT, identifier celles qui soutiennent des fonctions critiques ou importantes, documenter vos relations avec les tiers, et savoir expliquer — preuves à l'appui — comment votre résilience opérationnelle tient. C'est, au fond, une exigence de traçabilité appliquée à votre architecture.

Notre pilier complémentaire sur la gouvernance d'architecture pour DORA et NIS2 décrit la mécanique qui produit cela : le comité de revue, les décisions consignées, le registre des applications et la cartographie des dépendances IT. Cet article ne le répète pas. Il regarde ce qui change quand des agents IA se mettent à raisonner sur ces mêmes données d'architecture — car le niveau de traçabilité ne baisse pas quand un modèle rejoint le workflow ; il monte.

Une mise en garde d'emblée, et nous resterons honnêtes tout du long : rien ici ne vous rend légalement conforme. La conformité DORA est appréciée par les régulateurs et les auditeurs au regard de vos mesures organisationnelles, contractuelles et de sécurité. Un modèle d'architecture gouverné — avec ou sans IA — aide à documenter et à prouver ce que vous faites. Il ne remplace pas le travail juridique, de risque et de sécurité.

Ce qu'un agent IA change à votre chaîne IT

Un agent IA qui répond à des questions sur votre architecture, ou propose une remédiation, n'est pas une fonctionnalité neutre. Il dépend généralement d'un grand modèle de langage externe. Dès que ce modèle influence une décision opérationnelle ou de résilience, le fournisseur derrière lui peut prétendre faire partie de votre chaîne d'approvisionnement IT — exactement le type de relation que DORA attend de vous d'identifier, documenter et évaluer.

Traité honnêtement, cela soulève des questions tierces familières dans un nouvel endroit. Qui est le fournisseur, et sous quel contrat ? Où vont les données ? Et — celle qu'on oublie — si trois ou quatre workflows critiques dépendent en silence du même modèle, vous avez un risque de concentration que vous n'avez jamais consigné. La discipline consiste à traiter tout modèle externe comme une dépendance à documenter, pas comme un service invisible mobilisé par défaut.

• Un fournisseur de modèle externe derrière un agent est un tiers IT candidat
• Plusieurs workflows critiques sur un même modèle : un risque de concentration à consigner
• Contrat, localisation des données et stratégie de sortie : les questions tierces classiques, appliquées à l'IA
• Le réflexe honnête : documenter la dépendance au modèle, ne pas la masquer

Prompts et réponses sont un flux de données à décrire

Quand un agent envoie du contexte d'architecture à un modèle, demandez-vous ce qu'est réellement ce contexte. Il peut inclure l'inventaire des systèmes, les niveaux de criticité, les cartes de dépendances, les détails d'hébergement — agrégés, un plan quasi complet de l'organisation. Le prompt est un flux sortant ; la réponse qui façonne une décision est un flux entrant. Une gouvernance pensée pour DORA attend que vous sachiez quelles données vont où, et l'IA n'a pas de dérogation.

C'est là que la source du contexte compte énormément. Si l'agent puise dans des exports éparpillés et des copies improvisées, vous ne pouvez pas décrire le flux avec assurance — et encore moins le prouver plus tard. Si le contexte provient d'un seul modèle gouverné que vous pouvez désigner, le flux devient descriptible : cette part définie de l'architecture, avec ces attributs de résidence, a constitué l'entrée. Plus la source est propre, plus la preuve l'est.

Un modèle vivant et gouverné est l'ancre de traçabilité

L'actif qui rend tout cela défendable est un modèle d'architecture à jour et gouverné — pas un instantané vieux de dix-huit mois. Un registre des applications vivant, des dépendances IT cartographiées et des décisions consignées sont déjà ce qu'attend une revue de résilience. Ce sont aussi les données sur lesquelles un agent IA devrait raisonner, car ancrer un agent dans des données périmées ou superficielles produit des réponses assurées qu'aucun auditeur n'accepterait.

Concrètement, c'est la même colonne vertébrale que celle décrite par le pilier de gouvernance, utilisée pour un nouvel usage. Le registre vous dit quelles applications soutiennent une fonction critique. La carte des dépendances vous dit ce dont ces applications dépendent. Quand la recommandation d'un agent est ancrée dans ce modèle, elle hérite de la traçabilité du modèle au lieu de flotter librement dans une fenêtre de chat.

• Un registre des applications avec propriétaires, criticité et hébergement
• Des dépendances IT cartographiées, des fonctions critiques jusqu'aux fournisseurs
• Des décisions consignées qui captent le choix humain et sa justification
• Tenu à jour en continu, pour que l'agent raisonne sur la réalité actuelle

Garder les décisions influencées par l'IA dans le cadre

Le risque avec les agents n'est pas qu'ils donnent de mauvaises réponses ; c'est qu'une réponse présentable arrive sans provenance. Une décision de résilience traçable seulement vers une conversation opaque est précisément ce qu'une revue de supervision ne veut pas. Le remède est d'ancrer la décision : l'entrée de l'agent était cette part versionnée du modèle, le choix humain a été consigné comme une décision liée aux applications concernées, et la trace court de la fonction critique à la dépendance puis au fournisseur sans rupture.

C'est la discipline pratique. Servez-vous de l'agent pour accélérer l'analyse, puis consignez le résultat comme une décision de premier ordre dans le même modèle gouverné — contexte, options, décision, justification — exactement comme pour tout changement d'architecture significatif. L'IA accélère la réflexion ; le registre gouverné la garde traçable. L'un sans l'autre est soit lent, soit indéfendable.

Vers une couche de contexte souveraine pour l'IA régulée

Il existe une version prospective de tout cela dont nous sommes convaincus qu'elle est la bonne direction, et nous serons clairs : c'est une conviction et une feuille de route, pas une fonctionnalité livrée. Nous pensons que les organisations régulées devraient pouvoir donner à leurs agents IA une couche de contexte souveraine : un système de contexte gouverné, conservé dans une région que vous contrôlez, qu'un agent peut interroger sans que la cartographie sensible quitte votre périmètre. L'objectif est de répondre aux questions de DORA — qui dépend de quoi, où vont les données — par conception plutôt qu'après coup.

C'est la direction d'ArchiLU : le contexte d'abord, le raisonnement réglementaire ensuite, et tout accès conscient de la résidence des données pour les agents construit par-dessus un modèle déjà gouverné, à jour et vôtre. Pour aujourd'hui, le geste défendable est modeste et réel — tenir un modèle d'architecture vivant, traiter tout modèle externe comme une dépendance documentée, et ancrer chaque décision influencée par l'IA à une source gouvernée. Pour situer rapidement votre pratique, l'évaluation gratuite de maturité EA note dix dimensions et renvoie un plan priorisé en une dizaine de minutes.

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