Comment on construit Salty Poker : spec-driven development

La plupart des plateformes de poker sont construites comme la plupart des mains de poker sont jouées — vite, à l'instinct, en improvisant en cours de route. Nous ne faisons pas ça.

Dès le premier jour, on a pris la décision délibérée de construire cette plateforme avec du spec-driven development. C'est une méthodologie qui gagne un vrai terrain dans les milieux de l'ingénierie assistée par IA, et c'est la fondation sur laquelle tout ce qu'on construit repose.

Ce que veut dire spec-driven development

Avant qu'une seule ligne de code de production ne soit écrite, une spécification a été écrite en premier. Plus de 100 pages. Vingt-trois modules couvrant chaque domaine du système — infrastructure, schéma de base de données, contrats d'API, frontières de service, contrôles de conformité, pipelines CI/CD, runbooks opérationnels.

La méthodologie se décline en trois niveaux. Spec-first : une spec exhaustive est écrite avant tout code, puis utilisée pour piloter le développement. Spec-anchored : la spec reste vivante et évolue en parallèle du codebase à mesure que le projet mûrit. Spec-as-source : la spec est la seule chose que l'humain touche — le code est entièrement généré à partir d'elle.

Il y a aussi un pattern d'échec qui mérite qu'on le nomme : spec-once — une spec lance un projet puis est silencieusement abandonnée au fur et à mesure que le build avance. Le plan devient une relique.

On est explicitement conçus contre ça. Notre spec est un document vivant. Elle est mise à jour au fur et à mesure que des décisions sont prises, que des edge cases remontent, que l'architecture évolue. Quand une session se termine, la spec reflète ce qui a été construit. Quand la session suivante démarre, elle reprend exactement là où la précédente s'est arrêtée.

Pourquoi ça compte pour une plateforme de poker

Les plateformes de poker échouent de manière prévisible — et presque toutes ces défaillances remontent à la même cause racine : des raccourcis pris tôt qui se cumulent en problèmes sérieux plus tard.

Un système de wallet construit sans un vrai ledger en partie double. Un game engine qui n'a jamais été stress-testé sur ses edge cases. Une couche de conformité boulonnée après coup plutôt qu'intégrée dès le premier jour. Une plateforme qui marche bien à 50 joueurs et s'effondre à 500.

Le spec-driven development, c'est la discipline qui empêche ça. Chaque frontière de service est définie avant d'être construite. Chaque flux de données est documenté avant d'être implémenté. Chaque exigence de conformité est dans la spec avant qu'une seule migration ne tourne. Il n'y a pas de décisions du style « on verra ça plus tard » — parce que « plus tard », c'est quand les joueurs sont déjà aux tables.

L'IA agentique comme moteur d'exécution

On utilise de l'agentic AI pour construire cette plateforme — et il y a une distinction importante entre ça et les outils d'IA que la plupart des gens connaissent.

L'agentic AI ne se contente pas de répondre à des questions ou de faire de l'autocomplétion de code. Elle exécute des workflows multi-étapes de manière autonome dans des limites définies — écrire le code, lancer les tests, attraper l'erreur, la corriger, committer — sans qu'un humain ait à surveiller chaque action. Elle traite une tâche de bout en bout et rend la main dès qu'elle rencontre une décision réservée à un humain.

C'est la spec qui rend tout ça sûr et prévisible. L'agent opère à partir d'une spécification définie, revue, versionnée. Chaque session charge un sous-ensemble ciblé de modules — deux à quatre à la fois — donnant à l'agent exactement le contexte dont il a besoin et rien de plus. Chaque session a un périmètre défini. Un checkpoint verrouille le passage à la phase suivante. Rien n'avance tant que la checklist n'est pas propre.

L'agent ne décide pas quoi construire. La spec décide. L'agent exécute.

Le résultat

Une plateforme construite avec la rigueur qu'elle mérite. Chaque décision d'architecture documentée. Chaque frontière de service intentionnelle. Chaque exigence de conformité traitée avant d'être devenue un problème.

C'est ça qu'on construit. Et vous sentirez la différence quand vous jouerez dessus.

J'écris sur le spec-driven development en tant que méthodologie — les décisions, le tooling, la structure des sessions, et ce que ça veut dire au-delà du poker — sur The Salty Korean. Si le côté ingénierie vous intéresse, c'est là que vivent les analyses plus profondes.

Pour en savoir plus sur la méthodologie : Using Spec-Driven Development with Claude Code par Heeki Park.

Stay salty.