A.M.C Bank
Un marché simulé, un portefeuille et une ligne de crédit. Dix mille euros virtuels au départ, aucun argent réel — ni en entrée, ni en sortie.
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 entre deux passages, 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.
Ce que la banque fait
Le marché
Vingt actifs cotés, une courbe par actif, et un ticket d'ordre complet : marché, limite, stop, stop-limite et ordre de protection.
Le portefeuille
Positions revalorisées en direct, ordres en attente, et distinction stricte entre le solde total et ce qui est réellement disponible.
Le crédit
Une capacité d'emprunt calculée sur le patrimoine, avec emprunt et remboursement suivis au centime.
Le classement
Un classement par patrimoine net, et un journal paginé de tous les ordres passés.
Le casino
Quatre salles — crash, plinko, roulette, blackjack — avec une page d'équité qui explique et permet de vérifier chaque tirage.
Des cours réels
Les prix sont indexés en euros sur un marché réel, avec un mécanisme qui rapproche le cours simulé du cours réel à chaque tick.
Le parti pris technique
- Le serveur, c'est Postgres. Il n'y a pas de serveur applicatif de confiance. Toute écriture à conséquence économique passe par une fonction en base : le client 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 économique porte un identifiant généré côté client et 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 pour toute l'application. 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 client, c'est soixante-douze mille requêtes à l'heure pour cent joueurs — la facture est déjà tombée une fois, sur un autre projet.
Ce qui était difficile
- Une économie qui ne s'effondre pas. Un marché simulé dérive vite : soit tout le monde s'enrichit et l'argent ne vaut plus rien, soit tout le monde est ruiné en une soirée et ne revient pas. L'équilibrage a demandé plus de travail que le moteur d'ordres lui-même.
- Un marché qui vit sans joueur. Les cours doivent bouger même quand personne n'est connecté, ce qui suppose une tâche planifiée dans la base plutôt qu'un calcul déclenché par une visite.
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.