Du « tu me dois combien ? » au règlement en une transaction

Dimanche soir. Quatre amis rentrent de week-end. Camille a réservé le logement, Alex a fait les courses, Lou a payé le parking. Sam demande combien envoyer.

Les personnages et les montants sont inventés. Faisons les comptes. Pour suivre les mêmes montants jusqu’au paiement, les dépenses de notre exemple sont déjà exprimées en USDC, le jeton utilisé pour régler dans Spliz.

Camille a avancé 120. Alex, 60. Lou, 20. Sam n’a rien avancé. Le total est de 200 USDC, partagé également : 50 par personne.

Camille doit donc recevoir 70 et Alex 10. Sam doit payer 50, Lou 30.

Sam connaît maintenant le montant. Il lui manque encore le destinataire. Et Camille vient de retrouver un ticket dans sa poche.

En construisant Spliz, nous avons dû donner une place à chacun de ces moments. Le ticket retrouvé, le montant accepté, l’argent envoyé. Ils peuvent se suivre en quelques secondes ou rester séparés pendant des semaines. L’application doit savoir où le groupe en est.

Quatre soldes, trois transferts

Pour régler les comptes actuels, le groupe pourrait exécuter ces remboursements :

Après ces trois transferts, chacun aura supporté sa part de 50 USDC. Sur les 200 dépensés pendant le week-end, seuls 80 doivent encore circuler. Les frais éventuels du règlement sont laissés de côté dans ce premier calcul.

Ce mécanisme s’appelle la compensation. On calcule ce que chacun a avancé, on retranche sa part, puis on rapproche les personnes qui doivent payer de celles qui doivent recevoir.

Il existe plusieurs façons de construire les transferts. Réduire le montant total qui circule et réduire leur nombre sont deux objectifs distincts. Le mémoire de David Vávra (2012) décrit un algorithme en au plus N−1 transferts pour N participants, sans garantir le minimum.

Ce travail existe depuis longtemps. En 2018, Adrien Arcuri décrivait déjà un contrat Ethereum de partage de dépenses, avec accords des participants et remboursements en Ether.

Ces précédents posent les bases. Dans notre exemple, le calcul tient sur quelques lignes. Pour envoyer les 80 USDC, il manque encore quelque chose que le calcul ne peut pas produire.

Le montant affiché n’autorise aucun prélèvement

Supposons que Sam accepte de payer ses 50 USDC. Avant le règlement, Camille ajoute son ticket oublié : 40 USDC pour le groupe. La part de chacun augmente de 10. Sam doit désormais 60.

Son accord pour 50 ne vaut évidemment pas pour 60.

Il faut donc préciser ce que signifie « confirmer ». Dans Spliz, l’accord de règlement prend la forme d’un message signé. Il contient notamment l’identifiant du Spliz, le participant, son rôle de payeur ou de bénéficiaire, son montant et un plafond de frais. Un horodatage borne sa durée de validité.

Le format utilisé, EIP-712, décrit comment signer des données structurées. Un contrat, le programme qui exécutera le règlement sur Base, peut vérifier l’auteur du message et détecter une modification des champs signés. Le contexte de signature désigne aussi le réseau et le contrat concernés.

Une dépense saisie dans l’application n’est donc jamais, à elle seule, une permission de déplacer des fonds.

Dans le parcours applicatif, une modification qui change les soldes remet les confirmations à zéro. Le groupe doit accepter le nouveau calcul. Cette invalidation relève du serveur : supprimer une confirmation de la base ne fait pas disparaître les octets d’une signature déjà créée.

La séparation mérite d’être explicite. Le contrat vérifie les autorisations et la cohérence des transferts qui lui sont présentés. Il ne lit pas le ticket de Camille et ne recalcule pas toutes les dépenses. Relier le registre au règlement reste une responsabilité de l’application.

L’autorisation de dépenser arrive en second

Revenons au calcul initial, avant le ticket oublié. Sam accepte 50, Lou 30, Camille attend 70 et Alex 10.

Le contrat connaît leurs accords. Il lui faut aussi le droit de transférer les USDC des payeurs.

Cette seconde autorisation passe par un permit, selon le standard ERC-2612. Sam et Lou signent une permission de dépense pour le contrat, avec un montant et une échéance. Le montant couvre leur remboursement et les frais applicables. Un compteur empêche de soumettre indéfiniment le même permit.

Il y a donc deux objets signés côté payeur : son accord sur le règlement et l’autorisation de dépense du jeton. Ce détail compte quand on explique ce que recouvre un bouton de confirmation.

Ces signatures se produisent hors chaîne. Les amis peuvent confirmer à des moments différents. Un serveur, appelé relais, rassemble les signatures nécessaires puis soumet la transaction au réseau Base. Il paie les frais réseau, ou gas, pour cette opération.

Les USDC restent dans les portefeuilles des participants jusqu’au transfert. Ce règlement n’exige aucun dépôt préalable dans une cagnotte commune.

1. L’application calcule les soldes à partir des dépenses.
2. Les participants approuvent le règlement. Les payeurs ajoutent leur permit.
3. Le relais transmet les autorisations au contrat sur Base.
4. Le contrat les vérifie, puis exécute les transferts dans la même transaction.

Prendre en charge le gas ne rend pas tous les coûts inexistants. La version décrite ici applique 0,1 % du montant transféré, avec un minimum de 0,10 USDC. Notre exemple de 80 USDC entraîne donc 0,10 USDC de frais supplémentaires, répartis entre les payeurs. Acheter des USDC ou les reconvertir peut aussi coûter de l’argent.

Le dernier transfert peut annuler les précédents

Imaginons que Lou ne dispose plus que de 25 USDC au moment de l’exécution. Le contrat commence les transferts. Les 50 de Sam passent. Les 20 de Lou vers Camille passent aussi. Il reste 5 à Lou : le transfert de 10 vers Alex échoue.

Dans le règlement atomique de Spliz, cet échec annule les effets des transferts précédents de la même transaction. Camille ne conserve pas une partie du règlement pendant qu’Alex attend le reste.

C’est le sens précis d’un règlement atomique : les transferts de cette transaction aboutissent ensemble ou aucun n’est conservé. Le gas consommé par une transaction échouée reste, lui, à la charge du relais.

Le contrat contrôle les signatures avant d’exécuter les transferts. Il vérifie aussi que les montants envoyés et reçus correspondent aux accords, que les participants ne sont pas dupliqués et que ce Spliz n’a pas déjà été réglé. Les USDC passent directement du portefeuille du payeur à celui du bénéficiaire.

Une seule transaction contient ainsi plusieurs transferts. Les regrouper réduit aussi le nombre de transactions à soumettre, mais la propriété recherchée ici est surtout leur résultat commun.

Un autre détail se voit moins dans une démonstration : le téléphone peut perdre sa connexion après l’envoi. Son silence ne dit rien du résultat sur Base. L’application doit retrouver la transaction et vérifier son état avant d’afficher un succès ou de préparer une nouvelle tentative.

La signature, l’envoi et la confirmation sont trois étapes différentes. Les confondre peut faire afficher « payé » alors que rien n’a encore abouti.

Le paiement a eu lieu. Le zéro ne suffit plus.

Après un remboursement, le solde de Sam devient nul. Le lendemain, il veut quitter le Spliz.

Une règle paraît raisonnable : une ligne à zéro ne porte plus de dette, on peut la supprimer. C’est l’une des difficultés rencontrées pendant la conception du registre de Spliz.

Le même zéro peut pourtant raconter deux histoires. Sam a remboursé 50 USDC. Une autre personne n’a jamais eu de dépense ni de paiement. Si la suppression ne regarde que le solde, elle traite ces situations de la même manière.

Pour Sam, la ligne contient une preuve qu’il a intérêt à retrouver. Dans deux semaines, si Camille pense qu’il manque un remboursement, il doit pouvoir montrer ce qui s’est passé.

Il faut conserver les événements qui expliquent le solde. Une dépense décrit une avance et une répartition. Un paiement décrit un mouvement d’argent. Le solde se calcule à partir de ces éléments ; il ne peut pas les remplacer.

Cette distinction change aussi la manière de corriger une erreur. Si le groupe revoit une répartition après un remboursement individuel, le paiement déjà effectué compte toujours. Le nouveau calcul doit partir de ce fait.

Vávra relève aussi 25 % d’opérations modifiées, sur ses observations de février à avril 2012. Pour Spliz, la place des corrections sera à mesurer sur le terrain.

Le contrôle que nous utilisons désormais est concret : après une action, une personne peut-elle encore retrouver le montant qu’elle doit, son destinataire et ce qui l’explique ? Quand l’une de ces réponses disparaît, le modèle a perdu quelque chose.

La blockchain s’arrête au bord du ticket

Le ticket oublié de Camille peut être exact. Il peut aussi contenir un achat personnel. Aucune signature ne tranche cette question.

Un contrat exécute des autorisations selon des règles. Il ne sait pas qui était à table. Il ne fournit pas non plus les fonds d’un participant qui manque d’argent, et n’oblige personne à confirmer.

Dans un article de 2017 sur les retards de paiement, Matteo Pelati proposait de compenser des dettes entre entreprises. L’intuition réduit le besoin d’argent lorsque des obligations se compensent. Les montants qui subsistent exigent toujours un paiement.

Pour notre groupe, attendre tous les accords a donc un coût : le règlement collectif dépend du dernier participant prêt à payer. C’est une raison de garder un chemin de remboursement individuel.

La même exigence vaut pour les paiements extérieurs. Si Lou rembourse en espèces, l’application peut enregistrer sa déclaration. Elle ne doit pas présenter cette déclaration comme un transfert qu’elle aurait observé sur le réseau. Le lecteur de l’historique doit comprendre ce que chaque ligne atteste.

Les autres dépendances existent aussi. Spliz utilise un serveur pour son registre et un relais autorisé pour soumettre les règlements. Le contrat peut être mis en pause. Les transferts sur une chaîne publique sont visibles. Une adresse de portefeuille peut aussi être reliée à une personne, comme le rappelle la CNIL. Mettre l’exécution sur Base ne rend ni l’application entière autonome ni les paiements privés.

Le trajet qui reste jusqu’au compte bancaire

Pourquoi utiliser des USDC ? Ce jeton, émis par Circle, vise une valeur d’un dollar américain. Il peut circuler dans des contrats, dont celui de Spliz. Ses mécanismes et réserves sont décrits par son émetteur.

Ce choix évite de libeller les remboursements dans un actif comme l’Ether, dont le cours peut varier fortement. Il conserve d’autres contraintes. L’USDC dépend de son émetteur et un montant en USDC n’est pas un montant en euros. Notre exemple a volontairement laissé la conversion de devises de côté.

Pour un groupe qui possède déjà des USDC sur Base, le règlement peut partir de ces fonds. Pour quelqu’un qui veut payer depuis sa banque et recevoir sur sa banque, il reste un achat ou une conversion, parfois une vérification d’identité, puis éventuellement un retrait.

C’est ce trajet complet que nous devons rendre utile. La rapidité de la transaction finale ne suffit pas à juger le temps et l’effort demandés aux amis.

Le prochain week-end

La compensation, les signatures et l’atomicité sont des mécanismes connus. Leur assemblage dans Spliz pose des questions qui se vérifient dans le code. La volonté d’utiliser l’application se vérifie autrement.

Nous voulons observer des groupes ajouter leurs dépenses, retrouver une erreur et rembourser sans avoir besoin de nos explications. Mesurer où ils hésitent. Voir s’ils reprennent Spliz pour une autre occasion.

Camille doit pouvoir ajouter son ticket. Sam doit comprendre pourquoi son montant change avant de l’accepter. Et lorsque son remboursement est terminé, il doit pouvoir retrouver sa trace sans demander à Camille de refaire les comptes.

Le week-end suivant, nous aimerions que le message soit simplement : « J’ai créé le Spliz. »

Sources

• David Vávra (2012) : algorithmes et usages, sections 2.4 et 5.2.2.
• Adrien Arcuri (22 mars 2018) : partage de dépenses sur Ethereum, accords et paiements.
• Matteo Pelati (8 juillet 2017) : compensation des dettes entre entreprises.
• EIP-712 (2017) : signatures de données structurées et séparation des domaines.
• ERC-2612 (2020) : autorisation de dépense par signature, montant, nonce et échéance.
• Documentation Solidity : propagation des erreurs et annulation des changements dans les appels concernés.
• Ethereum.org : transactions, frais réseau et étapes de confirmation.
• Circle : fonctionnement de l’USDC et réserves de son émetteur.
• CNIL : blockchain, identification des participants et protection des données personnelles.

Sources consultées le 7 septembre 2026.