Intégration API Open banking
Nous développons votre connecteur Open banking
Nous passons par un agrégateur DSP2 pour ouvrir à votre application les comptes bancaires de vos utilisateurs : soldes, transactions, IBAN, avec un consentement qui se renouvelle au lieu de tomber.
- Équipe produit senior
- intégrations bancaires en production
- du cadrage au monitoring
Qu'est-ce que l'open banking et à quoi sert une intégration de données bancaires ?
L'open banking permet à votre application d'accéder aux données des comptes bancaires de vos utilisateurs, avec leur consentement, grâce à des APIs standardisées par la réglementation européenne DSP2. En pratique, on passe par un agrégateur bancaire : comme Bridge ou Powens, qui couvre plusieurs centaines de banques françaises et européennes avec une seule intégration. Résultat concret : vos clients n'envoient plus de relevés PDF, leurs transactions arrivent structurées et catégorisées dans votre outil. C'est la base de nombreux services financiers : scoring crédit, gestion de trésorerie, comptabilité automatisée.
Ce que nos clients construisent sur l'agrégation bancaire
Pilotage de trésorerie multi-banques
Soldes consolidés, flux catégorisés et prévisionnel, pour un client qui a trois banques différentes. Une seule intégration au lieu de trois connecteurs propriétaires.
Vérification à l'inscription
Titulaire du compte, IBAN et revenus récurrents lus à la source. Plus de relevé PDF à demander, à relire, et éventuellement à falsifier.
Relance qui s'arrête toute seule
L'encaissement détecté côté banque met fin à la séquence de relance et met à jour l'échéancier. Vous ne relancez plus un client qui a déjà payé.
Encaissement par virement initié
Un lien de paiement par virement pour les factures B2B à montant élevé, là où la commission carte devient difficile à justifier.
Ce que ça change dans votre produit
La technique au service d'un résultat mesurable : une donnée bancaire fiable, des décisions en minutes, des connexions qui tiennent.
Une décision en minutes, pas en jours
Les premiers jours d'historique sont disponibles dès la fin du parcours de connexion. L'instruction d'un dossier ne dépend plus d'un envoi de pièces.
Une pièce justificative qui ne se falsifie pas
La donnée vient de la banque, pas d'un fichier reçu par email. Le contrôle porte sur des flux réels et sur la période que vous avez définie.
Des connexions qui ne se vident pas
Le consentement expire à date fixe. Nous le renouvelons avant l'échéance plutôt que de découvrir la coupure quand l'utilisateur revient.
Un agrégateur que vous pouvez changer
Le fournisseur est isolé derrière une interface interne. Changer d'agrégateur pour une question de couverture ou de tarif ne réécrit pas votre produit.
Comment nous livrons votre connecteur bancaire
Cadrage
Quel agrégateur selon la couverture bancaire réelle de vos utilisateurs, quelles données, quelle durée de conservation. On tranche avant d'écrire une ligne de code.
Développement
Parcours de connexion hébergé, récupération strictement incrémentale, renouvellement des jetons courts, vérification de signature sur les webhooks.
Statuts et parcours
Chaque statut de connexion reçoit son message et son action : identifiants à corriger, action à faire dans la banque en ligne, code à saisir, migration en cours.
Monitoring
Relance avant expiration du consentement, alertes sur connexion en échec, tableau de bord de santé. Vous savez qu'un flux est cassé avant vos utilisateurs.
Ce que permet une API d'agrégation
- Connexions bancaires
- Création de l'utilisateur, parcours de connexion hébergé, puis suivi de l'état de chaque connexion et de sa date d'expiration de consentement.
- Comptes, soldes et IBAN
- Comptes rattachés à une connexion, avec solde, IBAN et données d'identité du titulaire. La base d'une vérification ou d'un tableau de trésorerie.
- Transactions catégorisées
- Historique par compte, catégorisé par l'agrégateur, avec une récupération incrémentale fondée sur la date de dernière modification.
- Initiation de paiement
- Chez les agrégateurs qui la proposent, liens et demandes de paiement par virement, avec leurs statuts et leurs événements de webhook.
Le vocabulaire de l'open banking
- AISP et PISP
- Les deux statuts réglementaires de l'accès aux comptes : consultation d'un côté, initiation de paiement de l'autre. Dans la quasi-totalité des projets, c'est l'agrégateur qui les porte, ni vous ni nous.
- Item
- Une connexion entre un utilisateur et une banque, distincte du compte. Elle porte un statut qui évolue dans le temps et qui doit être exposé dans votre interface.
- authentication_expires_at
- La date à laquelle l'authentification forte du client expire pour cette connexion. Le champ existe justement pour être surveillé et anticipé, pas pour être découvert après coup.
- Connect session
- Le parcours de connexion hébergé par l'agrégateur, où l'utilisateur s'authentifie auprès de sa banque. Le même parcours sert au renouvellement, avec réauthentification forcée.
- Récupération incrémentale
- On mémorise la date de dernière modification des transactions déjà lues et on la repasse en paramètre. C'est ce qui permet de tenir dans les quotas au lieu de tout relire.
- Consentement DSP2 et RGPD
- Deux notions distinctes qui se traitent séparément : l'une autorise l'accès aux comptes, l'autre encadre le traitement de données personnelles. Les données bancaires relèvent des deux.
Les contraintes réelles de l'agrégation bancaire
Le consentement expire au bout de 180 jours
L'authentification forte reste valable 180 jours après la connexion initiale, c'est réglementaire et non contournable. Sans relance avant l'échéance, votre base de connexions se vide toute seule en six mois.
Un statut de connexion n'est pas une erreur
Identifiants à mettre à jour, action à faire dans la banque en ligne, code à usage unique attendu, migration bancaire en cours : chaque cas appelle un message et une action différents. Un message unique fait échouer le produit.
La profondeur d'historique dépend de la banque
Elle va de zéro à trente-six mois selon l'établissement, une connexion peut être partielle avec des comptes temporairement indisponibles, et le rafraîchissement reste périodique. Ce n'est pas du temps réel.
Un webhook non reçu peut être perdu
Les retentatives s'étalent sur un à deux jours, et certains fournisseurs abandonnent après une poignée d'échecs consécutifs. Il faut une file durable et un balayage de rattrapage planifié.
Agrégation DSP2 ou API bancaire directe ?
Deux chemins pour lire des comptes depuis votre application. Le bon dépend de qui détient les comptes, pas de la technique.
| Critère | Agrégation DSP2Bridge, Powens, Tink | API bancaire directeQonto, Revolut Business |
|---|---|---|
| Banques couvertes | La plupart des banques françaises | Le seul établissement concerné |
| Mise en place côté utilisateur | Parcours de connexion et consentement | Clé API ou autorisation déclarée une fois |
| Richesse des données | Libellé, montant, date, catégorisation | Étiquettes, catégories natives, justificatifs |
| Fraîcheur | Rafraîchissement périodique | Webhooks à l'événement |
| Durée de l'accès | Consentement à renouveler tous les 180 jours | Jeton renouvelé côté serveur |
| Statut réglementaire | Porté par l'agrégateur | Sans objet, ce sont vos propres comptes |
| Le bon cas | Vos utilisateurs sont dans des banques différentes | Tous les comptes sont dans le même établissement |
Les deux se combinent souvent : l'API de votre banque pour vos propres comptes, l'agrégation pour ceux de vos clients. C'est un arbitrage de cadrage, pas un choix définitif.
Ce que nous mesurons sur une intégration bancaire
Les autres API bancaires
Si tous les comptes concernés sont dans le même établissement, l'accès direct se discute au cadrage.
QontoAccès direct et riche à vos propres comptes, avec virements sortants.
Revolut BusinessComptes multidevises et paiements internationaux, en accès direct.On combine l'open banking avec
La stack qui entoure l'agrégation bancaire sur nos projets.
Intégration open banking : vos questions
En passant par un agrégateur, pas par chaque banque. Le parcours est toujours le même : on crée l'utilisateur chez l'agrégateur avec votre identifiant en correspondance, on ouvre un parcours de connexion hébergé où il s'authentifie auprès de sa banque, puis on lit les comptes et les transactions rattachés à cette connexion. La récupération se fait ensuite de façon strictement incrémentale, déclenchée par les webhooks de rafraîchissement, en mémorisant la date de dernière modification déjà traitée. Relire tout l'historique à chaque passage sature les quotas en quelques minutes.
Dans la très grande majorité des projets, non : c'est l'agrégateur qui porte le statut réglementaire d'accès aux comptes, ni votre entreprise ni votre prestataire de développement. C'est d'ailleurs l'une des raisons d'utiliser un agrégateur plutôt que de contracter avec chaque banque. Ce qui reste à votre charge est le traitement des données personnelles : minimisation, hébergement en Union européenne, durée de conservation définie, purge effective, et un chemin de suppression qui coupe aussi la connexion chez l'agrégateur. Le consentement au sens bancaire et le consentement au sens RGPD sont deux sujets distincts.
Leur promesse est proche, leurs détails d'implémentation ne le sont pas. Les modèles de données diffèrent, les mécanismes d'authentification des webhooks aussi, et la politique d'abandon en cas d'endpoint indisponible varie fortement d'un fournisseur à l'autre : chez certains, quelques échecs consécutifs suffisent à perdre définitivement des événements. Le choix se fait sur trois critères concrets, dans cet ordre : la couverture réelle des banques de vos utilisateurs, le périmètre fonctionnel dont vous avez besoin, puis le tarif. Nous isolons le fournisseur derrière une interface interne pour que ce choix reste réversible.
Un premier flux utile, typiquement la lecture des comptes et des transactions après un parcours de connexion, se livre en trois à quatre semaines. Une chaîne complète demande plutôt six à huit semaines, et le temps supplémentaire ne va pas dans les appels API : il va dans la table des statuts de connexion, le renouvellement du consentement, la reprise sur erreur et la purge des données. C'est exactement ce qui sépare un prototype qui fonctionne en démonstration d'un produit qui tient six mois après la mise en ligne.
Parce que l'authentification forte du client expire 180 jours après la connexion initiale. C'est une règle européenne, pas un défaut de l'agrégateur, et aucune implémentation ne peut la contourner. La seule réponse est un renouvellement anticipé : un traitement quotidien lit la date d'expiration de chaque connexion, prévient l'utilisateur plusieurs jours avant l'échéance et lui propose une reconnexion en un clic. C'est la différence entre une base de connexions qui se maintient et une base qui se vide toute seule en six mois. Les autres causes fréquentes sont un changement d'identifiants et une action à effectuer dans la banque en ligne.
Un projet d'agrégation bancaire ?
Parlons-en. 30 minutes pour cadrer votre besoin, vérifier la couverture bancaire réelle de vos utilisateurs et vous dire franchement ce qui est faisable.
Parler de mon projet bancaire