Sebastien Rousseau
Me contacter ›

Ingénierie agentique pour les banques : un blueprint 2026 pour le COMEX et les ingénieurs qui le bâtiront

L'IA agentique est passée du pilote à la production. 70 % des banques l'utilisent déjà ; seule une sur cinq dispose d'un modèle de gouvernance mature. Les adversaires opèrent à vitesse machine, l'estate hérité a été écrit pour les hypothèses batch des années 1960, et l'échéance « haut risque » du Règlement européen sur l'IA arrive dans douze semaines.

37 min de lecture

Diagramme d'architecture pour l'ingénierie agentique dans la banque.class="img-fluid clearfix"

L'IA agentique est passée du pilote à la production dans la banque mondiale. Soixante-dix pour cent des institutions l'utilisent à un degré ou un autre ; seule une sur cinq dispose d'un modèle de gouvernance mature. En parallèle, des adversaires autonomes opèrent à vitesse machine, l'estate hérité COBOL avec lequel les nouveaux systèmes doivent interopérer a été écrit pour les hypothèses batch des années 1960, et l'échéance « haut risque » du Règlement européen sur l'IA est à douze semaines. Voici la position d'ingénierie et de gouvernance qu'une banque doit tenir.

L'année où l'ingénierie agentique est devenue inévitable #

La conversation sur l'IA dans les services financiers a été, jusqu'à très récemment, dominée par deux choses adjacentes mais distinctes : les interfaces conversationnelles génératives (utiles mais bornées) et les patterns de Retrieval-Augmented Generation appliqués aux données d'entreprise (utiles également, mais bornés). Ce qui a changé entre fin 2025 et début 2026 : la troisième catégorie — des agents autonomes qui planifient, exécutent et complètent des workflows multi-étapes avec une supervision humaine limitée — est passée de la démonstration technique à la réalité opérationnelle, et a franchi simultanément les frontières de l'entreprise et de la menace.

Andrej Karpathy, qui a forgé le terme « vibe coding » en février 2025 ⧉, a passé l'année qui suit à observer les ingénieurs professionnels le dépasser. Sa révision — « ingénierie agentique » — est désormais le terme de travail dans toute l'industrie. La substance du changement est simple : dans le travail logiciel sérieux en 2026, les ingénieurs n'écrivent pas le code directement 99 % du temps. Ils orchestrent des agents qui le font, tout en exerçant une supervision. Le travail ne consiste plus à taper des caractères dans un éditeur ; il consiste à produire des spécifications qui contraignent ce que les agents peuvent générer, à concevoir les portes de vérification que la sortie doit franchir et à organiser les décisions architecturales que les agents implémentent.

Ce changement ressemble à une conversation d'équipe d'ingénierie. Dans la banque, ce n'en est pas une. C'est une conversation de conseil d'administration, parce que la même capacité agentique qui réécrit la façon dont le code interne est produit réécrit aussi la façon dont les adversaires externes opèrent, la façon dont les régulateurs attendent que la supervision soit exercée et la façon dont le périmètre institutionnel est défini. Une banque qui ne prend pas position sur l'ingénierie agentique avant la fin 2026 n'est pas une banque qui a évité la question. C'est une banque dont les fournisseurs, les adversaires et les régulateurs y ont répondu à sa place.

L'état de l'adoption dans la banque #

Le tableau agrégé est sans ambiguïté. Selon les recherches compilées sur plusieurs enquêtes 2026, 70 % des dirigeants bancaires ⧉ déclarent que leurs établissements utilisent déjà l'IA agentique à un degré ou un autre. Gartner projette ⧉ qu'à la fin 2026 environ 40 % de toutes les sociétés de services financiers feront tourner des agents IA sous une forme ou une autre. Les dépenses IA des services financiers sont sur la trajectoire des 67 milliards de dollars en 2028 (IDC). McKinsey estime que l'IA agentique peut redonner 10 à 12 heures par semaine aux relationship managers dans la banque.

Le tableau de l'exécution est moins encourageant. KPMG indique ⧉ que 99 % des entreprises prévoient de mettre des agents autonomes en production, mais que seulement 11 % l'ont fait. EY constate que 34 % des dirigeants ont commencé à utiliser des agents IA et que seuls 14 % les ont pleinement implémentés. Forrester observe que 57 % des organisations estiment manquer des capacités internes pour tirer parti de l'IA agentique. L'écart entre l'intention et l'exécution n'est pas un artefact marketing. Il reflète le travail d'ingénierie, de gouvernance et de culture qui n'a pas encore été fait.

La Financial Conduct Authority britannique a publiquement exprimé ses inquiétudes ⧉ sur la vitesse de déploiement qui dépasse la maturité de la gouvernance — une tension que la Chief Data Officer Jessica Rasu a cadrée comme un risque consommateur retail à court terme. McKinsey a séparément averti que les banques qui n'adapteront pas leur modèle d'affaires ⧉ risquent d'éroder jusqu'à 170 milliards de dollars de profits mondiaux d'ici 2030. Les deux observations sont simultanément correctes. La question n'est pas s'il faut bouger ; c'est comment bouger avec l'intégrité opérationnelle et de gouvernance que la régulation financière a toujours exigée, et que les systèmes agentiques rendent plus tranchante.

Trois vecteurs de risque que les banques doivent intérioriser #

Avant toute conversation architecturale, l'attention du conseil doit se porter sur trois risques propres aux systèmes agentiques et qui arrivent plus tôt que la plupart des banques ne l'ont prévu.

1. L'adversaire autonome #

Le développement le plus déstabilisant de 2026 est l'opérationnalisation de l'IA agentique côté attaquant. En août 2025, Anthropic a divulgué une catégorie d'activité qu'il a appelée vibe hacking ⧉ : des cybercriminels utilisant l'IA agentique pour mener des attaques sophistiquées à grande échelle, l'IA étant intégrée à la reconnaissance, la collecte d'identifiants, la pénétration réseau et l'analyse des données dérobées. En novembre 2025 ⧉, Anthropic a divulgué la disruption d'une campagne menée par un groupe parrainé par l'État chinois (désigné GTG-1002) qui avait détourné des instances Claude Code pour mener un espionnage autonome contre environ trente cibles dans la défense, l'énergie et la technologie, l'IA gérant 80 à 90 % des opérations tactiques et opérant à plusieurs milliers de requêtes par seconde — des vitesses impossibles pour des opérateurs humains.

En janvier 2026, Step Finance — un gestionnaire de portefeuille DeFi sur Solana — a été compromis d'une manière qui a transformé une intrusion sur appareil en une perte de 27 à 30 millions de dollars, parce que les agents IA de trading du cabinet avaient les permissions d'exécuter de gros transferts sans approbation humaine. L'attaquant a piégé l'IA elle-même par ingénierie sociale, prétendant exécuter un programme de bug bounty autorisé. La leçon ⧉ n'était pas que l'IA est intrinsèquement dangereuse ; c'était qu'un agent IA qui accepte une autorisation revendiquée sans vérification est une faiblesse de périmètre.

La tendance agrégée est ce que les banques doivent intérioriser. Le rapport Flashpoint 2026 Global Threat Intelligence Report a identifié une hausse de 1 500 % des discussions illicites liées à l'IA ⧉ entre novembre et décembre 2025, avec des attaquants développant activement des systèmes autonomes qui scrapent des données, font tourner l'infrastructure, ajustent les messages et apprennent des tentatives ratées sans supervision humaine continue. Jamie Dimon (JPMorgan) a été publiquement explicite ⧉ : l'avantage initial de cette technologie va à l'offensive, pas à la défense. L'implication est inconfortable : une banque qui fait tourner des opérations de sécurité classiques contre des adversaires agentiques est, structurellement, dans la position d'un joueur d'échecs dont l'adversaire dispose d'un ordinateur.

2. La régression de qualité du code #

Le deuxième vecteur est interne et plus discret. Le code généré par LLM, en l'absence de discipline de spécification et de vérification rigoureuse, est livré avec des défauts à un taux nettement supérieur au code écrit par des humains. Une analyse SonarQube de cinq LLM frontières ⧉ générant du code Java a trouvé que plus de 70 % des vulnérabilités détectées dans la sortie de Llama 3.2 90B étaient classées BLOCKER, et qu'environ deux tiers des vulnérabilités de GPT-4o et OpenCoder-8B étaient classées BLOCKER ou CRITICAL. Pearce et al. (IEEE S&P) ont trouvé qu'environ 40 % des programmes générés par LLM dans des contextes sensibles à la sécurité contenaient des vulnérabilités. Yan et al. (2025) placent la fourchette à 9,8 à 42,1 % selon leurs benchmarks. Un catalogue séparé de Fu et al. identifie 43 CWE sur trois outils de génération de code IA.

Pour une industrie non régulée, c'est une taxe à la productivité. Pour une banque, c'est un risque réglementaire et opérationnel qui se compose. Du code livré avec un taux élevé de vulnérabilités dans un système qui gère paiements, règlement ou données clients n'est pas une question de qualité de code au sens abstrait ; c'est la surface que les adversaires de classe GTG-1002 sonderont en 2027 avec les mêmes outils agentiques qui l'ont produit. La défense n'est pas d'interdire le code généré par LLM (commercialement impossible), mais de l'entourer de l'infrastructure de vérification et de spécification qui garantit que les défauts apparaissent avant le déploiement. C'est la raison pratique pour laquelle le développement piloté par spécification est adopté à toute vitesse par les organisations d'ingénierie d'entreprise qui ne sont pas nativement des sociétés de technologie.

3. L'ancre du legacy #

Le troisième vecteur est celui que les banques comprennent déjà le mieux, et que la transition agentique a rendu simultanément plus urgent et plus tractable. Plus de 70 % des entreprises du Fortune 500 reposent encore sur des mainframes, note l'analyse de Computer Weekly ⧉, souvent bâtis sur des décennies de COBOL et RPG entrelacés avec de la logique métier sur mesure. Dans les services financiers spécifiquement, les technologies héritées consomment 70 à 75 % des dépenses IT annuelles ⧉. Une étude CIO citée dans l'analyse industrielle 2026 a trouvé que 63 % des banques s'appuient encore sur du code écrit avant 2000, et que plus de 75 % rapportent n'avoir qu'une ou deux personnes en interne avec les compétences pour le maintenir.

Ce qui a changé en février 2026, c'est l'arrivée d'un outillage agentique crédible pour la modernisation du legacy. L'annonce d'Anthropic que Claude Code pouvait cartographier les dépendances COBOL, documenter les workflows et identifier les risques ⧉ qu'il faudrait des mois à des analystes humains pour faire émerger — couplée à des capacités similaires de Microsoft (GitHub Copilot pour COBOL, Watsonx Code Assistant) et d'AWS (Mainframe Modernization avec IA agentique) — a comprimé matériellement la courbe de coût de la modernisation. La réaction du cours d'IBM (baisse de 13 % le jour de l'annonce) était un signal de marché inélégant mais précis. L'IA représente désormais environ un tiers de l'investissement de modernisation d'entreprise, et plus de 75 % des entreprises utilisent l'IA dans leur stratégie de modernisation. L'ancre du legacy est, pour la première fois, un problème d'ingénierie tractable plutôt que générationnel.

Pourquoi le vibe coding ne peut pas être le défaut dans la banque #

Il vaut la peine d'être précis sur pourquoi le vibe coding — prompt court, observer la sortie, itérer — échoue comme workflow par défaut dans un estate régulé. Le mode d'échec n'est pas le plus évident (le LLM hallucine de temps en temps). Le mode d'échec est structurel et apparaît simultanément à quatre endroits.

Le premier est l'absence de conventions partagées. Plusieurs ingénieurs travaillant par prompts produiront cinq manières différentes de faire la même chose dans la même base de code en un seul trimestre. Dans un contexte non régulé, c'est de la dette technique. Dans un contexte régulé, c'est la surface qui casse à l'examen.

Le deuxième est la décroissance du contexte. Les agents IA sont sans état. Sur un grand projet, les conversations dépassent les fenêtres de contexte, et le raisonnement derrière les décisions architecturales antérieures s'évapore. Le même agent, deux semaines plus tard, prendra la décision inverse dans une nouvelle conversation parce que rien ne persiste la justification de la première. Pour des systèmes qui exigent une piste d'audit pour les régulateurs, c'est structurellement incompatible.

Le troisième est l'accumulation invisible de défauts. Les résultats de Pearce, Yan et SonarQube cités plus haut ne sont pas des cas marginaux. C'est le taux de base auquel les LLM génèrent du code vulnérable en l'absence de discipline de spécification et de tests rigoureux. Une banque qui fait tourner des workflows de vibe coding en production accumule ces défauts au même rythme, sans la visibilité de surface qui permettrait de savoir ce qui a été livré.

Le quatrième est le problème de traçabilité réglementaire. L'article 12 du Règlement européen sur l'IA exige la journalisation automatique des entrées et sorties pour les systèmes IA à haut risque. SR 11-7 exige des rôles documentés de propriétaire et de validateur de modèle, une gestion du changement pour les mises à jour de modèle et un reporting au conseil sur le risque modèle IA. DORA exige une gestion des risques ICT exhaustive avec des preuves documentées. Aucune de ces obligations ne peut être satisfaite par un workflow dont l'artefact principal est un historique de chat que personne ne persiste.

La conclusion n'est pas que les LLM sont impropres à la banque. La conclusion est que le workflow qui les entoure doit produire spécifications, pistes d'audit et portes de vérification comme livrables de première classe plutôt que comme arrière-pensée. C'est cela, opérationnellement, le développement piloté par spécification.

Développement piloté par spécification dans un estate régulé #

Le développement piloté par spécification (SDD) inverse l'ordre du travail. Au lieu de plonger dans l'implémentation et d'itérer avec un agent, l'équipe produit d'abord une spécification — décisions architecturales, exigences, contrats d'interface, critères de succès, contraintes de sécurité — et l'agent génère du code qui satisfait la spécification. La vérification est structurée : la spécification définit ce que la sortie doit faire, et un processus séparé (génération de tests, revue de code, vérification formelle quand applicable) vérifie que cela a été fait.

L'outillage pratique s'est consolidé fin 2025 et début 2026. Spec Kit de GitHub ⧉ (sorti fin 2025) formalise l'intention avant la génération de code. AWS embarque des workflows spec-first directement dans son IDE Kiro. JetBrains et Cursor ont introduit des modes de planification qui structurent l'interaction avec l'IA. Des frameworks comme BMAD (Breakthrough Method for Agile AI-Driven Development) vont plus loin avec des équipes d'agents IA spécialisés qui reflètent les rôles d'analyste, architecte, développeur et QA à travers le SDLC. Constitutional SDD, formalisé dans un article arXiv en février 2026, embarque des contraintes de sécurité explicites avec des cartographies de vulnérabilités CWE dans la spécification elle-même.

Pour une banque, la variante qui compte est ce que l'analyse d'Augment Code appelle le développement ancré sur la spécification — les spécifications viennent d'abord, l'IA génère du code contraint par elles, et des couches de gouvernance supplémentaires (contraintes constitutionnelles, points de supervision, portes d'approbation humaine) se placent entre la génération et le merge. C'est la seule variante qui produit la piste d'audit que l'article 12 du Règlement européen sur l'IA attend, le rôle documenté de validateur que SR 11-7 exige, et la discipline de gestion du changement que DORA demande.

L'investissement requis est réel, mais il est aussi tractable. Les institutions qui le font bien ont déplacé le quotidien des ingénieurs de taper des caractères à produire deux artefacts : une spécification que l'agent satisfera et un harnais de vérification que la sortie doit franchir. La demande cognitive sur l'ingénieur est plus élevée à certains égards (la clarté d'intention compte plus que jamais) et plus faible à d'autres (le travail mécanique d'écrire du boilerplate a disparu). Les institutions qui n'ont pas encore fait ce basculement opèrent encore dans un mode où le LLM est un dactylo plus rapide. Cette position n'est pas tenable dans un estate régulé au-delà des douze prochains mois.

La pile réglementaire qui s'applique désormais #

Le périmètre réglementaire 2026 autour de l'IA dans la banque n'est plus une checklist ; c'est une pile d'obligations qui se chevauchent et qui doivent être raisonnées ensemble. La date la plus conséquente est le 2 août 2026, quand les obligations « haut risque » du Règlement européen sur l'IA deviennent pleinement applicables ⧉. L'annexe III classe explicitement le scoring de crédit, l'évaluation de solvabilité, l'évaluation des risques en assurance vie et santé, ainsi que l'évaluation ou la classification de la situation financière des individus comme à haut risque. Les obligations qui découlent de cette classification incluent des évaluations de conformité, des systèmes de management de la qualité, des cadres de gestion du risque, une documentation technique, l'enregistrement dans la base de données européenne, une gouvernance des données robuste, la supervision humaine et des protections cybersécurité. Les pénalités pour manquement aux obligations à haut risque atteignent 35 millions d'euros ou 7 % du chiffre d'affaires mondial annuel, le plus élevé des deux.

À côté du Règlement européen sur l'IA :

Trois modes de développement assisté par IA comparés #

Dimension Vibe Coding Développement piloté par spécification Ingénierie agentique
Entrée principale Prompt court Spécification formelle Spécification + plan d'orchestration d'agents
Rôle de l'ingénieur Itérateur de prompts Auteur de spécification Orchestrateur et vérificateur
Discipline de sortie Génération directe de code Code contraint par la spec Workflows multi-agents produisant code, tests, docs
Piste d'audit Historique de chat (non persisté) Spec + code généré + tests Spec + traces d'agent + artefacts de vérification
Taux de défauts (LLM seul) 10 à 40 % de vulnérabilités (baseline littérature) Sensiblement réduit par les contraintes de spec Plus bas avec portes de vérification
Traçabilité réglementaire Insuffisante pour l'IA à haut risque Compatible avec l'article 12 du Règlement européen sur l'IA Conçu pour Article 12 + SR 11-7 + DORA
Adapté à la banque ? Non, pour la production Oui, avec gouvernance Oui, avec gouvernance mature
Plafond de capacité Borné par le prompting unique Borné par la qualité de la spec Borné par la qualité d'orchestration

Source : Synthèse des commentaires de Karpathy (2026), analyse SDD d'Augment Code ⧉, analyse CGI sur le développement piloté par spécification ⧉, et la littérature académique sur les taux de vulnérabilité de la génération de code par LLM (Pearce et al., Yan et al., Fu et al., 2023-2025).

Construire la banque agentique : une vue d'architecture #

La position stratégique derrière ces workflows est ce que le COMEX doit s'approprier explicitement. L'ingénierie agentique dans la banque n'est pas une initiative de productivité développeur. C'est une capacité institutionnelle qui touche les parcours client de bout en bout, l'ensemble du cycle de vie de la transaction, et le substrat cryptographique et d'audit qui sous-tend les deux. Quatre couches de cette capacité méritent l'attention exécutive directe, de haut en bas :

Couche 4 — Plan de contrôle des agents Gouvernance, audit, kill switches, détection d'anomalie comportementale, override humain. Configurations de supervision HITL et HOTL par classe d'agent.

Couche 3 — Workflows agentiques Parcours client, opérations internes, pipeline de développement. Pilotage par spécification par défaut pour les flux à haut risque.

Couche 2 — Données et modèles AIBOM (AI Bill of Materials), registre de modèles, substrat de retrieval, gestion de version des prompt templates, lignée des fine-tunes.

Couche 1 — Fondation résistante au quantique ML-KEM, ML-DSA, PKI hybride, crypto-agilité. Le substrat dont dépendent les revendications d'intégrité de toutes les couches supérieures.

Couche 1 — La fondation résistante au quantique. Chaque couche au-dessus suppose l'intégrité du substrat cryptographique. Avec la roadmap du G7, le plan NCSC en trois phases et BIS Project Leap publiquement documentés, ce n'est plus une préoccupation de niche. Les systèmes agentiques dont les pistes d'audit sont signées sous ECDSA classique, ou dont l'établissement de clés dépend de RSA ou ECDH, verront leurs revendications d'intégrité expirer avec la cryptographie. Les institutions qui s'y prennent bien remontent le travail post-quantique en amont et traitent ML-KEM, ML-DSA et la PKI hybride comme le substrat sur lequel reposent les garanties d'audit et d'intégrité de toutes les couches supérieures.

Couche 2 — La couche données et modèles. C'est là que vit l'AI Bill of Materials (AIBOM). Analogue au Cryptographic Bill of Materials utilisé dans la planification de migration post-quantique, l'AIBOM est l'inventaire de chaque modèle, jeu de données, prompt template, index de retrieval, fine-tune et dépendance IA tierce que l'institution opère. C'est l'artefact que l'article 49 du Règlement européen sur l'IA exige de fait, l'inventaire que les examens SR 11-7 réclament désormais, et la fondation de toute posture de gouvernance crédible. La plupart des institutions n'en ont pas. Il leur en faudra un d'ici août.

Couche 3 — Les workflows agentiques. C'est la couche que la plupart des institutions construisent actuellement, souvent sans attention suffisante aux couches 1, 2 et 4. Les workflows eux-mêmes vont de l'interne (génération de code, rédaction de documents réglementaires, triage de service client) au client (copilotes pour relationship managers, onboarding, orchestration KYC, surveillance des transactions, optimisation FX) jusqu'au pleinement autonome (opérations de trésorerie, certaines fonctions de trading et de gestion des risques quand la tolérance du régulateur le permet). La discipline stratégique à cette couche est de la traiter comme de l'ingénierie systèmes, pas du développement applicatif — patterns d'orchestration, règles d'escalade, portes human-in-the-loop et émission d'audit sont des préoccupations de design de première classe.

Couche 4 — Le plan de contrôle des agents. C'est ce que Deloitte a qualifié de « salle de contrôle des agents » ⧉ : l'audit en temps réel, le logging des actions, la détection d'anomalies comportementales, les kill switches et l'infrastructure d'override humain qui entourent chaque agent en production. La perte Step Finance n'était pas, techniquement, un échec d'IA. C'était un échec du plan de contrôle : les agents avaient des permissions qu'ils n'auraient pas dû avoir, et l'anomalie comportementale qui aurait dû déclencher un arrêt ne s'est pas déclenchée. Les institutions qui construisent le plan de contrôle d'abord — avant de mettre à l'échelle le déploiement d'agents — sont celles qui ne verront pas d'incidents de classe Step Finance en 2027.

La comparaison pertinente pour le COMEX n'est pas « faisons-nous plus d'IA que nos concurrents ? ». C'est de savoir si l'institution possède les quatre couches, ou si une ou plusieurs couches sont silencieusement déléguées à un fournisseur sans capacité contractuelle à satisfaire les exigences de documentation de l'article 13 du Règlement européen sur l'IA. Cette dernière est une position qui paraît correcte jusqu'à ce qu'un régulateur ouvre la question.

Supervision humaine en pratique : HITL vs HOTL #

La distinction unique au sein de la couche 4 sur laquelle les régulateurs concentrent le plus leur attention en 2026 est celle entre deux modèles de supervision. Tous deux sont des formes de supervision humaine ; ils diffèrent en latence, en échelle et dans l'hypothèse que le régulateur accepte sur le comportement de l'agent.

Human-in-the-Loop (HITL) est le modèle dans lequel un agent ne peut pas exécuter une action conséquente sans approbation humaine explicite. L'agent prépare la décision, la présente et attend. Un agent de remédiation KYC qui signale un compte pour clôture mais ne peut pas le clôturer sans la signature d'un compliance officer est HITL. Le trade-off est opérationnel : HITL est plus sûr et produit une piste d'audit non ambiguë pour l'article 14, mais il ne passe pas à l'échelle pour les workflows à fort volume et faible latence.

Human-on-the-Loop (HOTL) est le modèle dans lequel un agent s'exécute de manière autonome dans des paramètres bornés, avec des humains surveillant la télémétrie en temps réel et conservant l'autorité d'arrêter l'agent à tout moment. Un agent de filtrage de fraude en temps réel qui auto-bloque les transactions correspondant à certains schémas de risque, avec une équipe opérations humaine qui surveille le volume d'alertes et intervient sur les anomalies, est HOTL. Le trade-off est inverse : HOTL passe à l'échelle, mais il dépend de paramètres d'agent correctement réglés et d'une détection d'anomalies comportementales qui rattrape la dérive avant que les dommages ne s'accumulent.

L'article 14 du Règlement européen sur l'IA ne prescrit pas HITL ou HOTL ; il exige que la supervision humaine soit significative. L'implication pratique est que chaque agent à haut risque que la banque opère doit avoir une position explicite et documentée sur le modèle qui s'applique, pourquoi, et quel est le chemin d'escalade quand l'agent rencontre des situations hors de ses paramètres bornés. La plupart des banques qui faisaient tourner des pilotes en 2025 n'avaient pas cette documentation. La plupart des banques qui feront tourner des agents en production en août 2026 en auront besoin.

La règle de décision n'est pas complexe. Pour les actions conséquentes, à faible volume et irréversibles — refus de crédit à une personne physique, clôture de compte, autorisation de virement de gros montant, soumission de déclaration réglementaire — HITL est le défaut défendable. Pour les actions à fort volume, réversibles et à paramètres bornés — alertes de monitoring de transactions, classification de documents, triage routinier de service client — HOTL est approprié, à condition que la détection d'anomalies comportementales et l'infrastructure de kill switch soient matures. Les banques qui traitent chaque workflow comme HITL ne captureront pas le levier opérationnel des systèmes agentiques. Les banques qui traitent chaque workflow comme HOTL auront tôt ou tard leur moment Step Finance.

Acheter ou construire : le problème des agents tiers #

La réalité 2026 qui a rattrapé la plupart des banques est qu'elles ne construiront pas, principalement, la capacité agentique. Elles l'achèteront. Le paysage fournisseur — la plateforme banking agentique d'Oracle lancée en février 2026, Watsonx d'IBM, la suite Copilot de Microsoft, AWS Bedrock Agents, Salesforce Agentforce, NowAssist de ServiceNow, et la vague de fournisseurs d'agents spécialistes fintech — bouge plus vite que l'ingénierie interne des banques. La conséquence stratégique est que la majorité des agents qui opéreront dans une banque en 2027 auront été écrits par quelqu'un d'autre, et la question de gouvernance n'est plus « pouvons-nous faire confiance à nos agents ? » mais « pouvons-nous faire confiance aux agents que nous avons achetés, et pouvons-nous le prouver à un régulateur ? ».

C'est le défi le plus bruyant et le moins reconnu sous DORA. Les articles 28 à 30 du règlement font de la gestion du risque ICT tiers un champ supervisoire actif, avec des exigences explicites couvrant les clauses contractuelles, le suivi continu, l'évaluation du risque de concentration et les stratégies de sortie. Les Autorités européennes de surveillance maintiennent un registre des fournisseurs tiers ICT critiques, avec des pouvoirs de supervision directe sur ceux qui sont désignés comme tels. La nouvelle réalité opérationnelle est que les fournisseurs IA de 2026 — fournisseurs de modèles frontières, fournisseurs de plateformes d'agents, SaaS IA-enabled — sont, de plus en plus, les tiers ICT que DORA a été écrit pour couvrir.

Pour une banque en position d'achat, trois disciplines pratiques s'appliquent :

Exigez l'AIBOM du fournisseur. Tout produit agentique acheté pour des workflows à haut risque doit s'accompagner d'une bill of materials documentée couvrant les modèles sous-jacents, la provenance et les limitations des données d'entraînement, les fine-tunes appliqués, les index de retrieval accédés, les versions de prompt templates et la chaîne de dépendances vers les composants agents en aval. C'est l'artefact dont la banque aura besoin pour satisfaire les exigences de documentation de l'article 13 du Règlement européen sur l'IA. La banque ne peut pas le produire rétrospectivement d'un fournisseur qui ne s'y est pas contractuellement engagé.

Testez la boîte noire, pas la brochure. Les évaluations de procurement fournisseur ont historiquement porté sur la comparaison de fonctionnalités et les entretiens avec des clients références. Pour les systèmes agentiques, ce n'est pas suffisant. L'institution doit conduire un testing comportemental de l'agent dans des conditions analogues à son déploiement de production cible — incluant le probing adversarial pour l'injection de prompt, la résistance à l'ingénierie sociale (le vecteur Step Finance), la dérive sous changement de distribution de données, et les modes de latence et de défaillance des chemins de kill switch et d'override. La plupart des contrats fournisseur actuels n'autorisent pas cette profondeur de testing sans négociation spécifique ; cette négociation doit avoir lieu avant la signature du contrat, pas après.

Renégociez les contrats sur les termes de l'article 13. La plupart des accords fournisseur IA existants ne contiennent aucun des droits de documentation, d'audit, de notification de changement de modèle, de reporting d'incident ou de divulgation de sous-traitants que le Règlement européen sur l'IA et DORA exigent conjointement. La Regulativ analysis of UK firms ⧉ a été explicite sur ce point : la revue juridique des accords fournisseur prend des semaines, et la plupart des institutions ne peuvent pas satisfaire l'article 13 pour un modèle dont leur fournisseur n'a jamais été contractuellement obligé de divulguer le fonctionnement interne. L'obligation réglementaire repose sur le déployeur, pas sur le fournisseur. Les équipes procurement doivent le savoir avant le prochain cycle de renouvellement, pas après une enquête réglementaire.

Le résumé pour le conseil est que la relation fournisseur est passée du procurement au transfert de risque — et le risque ne se transfère pas, en réalité. La banque reste le déployeur. La banque reste responsable. La banque a besoin des instruments contractuels et de la discipline de testing qui rendent sa responsabilité tractable plutôt que simplement formelle.

Ce que cela signifie par type de banque #

La bonne réponse varie. Le pattern ci-dessous est une segmentation grossière, pas une prescription.

Banques universelles de premier rang #

Les institutions avec 1 000 milliards de dollars de bilan et une présence mondiale sont simultanément les plus exposées (périmètre réglementaire le plus large, estate hérité le plus grand, cible de plus haute valeur pour les adversaires autonomes) et les mieux dotées. La priorité stratégique est de construire le plan de contrôle d'abord — couche 4 de l'architecture ci-dessus — et d'introduire la discipline du développement piloté par spécification dans la fonction d'ingénierie interne avant de mettre à l'échelle davantage le déploiement d'agents. La conséquence concurrentielle de bien faire les choses est significative ; la conséquence de mal les faire est existentielle, étant donné l'exposition aux pénalités du Règlement européen sur l'IA et l'exposition opérationnelle aux patterns de menace de classe GTG-1002.

Banques de taille intermédiaire et régionales #

La question concurrentielle pour les banques de second rang est plus tranchante que pour celles de premier rang. Elles font face au même périmètre réglementaire sans le même budget de gouvernance, à la même surface de menace sans les mêmes ressources défensives, et à une base client qui se compare de plus en plus à des fintechs IA-natives. La réponse pratique est de standardiser fortement sur un petit ensemble de fournisseurs vérifiés (avec des contrats qui satisfont les exigences de documentation de l'article 13), d'investir dans la discipline du développement piloté par spécification plutôt que dans une ingénierie plateforme sur mesure, et d'utiliser l'outillage agentique pour comprimer le calendrier de modernisation COBOL qui a été une ancre stratégique pendant deux décennies. Les institutions qui bougent tôt ici fermeront, matériellement, le fossé technologique avec les banques de premier rang pour la première fois en une génération.

Fintechs, PSP et institutions crypto-adjacentes #

Le segment fintech et institutions de paiement a le problème inverse : l'agilité est élevée, la gouvernance est souvent plus faible que chez les banques pairs, et l'exposition aux pénalités du Règlement européen sur l'IA est, pour une fintech de taille moyenne, potentiellement existentielle. La discipline stratégique est de traiter la gouvernance IA comme une porte de readiness produit plutôt qu'une couche de conformité — en construisant l'AIBOM, le substrat d'audit et les workflows pilotés par spécification dans la culture d'ingénierie dès le départ plutôt que de les retrofitter sous pression réglementaire. Pour les institutions dont l'infrastructure de paiement intersecte la date butoir SWIFT CBPR+ d'adresses structurées de novembre 2026, l'investissement en ingénierie agentique est aussi le mécanisme naturel pour industrialiser le travail de remédiation d'adresses structurées — les règles de validation, l'enforcement de la qualité des données et l'intégration pipeline CI sont précisément les patterns que les workflows pilotés par spécification rendent tractables.

Fonctions d'ingénierie interne #

Pour les ingénieurs et les chercheurs qui lisent cet article, la discipline de travail qui compte est la quotidienne. Déplacez le centre de gravité du travail de taper des caractères à produire des spécifications et des harnais de vérification. Traitez les traces d'agent, les plans intermédiaires et les portes d'approbation comme des artefacts de première classe dans votre gestion de version. Investissez dans l'outillage — Spec Kit, Kiro, le mode plan de Cursor, Claude Code avec des skill files au niveau projet — qui fait de la spécification l'artefact durable et du code généré le jetable. Le glissement ergonomique est réel. Le bénéfice professionnel est que la discipline adoptée à la frontière est aussi la discipline qui survit à l'examen réglementaire.

Le plan d'action de 12 semaines vers août 2026 #

Pour le sponsor exécutif qui pilote un programme d'ingénierie agentique entre maintenant et la date d'application du Règlement européen sur l'IA, le travail se compresse en une séquence de douze semaines. Le plan ci-dessous n'est pas exhaustif ; c'est le minimum qu'un conseil devrait attendre d'un programme crédible avant le 2 août 2026.

Semaines 1-2 — Produire l'AIBOM. Mettre en place l'inventaire centralisé de chaque système IA, modèle, jeu de données, prompt template, index de retrieval, fine-tune et dépendance IA tierce en production ou en développement. Cartographier chaque entrée à la classification annexe III du Règlement européen sur l'IA. Le livrable est une source de vérité unique que le CRO, le CCO, le CISO et le CTO peuvent interroger.

Semaines 3-4 — Classifier le modèle de supervision par système. Pour chaque agent à haut risque et conséquent, documenter explicitement si le modèle de supervision est HITL ou HOTL, le rationale, le chemin d'escalade, et la personne responsable nommée sous SM&CR (UK) ou le régime national équivalent. Lorsque la réponse n'est pas claire, défaut à HITL jusqu'à ce que l'analyse soit complète.

Semaines 5-6 — Construire ou durcir le plan de contrôle des agents. Logging d'actions en temps réel, détection d'anomalies comportementales, kill switches et chemins d'override opérationnels sur chaque agent en production. Quand le plan de contrôle n'existe pas encore pour un système, ce système passe en statut de déploiement restreint jusqu'à ce qu'il existe.

Semaines 7-8 — Revue des contrats fournisseur. Le juridique et le procurement parcourent chaque contrat fournisseur IA actif pour les droits de documentation article 13, la notification de changement de modèle, le reporting d'incident, les droits d'audit et la divulgation de sous-traitants. La sortie est une liste tierée : conforme, remédiation requise, remplacement requis. Les décisions de remplacement doivent démarrer maintenant pour avoir une chance d'aboutir cette année.

Semaines 9-10 — Répétition générale de l'évaluation de conformité. Pour chaque système à haut risque sous l'annexe III, compléter le workflow d'évaluation de conformité comme si un organisme notifié arrivait la semaine suivante. Cela fera émerger des écarts qui paraissent mineurs sur le papier et qui sont opérationnellement sévères à l'examen. Corrigez ce qui peut être corrigé ; documentez le résiduel.

Semaines 11-12 — Validation pré-bascule et sign-off conseil. Revue finale de l'AIBOM, des classifications HITL/HOTL, des preuves du plan de contrôle, du statut de remédiation fournisseur et des sorties d'évaluation de conformité. Responsabilité de senior manager nommée confirmée. Position consignée au procès-verbal du conseil. Notifier le régulateur où le cadre s'attend à une pré-notification.

Les institutions qui complèteront cette séquence de douze semaines n'auront pas résolu l'ingénierie agentique. Elles auront établi le socle qu'un programme crédible exige. Les institutions qui n'ont pas commencé à la date de publication de cet article ne sont pas, comme l'analyse Regulativ l'a formulé côté SWIFT, uniquement négligentes. Elles sont la majorité. La question que chaque CCO, CRO et CTO doit se poser dans les quinze prochains jours est de savoir si la firme agit en mai ou panique en juillet.

Conclusion #

L'observation dure qui s'est cristallisée à l'échelle de l'industrie ces six derniers mois est que les anciennes manières d'opérer à l'échelle d'entreprise sont dépassées non par une nouvelle technologie mais par un nouveau pattern de travail. Les outils agentiques ont révélé — parfois en production, parfois dans des rapports d'incident — des failles et des écarts dans les estates hérités qui s'accumulaient silencieusement depuis des années. Les mêmes outils ont donné aux acteurs malveillants des ressources qui exigeaient auparavant un soutien d'État. Les mêmes outils, utilisés en interne avec discipline, constituent le chemin le plus crédible pour les institutions afin de combler le retard du legacy, satisfaire l'échéance réglementaire d'août 2026 et atteindre le tempo opérationnel que les attentes clients et les réalités concurrentielles exigent désormais.

Les institutions qui s'approprient cette position en interne — qui traitent l'ingénierie agentique comme une capacité structurelle de la banque plutôt qu'une couche de productivité achetée à un fournisseur — passeront les deux prochaines années à composer leur avantage. Les institutions qui ne le font pas passeront les deux prochaines années à découvrir, dans des rapports d'incident et des findings de régulateur, ce qu'elles auraient dû construire. Le choix entre ces deux issues est une décision de conseil 2026, pas une décision technologique 2028.

Pour le contexte préalable sur ce site, l'article d'avril 2026 sur les seuils quantiques a couvert la trajectoire matérielle qui sous-tend la couche 1 de l'architecture ci-dessus, l'article de mai 2026 sur la migration post-quantique en finance d'entreprise a couvert le substrat cryptographique en profondeur, l'analyse de mai 2026 sur la deadline pacs.008 d'adresses structurées a couvert la discipline réglementaire et d'ingénierie que la validation pilotée par spécification rend tractable, et les travaux Rust open source sur KyberLib, pain001 et pacs008 s'inscrivent dans l'effort plus large pour mettre des primitives de qualité production — résistantes au quantique, conformes paiements, audit-ready — entre les mains des équipes d'ingénierie qui construiront la banque agentique. La connexion entre ces pièces n'est pas fortuite. C'est la forme du travail que les deux prochaines années exigent.

Questions ? Réponses.

Quelle est la différence entre IA générative, IA agentique et ingénierie agentique ?

L'IA générative produit du contenu en réponse à un prompt ; elle est réactive. L'IA agentique poursuit des objectifs définis de manière autonome, en accédant aux données, en utilisant des outils et en prenant des actions sur des workflows multi-étapes sans nécessiter de prompt humain à chaque étape. L'ingénierie agentique — le terme adopté par Karpathy en 2026 ⧉ — est la discipline de travail consistant à orchestrer des agents contre des spécifications détaillées avec supervision humaine. Pour la banque, la distinction compte parce que le périmètre réglementaire, le modèle de menace et la discipline d'ingénierie sont différents pour chaque catégorie. Une interface de chat et un agent de trading pleinement autonome ne sont pas dans la même classe réglementaire, et les traiter comme s'ils l'étaient crée de l'exposition aux deux extrémités.

Pourquoi la date butoir d'août 2026 du Règlement européen sur l'IA est-elle si conséquente pour les banques ?

L'annexe III du Règlement européen sur l'IA classe explicitement plusieurs cas d'usage IA bancaires centraux comme à haut risque : l'évaluation de solvabilité et le scoring de crédit de personnes physiques, l'évaluation des risques et la tarification en assurance vie et santé, et l'évaluation ou classification de la situation financière des individus. À compter du 2 août 2026, les déployeurs de ces systèmes doivent démontrer la conformité avec des systèmes de management de la qualité, des cadres de gestion du risque, une documentation technique, des évaluations de conformité, des enregistrements dans la base de données européenne, une gouvernance des données robuste, la supervision humaine et des protections cybersécurité. L'article 12 exige la journalisation automatique des entrées et sorties. L'article 14 exige une supervision humaine significative (HITL ou HOTL, selon le système). Les pénalités atteignent 35 millions d'euros ou 7 % du chiffre d'affaires mondial annuel. Le travail pour satisfaire ces obligations est du travail d'ingénierie — pas du travail documentaire — et c'est la raison pratique pour laquelle la discipline pilotée par spécification a accéléré au premier trimestre 2026.

Quelle est la différence pratique entre HITL et HOTL, et quand chaque modèle s'applique-t-il ?

HITL (Human-in-the-Loop) signifie que l'agent ne peut pas exécuter d'actions conséquentes sans approbation humaine explicite. HOTL (Human-on-the-Loop) signifie que l'agent s'exécute de manière autonome dans des paramètres bornés, avec des humains surveillant la télémétrie et conservant l'autorité d'arrêt à tout moment. L'article 14 du Règlement européen sur l'IA exige que la supervision soit significative mais ne prescrit pas quel modèle. La règle de décision consiste à appliquer HITL lorsque l'action est conséquente, à faible volume et irréversible (refus de crédit, clôture de compte, autorisation de virement de gros montant, soumission de déclaration réglementaire), et HOTL lorsque l'action est à fort volume, réversible et à paramètres bornés (alertes de monitoring de transactions, classification de documents, triage routinier de service client). Les deux exigent que l'infrastructure de kill switch et d'override soit opérationnelle et testée ; la différence est de savoir si l'humain est en amont de l'exécution (HITL) ou à côté (HOTL).

La plupart de nos agents viendront de fournisseurs. Comment satisfaire DORA et le Règlement européen sur l'IA pour des systèmes que nous n'avons pas construits ?

L'obligation réglementaire repose sur le déployeur, pas sur le fournisseur. La réponse pratique est triple. Premièrement, exigez du fournisseur un AIBOM documenté avant signature — lignée des modèles, provenance des données d'entraînement, fine-tunes, prompt templates, index de retrieval, chaîne de dépendances. Deuxièmement, conduisez un testing comportemental de l'agent dans des conditions analogues à la production, y compris le probing adversarial pour l'injection de prompt et la résistance à l'ingénierie sociale. Troisièmement, renégociez les contrats fournisseur pour inclure les droits de documentation article 13, la notification de changement de modèle, le reporting d'incident, les droits d'audit et la divulgation de sous-traitants — la plupart des contrats existants ne comportent rien de tout cela. Les articles 28 à 30 de DORA couvrent la gestion du risque ICT tiers et constituent l'ancre réglementaire pertinente côté européen ; la guidance FFIEC est l'équivalent côté américain. Le travail est significatif ; il ne peut pas être différé.

À quel point les banques doivent-elles vraiment s'inquiéter des adversaires agentiques ?

La réponse honnête est que la menace est réelle et opérationnellement distincte des menaces cyber précédentes. La divulgation par Anthropic de GTG-1002 en novembre 2025 est l'exemple canonique : IA agentique gérant 80 à 90 % des opérations tactiques dans une campagne d'espionnage parrainée par un État, contre environ trente cibles dans la défense, l'énergie et la technologie, opérant à plusieurs milliers de requêtes par seconde. L'incident Step Finance en janvier 2026 — perte de 27 à 30 millions de dollars due à des agents IA de trading avec une autorité sur-permise — est l'exemple canonique de la façon dont un déploiement IA interne peut devenir une surface d'attaque. Le Flashpoint 2026 GTIR a observé une hausse de 1 500 % des discussions illicites liées à l'IA en un seul mois. Ce ne sont pas des scénarios hypothétiques ; c'est de la matière de rapport d'incident 2025-2026. Les banques qui font tourner des opérations défensives classiques contre des adversaires agentiques sont, structurellement, asymétriquement exposées, et la réponse correcte est de construire une capacité défensive IA-contre-IA plutôt que de ralentir la transition agentique côté offensif.

L'IA agentique est-elle juste « ChatGPT plus des serveurs MCP » ?

Non, et c'est l'une des idées reçues les plus conséquentes du marché actuel. Une interface de chat augmentée de serveurs MCP est un pattern utile pour récupérer et agir sur des données dans une session bornée. L'ingénierie agentique est une capacité structurelle de l'institution — l'AIBOM, le plan de contrôle des agents, le pipeline de développement piloté par spécification, le substrat d'audit, la fondation cryptographique résistante au quantique, les patterns d'orchestration sur les parcours client de bout en bout. Ce ne sont pas des fonctionnalités achetées à un fournisseur ; c'est une position de propriété institutionnelle. Les banques qui traitent la question comme une décision de procurement aboutissent à des déploiements peu profonds qui échouent à l'examen. Les banques qui la traitent comme une question de propriété d'ingénierie et de gouvernance aboutissent à un actif qui se compose.

Quelle est la chose la plus importante qu'une banque devrait faire dans les douze prochaines semaines ?

Trois choses, séquencées. Premièrement, produire l'AI Bill of Materials — l'inventaire complet de chaque système IA, modèle, jeu de données, prompt template, index de retrieval et dépendance IA tierce en production ou en développement, avec chaque entrée classifiée par rapport à l'annexe III du Règlement européen sur l'IA. L'institution qui ne peut pas le produire quand un régulateur le demande est l'institution qui recevra des findings. Deuxièmement, construire le plan de contrôle des agents pour tout système IA qui prend ou influence matériellement des décisions affectant le client — logging d'audit, détection d'anomalies comportementales, override humain et kill switches comme infrastructure par défaut, pas comme item de roadmap futur. Troisièmement, déplacer la culture d'ingénierie interne du vibe coding vers le développement piloté par spécification sur les travaux qui comptent le plus — systèmes à haut risque, workflows régulés et pipeline de modernisation legacy. Les deux premières sont du travail de conformité ; la troisième est du travail concurrentiel. Les institutions qui font les trois seront matériellement dans une position plus forte que celles qui n'en font qu'une ou aucune. La séquence complète sur douze semaines est exposée dans la section plan d'action ci-dessus.

Références #

Dernière révision .