Ce POC (Proof of Concept) était un travail demandé par l'IUT avant le début de l'alternance, pour évaluer la capacité à concevoir et exploiter une base de données relationnelle dans un contexte métier réaliste. J'ai choisi le domaine bancaire, en lien avec le secteur d'Euro Information où j'allais démarrer.
L'objectif était de livrer un modèle MySQL complet et documenté, avec des contraintes métier, de l'historisation automatique, et un test de montée en charge.
La base couvre un périmètre bancaire réaliste : banques, clients, comptes et opérations, plus un ensemble de référentiels (devises, types de compte, statuts, types d'opération, codes MCC).
| Table | Contenu |
|---|---|
banque |
Branches et filiales |
client |
Clients avec KYC, coordonnées, rattachement à une banque |
compte |
Comptes (COURANT / EPARGNE), IBAN, devise, statut, découvert |
operation |
Transactions (CB, ATM, VIR_SEPA, POS, FRAIS...) avec sens et MCC |
| Référentiels | ref_devise, ref_type_compte, ref_statut_compte, ref_type_operation, ref_mcc |
Tables *_historique |
Une table miroir par table principale pour l'historisation |
Le moteur utilisé est InnoDB pour les transactions ACID et les clés étrangères. Des contraintes CHECK sont posées sur le format IBAN et le format email. Des index sont définis sur les colonnes les plus interrogées (client par nom, opérations par compte et date, etc.).
Trois versions du schéma ont été produites : une base minimale pour poser la structure, une version laxiste pour les tests, et une version pro avec toutes les contraintes activées.
Chaque table principale dispose de deux triggers AFTER UPDATE et AFTER DELETE qui copient automatiquement l'ancienne version de la ligne dans la table *_historique correspondante, avec horodatage (op_le) et utilisateur MySQL auteur de l'action (op_user).
Cela permet de reconstituer l'historique complet de toute modification ou suppression sans aucune intervention manuelle. Par exemple, modifier le découvert autorisé d'un compte archive immédiatement l'ancienne valeur dans compte_historique.
Au total, c'est plus d'une vingtaine de triggers déployés couvrant les tables métier et les référentiels.
Deux triggers BEFORE INSERT et BEFORE UPDATE sur la table operation bloquent toute transaction dont la devise ne correspond pas à celle du compte associé. Si la devise est incohérente, un SIGNAL SQLSTATE est levé et l'opération est rejetée directement en base, indépendamment de la couche applicative.
Pour valider les performances du modèle sur des volumes réalistes, des jeux de données massifs ont été générés via un script Python et des scripts PowerShell, puis injectés dans la table operation.
| Volume | Outil | Résultat |
|---|---|---|
| 10 000 000 lignes | PowerShell | Chargé avec succès |
| 100 000 000 lignes | Python | Chargé avec succès |
Les captures d'écran des résultats sont incluses dans le ZIP ci-dessous.
Cahier des charges - Définit le périmètre métier, les règles de gestion et les exigences fonctionnelles.