Etiseo
Une banque pilotable par API, sans dépendre d'un fournisseur.
6
contextes bornés livrés
5
niveaux de permissions granulaires
4 mois
Phase 1 livrée
Le contexte
Aqtara est une plateforme BaaS (Banking-as-a-Service) pour les PME et freelances français, construite pour Etiseo. L'offre consiste à donner à chaque client un compte bancaire complet (multi-soldes, paiements SEPA, émission de cartes), pilotable depuis une API ou une interface, sans que l'utilisateur final ait à connaître le fournisseur d'infrastructure bancaire sous-jacent, ni à en dépendre.
Au démarrage, l'enjeu architectural n'était pas de « construire une banque ». Il était de construire une plateforme capable de survivre à un changement de fournisseur d'infrastructure. Le marché européen du BaaS évolue rapidement (rachats, fusions, changements de modèle économique côté fournisseur). Un système qui couple directement le code métier à un fournisseur unique se condamne à un coût de migration prohibitif quand ce fournisseur change.
Nous avons construit Aqtara comme une plateforme hexagonale : six contextes bornés (Identité, Compte, Virement, Carte, Facturation, Noyau partagé) qui exposent chacun leurs ports métiers, avec une adaptation par fournisseur côté infrastructure. Swan est le fournisseur actuel ; un autre fournisseur pourrait s'enficher avec une à deux semaines d'implémentation d'adaptateurs, sans toucher au code métier.
Les décisions d'architecture
Architecture hexagonale avec adaptateur par fournisseur bancaire, pas Intégration directe Swan dans le code métier. Le métier bancaire (compte, virement, carte, facturation) est exprimé en termes propres à Aqtara, jamais en termes Swan. Un port `AccountProvider` déclare ce que le métier attend ; un adaptateur Swan l'implémente. Le métier ne sait pas qu'il parle à Swan : il pourrait parler à n'importe quel BaaS capable de fournir les mêmes opérations. La condition de réussite : qu'un changement de fournisseur se règle en une semaine d'écriture d'adaptateurs, et non en un mois de refonte.
Trade-off assumé : Coût de l'approche port-and-adapter payé d'avance : six contextes × N ports chacun. Plus de code à écrire au démarrage que dans une intégration directe. Bénéfice : le code métier reste lisible en termes du domaine, sans pollution par les particularités de l'API Swan, et la dépendance fournisseur est physiquement isolée à une seule couche.
Six contextes bornés DDD avec outbox transactionnel pour la cohérence éventuelle, pas Monolithe avec base de données unique et écritures cross-domaine en transactions. Le domaine bancaire a des frontières naturelles de cohérence : l'état d'un compte, le cycle de vie d'un virement ou d'une carte ne partagent pas les mêmes invariants. Modéliser explicitement chaque contexte comme un sous-système permet (a) de faire évoluer chaque partie indépendamment, (b) de migrer plus tard vers une architecture microservices sans refonte, et (c) de garantir que les événements inter-contextes survivent à un crash via un outbox transactionnel.
Trade-off assumé : Six schémas à migrer indépendamment, jamais de JOIN cross-contexte. Les lectures inter-contextes passent par des ports déclarés (par exemple, le contexte Compte regarde l'utilisateur via un port AccountHolderLookup, jamais via une FK). Coût de discipline à l'écriture, gain de flexibilité à l'évolution.
Modèle de permissions explicite à cinq niveaux, granulaire par membre, pas Rôles globaux (admin / membre / lecteur) avec privilèges implicites. Une PME ne fonctionne pas avec un rôle unique : le fondateur peut tout faire, le DAF gère les bénéficiaires et initie les virements, le comptable consulte sans pouvoir modifier, le commercial accède à un sous-ensemble. Les cinq permissions (consultation du compte, gestion des membres, gestion des bénéficiaires, initiation de virements, gestion des cartes) sont des colonnes booléennes sur la table d'adhésion ; chaque membre coche les capacités dont il a besoin. Ajouter une sixième permission est une migration, non une refonte du système de rôles.
Trade-off assumé : Plus de colonnes à maintenir, pas de raccourci 'role:admin' qui donne tout d'un coup. En contrepartie, la matrice de permissions est explicite, auditable et fine à l'usage : exactement ce qu'attend un client professionnel qui doit prouver à sa compliance qui peut faire quoi.
L'exécution
La plateforme tourne en Go 1.25 sur PostgreSQL 16. Chaque contexte borné a son propre schéma de base, ses propres migrations versionnées (vingt-et-une migrations à ce jour), et ne lit jamais directement dans le schéma d'un autre : les frontières passent par les ports métiers déclarés. L'identité est gérée par Keycloak en OIDC ; les événements inter-contextes transitent par un outbox transactionnel qui garantit la cohérence éventuelle même en cas de crash de consommateur.
Le développement progresse par tranches verticales : chaque tranche livre un sous-ensemble fonctionnel complet (identité + compte + virement, puis carte, puis facturation), avec un audit OWASP mené en parallèle. Cent-cinquante-trois commits en quatre mois ; la cadence est volontaire, la qualité de revue aussi.
L'infrastructure de développement tourne en Docker Compose : PostgreSQL 16, Keycloak 25, NATS, Mailpit pour les emails. Une collection Postman versionnée couvre cinquante-sept scénarios automatisés qui jouent le parcours utilisateur de bout en bout : création de compte, ajout de membre, configuration de permissions, émission de virement, demande de carte. C'est le test de non-régression qui s'exécute avant chaque tranche.
Les leçons
La première leçon vient de l'audit OWASP que nous tenons en parallèle de chaque tranche de développement. Notre première implémentation des endpoints d'accès aux ressources retournait 403 Forbidden quand un utilisateur sollicitait une ressource existante à laquelle il n'avait pas accès. Logique, conforme HTTP, et exploitable : un attaquant peut énumérer les comptes ou les cartes simplement en observant la différence entre 403 (ressource existe, accès interdit) et 404 (ressource n'existe pas).
L'audit a soulevé le risque dès les premières routes. Nous avons systématisé un pattern de réponse « 403 masqué en 404 » : toute tentative d'accès refusé renvoie 404, ce qui rend la cartographie de comptes ou de cartes invisible depuis l'extérieur du périmètre légitime. La leçon plus large : la conformité HTTP ne préempte pas la sécurité applicative. Les codes de réponse sont un canal d'information à part entière, et un audit systématique coûte moins cher qu'un incident en production.
La seconde leçon vient du même audit, sur le module de virement. Le service applique deux plafonds, l'un journalier (10 000 €) et l'autre mensuel (50 000 €), vérifiés avant chaque initiation. Sans verrou, deux requêtes simultanées juste sous le plafond pouvaient toutes deux passer le check, puis être insérées en parallèle, et dépasser le plafond ensemble. L'audit a identifié la race condition lors de la revue du module Transfer ; nous avons remplacé le check naïf par un verrou consultatif PostgreSQL sur la clé (compte, période), qui sérialise lecture et écriture sur cette clé. Le dépassement devient structurellement impossible.
La leçon : les contraintes métier en banque ne tolèrent pas l'approximation. Quand un plafond est annoncé au client, il doit être vérifié de manière atomique avec l'opération qu'il borne : ni avant, ni après.
En construction aujourd'hui
Aqtara est en Phase 1 livrée : les six contextes bornés sont fonctionnels, le pattern adaptateur Swan est validé sur les opérations de production de comptes et de virements, la collection Postman couvre cinquante-sept scénarios automatisés. La Phase 2 finalise le déploiement de production et les flux de réconciliation cross-tenant.
À horizon douze mois, le test ultime de la promesse architecturale sera la capacité à absorber un changement de fournisseur bancaire en une à deux semaines de travail : sans toucher au code métier, sans rejouer la conformité, sans interrompre le service. C'est ce que la couche d'abstraction est construite pour rendre possible.
Un système à concevoir, déployer ou reprendre en main ?
Nous étudions chaque cahier des charges sérieusement. Réponse sous 48 h ouvrées.