Pour une banque, la PSD2 est le moment où des systèmes bâtis pour des années de fonctionnement fermé doivent soudain s’ouvrir au monde par des API. La directive impose à la banque d’exposer les données de comptes et l’initiation de paiement à des tiers agréés, et l’open banking transforme ce devoir légal en un vrai changement d’architecture. Pour un chief digital officer, un architecte ou un directeur IT, cela signifie une chose : la PSD2 est un projet technologique, pas seulement un exercice de conformité.
D’après notre expérience, le difficile n’est pas de comprendre la directive mais de la traduire en API sûres, stables et maintenables dans un environnement où le core bancaire, les systèmes de lutte contre la fraude et les exigences réglementaires tournent tous en même temps. Nous n’avons pas d’étude de cas publique sur ce sujet, et nous ne prétendrons pas le contraire. Nous faisons autre chose, et nous y sommes forts : nous fournissons les personnes qui vont la construire - des ingénieurs expérimentés en intégrations bancaires et en delivery de plateformes, intégrés à votre équipe en renfort d’équipe ou en équipe dédiée.
Que sont la PSD2 et l’open banking, et qu’imposent-ils à une banque ?
La PSD2 est la directive européenne sur les services de paiement qui ouvre le marché à de nouveaux acteurs et oblige les banques à travailler avec eux. L’open banking est le phénomène plus large qui en découle : la banque cesse d’être un silo fermé et devient fournisseur de services par des interfaces.
En pratique, la directive impose plusieurs choses à la fois :
- l’accès aux comptes (AIS) et l’initiation de paiement (PIS) mis à disposition de tiers,
- l’authentification forte du client (SCA) partout où le risque l’exige,
- une interface sûre et documentée pour les tiers, alignée sur un standard adopté,
- un environnement de test et un enregistrement permettant aux prestataires externes de se connecter.
Il ne s’agit pas d’un changement ponctuel dans un seul système, mais d’une nouvelle couche qu’il faut maintenir et faire grandir avec le reste de la banque.
Comment exposer des API pour les tiers (AIS/PIS) ?
Deux types de services sont au coeur de la préparation. L’AIS (Account Information Service) permet à un tiers, avec le consentement du client, de lire les données de comptes et d’opérations. Le PIS (Payment Initiation Service) lui permet d’initier un paiement directement depuis le compte du client, sans carte intermédiaire.
Construire ces interfaces va bien au-delà d’exposer un endpoint. Nous les concevons pour absorber un trafic réel venu de nombreux acteurs à la fois, avec un contrat clair et sans surcharger les systèmes sources. Nous branchons la couche API sur le core bancaire par des intégrations stables, nous ajoutons la limitation de débit et le versionnage, et nous fondons l’ensemble sur le standard adopté par la banque - pour que chaque nouvelle connexion de tiers n’exige pas de reconstruire le socle.
Comment fonctionne l’authentification forte (SCA) dans le contexte des API ?
L’authentification forte du client (SCA) est l’exigence de confirmer l’identité par au moins deux facteurs indépendants : quelque chose que le client sait, quelque chose qu’il possède et quelque chose qu’il est. Dans le monde des API, la SCA décide si l’ouverture de la banque reste sûre ou devient une porte ouverte aux abus.
Le défi est de tisser la SCA dans les flux API sans casser l’expérience client. Nous l’assemblons à partir de plusieurs pièces :
- des redirections et des jetons reliant la session du client à la requête du tiers,
- la gestion des exemptions de SCA là où la réglementation les permet (petits montants, bénéficiaires de confiance),
- le rattachement du consentement à l’authentification, pour que le client sache à quoi il consent,
- la cohérence avec les systèmes de lutte contre la fraude qui évaluent le risque des transactions en arrière-plan.
Une SCA bien conçue protège la banque et le client sans transformer chaque opération en épreuve de patience.
Comment gérez-vous la sécurité et le consentement du client ?
Ouvrir la banque par des API repousse la frontière de confiance vers l’extérieur : la gestion du consentement devient donc un composant à part entière, pas une note de bas de page. Le client doit savoir à qui il accorde un accès et pour combien de temps, et pouvoir le révoquer à tout moment, pendant que la banque enregistre, applique et audite cet état.
Nous regardons ici plusieurs couches à la fois : le chiffrement et les certificats dans les échanges avec les tiers, un registre des consentements lié à un périmètre de données précis, une piste d’audit complète de chaque accès, et une surveillance qui repère les schémas de trafic inhabituels. Dans l’open banking, la sécurité n’est pas une fonction isolée mais une propriété de toute l’architecture - et nous la traitons ainsi dès la première ligne de code du projet.
Comment concevez-vous l’architecture des API et comment la gérez-vous ?
Le coeur technique de la PSD2 est la couche entre le monde extérieur et l’intérieur de la banque. Elle se construit généralement autour d’une API gateway et d’une gestion cohérente du cycle de vie des interfaces.
Nous assemblons cette couche à partir d’éléments qui doivent jouer ensemble :
- une API gateway comme point d’entrée, d’authentification et de limitation de débit,
- des microservices qui traduisent les requêtes en opérations dans les systèmes de la banque,
- un portail développeurs avec documentation et environnement de test (sandbox),
- la surveillance et l’observabilité, pour voir le trafic, les erreurs et la performance en temps réel.
Ce socle garde les API sous contrôle à mesure que le nombre d’acteurs connectés augmente.
Pourquoi l’open banking est-il une opportunité, pas seulement une obligation ?
La plupart des banques commencent par la conformité, mais s’arrêter là gaspille le potentiel. La même infrastructure construite pour l’obligation ouvre la voie au Banking as a Service et à de nouveaux modèles de revenus.
Avec des API solides et bien gérées, une banque peut aller plus loin : proposer des services à des partenaires par des interfaces, intégrer des paiements à l’intérieur d’applications tierces, construire ses propres produits fintech sur sa plateforme. C’est le changement de regard décisif : l’investissement dans les API cesse d’être un coût de conformité pour devenir un socle produit. C’est pourquoi il vaut la peine de concevoir l’architecture en pensant dès le départ à cette deuxième étape, même si c’est la réglementation qui déclenche le projet.
Quelles compétences fournissons-nous pour un projet PSD2 ?
Un seul profil ne suffit pas pour un projet de ce type. Nous affectons les rôles autour du travail réel, pas « au cas où » :
- des architectes solution qui comprennent les intégrations au core bancaire et les patterns d’API,
- des développeurs backend (Java, .NET par exemple) qui construisent les services AIS/PIS et la logique SCA,
- des spécialistes DevOps / plateforme qui montent l’API gateway, les environnements et les pipelines,
- des ingénieurs sécurité responsables du chiffrement, du consentement et de l’audit.
Nous traitons l’expérience en delivery de plateformes et en intégrations bancaires comme une condition d’entrée, pas comme un bonus.
En combien de temps une équipe peut-elle rejoindre un projet bancaire ?
La vitesse peut être critique ici, car les échéances réglementaires ne se négocient pas. Notre recrutement se clôt généralement en trois semaines environ, et ne s’étire à deux mois que pour des exigences hors normes. Comme partenaire nearshore depuis la Pologne, nous travaillons dans un fuseau horaire proche : les ingénieurs rejoignent donc votre rythme de travail, vos revues de code et vos réunions sans longue montée en charge. Dans un environnement bancaire, nous ajoutons du temps pour les processus de sécurité et les accès - et nous le planifions honnêtement.
Comment faisons-nous chez RITS ?
Nous le faisons comme partenaire nearshore depuis la Pologne qui renforce votre équipe avec des personnes, pas avec des slides. Sur la PSD2 et l’open banking, notre rôle est concret :
- nous pourvoyons les rôles d’architecte, de backend, de DevOps et de sécurité, accordés à votre stack,
- nous construisons la couche API et les intégrations sous la direction et les standards de votre banque,
- nous apportons une expérience plateforme et intégration, sans nous attribuer les déploiements d’autrui,
- nous vérifions les compétences avant le démarrage, car une banque ne laisse pas de place à l’approximation.
Le plus souvent, nous travaillons en renfort d’équipe ou en équipe dédiée et, quand un périmètre fermé est nécessaire, en projet de logiciel sur mesure livré par notre équipe.
Par où commencer la préparation à la PSD2 et à l’open banking ?
Partez d’une question : quels services (AIS, PIS, SCA) et dans quel standard vous devez exposer en premier, et comment cela se branche sur votre core bancaire. Cette réponse définit l’architecture des API, les exigences de sécurité et les rôles nécessaires dans l’équipe. Ce n’est qu’ensuite qu’il vaut la peine de décider du modèle de collaboration - nous avons traité les différences dans notre article sur les modèles de collaboration IT.
Vous préparez une banque à la PSD2 et à l’open banking ? Parlons-en - nous accorderons les ingénieurs et l’architecture qui la construiront avec vous.
Préparez avec nous votre banque à la PSD2 et à l’open banking