Spliz

Réveillon 2025, Montréal. Je dois 47 dollars canadiens à mon hôte. Le tracker de dépenses a fait son travail, le calcul est juste, tout le monde est d’accord. Puis vient le paiement. « Tu prends Wero ? » « C’est quoi ? » « Pix peut-être ? » « Moi j’utilise Interac. » Vingt minutes plus tard, on abandonne et on dit qu’on réglera ça plus tard. On ne l’a jamais réglé.

Le calcul n’a jamais été le problème. Le problème arrive juste après : quelqu’un avance, deux remboursent tout de suite, un promet demain, un disparaît. Une semaine plus tard tu relances, un mois plus tard tu laisses tomber. Multiplié par dix voyages et deux ans de colocation, c’est le vrai prix du « on règle ça plus tard ».

Les rails de paiement sont fragmentés par frontière. Wero en Europe, Pix au Brésil, Interac au Canada, Zelle aux États-Unis. Aucun ne se parle. J’ai commencé à coder Spliz le 15 janvier 2026.

La commande

Aucune. C’est mon produit, ma thèse, mon budget. J’ai tout tenu seul pendant sept mois : le produit, l’application mobile, l’API, le smart contract, l’infrastructure de production, la conformité, la landing page.

Le parti pris tient en une phrase : ne pas construire un tracker de plus, mais régler la partie qui casse, le règlement. Avec un stablecoin comme rail neutre, qui se comporte pareil à São Paulo, Toronto et Paris.

• React Native 0.83
• Expo 55
• NestJS 11
• PostgreSQL
• Solidity 0.8.24
• Foundry
• Base
• USDC
• Privy
• Next.js 16

La contrainte

Je voulais que l’expérience se résume à un bouton : « Régler ». Derrière ce bouton, il fallait faire tenir une mécanique de consensus cryptographique multi-parties, la regrouper en une seule transaction, garder la sécurité, et ne jamais devenir dépositaire de l’argent des gens.

Cinq étapes, deux standards de signature, une seule transaction. L’utilisateur ne détient jamais d’ETH, ne voit jamais d’écran d’approbation, et ne peut pas se retrouver dans un groupe à moitié réglé.Sept types de signatures cohabitent dans le produit, du règlement on-chain à l’authentification.

La décision

Un groupe est vivant. Pendant que deux membres signent, un troisième corrige une dépense. La question à trancher : qu’est-ce qui invalide les signatures déjà collectées ?

J’ai posé la règle. Toute modification qui change le solde net d’un membre, son « je dois » ou son « je récupère », est non cosmétique. Elle invalide les signatures, et les membres concernés sont notifiés. Tout le reste passe sans friction.

C’est ce qui permet aux gens du réveillon, rentrés au Canada, en France et au Brésil, d’éditer le même groupe en même temps sans que personne ne signe un montant qui n’existe plus.

Le détail qui fait mal

L’USDC a six décimales. Les devises fiat en ont deux. Tout l’affichage multi-devise se joue dans cet écart, et un arrondi mal placé dans un chemin de signature produit un montant signé qui ne correspond pas au montant affiché.

La réponse tient en un invariant : l’affichage n’est jamais la source de vérité. Une seule représentation canonique, un entier en micro-unités, de la base de données jusqu’à la signature et au contrat. La somme des parts affichées peut dériver d’un centime ; la somme des micro-unités est strictement égale au total.

Je ne me suis pas contenté de corriger les cas trouvés. J’ai écrit des tests de garde qui échouent la CI si quelqu’un réintroduit le motif : toute multiplication flottante par un million dans un chemin de signature, toute conversion aller-retour qui perd de la précision, tout affichage qui lirait la mauvaise source. La classe de bug est fermée, pas les occurrences.

Le design

Le design est de moi. Je cherchais du sobre, noir et blanc, sans être neutre : une combinaison de liquid glass, de nacre, d’obsidienne et de caustiques. Le bouton principal est rendu avec React Skia.

Le même invariant que dans le code remonte jusqu’à la typographie. Sur l’écran de portefeuille, le solde en euros s’affiche en grand, précédé d’un signe « environ ». Le montant exact en USDC est juste en dessous, en petit. La valeur locale dépend d’un taux de change du jour, elle annonce donc qu’elle est approchée. La valeur exacte, celle qui sera signée et transférée, reste lisible.Le marqueur « environ » est réservé aux surfaces portefeuille. Il n’apparaît jamais sur un montant USDC exact.

Une interface financière doit dire ce qu’elle sait et ce qu’elle approxime.

Ce qui a été dur autrement

Toucher au vrai argent des gens me faisait peur au début. Cette peur a produit le reste : la double vérification des signatures côté API puis on-chain, les gardes de CI sur les montants, l’effacement des credentials de permit dès que le règlement est confirmé, le non-custodial tenu de bout en bout. J’ai passé un temps considérable sur la conformité, et je suis allé voir un avocat plutôt que de deviner.

Ce rendez-vous a produit deux choses. Il m’a confirmé que rester non-custodial de bout en bout tenait debout : tant que l’utilisateur garde ses clés et que Spliz ne peut jamais déplacer les fonds seul, le périmètre reste gérable pour une personne seule. La ligne rouge a un nom, c’est la custody.

Et il m’a fait reporter une fonctionnalité. Je voulais faire travailler les soldes qui dorment et rendre 4 % à mes utilisateurs, via du lending. Techniquement c’est à portée. Réglementairement, servir un rendement change la nature du produit. J’ai reporté la décision plutôt que de la prendre à l’instinct.

Ce que le terrain a changé

La v1 marche, alors je vais la montrer. EthCC, où je confronte le produit aux gens à qui il est destiné, pas à ceux qui trouvent l’idée sympathique. La Paris Blockchain Week, salle nettement plus institutionnelle, et des side events qui valent mieux que le programme principal. VivaTech. Et l’école 42, où je pitche Spliz devant plus de cent cinquante personnes.

Personne ne parle du règlement. Il marche. Ce qui revient, c’est tout ce qu’il y a autour. Un groupe de voyage, une coloc et une équipe n’ont pas les mêmes besoins. Les gens appartiennent à une dizaine de groupes. Et dans chacun, l’argent reste géré individuellement.

Il existe plus de groupes que d’humains, et aucune banque ne prend le groupe comme objet. Chaque personne a un compte ; un groupe a une conversation et un tableur.

Le règlement couvrait l’après. Restent l’avant et le pendant : une cagnotte commune avec ses règles, et une carte qui répartit au moment où le groupe paie.Une thèse que personne n’a contredite dans une salle n’est pas une thèse testée. Il faut la salle.

L’état

Le contrat tourne sur Base mainnet. L’application est publiée sur l’App Store et sur le Play Store. L’infrastructure est en production : hébergement, edge, gestion des secrets et des clés, observabilité, analytics. 750 tests côté API, 810 côté mobile.

Spliz est lancé depuis août 2026, et les premiers règlements réels sont passés, en petit comité. C’est un produit fini avant d’être une entreprise qui marche : le travail qui reste devant moi est un travail de distribution. La roadmap est publique et le projet se construit en public.