Poto

Poto est un produit de monnaie électronique exploité en environnement régulé. J'ai contribué à la conception et à la construction des systèmes d'information qui le portent.

Un produit de monnaie électronique n'est pas un écran de wallet avec un solde dedans. C'est une obligation d'émetteur : des unités de valeur sont reçues, cantonnées, émises, détenues, déplacées et remboursées, et chacune de ces étapes doit être démontrable des mois plus tard à quelqu'un qui n'était pas là.

Cette contrainte décide de l'architecture avant toute décision produit. Cette page décrit publiquement le problème et la nature de la contribution. Elle ne contient aucun détail d'architecture interne, de processus ou de sécurité.

Trois choses devaient être vraies en même temps : le produit devait fonctionner pour ceux qui l'utilisent, l'exploitation devait être tenable par une petite équipe, et l'ensemble devait être explicable à un superviseur.

La plupart des systèmes en résolvent une. Ne résoudre que la première produit une bonne interface au-dessus d'un grand livre non auditable. Ne résoudre que la troisième produit un projet de documentation sans système d'exploitation derrière.

• Utilisabilité produit
• Exploitabilité opérationnelle
• Explicabilité au superviseur
• Auditabilité par défaut

Conception et mise en oeuvre d'un système capable de détenir de la monnaie électronique et d'en comptabiliser les mouvements.

Le modèle sépare ce qui est reçu de ce qui est émis, et ce qui est détenu de ce qui est dépensable. Les soldes sont une conséquence des mouvements enregistrés, jamais un champ que l'on édite.

Le remboursement est traité comme une opération de premier rang plutôt que comme une exception, parce que c'est le moment où l'obligation de l'émetteur s'éteint.

Les composants qu'un système transactionnel doit avoir avant qu'un produit puisse exister par-dessus.

Le travail a couvert les briques qui font fonctionner un système transactionnel : comptes, wallets, transactions, règles, soldes, rapprochement, contrôle et traçabilité, avec le système d'information qui permet à l'exploitation de tourner au quotidien.

Un outillage interne pour qu'un contrôle produise sa propre preuve.

Contrôles, workflows, vérifications, suivi et outillage d'exploitation ont été construits comme du logiciel à l'intérieur du système plutôt que comme une pratique manuelle parallèle.

La règle de conception est simple : si un contrôle ne sait pas produire sa preuve automatiquement, il n'est pas fini. Une preuve assemblée à la main en fin de trimestre n'est pas un contrôle, c'est un chantier d'archéologie.

• Contrôles
• Workflows
• Vérifications
• Auditabilité
• Suivi
• Exploitation

Contribution au travail technique et opérationnel soutenant le processus d'agrément ACPR et sa mise en oeuvre.

L'établissement opère sous supervision ACPR. La contribution a été technique, organisationnelle et opérationnelle : produire les preuves système, les procédures d'exploitation sous forme logicielle et les données nécessaires au processus, puis les maintenir vraies une fois l'agrément obtenu.

La distinction compte et elle est tenue partout sur ce site : un agrément est accordé à un établissement, pas à une personne.

Une structure de données, plusieurs projections.

Le travail de reporting réglementaire a porté sur la structuration et l'automatisation des données derrière les différents états, pour que chaque état soit une requête sur les données d'exploitation plutôt qu'un assemblage manuel.

Le gain n'est pas l'état lui-même. C'est que la même structure réponde à un superviseur, à une équipe finance et à une revue d'incident sans que trois vérités différentes apparaissent.

Toute contrainte réglementaire finit par se voir dans l'interface : ce qu'un utilisateur peut détenir, ce qu'il peut envoyer, ce qui doit être vérifié avant une action, ce qui doit être expliqué après.

Concevoir ces contraintes comme des comportements produit plutôt que comme des états d'erreur constitue l'essentiel du travail. Un refus qu'une personne comprend est une fonctionnalité ; un refus qu'elle ne comprend pas est un ticket de support, puis une réclamation.

Quatre choses ont été reprises dans tout ce qui a suivi.

• Les règles vivent dans les données, pas dans la prose
• La preuve se produit, elle ne se collecte pas
• Les soldes se calculent, ils ne se stockent jamais comme vérité
• L'exploitation est un produit avec ses propres utilisateurs