Technologie financière —
Paiements / finance réglementée

Le grand livre existant du client avait été greffé sur l'instance PostgreSQL opérationnelle dès le premier jour. Règlements, remboursements, versements aux partenaires et soldes des clients écrivaient tous dans les mêmes tables qui servaient l'application, sans invariant en ajout seul et sans piste d'audit distincte. L'audit de l'organisme de réglementation a relevé quatre défaillances concrètes : les transitions d'état n'étaient pas systématiquement enregistrées avec l'acteur qui les avait initiées, les calculs de solde dépendaient d'une jointure qui pouvait perdre des lignes en silence sous charge, les périodes de conservation étaient incohérentes d'une table à l'autre, et la posture de récupération à partir d'un instantané corrompu n'avait pas été testée.

Pire, l'équipe qui avait bâti le grand livre était partie depuis. Le savoir institutionnel sur la raison d'être de chaque raccourci était parti avec elle. PLACEHOLDER : confirmer l'échéancier de transition de l'équipe avec le client avant toute publication externe.

La posture de SDEN sur les grands livres financiers est explicite : en ajout seul par construction, en partie double par principe comptable, isolé de la base de données opérationnelle, et conçu pour l'audit avant que l'audit ne soit planifié. La migration s'est déroulée en quatre phases, chacune avec un point de validation contrôlé que le client pouvait opposer son veto.

1. Phase 1 — Cadrage et modèle de menaces

   Deux semaines. Nous avons cartographié chaque transition d'état que le grand livre existant produisait, repéré les sept que l'organisme de réglementation traiterait comme critiques pour l'audit, et rédigé le modèle de menaces autour d'elles. Résultat : une taxonomie d'événements typée, un schéma cible, et un registre des risques que le directeur financier du client a signé.

2. Phase 2 — Construction du grand livre en ajout seul

   Huit semaines. Nouveau grand livre dans une grappe PostgreSQL distincte avec des invariants stricts en ajout seul imposés à la base de données et à la couche applicative, comptabilisation en partie double, journal d'audit immuable diffusé vers une destination isolée, et clés de chiffrement par locataire pour les comptes de grande valeur.

3. Phase 3 — Migration à double écriture

   Dix semaines. Chaque écriture vers le grand livre existant était dupliquée vers le nouveau, avec une réconciliation continue. Les écarts étaient investigués et corrigés à la source, pas rafistolés. La fenêtre de double écriture est restée ouverte assez longtemps pour absorber le cycle complet de réconciliation que le client exécute mensuellement avec ses partenaires bancaires.

4. Phase 4 — Basculement et répétition d'audit

   Six semaines. Les chemins de lecture ont migré vers le nouveau grand livre derrière des drapeaux de fonctionnalité. Le basculement des écritures a eu lieu un samedi avec l'équipe des opérations dans une salle de crise dédiée. La répétition d'audit a exécuté les requêtes attendues de l'organisme de réglementation contre le nouveau grand livre et a produit le dossier de preuves exact que l'équipe d'audit a réclamé le mois suivant.

L'audit a réussi du premier coup. PLACEHOLDER : confirmer l'organisme d'audit et le cadre réglementaire avant toute publication externe — le mandat était cadré selon les attentes d'une autorité de surveillance financière européenne équivalentes à l'AMF / l'ACPR / l'ESMA.

Sur le plan opérationnel, le cycle de réconciliation que l'équipe exécutait manuellement chaque mois est devenu un processus quotidien automatisé. Le facteur d'autobus sur le savoir du grand livre est passé d'un ingénieur à quatre. La base de code est dans les dépôts du client avec une documentation rédigée pour le prochain ingénieur qui se joint à l'équipe — pas pour le chef de projet qui a cadré le mandat.