Chaque lundi matin, le même rituel : un trésorier exporte manuellement les relevés bancaires de cinq banques différentes, les charge dans l’ERP, passe deux heures à rapprocher les lignes non reconnues, et obtient enfin une position de trésorerie qui reflète… vendredi soir. C’est la réalité de nombreuses ETI françaises en 2026, alors même que la réglementation européenne PSD2 a rendu techniquement possible une synchronisation automatique quotidienne depuis 2018.
Ce guide explique comment connecter concrètement votre ERP à vos banques via les APIs Open Banking, quels agrégateurs choisir selon votre contexte, et ce que cela change sur votre quotidien opérationnel — sans confondre une obligation réglementaire avec un service supplémentaire que vos banques facturent en option.
PSD2 et Open Banking : ce que cela change concrètement pour votre ERP
La directive PSD2 expliquée en 3 minutes pour les DAF
La directive européenne PSD2 (Payment Services Directive 2), transposée en droit français en 2018 et dont les normes techniques réglementaires (RTS) sont entrées en vigueur en 2021, oblige les banques à ouvrir leurs données de comptes à des prestataires tiers agréés — à condition que le titulaire du compte ait donné son consentement. Ce principe s’appelle l’Open Banking.
Concrètement pour un DAF, cela signifie deux choses :
- Votre banque ne peut plus bloquer l’accès à vos propres données. Si vous autorisez un prestataire agréé (votre ERP, un agrégateur, un outil de trésorerie) à lire vos relevés bancaires, la banque est légalement obligée d’exposer cette donnée via une API standardisée. La facturation de ce service sous forme d’option bancaire payante est contraire au principe de la directive.
- L’agrément est clé. Les prestataires qui accèdent aux comptes bancaires en votre nom doivent être enregistrés comme AISP (Account Information Service Provider) ou PISP (Payment Initiation Service Provider) auprès d’un régulateur national — l’ACPR en France, la BaFin en Allemagne, etc. Ce n’est pas un label marketing, c’est une autorisation réglementaire vérifiable sur les registres publics.
PSD2 ne crée pas directement un droit pour votre ERP d’aller lire vos comptes bancaires — il crée un écosystème de prestataires agréés qui peuvent le faire à votre place. C’est là qu’interviennent les agrégateurs bancaires.
De la réconciliation manuelle hebdomadaire à la synchronisation automatique quotidienne
Avant PSD2, la connexion entre un ERP et une banque passait soit par un export manuel de fichiers (OFX, CAMT.053), soit par des protocoles lourds comme EBICS — pertinents pour les grands comptes avec des volumes de transactions importants, mais complexes à déployer pour une ETI avec deux ou trois banques partenaires.
Avec PSD2 et les agrégateurs, le processus change radicalement :
- Votre ETI mandate un agrégateur agréé AISP (Bridge, Powens, GoCardless, Tink, Salt Edge)
- L’agrégateur se connecte à vos banques via leurs APIs PSD2 avec votre consentement
- Les transactions de tous vos comptes arrivent dans votre ERP en format normalisé, plusieurs fois par jour
- L’ERP applique des règles de rapprochement automatique (référence de facture, montant, contrepartie)
- Seules les exceptions non reconnues remontent au trésorier pour traitement manuel
Le résultat : une position de trésorerie J+0 au lieu de J+3 à J+7 avec les relevés manuels. Les décisions de placement à court terme, d’affacturage ou d’arbitrage entre lignes de crédit peuvent être prises le matin même sur une base factuelle, pas sur une estimation.
Comment fonctionne la connexion banque-ERP via PSD2
Les APIs AIS (Account Information Services) : lire les comptes
L’AIS est la brique de base de tout projet de synchronisation bancaire. Un prestataire agréé AISP peut, avec votre consentement, accéder aux données de vos comptes de paiement : soldes, historiques de transactions, identifiants IBAN. Les données sont exposées en quasi-temps réel — plusieurs mises à jour par jour selon les banques.
Pour votre ERP, l’AIS remplace les exports de fichiers OFX et les relevés PDF : les transactions arrivent directement dans la comptabilité via l’API de l’agrégateur, formatées pour correspondre à vos écritures comptables.
Le consentement AIS a une durée de validité de 90 jours selon la réglementation PSD2, renouvelable. En pratique, la plupart des agrégateurs automatisent ce renouvellement pour éviter les ruptures de synchronisation.
Les APIs PIS (Payment Initiation Services) : initier les paiements
Le PIS va un cran plus loin : il permet à un prestataire agréé PISP d’initier un paiement depuis votre compte bancaire, sans passer par l’interface de votre banque. Dans un contexte ERP, cela ouvre la voie à l’approbation et au virement depuis le module fournisseurs directement — sans export de fichiers de paiement, sans reconnexion à votre espace bancaire.
À ce stade, le PIS reste moins mature que l’AIS dans les intégrations ERP standard. La plupart des projets de synchronisation bancaire commencent par l’AIS pour le rapprochement, et envisagent le PIS dans un second temps pour l’initiation de paiements groupés. Les contraintes SCA (Strong Customer Authentication) imposées par PSD2 sur les paiements ajoutent une couche d’authentification qui complique l’automatisation complète.
Les agrégateurs bancaires : le maillon entre votre banque et votre ERP
Votre ERP n’a pas vocation à gérer les APIs spécifiques de chaque banque européenne — il y en a plusieurs centaines. C’est le rôle des agrégateurs bancaires : ils maintiennent les connecteurs banque par banque, gèrent les authentifications PSD2, et exposent une API unique et normalisée à votre ERP.
L’architecture est simple :
ERP ←→ API agrégateur ←→ APIs PSD2 de vos banquesL’agrégateur gère la complexité technique (variabilité des implémentations PSD2 banque par banque, SCA, renouvellement de consentement, gestion des erreurs). Votre ERP ou votre intégrateur ne traite qu’un seul format de données.
EBICS vs PSD2 : quelle différence pour les ETI et grands comptes ?
EBICS (Electronic Banking Internet Communication Standard) est le protocole de facto pour les échanges bancaires en France, en Allemagne et en Suisse depuis les années 2000. Il reste dominant pour les grands comptes avec des volumes de virements importants et des workflows de signatures multiples.
Tableau comparatif pour une ETI française :
| Critère | EBICS | PSD2 / AIS |
|---|---|---|
| Couverture banques | Excellente (grandes banques FR/DE/CH) | Paneuropéenne via agrégateur |
| Temps réel | Non — traitement par lots programmés | Oui — plusieurs actualisations/jour |
| Déploiement | Lourd — contrat banque par banque, certificats | Léger — via agrégateur, quelques jours |
| Volumes | Adapté aux gros volumes de paiements | Adapté consultation + paiements unitaires |
| Coût | Frais bancaires + infrastructure | Abonnement agrégateur (quelques centaines €/mois) |
| Multi-banque | Chaque banque = contrat séparé | Une seule connexion agrégateur |
Pour une ETI avec deux ou trois banques partenaires, PSD2 via agrégateur est généralement plus rapide à déployer et moins coûteux à maintenir qu’EBICS. Pour un groupe avec des paiements de masse et des workflows de validation complexes, EBICS reste pertinent — et les deux peuvent coexister : EBICS pour les paiements de masse, AIS pour la consultation de soldes en temps réel.
Les ERP qui supportent nativement l’Open Banking en 2026
SAP S/4HANA : SAP Multi-Bank Connectivity et SWIFT
SAP propose sa propre solution de connectivité bancaire : SAP Multi-Bank Connectivity (MBC). Elle centralise les connexions bancaires pour S/4HANA et supporte simultanément SWIFT, EBICS, SFTP (Host-to-Host), et les APIs PSD2 selon les partenaires connectés. Les relevés bancaires arrivent au format camt.053 et camt.054, les standards XML ISO 20022 que S/4HANA traite nativement.
SAP MBC est pertinent pour les groupes qui veulent une solution SAP-native, mais il faut noter que SAP n’est pas revendeur de SWIFT — les entreprises qui utilisent la connectivité SWIFT via MBC doivent souscrire séparément au réseau SWIFT et obtenir leur propre BIC. Pour les ETI hors groupe international, un agrégateur tiers (Tink, Salt Edge) connecté à S/4HANA via API est souvent une alternative plus légère.
Microsoft Dynamics 365 Finance : connecteurs bancaires natifs
Dynamics 365 Finance dispose d’un module de rapprochement bancaire avancé avec import de relevés bancaires en formats électroniques standards (BAI2, MT940, camt.053). La connectivité PSD2 passe par des connecteurs tiers — Tink est partenaire de Microsoft et s’intègre nativement dans l’écosystème Azure/Power Platform. Les relevés synchronisés alimentent directement le journal de trésorerie et les règles de rapprochement automatique.
Odoo 17/18 : le module Bank Synchronization (Salt Edge, Ponto)
Odoo propose un module de synchronisation bancaire natif depuis la version 13, sans développement spécifique. La configuration se fait depuis le tableau de bord comptabilité et prend généralement moins d’une journée pour les banques couvertes. Les prestataires connectés nativement sont Salt Edge (couverture mondiale), Ponto (Europe, fort sur les ETI belges et françaises), et Enable Banking (pays nordiques) (source : Odoo 18.0 documentation, Bank synchronization).
La synchronisation se déclenche automatiquement toutes les 12 heures par défaut, avec possibilité de déclenchement manuel à tout moment. C’est l’implémentation la plus accessible du marché pour une PME ou ETI déjà sur Odoo.
Cegid et Sage : modules de rapprochement bancaire automatique
Cegid XRP Pulse et Sage X3 supportent tous deux l’import de relevés bancaires aux formats standards et proposent des modules de rapprochement automatique. La connexion PSD2 passe généralement par des partenaires intégrateurs ou des connecteurs développés par des tiers. Cegid a signé des partenariats avec des fintechs françaises de trésorerie (Agicap, Kyriba) dont les connexions bancaires enrichissent les données du module financier.
NetSuite : Bank Feeds et Electronic Bank Payments
Oracle NetSuite propose deux fonctionnalités complémentaires : Bank Feeds pour la synchronisation automatique des relevés (via des fournisseurs agréés selon les pays), et Electronic Bank Payments pour l’initiation de paiements. La couverture européenne des Bank Feeds varie selon les pays — à vérifier avec votre partenaire NetSuite pour les banques françaises spécifiques.
Les agrégateurs bancaires européens : panorama
Bridge (ex Bankin) : leader français, agréé ACPR
Bridge est l’agrégateur historique français, issu de l’application Bankin. Il couvre toutes les grandes banques françaises et est agréé AISP par l’ACPR. Bridge est particulièrement utilisé par les fintechs B2B françaises et les cabinets comptables. Son API est bien documentée et ses tarifs B2B sont négociables selon les volumes. À vérifier : la couverture des banques régionales et des comptes professionnels spécifiques.
Powens (ex Budget Insight) : fort en B2B et intégrations ERP
Powens est spécialisé dans les cas d’usage B2B — rapprochement bancaire, trésorerie, détection de fraude. Son positionnement est moins grand public que Bridge, ce qui se traduit par une API plus orientée intégrateurs. Powens propose également des fonctionnalités enrichies autour des données transactionnelles (catégorisation, normalisation) qui simplifient le travail côté ERP.
GoCardless (ex Nordigen) : pan-européen, API ouverte
Nordigen, racheté par GoCardless, propose une API Open Banking paneuropéenne qui couvre plus de 2 300 institutions financières dans 31 pays (source : OpenBankingTracker, European PSD2 aggregators). Son positionnement est plus orienté paiements récurrents que consultation de comptes, mais la couverture géographique est un atout pour les groupes avec des filiales dans plusieurs pays européens.
Tink (Visa) : couverture européenne, partenaire Microsoft
Tink, racheté par Visa en 2022, est l’un des agrégateurs à la plus large couverture européenne. Son partenariat avec Microsoft en fait la solution naturelle pour les environnements Dynamics 365. Tink supporte l’AIS et le PIS dans la majorité des pays de l’UE.
Salt Edge : international avec forte présence Odoo
Salt Edge se distingue par sa couverture mondiale (plus de 50 pays) et par son intégration native dans Odoo. C’est l’option la plus simple pour une entreprise déjà sur Odoo qui veut activer la synchronisation bancaire sans développement custom.
Bénéfices concrets : ce que cela change au quotidien
Rapprochement bancaire : de 4h/semaine à 15 min
Le gain le plus immédiat est la réduction du temps de rapprochement bancaire. Avant synchronisation automatique : export de relevés, import dans l’ERP, matching manuel des lignes non reconnues. Après : les transactions arrivent déjà dans l’ERP, les règles de rapprochement automatique matchent 85 à 95 % des lignes selon la qualité des règles configurées. Le trésorier ne traite que les exceptions. Les retours terrain d’entreprises ayant déployé ce type de solution (Odoo + Salt Edge, Dynamics 365 + Tink) évoquent régulièrement une réduction de 80 à 90 % du temps de rapprochement manuel — une estimation cohérente avec la nature du gain, même si chaque contexte est différent.
Prévisions de trésorerie : vision J+0 au lieu de J+7
Avec une synchronisation quotidienne des soldes bancaires, le module de prévision de trésorerie de l’ERP travaille sur des données réelles actualisées, pas sur des estimations ou des données vieilles de plusieurs jours. La construction d’un prévisionnel à 30 ou 90 jours devient plus fiable dès lors que la position de départ est certaine.
Détection précoce des anomalies
Un flux transactionnel automatisé permet de configurer des alertes sur des patterns inhabituels : virements vers de nouveaux IBAN bénéficiaires, transactions au-dessus d’un seuil, doublons de paiements. Ces contrôles, difficiles à réaliser manuellement sur des relevés hebdomadaires, deviennent automatisables dès que les données bancaires sont dans l’ERP en temps quasi-réel.
Mise en oeuvre : étapes et points de vigilance
Étapes de déploiement
Étape 1 — Inventaire des comptes. Listez toutes les banques et comptes professionnels à synchroniser, incluant les comptes courants, les comptes à terme, et les cartes corporate si elles sont gérées dans votre ERP. Vérifiez la couverture de ces banques chez votre agrégateur cible avant de signer.
Étape 2 — Choix de l’agrégateur. Comparez la couverture banques, les certifications réglementaires (agrément ACPR, FCA, BaFin selon vos pays), les niveaux de SLA, et les modèles tarifaires. Un agrégateur déjà partenaire de votre ERP réduit le travail d’intégration. Si vous avez des banques dans plusieurs pays européens, priorisez un acteur pan-européen comme GoCardless ou Tink.
Étape 3 — Configuration des règles de rapprochement. La qualité des règles de rapprochement automatique détermine directement le taux de match. Travaillez avec votre intégrateur pour modéliser les patterns de vos transactions : références de factures, montants types par fournisseur, libellés bancaires récurrents.
Étape 4 — Formation et validation. Formez les équipes trésorerie aux nouveaux workflows. Prévoyez une période de double run (rapprochement manuel + automatique en parallèle) de 2 à 4 semaines pour valider les règles avant de basculer complètement.
Points de vigilance
RGPD et données bancaires. Les données bancaires sont des données financières sensibles soumises aux exigences RGPD. Votre contrat avec l’agrégateur doit inclure un DPA (Data Processing Agreement) conforme, précisant les durées de conservation, les mesures de chiffrement en transit et au repos, et les sous-traitants éventuels. Si votre entreprise a un DPO, impliquez-le dès la sélection de l’agrégateur. Pour approfondir le cadre RGPD dans votre ERP, consultez notre guide complet RGPD et conformité ERP.
Périmètre PSD2. PSD2 couvre les comptes de paiement au sens de la directive — pas nécessairement tous les comptes bancaires professionnels. Vérifiez avec votre banque quels comptes sont exposés via l’API PSD2 et lesquels restent en dehors du périmètre (comptes à terme, comptes de cantonnement, etc.).
Double réconciliation à éviter. Si vous maintenez un outil de trésorerie externe (Agicap, Kyriba, Cashforce) en parallèle de votre ERP, assurez-vous de ne pas avoir deux flux de synchronisation bancaire concurrents qui créent des doublons d’écritures. Définissez un système de référence unique.
PSD3 en vue : ce qui va changer pour les ERP (2027-2028)
Le Parlement européen et le Conseil ont atteint un accord politique sur PSD3 et le nouveau règlement PSR (Payment Services Regulation) fin 2025 (source : OpenBankingTracker, Open Banking in 2026). PSD3 renforcera plusieurs points importants pour les équipes DSI et finance :
- Amélioration de la qualité des APIs bancaires. PSD2 a ouvert les APIs en principe, mais la qualité des implémentations varie fortement d’une banque à l’autre. PSD3 devrait imposer des standards de performance et de disponibilité plus stricts.
- Extension des droits d’accès. PSD3 devrait élargir les données accessibles via Open Banking au-delà des seuls comptes de paiement, incluant potentiellement les données d’épargne et de crédit.
- Renforcement de la sécurité. De nouvelles exigences SCA et des mécanismes anti-fraude renforcés sont attendus.
Pour les équipes IT et finance, le message est clair : les projets de synchronisation bancaire lancés sous PSD2 seront compatibles avec PSD3 — PSD3 améliore le cadre sans remettre en cause l’architecture Open Banking. Anticipez néanmoins une mise à jour des consentements et potentiellement des fonctionnalités supplémentaires offertes par vos agrégateurs dans le courant de 2027.
Pour aller plus loin sur la gestion de trésorerie dans votre ERP, lisez notre guide complet trésorerie ERP et cash flow en temps réel et notre comparatif ERP trésorerie : CMS, SWIFT et prévisions de cash pour DAF.
