ZeniPay : un grand livre financier que personne ne peut réécrire, pas même nous.

Ce qu'on a construit

Une application Next.js 14 de 133 pages et 198 routes d'API, sur une base Postgres d'environ 70 tables protégées par 58 politiques de sécurité au niveau des lignes. Neuf tâches planifiées tournent seules : synchronisation des soldes et des comptes, expiration des approbations, signaux d'anomalie. Le code est couvert par 24 fichiers de tests automatisés.

Les quatre décisions qui rendent l'argent traçable

• Un grand livre en ajout seul. Des règles Postgres refusent toute modification ou suppression d'une écriture : une erreur se corrige par une écriture inverse, jamais en effaçant. Les soldes ne sont pas stockés, ils sont calculés à partir du grand livre.
• Des clés d'idempotence. Chaque paiement et chaque versement porte une clé unique : si la même requête arrive deux fois, à cause d'un réseau lent ou d'un double clic, elle n'est traitée qu'une fois.
• Des mises à jour de solde atomiques. Les opérations sur les soldes passent par des fonctions de base de données qui lisent et écrivent d'un seul geste, ce qui élimine les courses entre deux requêtes simultanées.
• Un journal d'audit signé. L'export d'audit est scellé par un arbre de Merkle et signé avec une clé Ed25519 : un vérificateur peut confirmer hors ligne que rien n'a été retiré ni modifié.

Ce que ça vous apprend si vous faites construire

Si votre logiciel encaisse, verse ou partage de l'argent, posez trois questions au fournisseur : peut-on modifier une transaction passée, que se passe-t-il si un paiement est envoyé deux fois, et comment prouve-t-on à un vérificateur que l'historique est complet. Ces trois réponses se décident au premier jour ; les ajouter après coûte beaucoup plus cher.

Autres réalisations