A.M.C Bank

Le projet est parti d'une envie simple : comprendre comment fonctionne un carnet d'ordres en le construisant. Il est devenu une banque complète, avec des cours qui bougent tout seuls, une ligne de crédit, un classement par patrimoine net, et un casino dont chaque tirage peut être vérifié après coup par le joueur.

Il a été conçu en deux jours de cadrage — identité, économie du joueur, moteur de marché — consignés dans un journal des décisions, puis développé en une dizaine de livraisons. Chaque décision y est datée, avec ce qu'elle coûte : c'est ce journal qui fait foi, pas la spécification d'origine.

Ce que la banque fait

Le serveur, c'est la base

• Aucun serveur applicatif de confiance. Toute écriture qui a une conséquence économique passe par une fonction en base : le navigateur dit ce qu'il veut faire, la base décide de ce qui se passe. Aucun écran n'envoie jamais un prix, un solde ou une quantité à créditer.
• Une clé d'idempotence par action. Chaque opération porte un identifiant généré par le navigateur, conservé tant qu'elle n'a pas abouti. Un double clic ou une reconnexion ne passe pas deux ordres : la base rend le résultat d'origine.
• Un seul abonnement temps réel. Le ruban de cotation, la liste du marché et la fiche d'actif lisent la même table de diffusion. Faire interroger les prix par chaque joueur toutes les cinq secondes, c'est soixante-douze mille requêtes à l'heure pour cent joueurs.
• Un ordre en attente immobilise. Le solde ne bouge pas quand on pose un ordre, mais l'argent est réservé. Partout où l'on demande de l'argent, l'écran affiche le disponible, jamais le solde total : sinon il promettrait de l'argent déjà engagé.

Un marché qui avance sans tâche planifiée

Les cours bougent toutes les cinq secondes, même quand personne n'est connecté. Or les tâches planifiées de la base ne descendent pas de façon fiable sous la minute. J'ai donc fait du temps du marché une fonction : le hasard de chaque tick est dérivé d'une empreinte de l'actif, du numéro de tick et d'une graine secrète. Rattraper douze ticks d'un coup donne le même résultat que douze exécutions espacées.

Chaque tick additionne quatre forces — rappel vers le cours réel, volatilité, flux d'ordres, sentiment — bornées à ±2 % par tick et ±35 % par jour. Pas de faux joueurs : un flux fictif entre directement dans la formule. Et un seul paramètre par actif, sa profondeur, décide si un joueur peut le faire bouger : les grandes valeurs sont un abri, les entreprises fictives un terrain de chasse.

• Un verrou qui bloquait tout le monde. Le premier moteur rattrapait tous les actifs sous un même verrou : 10,6 secondes de blocage après une heure d'absence, 26 secondes à vingt actifs, pendant lesquelles aucun ordre ne passait. Le moteur est désormais découpé par actif, avec un verrou local.
• Un historique qui remplissait la base en 129 jours. J'avais raisonné en nombre de lignes, alors que c'est le poids sur l'année qui décide. Les ticks ne sont plus stockés un par un : des bougies à la minute, agrégées puis purgées.
• Un prix de réouverture qui se lisait d'avance. Après une longue panne, le rappel vers le cours réel était total : le prix de réouverture était donc connu à l'avance, exploitable dès qu'il y aurait des ordres à cours limité. Il est plafonné à 90 % de l'écart.

Un crédit réaliste, avec ses limites

Je voulais un prêt réaliste. Un prêt personnel repose sur des revenus, que les joueurs n'ont pas. Le seul crédit réel qui corresponde à quelqu'un qui détient un portefeuille, c'est le crédit sur titres : 50 % de la valeur du portefeuille, 6 % par an, sans échéance. La quotité borne d'elle-même le levier à deux fois les fonds propres.

Le journal des décisions consigne aussi ce que ce choix ne règle pas : une banque ne prête rien sans garantie, donc le crédit ne sauve pas un joueur ruiné. Et un taux réaliste rend l'emprunt presque gratuit à l'échelle du jeu — 82 centimes par jour pour 5 000 € empruntés. C'est le premier réglage à toucher si l'emprunt doit redevenir une vraie décision.

Un système visuel strict

Trois tours de recherche ont été nécessaires pour la direction artistique ; les pistes écartées sont conservées avec leurs raisons. Le système retenu tient en trois règles : aucun angle arrondi, aucune ombre, aucun dégradé ; le vert et le rouge disent uniquement ce qui monte et ce qui baisse — une erreur se signale autrement ; et tout ce qui est un nombre est en chasse fixe. Onze couleurs, définies dans les deux thèmes, et aucun composant n'en écrit une lui-même.

Pourquoi il est fermé pour travaux

A.M.C Bank vivait dans la base de The Circle, pour partager les comptes des joueurs. En septembre 2026, je l'en ai sorti, pour pouvoir le réinstaller plus tard dans sa propre base. Le site affiche une page de travaux, les tâches planifiées ont été mises en pause, puis tout ce qui lui appartenait a été exporté — 37 tables, 117 fonctions, 15 tâches planifiées — avec une notice de restauration.

Avant de supprimer quoi que ce soit, j'ai prouvé que la sauvegarde se restaurait : rechargée entièrement dans une transaction annulée, elle a reconstruit toutes ses tables, fonctions et règles d'accès. Les 34 migrations du produit ont regagné son propre dépôt : tout est prêt pour une réinstallation.

Ce que j'en retiens

C'est le projet où j'ai appris à ne faire confiance à rien de ce qui vient du navigateur. Poser cette règle dès le début a coûté du temps au départ et en a fait gagner ensuite : aucune fonctionnalité n'a eu besoin d'être reprise pour cause de faille économique. Et depuis que chaque fonction est appelée au moins une fois avant d'être appliquée, plus aucune requête n'arrive en production sans avoir tourné — une erreur de colonne avait traversé deux relectures parce que la base ne vérifie pas le corps d'une fonction à sa création.