Pogofish — l'expérience qui a entraîné l'humain

Pogo est entré dans ma vie par un ami qui en avait la boîte et m'en a expliqué les règles sur un coin de table un soir. Trois lignes, trois colonnes, douze pièces, ni dé ni carte cachée — les deux joueurs voient tout, comme aux échecs. Les règles s'apprennent en cinq minutes. Le jeu, lui, met plus longtemps à s'oublier.

Ce que je cherchais, ce mois-là, c'était une expérience d'apprentissage par renforcementRLApprentissage par renforcement — apprendre par récompenses et punitions, pas par étiquettes.. Le RL — la branche du machine learning où l'on apprend à un programme à jouer en le faisant jouer contre lui-même, des milliers ou des millions de fois, jusqu'à ce qu'une chose qui ressemble à un savoir émerge du bruit. C'est la méthode derrière les programmes qui ont battu les champions du monde au Go, aux échecs, à peu près à tout ce qu'on leur a posé sur la table — et c'est, notoirement, coûteux : les gros joueurs consomment de petits data centers pendant des semaines.

Je n'avais pas de petit data center. J'avais huit gigaoctets de RAM. Ce que je voulais, c'était un jeu assez petit pour que l'expérience tienne sur un laptop — entraîner, évaluer, et affronter le résultat, sur la même machine, dans un temps qui se compterait en jours plutôt qu'en mois.

Pogo, trois lignes sur trois colonnes, ressemblait beaucoup à ce jeu.

Je n'ai pas écrit la première ligne de code ce soir-là. J'ai ouvert un chat avec Claude — une IA générale que j'utilisais depuis plusieurs mois — pour planifier l'expérience.

Dans le chat, j'ai décrit ce que je voulais : un agent RL qui apprenne à jouer à Pogo en s'affrontant lui-même, sur mon laptop, en quelques jours. J'ai demandé à Claude comment structurer le projet.

Claude est revenu avec un plan en cinq phases. Phase un, un moteur de jeu en Python — un bac à sable où un agent RL peut interagir avec les règles. Phase deux, un solveur minimaxMinimaxUne recherche qui joue de façon optimale en supposant que l'adversaire fait de même. : un algorithme par force brute qui lit tous les coups possibles depuis la position courante, puis toutes les ripostes, puis les ripostes aux ripostes, jusqu'à la fin de la partie, et fait remonter les verdicts. Lancé une fois, en amont, il produit la carte complète de chaque position atteignable avec sa valeur exacte — la vérité terrain contre laquelle mesurer ce que le réseau apprendra ensuite. Phases trois et quatre, le RL lui-même : Q-learning tabulaire comme référence, puis deep RL par-dessus. Phase cinq, une page interactive où n'importe quel lecteur peut affronter le réseau entraîné.

Je ne connaissais pas le minimax avant cette conversation. Une fois la logique posée — résoudre d'abord, entraîner contre la solution — la chose tenait. Le plan faisait sens.

Restait une seule question pratique : est-ce que Pogo était assez petit pour que la phase de force brute se termine en un temps raisonnable sur un laptop de huit gigaoctets ?

L'estimation tenait. Un million de positions passées à la moulinette en un après-midi, ce n'était pas un obstacle — ça libérait le terrain pour la partie RL, plus intéressante. J'ai validé le plan et demandé à Claude d'écrire le moteur.

L'estimation allait s'avérer fausse d'un facteur cinquante.

Le moteur a tenu en deux jours. Claude l'a écrit ; j'ai lu chaque commit, posé des questions, lancé les fixtures de test livrées avec. Phase un, faite.

Le solveur minimax est venu ensuite. Claude l'a écrit en Python, en parallèle du moteur. Les deux outils standards de trente ans de recherche en arbres de jeu y étaient : l'élagage alpha-bêtaÉlagage alpha-bêtaUn raccourci qui saute les branches déjà prouvées moins bonnes qu'une précédente. (jeter une branche dès qu'on a prouvé qu'une autre est meilleure) et une table de transpositionTable de transpositionUne table de hachage des positions déjà évaluées, pour ne pas refaire le travail. (mémoriser la valeur de chaque position rencontrée pour ne pas la recalculer si on y revient par un autre chemin). Rien d'exotique. Sur le papier, le genre de solveur qui ratisse un million de positions entre midi et deux.

Je l'ai lancé, j'ai regardé les premières centaines de positions s'évaluer, et je suis parti faire autre chose. Je tenais Claude au courant. Jour un, table à huit cent mille entrées, croissance nominale. Jour deux, plus lente, plausible. Jour trois, la courbe ne ressemblait déjà plus à rien de connu. Jour cinq, elle montait presque à la verticale. Au matin du sixième, le système d'exploitation a tué le processus — plus de mémoire, trente-six gigaoctets résidents, quarante-neuf millions d'entrées dans la table, et pas une seule valeur remontée à la racine. Six jours, aucune réponse, aucun snapshot sur disque.

J'ai eu de la chance, une fois. Le solveur tournait dans un bash à l'intérieur d'une session Claude Code, ce qui voulait dire que l'image mémoire du processus mort était encore accessible depuis la même session : à nous deux, Claude et moi avons sorti la table de valeurs de la RAM dans un fichier Pickle avant la fin de la session. Sur le papier, les six jours de calcul étaient sauvés.

Fort de cette récupération, j'ai demandé à Claude si on pouvait relancer — cette fois en dehors de la session, dans un terminal frais, avec plus de marge. Claude a dit oui.

Ce n'était pas vrai. Le second run est tombé de la même manière au sixième jour, sans Claude Code dessous pour récupérer la mémoire. Cette fois, rien à sauver. Douze jours de calcul, perdus. Un fichier de logs à peu près vide, un ventilateur silencieux depuis une semaine, et un diagnostic à faire.

Après le second échec, Claude et moi nous sommes installés devant le code source et avons compris ce qui s'était réellement passé.

La cause était petite. Pogo n'a pas de captures : les pièces ne quittent jamais le plateau, elles s'empilent. Une même position peut donc être atteinte non par une seule suite de coups, mais par plusieurs — y compris des suites qui la traversent en boucle. Deux joueurs prudents peuvent se renvoyer les mêmes trois pièces entre les mêmes trois cases indéfiniment. C'est aussi vrai pour un algorithme de recherche : rien dans un minimax classique ne l'empêche de faire mille fois le tour du même cycle, en enregistrant chaque tour comme un nouveau chemin.

Voilà ce qui avait avalé trente-six gigaoctets. Les quarante-neuf millions d'entrées que le solveur avait accumulées n'étaient pas quarante-neuf millions de positions distinctes — beaucoup étaient la même poignée de positions rangées sous des suites de coups différentes. La table de transposition ne pouvait rien : elle indexe les positions, pas les chemins, et rien ne disait à la route qui menait à une position stockée qu'elle-même tournait en rond.

Le correctif est connu. Quand la recherche rencontre une position qu'elle a déjà visitée plus haut dans la même ligne de jeu, on traite cette branche comme un nul et on rebrousse chemin. Deux lignes de code ajoutées, trois avec le commentaire. Claude les a écrites.

Pendant que nous étions dans le code, nous avons remarqué autre chose. La condition de défaite de Pogo — on perd quand plus aucune case du plateau n'a sa couleur au sommet, et donc quand on n'a plus de coup légal — laissait en théorie la place, à deux joueurs prudents, à une configuration stable et mutuellement inerte que personne n'avait envie de bouger. Dans une partie ordinaire ça n'arrive presque jamais. Pour une recherche qui essaie tout, ça arrivait sans cesse. Il fallait au jeu une manière plus nette de se terminer, non seulement pour l'algorithme mais pour que le jeu en soit un.

Douze jours de calcul. Deux lignes de code. Trois avec le commentaire.

La modification était petite. Une règle ajoutée : si la même position revient trois fois dans une partie, le joueur au trait perd. Une répétition une ou deux fois fait partie du jeu normal ; trois fois, c'est le signe que personne ne veut s'engager. Cela suffisait à donner au jeu une fin sans ambiguïté, même entre deux joueurs qui s'étaient tacitement mis d'accord pour ne rien faire.

Avec le bug du moteur de recherche corrigé et la règle ajoutée au niveau du jeu, Claude a relancé le solveur. Il a tourné cinquante-quatre minutes. Neuf millions huit cent mille positions distinctes vues, dont environ neuf cent soixante-quinze mille décisives — un camp ou l'autre y avait un gain forcé — et le reste, des nuls. Depuis la position de départ, les deux côtés jouant le meilleur coup possible, la partie est nulle.

Il faut bien, à la fin, que quelqu'un perde.

Phase deux du plan d'origine : faite. Mais le résultat arrive avec une note de bas de page. Pour garder la mémoire bornée, le solveur avait été plafonné à vingt demi-coups de recherche, et tout ce qui restait indécis à cette profondeur était classé nul. Pogo, on l'apprend par là, est plus profond que vingt demi-coups. Certains de ces « nuls » sont des positions dont la vraie valeur ne se règle qu'en regardant plus loin. La force brute mène Pogo jusqu'à vingt. Pas plus loin.

C'est, à la réflexion, le bon cadre pour l'expérience que je voulais dès le départ. Tout ce que la force brute peut prouver est maintenant prouvé. Le reste — les positions encore indécises à vingt demi-coups — est exactement le terrain où l'apprentissage par renforcement justifie sa place. Si un réseau, après assez d'auto-jeu, surpasse l'oracle partiel sur les positions profondes, c'est un résultat réel.

Les variantes que le projet a fini par tester sont de petites variations autour de cette règle de fin : nombres de répétitions différents, plafonds de coups différents, un départage de temps en temps. Le chapitre suivant en fait le tour, et le verdict trie celles qui valent la peine d'être jouées.