Les API bancaires ont cessé d’être un sujet d’architectes pour devenir une brique de droit : depuis la directive européenne sur les services de paiement, une banque doit ouvrir l’accès à certaines données de compte, à des acteurs agréés, et seulement avec l’accord de son client. Voici ce que ce dispositif permet réellement — et, tout aussi important, ce qu’il ne permet pas.
- Le périmètre légal ne couvre pas tous vos avoirs : il vise les comptes de paiement accessibles en ligne, pas l’ensemble de votre patrimoine.
- Deux services sont concernés : l’information sur les comptes (agrégation) et l’initiation de paiement.
- Le prestataire doit être agréé par l’ACPR (ou par une autorité européenne équivalente) et figure dans un registre public.
- Votre consentement est révocable et limité dans le temps — la réglementation impose de le réauthentifier périodiquement.
Plan de l'article
- De l’architecture monolithique à l’APIfication des banques
- Open banking : ce que dit exactement le cadre réglementaire
- Qui a le droit d’accéder à vos comptes, et sous quel statut
- Mécanismes de connexion et interopérabilité des API financières
- Agrégation, initiation de paiement : les usages réellement ouverts
- API partagées et banque en tant que service (BaaS)
- Ce que l’open banking ne fait pas
- Sécurité, consentement et confiance : les chiffres qui tiennent
- Questions fréquentes
De l’architecture monolithique à l’APIfication des banques #
Pendant longtemps, un système bancaire s’est présenté comme un bloc : cœur de métier, gestion de compte, vérification d’identité et traitement des paiements y étaient enchevêtrés, et toucher à l’un revenait à risquer les autres. Le passage à une architecture en modules renverse cette logique : chaque fonction est isolée dans un composant distinct, exposé au reste du système par une interface standardisée. Ajouter un service ne suppose alors plus de rouvrir le cœur bancaire, mais de le brancher. C’est ce découplage, bien plus que la technologie elle-même, qui explique la vitesse à laquelle des offres nouvelles apparaissent dans le secteur financier.
Open banking : ce que dit exactement le cadre réglementaire #
Le mouvement ne relève pas d’une bonne volonté du secteur : il découle d’une obligation. En Europe, la directive (UE) 2015/2366 sur les services de paiement — la DSP2 — impose aux banques d’ouvrir, de façon sécurisée, l’accès aux comptes de paiement consultables en ligne, au bénéfice de tiers autorisés et sur consentement du titulaire. Au Royaume-Uni, la Competition and Markets Authority a fait naître un dispositif parallèle, piloté aujourd’hui par Open Banking Limited, qui se présente comme l’entité de mise en œuvre décrite par l’ordonnance de la CMA.
À lire La Révolution Silencieuse des Banques: Comment les API Transforment le Monde Financier
Un point mérite d’être posé sans détour, parce qu’il vieillit vite : la DSP2 reste le texte applicable, et sa révision — le paquet communément appelé DSP3 et son règlement associé — était toujours en cours d’élaboration au moment où ces lignes sont mises à jour. L’Autorité bancaire européenne continue d’ailleurs de publier ses orientations sous DSP2 en visant l’échéance « jusqu’à ce que la DSP3 et le règlement s’appliquent ». Plutôt que d’annoncer un calendrier qui aura changé d’ici votre lecture, vérifiez l’état du texte à la source : page « payment services » de l’Autorité bancaire européenne et fiche EUR-Lex de la directive.
Qui a le droit d’accéder à vos comptes, et sous quel statut #
C’est le point que la plupart des présentations escamotent : l’ouverture ne bénéficie pas à qui veut, mais à des acteurs porteurs d’un statut réglementé, dont l’intitulé officiel compte autant que l’idée.
Le portail public de la Banque de France, de l’ACPR et de l’AMF détaille ces deux statuts : prestataires de services d’information sur les comptes et établissements de paiement.
Mécanismes de connexion et interopérabilité des API financières #
Techniquement, une API bancaire échange des données structurées — JSON le plus souvent, XML dans les usages de trésorerie — entre le système d’une banque et celui d’un tiers. L’échange s’ouvre par une authentification appuyée sur des certificats et des jetons délivrés selon des protocoles d’autorisation normalisés, dont OAuth 2.0 est le plus répandu ; des normes de messagerie financière comme ISO 20022 fixent un vocabulaire commun aux ordres et aux relevés.
L’interopérabilité tient précisément à cela : parce que le format est partagé, une banque, une fintech et un éditeur de logiciel n’ont pas à réécrire un connecteur à chaque partenariat — qu’il s’agisse d’une néobanque ou d’une suite logicielle d’entreprise devant se raccorder à plusieurs établissements.
Agrégation, initiation de paiement : les usages réellement ouverts #
Deux familles d’usages découlent des statuts décrits plus haut. L’agrégation réunit sur une interface unique les soldes et les opérations de plusieurs comptes en ligne, y compris ouverts dans des établissements différents : on visualise sa situation d’ensemble, on catégorise ses dépenses, on pose des alertes de seuil. L’initiation de paiement déclenche un virement depuis un compte tiers sans passer par l’application de la banque teneuse du compte.
Pour les organisations, ces deux briques se traduisent par l’automatisation du rapprochement bancaire, un suivi de trésorerie consolidé et une chaîne de règlement fournisseurs moins manuelle. Le gain est réel ; il est aussi souvent surestimé dans les argumentaires, où circulent des pourcentages d’économies avancés sans étude identifiable derrière. Mieux vaut mesurer sur son propre périmètre que reprendre un chiffre orphelin.
API partagées et banque en tant que service (BaaS) #
Le modèle de la banque en tant que service (BaaS) pousse la logique plus loin : un acteur agréé expose ses briques réglementées — ouverture de compte, émission de moyens de paiement, vérification d’identité — à des tiers qui les intègrent dans leur produit. Une place de marché encaisse, une application de paie verse, un logiciel métier propose un financement, sans qu’aucun ne devienne banque.
C’est là que l’ouverture technique rejoint le parcours client : le service financier cesse d’être une destination séparée pour devenir une étape intégrée. La contrepartie, rarement dite, est une chaîne de responsabilité plus longue — entre l’éditeur visible, l’acteur agréé et la banque teneuse du compte.
Ce que l’open banking ne fait pas #
Un article qui ne présenterait que les bénéfices de ce dispositif serait trompeur par construction. Quatre limites structurelles méritent d’être connues avant de connecter quoi que ce soit à vos comptes.
- Le périmètre n’est pas tout votre argent. L’obligation d’ouverture porte sur les comptes de paiement accessibles en ligne. Ce que vous voyez dans un agrégateur au-delà de ce périmètre relève d’accords commerciaux ou de techniques de collecte hors cadre — pas du droit d’accès.
- Ce n’est pas du temps réel. Sans action de votre part, un agrégateur ne peut interroger un compte donné qu’un nombre limité de fois par jour. Entre deux interrogations, l’affichage est une photographie, pas un flux.
- Le consentement expire. Il est révocable à tout instant, et la réglementation impose une réauthentification périodique : une connexion accordée une fois n’est pas une autorisation permanente.
- Agréger n’est pas détenir. Un agrégateur pur ne détient pas vos fonds et n’est pas habilité à exécuter des paiements. En cas d’opération contestée, l’interlocuteur reste l’établissement teneur de votre compte : demandez-lui la marche à suivre plutôt que de vous fier à un support applicatif.
Sécurité, consentement et confiance : les chiffres qui tiennent #
Deux garde-fous sont écrits noir sur blanc dans les normes techniques de la DSP2. Ils constituent le meilleur démenti aux promesses de « connexion permanente en temps réel ».
L’authentification forte repose sur au moins deux facteurs parmi trois : un élément de connaissance, un élément de possession et un élément d’inhérence. C’est ce dispositif, et non une promesse de sécurité absolue, qui protège l’accès. S’y ajoute la conformité au RGPD sur les données collectées : traçabilité des accès et exactitude du consentement sont devenues des marqueurs de sérieux autant que la qualité de l’interface.
- L’open banking est un droit d’accès encadré, pas une ouverture générale : DSP2 en vigueur, révision en cours — vérifiez le statut du texte à la source avant d’en tirer un calendrier.
- Deux statuts, deux périmètres : information sur les comptes et initiation de paiement, tous deux sous agrément de l’ACPR ou d’une autorité européenne équivalente.
- Avant de connecter une application, vérifiez son agrément dans REGAFI. C’est un contrôle de trente secondes.
- Votre consentement est révocable et se réauthentifie ; l’accès est plafonné et n’a rien d’un flux continu.
- Méfiez-vous des pourcentages d’économies sans étude citée : mesurez sur votre propre périmètre.
Questions fréquentes #
Une API bancaire donne-t-elle accès à tous mes comptes ?
Dois-je communiquer mes identifiants bancaires à l’application ?
Les données affichées sont-elles à jour en permanence ?
Puis-je retirer mon autorisation ?
Que se passe-t-il en cas d’opération contestée ?
Que deviendra la DSP2 ?
- EUR-Lex : directive (UE) 2015/2366 ; règlements délégués (UE) 2018/389 et (UE) 2022/2360.
- Autorité bancaire européenne ; ABE Infoservice (Banque de France, ACPR, AMF) ; REGAFI ; Open Banking Limited.
