De la fragmentation à la ligne de fracture : le standard d'API manquant de la banque d'entreprise à l'ère agentique

La banque de détail a obtenu son standard d'API il y a dix ans. La banque d'entreprise, jamais — et en 2026 cette omission a cessé d'être une nuisance pour devenir une ligne de fracture. ISO 20022 a donné au secteur une grammaire commune ; il ne lui a jamais donné une surface commune, prête pour les agents. Aujourd'hui, l'appelant a changé. Ce n'est plus un développeur disposant d'un trimestre à consacrer à l'intégration, mais un modèle qui découvre les outils au runtime et déplace de l'argent à l'intérieur de bandes de politique. L'ambiguïté que les trésoriers d'entreprise absorbent discrètement depuis vingt ans est sur le point d'être confiée à un logiciel qui ne peut pas l'absorber — pendant que la couche de données sous-jacente est forcée à la structuration, que les banques le veuillent ou non. Voici ce que coûte l'absence de direction, pourquoi les agents rendent la fragmentation actuelle dangereuse et non plus seulement inefficace, et ce qu'un standard d'API pour la banque d'entreprise doit imposer avant que la trésorerie autonome puisse passer à l'échelle.

Résumé analytique

La banque d'entreprise a la grammaire, pas la surface. ISO 20022 a standardisé les données ; personne n'a standardisé l'API. C'était supportable tant qu'un intégrateur humain absorbait l'ambiguïté — un modèle au runtime ne le peut pas.

L'appelant a changé. MCP a fait de la découverte d'outils une décision au runtime. Un agent censé abolir le problème d'intégration M×N le retrouve à la frontière bancaire, où chaque institution est un serveur sur mesure avec sa propre sémantique.

La fragmentation déplace désormais l'argent de travers, à la vitesse de la machine. Un timeout, trois banques, trois vérités contradictoires — un doublon chez A, une instruction bloquée chez B, une défaillance silencieuse chez C. L'idempotence et une grammaire d'erreurs déterministe deviennent porteuses.

Envelopper chaque banque dans un serveur MCP déplace le marécage. Quarante serveurs, quarante sémantiques, aucun socle non fonctionnel partagé — et un modèle non déterministe disposant d'un accès en écriture aux rails de paiement, un problème carrément SR 11-7 / DORA / EU AI Act.

Standardisez votre propre surface, ou devenez la commodité. Les banques qui publient dès maintenant une API native ISO 20022 et prête pour les agents deviennent les contreparties par défaut de la trésorerie autonome ; les autres louent leur relation client à celui qui détient l'adaptateur.

Deux mondes bancaires, un seul standardisé

Observez le détail et le tableau est désordonné mais navigable. L'Europe a l'UK Open Banking et le NextGenPSD2 du Berlin Group, ce dernier adopté par plus des trois quarts des banques européennes et traité en pratique comme un standard de fait. Les États-Unis ont le Financial Data Exchange, qui couvre désormais plus de soixante millions de comptes de particuliers. L'Australie a le Consumer Data Right. Aucun d'entre eux n'est mondial, et aucun n'est susceptible de le devenir — mais chacun est un contrat réel, versionné et testable par machine, et là où les contrats s'arrêtent, les agrégateurs (Plaid, Tink, TrueLayer, Salt Edge) absorbent la différence derrière une interface unique. La fragmentation du détail est une taxe. Ce n'est pas un mur.

La banque d'entreprise et de gros n'a aucun équivalent. Une trésorerie multinationale atteint ses banques par des tuyaux de fichiers host-to-host, une douzaine de portails sur mesure, un système de gestion de trésorerie ou un agrégateur — généralement les quatre à la fois. Ce n'est pas un homme de paille : les propres travaux de McKinsey sur la transaction banking cataloguent le même héritage depuis des années, décrivant comment les banques s'appuient sur le transfert de fichiers host-to-host et SFTP, énumérant les modes de défaillance bien connus de l'intégration par fichiers — des formats ERP volumineux qui doivent être personnalisés pour chaque entreprise, une incapacité à gérer le routage conditionnel — et rapportant que plus de 85 % des dirigeants de la transaction banking comptent investir dans des API de cash management. L'appétit pour les API ne fait aucun doute. Ce qui manque, c'est le contrat commun qu'elles visent.

Car les candidats habituels ne le sont pas. ISO 20022 est régulièrement pris pour le standard manquant, mais c'est une grammaire de données, pas un contrat d'API : pain.001 vous dit comment formuler un virement, pas quel endpoint en crée un, comment il s'authentifie, comment il pagine, ou comment il vous signale qu'il a échoué. BIAN donne au secteur un modèle de référence sémantique partagé, pas une interface imposée. Les API Payment Initiation et Instant Cash Reporting de Swift constituent un vrai pas vers la standardisation, mais elles sont centrées sur le réseau et encore émergentes, et non une surface universelle. Le cadre openFinance du Berlin Group s'étend vers les cas d'usage entreprise — ouverture de compte, financement du commerce, paiements récurrents dynamiques — mais il est européen, précoce et premium par accord. Assemblez tout cela et vous n'avez toujours pas de standard d'API contraignant et mondial pour la banque d'entreprise. Vous avez des matériaux de construction et aucun plan.

Pourquoi la fragmentation a survécu — et pourquoi cela prend fin

Pendant vingt ans, cela a été tolérable, parce que l'intégrateur était humain et patient. Une entreprise mettait en place une poignée de connexions bancaires sur des mois, parfois des trimestres. Chacune était un projet : certificats échangés, un penny test exécuté, un document de mapping âprement débattu. Le coût était réel mais payé une fois par relation et amorti sur des années de paiements ultérieurs. Quand l'API d'une banque était sous-spécifiée — quand un standard « laissait le reste à l'institution qui l'implémente », comme les banques elles-mêmes s'en plaignent — un ingénieur humain lisait le portail, déduisait l'intention et comblait l'écart. L'ambiguïté était supportable parce qu'une personne était là pour la résoudre.

Elle a aussi survécu pour des raisons moins souvent dites à voix haute. La plomberie sous-jacente est réellement difficile à changer : fenêtres de règlement par lots, cycles de nuit et cœurs mainframe qui n'ont jamais été conçus pour répondre à une question en temps réel. Et la fragmentation n'est pas seulement un accident — c'est, discrètement, une forme de verrouillage. Chaque tuyau host-to-host sur mesure qu'un trésorier construit est un coût de changement qui bénéficie à l'acteur en place. Une banque difficile à intégrer est, à la marge, une banque difficile à quitter. Rien de tout cela n'est complotiste ; c'est de l'incitation ordinaire. Mais cela explique pourquoi un secteur qui s'est accordé sur une grammaire de données ne s'est jamais accordé sur une surface — et pourquoi la surface est la dernière couche non standardisée restante. La raison pour laquelle elle ne peut plus tenir, c'est que la couche en dessous est forcée à la structuration dans un délai imparti, et que la couche au-dessus vient d'acquérir un nouvel utilisateur, impatient.

L'appelant a changé

Cet utilisateur est arrivé en dix-huit mois. Le Model Context Protocol, qu'Anthropic a rendu open source en novembre 2024 et donné à l'Agentic AI Foundation de la Linux Foundation en décembre 2025 aux côtés de Block et OpenAI, est devenu la voie par défaut par laquelle les systèmes d'IA atteignent les outils et les données. Début 2026, il enregistrait environ quatre-vingt-dix-sept millions de téléchargements de SDK par mois ; à mi-année, selon une lecture directionnelle du secteur, environ soixante-dix-huit pour cent des équipes IA d'entreprise faisaient tourner des agents adossés à MCP en production et plus d'un quart du Fortune 500 exploitaient des serveurs MCP, sécurisés par une couche d'autorisation OAuth 2.1 standard. Il est couramment, et à juste titre, décrit comme l'USB-C de l'IA : il fait s'effondrer le cauchemar d'intégration M×N — chaque modèle câblé à la main à chaque outil — en M+N. Son propre résumé de lui-même est la phrase qui compte pour les banques : les API sont pour les programmes ; MCP est pour les agents. Une API REST attend de l'appelant qu'il sache à l'avance quel endpoint appeler et avec quels paramètres. Un agent s'attend à découvrir les outils disponibles au runtime et à décider lui-même comment et quand les utiliser.

Ce n'est pas hypothétique pour la trésorerie. Le schéma est déjà constant dans les trésoreries des banques de financement et d'investissement en 2026 : un agent lit des données de trésorerie ISO 20022, appelle un ensemble borné d'outils et rééquilibre la liquidité à l'intérieur de bandes de politique, avec les contrôles SR 11-7, DORA et EU AI Act enveloppés autour de lui. La grammaire de données est prête pour cela. La surface d'API ne l'est pas.

Le décalage, précisément

Réduisez l'agent à ce dont il a réellement besoin de la part d'une contrepartie bancaire et la liste est courte et impitoyable :

Un contrat découvrable par machine — une description OpenAPI, ou un manifeste d'outils, que l'agent peut lire au runtime plutôt qu'un PDF qu'un humain lit une fois.
Un seul modèle d'authentification — un profil OAuth2/mTLS de qualité financière (FAPI est l'ancrage évident), pas une poignée de main différente par banque.
L'idempotence comme garantie — une référence d'instruction unique qui fait d'un paiement réémis un no-op, parce qu'un agent va réessayer.
Une grammaire d'erreurs déterministe — la même défaillance signifiant la même chose partout, pour que le modèle puisse raisonner dessus.
Un versionnage sémantique et la découverte des capacités — pour qu'un agent puisse savoir ce qu'une contrepartie sait faire ce trimestre sans note de version rédigée par un humain.
Des payloads ISO 20022 structurés, le consentement et les habilitations, et une piste d'audit infalsifiable — la substance, la permission et la preuve.

Confrontez cela à la banque d'entreprise telle qu'elle existe et chaque ligne se fracture en N dialectes — un par banque. L'agent censé abolir le problème M×N le retrouve à la frontière bancaire, parce que chaque institution est, de fait, un serveur sur mesure avec sa propre grammaire pour « solde », sa propre notion de « statut de paiement », sa propre danse d'authentification et sa propre idée de ce qu'est une erreur. Le protocole a standardisé le côté agent du fil. Personne n'a standardisé celui de la banque.

Un mode de défaillance, rendu concret

Rendez-le spécifique, car c'est là que l'abstraction mord. Imaginez un agent de liquidité autorisé à balayer la trésorerie sur trois banques pour maintenir chaque compte à l'intérieur d'une bande cible. Il déclenche trois instructions quasi identiques et, comme le font les réseaux, se heurte à un timeout sur chacune.

La banque A traite le timeout comme inconnu — sûr à réessayer, donc l'agent réessaie, et l'instruction d'origine se règle aussi : un paiement en doublon. La banque B traite le même timeout comme soumis — ne pas réessayer, mais ne fait jamais remonter de confirmation que l'agent puisse analyser, donc l'instruction reste dans les limbes tandis que l'agent, ne voyant aucun succès, escalade ou reroute : un paiement bloqué et une position comptabilisée deux fois. La banque C renvoie un joyeux HTTP 200 avec un rejet enfoui dans le corps du payload ; l'agent lit le code de statut, marque le balayage comme terminé et passe à autre chose : une défaillance silencieuse qui ne fait surface que le lendemain matin, sous la forme d'un écart de rapprochement que personne ne peut expliquer.

Trois banques, une condition, trois vérités contradictoires — des fonds en doublon sortis chez A, une instruction gelée chez B, un succès fantôme chez C. Un trésorier humain aurait téléphoné à trois chargés de relation et réglé l'affaire avant le déjeuner. L'agent ne peut téléphoner à personne. C'est exactement pourquoi « l'idempotence comme garantie » et « une grammaire d'erreurs déterministe » ne sont pas des agréments d'architecture : sans elles, la même fragmentation qui ne coûtait que des heures humaines déplace désormais de l'argent réel de manière incorrecte, à la vitesse de la machine, sur toutes les contreparties à la fois.

Pourquoi « envelopper chaque banque dans un serveur MCP » n'est pas la solution

La réponse réflexe est de donner à chaque banque un serveur MCP et d'en finir. Elle ne tient pas, parce qu'elle déplace la fragmentation au lieu de la supprimer. Quarante banques deviennent quarante serveurs avec quarante sémantiques, quarante flux d'authentification et aucun sens partagé — et, surtout, aucun socle non fonctionnel partagé : pas de budget de latence commun, pas de palier de disponibilité convenu, pas de garantie d'idempotence comparable. Le mode de défaillance ci-dessus survit intact à l'enveloppe. Pire, l'appelant est désormais un modèle non déterministe disposant d'un accès en écriture aux rails de paiement, ce qui n'est pas seulement une question d'intégration mais de risque de modèle et de résilience opérationnelle qui atterrit carrément sur SR 11-7, DORA et l'EU AI Act. Les primitives human-in-the-loop de MCP — l'elicitation pour la confirmation, le sampling pour le raisonnement — sont nécessaires et bienvenues, mais une boîte de dialogue de confirmation ne remplace pas une contrepartie au comportement prévisible. On ne peut pas gouverner à l'échelle ce qu'on ne peut pas décrire uniformément. Mille serveurs sur mesure ne sont pas un standard ; c'est le même marécage recouvert d'un vernis JSON-RPC.

Deux futurs, et un choix stratégique

Celui qui résout ce problème détermine qui possédera la relation entreprise pour la prochaine décennie, et il n'y a que deux candidats.

Dans le premier, les banques standardisent leurs propres surfaces. Elles publient des API prêtes pour les agents, conservent la connexion directe au trésorier et restent la contrepartie que l'agent découvre et appelle. Dans le second, les agrégateurs la standardisent à leur place. Une poignée de plateformes définissent le contrat d'agent de fait, et les banques deviennent des endpoints interchangeables derrière lui — accessibles seulement à travers l'abstraction de quelqu'un d'autre. Ce n'est pas de la spéculation ; c'est l'histoire du détail rejouée un segment plus loin. Les propres travaux 2025 de McKinsey sur la transaction banking décrivent des plateformes de gestion de trésorerie telles que Kyriba et GTreasury, et des plateformes office-of-the-CFO telles que Bill.com, qui se positionnent entre les clients et les banques avec une vue unique et agnostique de la position. C'est précisément la couche qui, dans le détail, a discrètement fait disparaître la longue traîne derrière Plaid et Tink. Les mêmes travaux notent que les trésoriers d'entreprise tiennent désormais leurs banques aux standards de leurs applications grand public, et changeront de banque quand l'onboarding, les habilitations et l'intégration d'API les décevront.

Le contenu stratégique du choix est brutal. Une banque qui devient un endpoint derrière le contrat d'agent d'un agrégateur cède trois choses à la fois. La marge, à mesure que ses services sont banalisés et comparés d'abord sur le prix à travers l'interface de quelqu'un d'autre. La propriété du client, à mesure que la relation, le contexte et le coût de changement migrent vers la plateforme. Et le pouvoir de la donnée et de l'analytique, à mesure que le flux qu'elle voyait autrefois de bout en bout est désormais médié par un intermédiaire qui voit plus du client que la banque n'en voit. Standardiser votre propre surface n'est pas un projet d'hygiène technique. C'est la différence entre être la contrepartie et être la commodité.

Ce que le standard doit imposer

La direction qui manque n'a rien d'exotique. Chaque composant existe déjà, en libre accès — ISO 20022 pour les données, les API Payment Initiation et Instant Cash Reporting de Swift pour les opérations de référence, BIAN pour la sémantique, l'openFinance du Berlin Group pour le motif consentement-et-catalogue, FAPI pour l'authentification de qualité financière, MCP pour l'exposition des outils, A2A pour l'orchestration agent-à-agent. Ce qui est absent, c'est l'acte de les assembler en un contrat contraignant pour l'espace entreprise — et la discipline de spécifier deux socles, pas un. La littérature existante sur les API B2B, y compris celle de McKinsey, traite largement les API comme une opportunité de croissance et d'expérience. Elle dit peu de choses sur le déterminisme, la découverte des capacités au runtime, ou les non-fonctionnels standardisés — exactement l'omission que les agents ne peuvent pas tolérer. Le standard doit donc être explicite à la fois sur ce qu'est l'interface et sur la façon dont elle se comporte sous gouvernance.

Le socle technique

Un contrat OpenAPI-first avec un manifeste d'outils MCP canonique généré à partir de lui — pas rédigé à la main à côté, pour que les outils qu'un agent voit ne puissent jamais diverger de l'API que la banque exploite.
L'authentification et le consentement de qualité FAPI comme poignée de main unique sur toute la surface.
L'idempotence et une taxonomie d'erreurs déterministe — codes stables, un sens par défaillance, documentés dans le contrat lui-même.
Des payloads natifs ISO 20022, structurés et prêts pour l'adresse hybride.
Un versionnage sémantique avec découverte des capacités au runtime — un agent peut demander ce que cette contrepartie sait faire aujourd'hui, et obtenir une réponse lisible par machine.

Le socle de gouvernance et de résilience

Des SLO non fonctionnels publiés et imposés — latence, disponibilité, débit, traitement de bout en bout (straight-through-processing) et effort humain — exprimés en chiffres réels de temps et de mouvement, pas en langage marketing.
Les habilitations, le consentement et une piste d'audit infalsifiable liés au chemin d'exécution, et non flottant dans un portail hors bande.
Des contrôles de risque de modèle et de résilience opérationnelle alignés sur SR 11-7, DORA et l'EU AI Act, pour que les appels d'un agent soient des événements gouvernés avec un responsable, et non des cas limites exotiques.

Il y a une leçon dure enfouie ici dans l'expérience du détail. Un standard qu'une machine exécute doit être plus précis qu'un standard qu'un intégrateur humain peut discrètement réparer ; la sous-spécification n'est plus un coût diffus payé en heures de développeur mais un mode de défaillance dur payé en paiements mal envoyés. Il est révélateur que l'effort d'harmonisation le plus autoritaire du secteur — les exigences de données ISO 20022 harmonisées du CPMI et du PMPG, que les systèmes de paiement du monde entier sont pressés d'adopter d'ici fin 2027 dans le cadre du programme du G20 sur les paiements transfrontaliers, pour combattre exactement cette fragmentation — n'est, selon sa propre description, ni une réglementation ni un standard d'API. Il harmonise les données. L'interface reste le travail de personne.

Une image cible

La construction est moins intimidante que le diagnostic, parce que ce sont trois couches, pas un programme. Une API canonique pour la banque d'entreprise expose les paiements et le reporting de trésorerie via REST et OpenAPI, avec des payloads natifs ISO 20022 et une authentification de qualité FAPI — un contrat, une grammaire, une poignée de main. Un pont MCP se place au-dessus et génère le manifeste d'outils exposé aux agents directement à partir de ce contrat OpenAPI, pour que la découverte, les schémas et les permissions soient dérivés de la surface plutôt que maintenus en parallèle d'elle. Et une couche de politique et de résilience enveloppe chaque appel d'agent avec les contrôles qui rendent l'autonomie sûre : limites de transaction et de contrepartie, segmentation, déclencheurs human-in-the-loop (elicitation sur les actions à haut risque), surveillance en direct des SLO et une coupure d'urgence ferme. Aucun diagramme n'est requis pour saisir l'idée — le standard n'est pas un nouveau rail, c'est un agencement discipliné de rails qui existent déjà, avec le chemin de l'agent et le chemin de la gouvernance intégrés dès le premier commit plutôt que rajoutés après l'incident.

Ce que font les banques crédibles dans les 24 prochains mois

Si vous acceptez que l'appelant a changé, le travail est concret et se décompose en cinq chantiers.

Publier une surface native ISO 20022 et OpenAPI-first. Prenez un corridor à forte valeur — typiquement les paiements transfrontaliers et le reporting de trésorerie — et exposez-le à travers une définition OpenAPI unique et versionnée avec des payloads ISO 20022, alignée sur vos schémas CBPR+ existants plutôt que sur une cinquième grammaire inventée. Rendez-la publique pour les clients et les agents internes, avec un sandbox, et traitez les changements comme des mises en production de produit. Le succès de la première année n'est pas la couverture complète ; c'est de prouver qu'un corridor peut être rendu adressable par agent de bout en bout.
Standardiser l'authentification et l'idempotence sur toute la surface. Adoptez un seul profil de qualité FAPI comme unique poignée de main, imposez des clés d'idempotence sur chaque écriture, et faites de « réessayer la même instruction » une garantie documentée dans le contrat — transformant « les agents réessaieront » d'un risque en une hypothèse sûre.
Définir une grammaire d'erreurs déterministe et la découverte des capacités. Donnez à chaque défaillance un code stable et une sémantique cohérente, ajoutez le versionnage sémantique, et exposez un catalogue de capacités qu'un agent peut interroger au runtime, avec des indicateurs explicites pour le support partiel, la dépréciation et « pas encore disponible ».
Rattacher les habilitations, le consentement et l'audit à la même surface. Déplacez les flux de consentement et d'approbation sur le chemin d'API, émettez une piste infalsifiable pour chaque instruction initiée par un agent — qui, quoi, quand, sous quelle bande de politique — et alignez-la explicitement sur SR 11-7, DORA et l'EU AI Act pour que la deuxième ligne puisse la valider.
Publier des socles non fonctionnels, puis mener un pilote d'agent supervisé. Engagez-vous sur des cibles de latence, de disponibilité, de débit et de STP pour le corridor et instrumentez-les ; puis mettez en place un agent supervisé de liquidité ou de balayage de trésorerie qui n'utilise que cette surface, avec des limites fermes, des points de contrôle human-in-the-loop et un audit complet, pendant six à douze mois. C'est la fonction de forçage que vous contrôlez vous-même — elle prouve qu'un agent peut déplacer de l'argent en toute sécurité à l'intérieur de bandes de politique quand la surface est prévisible, et elle vous dit vite où votre standard reste une aspiration plutôt qu'un fait.

La fonction de forçage

Le secteur vient de prouver qu'il sait bouger quand quelque chose l'y force. Le basculement de Swift vers l'adresse structurée de novembre 2026 — après lequel les adresses non structurées dans les paiements transfrontaliers sont simplement rejetées, sans conversion de secours — a tiré un marché réticent vers les données ISO 20022 structurées à une date fixe, renforcé par la poussée du CPMI pour des exigences de données harmonisées d'ici fin 2027 dans le programme du G20 sur les paiements. Remarquez ce que ces deux efforts standardisent : les données, pas l'interface. La grammaire est forcée au propre. La surface a été laissée à la discrétion de chaque banque — qui est précisément la discrétion avec laquelle les agents ne peuvent pas travailler. Pour un agent, cela signifie que les payloads seront enfin cohérents tandis que le comportement derrière eux reste divergent — une inversion de ce dont une machine a réellement besoin, à savoir un comportement prévisible d'abord et des données propres ensuite.

Voici donc l'erreur non forcée à éviter : attendre qu'un comité mondial bénisse un standard d'API pour la banque d'entreprise avant d'agir. Les banques qui publient dès maintenant une surface native ISO 20022 et prête pour les agents — un contrat OpenAPI, un manifeste MCP généré à partir de lui, une authentification de qualité financière et des socles non fonctionnels qu'elles tiendront réellement — deviendront les contreparties par défaut de la trésorerie autonome. Leurs outils seront ceux que les agents peuvent découvrir, en qui ils peuvent avoir confiance et qu'ils peuvent appeler sans humain au milieu. Les banques qui attendent ne seront accessibles qu'à travers l'abstraction d'un agrégateur, louant leur propre relation client à celui qui détient l'adaptateur.

Une grammaire sans direction n'est pas un standard. ISO 20022 a dit à la banque d'entreprise comment parler. Il ne lui a jamais dit où aller. Les agents sont arrivés, éloquents et impatients, et la carte n'est toujours pas là. La dessiner est désormais le travail d'infrastructure le plus lourd de conséquences de la transaction banking — et, pour une fois, l'échéance est fixée non par un régulateur mais par les machines qui attendent déjà à l'interface.

Foire aux questions

ISO 20022 n'est-il pas le standard manquant ? Non. ISO 20022 est une grammaire de données, pas un contrat d'API. pain.001 dit à un système comment formuler un virement ; il ne dit pas quel endpoint en crée un, comment il s'authentifie, comment il pagine, ou comment il signale une défaillance. La grammaire est prête pour les agents. La surface — l'interface découvrable par machine et au comportement uniforme qu'un agent appelle réellement — ne l'est pas.

Pourquoi ne pas simplement envelopper chaque banque dans un serveur MCP ? Parce que cela déplace la fragmentation au lieu de la supprimer. Quarante banques deviennent quarante serveurs avec quarante sémantiques, quarante flux d'authentification et — surtout — aucun socle non fonctionnel partagé : pas de budget de latence commun, pas de palier de disponibilité convenu, pas de garantie d'idempotence comparable. L'appelant est désormais un modèle non déterministe disposant d'un accès en écriture aux rails de paiement, ce qui est un problème de risque de modèle et de résilience opérationnelle sous SR 11-7, DORA et l'EU AI Act. Mille serveurs sur mesure ne sont pas un standard.

Quel est le premier geste le plus utile pour une banque ? Publier un corridor natif ISO 20022 et OpenAPI-first — typiquement les paiements transfrontaliers et le reporting de trésorerie — avec une poignée de main de qualité FAPI, l'idempotence comme garantie documentée, et une grammaire d'erreurs déterministe. Puis mener un pilote d'agent supervisé contre cette seule surface, avec des limites fermes, des points de contrôle human-in-the-loop et un audit complet. Prouver un corridor de bout en bout vaut mieux qu'une feuille de route qui couvre tout et n'impose rien.

Qui résout ce problème si les banques ne le font pas ? Les agrégateurs. Une poignée de plateformes de trésorerie et d'office-of-the-CFO définiront le contrat d'agent de fait, et les banques deviendront des endpoints interchangeables derrière lui — cédant la marge, la propriété du client et la donnée de bout en bout d'un seul coup. C'est l'histoire du détail, où Plaid et Tink ont absorbé la longue traîne, rejouée un segment plus loin dans la banque d'entreprise.

Références

Model Context Protocol — documentation officielle ⧉. [MCP rendu open source en novembre 2024 et donné à l'Agentic AI Foundation de la Linux Foundation en décembre 2025 aux côtés de Block et OpenAI ; la couche de découverte d'outils au runtime sur laquelle s'appuie l'analyse. Les chiffres d'adoption dans le texte sont des lectures directionnelles du secteur et signalés comme tels.]
Berlin Group — NextGenPSD2 et openFinance ⧉. [Le standard d'API de détail européen de fait et son extension vers les cas d'usage entreprise — cité pour le motif consentement-et-catalogue et le contraste détail-versus-entreprise.]
Financial Data Exchange (FDX) ⧉. [Le standard américain de partage de données de détail, cité pour l'échelle des contrats de détail standardisés face auxquels la banque d'entreprise n'a aucun équivalent.]
McKinsey & Company — Financial Services insights ⧉. [Recherche sur les API de transaction banking : héritage host-to-host / SFTP, l'intention d'investissement de ~85 % dans les API de cash management et l'intermédiation par les plateformes de trésorerie. Cité pour le diagnostic de marché ; le cadrage et les conclusions ici sont ceux de l'auteur.]
Bank for International Settlements (CPMI) — Exigences de données ISO 20022 harmonisées ⧉. [La poussée d'ici fin 2027 pour harmoniser les données de paiement — selon sa propre description, ni une réglementation ni un standard d'API — citée pour le point « une grammaire sans surface ».]
Swift — ISO 20022 pour les institutions financières ⧉. [CBPR+ et le jalon de l'adresse structurée de novembre 2026 ; les API Payment Initiation et Instant Cash Reporting citées comme opérations de référence, et non comme surface universelle.]

Dernière revue en juillet 2026. Analyse originale ; les sources sont citées, non reproduites. Les chiffres d'adoption et de marché sont des lectures directionnelles du secteur — à vérifier auprès des sources primaires avant republication. Sous licence CC-BY-4.0.

Dernière révision 2026-07-08.

Republier cet article

De la fragmentation à la ligne de fracture : le standard d'API manquant de la banque d'entreprise à l'ère agentique — Sebastien Rousseau

La banque de détail a obtenu son standard d'API il y a dix ans. La banque d'entreprise, jamais — et maintenant que les agents IA et le Model Context Protocol font de l'intégration une décision au runtime, l'écart est devenu une ligne de fracture.

Cet article est sous licence Creative Commons Attribution 4.0 International. La republication nécessite l'attribution à l'URL canonique.

De la fragmentation à la ligne de fracture : le standard d'API manquant de la banque d'entreprise à l'ère agentique — Sebastien Rousseau

La banque de détail a obtenu son standard d'API il y a dix ans. La banque d'entreprise, jamais — et maintenant que les agents IA et le Model Context Protocol font de l'intégration une décision au runtime, l'écart est devenu une ligne de fracture.

Originally published at https://sebastienrousseau.com/fr/2026-07-07-entreprise-banking-api-standard-agentique-mcp-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FONDATEUR · INGÉNIEUR