Moderniser une plateforme de paiements sans attendre l'échéance DSP3

/Contexte

Une plateforme applicative bancaire à moderniser pendant qu'une directive européenne se précise

Le secteur bancaire aborde sa transformation numérique avec un héritage applicatif dense : des plateformes de paiement construites par couches successives, difficiles à faire évoluer, et sur lesquelles pèse désormais la troisième directive sur les services de paiement.

La tentation habituelle consiste à traiter la modernisation et la conformité comme deux chantiers séparés — refondre d'abord, mettre en conformité ensuite. C'est précisément ce découplage qui coûte cher : une exigence réglementaire intégrée après coup se traduit par une couche de contrôles ajoutée en périphérie, que personne n'ose ensuite retoucher.

/Démarche

La conformité traitée comme une contrainte d'architecture, pas comme une couche ajoutée

Les exigences réglementaires ont été traduites en contraintes d'architecture et en critères d'acceptation dès les premiers ateliers, et non en points de contrôle en fin de recette. Les équipes de développement sont intervenues au sein des équipes de la banque : sur une plateforme de paiements, la connaissance du métier et des cas limites ne se transmet pas par spécification.

• Traduction des exigences DSP3 en règles vérifiables dans le pipeline de livraison
• Découpage des services autour des flux de paiement plutôt qu'autour des équipes existantes
• Traitement des volumes en batch et en temps réel dans une même chaîne
• Automatisation des déploiements pour rendre la mise en conformité rejouable

‍

/Impact

Une conformité qui ne se repaye pas à chaque évolution

Le gain ne se voit pas au premier jour, il se voit à la troisième évolution. Parce que les règles réglementaires sont vérifiées à chaque livraison plutôt que reconstituées avant chaque audit, la plateforme accueille de nouvelles fonctions sans rouvrir le dossier de conformité.

• De nouvelles solutions de paiement conçues, développées et déployées en production
• Des contrôles réglementaires exécutés dans la chaîne de livraison, et non en fin de recette
• Une sortie progressive de l'existant GWT engagée sans interruption de service
• Des équipes clientes autonomes sur l'architecture livrée, parce qu'elles l'ont construite

/Dispositif

Des profils full stack seniors, sur un socle choisi pour durer

Des développeurs Java Angular full stack expérimentés, positionnés au sein des équipes de la banque plutôt qu'en centre de développement isolé. Le socle technique privilégie la durabilité : Java 21 et Spring Boot 3 pour les services, Spring Batch pour les traitements de masse, des API REST pour les échanges, Kafka pour la circulation des événements, PostgreSQL pour la persistance, Docker et Kubernetes pour l'exécution, GitHub Actions pour la chaîne de livraison. Côté interfaces, Angular, React et VueJS coexistent avec l'existant GWT.

‍