En bref — les faits clés en un coup d'œil
L'open banking transforme un compte bancaire en quelque chose auquel votre logiciel peut se connecter via une API — avec le consentement du client et sans jamais toucher à son mot de passe bancaire. La partie difficile est rarement le premier appel d'API ; c'est le consentement, la réconciliation et le maintien de la conformité à mesure que les règles évoluent. Voici ce que les responsables de la fintech doivent savoir d'emblée :
- Deux capacités : AIS (lire les données du compte — soldes, transactions) et PIS (initier un paiement depuis le compte). La plupart des produits commencent par l'AIS ; les paiements relèvent le niveau de conformité.
- Les règles évoluent. Dans l'UE, la PSD3 et le PSR ont fait l'objet d'un accord politique en novembre 2025 avec des textes finaux publiés en avril 2026 ; aux États-Unis, la Section 1033 est contestée et le marché s'appuie sur le standard FDX.
- L'agrégateur d'abord. Plaid, MX, Finicity, TrueLayer ou Tink couvrent des milliers de banques via une seule API et sont en service en 1–2 semaines ; les connexions bancaires directes prennent 4–8 semaines chacune.
- L'authentification, c'est OAuth + SCA. Redirection vers la banque, authentification à deux facteurs, consentement explicite et délimité, puis jetons d'accès et de rafraîchissement. Vous ne stockez jamais d'identifiants.
- Coût : agrégation en lecture seule 25 000–60 000 $ ; production avec paiements et réconciliation 60 000–150 000 $ ; une plateforme réglementée 150 000–400 000 $+.
- L'accès aux États-Unis se monétise. En 2025, de grandes banques ont commencé à facturer aux agrégateurs l'accès aux API — concevez pour le coût par appel et le repli de fournisseur.
Ce qu'est réellement l'open banking
L'open banking est le partage réglementé et fondé sur le consentement des données bancaires et de l'initiation de paiement via des API sécurisées. Une fois le jargon écarté, il n'y a que deux choses que vous pouvez faire, toujours avec l'autorisation explicite du client :
- Services d'information sur les comptes (AIS) — lire les données : détails du compte, soldes et historique des transactions. Cela alimente les applications de finances personnelles, le scoring de crédit et de solvabilité, l'automatisation comptable et la vérification des revenus.
- Services d'initiation de paiement (PIS) — initier un paiement directement depuis le compte bancaire de l'utilisateur, en contournant les rails des cartes. Cela alimente le paiement de compte à compte, le règlement de factures et les versements.
Les acteurs portent des noms qu'il vaut la peine de connaître car chaque API et chaque contrat les utilisent. L'ASPSP (prestataire de services de paiement gestionnaire du compte) est la banque qui détient le compte et expose l'API. Un AISP est un prestataire agréé de services d'information sur les comptes ; un PISP est un prestataire agréé de services d'initiation de paiement. Soit vous détenez vous-même l'une de ces licences, soit, bien plus couramment, vous intégrez via un agrégateur qui les détient pour vous. La discipline pour bien faire cela est exactement ce sur quoi nos services de développement de logiciels fintech sont bâtis, et elle se situe à côté du travail sur les paiements dans notre guide d'intégration de passerelle de paiement.
La carte réglementaire : PSD2, PSD3/PSR, Section 1033, FDX
L'open banking se présente différemment de chaque côté de l'Atlantique, et bien situer la géographie est la première décision de cadrage.
Europe : la PSD2 aujourd'hui, la PSD3/PSR ensuite
La PSD2 est la directive de l'UE en vigueur depuis 2018. Elle a obligé chaque banque de l'EEE à exposer des API sécurisées afin que les tiers agréés puissent — avec consentement — lire les données du compte et initier des paiements, et elle a introduit l'authentification forte du client (SCA). C'est la raison pour laquelle la couverture de l'open banking européen est large et standardisée (la spécification Berlin Group plus les schémas nationaux).
La PSD3 et le règlement sur les services de paiement (PSR) qui l'accompagne sont la génération suivante. Ils ont fait l'objet d'un accord politique en novembre 2025, avec des textes de compromis finaux publiés en avril 2026 ; le vote final et la publication au Journal officiel sont attendus au second semestre 2026, et la plupart des règles devraient s'appliquer environ 21 mois plus tard — vers 2028. La PSD3/PSR conserve le modèle mais renforce la qualité et la disponibilité des API, consolide la protection contre la fraude et la SCA, et standardise l'accès afin que les tiers obtiennent des connexions plus fiables. Le conseil pratique pour un projet 2026 : implémentez selon la PSD2 maintenant, et concevez votre couche de consentement et d'API pour que les exigences plus strictes de la PSD3/PSR soient un changement de configuration, pas une refonte.
États-Unis : la Section 1033 contestée, le FDX en pratique
Les États-Unis ont développé l'open banking par le marché d'abord. Les agrégateurs — Plaid, MX, Finicity, Akoya, Yodlee — ont construit la connectivité, et le standard FDX (Financial Data Exchange) fait converger le format des données. Le CFPB a publié une règle sur les droits aux données financières personnelles (Section 1033) en octobre 2024, mais sa mise en œuvre a connu des turbulences juridiques et réglementaires, vous ne pouvez donc pas la considérer comme acquise. Pendant ce temps, le terrain commercial évolue : en 2025, de grandes banques comme JPMorgan Chase ont commencé à facturer aux agrégateurs l'extraction des données de compte des clients via leurs API. La posture réaliste aux États-Unis en 2026 est hybride — un accès réglementé de type FDX s'étend parallèlement à des accords payants avec les agrégateurs.
Agrégateur vs intégration bancaire directe
Il y a deux façons d'atteindre les API bancaires, et ce choix détermine l'essentiel de votre calendrier et de votre coût.
Via un agrégateur
Un agrégateur vous donne une API unifiée qui se déploie vers des milliers de banques, gère les particularités de chaque banque, et détient généralement les licences AISP/PISP pour que vous n'ayez pas à le faire. Une connexion de données de compte en lecture seule peut être en service en environ une à deux semaines. Les différences entre fournisseurs sont réelles :
- Plaid — une plateforme de connectivité avec la plus large couverture en fintech grand public et l'expérience de connexion la plus fluide.
- MX — une société de données solide sur le nettoyage et l'enrichissement des données ainsi que sur la connectivité.
- Finicity (Mastercard) — une infrastructure de vérification qui brille pour la vérification des revenus et des actifs dans les flux de crédit et de prêt hypothécaire.
- TrueLayer / Tink (Visa) — une forte couverture PSD2 européenne et l'initiation de paiement.
Choisissez selon votre cas d'usage dominant : agrégation grand public, vérification de crédit, ou paiements A2A. Beaucoup d'équipes adoptent un agrégateur et en ajoutent un second plus tard pour le repli et la couverture.
En direct avec la banque
Une intégration directe se connecte à l'API propre d'un ASPSP individuel. Chacune prend généralement quatre à huit semaines en raison de la certification et de l'onboarding, elle n'est donc rentable que lorsque vous avez besoin d'une banque spécifique que l'agrégateur couvre mal, voulez un coût par appel inférieur à fort volume, ou avez un partenariat qui le justifie. Le schéma honnête est hybride : un agrégateur pour la couverture large, une poignée de connexions directes pour les banques qui portent votre volume. C'est du développement de logiciels sur mesure ordinaire — quoique exigeant —, et à l'échelle cela devient le genre de parc d'intégration d'API qui nécessite une réelle appropriation.
Le flux d'intégration : OAuth, SCA et consentement
Quelle que soit la voie que vous empruntez, le flux d'authentification et de consentement a la même forme, et c'est la partie que les équipes sous-estiment le plus souvent.
- Initier & rediriger. Votre application lance une demande d'autorisation et redirige l'utilisateur vers sa banque (ou l'interface de connexion de l'agrégateur, qui en assure l'intermédiation).
- Authentification forte du client. La banque authentifie l'utilisateur avec deux facteurs — par exemple un mot de passe plus la biométrie ou un code à usage unique. Vous ne voyez jamais ces identifiants.
- Consentement explicite et délimité. L'utilisateur approuve exactement ce que vous avez demandé : quels comptes, quelles données, pour combien de temps, ou le montant et le bénéficiaire d'un paiement précis.
- Échange de jetons. La banque renvoie un code d'autorisation que votre backend échange contre des jetons d'accès et de rafraîchissement via le flux de code d'autorisation OAuth.
- Utiliser & renouveler. Vous appelez les points de terminaison de données ou de paiement avec le jeton d'accès, le rafraîchissez au besoin, et — surtout — suivez le moment où le consentement expire et doit être renouvelé ou ré-authentifié.
Le détail qui coule les projets naïfs est le cycle de vie du consentement. Sous la PSD2, le consentement d'accès aux comptes est limité dans le temps et nécessite généralement un renouvellement périodique ; la PSD3/PSR devrait standardiser les tableaux de bord de consentement et la ré-authentification. Vous devez stocker l'état du consentement, demander le renouvellement avant qu'il n'expire, gérer proprement la révocation, et ne jamais continuer silencieusement à utiliser un jeton que l'utilisateur a révoqué. Ratez cela et les connexions se rompent « mystérieusement » ou, pire, vous continuez à extraire des données sans consentement valide.
Architecture et pile
Il n'existe pas de « pile open banking » unique, mais les intégrations en production convergent vers une forme reconnaissable bâtie autour d'un modèle interne propre, d'une gestion attentive des jetons et d'une auditabilité stricte.
Un modèle de compte canonique
Normalisez tout — chaque agrégateur et chaque banque — en un seul modèle interne que possède votre application : comptes, soldes, transactions, consentements, paiements. Cela vous découple du schéma d'un fournisseur unique et fait de l'ajout du prochain agrégateur ou de la prochaine banque une tâche de mappage plutôt qu'une réécriture. PostgreSQL est un système d'enregistrement courant ; les charges utiles brutes des fournisseurs se stockent proprement en JSONB pour la relecture et l'audit, tandis que les entités canoniques restent fortement typées. La même discipline architecturale sous-tend notre développement de néobanque et nos projets fintech plus larges.
Service de jetons et de consentement
Traitez les jetons et les consentements comme un sous-système de premier ordre, pas comme une colonne sur une ligne d'utilisateur. Chiffrez les jetons au repos, délimitez étroitement l'accès, faites tourner les clés, et exécutez un planificateur qui renouvelle ou expire les consentements à temps. Chaque accès doit être attribuable à un consentement spécifique et actuellement valide.
Ingestion et réconciliation pilotées par événements
Les données bancaires arrivent par à-coups et les webhooks se déclenchent de façon asynchrone, donc un pipeline piloté par événements — une file ou un flux — découple les flux des fournisseurs de votre application et rend les réessais et la relecture gérables. Pour l'initiation de paiement, la réconciliation n'est pas négociable : chaque paiement initié doit être suivi jusqu'à un statut final et rapproché de votre grand livre. C'est du travail backend et cloud ; notre service Cloud & DevOps couvre la façon dont nous construisons ces pipelines, et le volet identité recoupe notre guide sur les logiciels KYC et AML.
Combien coûte une intégration open banking en 2026
Des chiffres précis, avec la mise en garde habituelle que l'initiation de paiement, le nombre de connexions bancaires directes, et la profondeur du travail de consentement et de réconciliation déplacent significativement les montants. Ces fourchettes reflètent des projets d'intégration complets par une équipe expérimentée — pas une démo qui relie un seul compte de test.
| Périmètre | Coût typique | Délai |
|---|---|---|
| Agrégation en lecture seule via un agrégateur, gestion du consentement, 1–2 cas d'usage | 25 000–60 000 $ | 4–8 semaines |
| Production : initiation de paiement, réconciliation, repli multi-agrégateurs, modèle canonique | 60 000–150 000 $ | 3–5 mois |
| Plateforme réglementée : posture AISP/PISP, connexions bancaires directes, gestion du consentement, supervision | 150 000–400 000 $+ | 6–10 mois |
| Chaque connexion bancaire directe (ASPSP) supplémentaire | +15 000–40 000 $ | +4–8 semaines |
Ce sont des engagements mixtes qui incluent le consentement, la réconciliation, la supervision et l'assurance qualité — pas seulement la récupération visible. Pour le fonctionnement plus général du coût d'un projet sur mesure, consultez notre guide sur le développement d'applications fintech, qui couvre les décisions de conformité et de pile qui l'entourent.
Où va réellement l'argent
- Cycle de vie du consentement & des jetons (25–35 %) : capture, renouvellement, révocation, ré-authentification, stockage chiffré — la partie qui maintient les connexions vivantes et conformes.
- Intégration des fournisseurs (15–25 %) : configuration de l'agrégateur, éventuelles connexions bancaires directes, et l'interface de connexion/consentement.
- Réconciliation & opérations (20–30 %) : suivi du statut des paiements, gestion des exceptions, alertes et la supervision qui rend le flux fiable.
- Modèle de données & intégration (20–30 %) : le modèle canonique de compte/transaction et l'acheminement des données dans le reste de votre produit.
Sécurité, conformité et qualité des données
L'open banking déplace certaines des données les plus sensibles qui soient, donc la sécurité et la conformité sont un socle, pas des extras.
- Ne stockez jamais les identifiants bancaires. Tout l'intérêt réside dans les jetons OAuth, pas les mots de passe. Chiffrez les jetons au repos, délimitez-les étroitement, et faites tourner les clés.
- La SCA et le consentement sont obligatoires, pas une UX facultative. L'authentification forte du client et un consentement explicite, délimité et limité dans le temps sont exigés — intégrez la capture, le renouvellement et la révocation du consentement dès le premier jour.
- PCI DSS et SOC 2 lorsque des paiements sont impliqués. L'initiation de paiement et tout flux adjacent aux cartes vous font entrer dans le périmètre PCI ; une couche KYC/AML est généralement requise pour les cas d'usage réglementés, et le SOC 2 Type II est un prérequis pour vendre aux banques.
- La qualité des données est une fonctionnalité. Les données de transaction bancaires sont désordonnées — noms de commerçants incohérents, en attente vs comptabilisé, doublons. L'enrichissement et la déduplication sont ce qui rend les données utilisables ; sous-investir ici est la cause discrète de la plupart des plaintes « les chiffres ont l'air faux ».
- Auditez tout. Stockez les charges utiles brutes et un historique complet du consentement et des accès. Les régulateurs, les partenaires et vos propres litiges en auront besoin.
Rien de tout cela n'est exotique, mais rétro-adapter la gestion du consentement ou une piste d'audit dans une intégration déjà lancée coûte bien plus cher que de la concevoir d'emblée.
Comment choisir un partenaire d'intégration
La compétence logicielle générale est nécessaire mais pas suffisante pour l'open banking. Cette liste de contrôle distingue les partenaires capables de livrer une intégration en production et conforme de ceux qui apprendront la PSD2 sur votre budget.
1. Une réelle expérience de l'open banking et des agrégateurs
Demandez spécifiquement quels agrégateurs ils ont intégrés (Plaid, MX, Finicity, TrueLayer, Tink), s'ils ont livré l'initiation de paiement en plus de l'accès aux données, et comment ils ont géré le cycle de vie du consentement. Une équipe qui a renouvelé et révoqué des consentements en production vous fera gagner des mois.
2. Un état d'esprit de modèle canonique
Méfiez-vous de quiconque câble votre application directement au schéma d'un seul agrégateur. Cela fonctionne jusqu'à ce que vous ajoutiez un second fournisseur ou une banque directe, puis s'effondre. Cherchez un partenaire qui conçoit d'abord le modèle de compte interne et traite chaque fournisseur comme un mappage sur celui-ci.
3. Sécurité et conformité par défaut
Le stockage chiffré des jetons, des flux conformes à la SCA, la conscience PCI, les pratiques SOC 2 et une vraie piste d'audit devraient figurer dans la conception dès le premier jour, pas être greffés avant une revue de sécurité d'entreprise.
4. Adéquation du modèle d'engagement
Les parcs open banking durent longtemps et grandissent avec chaque nouveau fournisseur, banque et changement réglementaire. Une équipe de développement dédiée qui possède l'intégration dans la durée l'emporte généralement sur un transfert ponctuel pour tout ce qui dépasse un pilote restreint.
5. Discipline de cadrage
Insistez sur un cadrage payant qui délimite les cas d'usage (données vs paiements), les fournisseurs, le modèle de consentement et la posture de conformité avant tout engagement à prix fixe. Un partenaire qui chiffre à prix fixe une plateforme open banking réglementée après un seul appel sous-évalue le risque — notre guide sur comment choisir une société de développement logiciel couvre l'ensemble du processus de sélection.
FAQ
Qu'est-ce que l'open banking ?
L'open banking est le partage réglementé et fondé sur le consentement des données bancaires et de l'initiation de paiement via des API sécurisées. Avec l'autorisation explicite du client, un tiers agréé peut lire les données du compte (services d'information sur les comptes, AIS) ou initier un paiement depuis le compte (services d'initiation de paiement, PIS) — sans screen-scraping ni stockage des identifiants bancaires. Un compte bancaire devient quelque chose auquel votre logiciel peut se connecter via une API.
Quelle est la différence entre la PSD2 et la PSD3 ?
La PSD2 est la directive de l'UE en vigueur depuis 2018 qui exigeait des banques d'exposer des API sécurisées et imposait une authentification forte du client. La PSD3, avec le règlement sur les services de paiement (PSR), est la génération suivante — accord politique en novembre 2025, textes finaux publiés en avril 2026, application attendue vers 2028. Elle conserve l'open banking mais renforce la qualité des API, la protection contre la fraude et la SCA. Construisez selon la PSD2 aujourd'hui et concevez pour les exigences plus strictes de la PSD3/PSR.
L'open banking est-il identique aux États-Unis et dans l'UE ?
Non. L'UE est pilotée par la réglementation : la PSD2 force les banques à publier des API, donc la couverture est large et standardisée. Les États-Unis ont été pilotés par le marché via les agrégateurs (Plaid, MX, Finicity, Akoya, Yodlee) et le standard FDX ; la règle Section 1033 du CFPB d'octobre 2024 est contestée, et en 2025 certaines banques ont commencé à facturer aux agrégateurs l'accès. La posture pratique aux États-Unis en 2026 est hybride.
Dois-je utiliser un agrégateur comme Plaid ou me connecter directement aux banques ?
Pour la plupart des produits, commencez par un agrégateur : une seule API couvre des milliers de banques et est en service en 1–2 semaines. Les intégrations bancaires directes prennent 4–8 semaines chacune et ne sont rentables que pour des banques spécifiques, un coût par appel inférieur à fort volume, ou des partenariats particuliers. Beaucoup d'équipes optent pour une approche hybride.
Comment fonctionne l'authentification open banking ?
Elle utilise OAuth 2.0 avec le flux de code d'autorisation plus l'authentification forte du client. Votre application redirige l'utilisateur vers sa banque, la banque l'authentifie avec deux facteurs, l'utilisateur accorde un consentement délimité, et la banque renvoie un code que vous échangez contre des jetons d'accès et de rafraîchissement. Vous ne stockez jamais les identifiants bancaires de l'utilisateur, et le consentement est explicite et limité dans le temps.
Combien de temps et combien coûte une intégration open banking en 2026 ?
Une intégration d'agrégation en lecture seule coûte généralement 25 000–60 000 $ sur 4–8 semaines ; un projet en production avec initiation de paiement et réconciliation 60 000–150 000 $ sur 3–5 mois ; une plateforme réglementée 150 000–400 000 $+. Les principaux facteurs sont les paiements par rapport à la lecture seule, le nombre de connexions bancaires directes, et la profondeur du travail de consentement et de conformité.
Dernière mise à jour le 27 juin 2026. Les fourchettes de coût et de délai reflètent des projets d'intégration complets pour des clients fintech américains et européens et varieront selon le périmètre, les cas d'usage, les fournisseurs et la profondeur opérationnelle. Les références réglementaires (PSD2, PSD3/PSR, Section 1033, FDX) sont des indications générales, pas un avis juridique — consultez un conseil qualifié et vos fournisseurs pour les exigences en vigueur. Demandez une proposition cadrée pour votre produit spécifique.
