La synchronisation bancaire est devenue un rouage central de la comptabilité moderne : elle alimente automatiquement les logiciels de gestion avec les écritures du compte professionnel, sans saisie manuelle ni import de fichiers. Derrière cette apparente simplicité se cache un empilement technique précis — réglementation européenne, cryptographie, protocoles d’autorisation et formats normalisés. Cet article détaille le fonctionnement réel d’une connexion bancaire sécurisée, couche par couche.
Qu’est-ce que la synchronisation bancaire ?
La synchronisation bancaire désigne la récupération automatisée, par un logiciel tiers, des données d’un ou plusieurs comptes bancaires : soldes, opérations, libellés, dates de valeur, références de virement. Selon les cas, elle peut aussi couvrir l’initiation de paiements depuis l’outil de gestion.
Historiquement, ces échanges reposaient sur des imports manuels (relevés PDF, fichiers CSV, CFONB 120) ou sur du screen scraping : un robot se connectait à l’espace client en réutilisant les identifiants du titulaire. Cette méthode, fragile et discutable en matière de sécurité, a largement cédé la place à des interfaces applicatives dédiées imposées par la réglementation européenne.
Le cadre réglementaire : la DSP2 et l’open banking
La deuxième directive sur les services de paiement (DSP2, directive UE 2015/2366) a rendu obligatoire l’ouverture, par les banques, d’interfaces dédiées permettant à des acteurs tiers agréés d’accéder aux comptes de paiement avec l’accord explicite du client. Les normes techniques de réglementation associées, dont l’authentification forte, s’appliquent depuis le 14 septembre 2019.
Les rôles AISP et PISP
Deux statuts structurent l’écosystème :
- AISP (prestataire de services d’information sur les comptes) : accès en lecture aux données de compte. C’est le statut utilisé pour la synchronisation comptable.
- PISP (prestataire de services d’initiation de paiement) : déclenchement d’un virement à la demande du client, sans passer par sa banque en ligne.
En France, ces agréments ou enregistrements sont délivrés par l’ACPR, et les acteurs autorisés figurent dans le registre REGAFI ainsi que dans le registre européen tenu par l’EBA. Vérifier l’inscription d’un prestataire dans ces registres est le premier contrôle à effectuer.
Les certificats eIDAS : QWAC et QSealC
Un prestataire tiers ne peut pas se contenter d’une clé d’API. Il doit s’identifier auprès de la banque à l’aide de certificats qualifiés délivrés par un prestataire de services de confiance (QTSP) au titre du règlement eIDAS :
- le QWAC (certificat qualifié d’authentification de site web), utilisé pour établir un canal TLS mutuellement authentifié entre le serveur du tiers et l’API bancaire ;
- le QSealC (certificat qualifié de cachet électronique), utilisé pour signer les requêtes et prouver l’intégrité et l’origine des messages.
Ces certificats embarquent le numéro d’agrément et les rôles autorisés (AISP, PISP, CBPII). Une banque peut ainsi refuser techniquement une requête émanant d’un acteur dont l’agrément a été retiré.
L’architecture technique d’une connexion bancaire
Étape 1 : le consentement via OAuth 2.0
La quasi-totalité des API bancaires européennes s’appuient sur OAuth 2.0, en authorization code flow. Le principe est de ne jamais exposer les identifiants bancaires à l’application tierce :
- L’utilisateur clique sur « connecter ma banque » dans son logiciel comptable.
- Il est redirigé vers le domaine de sa banque (ou vers son application mobile bancaire, via app-to-app redirect).
- Il s’authentifie sur l’environnement de la banque et sélectionne les comptes qu’il souhaite partager.
- La banque renvoie un code d’autorisation à usage unique vers l’URL de redirection déclarée.
- Le serveur du prestataire échange ce code contre un access token et un refresh token, sur un canal mTLS.
Les standards d’implémentation varient selon les zones : STET en France, NextGenPSD2 du Berlin Group en Allemagne et dans une large partie de l’Europe, Open Banking Standard au Royaume-Uni. Ces spécifications divergent sur les endpoints, la pagination ou la gestion des erreurs, ce qui explique le rôle des agrégateurs qui normalisent des centaines de connecteurs derrière une API unique.
Étape 2 : l’authentification forte du client (SCA)
L’authentification forte impose la combinaison d’au moins deux facteurs indépendants parmi : la connaissance (mot de passe, code), la possession (téléphone enrôlé, carte, dispositif matériel) et l’inhérence (empreinte digitale, reconnaissance faciale). En pratique, la validation se fait le plus souvent dans l’application mobile de la banque.
Pour l’accès aux données de compte, un renouvellement périodique du consentement est requis. Le délai initial de 90 jours a été porté à 180 jours par un amendement aux normes techniques adopté en 2022, applicable depuis 2023, lorsque l’accès est réalisé par un prestataire tiers agréé. C’est la raison pour laquelle une connexion bancaire doit être réauthentifiée à intervalles réguliers : il ne s’agit pas d’un défaut logiciel mais d’une exigence réglementaire.
Étape 3 : la récupération des données
Une fois le jeton obtenu, le prestataire interroge les endpoints de la banque, généralement en REST/JSON : liste des comptes, soldes, transactions sur une plage de dates. Deux modes coexistent :
- Le polling : interrogation planifiée, souvent une à plusieurs fois par jour, dans les limites de quotas fixés par chaque banque.
- Les webhooks : notification poussée vers l’application tierce lorsqu’un nouvel événement survient, ce qui réduit la latence et la charge réseau.
Les API imposent des limites de débit (rate limiting), une profondeur d’historique variable (souvent 12 à 24 mois à l’initialisation) et des règles distinctes selon que l’utilisateur est présent ou non devant son écran. Les requêtes réalisées hors présence de l’utilisateur sont contingentées, typiquement à quelques appels quotidiens par compte.
Étape 4 : la restitution dans l’outil comptable
Les données brutes sont ensuite normalisées : dédoublonnage par identifiant de transaction, distinction entre opérations en attente et opérations comptabilisées, enrichissement du libellé, catégorisation, puis proposition de rapprochement avec les factures d’achat et de vente. C’est à ce niveau que la synchronisation rejoint la chaîne de facturation électronique et les flux normalisés type Peppol : le lettrage automatique repose sur la correspondance entre une référence de virement et un identifiant de facture.
Les couches de sécurité
Chiffrement en transit et au repos
Les échanges s’appuient sur TLS 1.2 ou 1.3, avec authentification mutuelle des certificats. Côté stockage, les données sont généralement chiffrées avec des algorithmes symétriques robustes (AES-256), les clés étant gérées dans un module dédié (HSM ou service de gestion de clés) et non dans le code applicatif.
Tokenisation et absence de stockage des identifiants
C’est la différence structurante avec l’ancien scraping : dans un parcours DSP2, le logiciel tiers ne détient jamais les identifiants de banque en ligne. Il conserve uniquement des jetons à durée de vie limitée, périmètre restreint (lecture seule) et révocables à tout moment par le client depuis son espace bancaire. Une compromission côté prestataire n’expose donc pas directement les moyens de connexion du titulaire.
Cloisonnement, journalisation et supervision
Les architectures sérieuses ajoutent : cloisonnement des environnements, principe du moindre privilège, journalisation horodatée et inaltérable des accès, détection d’anomalies, tests d’intrusion réguliers. Sur le plan organisationnel, les certifications ISO/IEC 27001 ou les rapports SOC 2 constituent des indicateurs de maturité, sans se substituer à un examen contractuel. Le RGPD impose par ailleurs la minimisation des données, une durée de conservation définie et une information claire sur les sous-traitants et les lieux d’hébergement.
EBICS : la voie des entreprises
Parallèlement à la DSP2, les entreprises utilisent souvent le protocole EBICS (Electronic Banking Internet Communication Standard), très répandu en France et en Allemagne. Il fonctionne différemment : échange de messages signés entre le système d’information de l’entreprise et la banque, avec des clés cryptographiques asymétriques propres à l’entreprise, une lettre d’initialisation signée, et selon les variantes (EBICS T ou EBICS TS) une signature électronique distincte pour le transport et pour l’autorisation des ordres.
EBICS est adapté aux volumes importants, aux remises de virements SEPA et aux schémas de double validation. Il suppose en revanche une contractualisation avec chaque banque et une gestion rigoureuse des certificats, là où une connexion DSP2 s’active en quelques minutes.
Les formats de données échangés
Au-delà du JSON des API, les flux bancaires professionnels reposent sur des formats normalisés ISO 20022 :
- camt.053 : relevé de compte de fin de journée ;
- camt.052 : mouvements intrajournaliers ;
- camt.054 : avis de débit et de crédit détaillés ;
- pain.001 : ordres de virement émis par l’entreprise.
Les formats plus anciens comme MT940 ou CFONB 120 restent en usage. Le camt.053 est particulièrement utile en comptabilité car il transporte des zones de remise structurées permettant un rapprochement automatique plus fiable.
Limites et points de vigilance
Une connexion bancaire n’est jamais totalement stable : évolutions d’API côté banque, indisponibilités temporaires, changements de parcours d’authentification, expiration de consentement. Un bon prestataire publie un état de service par établissement et gère les reprises sur erreur.
Autres points à examiner : la profondeur d’historique récupérable, la couverture des comptes professionnels (certaines banques ont ouvert leurs API entreprises plus tardivement que les comptes particuliers), la politique de conservation après résiliation, et la localisation des traitements.
Ce qui se prépare : DSP3, PSR et accès aux données financières
La Commission européenne a présenté en juin 2023 un ensemble législatif comprenant une troisième directive sur les services de paiement, un règlement sur les services de paiement et un cadre sur l’accès aux données financières (FIDA). Ces textes visent notamment à améliorer la qualité et la disponibilité des interfaces bancaires, à renforcer la lutte contre la fraude et à étendre le partage de données au-delà des seuls comptes de paiement. Leur calendrier d’application dépend de l’issue du processus législatif européen et des périodes de transition retenues.
Comment évaluer une solution de synchronisation
Quelques critères concrets : vérifier l’agrément dans les registres officiels, demander la liste des sous-traitants et la localisation des données, contrôler l’existence d’une politique de sécurité documentée et de tests d’intrusion, examiner la couverture bancaire réelle sur vos établissements, tester la qualité du rapprochement automatique sur un échantillon d’écritures, et s’assurer que les jetons et consentements sont révocables simplement.
Une synchronisation bien conçue combine ainsi trois éléments : un cadre réglementaire qui encadre l’accès, une chaîne cryptographique qui protège les échanges, et une couche métier qui transforme des lignes bancaires en écritures exploitables. C’est cette combinaison, plus qu’une technologie isolée, qui détermine le niveau de sécurité effectif de votre comptabilité.