Dans la plupart des logiciels, un bug est un incident. En fintech, un bug est un passif qui a peut-être déjà coûté de l'argent sans que personne s'en soit aperçu.
L'architecture fintech comporte un petit nombre de décisions réellement non négociables. Se tromper dessus, et aucune ingénierie ultérieure ne rattrape complètement le coup — vous héritez d'un système où l'argent peut être silencieusement faux, le seul mode de défaillance qu'un produit financier ne peut pas absorber.
1. Les soldes sont dérivés, jamais stockés comme vérité
L'erreur la plus fréquente et la plus destructrice est une colonne de solde modifiable que le code met à jour directement. C'est commode, rapide et irrécupérable : quand elle dérive, il n'y a aucun moyen de déterminer ce qu'elle aurait dû être.
Le modèle correct est un journal d'écritures en append-only. Rien n'est jamais mis à jour ni supprimé ; les corrections sont de nouvelles écritures compensatoires. Le solde est la somme des écritures, mise en cache pour la performance mais toujours reconstructible depuis le journal.
| Solde modifiable | Grand livre append-only |
|---|---|
| UPDATE accounts SET balance = balance - 100 | INSERT écriture (débit 100), INSERT écriture (crédit 100) |
| Historique perdu à chaque écriture | Historique complet par construction |
| La dérive est indétectable et irréparable | Tout état reproductible à n'importe quel instant |
| Les bugs de concurrence corrompent l'état définitivement | L'invariant de la partie double attrape les erreurs |
| Auditer, c'est lire les logs applicatifs | Auditer, c'est lire le grand livre |
2. Tout chemin monétaire est idempotent
Les réseaux réessaient. Les utilisateurs double-cliquent. Les prestataires de paiement livrent les webhooks plus d'une fois — c'est un comportement documenté, pas un cas limite. Toute opération qui déplace de l'argent doit pouvoir s'exécuter plusieurs fois sans danger.
- Chaque opération monétaire porte une clé d'idempotence fournie par l'appelant, unique par intention logique
- La clé est stockée avec une contrainte d'unicité avant les effets de bord, pas après
- Une clé répétée renvoie le résultat d'origine plutôt que de refaire le travail
- Les handlers de webhook stockent la charge brute indexée par l'identifiant d'événement du prestataire, puis traitent — ainsi une relivraison est reconnue même en cours de traitement
3. L'argent, ce sont des entiers en unités mineures
Le flottant ne peut pas représenter exactement les fractions décimales, donc l'arithmétique sur de l'argent en flottant accumule l'erreur. Stockez les unités mineures en entiers (ou en type décimal à précision fixe), et rendez la devise explicite sur chaque montant — un montant sans devise est un bug qui attend son premier client international.
4. La réconciliation est une fonctionnalité, pas une pensée après coup
Partez du principe qu'il y aura divergence entre votre grand livre et le prestataire de paiement — cela arrivera, via des timeouts, des échecs partiels et des corrections côté prestataire. La question est de savoir si vous la détectez.
- Un job planifié comparant l'état interne aux données de règlement du prestataire
- Une alerte sur écart, avec un responsable défini et un runbook
- Un chemin de résolution défini — écritures compensatoires, jamais d'ajustement silencieux
- Des balayages d'états bloqués : transactions en attente plus longtemps qu'elles ne devraient
5. Isolation, dans les deux sens
- Isolation des tenants — imposée au niveau des données, pas en espérant que chaque requête contienne le bon filtre
- Isolation des pannes — un prestataire lent ne doit pas épuiser le pool de requêtes et faire tomber des fonctionnalités sans rapport
- Isolation des environnements — jamais de transactions de test dans les grands livres de production
6. Construisez pour l'audit que vous finirez par subir
Non. Il fournit des constats techniques dans le périmètre convenu. L'interprétation juridique et la certification formelle nécessitent les intervenants qualifiés correspondants.
- Piste d'audit immuable de qui a fait quoi et quand — y compris les actions d'administration internes
- Les données de carte ne touchent jamais vos serveurs, sauf si vous voulez réellement être conforme PCI (utilisez des champs hébergés ou une page hébergée)
- Une rétention et une suppression des données réellement exécutables sur demande
- Un contrôle d'accès auditable — qui peut déplacer de l'argent, qui l'a approuvé
Dans un logiciel ordinaire, on optimise la vitesse de changement. En fintech, on optimise la capacité à prouver, plus tard, exactement ce qui s'est passé et pourquoi.
Les cinq questions à poser à votre propre système
- Si ce webhook arrive deux fois, quelque chose change-t-il la seconde fois ?
- Puis-je reconstruire le solde de n'importe quel client à n'importe quel instant passé à partir du seul grand livre ?
- Détecterions-nous un écart avec le prestataire, ou un client nous le dirait-il ?
- Une requête forgée peut-elle lire ou déplacer l'argent d'un autre tenant ?
- Si un régulateur demandait qui a approuvé un ajustement manuel en mars dernier, pourrions-nous répondre en quelques minutes ?
Distinguer acceptation et règlement d'une transaction
Les états doivent permettre le rapprochement d'événements retardés ou répétés. Vérifier écritures et procédure de correction.
- Utiliser des décimales exactes ou unités entières avec règles par devise.
- Corréler événements et écritures sans comptabiliser deux fois une répétition.
- Conserver les originaux et tracer les corrections autorisées.
Questions fréquentes
Faut-il un grand livre en partie double pour un produit fintech simple ?
Si vous détenez des soldes ou déplacez de l'argent pour le compte d'utilisateurs, oui. Le journal en append-only n'est pas une formalité comptable — c'est ce qui rend l'état reconstructible et les erreurs détectables. L'ajouter après que les soldes ont dérivé est bien plus difficile que de commencer avec.
Quel est le défaut sérieux le plus fréquent dans les systèmes fintech précoces ?
Des soldes modifiables sans journal, suivis de près par l'absence d'idempotence sur les chemins de paiement et de webhook. Les deux permettent à l'argent de devenir silencieusement faux, le mode de défaillance le plus difficile à détecter et à corriger après coup.
Devons-nous stocker nous-mêmes les données de carte ?
Presque certainement non. Utilisez les champs hébergés ou la page de paiement hébergée d'un prestataire pour que les données de carte n'atteignent jamais vos serveurs. Les traiter vous-même fait entrer toute votre infrastructure dans le périmètre PCI DSS, ce qui représente une charge de conformité et d'audit permanente et lourde.
Quand une startup fintech doit-elle faire un audit d'architecture ?
Avant la première hausse significative de volume, et avant toute levée où une due diligence technique est attendue. Les décisions structurelles ci-dessus sont peu coûteuses à vérifier tôt et coûteuses à corriger une fois que de l'argent réel a transité par le système.
Toutes les devises ont-elles deux décimales ?
Non. Définir précision et arrondi selon devise et opération, puis vérifier les exigences du fournisseur. Éviter les flottants binaires lorsque le calcul décimal doit être exact.
Envie de vérifier tout cela sur votre système ?
Nous auditons l'architecture fintech exactement contre cette liste — intégrité du grand livre, idempotence, réconciliation, isolation.
Pour aller plus loin
Due diligence technique pour investisseurs : le guide complet
La due diligence technique n'est pas une revue de code. C'est la réponse à une question : combien coûtera-t-il d'amener cette technologie là où la thèse d'investissement en a besoin ?
Audit d'architecture système : quand il en faut un et ce qu'il trouve
Un audit d'architecture n'est pas un avis sur votre stack technique. C'est une carte des endroits où le système casse sous le plan que vous avez réellement.