Le parcours de Jev dans Pokémon Red s’est achevé en 37 heures, mais Claude a aidé à construire le système gagnant

Jev a terminé Pokémon Red en 37 heures et 40 minutes, achevant un parcours qui a nécessité 16 150 décisions du modèle. Ce résultat contraste fortement avec de précédentes expériences de chatbots, qui ont passé des semaines ou des mois à errer dans des jeux comparables. Pourtant, cette apparente victoire d’un système non-LLM comporte une nuance importante. Le développeur affirme que Claude Opus 5 a aidé à diagnostiquer les échecs et à améliorer l’environnement de décision autour de Jev.

Cette distinction est importante, car Jev n’observait pas le jeu, ne se souvenait pas de l’intégralité de son parcours et ne manipulait pas directement une manette. Un dispositif logiciel sur mesure lisait certaines données de la mémoire de la Game Boy, construisait des choix autorisés et ajoutait des informations sur chaque option. Jev choisissait ensuite parmi ces actions préparées.

Claude aurait opéré à un autre niveau du système. Il a examiné les journaux, identifié les situations dans lesquelles Jev manquait d’informations utiles et contribué à affiner les options et instructions présentées au modèle de décision. Le parcours remet donc en cause une hypothèse répandue sur les agents IA, mais il n’établit pas qu’un petit modèle de décision puisse, seul, surpasser un chatbot de pointe.

Le parcours de Jev dans Pokémon Red s’est achevé après 37 heures

Le résultat annoncé est réel dans le cadre publié par le développeur, mais il mesure un système logiciel complet plutôt qu’un modèle isolé.

Christian Mathiesen, développeur chez Frigade, a conçu cette expérience open source et diffusé son parcours final du 25 au 26 septembre 2026. Les données de parcours publiées du projet indiquent que Jev a terminé Pokémon Red en 37 heures et 40 minutes.

Le dépôt recense 16 150 décisions et environ 39,2 millions de tokens d’entrée. Une décision typique aurait pris environ 0,4 seconde. Jev a subi 16 défaites complètes de son équipe, dont 14 lors de tentatives contre le Conseil des 4, et a eu besoin de 15 tentatives avant de terminer.

Son équipe finale comprenait un Dracaufeu de niveau 83 et un Gravalanch de niveau 62. Nidoqueen, Dardargnan, Spectrum et Férosinge complétaient le groupe. Ces détails montrent que le système a fait davantage que suivre un court itinéraire prédéterminé dans les premières zones.

Jev a choisi le Pokémon de départ, géré l’équipe, capturé des créatures, sélectionné des attaques, acheté des objets, soigné, entraîné son équipe et décidé où se rendre. Il a également géré les menus et répondu aux invites scénaristiques. Selon le dépôt, le dispositif n’écrivait pas directement dans la mémoire du jeu et ne modifiait pas les indicateurs d’événements.

Le système recevait toutefois bien davantage de structure qu’une personne tenant une Game Boy. Le dispositif lisait la mémoire pour les cartes, les informations sur l’équipe, les conditions de combat, l’inventaire et le texte à l’écran. Il convertissait cet état en choix explicites accompagnés d’informations utiles.

Pour la navigation, du code classique effectuait la vérification des collisions et la recherche de chemin A*, un algorithme qui calcule un itinéraire vers une destination définie. Jev ne décidait pas de chaque pression individuelle sur les boutons directionnels à travers la carte. Il sélectionnait des objectifs de plus haut niveau, tandis qu’un logiciel déterministe gérait une grande partie de leur exécution physique.

Le dispositif incluait également des jalons scénaristiques décrivant le prochain objectif et son emplacement. La progression était vérifiée à partir des véritables indicateurs d’événements du jeu. L’agent disposait ainsi d’une représentation structurée de sa position dans l’histoire, même si les objets cachés restaient dissimulés.

Une protection contre les boucles ajoutait une couche supplémentaire. Des avertissements pouvaient être attribués aux choix déjà tentés lorsqu’ils n’avaient produit aucun changement. Des échecs répétés pouvaient déclencher la sélection d’une alternative. Le système pouvait finalement recharger son dernier point de contrôle.

Ces interventions n’invalident pas le parcours. Tout agent IA pratique dépend de logiciels environnants, de mémoire, d’outils et d’une logique de récupération. Elles signifient toutefois que la réussite pertinente relève d’une architecture d’agent bien conçue, et non d’un affrontement brut entre un modèle et une cartouche.

La conclusion la plus défendable est limitée. Un modèle de décision, associé à un environnement conçu à cet effet et à des contrôles déterministes, a terminé un long jeu exigeant des milliers de choix séquentiels. L’expérience ne montre pas comment Jev se comporterait avec des pixels, un espace d’actions illimité ou sans gestion d’état externe.

Pourquoi Pokémon continue de révéler les faiblesses des agents IA

Pokémon paraît simple à l’échelle des tours individuels, mais ses longues chaînes de décisions interdépendantes pénalisent une mémoire fragile et une mauvaise capacité de récupération.

Le Pokémon Red original est au tour par tour, visuellement limité et indulgent en comparaison d’un jeu d’action rapide. Il exige néanmoins d’un agent qu’il conserve ses objectifs pendant de nombreuses heures. Le joueur doit explorer des cartes, lire des dialogues, constituer une équipe, gérer des ressources et se souvenir des obstacles qui bloquent une progression ultérieure.

Un mauvais choix en combat met rarement fin à toute la partie. Des erreurs mineures répétées peuvent néanmoins épuiser les objets, affaiblir l’équipe ou renvoyer le joueur vers un centre de soins. Un agent doit reconnaître qu’un mouvement localement attrayant peut nuire à son plan à plus long terme.

Cette combinaison a fait de Pokémon un test public pour les modèles d’IA généralistes. En février 2025, Anthropic a équipé Claude 3.7 Sonnet de mémoire, de captures d’écran et d’outils permettant d’appuyer sur des boutons. Ses recherches sur la réflexion étendue décrivaient des sessions de jeu s’étendant sur des dizaines de milliers d’interactions.

L’expérience a mis en lumière des faiblesses que des conversations de chatbot soignées tendent à masquer. Un modèle peut sembler cohérent tout en perdant la trace de son emplacement, en répétant un itinéraire infructueux ou en s’en tenant à un plan dépassé. Un jeu rend ces erreurs visibles, car chaque décision modifie un environnement persistant.

D’autres développeurs ont ensuite diffusé des systèmes reposant sur Gemini, GPT et des modèles Claude plus récents. Certains ont fini par terminer des jeux Pokémon, mais les comparaisons sont restées difficiles. Chaque projet exposait des informations différentes, utilisait des systèmes de mémoire différents et autorisait diverses formes d’assistance du développeur.

Une analyse d’agents de jeu publiée en janvier 2026 décrivait les principaux modèles comme lents, désorientés et sujets à l’excès de confiance durant ces parcours. Cette critique identifiait un problème qui dépasse Pokémon. Les modèles généralistes peuvent produire un raisonnement convaincant même lorsque leur représentation interne de l’environnement est incomplète.

Jev adopte une autre approche. TypeSafe AI le décrit comme un modèle de System One, c’est-à-dire optimisé pour des jugements rapides et bornés plutôt que pour une production de texte étendue. Il accepte du contexte et des questions ciblées, puis renvoie des choix, des scores ou des probabilités de type oui/non.

L’entreprise positionne ces résultats comme des composants intégrés à des logiciels ordinaires. Sa présentation de Jev met l’accent sur la classification, le routage, la notation et le branchement. Elle ne présente pas Jev comme un remplacement de toutes les capacités d’un LLM.

Ce rôle plus restreint convient étonnamment bien à Pokémon une fois que le développeur restructure le jeu. Dans la plupart des situations, le joueur n’écrit pas un essai et n’invente pas un plan ouvert. Il sélectionne une attaque, choisit une destination, achète un objet ou décide de s’entraîner.

La difficulté consiste à générer le bon ensemble de choix et à y attacher les bonnes informations. Si le modèle voit toutes les options pertinentes, un moteur de décision rapide peut faire avancer la partie. Si le dispositif masque un fait crucial, la rapidité ne fait qu’aider l’agent à répéter plus vite le mauvais jugement.

C’est pourquoi le résultat de Jev met sous pression les équipes qui construisent des agents entièrement autour de modèles conversationnels. Il suggère que de nombreuses étapes récurrentes d’un agent n’exigent pas une réponse coûteuse et ouverte. Un modèle spécialisé peut traiter une décision préparée, tandis que du code conventionnel prend en charge les calculs précis et l’exécution.

Il remet également en question l’idée qu’un seul grand modèle devrait assurer la perception, la mémoire, la planification, le jugement et le contrôle au sein d’une conversation continue. Le parcours dans Pokémon répartit ces responsabilités entre des composants distincts. Cette séparation semble être la contribution la plus importante de l’expérience.

Opposer Jev aux chatbots n’est pas le bon débat

Le débat pertinent oppose une IA monolithique à un système réparti qui confie chaque tâche au composant le mieux adapté.

Un chatbot accepte des invites ouvertes et produit du langage. Cette flexibilité lui permet d’expliquer des situations inconnues, de rédiger des plans, d’interpréter des instructions ambiguës et de se rétablir par la conversation. Cette même flexibilité peut créer une latence inutile et un formatage peu fiable lorsque le logiciel n’a besoin que d’une seule sélection.

Jev ne peut pas rédiger un nouveau document stratégique ni décrire librement l’écran. Il renvoie un jugement typé à partir de questions et d’options fournies par l’application. Cette restriction rend sa sortie plus facile à exploiter par le code.

Dans le système Pokémon, la répartition du travail était explicite. L’émulateur produisait un état lisible par machine. Le dispositif transformait cet état, calculait les itinéraires, estimait les résultats des combats et préparait des alternatives autorisées. Jev apportait son jugement là où des règles rigides auraient été maladroites.

Cette architecture ressemble davantage à un flux de production mature qu’à une démonstration de chatbot. Les systèmes fiables séparent souvent les opérations déterministes des opérations probabilistes. Le code doit effectuer les calculs arithmétiques, appliquer les autorisations et valider les schémas. Les modèles doivent traiter les ambiguïtés que des règles fixes ne peuvent pas résoudre proprement.

Le parcours illustre aussi la valeur d’une mémoire externalisée. Jev n’avait pas besoin d’un transcript conversationnel toujours plus long, car le dispositif reconstruisait une description de l’état actuel pour chaque décision. L’historique pertinent devait être stocké par l’application et inséré lorsque nécessaire.

Cette conception réduit le risque qu’un long contexte s’encombre de plans obsolètes. Elle oblige également les développeurs à déterminer quels faits sont importants. Cette clarté peut améliorer la fiabilité, mais elle transfère une responsabilité importante du modèle vers le concepteur du système.

Un chatbot généraliste masque une grande part de ce travail. Les développeurs peuvent transmettre une capture d’écran, fournir un objectif général et demander au modèle de décider de la suite. L’interface paraît simple, tandis que le modèle absorbe la perception, l’interprétation, la planification et la génération de réponses.

Cette simplicité apparente a des coûts qui dépassent le calcul. Lorsqu’un problème survient, le développeur doit déterminer s’il provient de la vision, de la mémoire, du raisonnement, de la sélection d’outils ou d’une instruction imprécise. Une longue réponse en langage naturel peut offrir des indices, mais elle ne garantit pas un diagnostic précis.

Un pipeline de décision typé expose des éléments de preuve différents. Le projet Jev a enregistré l’état complet, les options, les probabilités et la latence pour chaque appel. Les développeurs pouvaient examiner quels choix étaient disponibles et si le modèle exprimait de l’incertitude.

Cette journalisation transforme l’échec d’un agent en une question d’ingénierie plus précise. Le modèle a-t-il mal choisi malgré un contexte adéquat ? Le dispositif a-t-il omis une option nécessaire ? Une bonne décision de haut niveau est-elle devenue une mauvaise séquence de boutons ? Chaque réponse suggère une correction différente.

Cela ne signifie pas qu’un modèle de décision l’emporte toujours. Les environnements ouverts introduisent régulièrement des événements que les développeurs n’avaient pas anticipés. Un modèle à choix limités ne peut pas sélectionner une action que son application ne lui a jamais proposée.

Un chatbot peut parfois inventer un plan de récupération face à une situation inconnue. Il peut interpréter un texte inhabituel, expliquer pourquoi les outils actuels sont insuffisants ou proposer une nouvelle séquence d’opérations. L’interface plus restreinte de Jev dépend d’un autre composant pour accomplir ce travail.

Le cadrage Jev contre LLM masque donc l’architecture qui a réellement réussi. L’exécution achevée combinait un modèle de décision rapide, un traducteur d’état détaillé, du code de recherche de chemin, des points de contrôle, une protection contre les boucles et un modèle de pointe utilisé durant le développement.

Cette pile n’a pas éliminé les grands modèles de langage. Elle en a placé un dans un rôle de supervision.

Claude Opus 5 a guidé le système à travers les impasses

L’implication de Claude transforme le résultat, qui n’est plus une victoire surprise d’un modèle, en preuve d’une architecture IA à deux niveaux.

Selon le récit du développeur relayé par Google News, Claude Opus 5 surveillait les journaux et aidait à ajuster les choix et les formulations fournis à Jev. Ce travail serait devenu important lorsque le modèle de décision rencontrait des impasses.

L’intervention semble avoir pris la forme de modifications durant le développement, plutôt que de voir Claude sélectionner des mouvements à chaque tour de jeu. Cette distinction préserve le rôle de Jev dans les décisions enregistrées. Elle complique néanmoins les affirmations selon lesquelles un système non-LLM aurait réussi de façon indépendante là où les chatbots ont échoué.

Un modèle ne peut bien choisir qu’à partir du monde qui lui est présenté. Supposons qu’un agent se dirige à plusieurs reprises vers un chemin bloqué parce que le prompt n’identifie pas un objet requis. Reformuler les options disponibles peut aider, mais la correction plus profonde consiste à ajouter l’état manquant.

Un modèle de pointe est bien adapté à l’examen de ce type d’échecs. Il peut lire une longue trajectoire, comparer des tentatives répétées, déduire quel fait manque et proposer des modifications au harnais. Ce sont des tâches ouvertes impliquant diagnostic et production de nouveau texte, précisément les tâches pour lesquelles Jev n’est pas conçu.

L’organisation qui en résulte rappelle la distinction entre pensée rapide et pensée lente. Jev traite des jugements fréquents et circonscrits. Claude réalise une analyse moins fréquente lorsque le système se comporte mal ou rencontre une situation que ses concepteurs n’ont pas réussi à représenter.

Il ne s’agit pas seulement d’un compromis imposé par les limites de Jev. Cela pourrait constituer un schéma de production utile. La plupart des événements logiciels sont routiniers, tandis qu’un sous-ensemble plus restreint exige une interprétation plus approfondie. Envoyer chaque événement au modèle le plus performant peut gaspiller des ressources et introduire un délai supplémentaire.

Un modèle superviseur peut à la place analyser les cas incertains, examiner des lots d’échecs ou réécrire la politique de décision. Ses améliorations peuvent ensuite profiter à des milliers d’appels ultérieurs effectués par le composant plus rapide.

Cependant, le processus d’accompagnement nécessite une documentation plus stricte avant que les chercheurs puissent considérer l’exécution comme une comparaison propre. Le résumé public ne fournit pas de référence Jev seul, contrôlée et utilisant le harnais final. Il ne quantifie pas non plus la fréquence à laquelle Claude a modifié le système ni la part des progrès ayant suivi chaque modification.

L’historique du dépôt contient des centaines de commits, ce qui rend son évolution inspectable en principe. Pourtant, une suite de commits de développement n’équivaut pas à un protocole expérimental. Une comparaison correcte gèlerait l’environnement, définirait les règles d’intervention et exécuterait plusieurs essais avec des graines contrôlées.

Il existe une autre source d’ambiguïté. Tout benchmark d’agent inclut un échafaudage logiciel, mais celui-ci peut intégrer une connaissance substantielle de la tâche. Le harnais Jev connaissait les jalons et les lieux de l’histoire, calculait les itinéraires, estimait les dégâts et préparait les actions légales.

Une exécution par chatbot ne recevant que des captures d’écran et des outils de bouton génériques fait face à un problème différent. Elle doit effectuer davantage de perception et de planification à l’intérieur du modèle. Comparer le temps d’achèvement sans harmoniser ces interfaces risque d’attribuer au modèle des avantages fournis par le harnais.

L’interprétation juste n’est ni le rejet ni le triomphe. Jev a pris des milliers de décisions importantes au sein d’un système qui a finalement terminé le jeu. Claude a aidé les ingénieurs à améliorer ce système. Ensemble, ils ont produit un résultat plus rapide que plusieurs démonstrations célèbres de chatbots, mais ils n’ont pas réalisé le même test.

Ce que le résultat ne prouve pas

Une seule partie réussie ne peut établir que les modèles de décision sont généralement plus intelligents, plus autonomes ou plus fiables que les agents LLM.

La plus grande incertitude concerne la reproductibilité. Le résultat publié décrit une exécution terminée après un développement actif du système environnant. Pokémon comporte des rencontres aléatoires, des résultats de combat incertains et de nombreuses configurations d’équipe possibles.

Une seconde exécution pourrait emprunter un autre itinéraire ou se bloquer dans un lieu différent. Répéter l’expérience révélerait si le système termine le jeu de manière fiable ou s’il a bénéficié d’une trajectoire favorable.

La configuration ne dispose pas non plus d’un concurrent comparable. Pour comparer équitablement Jev et Claude, les deux modèles devraient utiliser la même représentation d’état, les mêmes options, la même navigation déterministe, les mêmes règles de récupération et les mêmes points de contrôle. Sinon, le benchmark mesure deux combinaisons différentes de modèle et de logiciel.

Une expérience utile exécuterait trois configurations. L’une utiliserait Jev avec le harnais gelé. Une autre remplacerait Jev par un modèle généraliste tout en préservant tous les autres composants. Une troisième utiliserait le système hybride, avec un superviseur examinant certains échecs sélectionnés.

Les chercheurs compareraient alors les taux d’achèvement, les décisions, les nombres d’interventions, le temps réel écoulé et le comportement de récupération au cours d’essais répétés. Ces mesures montreraient où le modèle spécialisé aide et où un modèle de pointe reste nécessaire.

L’utilisation par le développeur de l’inspection de la mémoire limite également les conclusions plus générales. La lecture d’un état de jeu structuré élimine le problème de la perception visuelle. Ce choix est raisonnable pour tester les décisions, mais il ne démontre pas que Jev peut opérer directement dans des environnements visuels désordonnés.

Les applications réelles proposent rarement des listes parfaites d’options légales. Un routeur de support peut recevoir un nouveau problème qui ne correspond à aucune catégorie connue. Un agent de navigation web peut rencontrer une page remaniée. Un robot physique peut observer un objet que son planificateur n’a jamais représenté.

Les modèles bornés ont besoin de voies de sortie sûres dans ces situations. Des seuils de confiance peuvent transmettre les décisions incertaines à une personne ou à un modèle généraliste. Les applications ont également besoin d’un moyen de détecter lorsque le bon choix manque totalement.

La probabilité seule ne résout pas ce problème. Un modèle peut afficher une forte confiance parmi de mauvaises alternatives, car toutes les options disponibles sont erronées. Les développeurs doivent valider l’ensemble d’actions et surveiller les résultats en aval.

La protection contre les boucles de Jev démontre la nécessité de telles protections. Le harnais marquait les choix inefficaces, échantillonnait des alternatives après des échecs répétés et restaurait des points de contrôle en dernier recours. Ces mécanismes ont empêché un mauvais jugement de piéger le système pour toujours.

Ils signifient également que l’achèvement n’était pas uniquement le résultat de choix corrects à chaque étape. Le système tolérait les erreurs et s’en remettait. L’IA de production doit offrir la même qualité, même si les flux de travail métier ne disposent souvent pas d’un point de contrôle pratique capable d’annuler les dommages.

Une action erronée dans un jeu peut coûter quelques minutes. Une suppression, un paiement ou une réponse client erronés peuvent avoir des conséquences durables. Les développeurs envisageant une architecture de type Jev doivent définir quelles décisions sont réversibles et lesquelles exigent une approbation.

L’expérience dit également peu de choses sur la sécurité. Un modèle qui consomme du texte provenant de sources externes peut rencontrer des instructions manipulatrices ou un contexte trompeur. Limiter la sortie à des choix typés réduit la surface d’action, mais ne garantit pas une interprétation correcte.

Enfin, Pokémon Red est un environnement connu et stable. Ses cartes, mécanismes de combat, menus et structure narrative ne changent pas pendant l’exécution. Cette stabilité permet aux ingénieurs de construire un traducteur d’état inhabituellement détaillé.

De nombreux environnements d’entreprise changent continuellement. Les documents arrivent dans de nouveaux formats, les politiques évoluent et les outils renvoient des données incomplètes. Plus l’environnement est volatil, plus le harnais exige de maintenance.

L’exécution soutient donc une hypothèse de conception, et non un classement universel. Les modèles de décision spécialisés semblent prometteurs lorsque les actions sont bornées, que le contexte peut être structuré et qu’un logiciel déterministe peut exécuter le résultat. Les modèles généralistes restent précieux lorsque le système doit interpréter la nouveauté, générer des plans ou réparer sa propre représentation.

Trois signaux montreront si le résultat de Jev compte

Le prochain test consiste à déterminer si l’architecture résiste à la répétition, aux comparaisons équitables et à des environnements qui n’ont pas été soigneusement préparés autour d’elle.

Premièrement, surveillez l’apparition d’exécutions Pokémon reproductibles utilisant une version gelée du harnais. Plusieurs achèvements autonomes renforceraient l’affirmation selon laquelle le système représente une boucle de décision fiable. Les échecs publiés seraient tout aussi précieux, car ils révéleraient quelles parties de la représentation d’état restent fragiles.

La publication la plus utile inclurait les trajectoires complètes, des versions de modèles fixes, des journaux d’intervention et une définition claire de l’achèvement. Elle devrait distinguer la récupération automatisée des modifications humaines effectuées entre les exécutions. Sans cette séparation, les développeurs ne peuvent pas déterminer si les améliorations proviennent du modèle ou d’un travail d’ingénierie continu.

Deuxièmement, recherchez un test Jev contre LLM équitable. Les deux systèmes devraient recevoir un état, des choix, du code de navigation et des règles de point de contrôle identiques. Cela transformerait le contraste architectural actuel en une comparaison de modèles mesurable.

Un test équitable pourrait montrer qu’un LLM fonctionne de manière similaire, mais répond plus lentement. Il pourrait montrer que Jev excelle dans les choix routiniers tout en échouant dans les situations rares. Il pourrait aussi révéler que le harnais détaillé retire l’essentiel de la charge d’intelligence à l’un comme à l’autre modèle.

Troisièmement, surveillez les applications hors jeu dont les résultats possèdent des étiquettes objectives. Le routage de tickets, les files de modération, la classification de documents, la sélection d’outils et la priorisation d’alertes sont des candidats plausibles. Ces flux de travail produisent des décisions répétées que les équipes peuvent auditer par rapport aux résultats ultérieurs.

La preuve la plus forte ne serait pas une démonstration spectaculaire. Ce serait une précision stable face à des entrées changeantes, une calibration claire, de faibles taux d’exception et une escalade sûre lorsqu’aucun des choix préparés ne convient.

Pour les développeurs, la leçon immédiate est pratique. Ne demandez pas à un seul modèle d’exercer chaque fonction cognitive simplement parce qu’une interface de chat rend cet agencement facile. Séparez la perception, l’état, le jugement, l’exécution, la mémoire et la récupération, puis évaluez chaque frontière.

Les équipes peuvent appliquer la même idée à leurs propres flux de travail IA en conservant le matériel source derrière chaque décision. Une base de connaissances d’ingénierie consultable peut aider les évaluateurs à relier le comportement du modèle aux spécifications, aux journaux et aux correctifs antérieurs.

L’expérience Jev Pokémon Red est importante parce qu’elle rend l’architecture visible. Un modèle ciblé a traité des milliers de choix, un logiciel classique a réalisé des opérations exactes, et Claude aurait aidé à repenser le système lorsque sa représentation échouait.

Ce n’est pas une victoire nette sur les LLM. C’est un argument en faveur d’un usage moins fréquent et plus délibéré de ces modèles.

La prochaine question est de savoir si les développeurs peuvent reproduire cette division du travail sans des mois de réglage propre à la tâche. Si des équipes indépendantes peuvent geler le harnais, répéter l’exécution et transposer ce schéma dans de vrais flux de travail, Jev aura démontré quelque chose de plus vaste qu’une manière inhabituelle de terminer Pokémon Red.