Un LLM a écrit un agent pour Arkanoid et battu le boss dans 10 parties sur 10

Un problème bien connu avec les agents d’IA se présente ainsi : le modèle écrit du code avec assurance, l’exécute et annonce un succès, mais personne ne peut prouver que la tâche a réellement été accomplie. Une expérience menée avec le jeu DOS Arkanoid a rendu ce problème littéralement visible à l’écran. Le LLM a reçu le jeu sans API ni accès à la mémoire du processus : seulement une image de 320 × 200 pixels, une souris, un clavier et la possibilité de revenir à des états sauvegardés. Le programme joueur final a battu le boss DOH dans 10 parties sur 10, avec un score moyen de 343 977 points.

Pourquoi l’entraînement n’a pas fonctionné

La première tentative suivait une approche classique : le LLM aidait l’auteur à écrire un système d’apprentissage par renforcement. L’agent a effectué 17 millions d’étapes en environ 17 heures, mais a plafonné à un score moyen de 7 000 à 8 000 points. Il observait une image réduite, déplaçait la raquette par petits incréments et recevait une récompense liée au score.

Le problème se cachait dans la mécanique des rebonds. Lorsque la raquette frappait la balle à différents endroits dans une zone d’environ 12 pixels autour de son centre, l’angle variait d’une trajectoire oblique vers la gauche à une trajectoire oblique vers la droite. Sur l’image réduite, la balle devenait une simple tache, tandis que le système de contrôle ne permettait pas de placer rapidement la raquette au bon endroit. L’auteur a indiqué cette relation, mais le nouvel entraînement n’a jamais été mené à son terme.

C’était l’approche Software 2.0 : l’humain choisissait l’architecture, les données, la récompense et la méthode d’entraînement, tandis que le LLM aidait à construire le système à l’intérieur de ces contraintes. Il accélérait le travail, mais ne décidait pas quelle méthode convenait à la tâche.

Ce qui a changé lors de la deuxième tentative

Le même LLM a ensuite reçu un autre rôle. Au lieu de lui demander d’écrire un système d’entraînement, on lui a donné accès à l’émulateur, à l’image complète, à un contrôle précis de la souris, à des sauvegardes permettant de répéter les expériences, ainsi qu’un objectif : comprendre le jeu de manière autonome et écrire un programme joueur.

Le modèle a commencé comme un chercheur. Il a trouvé les paramètres, appris à passer l’écran d’introduction, créé des modèles de chiffres pour lire le score et remarqué que la raquette pouvait traverser tout le terrain en une seule image. Il a ensuite mené une expérience : il a reproduit plusieurs fois la même situation, modifié le point de contact entre la raquette et la balle, puis mesuré la trajectoire. Il a ainsi identifié six zones de rebond. Le programme joueur a commencé à calculer le vol de la balle pour chacune d’elles et à choisir le coup qui détruirait les briques le plus rapidement.

Les premières versions commettaient des erreurs. La raquette tremblait près du bord, la balle restait bloquée dans l’un des derniers niveaux et le boss final tirait des projectiles que le programme n’avait encore jamais vus. Le chercheur examinait les images précédant l’échec, formulait une hypothèse, modifiait le code et répétait le test. Pour le boss, il a ajouté une prédiction du point d’intersection entre le projectile et la ligne de la raquette. Pour les boucles, il a ajouté une règle qui laisse volontairement passer la balle afin de recommencer le service.

Détail important : le LLM n’a pas joué les parties finales. Il a écrit un programme déterministe classique, lisible et testable. Le modèle explorait un environnement inconnu, tandis qu’un code rapide exécutait la stratégie découverte.

Ce qu’il faut appliquer au produit

Première règle : donnez un bac à sable à l’agent. Il peut s’agir d’une copie du CRM sans paiements réels, d’une base de données de test ou d’un émulateur du processus de production. L’agent doit avoir le droit de se tromper, de répéter une expérience et de revenir à l’état précédent.

Deuxième règle : concevez la validation avant l’automatisation. Dans l’expérience, le résultat était mesuré par un évaluateur distinct : il lançait le jeu avec différents délais, lisait le score et confirmait l’écran final. Le chercheur ne pouvait pas s’attribuer lui-même une note. Dans une entreprise, l’équivalent peut être un test automatisé, un rapprochement des soldes ou un ensemble de cas de contrôle.

Troisième règle : séparez la recherche de l’exécution. Le LLM est utile lorsqu’il faut comprendre une situation nouvelle, mener une expérience et proposer une solution. Il vaut mieux confier l’opération répétable à un programme classique, doté d’entrées clairement définies, d’un journal d’activité et de tests.

L’expérience ne prouve pas qu’un agent peut maîtriser n’importe quel système : le jeu est limité, la boucle de rétroaction est rapide et les performances annoncées reposent sur un seul projet. Elle illustre toutefois clairement un principe d’architecture. Un agent puissant n’est pas une fenêtre de chat placée à côté d’un processus. C’est un chercheur intégré à une boucle sûre : observation, hypothèse, expérience, code et validation indépendante.