# Hold the Throne > Un site transactionnel où un seul roi tient le trône à la fois : concurrence, arbitrage de paiement et historique inviolable, le tout garanti par la base de données. Étude de cas, projet personnel Un trône, une règle : il revient à celui qui mise le plus. Un site où les visiteurs se disputent une place unique, publiquement, en misant les uns contre les autres. L’idée est simple, le problème d’ingénierie beaucoup moins : plusieurs personnes qui paient en même temps pour la même place. **Statut.** **En ligne.** L’ouverture des paiements se prépare. **Mon rôle.** Idée, conception, développement et volet juridique. **Projet personnel.** **Techniques.** Next.js, base Postgres, paiement en deux temps : autorisation puis capture. **Déjà en place.** Conditions de vente, mentions légales, politique de confidentialité et interface bilingue. En clair Un site où une seule personne à la fois occupe la place, celle de la mise la plus haute. Le jeu tient en une phrase ; le travail, lui, consistait à garantir que **deux personnes qui paient dans la même seconde ne fassent jamais deux gagnants**, ni un débit injustifié. Le reste de la page est technique. ## Ce qui rend l’exercice difficile Une seule place, un prix qui monte, et n’importe qui peut la prendre à n’importe quel moment. Énoncé comme ça, c’est un jeu. Écrit sérieusement, c’est le problème de la dernière place d’un avion ou du dernier article en stock : **deux personnes qui cliquent dans la même seconde.** Et comme de l’argent circule, chaque défaut se paie pour de vrai : deux détenteurs au lieu d’un, quelqu’un débité alors qu’il a perdu, un paiement compté deux fois, un historique réécrivable. C’est ce qui rend le projet intéressant à construire. ## Quatre garanties, quatre mécanismes Aucune de ces garanties ne repose sur une vérification écrite dans le code applicatif. Chacune est descendue à la couche qui refuse l’opération, là où le code applicatif se contenterait de la contrôler. Unicité ### Un seul détenteur, toujours La base refuse par construction d’enregistrer deux règnes actifs en même temps. Le code ne vérifie pas avant d’écrire ; c’est la base qui rejette l’écriture. **Même un bug applicatif ne peut pas fabriquer deux rois.** Arbitrage La méthode courante consiste à vérifier dans le code qu’aucun règne actif n’existe, puis à écrire. Entre les deux, une autre requête a tout le temps de passer. Ce genre de faille ne se voit pas en développement, seulement le jour où deux personnes cliquent ensemble. Une contrainte posée dans la base ne se contourne pas, ni par du code écrit plus tard, ni par une mise à jour faite à la va-vite. Même logique que sur [Argentique](https://noah-baron.fr/argentique), où c’est le système qui tient la promesse de confidentialité, et non une intention. Argent ### Personne n’est débité pour rien Une mise n’est pas encaissée au clic. Elle est d’abord autorisée, mise de côté sans être prélevée, et ne part réellement que si elle bat encore le trône **au moment de l’arbitrage**. Un perdant n’est pas débité, et n’a donc pas de remboursement à réclamer. L’arbitrage lui-même se joue dans une transaction verrouillée : le temps qu’on décide, personne d’autre ne peut toucher à l’état du trône. Fiabilité ### Un paiement compté une seule fois Par sécurité, les services de paiement renvoient parfois deux fois la même notification. Un système naïf couronne alors deux fois la même personne, ou double son montant. Chaque événement reçu est donc enregistré sous une identité unique, ce qui permet de reconnaître le second passage et de l’ignorer. Mémoire ### Un historique qu’on ne peut pas réécrire Les règnes passés ne sont jamais supprimés : chacun garde sa plaque publique, avec sa durée et son montant. Si un paiement finit par être rejeté, la plaque reste en place et porte la mention révoquée, à la vue de tous. Sur un site dont tout l’intérêt tient au classement, **effacer en douce serait bien pire que d’afficher un échec**. ## Le travail qui ne se voit pas dans le code Un site qui encaisse de l’argent ne se résume pas à sa technique. Celui-ci porte ses conditions de vente, ses mentions légales et sa politique de confidentialité, rédigées avant l’ouverture plutôt qu’après coup, avec une note de cadrage préparée pour un juriste. La page dit aussi en toutes lettres ce qu’elle vend : un espace d’affichage, rien de plus. Sur un concept aussi frontal, **c’est l’ambiguïté qui serait risquée**. L’interface existe en français et en anglais. **Ce que ça démontre.** Concurrence, arbitrage, paiement et obligations légales : **les contraintes d’une vraie boutique en ligne.** ## Ce qui reste à faire Le site est en ligne sur son nom de domaine et le socle transactionnel est posé. Les paiements, eux, ne sont pas encore ouverts : le temps de finir, les règnes actuels se jouent sur des montants fictifs. Il reste une étape avant l’ouverture, et c’est celle qui compte : **une suite de tests automatiques sur l’arbitrage**. Le comportement a été éprouvé à la main, ce qui suffit pour se convaincre mais pas pour dormir tranquille. Sur le seul de mes projets qui manipule de l’argent, c’est la dernière chose que je laisserais en l’état. **Prochaine étape.** Tests automatiques de l’arbitrage, puis ouverture des paiements. **Le même réflexe.** Une règle tient mieux posée dans le système que répétée dans le code. Voir [Argentique](https://noah-baron.fr/argentique). --- Source : https://noah-baron.fr/hold-the-throne