Le créateur d’un jeu développé avec un agent IA : 30 tests au vert ne prouvaient rien, jusqu’à ce qu’il en écrive un nouveau

La situation est familière : vous expliquez trois fois la même chose à l’agent, qui s’y prend encore à sa manière la quatrième fois. Le créateur du jeu de stratégie Age of Poleis, dont le code est écrit par une IA tandis qu’il imagine, arbitre et joue, explique comment il est sorti de cette boucle. Son expérience sera utile à tous ceux qui confient les tâches routinières à des agents.

Une règle, une méthode et un contrôle

La stack est la suivante : backend sous Django, interface en React et TypeScript. Le contrat est défini côté backend, puis transformé en schéma OpenAPI, à partir duquel sont générés les types TypeScript. La tentation est évidente : lorsqu’un type côté frontend ne correspond pas à la réponse de l’API, on a envie de le corriger à la main, puisqu’il ne s’agit que d’une ligne. Mais à la génération suivante, la modification disparaît silencieusement et le bug revient.

Quand l’auteur a constaté qu’il ne donnait pas cette explication pour la première fois, il a intégré la règle aux instructions permanentes de l’agent : ne pas modifier manuellement les fichiers générés, corriger la source puis relancer la génération, laquelle ne doit rien modifier si elle est répétée. Mais une instruction écrite reste un simple souhait. Il a donc ajouté une étape au script commun de vérification : celui-ci génère le schéma et les types dans des fichiers temporaires, puis les compare aux versions présentes dans le dépôt. Toute différence fait échouer le contrôle.

La formule est simple : une règle, un moyen de l’appliquer et un contrôle. Sans contrôle, la règle ne fonctionne que tant que l’agent s’en souvient. Avec un contrôle, elle fonctionne toujours. L’auteur applique la même méthode au formatage, à la localisation et aux autres tâches répétitives.

Trente tests au vert qui ne vérifiaient pas la bonne chose

Dans la version Windows, le jeu s’ouvrait dans trois fenêtres : chargement, jeu, puis attente avant la fermeture. L’auteur voulait une seule fenêtre, dans laquelle se succèdent le chargement et le jeu. Sur le papier, l’exigence tient en une ligne. Dans le code, elle couvre plusieurs états : lancement, chargement, fermeture en cours de démarrage, sauvegarde et redémarrage.

Les 30 tests existants du shell étaient tous au vert. Mais ils validaient l’ancien comportement, précisément celui que l’auteur voulait abandonner. Le vert signifiait « fonctionne comme avant », alors qu’il fallait « fonctionne autrement ». Il a donc commencé par ajouter un nouveau test portant sur le cycle de vie de la fenêtre. Celui-ci échouait avec l’ancien code, car il cherchait la fenêtre principale et trouvait celle de chargement. Après la refonte, il est passé au vert.

Pour permettre à l’agent de vérifier lui-même le résultat, l’auteur formule l’objectif sous forme de faits observables : le chargement et le jeu se déroulent dans une même fenêtre, une fermeture pendant le lancement n’ouvre pas une nouvelle fenêtre, la campagne sauvegardée reste en place après un redémarrage. Au final, 96 tests JavaScript ont réussi, et l’agent a également exécuté séparément la véritable application Electron.

Deux autres pratiques complètent le dispositif. Premièrement, dans chaque rapport, l’agent doit indiquer ce qui n’a pas été vérifié. Ici, il s’agissait d’une installation sur une version propre de Windows. Un mois plus tard, cette ligne évite les fausses certitudes. Deuxièmement, une capture d’écran ne prouve pas que l’état attendu a été atteint. La première image montrait le menu de préparation de la campagne, pas le jeu lui-même. Seule une image ultérieure de la campagne, associée à une vérification de la fenêtre réelle, a servi de confirmation.

Ce qui reste à l’humain

Lorsque la partie technique peut être vérifiée sans lui, l’auteur se concentre sur d’autres questions : non plus « le bouton fonctionne-t-il ? », mais « a-t-on envie de cliquer dessus ? ». Une mécanique peut être irréprochable et ennuyeuse, tandis qu’un système économique peut facilement se transformer en exercice comptable. Aucun test ne détectera cela. Associer les habitants aux professions était amusant pendant les premières minutes, puis fastidieux après une centaine de périodes de jeu. Le système a donc fini par intégrer une sélection automatique des candidats selon des critères.

Le perfectionnisme constitue un autre piège. L’auteur a rejoué des dizaines de fois le début du jeu et corrigé des boutons mal alignés, alors que l’aléatoire rend de toute façon chaque partie différente. Il reconnaît lui-même que son plaisir personnel ne remplace pas les parties jouées par d’autres.

Les builds, les signatures, la certification et le marketing restent à la charge de l’humain. L’IA peut rédiger une description en cinq minutes, mais elle ne décidera pas à qui le jeu s’adresse ni ce qu’il faut montrer en premier.

Conclusion pratique

• Si vous avez répété deux fois la même explication, transformez-la en règle, puis immédiatement en contrôle automatique.
• Pour modifier un comportement, écrivez un test qui échoue avec l’ancien code.
• Exigez de l’agent une liste des éléments non vérifiés et des preuves de l’état atteint, pas une simple capture d’écran.
• Confiez à l’agent ce qui peut être mesuré. Gardez pour vous le goût et le jugement sur ce qui est « intéressant ».