Faire créer un jeu par l’IA n’est déjà plus vraiment une nouveauté aujourd’hui.

Mais si, au lieu de livrer une petite page avec un bouton sur lequel cliquer et un personnage capable de bouger, elle travaillait en continu pendant huit heures, et réalisait les scènes, les modèles, les textures et les sons ?

Felix Rieseberg d’Anthropic a partagé une telle expérience. Il voulait voir, sans ajouter de retours humains, à quoi Claude Fable 5.2 pouvait aboutir en créant un jeu. Selon ses notes publiques, cette exécution a pris environ huit heures, coûté environ 550 dollars selon les tarifs de l’API, cumulé environ 445M de Tokens d’entrée et 2,7M de Tokens de sortie, tout en utilisant largement le cache. Partage original

Ces chiffres ne sont pas nos propres mesures, ni un devis standard pour « créer un jeu ». Toutefois, plutôt qu’une simple phrase comme « le modèle est encore devenu plus puissant », ils permettent au moins de voir une question concrète : lorsque le modèle peut écrire du code de façon continue, jusqu’où les frontières de la création vont-elles se déplacer ?

Cet article ne compare pas des classements, mais examine principalement trois cas publics. Les images proviennent de projets ou d’écrans de démonstration présentés publiquement par leurs auteurs ; les descriptions portant sur le temps nécessaire, les coûts et le processus de génération suivent les indications des sources, sans présenter des expériences personnelles comme des conclusions générales.

Ce qui a été fait en huit heures est un petit niveau, pas une grande œuvre complète

Le jeu présenté par Felix s’appelle Saltline, un projet de jeu de tir à la première personne pouvant être expérimenté dans un navigateur. Accès au projet

Écran de démonstration du jeu Saltline présenté publiquement par Felix Rieseberg

Écran de démonstration de Saltline, tiré de la couverture vidéo du post original de Felix Rieseberg, image statique uniquement citée. Source : post original de l’auteur.

Son prompt n’était pas très long : il voulait un jeu de tir à la première personne, avec des visuels aussi détaillés que possible, mais une portée réduite, pouvant se limiter à un très petit niveau. Prompt public

Le « petit » est ici très important.

Concentrer les ressources de production sur un court segment d’expérience, et créer un jeu commercial riche en contenu, jouable pendant des dizaines d’heures d’affilée, sont deux niveaux de difficulté différents. La mention de visuels de niveau AAA dans le prompt n’est également qu’un objectif, et non une conclusion de qualité obtenue après évaluation.

Ce qui mérite véritablement attention est la manière dont les ressources ont été générées. Felix a ensuite précisé que les textures et les modèles étaient tous des fonctions, sans fichiers image ni fichiers de modèles tridimensionnels, et que le code source se trouvait dans le HTML, où il peut être consulté librement. Précision complémentaire

Selon l’auteur, il ne s’agit pas de commencer par appeler un modèle d’images pour générer une image, puis de la faire bouger, mais de construire par programme les éléments visibles dans la scène.

Cette voie est très attrayante pour les créateurs : si l’on veut modifier une lumière, ajuster les proportions d’un objet ou changer un matériau, on peut essayer de modifier les paramètres et la logique, sans devoir régénérer toute l’image. Pour les contenus nécessitant de l’interaction, le code peut aussi directement prendre en charge la caméra, les collisions et la réponse aux entrées.

Mais pouvoir être modifié ne signifie pas être facile à maintenir. Ici, nous n’avons ni audité le code source du jeu, ni effectué des tests complets de compatibilité sur plusieurs appareils. Une démonstration qui semble réussie reste encore à une certaine distance d’un produit stable.

Par ailleurs, « terminé avec un seul prompt » est aussi facile à mal interpréter. Cela signifie que l’auteur n’a pas continué à guider cette exécution, mais pas que le modèle n’a été appelé qu’une seule fois, ni, encore moins, qu’il a livré le résultat en quelques secondes. Les huit heures et cette facture font tous deux partie de ce cas.

Des centaines de mondes tridimensionnels sont plus intéressants qu’une belle scène unique

L’expérience d’Ethan Mollick a poussé cette idée dans une autre direction.

Il a donné à Fable une description, souhaitant créer un voyage reliant différents mondes tridimensionnels par des portails et permettant d’avancer automatiquement. Selon son récit dans Fable 5.2 and Jagged AGI, après vingt heures, le site contenait 204 mondes ; le nombre consigné plus tard dans l’article avait déjà dépassé 450. Article de l’auteur

Ici, nous ne figeons pas le nombre à un instant donné comme un « résultat final ». Il s’agit d’un projet continuellement mis à jour, dont le nombre évolue ; ce qui est réellement intéressant réside dans son mode de création.

Mosaïque de mondes tridimensionnels de Portals présentée dans l’article d’Ethan Mollick

Mosaïque des mondes du projet Portals, image issue du texte original d’Ethan Mollick. Source : Fable 5.2 and Jagged AGI.

Sur le site Portals, on peut voir une vallée cousue en denim, en train d’être ouverte par une fermeture éclair, et entrer dans une perspective de mouche des fruits dont le monde est un réfrigérateur. Dans un autre monde, les deux côtés d’un canyon ne sont pas des rochers, mais des commodes à tiroirs empilées très haut. Projet de vallée · Projet de réfrigérateur · Canyon de tiroirs

Mollick écrit que ces mondes sont tous dessinés en temps réel par du code, sans utiliser de modèles tridimensionnels préfabriqués ni de fichiers image. Son prompt demandait à des agents d’art, de programmation et d’évaluation de collaborer ; par la suite, il a également formulé des demandes comme une liste de lieux, un mode réduisant le mal des transports et une galerie d’images.

On ne peut donc pas dire que le site final est né « après une seule phrase, sans plus aucune participation humaine ». Le lancement initial était très bref, mais les choix de direction ultérieurs et les ajustements de fonctionnalités étaient toujours réalisés par des personnes.

Pour ceux qui souhaitent créer des animations interactives ou des contenus éducatifs, je pense que ce projet offre davantage de références utiles qu’une image unique réussie. Il suggère que l’on peut laisser le modèle décomposer une idée en règles de scène, relations spatiales, mouvements et paramètres ajustables, plutôt que de seulement écrire une description dans une fenêtre de chat. Par exemple, pour expliquer le mouvement des planètes, on peut transformer l’orbite, la période et la vitesse en variables contrôlables ; pour expliquer la géométrie, on peut permettre aux spectateurs de faire glisser des sommets et d’observer les changements. Il s’agit ici de directions d’application que nous proposons à partir de cas, et non d’une déclaration issue de tests selon laquelle Fable aurait déjà réalisé ces projets pédagogiques spécifiques.

La partie la plus fascinante est peut-être aussi celle qui risque le plus de devenir incontrôlable

L’histoire de Portals ne s’est pas arrêtée à « les mondes sont de plus en plus nombreux ».

Mollick a constaté que la qualité de certaines scènes était inégale, et que différentes équipes avaient tendance à imaginer à plusieurs reprises des idées similaires. Il a demandé au modèle de suspendre l’expansion et de peaufiner d’abord le contenu existant.

Ce qui s’est passé ensuite est très intéressant : les agents ont commencé à mettre en place un processus d’évaluation. Les nouvelles versions devaient être comparées par plusieurs évaluateurs sur des captures d’écran fixes, et les équipes ont donc eu tendance à optimiser pour ces captures ; l’agent chargé de la coordination, après l’avoir constaté, a ajouté davantage de règles.

Selon les notes de Mollick, le document de règles a ensuite atteint 204 sections et environ 87 500 mots. Un projet créatif a progressivement été ralenti par son propre processus d’approbation. Journal du processus

Ce n’est pas seulement une anecdote amusante.

Nous considérons souvent le fait de « vérifier ses propres résultats » comme un avantage, mais la vérification a elle aussi besoin d’un objectif. Si l’on ajoute une règle chaque fois qu’un problème est découvert, sans supprimer les exigences obsolètes, le système peut devenir de plus en plus consciencieux, mais de moins en moins efficace.

De même, avoir une évaluation ne signifie pas avoir du goût. Une capture d’écran conforme, un code qui s’exécute et tous les points de contrôle validés ne signifient pas nécessairement qu’un monde mérite qu’on y reste quelques minutes de plus.

Une observation importante de Mollick au sujet de ces expériences est que le modèle peut accomplir de nombreux travaux complexes, sans nécessairement découvrir de lui-même que l’œuvre est trop longue, trop répétitive ou pas assez intéressante. Il faut toujours, au final, qu’un humain ramène le projet d’une mauvaise direction.

Pour la création, cette limite mérite plus d’attention qu’une petite erreur occasionnelle. Car elle se cache souvent dans le résultat où « chaque étape a été réalisée avec beaucoup de sérieux ».

Le court métrage Blender montre autre chose : le modèle peut coordonner les outils

L’expérience partagée par Riley Brown a, quant à elle, introduit le code dans un processus de production 3D plus traditionnel.

Selon son post original, Fable a écrit le code et construit dans Blender une pièce, une table, un ordinateur portable, un éclairage et un personnage ; l’interface affichée sur l’écran de l’ordinateur était également une page web qu’il avait écrite. Ensuite, le modèle a orchestré 13 plans, ainsi que les actions au clavier, les mouvements du personnage et les changements d’éclairage du crépuscule à la nuit, puis jusqu’au lever du soleil. Post original de l’auteur

Scène d’animation Blender présentée publiquement par Riley Brown

Scène d’animation Blender, tirée de la couverture vidéo du post original de Riley Brown, avec uniquement une image fixe citée. Source : Post original de l’auteur.

Riley a également écrit que le rendu avait utilisé 10 GPU sur RunPod et qu’un rendu 4K avait été achevé en environ 52 minutes, avec ElevenLabs pour la musique et les effets sonores.

Ainsi, il ne s’agit pas de dire que « Fable est lui-même un modèle de génération vidéo ». Plus précisément, il a fait avancer la construction de scène, l’animation, le rendu et la production sonore grâce au code et à des outils externes.

Le post original donne également un chiffre de coût de 5,75 dollars, mais ne fournit pas de facture détaillée complète. Cet article ne l’interprète pas comme un coût général de production finale incluant les appels au modèle, la musique, les effets sonores et toutes les infrastructures, et ne promet pas non plus que les lecteurs pourront reproduire le résultat avec le même budget.

Pour les personnes qui veulent réellement créer du contenu, cette distinction est très utile.

Si la tâche consiste à obtenir rapidement une séquence visuelle, utiliser directement un modèle de génération vidéo peut être plus pratique. Si vous avez besoin d’ajuster les plans à plusieurs reprises, de modifier un objet précis, de conserver les relations spatiales, ou de faire suivre à l’animation des changements de données, un processus 3D piloté par script mérite d’être essayé.

Les deux approches n’ont pas besoin de se remplacer mutuellement. L’essentiel est de savoir quels contenus doivent être contrôlables et modifiables, et quelles parties peuvent être confiées à l’exploration par un modèle génératif.

Si vous voulez vraiment essayer vous-même, remplacez d’abord « faire quelque chose d’impressionnant » par une petite tâche vérifiable

Après avoir vu ces cas, il est facile de vouloir donner directement une phrase au modèle : crée-moi un jeu complet, ou réalise un film d’animation.

Je recommande plutôt de réduire d’abord le périmètre.

Pour un jeu, ne faites qu’une pièce, un itinéraire ou un mécanisme clair ; pour une animation, commencez par un plan ; pour un contenu pédagogique, expliquez d’abord clairement un point de connaissance. Vérifiez d’abord si le modèle peut accomplir dans l’environnement que vous fournissez un cycle de « génération, exécution, observation, modification », puis décidez s’il faut agrandir le projet.

Les prompts n’ont pas non plus besoin d’être formulés de manière trop mystérieuse. Voici une consigne de tâche qui peut être adaptée ; elle relève de nos recommandations pratiques et ne constitue pas le prompt original des auteurs mentionnés ci-dessus :

Veuillez créer une scène interactive pouvant s’exécuter dans un navigateur, ne présentant qu’une idée centrale, sans l’étendre en jeu complet. Avant de commencer, expliquez d’abord la solution technique, les dépendances nécessaires et les étapes d’exécution prévues. Exprimez autant que possible la géométrie, les couleurs et les mouvements de la scène par du code, et regroupez les réglages courants sous forme de paramètres. Livrez d’abord une version minimale exécutable, puis corrigez-la en fonction des résultats réels de l’exécution. Distinguez ce que vous avez déjà testé de ce qui reste à vérifier, et ne remplacez pas les relevés de test par « cela devrait fonctionner ». Sans ma confirmation, n’achetez pas de ressources cloud, ne déployez pas sur Internet et n’accédez pas à des fichiers en dehors du répertoire du projet. Mettez en pause dès que la limite de budget ou de temps convenue est atteinte, conservez le résultat actuel et expliquez les problèmes restants.

L’élément le plus important ici n’est pas la formulation, mais les limites de livraison.

Pouvoir s’exécuter exige une méthode de démarrage et des dépendances clairement définies. Pouvoir être modifié exige de savoir où se trouvent les paramètres et la logique centrale. Pouvoir être vérifié exige des relevés de test, des problèmes connus et les parties qui n’ont pas été achevées.

Les tâches longues doivent également conserver des versions intermédiaires. Si la dernière modification casse la scène, on peut au moins revenir à la dernière version utilisable, au lieu de n’avoir plus qu’un historique de discussion indiquant « correction en cours ». Les systèmes multi-agents peuvent aussi commencer par un petit nombre de rôles clairement définis, plutôt que de faire travailler simultanément des dizaines d’agents dès le départ. Ce que doivent livrer ceux responsables de la production, ceux responsables des vérifications de fonctionnement réel, et ceux responsables de l’évaluation du rendu, devrait idéalement être clairement précisé. Après que l’évaluation a identifié des problèmes, il faut aussi quelqu’un pour décider lesquels méritent d’être corrigés et lesquels doivent s’arrêter là.

Le seuil de création évolue, le jugement n’a pas perdu sa valeur

Dans sa présentation de publication officielle, Anthropic positionne Fable 5.2 pour les travaux techniques difficiles et ouverts, tout en recommandant de commencer la plupart des tâches quotidiennes de programmation et de connaissance avec Opus 5.5, puis de choisir le modèle selon la complexité. Présentation de publication officielle

En replaçant ce positionnement dans les trois cas, il devient plus facile d’en comprendre la signification.

Saltline démontre la possibilité d’une production procédurale de longue durée ; Portals démontre la capacité à construire en lot des mondes créatifs, tout en révélant aussi les répétitions et l’expansion des processus ; le court métrage Blender démontre quant à lui comment le code peut relier différents outils de production.

Tous ces éléments méritent d’être examinés sérieusement, mais il n’est pas nécessaire de se hâter de les résumer par « les créateurs ne sont plus nécessaires ».

Les modèles peuvent nous aider à construire des scènes, écrire la logique, organiser les plans, et même organiser eux-mêmes les vérifications. Mais ce que l’œuvre doit réellement exprimer, pourquoi une image doit s’attarder, à quel moment il faut supprimer la moitié du contenu, et à quel moment c’est déjà suffisamment bon, nécessitent encore que des humains prennent les décisions.

Ce qui mérite peut-être davantage d’être attendu n’est pas que chacun puisse réaliser une grande œuvre avec une seule phrase, mais que certains petits concepts qui ne pouvaient auparavant rester que dans l’esprit aient maintenant l’occasion de devenir des œuvres que l’on peut ouvrir, expérimenter et continuer à modifier.

Sources et précisions sur les images

Les trois images illustrant le corps du texte citent respectivement les images de présentation publiques ou les couvertures de démonstration statiques des projets ci-dessus ; les droits d’auteur appartiennent aux titulaires de droits correspondants et cela ne signifie pas qu’une autorisation de republication a été obtenue ; avant une publication publique, il convient de confirmer la licence d’utilisation des images, la disponibilité des liens externes et les exigences d’attribution. La couverture de l’article reprend l’affiche anglaise Fable 5.2 déjà préparée pour cette création. Cet article est un brouillon d’analyse de cas, et non une évaluation indépendante des performances ; il ne constitue pas non plus une garantie d’utilisation commerciale des projets ou de disponibilité des modèles.

Vous voulez essayer quelques idées de plus ? Réservez davantage de crédits à la création

Créer des scènes interactives, modifier la logique d’un jeu et déboguer des animations de manière répétée : ce qui consomme réellement des Tokens n’est souvent pas seulement la première génération, mais les cycles successifs de modification et de validation. Si vous prévoyez également de transformer ces idées en vos propres petits projets, vous pouvez consulter Ace Data Cloud Coding Plan.

Coding Plan peut se connecter à des outils de programmation courants tels que Claude Code et Codex, vous permettant de continuer à écrire du code, exécuter des tests et ajuster vos œuvres dans un environnement familier. L’offre limitée actuelle ajoute des Crédits sans modifier le prix des forfaits, afin que les forfaits de même niveau disposent de davantage de crédits pour les appels de Tokens.

Forfait Crédit de base Bonus limité Total de l’offre
Coding Plus 400 Crédits 100 Crédits 500 Crédits
Coding Standard 1,200 Crédits 400 Crédits 1,600 Crédits
Coding Pro 3,000 Crédits 1,000 Crédits 4,000 Crédits
Coding Max 8,000 Crédits 2,000 Crédits 10,000 Crédits

Les informations ci-dessus reposent sur les descriptions actuelles des forfaits officiels ; l’offre est prévue jusqu’au 30 novembre 2026 à 23:59:59 (heure de Pékin). Les prix spécifiques, l’éligibilité à la participation et les crédits reçus sont soumis à la page d’achat. Les quatre niveaux de forfait offrent la même portée d’accès aux modèles Coding ; la principale différence réside dans les Crédits inclus.

Les Crédits mentionnés ici sont des crédits d’appel, et non un nombre fixe de Tokens ; le nombre réel de Tokens utilisables dépend du modèle, du ratio entrée-sortie et de la mise en cache. Les forfaits sont gérés par cycles de 30 jours : un renouvellement avant l’expiration permet de reporter les crédits restants et de prolonger la durée de 30 jours ; les crédits non utilisés à l’expiration deviennent invalides. Il n’y a pas de renouvellement automatique, et aucun solde général ne sera débité automatiquement. Pour savoir si Fable 5.2 est disponible et connaître la compatibilité des clients, veuillez vous référer au catalogue actuel des modèles et aux autorisations de vos identifiants.

Il n’est pas nécessaire de relever dès le début le défi d’un grand projet de huit heures. Choisissez d’abord une petite scène que vous voulez vraiment réaliser, faites-la fonctionner, puis peaufinez-la progressivement avec des crédits plus généreux.

Liens associés :