La loi européenne sur l'IA accorde deux ans aux banques pour consolider les fondations des systèmes agentiques

Deux ans après l'entrée en vigueur du règlement européen sur l'IA, la conversation au sein du secteur bancaire européen a changé. La réglementation n'est plus un horizon lointain ; c'est un calendrier figé. Les systèmes d'IA à haut risque utilisés pour le scoring de crédit, l'évaluation des risques et la détection de fraude doivent être conformes d'ici août 2027. Pourtant, les établissements les plus avancés dans leurs préparatifs ne célèbrent pas leur conformité réglementaire. Ils s'inquiètent de savoir si la technologie sous-jacente à leurs programmes de conformité peut réellement délivrer ce que la loi exige : explicabilité, responsabilité et surveillance humaine sur des systèmes qui agissent de manière autonome.

Le calendrier de conformité n'est pas la contrainte

La mise en œuvre échelonnée de la loi accorde aux banques une fenêtre de préparation qui court jusqu'à mi-2027 pour la plupart des cas d'usage à haut risque dans les services financiers. Cela semble ample. En pratique, l'échéance qui compte n'est pas celle imprimée au Journal officiel. C'est le moment où l'infrastructure centrale d'une banque peut prendre en charge les pistes d'audit, l'accès aux données en temps réel et les couches d'orchestration que requiert une IA digne de confiance. Si ce moment survient après l'échéance réglementaire, l'établissement fait face à un choix entre non-conformité et arrêt de capacités qu'il a déjà vendues à ses clients et à ses superviseurs.

L'Autorité bancaire européenne (ABE) a signalé que les attentes de supervision évolueraient avec la technologie. Dans son rapport 2024 sur l'IA dans les services financiers, l'ABE a noté que les cadres de gouvernance doivent couvrir l'ensemble du cycle de vie des modèles d'IA, du développement au déploiement jusqu'au déclassement. La Banque centrale européenne (BCE), qui supervise directement les plus grandes banques de la zone euro, a intégré le risque d'IA dans ses revues thématiques. Aucun des deux superviseurs n'a publié de liste de contrôle finale. Tous deux ont clarifié que cette liste, lorsqu'elle arrivera, ne sera pas statique.

La gouvernance est un problème d'architecture, pas un exercice de paperasse

Traiter la gouvernance de l'IA comme un exercice de documentation est tentant. Cela permet aux équipes conformité de produire des fiches modèles, des évaluations de risque et des comités de surveillance sans toucher aux systèmes qui font réellement circuler l'argent. Mais les exigences de la loi en matière de traçabilité et de surveillance humaine deviennent exponentiellement plus difficiles lorsque l'IA passe de la génération d'insights à l'exécution d'actions. Un agent qui enquête sur une transaction suspecte, interroge le fichier client maître, vérifie les listes de sanctions et initie un blocage le fait à travers plusieurs systèmes en quelques secondes. Un journal de surface qui enregistre la décision et la version du modèle ne satisfera pas un superviseur demandant quel enregistrement de données a été accédé à quelle milliseconde, par quel composant, sous l'autorité de qui.

C'est là que l'architecture de la plupart des banques européennes se brise. Les plateformes bancaires centrales construites dans les années 1990 et 2000 étaient conçues pour le traitement par lots, les réconciliations nocturnes et les transactions initiées par des humains. Elles exposent les données via des interfaces fragiles, si tant est qu'elles le fassent. Elles ne conservent pas de pistes d'audit immuables au niveau des lectures de champs individuels. Elles ne peuvent pas appliquer des contrôles d'accès à grain fin sur une base par agent. Lorsqu'un agent d'IA doit orchestrer un flux de travail à travers le cœur de système, le moteur de paiement, le CRM et le système de gestion documentaire, la couche d'intégration devient le goulot d'étranglement et l'angle mort.

Des résumés génératifs à l'exécution agentique

La plupart des pilotes d'IA bancaires actuels relèvent du génératif : résumé de dépôts réglementaires, rédaction de réponses clients, assistance au code. Ce sont des cas précieux mais aussi sûrs. Le modèle produit du texte ; un humain le relit ; le risque est contenu. La vague suivante est agentique. Des systèmes qui planifient des tâches multi-étapes, appellent des API, écrivent dans des bases de données et déclenchent des processus en aval. La Revue de la stabilité financière de la BCE a déjà signalé le potentiel des agents autonomes à amplifier le risque opérationnel si les garde-fous faillent. Pour que cette transition se fasse en sécurité, les banques ont besoin de quatre fondations que la plupart ne possèdent pas encore : accès en temps réel à des données structurées, connectivité « API-first » entre systèmes, couches d'orchestration qui appliquent la politique à l'exécution, et pistes d'audit suffisamment granulaires pour reconstruire toute décision d'agent a posteriori.

La surveillance humaine doit être conçue dans le flux de travail, pas rajoutée comme une file d'attente d'approbation. La loi exige que les systèmes à haut risque permettent une intervention humaine. Dans un contexte agentique, cela signifie que l'architecture doit prendre en charge des points de contrôle où une personne peut inspecter le raisonnement de l'agent, les données sur lesquelles il s'est appuyé, et l'action qu'il propose avant exécution. Les cœurs de système hérités avec leurs interfaces synchrones, souvent en mode écran gratté, ne peuvent pas fournir ce budget de latence. La surveillance devient alors soit un cachet de caoutchouc, soit un goulot d'étranglement qui défait l'objectif de l'automatisation.

Modernisation de l'existant sans « big bang »

L'instinct face à ce fossé est de lancer un programme de remplacement du cœur de système. L'histoire bancaire européenne est jonchée de transformations pluriannuelles, à plusieurs milliards d'euros, qui ont livré en retard, au-delà du budget et avec des fonctionnalités réduites. L'alternative est la modernisation progressive : envelopper le cœur existant d'une couche API, construire un tissu de données qui expose des jeux de données propres et versionnés, et déployer des outils d'orchestration et de gouvernance cloud-natifs aux côtés du mainframe. Cela permet aux banques de migrer les cas d'usage vers la nouvelle couche un par un, prouvant la valeur et dérisquant la migration.

Les banques nativement numériques comme N26, Bunq et Revolut ont bâti leurs stacks ainsi dès le premier jour. Les établissements traditionnels ne peuvent pas reproduire cet historique, mais ils peuvent adopter le même schéma. Des partenaires technologiques spécialisés fournissent désormais les composants composables, identité, registre, conformité, orchestration, qui auraient sinon nécessité des équipes d'ingénierie internes d'une taille que peu de banques européennes peuvent se permettre ou retenir. La voie pragmatique est d'acheter la plomberie et de construire la différenciation.

La fenêtre de préparation comme atout stratégique

La réglementation est habituellement présentée comme un frein à l'innovation. En l'occurrence, le délai de mise en œuvre de deux ans crée un alignement rare. Le travail requis pour satisfaire la loi, données propres, services composables, connectivité temps réel, explicabilité, auditabilité, est exactement le travail requis pour adopter quelle que soit la capacité d'IA qui s'avérera utile l'an prochain ou l'année d'après. Les banques qui traitent l'échéance comme une ligne d'arrivée construiront la couche de conformité minimale viable et se retrouveront à reconstruire quand le premier cas d'usage agentique atterrira. Celles qui la traitent comme une fondation seront celles capables de dire oui à la capacité suivante sans un projet d'intégration de deux ans.