Sécurité et confiance
Nous avons recalculé chaque écriture de zéro. Elle s'est réconciliée à zéro.
La confiance dans une infrastructure monétaire doit se gagner avec des preuves. Voici les nôtres : un audit indépendant du registre brut, les invariants que nous garantissons, notre posture de sécurité, et un compte rendu honnête de ce qui n'est pas encore prêt pour la production.
L'audit indépendant
Pas le propre vérificateur du logiciel, les tables brutes.
Le 2026-08-18, les livres ont été recalculés directement à partir des enregistrements bruts de la base de données, en contournant délibérément le vérificateur intégré du système (un vérificateur et le code qu'il vérifie peuvent partager le même angle mort). Chaque contrôle de conservation, de réconciliation, d'autorisation et de cycle de vie a retourné zéro exception.
Audit SQL indépendant, 2026-08-18. Les contrôles de conservation, de réconciliation, d'autorisation et de cycle de vie ont tous retourné zéro sur 5 registres.
Soldes en cache comparés aux soldes recalculés depuis l'historique complet. Dérive absolue totale : 0.
Enregistrements du domaine réconciliés avec les écritures du registre sur le nombre et le montant. Zéro octroi manquant, dupliqué ou non positif.
Test de performance synthétique, hôte unique, architecture à registre séparé (2026-08-14). Un paiement correspond à une autorisation plus une capture. Les invariants d'exactitude ont tenu tout du long.
Ce qui a été contrôlé, sur 5 registres
- 2,284,416 transactions, zéro déséquilibrée, zéro écriture à ligne unique.
- Balance de vérification exactement nulle dans les deux devises, sur tous les registres.
- 7,463 comptes, les soldes en cache correspondaient au recalcul sur l'historique complet avec zéro dérive.
- La projection de reporting s'est réconciliée écriture par écriture entre deux bases de données (5,454,688 = 5,454,688).
- 1,394,739 octrois de récompense concordaient avec le registre sur le nombre et le montant, zéro manquant, dupliqué ou non positif.
- 22,028 revendications de limite, zéro plafond dépassé ; zéro compte au-delà de son plancher.
Une seule constatation, divulguée : les remboursements sont enregistrés sous forme d'écritures de contre-passation avec une référence plutôt que par un lien de réversion, si bien que la mécanique de réversion reste inexploitée. Une lacune de documentation, pas un défaut, et désormais documentée.
Garanties
Des propriétés que le système garantit par conception.
Équilibré par construction
Chaque transaction écrit des lignes dont la somme est nulle par devise. La balance de vérification sur tous les registres est exactement nulle, dans chaque devise.
Rejeu idempotent
Chaque appel de mouvement d'argent porte une clé d'idempotence et se rejoue octet par octet. N doublons concurrents déplacent l'argent exactement une fois.
Les plafonds tiennent sous charge
Les totaux de remboursement, la vélocité d'envoi et les plafonds de récompense sont revendiqués à l'intérieur de la transaction d'écriture. Huit envois contre une limite de cinq en aboutissent exactement à cinq.
Facturation au plus une fois
Les charges d'abonnement dérivent leur clé d'idempotence de la période, si bien qu'une tempête de nouvelles tentatives ne peut pas facturer en double.
Posture de sécurité
Durcie là où ça compte.
Les identifiants, les conteneurs et les surfaces de paiement sont conçus pour réduire le rayon d'impact, et chaque correctif issu de nos revues adverses est accompagné d'un test de non-régression.
- Les données de carte ne touchent jamais la plateforme, la portée PCI reste au niveau SAQ-A, les rechargements passent par les champs propres au processeur.
- Clés d'API hachées avec Argon2id et affichées exactement une fois ; jetons utilisateur RS256 à courte durée de vie avec rotation JWKS à chaud, sans redémarrage.
- Comparaisons d'identifiants à temps constant, plafonds de corps de requête à 1 MiB, SQL paramétré partout.
- Les cibles de webhook sont contrôlées contre le SSRF : hôtes publics uniquement, aucune redirection suivie.
- Les conteneurs sont distroless, non-root, système de fichiers racine en lecture seule, toutes les capacités Linux retirées.
- Deux revues de sécurité adverses documentées, chaque correctif accompagné d'un test de non-régression.
La partie honnête
Ce qui n'est pas encore prêt pour la production.
Nous sommes en pré-production, et nous le disons officiellement. Si un fournisseur refuse de vous dire ses lacunes, soit il ne les connaît pas, soit il ne veut pas les partager. Voici les nôtres.
- Il s'agit d'une version en accès anticipé. La plateforme n'a pas encore transporté d'argent réel de clients.
- Tous les chiffres de performance et de réconciliation proviennent d'une charge synthétique sur un hôte unique, pas d'un trafic de production.
- L'entrée d'argent en service passe aujourd'hui par Stripe ; les versements aux marchands sont exécutés sur un canal manuel avec références enregistrées.
- La limitation de débit se fait actuellement par IP ; la propagation d'identité par tenant est en cours.
- Durcissement en cours avant la disponibilité générale : stockage de clés géré (KMS), déploiement d'identité en production, sécurité au niveau des lignes de la base de données, et sauvegarde et récupération à un instant donné répétées.
Nous partageons le backlog de durcissement détaillé et le rapport d'audit avec les partenaires de conception sous NDA.
Accès anticipé
Mettez les livres à l'épreuve.
Apportez votre question de réconciliation la plus ardue. Nous préférons gagner votre confiance face à des preuves plutôt qu'à un argumentaire.