- Une interface d’accès au moins, permettant aux prestataires tiers de s’identifier et de dialoguer de façon sécurisée (art. 30 §1).
- Un dispositif d’essai avec assistance, ouvert aux prestataires agréés ou en cours d’agrément, sans données sensibles (art. 30 §5).
- Pour une interface dédiée : le même niveau de disponibilité et de performances, assistance comprise, que le canal utilisé par les clients de la banque (art. 32 §1).
- Des statistiques trimestrielles de disponibilité et de performance, publiées sur le site de l’établissement (art. 32 §4).
- Un plan de secours écrit, activable quand l’interface ne répond plus (art. 33).
Plan de l'article
- Le point de départ : un cœur bancaire qu’on ne réécrit pas
- Exposer une API n’est pas ouvrir sa base
- Le cahier des charges que l’établissement doit tenir
- Quand l’interface tombe : le plan de secours
- La gouvernance : qui possède l’interface, qui répond au client
- Ce que ce chantier coûte, et pourquoi vous ne trouverez pas de chiffre ici
- Ce que l’APIfication ne règle pas
- Questions fréquentes
Le point de départ : un cœur bancaire qu’on ne réécrit pas #
Les systèmes bancaires historiques n’ont pas été conçus pour être appelés de l’extérieur. Tenue de compte, référentiel client, contrôle d’identité et traitement des paiements y ont grandi ensemble sur plusieurs décennies, avec une conséquence pratique : toucher à une fonction revient à mettre en risque les autres. C’est ce qui explique la lenteur reprochée au secteur, bien plus que l’ancienneté du matériel.
Le passage aux architectures modulaires renverse la charge. Chaque grande fonction est isolée dans un composant qui expose un contrat d’appel stable, et le reste du système ne connaît plus que ce contrat. L’intérêt n’est pas la modernité : c’est de pouvoir remplacer une brique sans rouvrir le cœur. Si le vocabulaire vous manque, nous avons publié ailleurs une explication sans jargon de ce qu’est une API bancaire et de ce qu’elle permet ; la suite de cet article suppose ces bases acquises et regarde le chantier depuis l’intérieur de l’établissement.
Exposer une API n’est pas ouvrir sa base #
La confusion la plus tenace consiste à croire qu’une banque « ouvre ses données ». Elle n’ouvre rien de tel : elle met en place une façade qui expose un périmètre déterminé, à des acteurs identifiés, pour des opérations précises — permettre à un prestataire de s’identifier, lui transmettre les informations d’un ou plusieurs comptes désignés, ou lui laisser initier un ordre de paiement et en recevoir les informations d’exécution. Tout ce qui n’entre pas dans ce périmètre reste derrière la façade.
Cette distinction n’est pas cosmétique : elle détermine qui peut appeler, sous quel statut, et pour quoi faire. Ce volet-là — les statuts réglementés, l’agrément et la manière de vérifier qu’un prestataire est bien autorisé — fait l’objet d’un article dédié : ce que la DSP2 autorise réellement, statut par statut, et où contrôler l’agrément d’un prestataire. Nous ne le reprenons pas ici, où la question est différente : qu’est-ce que cela oblige la banque à construire, à documenter et à tenir dans la durée ?
Le cahier des charges que l’établissement doit tenir #
C’est le point que les présentations enthousiastes escamotent le plus souvent. Une API bancaire n’est pas livrée le jour où elle répond : elle l’est le jour où elle satisfait un ensemble d’obligations vérifiables, dont voici les principales, telles qu’elles figurent dans la norme technique européenne.
Une documentation publique
Un préavis sur les évolutions
Un environnement d’essai
Une parité de service
Des indicateurs opposables
Des statistiques publiées
Le dernier point change la nature de la discussion : la qualité d’une API bancaire n’est pas un argument commercial invérifiable, elle est censée être publiée trimestre après trimestre par l’établissement lui-même. Avant de choisir un partenaire d’intégration, c’est une lecture plus instructive que n’importe quelle plaquette.
Quand l’interface tombe : le plan de secours #
Un système qui ne prévoit pas sa propre panne n’est pas un système de production. La norme l’admet explicitement et fixe même un seuil de présomption : une indisponibilité imprévue ou une panne peut être présumée lorsque cinq demandes consécutives n’obtiennent pas de réponse dans les trente secondes. La banque doit avoir prévu, dès la conception, une stratégie et des plans de mesures d’urgence.
- Un plan de communication informant les prestataires des mesures de rétablissement et des options immédiatement disponibles pendant l’incident.
- Une notification sans délai aux autorités nationales compétentes, par la banque comme par les prestataires concernés.
- Un mécanisme de secours autorisant les prestataires à repasser par les interfaces destinées aux clients, le temps que l’interface dédiée retrouve son niveau de service.
Autrement dit, la continuité ne repose pas sur une promesse de fiabilité mais sur un dispositif écrit, opposable et connu à l’avance des deux côtés. C’est très exactement l’inverse de la formule que l’on lit partout, selon laquelle une surveillance permanente « garantirait » une réaction immédiate. Rien ne garantit qu’un système ne tombe pas ; ce qui est encadré, c’est ce qui se passe ensuite.
La gouvernance : qui possède l’interface, qui répond au client #
Un chantier d’APIfication échoue rarement pour des raisons techniques : il échoue parce que personne n’est propriétaire du contrat d’interface. Une API exposée devient un engagement de long terme — versions, dépréciations, utilisateurs extérieurs à l’entreprise qui n’ont aucune raison de suivre le rythme des projets internes. Le préavis de trois mois évoqué plus haut n’est pas une contrainte administrative, c’est la formalisation de cette réalité.
Reste la question la plus concrète pour le client final, et celle qu’un article sur les API oublie presque toujours : lorsqu’une opération est contestée, l’interlocuteur demeure l’établissement qui tient le compte, même si l’ordre a transité par une application tierce. La chaîne s’allonge — éditeur visible, prestataire agréé, banque teneuse — mais elle ne se dilue pas. Une entreprise qui connecte son outil de gestion à ses comptes a intérêt à savoir, avant l’incident, à quelle porte elle frappera.
Ce que ce chantier coûte, et pourquoi vous ne trouverez pas de chiffre ici #
Les argumentaires du secteur circulent avec des pourcentages spectaculaires : tant de coûts opérationnels en moins, tant de temps gagné sur le traitement des factures. Ces chiffres sont presque toujours orphelins — ni étude identifiable, ni périmètre, ni méthode. Nous avons cherché les sources des ordres de grandeur qui figuraient dans la version précédente de cet article ; aucune n’a pu être retrouvée, et ils ont donc été retirés plutôt que recopiés.
Le gain est réel, et il se mesure honnêtement : sur votre propre périmètre, comptez le temps consacré au rapprochement bancaire et aux ressaisies, avant connexion puis après. Un chiffre construit sur trois mois de votre activité résiste à la seule question qui compte — « d’où sort-il ? »
Ce que l’APIfication ne règle pas #
Ouvrir une interface ne transforme pas un système d’information, et il serait malhonnête de laisser croire l’inverse. Trois limites méritent d’être posées avant d’engager un projet.
- La façade ne corrige pas ce qu’elle masque. Une donnée incohérente dans le référentiel le reste une fois exposée : l’interface la diffuse simplement plus vite et à plus de monde.
- Le périmètre légal ne couvre pas tous les avoirs. L’obligation d’ouverture porte sur les comptes de paiement accessibles en ligne, pas sur l’ensemble du patrimoine d’un client.
- Ce n’est pas un flux continu. Sans action de l’utilisateur, le nombre d’interrogations d’un compte par un agrégateur est plafonné sur vingt-quatre heures : ce que voit une application est une photographie datée, pas un direct.
- Exposer une API bancaire, c’est livrer un service régulé : documentation publique, environnement d’essai, préavis d’évolution, niveau de service et plan de panne.
- Une interface dédiée doit tenir la parité de disponibilité et de performances avec le canal des clients de la banque, assistance comprise.
- Les statistiques trimestrielles publiées par l’établissement sont le seul indicateur de qualité vérifiable : lisez-les avant de choisir un partenaire.
- La panne est prévue par la norme — cinq demandes sans réponse en trente secondes suffisent à la présumer — et déclenche un mécanisme de secours écrit.
- Méfiez-vous des pourcentages d’économies sans source : mesurez sur votre propre périmètre, avant et après connexion.
Questions fréquentes #
Une banque peut-elle se contenter d’ouvrir son site aux prestataires ?
Où voir la qualité réelle d’une API bancaire ?
Que se passe-t-il si l’interface tombe en pleine intégration ?
Un changement d’API peut-il casser une intégration du jour au lendemain ?
Qui est responsable en cas d’opération contestée ?
L’authentification est-elle assurée par le protocole d’autorisation utilisé ?
Cet article est informatif et ne remplace ni l’avis d’un professionnel, ni l’information officielle de votre établissement bancaire ou de votre prestataire.
