Blockchain : les quatre idées que je garde côté back-end, et le reste que je laisse

Mise au point préalable : je n'exploite aucune blockchain en production, et je n'en recommande une à personne comme socle par défaut. Ce texte n'est pas un plaidoyer.

Il reste que l'écosystème crypto a produit, sous une contrainte extrême — des milliers de nœuds mutuellement méfiants, sans autorité centrale, avec de l'argent au bout — des solutions d'ingénierie que la plupart des systèmes centralisés gagneraient à connaître. Quatre d'entre elles me servent régulièrement, sur des produits qui n'ont aucun rapport avec la crypto.

1. L'idempotence comme condition de départ, pas comme rustine

Un réseau distribué rejoue les messages. Par conception, pas par accident. Une transaction peut être vue deux fois, dans le désordre, ou avec des minutes d'écart. Le système ne peut donc pas se permettre qu'un traitement en double produise un effet en double : chaque opération porte un identifiant unique, et la seconde exécution est un no-op reconnu.

Exactement le même problème se pose sur un webhook de paiement, une file de messages ou un job planifié. Tous les fournisseurs de paiement rejouent leurs événements — c'est écrit dans leur documentation et c'est délibéré. Traiter un webhook comme un appel unique, c'est se garantir un double débit un jour de latence réseau.

-- La table qui coûte trois lignes et évite l'incident
CREATE TABLE processed_events (
  event_id   TEXT PRIMARY KEY,
  handled_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

L'insertion échoue sur doublon : l'unicité est garantie par la base, pas par une vérification applicative qui aurait sa propre fenêtre de concurrence.

2. La finalité n'est pas la confirmation

En crypto, la distinction est explicite et vitale : une transaction vue n'est pas une transaction confirmée, et une transaction confirmée n'est pas irréversible. Chaque étape a un niveau de confiance différent, et l'application décide à partir de quel niveau elle agit.

Cette distinction manque cruellement ailleurs. Une commande « payée » selon le front, « payée » selon le webhook et « payée » selon le relevé bancaire ne sont pas le même état. Confondre les trois, c'est expédier une marchandise sur une autorisation qui sera refusée deux jours plus tard.

Nommer explicitement les états intermédiaires — annoncé, confirmé, irréversible — coûte une colonne et évite une classe entière de litiges.

3. Les clés sont une préoccupation de premier plan

La crypto n'a pas le luxe du « on remettra la gestion des clés à plus tard » : perdre une clé, c'est perdre les fonds. Il en découle une culture inhabituelle — rotation prévue dès le départ, séparation stricte entre clé de signature et clé de chiffrement, hiérarchie de dérivation, et surtout un chemin de récupération conçu avant l'incident.

Dans un back-end ordinaire, les secrets sont trop souvent une variable d'environnement posée le jour du déploiement et jamais retouchée. Trois questions suffisent à mesurer l'écart : savez-vous quels secrets sont en production, savez-vous lesquels ont transité par un canal non sûr — un chat, un ticket, une capture d'écran — et savez-vous en faire tourner un sans coupure ?

4. Vérifier plutôt que faire confiance

Le principe fondateur : ne jamais croire un pair sur parole, toujours vérifier sa preuve. Transposé, cela donne une règle d'architecture simple — toute donnée qui traverse une frontière de confiance est revalidée du côté qui la reçoit.

Un identifiant d'utilisateur venu d'un token, un prix venu du client, un rôle venu d'un JWT : chacun a été vrai au moment de son émission, et chacun peut avoir cessé de l'être. Le rôle inscrit dans un access token de quinze minutes survit quinze minutes à la rétrogradation de son porteur.

Ce que je laisse

Trois choses, sans regret.

La blockchain comme base de données. C'est un journal répliqué, lent, coûteux et immuable — trois propriétés qui sont des défauts dès lors qu'on dispose d'une autorité de confiance, c'est-à-dire dans l'immense majorité des projets d'entreprise. Postgres écrit plus vite, coûte moins cher, et se corrige.

L'immuabilité comme vertu. Sur un système qui manipule des données personnelles, l'impossibilité d'effacer n'est pas une garantie : c'est une non-conformité. Le droit à l'effacement n'est pas négociable, et il ne s'accommode pas d'un journal immuable.

La décentralisation par défaut. Elle a un coût — en latence, en complexité, en exploitation — qui ne se justifie que si l'absence d'autorité de confiance est une contrainte réelle du problème. Dans presque tous les projets que je rencontre, cette autorité existe : c'est le client lui-même.

Pourquoi je continue à suivre le sujet

Pas pour le cours du jour. Pour la même raison qu'on lit les retours d'expérience des systèmes à très forte contrainte : ils rendent visibles des problèmes que les autres systèmes ont aussi, mais peuvent se permettre d'ignorer un peu plus longtemps.