La phase d'exécution de DORA veut des preuves, pas des PDF de politique.
Pendant l'essentiel de sa jeunesse, la conformité du secteur financier récompensait la bonne documentation. Vous écriviez la politique, vous cartographiez les contrôles, vous teniez le classeur à jour, et quand le superviseur venait vous lui remettiez un jeu de PDF bien organisé. Le document était le livrable. Une organisation capable de décrire sa résilience de façon convaincante était, aux fins réglementaires, résiliente.
Sauf que cette ère se referme. DORA, le règlement européen sur la résilience opérationnelle numérique, est en vigueur depuis le 17 janvier 2025, et en 2026 il est entré en phase d'exécution. Comme le rapporte l'analyse de Dawiso sur les agents IA dans la banque sous DORA, et comme le relaient les couvertures d'Auriga et d'ATM Marketplace sur la gouvernance de l'IA pour les institutions financières, les superviseurs ont changé ce qu'ils acceptent. Ils sont passés de la prise au mot des documents de politique à l'exigence de preuves de résilience fondées sur les données. Le classeur n'est plus le livrable. La preuve l'est.
Ce basculement frappe le plus durement exactement les systèmes que les banques se précipitent aujourd'hui à déployer. Parce qu'un PDF de politique décrivant comment vos agents se comportent et une piste de preuves démontrant comment ils se sont comportés sont deux artefacts entièrement différents, et le second est le seul qui survive à une revue en phase d'exécution.
L'écart que la phase d'exécution révèle
Une politique est une description d'un comportement voulu. Une preuve est un enregistrement d'un comportement réel. Dans le monde d'avant l'exécution, l'un pouvait tenir lieu de l'autre, parce que personne ne vérifiait le second contre le premier. La phase d'exécution ferme cette substitution.
Ce qui rend cela important maintenant, et pas il y a cinq ans, c'est ce que les banques déploient. Le reportage de Dawiso projette qu'environ 44 % des équipes financières utiliseront de l'IA agentique en 2026, un bond important. C'est la collision au centre de cette histoire. Un régime de supervision qui vient de commencer à exiger des preuves de comportement réel rencontre une vague de systèmes dont le comportement réel est probabiliste, change à chaque mise à jour de modèle et, dans la plupart des déploiements, est à peine enregistré.
Les risques nommés dans cette couverture sont précis, et ils ne sont pas abstraits. Un accès non contrôlé des agents aux systèmes internes. Une journalisation insuffisante qui rend la reconstitution d'incident impossible. Lisez ces deux-là ensemble et vous avez le mode d'échec exact que la phase d'exécution de DORA est faite pour attraper : un système qui peut agir sur vos plateformes centrales et qui ne peut pas ensuite vous dire ce qu'il a fait ni pourquoi. Le PDF de politique disait qu'il était gouverné. La revue vous demande de le prouver, et il n'y a rien à montrer.
Un agent qui ne peut pas reconstituer ce qu'il a fait ne peut pas passer une revue DORA
C'est la phrase à intérioriser, parce qu'elle convertit une angoisse vague de conformité en une exigence architecturale concrète.
Les attentes de résilience de DORA supposent que lorsque quelque chose tourne mal, vous pouvez le reconstituer. La déclaration d'incident, l'analyse des causes racines et toute la posture de résilience opérationnelle reposent sur la capacité à répondre, après coup, à ce qui s'est passé, dans quel ordre et sur quelle base. Pour du logiciel déterministe, c'est un problème résolu : les journaux sont l'histoire, et le code qui les a produits ne change pas entre l'incident et l'enquête.
Un agent brise cette hypothèse de deux façons. D'abord, il agit sur du contexte vivant et raisonne de façon probabiliste, donc « ce qu'il aurait fait » n'est pas récupérable en rejouant le code. Ensuite, si la journalisation est insuffisante, comme la couverture le nomme explicitement, alors même « ce qu'il a réellement fait » est irrécupérable. Un agent qui a lu un dossier, raisonné dessus et posté une décision, mais n'a laissé aucun enregistrement inspectable des entrées qu'il a vues, de la politique qu'il a appliquée et du verdict qu'il a rendu, a produit un résultat que personne ne peut reconstituer.
Sous l'ancien régime, c'était survivable, parce que vous pouviez pointer la politique. Sous l'exécution, c'est disqualifiant. Un agent dont les décisions ne peuvent pas être reconstituées ne peut pas être montré comme résilient, et un système qui ne peut pas être montré comme résilient ne passe pas. L'absence de preuve n'est pas une lacune documentaire que l'on corrige plus tard. C'est un trou permanent, parce que vous ne pouvez pas enregistrer rétroactivement des décisions que le système a déjà prises sans les capter.
La conformité comme politique exécutable, la preuve comme sous-produit
La sortie n'est pas d'écrire un meilleur PDF de politique. C'est de construire une architecture où la politique est exécutable et où la preuve est produite automatiquement, comme condition même du fonctionnement du système.
Deux propriétés font le travail, et elles correspondent directement à ce qu'exige « des preuves, pas des politiques ».
La conformité comme politique exécutable. Au lieu d'un document qui décrit les règles, les règles sont du code que votre équipe conformité possède, versionne et signe, évalué au moment de chaque décision. Chaque action à conséquence passe par un point de décision de politique qui renvoie un verdict lisible par la machine : autoriser, autoriser sous conditions documentées, refuser, ou exiger une personne. Le poids réglementaire non délégable se résout vers une personne par politique ; l'agent se contente d'analyser. La politique n'est plus une affirmation sur le comportement. C'est le mécanisme qui produit le comportement, et il peut être testé, réapprouvé et prouvé.
Une piste de preuves append-only, chaînée par hachage. Chaque décision écrit un enregistrement immuable, avant que la décision ne s'engage, des entrées vues par l'agent, de la version de politique appliquée et du verdict rendu. Le chaînage par hachage rend la trace inviolable : vous pouvez prouver non seulement ce qui s'est passé, mais que l'enregistrement n'a pas été modifié après coup. Et elle échoue en fermé. Pas de stockage de preuves, pas de décision. Le système ne peut physiquement pas agir sans laisser l'enregistrement qu'un superviseur demandera.
Mettez cela ensemble et la reconstitution cesse d'être un espoir pour devenir une requête. Quand arrive la question de la phase d'exécution, qu'a fait cet agent, sur quelle base, et pouvez-vous prouver que l'enregistrement est intact, la réponse est un rapport que vous exécutez, pas une enquête que vous lancez. La preuve existe parce que l'architecture n'aurait pas pu produire la décision sans la créer.
C'est la différence entre décrire la résilience et la démontrer, et c'est exactement la différence que la phase d'exécution de DORA a été faite pour tester.
Le recadrage
La question que les banques posent encore, celle qui produit un classeur de plus, est « avons-nous une politique qui couvre nos agents IA ? ». En phase d'exécution, cette question répond à un examen que plus personne ne fait passer. Avoir la politique est le ticket d'entrée. Prouver le comportement est l'examen.
La meilleure question est celle-ci. Quand un superviseur nous demande de reconstituer exactement ce qu'un de nos agents a fait, sur quelles données, sous quelle règle, et de prouver que l'enregistrement n'a pas été touché, pouvons-nous exécuter cela comme un rapport, ou devons-nous admettre que nous ne l'avons pas capté ? Si la réponse honnête est la seconde, aucun PDF de politique ne comble l'écart, parce que l'écart n'est pas dans votre documentation. Il est dans votre architecture, et la phase d'exécution lit l'architecture, pas les intentions.
Les superviseurs ont changé ce qu'ils acceptent. Les systèmes déployés ont rendu le changement urgent. Et les organisations qui construisent la piste de preuves dans l'agent, plutôt que d'écrire une politique à son sujet, sont les seules qui passeront la revue qu'elles sont désormais certaines d'affronter.
Si vous voulez tester si vos processus agentiques pourraient produire une reconstitution qu'un superviseur DORA accepterait, prenez rendez-vous et apportez-nous celui qui touche le plus de systèmes internes.