Le Jeux Vidéo en 2026 — Prototype d’abord, budget ensuite : comment l’IA m’a permis d’avancer seul

Le développement de jeu vidéo indépendant commence presque toujours au même endroit : une idée forte et zéro budget pour la prouver.

Le paradoxe est brutal. Les éditeurs, les commissions de subvention, les investisseurs veulent voir une vertical slice — un fragment jouable, visuellement cohérent, qui montre que l’idée tient debout. Mais pour construire ça, il faut un designer, un artiste, un développeur. Et pour payer ces gens, il faut du budget.

L’œuf et la poule.

Je développe seul, depuis plusieurs mois, un jeu narratif dans Unreal Engine 5.7. 25 ans de développement logiciel — de la ligne de code à la direction de projets complexes — mais jamais de jeu vidéo, jamais d’Unreal Engine, et pas le profil d’un artiste 3D. Ce n’est pas un manque de bagage technique en général : c’est une frontière précise, celle du jeu, que je n’avais pas franchie. Et pourtant, je suis en train de finaliser un prototype jouable, avec une direction artistique définie, des visuels de référence pour une vingtaine de personnages, et une architecture technique documentée.

Cet article n’est pas un éloge de l’IA. C’est un compte-rendu honnête (j’espère) de ce que ça donne réellement — avec les ratés, les outils qui ont déçu, et les ajustements constants que cette approche impose.

Le vrai problème : convaincre sans avoir rien à montrer

Quand on cherche du budget pour un jeu, on vend une idée. Mais une idée, même forte, reste abstraite tant qu’elle n’a pas de forme. Les phrases comme ”c’est un roguelite narratif sans combat, avec une ressource centrale qui sert simultanément de monnaie du jeu et de signe vital du monde” donnent une intuition — pas de conviction.

Les outils de financement que j’explore (subventions type CNC, appels à projets, pitchs à des éditeurs indé) demandent tous la même chose : montrez-moi. Une image, une vidéo, une capture d’écran. La première étape, avant même d’écrire une ligne de code, c’était donc de générer ce langage visuel. Pas pour que ce soit beau. Pour que ce soit communicant.

Le pipeline visuel : explorer, générer, nettoyer, intégrer

Je n’aurais pas pu faire ça sans outils génératifs, et je ne vais pas faire semblant du contraire.

Gemini pour la direction artistique

Pour explorer des directions visuelles, j’ai utilisé Nano Banana Pro— le modèle de génération d’images construit sur Gemini 3 Pro, accessible directement depuis l’app Gemini. Pas pour “générer des assets prêts à l’emploi” — ça ne marche pas comme ça. Mais pour tester des palettes, des ambiances, des types de composition. Le modèle génère rapidement des variations que je n’aurais pas su dessiner, et me permet de choisir parmi elles.

Le process n’est pas uniquement textuel. Selon les cas, j’ai fourni en entrée des crayonnages rapides pour donner une orientation de forme ou de composition, ou des captures d’autres jeux dont j’aimais le style graphique. Le modèle ne partait pas d’une page blanche guidée par des mots — il partait d’une intention visuelle déjà esquissée, même grossièrement. Ça change beaucoup la cohérence du résultat.

Le résultat n’est pas de l’art final. C’est un brief visuel que je peux montrer à un futur artiste et dire : “je veux quelque chose dans cette direction-là.” La direction artistique choisie — stylized-realistic PBR aurait pris des semaines à communiquer avec des mots. Avec des images générées à partir de mes propres références, c’est immédiat.

Tencent Hunyuan 3D pour la modélisation

Pour les objets narratifs clés — ceux trop spécifiques pour exister sur un marketplace — j’ai utilisé Hunyuan 3D de Tencent pour la modélisation 3D.

Résultat brut : peut être de temps à autre inutilisable directement. Topologie incorrecte, maillage non-manifold, UVs inexistantes ou désorganisées. Ce n’est pas toujours un outil “prêt à l’emploi” — c’est un point de départ, gratuit.

Blender + Mixamo + Modddif pour le nettoyage, le rigging et le texturing

Chaque mesh généré passe ensuite dans Blender pour la correction manuelle. Pour les meshes de personnages, le rigging est assuré par Mixamo (Adobe) — l’outil génère automatiquement un squelette et une skin weight correcte à partir d’un mesh propre en T-pose ou A-pose. Résultat : un personnage riggé et animable en quelques minutes, sans passer par le rigging manuel dans Blender. Puis Modddif pour le texturing.

C’est là que la réalité rattrape l’enthousiasme. J’ai généré des objets qui avaient l’air corrects en aperçu et qui étaient pas toujours facile à texturer proprement. J’ai retentré plusieurs fois le même asset avant d’obtenir quelque chose d’utilisable. La chaîne Hunyuan 3D → Blender → Mixamo → Modddif → UE5.7 fonctionne, mais elle est fragile — chaque outil a ses propres incohérences, et les erreurs se cumulent.

Ce pipeline m’aurait coûté plusieurs jours de commande à un artiste externe. Ça m’a coûté du temps d’exploration et de la patience. Ce n’est pas forcément “moins cher” en heures — mais c’est accessible sans budget. Et nous ne faisons à ce stade qu’un proto donc ça reste acceptable.

Le pipeline code : Claude Code comme encyclopédie contextuelle

Pour la partie développement, j’utilise Claude Code (Anthropic). L’analogie qui colle le mieux : c’est une encyclopédie technique qui répond aux questions sur mon projet, pas sur UE5 en général.

La différence avec un tutoriel YouTube, c’est le contexte. Un tuto explique comment implémenter un inventaire dans UE5. Claude Code m’aide à implémenter mon inventaire, avec mes contraintes — 12 slots maximum, persisté dans le GameInstance, synchronisé avec un Widget dynamique, vidé à chaque run mais avec un état de réserve séparé. Ce n’est pas la même chose.

Résultat concret : un prototype jouable avec boucle complète (hub → exploration → retour), système de craft fonctionnel, inventaire géré, save/load opérationnel. Mais chut, j’en dirais plus, plus tard !

Mais j’ai aussi compris la limite principale de cet usage : l’IA génère du code qui **semble correct et qui peut introduire des bugs subtils que je ne détecterais pas sans comprendre ce qu’il fait**. J’en parle plus en détail dans l’article 2 de cette série.

Ce que ça change pour trouver du budget

Aujourd’hui, si je pitch mon jeu à un éditeur ou à une commission, je n’arrive pas avec un document Word et des mots. J’arrive avec :

• Une direction artistique visuellement définie — palettes par zone, évolution chromatique avec la progression du jeu, visuels de référence pour les personnages et les environnements

• Un prototype en cours de finalisation — la mécanique centrale devient expérimentable, pas seulement décrite

• Une documentation technique qui montre que je comprends ce que je construis

Aucun de ces éléments n’est de niveau “production final”. Mais tous montrent que l’idée tient, qu’un joueur peut vivre quelque chose, que la vision est cohérente. C’est ça que les décideurs cherchent à ce stade.

L’IA m’a permis d’atteindre ce point seul, sans budget externe, dans un délai qui n’était pas envisageable avant.

Au-delà du greybox : quand l’ambiance est un personnage du jeu

Un prototype avancé visuellement, c’est aussi ce qui rend possible les premiers beta tests réels.

Le greybox — cubes gris, pas de textures, pas de musique — est une approche valide pour certains types de jeux. Pour un jeu d’action ou un platformer, le game feel se teste très bien en greybox : ce qui compte est le mouvement, la réactivité, la précision. L’habillage peut attendre.

Mais quand les décors, la musique, l’ambiance et la narration sont eux-mêmes des personnages du jeu — quand c’est la couleur d’un bassin qui dit au joueur que le monde se dégrade, quand c’est l’architecture d’une zone qui porte l’émotion, quand la bande sonore n’est pas un fond mais une information — mettre un beta testeur devant du greybox, c’est lui faire tester un jeu qui n’existe pas encore.

Il ne ressentira pas ce qu’il est censé ressentir. Son retour sera biaisé par l’absence de ce qui fait le jeu.

Avoir un prototype plus proche du design final — même imparfait, même partiel — permet d’obtenir des retours sur ce qui compte vraiment : est-ce que l’émotion passe ? Est-ce que la mécanique centrale crée la tension prévue dans ce contexte visuel et sonore précis ? C’est une question à laquelle seul un prototype habillé peut répondre.

Ce que je ne prétends pas

L’IA n’a pas inventé mon jeu. Elle n’a pas pris de décision créative à ma place. Elle n’a pas de goût, pas d’intuition, pas de conviction sur ce qui doit exister et ce qui doit être abandonné.

Les décisions difficiles — quel mécanisme supprimer parce qu’il contredit l’intention du jeu, quelle direction artistique garder parce qu’elle incarne quelque chose que les autres ne capturent pas, quel compromis accepter entre ambition et faisabilité — ces décisions sont entièrement les miennes. Et elles sont les plus importantes.

L’IA est un accélérateur. Mais elle n’accélère que là où il y a déjà une direction claire. Sans vision, les outils génèrent du bruit cohérent.

Certains outils sont aussi franchement immatures : topologie incorrecte sur les meshes générés, textures qui ne respectent pas le style attendu, assemblages visuels incohérents. On se trompe, on retente. C’est l’exploration qui a de la valeur, pas la solution parfaite du premier coup.

Et maintenant ?

Le prototype commence à exister. Le budget pour la suite — développement alpha, recrutement d’artistes, polish — restera à trouver. Mais le langage pour le demander est là.

La prochaine étape : finir le proto pour explorer les mécaniques, proposer l’ambiance puis faire jouer des gens. Valider que la mécanique centrale crée l’émotion qu’elle est censée créer. Et corriger ce qui ne fonctionne pas… même si ça veut dire recommencer une partie du pipeline.

Si vous développez un projet seul — un jeu, un produit créatif, quelque chose d’ambitieux — et que vous cherchez comment franchir le même seuil : quelle partie vous coince le plus ? Le visuel, le code, le design, la communication avec les financeurs ?

Je serais curieux de savoir où en sont les autres.