Conception de Bases de Données Bancaires en 2026 : Schémas et Partitionnement
Guide pratique sur la conception de bases de données pour la banque centrale : schémas de grand livre, comptabilité en partie double, cohérence ACID, event sourcing et stratégies de sharding pour le traitement de transactions à fort volume.
Principes fondamentaux de la conception de bases de données bancaires
Tout produit fintech n'est fiable qu'autant que sa base de données. Le paiement par carte, le virement SEPA, l'accumulation d'intérêts nocturne - tous écrivent dans et lisent depuis un référentiel central. Se tromper dans ce référentiel n'est pas un problème de performance que l'on optimise plus tard ; c'est un problème de justesse qui se manifeste sous forme d'écarts de réconciliation, de constats réglementaires ou d'argent client introuvable.
La conception de bases de données pour la banque centrale repose sur des principes qui ont traversé chaque génération technologique : des fichiers VSAM sur mainframe aux bases de données relationnelles jusqu'aux systèmes distribués cloud-natifs d'aujourd'hui. Les noms évoluent, mais les exigences de fond ne changent pas.
Immuabilité
Les transactions comptabilisées ne sont jamais modifiées ni supprimées. Les corrections arrivent sous forme de nouvelles écritures d'annulation. Le grand livre ne croît que vers l'avant.
Comptabilité en partie double
Chaque mouvement d'argent débite un compte et en crédite un autre du même montant. La somme de toutes les écritures est toujours nulle.
Event sourcing
Le registre autoritatif est le journal ordonné d'événements, et non un champ de solde mutable. Les soldes sont dérivés en rejouant ce journal.
En pratique, ces principes signifient : utiliser DECIMAL ou NUMERIC pour toutes les colonnes monétaires (jamais FLOAT), appliquer les contraintes de clé étrangère au niveau de la base de données et pas seulement dans la couche applicative, et traiter la table de transactions comme append-only dès le premier jour. Les décisions prises lors de la conception du schéma sont coûteuses à revenir sur une fois les données de production existantes.
Discutons de votre projet et voyons comment nous pouvons lancer votre projet. produit bancaire numérique ensemble
Demander une démoConception du schéma pour les comptes, les écritures et les produits
Un schéma bancaire minimal mais complet nécessite trois entités de domaine principales avec une séparation claire entre elles. Les noms exacts de colonnes varient selon le fournisseur ou l'équipe, mais la structure conceptuelle reflète l'organisation des systèmes de production dans les fintechs en 2026.
| Entité | Colonnes clés | Notes de conception |
|---|---|---|
| Client | customer_id, status, niveau KYC, created_at | Données personnelles stockées chiffrées (AES-256). Une table d'événements KYC séparée stocke les résultats de vérification AML avec journal d'audit immuable. |
| Compte | account_id, customer_id, product_id, currency, status, current_balance, available_balance | Les colonnes de solde sont des agrégats dérivés mis à jour transactionnellement ; stockés pour la vitesse de lecture. product_id pointe vers le catalogue de produits, sans logique codée en dur. |
| Écriture / Ligne du grand livre | posting_id, account_id, transaction_id, amount (DECIMAL), direction (D/C), value_date, booking_date, status | Append-only. transaction_id regroupe les deux lignes d'une paire d'écriture double. Les soldes sont réconciliés en additionnant les écritures. |
| Transaction | transaction_id, reference, channel, initiated_at, settled_at, narrative | Enregistrement parent reliant une ou plusieurs paires d'écritures. Stocke les références externes (SWIFT UETR, identifiant de bout en bout SEPA). |
| Produit | product_id, type, interest_rate_config, fee_config, currency_rules | Définitions de produit sous forme de données - un compte courant, un compte d'épargne et un prêt diffèrent par configuration, pas par code. Permet de nouveaux produits sans changement de schéma. |
Un schéma que de nombreux cœurs cloud-natifs adoptent est la séparation du Grand Livre Général (General Ledger) de la couche de comptes orientée client. Le grand livre applique la partie double au niveau système ; la couche de comptes agrège et présente les soldes aux clients et aux API. Les rapports s'exécutent contre un réplica de lecture séparé ou un entrepôt de données alimenté par Change Data Capture (CDC), évitant que les requêtes analytiques n'entrent en concurrence avec les écritures transactionnelles en temps réel.
Cohérence, ACID et le grand livre
La banque est l'un des rares domaines où la garantie ACID complète - Atomicité, Cohérence, Isolation, Durabilité - est non négociable. Un débit de paiement qui réussit sans son crédit correspondant n'est pas une dégradation des performances ; c'est de l'argent manquant.
| Propriété | Ce que cela signifie pour la banque | Application pratique |
|---|---|---|
| Atomicité | Le débit et le crédit d'un virement sont tous deux validés ou tous deux annulés. Pas d'état partiel. | Transaction de base de données unique englobant les deux lignes d'écriture. Patron saga pour les grands livres distribués. |
| Cohérence | La somme de tous les débits moins la somme de tous les crédits doit être nulle après chaque transaction. | Contraintes CHECK en base de données et assertion au niveau applicatif au moment de l'écriture. |
| Isolation | Une vérification de solde lors d'un virement concurrent doit voir soit l'état avant, soit l'état après le virement, jamais un état intermédiaire. | Niveau d'isolation Serializable ou REPEATABLE READ ; verrouillage au niveau des lignes pour les mises à jour de solde. |
| Durabilité | Une fois un paiement confirmé, il doit survivre à une panne serveur ou à une coupure de courant. | WAL (write-ahead log) dans PostgreSQL/Oracle ; réplication synchrone vers au moins un serveur de secours. |
L'event sourcing complète ACID en traitant le journal d'écritures comme le registre canonique. Plutôt que de stocker un champ de solde mutable comme source de vérité, le système stocke chaque événement (débit, crédit, commission, accumulation d'intérêts) et dérive le solde courant en les additionnant. Cela crée une piste d'audit naturelle et simplifie la conformité sous la supervision de l'ACPR et de l'AMF : chaque opération comptable étant enregistrée de façon immuable, la base de données satisfait les exigences de traçabilité sans infrastructure supplémentaire. Les établissements soumis aux orientations EBA sur la gestion des risques opérationnels et la DORA trouveront que ce schéma facilite la démonstration de l'intégrité des données lors des contrôles.
PostgreSQL est le moteur open source le plus courant pour ce modèle en 2026 : isolation sérialisable, verrouillage au niveau des lignes, réplication logique pour le CDC, partitionnement par plage ou par hachage, et le type NUMERIC avec précision arbitraire. Les variantes gérées dans le cloud (AWS Aurora, Google AlloyDB, Azure Database for PostgreSQL) ajoutent le basculement géré et l'autoscaling de stockage sur le même protocole.
Stratégies de sharding pour le traitement de transactions à fort volume
Un seul nœud PostgreSQL peut traiter environ 10.000 à 30.000 transactions par seconde dans de bonnes conditions. De nombreuses plateformes fintech atteignent ce plafond en quelques années après le lancement. Une fois que la mise à l'échelle verticale (ajout de RAM et de CPU à un serveur) atteint sa limite de coût et physique, l'étape suivante est la mise à l'échelle horizontale via le sharding - distribution des lignes sur plusieurs nœuds de base de données autonomes afin que chaque nœud ne stocke qu'une fraction des données et du trafic.
Une shard map (également appelée table de routage ou répertoire) suit quelles données résident sur quel nœud. Chaque requête passe par une couche de routage qui consulte la shard map et dirige la demande vers le bon nœud.
| Stratégie | Fonctionnement | Adéquation bancaire | Risques |
|---|---|---|---|
| Basé sur le hachage | Fonction de hachage sur la clé de shard (ex. account_id) achemine vers un shard fixe. Le hachage cohérent minimise les déplacements de données lors de l'ajout de nœuds. | Excellent pour distribuer les écritures entre comptes de façon uniforme. | Les requêtes de plage sur de nombreux comptes nécessitent un fan-out vers tous les shards. |
| Basé sur des plages | Plages séquentielles de la clé (ex. IDs de compte 0-999999 sur shard 1, 1000000-1999999 sur shard 2). | Bon pour les données de séries temporelles et les rapports par plage de dates. | Les nouveaux comptes ou transactions récentes se concentrent sur le dernier shard - problème classique de hot-spot. |
| Géo-sharding | Données acheminées par géographie client. Clients en France sur des shards européens ; clients hors EEE sur des shards régionaux. | Réduit la latence ; supporte les exigences de résidence des données selon le RGPD et les règles de l'ACPR sur la localisation des données sensibles. | Les virements transfrontaliers nécessitent une coordination entre shards. |
| Basé sur un répertoire | Table de recherche qui associe chaque clé à son shard explicitement. Flexibilité maximale dans le placement. | Utile pour les comptes VIP ou entreprises nécessitant des shards dédiés. | Le répertoire lui-même devient un point de défaillance unique critique s'il n'est pas répliqué. |
Mise à l'échelle des lectures et écritures, clés de partition et éviter les hot-spots
Choisir une clé de shard est la décision la plus lourde de conséquences dans une architecture bancaire fragmentée. Un mauvais choix de clé crée des hot-spots - des shards qui reçoivent une fraction disproportionnée du trafic pendant que d'autres shards restent inactifs. L'erreur classique est de fragmenter par un champ à faible cardinalité (devise, statut de compte, pays) plutôt que par un identifiant à haute cardinalité (ID de compte, ID client, ID de transaction).
Directives pratiques pour la sélection de clé de shard en banque :
- Utiliser account_id ou customer_id pour les données du grand livre - toutes les écritures d'un compte restent sur le même shard, rendant les requêtes mono-compte rapides et intra-shard.
- Éviter les IDs séquentiels d'une seule séquence comme clé de shard en mode hachage lors de la création de comptes à fort volume. Utiliser des UUIDs v4 ou des IDs snowflake à la place.
- Pré-découper les shards si la charge initiale est connue - mieux vaut démarrer avec plus de shards que nécessaire que de re-fragmenter ensuite. Re-fragmenter un grand livre en production sans interruption de service est l'une des tâches opérationnelles les plus complexes en ingénierie fintech.
- Maintenir l'intégrité référentielle au niveau applicatif - les clés étrangères traditionnelles ne traversent pas les frontières de shard. L'application ou un coordinateur de sagas doit assurer la cohérence entre écritures sur différents shards pour les virements inter-comptes.
La mise à l'échelle des lectures est gérée séparément du sharding des écritures. Les réplicas de lecture sur chaque shard servent les rapports, les consultations de solde et la génération de relevés sans concurrencer le trafic d'écriture. Le patron CQRS (Command Query Responsibility Segregation) est courant : les écritures vont au cluster OLTP fragmenté ; les lectures pour les rapports et analyses vont vers un modèle de lecture séparé ou un entrepôt de données (BigQuery, Redshift, Snowflake) alimenté via des pipelines CDC.
Pour les requêtes inter-shards (ex. "montrer toutes les transactions supérieures à 10.000 EUR sur tous les comptes pour contrôle AML"), les options sont : distribuer la requête à tous les shards et fusionner les résultats dans la couche applicative, maintenir un index matérialisé inter-shards mis à jour via event streaming, ou acheminer ces requêtes vers l'entrepôt de données. La plupart des systèmes de production utilisent les trois approches selon le type de requête et la tolérance de latence.
Sauvegarde, piste d'audit et conservation réglementaire des données
En France, sous la supervision de l'ACPR, les établissements de paiement et de monnaie électronique doivent conserver les enregistrements de transactions pendant cinq ans au minimum au titre de la réglementation AML/LCB-FT, et jusqu'à dix ans pour les données liées aux opérations suspectes. Les exigences DORA sur la résilience opérationnelle numérique, pleinement applicables en 2025, renforcent également les obligations de continuité des données et de test des plans de reprise.
| Exigence | Approche d'implémentation |
|---|---|
| Piste d'audit immuable (ACPR / LCB-FT) | Tables de grand livre append-only. Déclencheurs de base de données ou logique applicative empêchent UPDATE/DELETE sur les lignes comptabilisées. Les événements d'audit sont écrits dans un journal append-only séparé (schéma séparé ou sink de streaming comme Kafka). |
| Conservation réglementaire (5-10 ans) | Partitionner les tables de transactions par mois ou trimestre. Les partitions les plus anciennes sont déplacées vers un stockage froid moins coûteux (object store, niveau d'archivage) tout en restant interrogeables via des vues partitionnées ou des moteurs de requête fédérés. |
| Sauvegarde et récupération (DORA) | Récupération point-in-time (PITR) via archivage WAL. Minimum : sauvegarde complète quotidienne et WAL continu. Tests de restauration trimestriels. Objectifs RTO et RPO documentés dans le plan de continuité d'activité, conformément aux exigences DORA. |
| Masquage des données et RGPD / CNIL | Chiffrer les données personnelles au niveau applicatif (AES-256) avant écriture en BD. Masquer les données dans les environnements hors production. Chiffrement au niveau des colonnes pour les champs particulièrement sensibles (IBAN, numéros de carte). Implémenter le droit à l'oubli via suppression logique (pseudonymisation). |
| Contrôle d'accès | Row-Level Security (PostgreSQL RLS) garantit que les rôles applicatifs n'accèdent qu'aux données de leur propre client. Rôles en lecture seule séparés pour le reporting. Accès DBA journalisé et limité dans le temps. |
La règle d'immuabilité simplifie aussi les audits de conformité. Quand l'ACPR ou les auditeurs internes demandent "montrez toutes les transactions du compte X entre la date A et B", la réponse est une requête directe contre la table d'écritures - sans reconstruction depuis des logs, sans inquiétude sur des lignes modifiées. Cette simplicité justifie la discipline de conception de traiter le grand livre comme append-only dès le départ.
Comment Crassula s'intègre
La plateforme bancaire white-label de Crassula est construite sur ces principes. Le grand livre est append-only, en partie double et conforme ACID depuis sa conception. Les soldes de comptes sont maintenus transactionnellement et réconciliés avec le journal d'écritures. Les pistes d'audit sont écrites dans un stockage d'événements immuable et disponibles pour inspection réglementaire sur demande.
Pour les clients lançant de nouveaux produits bancaires ou de paiement en France ou dans d'autres marchés réglementés par l'ACPR, Crassula supprime la nécessité de concevoir et construire cette infrastructure de zéro. La couche de données, le moteur de réconciliation, les politiques de partitionnement et de conservation - tout est inclus dans la plateforme. Les équipes se concentrent sur l'expérience client et la configuration des produits plutôt que sur l'ingénierie des bases de données.
Si vous évaluez l'architecture de base de données pour une construction bancaire centrale, ou si vous examinez si une plateforme white-label convient à vos volumes de transactions et exigences de conformité, l'équipe Crassula est disponible pour approfondir les aspects techniques.
FAQ
Commencez avec le grand livre comme source unique de vérité. Définissez vos entités principales - Client, Compte, Écriture (ligne du grand livre), Transaction et Produit - avec une séparation claire entre elles. Utilisez DECIMAL ou NUMERIC pour toutes les colonnes monétaires. Rendez la table d'écritures append-only dès le premier jour : les corrections arrivent comme de nouvelles écritures d'annulation, jamais comme des mises à jour de lignes existantes. Appliquez des transactions ACID au niveau de la base de données pour chaque mouvement de fonds. Séparez votre chemin d'écriture (OLTP) du chemin de rapports et d'analyses. Intégrez le partitionnement de conservation dès le départ pour que les données plus anciennes puissent être archivées sans changement de schéma.
La comptabilité en partie double signifie que chaque mouvement d'argent produit deux écritures dans le grand livre - un débit sur un compte et un crédit sur un autre pour le même montant. La somme de toutes les écritures est toujours nulle, ce qui rend impossible que de l'argent apparaisse ou disparaisse silencieusement.
L'event sourcing étend cela en stockant le journal ordonné d'événements (chaque écriture) comme enregistrement autoritatif, avec des soldes dérivés en additionnant ce journal plutôt que stockés comme champs mutables. La combinaison fournit une piste d'audit naturelle, des requêtes dans le temps ("quel était le solde à l'instant T ?") et une base pour le reporting réglementaire auprès de l'ACPR ou de l'AMF - sans infrastructure d'audit supplémentaire.
Le sharding est un partitionnement horizontal : distribution des lignes sur plusieurs nœuds de base de données indépendants afin que chaque nœud ne stocke qu'une fraction des données. Une couche de routage (shard map) dirige chaque requête vers le bon nœud.
En banque, vous avez besoin du sharding quand un seul nœud de base de données ne peut plus gérer le pic d'écritures, ou quand le volume de données rend le stockage sur un seul nœud impraticable. Un nœud PostgreSQL bien optimisé traite environ 10.000 à 30.000 transactions par seconde. À des volumes plus élevés, ou quand la résidence des données géographiquement distribuée est nécessaire pour respecter le RGPD ou les règles de l'ACPR, le sharding devient la solution standard.
La clé de shard doit avoir une haute cardinalité - suffisamment de valeurs distinctes pour répartir les données de façon uniforme entre tous les shards. Pour un grand livre bancaire, account_id ou customer_id sont les choix naturels : toutes les écritures d'un compte tombent sur le même shard, rendant les requêtes mono-compte rapides et sans jointures inter-shards.
Évitez de fragmenter par des champs à faible cardinalité (devise, pays, statut) - ils créent des hot-spots. Évitez les entiers auto-incrémentaux séquentiels comme clé de shard à fort volume de création de comptes ; utilisez des UUIDs v4 ou des IDs snowflake à la place. Planifiez généreusement votre nombre de shards au lancement - re-fragmenter un grand livre en production sans interruption de service est l'une des opérations les plus complexes en ingénierie fintech.
Au sein d'un seul shard, les transactions ACID standard maintiennent la cohérence. Le problème difficile est celui des transactions inter-shards - par exemple, un virement entre deux comptes résidant sur des shards différents.
Les approches standard sont : le patron saga (une séquence de transactions locales coordonnées par un orchestrateur de sagas ou une chorégraphie via des événements, avec des transactions compensatoires pour le rollback), et le Two-Phase Commit (2PC) entre nœuds (rarement utilisé dans les systèmes à haut débit en raison de la latence et du risque de défaillance du coordinateur). La plupart des grands livres fintech de production utilisent les sagas, avec une clé d'idempotence sur chaque opération pour que les nouvelles tentatives après un échec partiel soient sûres.
