Claude Opus 5.5 a créé un RTS qui se joue par le son : plongée dans le modem audio de Battle Drones

Deux téléphones sur une table, sans Wi-Fi, sans Bluetooth, sans serveur où que ce soit. L'un héberge une partie de stratégie en temps réel, l'autre la rejoint, et la seule chose qui passe entre eux est du bruit — une porteuse autour de 10 kHz dans un sens et de 17 kHz dans l'autre, transportant les ordres des joueurs à environ 1 880 bits par seconde. C'est la fonctionnalité la plus récente de Claude Opus 5.5 au sein de son artefact public le plus ambitieux à ce jour : Battle Drones, un RTS jouable dans le navigateur, dans le style de Command & Conquer, que Simon Willison a publié le 20 octobre 2026, après douze itérations majeures et 321 commits, principalement de la part d'agents de codage. Anthropic a livré Claude Opus 5.5 le 22 septembre 2026 à 4 $ par million de jetons d'entrée et à 20 $ par million de jetons de sortie, donc le modèle lui-même n'a qu'un mois ; ce qui est nouveau cette semaine, c'est ce qu'il a servi à construire, et la spécification ouverte qui l'accompagne.Les artefacts publics comme celui-ci ont tendance à omettre la manière dont le modèle échoue sous le capot, et les incidents recensés sont répertoriés dans l'OrcaRouter AI Incident Archive où chaque entrée comporte ses propres sources, son niveau de gravité, sa note de confiance et son indicateur de contestation.

Les deux moitiés de cette affirmation sont vérifiables. Le jeu tourne sur simonw.github.io/battledrones/, le code source est sur GitHub sous Apache-2.0, et la liaison acoustique n'est pas une boîte noire — le dépôt contient SOUND-DUEL.md, une spécification complète du modem avec plans de bandes, débits de codage, formats de paquets et valeurs de rapport signal/bruit mesurées. Ce qui suit est ce que ce document et l'article disent réellement, dissocié de ce qu'ils ne disent pas.

Qu’est-ce qui a été livré le 20 octobre ?

Battle Drones n’est pas une bande démo. Comme décrit dans l’article, il contient neuf bâtiments, sept véhicules terrestres, six véhicules aériens et trois types d’infanterie, tous construits sous forme de modèles 3D générés en TypeScript plutôt que chargés depuis un pack d’assets. Il y a un brouillard de guerre, avec des exigences distinctes en matière d’armes anti-aériennes et anti-sol. Six cartes couvrent cinq biomes, plus un générateur de cartes aléatoires à graine qui produit un champ de bataille à symétrie ponctuelle de 108×108 — construit, selon le post, en un sprint de 45 minutes après que l’auteur a remarqué qu’il lui restait 25 % d’une allocation hebdomadaire Claude et 45 minutes avant sa réinitialisation.

Les modes incluent l’escarmouche, les vagues de survie Last Stand, l’observation IA contre IA, une campagne de huit missions et quelque chose de vraiment inhabituel : un mode agent contre agent où deux modèles de langage s’affrontent via un outil qui n’expose que l’état de jeu non visuel visible par le brouillard de guerre. Des rediffusions enregistrées de ces matchs sont livrées avec le dépôt, accompagnées d’une visionneuse de débogage qui affiche les réponses sous-jacentes des modèles.

Les chiffres indiqués dans le README du dépôt se sont légèrement écartés de la liste des fonctionnalités de l’article — le README mentionne seize unités et dix bâtiments, tandis que l’article énumère neuf bâtiments et seize unités réparties entre le sol, l’air et l’infanterie. Seize correspond ; le nombre de bâtiments, non. C’est un détail, mais c’est le genre de dérive qui se produit quand un agent rédige le README et que personne ne le vérifie, et l’auteur dit clairement qu’il n’a « examiné presque aucun code ».

Le lien sonore, en chiffres

Voici la partie pour laquelle il vaut la peine de lire la spécification, car « le multijoueur par l’audio » ressemble à un coup d’éclat tant qu’on n’a pas vu le budget d’ingénierie auquel il devait se plier. Deux appareils partagent une même pièce et un même canal acoustique ; la conception repose donc sur un duplex à répartition en fréquence : les deux téléphones émettent en continu, l’hôte dans la bande 9,525–12,5 kHz et l’invité dans 15,975–18,95 kHz, les bandes étant placées de sorte que la deuxième harmonique de l’hôte commence au-dessus de 19,05 kHz et que l’intermodulation du troisième ordre issue de chaque bande reste à l’écart de l’autre.

• Modulation — OFDM avec un espacement des porteuses de 25 Hz, un symbole utile de 40 ms plus un préfixe cyclique de 10 ms, soit 50 ms par symbole et 20 symboles par seconde

• Charge utile — 188 bits par paquet sur le plan de bande haute, 186 sur le plan de repli basse bande, identique dans les deux modes afin qu’un changement de mode ne modifie jamais ce qui peut tenir

• Débit — 1 880 bit/s en mode haut rapide, 940 bit/s en haut robuste, 930 et 465 sur le forfait bas ; les paquets prennent respectivement 100, 200, 200 et 400 ms

• Contrôle d'erreur — code convolutif à K=7, rendement ½, polynômes 133/171, décodage de Viterbi à sortie pondérée (soft), entrelacement sur les symboles et les tonalités, CRC-16 de polynôme 0x1021, et rejet strict si plus de 10 % des bits réencodés sont en désaccord

• Structure de trame — un symbole de synchronisation plus 40 symboles de données par supertrame, soit 41 symboles ou 2,05 secondes, transportant 20, 10, 10 ou 5 paquets selon le plan et le mode

• Liaison mesurée — un SNR de puissance de 40 à 70 dB dans chaque bande de 1 kHz de 1 à 21 kHz à 10–30 cm, se dégradant jusqu'à un rapport effectif de 17 à 31 dB à 10 cm et de 9 à 19 dB à 30 cm une fois l'écho pris en compte, les réflexions arrivant 8 à 15 ms après le trajet direct

La partie honnête de la spécification, c’est ce qu’elle refuse de promettre. Il n’y a pas d’ARQ : un paquet perdu n’est pas retransmis, le suivant se contente de redécrire chaque tour non acquitté, et si l’arriéré ne tient plus dans un seul paquet, il est réparti sur jusqu’à quatre segments rotatifs. Les gros arriérés se transforment donc en blocages synchronisés plutôt qu’en corruption. Les tours ne sont acceptés qu’une seule fois chacun grâce à un repère de plus haut niveau, et les paquets de jeu sont protégés par un CRC dérivé des deux nonces d’appairage, de sorte qu’un enregistrement d’une autre partie échoue à sa vérification. Comme le dit la spécification, on peut survivre au brouillage mais pas l’empêcher : on se fige, on ne se désynchronise jamais silencieusement.

Les chiffres de livraison issus des tests sur modèle de pièce sont de 99 % ou mieux à 20 cm et de 95 % à 40 cm en mode robuste, 98 % à 20 cm en mode rapide. Ce sont des résultats de simulation rapportés dans la spécification, pas une étude sur le terrain — et l’article lui-même indique que la fonctionnalité était très récente au moment de sa sortie : « Je viens seulement de réussir à la faire fonctionner, donc je n’ai pas encore eu beaucoup de temps pour la tester activement. »

Le bug qui compte plus que le modem

Dans les observations finales se cache le détail le plus susceptible d’être utile à quiconque développe un logiciel avec état à l’aide d’un agent. Comme les replays et le multijoueur en lockstep exigent tous deux que la simulation soit identique bit à bit sur chaque appareil, Claude a dû cesser d’appeler Math.sin() et Math.cos() — Chrome et Safari renvoient des valeurs très légèrement différentes — et les remplacer par ses propres implémentations. Deux navigateurs en désaccord sur les derniers bits d’une fonction transcendante suffisent à désynchroniser une partie plusieurs minutes plus tard.

Il s’agit d’une véritable contrainte d’ingénierie, découverte par le modèle et corrigée par le modèle, et elle se généralise bien au-delà des jeux. Tout système construit par un agent avec un noyau déterministe — un ordonnanceur, une relecture de registre financier, un banc de simulation, une compilation reproductible — rencontrera la même classe de problème, et il la rencontrera silencieusement. La leçon pour le lecteur n’est pas « Claude est doué pour les jeux. » C’est que le déterminisme doit être une exigence explicite dans le prompt, car rien dans une implémentation par défaut ne le rend vrai.

La sonde radio, et un schéma de prompting qui vaut la peine d’être volé

Avant d’écrire le modem, le modèle a construit une page de mesure. Le billet décrit un outil « Radio Probe », toujours présent dans le dépôt sous le nom radio-probe.html, dont le rôle était de répondre à une question : quelle bande passante deux appareils peuvent-ils réellement obtenir entre eux, dans cette pièce, à cette distance ? L’implémentation complète n’a été lancée qu’après que la sonde a renvoyé des chiffres suffisamment bons pour la justifier. Le même fichier documente les deux choses que la sonde n’a pas mesurées — un iPhone émettant avec son propre microphone ouvert, et un téléphone entendant sa propre émission — qui sont exactement les modes de défaillance qui compteraient sur le terrain.

Le schéma vaut la peine d’être copié, quel que soit le modèle que vous utilisez : demandez à l’agent de construire l’instrument avant de construire la fonctionnalité. Mesurer d’abord, construire ensuite, c’est ainsi que vous évitez qu’une semaine de travail repose sur une hypothèse que personne n’a vérifiée. Cela produit aussi les chiffres qui rendent une affirmation comme « le multijoueur audio fonctionne » vérifiable plutôt que charmante.

Ce que cela dit sur Claude Opus 5.5, et ce que cela ne dit pas

Les affirmations les plus fortes du billet sont précises. Willison écrit que Claude Opus 5.5 est « spectaculaire en modélisation 3D avec Three.js » : chaque bâtiment, véhicule et paysage du jeu est construit de façon procédurale dans le code, et il place GPT-6 Astra dans la même catégorie. Il note aussi que le modèle compose de la musique : le projet ne contient aucun fichier audio, et la bande-son est générée dans le code, varie selon la carte et monte en intensité à mesure que le combat s'intensifie.

Deux autres résultats sont rapportés par l’auteur plutôt que reproduits indépendamment, et doivent être lus comme tels. La {{1}}« mise à jour fun »{{/1}} a consisté en un seul prompt — {{2}}« Ce jeu n’est pas encore assez amusant. Rends-le BEAUCOUP plus amusant. »{{/2}} — exécuté dans un mode de flux de travail dynamique qui orchestre de nombreux sous-agents pendant de nombreuses heures, durant lequel le modèle a mené plus de mille sessions de test de jeu simulées. Le résultat rapporté, issu de 1 200 parties IA contre IA en difficulté Normale : les parties encore indécises au bout de 25 minutes sont passées de 14 % à 0,9 %, et la part des victoires d’un camp qui avait au moins 800 ferrailles de retard est passée de 24 % à 46 %. Ce sont les mesures de l’auteur sur son propre jeu, et non un benchmark du modèle.

Ce que l’article ne montre pas est tout aussi important. Il n’y a pas d’évaluation par un tiers de Claude Opus 5.5 en matière de développement de jeux, pas de comparaison directe avec un autre modèle sur la même tâche, ni de comptabilisation des tokens ou des dollars pour les exécutions. L’auteur lui-même présente les choses ainsi : il ne connaît « presque rien au développement de jeux », n’a « examiné presque rien du code » et ne considère pas le résultat comme un projet indie sérieux. C’est un ensemble de réserves d’une franchise inhabituelle, qui limite la portée des généralisations possibles : il s’agit d’un seul praticien, d’une seule base de code, d’un seul mois.

Combien coûte la gestion d’un projet comme celui-ci

La grille tarifaire publiée par Anthropic pour Claude Opus 5.5 indique 4,00 $ par million de tokens d’entrée, 20,00 $ par million de tokens de sortie et 0,20 $ par million pour les lectures de cache. Un projet de cette forme est presque entièrement dominé par la sortie — le modèle écrit du TypeScript, il ne lit pas un vaste corpus fixe —, donc c’est la ligne des 20 $ de sortie qui détermine la facture, et ce sont les exécutions nocturnes de plusieurs heures à fort parallélisme qui transforment « bon marché au token » en un chiffre bien réel. Aucun total n’a été publié pour Battle Drones, donc l’affirmation honnête est que le plafond est fixé par le nombre d’heures-agent que vous êtes prêt à acheter, et non par quelque chiffre que ce soit dans l’article.

C'est aussi l'argument qui plaide contre le fait de confier un chemin de production à un seul modèle sur la foi d'un unique artefact impressionnant. Claude Opus 5.5 est sur OrcaRouter au prix catalogue d'Anthropic, avec 0 % de marge, donc tout changement de prix du fournisseur est effectif de notre côté le jour même, et le basculement automatique signifie qu'une longue exécution d'agent ne s'arrête pas parce qu'un point de terminaison amont connaît un après-midi difficile. Si vous voulez vérifier si un build nocturne comme celui-ci est reproductible sur un autre modèle, une seule API pour plus de 200 modèles est le moyen le moins cher de le découvrir — même structure de requête, nom de modèle différent, pas de second contrat.

Qu'est-ce qui n'est pas établi ?

• Popularité — le dépôt affichait 4 étoiles et 0 fork lors d'une vérification le 21 octobre 2026, un jour après la mise en ligne du post. Ce n'est pas un phénomène ; c'est le projet d'une personne, publié.

• Fiabilité sur le terrain de la liaison audio — les pourcentages de livraison indiqués dans la spécification proviennent de tests sur modèle de pièce, et l’auteur déclare qu’il n’a pas eu beaucoup de temps pour tester activement la fonctionnalité. Ne considérez pas 99 % comme une promesse concernant votre table de cuisine.

• État de l’art — l’article cite Siner d’Alon Horesh et ggwave de Georgi Gerganov comme les seuls travaux comparables qu’il ait pu trouver, et qualifie le multijoueur audio pour les jeux HTML statiques de « première pour un RTS pour autant que je sache ». Il s’agit de la recherche de l’auteur, pas d’une revue de la littérature.

• Attribution du code — Claude Opus 5.5 a piloté la plupart des itérations suivantes, mais la première version a été construite avec Claude Fable 5 en juillet, et le README lui-même indique que le reste du document a été rédigé par Claude. Considérez le dépôt comme un artefact à provenance mixte.

• Un résultat de benchmark — il n’y en a pas. Rien ici ne mesure Claude Opus 5.5 face à un autre modèle sur une tâche avec un score.

Ce qu'il faut réellement retenir est plus précis et plus utile que « une IA a créé un jeu ». Un RTS de navigateur sans backend, une simulation déterministe et un modem acoustique fonctionnel : c'est la démonstration que la partie difficile des logiciels produits par des agents est passée de la génération de code à la spécification de contraintes — déterminisme, mesure, comportement en cas d'erreur — assez précisément pour que le code généré soit vérifiable. Le document SOUND-DUEL.md en est la preuve : il existe parce que quelqu'un a obligé le modèle à consigner ce que la liaison pouvait et ne pouvait pas faire avant de la livrer. Si vous voulez savoir si cette discipline est transposable à votre propre charge de travail, soumettez le même prompt à un second modèle et comparez les spécifications, pas les captures d'écran.