Claude Sonnet joue à Doom, avec des béquilles

Depuis trente ans, la communauté du hack s'amuse à faire tourner Doom sur tout ce qui possède un processeur : calculatrices, oscilloscopes, tests de grossesse, distributeurs de billets. Le chercheur Andrea Ricci vient d'inverser la proposition. Dans un projet relayé par Hackaday le 26 août 2026, ce n'est plus la machine qui exécute Doom, c'est Claude Sonnet qui y joue.

Le montage repose sur une carte SCINTIX P4, compatible avec le format des modules Raspberry Pi CM4 et CM5, associant un microcontrôleur ESP32-P4 et un ESP32-C6. Le jeu s'affiche sur une dalle de 1024 sur 600 points, les images sont capturées puis transmises par WebSocket au modèle, qui décrit ce qu'il voit avant de renvoyer ses ordres de déplacement et de tir. Il fonctionne, dans une certaine mesure : il décrit correctement l'environnement, avance dans les couloirs, ouvre les portes et tire sur ce qui bouge.

Une perception équipée de béquilles

L'argument central du projet est que le modèle ne reçoit que ce qu'un joueur humain verrait. La réalité est un peu plus nuancée. Pour éviter que la chose ne passe son temps le nez contre les murs, l'auteur lui fournit une carte de profondeur couvrant le champ de vision, ainsi qu'un plan automatique en caractères ASCII qui lui permet de savoir où elle est déjà passée.

Autrement dit, l'image brute ne suffit pas. Il a fallu la traduire en représentations symboliques exploitables par une machine à produire du texte. C'est là toute l'ambiguïté de ces démonstrations : ce qu'elles présentent comme de la perception relève surtout d'un travail d'adaptation en amont, réalisé par un humain qui sait précisément quelles informations manquent au modèle. Le mérite du projet est de le documenter ; le problème est que la démonstration circule ensuite sans ces réserves.

Un aller-retour réseau pour tourner à gauche

Le second point mérite d'être posé sans détour. Doom tournait en 1993 sur un 486 à 66 mégahertz, sans accélération graphique, avec quatre mégaoctets de mémoire. Trente-trois ans plus tard, décider de tourner à gauche suppose d'expédier une image sur un réseau vers un centre de données, d'y mobiliser des ressources de calcul sans commune mesure avec celles de la machine d'origine, puis d'attendre la réponse.

Le coût énergétique de l'opération n'est documenté nulle part, et pour cause : les fournisseurs de ces services ne le publient pas. La carte embarquée, elle, ne fait rien d'autre qu'afficher le jeu et servir de relais. Sans connexion, l'ensemble ne joue plus. Pour un objet présenté comme de l'informatique embarquée, la dépendance est totale.

Le code libre d'un côté, l'API fermée de l'autre

La comparaison est cruelle. Le moteur de Doom a été publié par id Software en 1997 puis placé sous licence GPL deux ans plus tard, ce qui explique précisément qu'on puisse encore le porter sur n'importe quoi trois décennies après. Chacun peut lire ce code, le modifier, le compiler pour une architecture que personne n'avait prévue. C'est la condition matérielle de tous les détournements auxquels ce jeu a donné lieu.

Le composant qui joue, lui, est un service distant dont ni les poids, ni les données d'entraînement, ni le fonctionnement interne ne sont accessibles. On peut l'interroger, pas l'examiner. Dans dix ans, le dépôt de Doom sera toujours là ; rien ne garantit que l'interface utilisée par ce projet réponde encore. Des modèles à poids ouverts existent pourtant, capables de tourner sur du matériel local, et c'est de ce côté que la démonstration deviendrait réellement intéressante : non pas qu'une intelligence artificielle sache jouer à Doom, mais qu'elle le fasse sans demander l'autorisation à personne.