Ce matin, 7 août, j'ai posté Neo Studio sur r/neogeo. Une scène homebrew qui remonte à la fin des années 90, des gens qui possèdent le vrai matériel et qui ont vu défiler les projets annoncés trop tôt puis abandonnés six mois plus tard. Le genre d'endroit où un pitch se fait démonter en une phrase — c'est d'ailleurs pour ça que j'y suis allé en demandant explicitement de la critique.
Trois heures plus tard : « The shape of things to come ». Quelqu'un espère des cartouches homebrew sous les 200 dollars. Un autre remercie « au nom de toute la communauté Neo ».
Dans tout ça, personne n'a posé la seule question qui occupe ce blog : comment c'est fabriqué. La page produit ne le dit nulle part. C'est un choix, réfléchi, et cet article raconte les deux choses à la fois : la méthode, et pourquoi la page n'en parle pas.
Ce qui est sorti ce matin
Neo Studio est un studio de développement qui tourne dans un onglet de navigateur et qui produit une vraie ROM Neo Geo. Pas une fantasy console, pas un moteur « à l'esthétique Neo Geo » : un fichier .neo qui se flashe sur une cartouche NeoSD, ou un romset qui boote dans MAME.
Concrètement : on dessine ses sprites dans les palettes natives du matériel, on peint ses niveaux, on compose sa musique sur le YM2610 lui-même (ce qu'on entend en composant, c'est la puce qui jouera le morceau), et on câble la logique du jeu sur un event sheet, sans écrire de code. L'event sheet génère du C ngdevkit. Le fichier qui sort est celui qu'un développeur aurait écrit à la main. Au build, le projet part sur un serveur qui fait tourner la vraie toolchain homebrew (ngdevkit) dans un conteneur, et il en ressort les binaires des deux processeurs de la machine. Quelques secondes plus tard, le jeu boote dans l'émulateur, par-dessus l'éditeur qui vient de le fabriquer.
Un mot sur l'émulateur : c'est un Neo Geo complet écrit from scratch en TypeScript et WebAssembly, zéro dépendance d'émulation. Le deuxième que le lab écrit — le premier était un CPS1, et c'était l'article d'il y a quelques mois.
La beta est ouverte depuis ce matin. Gratuite, sans inscription, rien à installer : studio.sprixe.dev.
Le POC, c'était il y a quatre mois
En avril, je racontais ici comment un émulateur CPS1 complet était sorti en treize jours de pair-programming avec Claude. 22 000 lignes, 1 016 tests, trois pivots d'architecture. L'article se terminait sur la reproductibilité de la méthode, et hevc.js l'a confirmée dans la foulée : huit jours pour un décodeur H.265.
Deux preuves techniques, et le même angle mort. Un POC n'a ni utilisateurs, ni licences, ni serveur qui tombe. La méthode tenait le code pointu. Il restait à prouver qu'elle tenait aussi un produit.
Neo Studio est la réponse, quatre mois jour pour jour après l'article (le CPS1, c'était le 7 avril ; le post r/neogeo, ce 7 août). Entre les deux, il a fallu tout ce qu'aucune démo ne demande :
- Un audit de licences. ngdevkit est sous LGPL : établir ce que la distribution d'une ROM compilée impose réellement (fournir les fichiers objets du jeu, pas ses sources), et bannir de toute la communication « NeoGeo » écrit en un seul mot, marque déposée de SNK.
- Un serveur de compilation exposé au public, avec ce que ça implique de rate-limit par IP, de file d'attente bornée, de concurrence maîtrisée. Rien d'héroïque. Juste ce qu'on ne fait jamais pour une démo.
- Un plan de communication séquencé, écrit avant le premier post, avec des canaux qui ne se grillent qu'une fois.
- Des coupes de scope assumées : le Time Travel Debugger attendra, et le mode code existe mais n'a pas d'entrée visible dans l'interface — sans passerelle depuis le no-code, il se serait fait démonter par le premier testeur.
Ce que les agents ont fait, ce que j'ai fait
Dix semaines séparent la première ligne de code de la beta publique : premier commit le 29 mai, le plan avait été validé la veille.
Sur le CPS1, je parlais de pair-programming — un développeur et Claude dans la même session, pendant treize jours. À l'échelle d'un produit, le mot ne suffit plus. Des agents Claude ont écrit l'émulateur, le serveur de compilation, les pipelines d'assets, les éditeurs. La répartition exacte est difficile à mesurer ; à la louche, la quasi-totalité du typing. Le mot juste est orchestration, et c'est un métier différent du pair-programming.
Parce que mon travail, vu de l'intérieur, ressemblait à quatre choses :
- Trancher aux croisements. Couper le Time Travel Debugger, cacher le mode code : deux cas où les agents argumentaient correctement les deux côtés, et où quelqu'un devait décider ce qu'on ne ferait pas.
- Tenir la ligne rouge des licences. Les agents ont produit l'audit ; décider qu'on ne s'exprimerait jamais en public sur la LGPL sans cet audit sous les yeux, c'est une décision de quelqu'un qui engage sa signature.
- Séquencer la sortie. Quels canaux, dans quel ordre, ce qu'on dépense maintenant et ce qu'on garde.
- Décider de sortir, enfin. Le plan écrivait « construction silencieuse jusqu'en octobre ». C'était prêt début août. On était en avance, et je n'aime pas traîner : la beta est sortie le 7.
Le chantier qui m'a fait sérieusement douter, c'est l'audio. L'import Furnace — le tracker dans lequel se composent les musiques de puce — a été le plus long et le plus difficile du projet. Des semaines de tests entre fin juin et mi-juillet ; dans l'historique git, le dernier commit du chantier contient le mot « enfin ». C'est aussi le chantier où les agents avaient le plus besoin de moi, pour une raison qu'aucune spec ne couvre : mon oreille. Des années de musique assistée par ordinateur servent, au final, exactement à ça — entendre qu'un rendu « conforme » ne sonne pas encore juste.
Pourquoi la page produit ne dit pas « IA »
Allez sur studio.sprixe.dev, lisez tout. Le mot « IA » n'y figure pas. La bio du compte X dit « Built from scratch. Every byte. » Tout est exact : l'émulateur ne dépend d'aucune librairie d'émulation, et il n'y a qu'un humain sur ce projet. Il y a simplement une information qui ne s'y trouve pas.
C'était une décision, prise avant le premier post, et elle tient en deux constats.
Le premier : l'utilisateur de Neo Studio veut une ROM qui boote sur sa flashcart. La méthode de fabrication de l'outil ne change rien à son usage. Mettre « AI-powered » sur la page, c'était garantir que chaque fil de discussion sur le produit devienne un débat sur la méthode.
Le second : la scène rétro est l'un des publics les plus méfiants envers l'IA qui existent (à raison, souvent : elle voit passer du contenu généré médiocre en quantité industrielle). Y débarquer avec l'IA en étendard, c'était se faire juger sur le mot avant d'être jugé sur la ROM.
Trois heures après le post, les commentaires parlent de cartouches à 200 dollars et de l'avenir de la scène. Personne ne parle de méthode. Le produit est jugé sur ce qu'il fait.
En 2026, où chaque landing page colle « AI-powered » à côté du bouton signup, je crois que la preuve de maturité a changé de camp : un produit construit par des agents et assez solide pour que personne ne le devine vaut mieux que n'importe quel badge. La qualité du résultat ne trahit pas la méthode.
Reste la question de l'honnêteté, et elle a une réponse simple : rien n'est caché, tout est publié — vous êtes en train de le lire. La page produit parle aux créateurs de jeux. Ce blog parle aux gens dont le métier est de fabriquer du logiciel. Chaque audience reçoit l'information qui lui est utile, et le mensonge ne commencerait que si l'une contredisait l'autre.
Ce qu'on ne sait pas encore
La liste est courte, mais elle pique.
La ROM n'a jamais tourné sur un vrai hardware. Tout ce qui est vérifié l'est sous MAME et sous notre émulateur. Le fichier .neo est donc éprouvé partout, sauf à l'endroit exact où cette scène l'attend : sur une cartouche, dans une AES. Je l'ai écrit tel quel dans le post, au milieu et en gras. Ce genre d'aveu coûte moins cher quand c'est vous qui le faites.
Le critère de succès de la beta est exigeant : des jeux faits par d'autres que moi. Le trafic, lui, est une vanity metric. À J+0, des gens sont déjà dans l'éditeur et les premiers projets se créent — c'est exactement ce qu'on espérait voir. Ce qui validera la beta, ce sont les ROMs qui sortiront de ces essais.
Le modèle économique n'est pas décidé. La beta est gratuite et sans inscription parce que la seule chose qui compte maintenant, ce sont ces jeux. Je n'ai pas de réponse plus sophistiquée, et je préfère l'écrire que broder.
Dernier point : le serveur de compilation est dimensionné pour un lancement tranquille. En cas de gros pic de trafic, il faudra monter la capacité en urgence. Autant le dire avant que ça arrive.
La suite est une phase d'écoute : corriger les frictions d'onboarding au fil des retours, et accompagner ces premiers projets jusqu'à leur ROM.
La méthode, elle, en est à trois projets publics : un décodeur H.265 en huit jours, un émulateur CPS1 en treize, et maintenant un produit complet en dix semaines. Si vous vous demandez ce que l'orchestration d'agents donnerait sur votre roadmap, on peut en parler.
La prochaine chose à prouver, côté Studio : une .neo qui boote sur une vraie AES.