Quatre heures d'attention humaine ont suffi pour reconstruire un jeu de guerre de 1989 pour le web

Une personne, une semaine, un jeu de stratégie de 1989

Un développeur qui écrit sur this.os.isfine.org a publié le récit, encore en cours, de la rétro-ingénierie de War of the Lance (1989) et de son portage vers les navigateurs modernes à l'aide d'un « harnais de code » IA, c'est-à-dire une boucle automatisée qui exécute des modèles sur une base de code. Selon lui, l'ensemble a pris environ une semaine de temps réel et moins de quatre heures de son attention dédiée. Il affirme n'avoir jamais ouvert d'IDE, de Blender, d'outil de rétro-ingénierie, de ligne de commande ni de gestionnaire de versions. Il ne sait pas à quoi ressemble le code. Il sait seulement qu'il satisfait aux exigences de lint et de tests que le harnais imposait à chaque exécution.

Il s'agit du billet de blog d'une seule personne à propos de son projet personnel, et non d'une étude auditée. Considérez chaque chiffre comme une affirmation. Mais ces affirmations sont assez précises pour mériter d'être décortiquées, car le mécanisme décrit est la partie qui se généralise.

Ce que fait réellement le harnais

Faire de la rétro-ingénierie sur un ancien jeu DOS consiste à retrouver les règles et le comportement d'affichage à partir d'un binaire compilé : le code source a disparu, on déduit donc ce que fait le programme en le regardant tourner. Jusqu'ici, cela exigeait un ensemble de compétences rares : désassemblage, formats graphiques, organisation de la mémoire, auxquels s'ajoute l'ingénierie nécessaire pour tout reconstruire ailleurs. L'auteur estime que cette combinaison n'existait que chez quelques milliers de personnes, parmi 320 000 professionnels du jeu vidéo, et qu'un seul titre prenait des mois, voire des années.

Le harnais qu'il décrit réunit plusieurs de ces rôles à la fois. Il joue au jeu original dans DOSBox-X, en lisant les vidages mémoire et le désassemblage pour déterminer les règles. Il joue à sa propre nouvelle version via Playwright, un outil d'automatisation de navigateur normalement utilisé pour les tests, en inspectant la structure de la page et la mémoire, et en s'appuyant sur des modèles de vision pour observer l'écran. Il écrit des tests au fil de l'eau, de sorte que les modifications ultérieures ne puissent pas casser silencieusement le travail précédent. Pour les ressources 3D, le modèle écrit du code Python qui pilote Blender en mode headless afin de produire des fichiers GLB, le format standard pour la 3D sur le web. Il indique avoir modélisé environ 80 à 100 modèles avec un abonnement d'une semaine, et que l'ajout des saisons, du cycle jour/nuit et de trois phases de lune lui a coûté 15 minutes et 2,28 $.

Le jargon à retenir : une lane est un travailleur parallèle. Il n'a pu en exécuter qu'une seule en local à cause des limites de VRAM. Sa courbe de tendance est la suivante : un modèle local équivalent à un modèle de pointe d'avril ou de mai prend une semaine ; avec des lanes dans le cloud, on tombe à deux jours ; un modèle de pointe de septembre 2026 le fait en quelques heures. Il prédit quelques minutes d'ici 18 à 36 mois. Les étapes précédentes sont des choses qu'il dit avoir faites. La dernière est une prévision.

Le signal n'est pas le jeu

Son argument le plus tranchant porte sur la tarification. L'économie du savoir rémunère les connaissances qui sont coûteuses à acquérir et appliquées de façon fiable : son exemple est celui des quinze ans d'un médecin comparés à ceux d'un gérant de supermarché. Si une machine devient un support de stockage et d'application compétent pour ces connaissances, avec les avantages de coût de l'échelle centralisée, la prime de rareté s'érode, que quoi que ce soit ressemblant à une intelligence générale arrive un jour ou non.

Il se montre notamment peu impressionné par le théâtre des benchmarks : selon lui, GPT6 Astra d'OpenAI a été fortement entraîné sur des scènes Three.js en une seule passe précisément parce qu'Internet les utilise comme benchmark, alors que le codage s'est beaucoup moins amélioré. Il cite aussi un échec : Opus 5, qui, dit-il, ne converge tout simplement pas sur les tâches longues. La capacité utile, selon lui, n'est pas le score au benchmark mais l'aptitude à continuer de façon cohérente pendant des heures ou des jours. Il s'attend à ce que l'effet économique plus large prenne une décennie ou plus, car les emplois réels sont plus désordonnés que les démonstrations, et remplacer des systèmes optimisés est rarement rentable.

Les questions que vous devriez vous poser

• Si personne dans votre équipe n'a lu le code, quel est votre plan lorsqu'il tombera en panne d'une manière que les tests n'avaient jamais couverte ?
• Qui est juridiquement responsable d'une production reconstruite à partir de l'artefact de quelqu'un d'autre, et votre conseil juridique a-t-il réellement répondu à cette question, ou s'est-il contenté de noter que l'application du droit semble faible en ce moment ?
• Lorsqu'un fournisseur cite un gain de benchmark, mesure-t-il la capacité dont vous avez besoin, ou celle sur laquelle Internet les note ?
• Quelle part de votre pouvoir de fixation des prix repose sur le fait que le savoir est difficile à acquérir plutôt que difficile à appliquer ?
• Le modèle que vous achetez peut-il rester cohérent sur une tâche de plusieurs jours, et comment le vérifier avant de vous engager ?

Ce qu'il faut surveiller ensuite

Surveillez si des résultats de rétro-ingénierie vérifiés et reproductibles commencent à apparaître chez des personnes qui ne sont pas aussi celles qui avancent l'affirmation. La semaine d'un amateur isolé est une anecdote ; le même travail reproduit en quelques heures par des personnes qui n'ont aucun intérêt dans le récit constituerait un signal pour le marché du travail. Et surveillez les affaires de droit d'auteur : le constat brutal de l'auteur est que le climat politique actuel n'empêchera rien de tout cela, et que l'issue de l'affaire Meta devrait mettre fin à tout espoir que les anciennes règles tiennent encore.