Les modèles de pointe savent décrire Prince of Persia. Ils ne savent toujours pas y jouer.

Ce que le test a réellement montré

Une analyse largement relayée sur Hacker News a utilisé le jeu de plateforme DOS de 1989 Prince of Persia comme benchmark informel pour des modèles de langage de pointe, en leur demandant d'interpréter des captures d'écran, de planifier des séquences de déplacements et de raisonner sur l'état du jeu. Le résultat qui compte : tous les modèles testés étaient capables de décrire ce qui se passait à l'écran avec une précision raisonnable. Aucun n'était capable de décider de manière fiable de la suite, de façon à garder le Prince en vie au-delà de quelques mouvements. Cet écart, entre une description fluide et une prise de décision fragile, est la conclusion qui mérite qu'on s'y arrête.

Pourquoi un jeu vieux de 35 ans est un bon test de résistance

Prince of Persia a l'air simple. Il ne l'est pas. Chaque écran exige du joueur qu'il lise des indices au niveau du pixel (cette corniche fait-elle une case ou deux ?), qu'il se souvienne des dangers apparus trois écrans plus tôt et qu'il planifie une séquence d'actions chronométrées où un seul saut mal synchronisé signifie la mort et un nouveau départ. Il n'y a aucune marge pour un raisonnement approximatif.

C'est précisément pour cela qu'il révèle ce que les classements de benchmarks tendent à masquer. Les grands modèles de langage sont entraînés sur du texte et, de plus en plus, sur des images, mais leur mécanisme central reste la prédiction du jeton suivant : compte tenu de tout ce qui a été vu jusqu'ici, quel mot ou quel symbole vient ensuite ? Ce processus est extraordinairement efficace pour repérer des motifs et produire des suites plausibles. Il est structurellement faible pour s'engager sur une action précise, vérifier si cette action a fonctionné et mettre à jour un plan en fonction du résultat. Les jeux qui sanctionnent l'imprécision exposent cette faiblesse comme ne le fera jamais un exercice de questions-réponses ouvertes.

Les modèles testés ont su produire des commentaires convaincants sur le jeu, le genre de propos que tiendrait un spectateur averti. Produire la bonne commande suivante, puis la suivante, dans une boucle fermée où chaque choix a des conséquences réelles, est une tâche cognitive entièrement différente. L'analyse n'a pas utilisé d'environnement contrôlé et standardisé, ce qui limite la précision des comparaisons entre modèles, mais la conclusion générale est cohérente avec ce que des benchmarks d'agents plus rigoureux ont montré tout au long de 2025 et jusqu'à cette année.

L'écart entre la démo et le produit

Cela dépasse largement le cadre du jeu vidéo. Les éditeurs qui vendent des agents IA pour l'orientation du service client, le déploiement de code ou les décisions de chaîne logistique prétendent implicitement que leurs systèmes savent faire ce que les modèles de pointe peinent à faire dans Prince of Persia : tenir un plan sur plusieurs étapes, repérer leurs propres erreurs et rebondir. La différence, c'est qu'une corniche mal évaluée fait simplement recommencer une partie. Un environnement de production mal interprété, non.

Cette analyse est un article de blog fondé sur des tests informels, et non un benchmark évalué par des pairs, avec des conditions contrôlées et des graines reproductibles. Il faut le dire clairement. Cela ne rend pas l'observation centrale fausse : cela en fait une invitation à un suivi plus rigoureux, et non un résultat phare à citer lors d'une réunion d'achat.

Les questions à poser

• Quelle est la longueur de la boucle de tâches ? Toute affirmation sur un agent devrait préciser combien de décisions successives le système prend avant qu'un humain ne vérifie son travail. Une tâche en une seule étape et une chaîne autonome de dix étapes ne constituent pas le même produit.
• Comment le système gère-t-il ses erreurs ? Demandez un cas d'échec enregistré, pas seulement une démo réussie. Si l'éditeur ne peut pas vous en montrer un, c'est qu'il n'a pas testé son système sérieusement.
• Le benchmark est-il fermé ou ouvert ? Les modèles obtiennent de bons scores sur des benchmarks qui ressemblent à leurs données d'entraînement. Demandez si l'évaluation a utilisé des scénarios inédits que le modèle ne pouvait pas avoir vus pendant l'entraînement.
• Qui vérifie la sortie avant qu'elle n'ait des conséquences ? Une réponse qui sonne bien et une réponse correcte ne sont pas la même chose. Quel est le point de contrôle humain, et à quelle fréquence détecte-t-il des erreurs ?
• Qu'est-ce qui change entre l'environnement de démonstration et le vôtre ? Les démos contrôlées éliminent le bruit. Les déploiements réels le réintroduisent. Demandez précisément quelles hypothèses la démo a posées que votre cas d'usage ne partage pas.

Ce qu'il faut surveiller ensuite

Le signal à suivre est de savoir si un laboratoire de pointe publie des résultats de benchmarks d'agents, dans des conditions reproductibles et vérifiées par un tiers, montrant des performances soutenues sur des chaînes de tâches d'au moins vingt étapes avec récupération après erreur, et pas seulement l'achèvement d'une tâche quand tout se passe bien. Tant que cela n'existe pas à grande échelle, l'écart identifié par cette analyse reste ouvert, et chaque présentation commerciale d'un agent doit être lue en gardant cela à l'esprit.