Développer un petit jeu solo : quoi confier à l'IA, quoi garder sous votre contrôle

Après plusieurs semaines à coder avec l’IA, tout fonctionne — puis vous voulez modifier une logique centrale et découvrez que toute l’architecture est enchevêtrée : toucher un point fait tout s’effondrer. Certains développeurs finissent par supprimer tout le code IA et repartir de zéro. D’autres, eux, ont enchaîné 8 prototypes de petits jeux en un après-midi avec l’IA, un volume de travail qui leur aurait pris au moins une semaine avant. Les deux expériences sont réelles, mais mènent à des conclusions très différentes.

Les données du GDC 2026 montrent que 52 % des développeurs estiment que l’IA a un impact négatif sur l’industrie du jeu — près de trois fois plus qu’il y a deux ans. Les artistes s’opposent le plus (64 %), tandis que la direction utilise l’IA à 47 % et les équipes opérationnelles seulement à 29 %. L’écart est net. L’IA n’est ni une panacée ni un fléau en développement de jeux — le vrai enjeu, c’est la frontière. En solo, cette frontière compte double : pas de marge de manœuvre pour rattraper une mauvaise utilisation, mais un bon usage peut multiplier l’efficacité.

Cet article ne liste pas ce que l’IA peut faire — il y en a déjà assez. Je parle de ce qu’elle ne peut pas faire, et surtout : quand vous devez juger vous-même.

La question centrale est simple : pour une tâche concrète, la confier à l’IA ou la faire vous-même ? La réponse ne tient pas à « peut-on », mais à « faut-il ».

Ce que l’IA peut faire — confier le répétitif à l’IA

Commençons par une chose claire : en développement de jeux, l’IA excelle dans plusieurs domaines. Pas « peut-être utile » — en pratique, ça fait gagner du temps.

Après plus d’un an d’usage, avec des écueils et des succès, voici ce que je confie à l’IA : tâches à réponse standard, répétitives, à faible valeur créative.

Génération et complétion de code

Pour la validation de prototypes, l’efficacité de l’IA est visible à l’œil nu.

Un article approfondi de NetEase cite un cas : en réunion de brainstorming, le game designer décompose les besoins et rédige une première version, un bot écoute, puis produit directement du code prototype exécutable. Avant, ce prototype demandait une semaine ; aujourd’hui, un après-midi suffit.

Des retours similaires circulent sur Zhihu. Un développeur explique que pour les questions de maths ou la connaissance des API moteur, l’IA répond en quelques secondes. « Par exemple, comment configurer un Animator Unity ou un URP RenderFeature — ça prend des heures dans la doc, l’IA l’explique en une phrase. »

Mon expérience est proche. Pour la logique de déplacement de base d’un RPG vue du dessus, le squelette de code fourni par l’IA était directement utilisable. J’ai ajouté moi-même le ressenti et la détection de collision, mais la structure venait de l’IA.

Sohu publie un chiffre mesuré : 70 % des fonctionnalités d’une demo RPG vue du dessus en 40 minutes. Je le crois — j’ai à peu près le même rythme.

Attention : on parle ici de « squelette » et de « validation de prototype ». Avant une sortie officielle, repassez le code IA : optimisez, refactorisez. Ne comptez pas sur l’IA pour du code production-ready.

Génération de textes en masse

Point fort de l’IA. Dialogues de PNJ, descriptions de quêtes, textes d’objets, noms de succès — du remplissage, peu créatif, mais volumineux.

Un game designer textuel de NetEase partage sa méthode : confier à l’IA les textes de remplissage « porteurs de sac », quelques minutes, puis relire, ajuster la formulation et calibrer sa propre production sur la sortie IA.

« On utilise l’IA comme groupe de contrôle pour voir si notre texte accuse un écart flagrant. » Une approche pratique — l’IA ne vous remplace pas, elle vous calibre.

Le guide Sohu mentionne : l’IA peut générer 10 quêtes de débutant avec conditions de déclenchement et récompenses. Ce contenu structuré, l’IA le gère bien.

J’ai rédigé une série de descriptions d’objets, environ 50 entrées. Temps : 15 minutes. À la main, au moins deux heures. Écart de qualité : négligeable — une description d’objet n’a pas besoin de haute créativité, juste d’être exacte, concise et cohérente avec l’univers.

Génération de prototypes visuels

L’art est le domaine le plus controversé, mais en phase Demo, c’est utilisable.

Un développeur sur Zhihu partage : en Demo, l’art IA temporaire « ne dépare pas ». L’essentiel : ne pas viser la sortie directe — erreurs d’anatomie, style incohérent, détails grossiers, tout cela demande un artiste pour retoucher.

J’ai fait une Demo avec des aplats de couleur pour personnages et arrière-plans. Mes amis ont dit « ça va ». Mais je savais que c’était provisoire ; pour publier, il faudrait un vrai artiste.

Du point de vue d’un dev indie, l’art IA en Demo est un choix pragmatique — pas de budget art, mais besoin d’un visuel pour valider le gameplay.

La clé : usage temporaire oui, sortie officielle non.

Extension créative et validation de prototype

Ici, l’IA joue surtout le rôle d’« assistant de référence ».

Le guide Sohu cite Ludo.ai, qui analyse les données Steam et TapTap pour générer des concepts de jeu. Pour ce type de veille marché, l’IA est plus rapide — gros volumes, nombreuses dimensions, analyse manuelle trop lente.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Un article ACM ajoute : l’IA peut soutenir le processus créatif, mais ne doit pas remplacer la décision créative. En clair, l’IA vous propose des options ; le choix, c’est vous.

J’ai testé la génération d’un cadre GDD : à partir d’une description de gameplay centrale, l’IA a produit 5 directions d’extension possibles. J’en ai approfondi 2. Le rôle de l’IA : « élargir la réflexion », pas « décider ».

Ce que l’IA ne peut pas faire — à juger vous-même

On a vu ce qu’on peut confier à l’IA ; voici ce qu’il ne faut pas lui confier.

C’est plus important. Mal utiliser l’IA coûte souvent plus cher que ne pas l’utiliser.

Décisions créatives et game feel

Gameplay central, univers, expérience émotionnelle — l’IA ne sait vraiment pas faire.

Un article ACM résume bien : « L’IA n’a pas de compréhension du jeu. » Elle sait écrire du code, pas ce qu’est « amusant ».

Un texte Medium va plus loin : la magie du jeu n’est pas dans le code, mais dans le « feel ». Sensation, rythme, flux émotionnel — le développeur doit les vivre et les ajuster.

Eric Barone, auteur de Stardew Valley, incarne l’opposition à l’IA dans l’industrie : « la créativité humaine doit primer sur la machine sans âme ». Un peu radical, mais du côté créateur, c’est juste. Le rythme de la ferme, la chaleur des interactions avec les villageois, la satisfaction de la récolte — ce n’est pas du code, c’est une expérience peaufinée par le designer.

J’ai fait un jeu de flipper : les paramètres physiques de l’IA tournaient dès le départ. Mais le « feel » était faux — rebonds trop durs, rythme trop rapide, aucun sentiment de contrôle. Trois jours de réglages, d’innombrables paramètres, pour trouver ce « satisfaisant sans déraper ».

L’IA donne du code, pas le « feel ».

Direction artistique

L’art est le domaine le plus disputé et celui où l’IA dérape le plus.

Sur Zhihu : erreurs d’anatomie, retouches nécessaires par un artiste pro. Doigts en trop, perspective incohérente, éclairage mal équilibré — des défauts visibles d’un coup d’œil pour les joueurs.

Sur Reddit : l’art IA « ne peut pas suivre une direction artistique fixe ». Vous voulez du pixel art, l’IA sort du cartoon ; vous voulez des tons froids, elle chauffe la palette. La cohérence de style est le cœur de l’art de jeu ; l’IA y est presque désastreuse.

Des artistes de terrain constatent : ce que l’IA produit n’est pas fiable ; retoucher coûte plus cher que dessiner.

J’ai généré des avatars de personnages pour une Demo : 5 styles totalement différents — cartoon, réaliste, pixel, anime, indéfinissable. Suppression, puis commande à un vrai artiste.

La cohérence de style est la faiblesse de l’IA ; pour l’instant, pas de solution.

Conception d’architecture et compréhension des problèmes

C’est le cœur du cas Reddit « tout supprimer et repartir de zéro ».

Le code IA tourne, mais l’architecture est souvent enchevêtrée. Couplage fort entre fonctionnalités : modifier un point en impacte d’autres. On appelle ça un « cauchemar architectural ».

L’article ACM qualifie l’IA de « collègue mal informé » — compétence technique, mais compréhension superficielle. Elle sait implémenter, pas pourquoi ni quel impact à long terme.

Un développeur sur Zhihu résume : « sur les questions de conception, l’IA n’aide pas. »

Qu’est-ce qu’une question de conception ?

• Quel est le mécanisme central de votre jeu ?
• Comment les systèmes interagissent-ils ?
• Quelles extensions prévoyez-vous ?
• Où sont les goulots de performance ?

Pas de réponse standard : c’est à vous de réfléchir. L’IA peut assister, pas décider.

Une phrase du fil Reddit original : « utiliser l’IA limite fortement la capacité de revenir en arrière et d’ajuster ». Architecture floue, vous voulez changer une logique, l’impact est trop large — vous êtes bloqué.

Sécurité et contrôle de la maintenance

SonarSource signale : le code IA peut cacher des failles. Validation d’entrée absente, contrôles d’autorisation oubliés, données sensibles exposées — des détails que l’IA oublie facilement et qui deviennent fatals en production.

Le BSI allemand recommande : les assistants de code IA exigent la supervision d’un développeur expérimenté. Pas une interdiction, mais une revue humaine après usage.

À long terme, le problème est plus insidieux : code sans commentaires, sans doc, sans note de design. Trois mois plus tard, vous ne comprenez plus ce que vous avez écrit.

J’ai vécu ça. Un module généré par l’IA tournait bien en prod. Six mois après, nouvelle fonctionnalité : code totalement étranger — noms de variables confus, sauts logiques bizarres, zéro commentaire. Deux jours de refactoring, plus long que si j’avais codé moi-même.

L’IA peut réduire le temps de développement, pas forcément celui de maintenance. Beaucoup l’oublient.

Cadre de décision — quand déléguer, quand agir soi-même

« Peut » et « ne peut pas » posés, la réalité met souvent les tâches entre les deux.

Il faut alors un cadre de décision.

Questions de connaissance vs questions de conception

Sur Zhihu, une règle simple : « questions de connaissance → IA ; questions de conception → vous. »

Question de connaissance ? Réponse absolue. Par exemple :

• Comment configurer une machine à états dans Unity Animator ?
• Comment implémenter la détection de collision dans Cocos Creator ?
• Comment calculer cette formule ?

L’IA répond avec précision : réponse unique, vérifiable.

Question de conception ? Pas de réponse absolue, jugement esthétique et expérience requis. Par exemple :

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

• Le gameplay central est-il amusant ?
• L’univers est-il cohérent ?
• Le ressenti est-il fluide ?

L’IA ne peut pas répondre : tout dépend de votre goût, de votre public, de votre philosophie de design.

Mon réflexe : « cette question a-t-elle une réponse standard ? »

Oui → IA.
Non → réflexion personnelle.

Pour un saut, l’IA donne le squelette de code. Mais quelle hauteur ? Quel temps en l’air ? Quel feedback à l’atterrissage ? C’est vous qui réglez — le « feel » n’a pas de standard.

Phase prototype vs phase production

La phase compte aussi.

En prototype, l’objectif est de valider une idée, pas la qualité de sortie. Osez l’IA — le code doit tourner, l’art peut être des aplats, le texte provisoire.

En production, face aux joueurs, l’expérience doit être complète. Contrôle humain strict — refactoring, art peaufiné, textes polis.

Les chiffres Sohu : 70 % d’une demo RPG en 40 minutes, en prototype. Pour en faire un produit publié, 40 minutes ne suffisent pas — 30 % de fonctionnalités centrales à compléter, architecture à refactoriser, art à remplacer, textes à relire.

Le cas NetEase est similaire : prototype en un après-midi avec l’IA, développement officiel sous contrôle humain.

Mon jeu de flipper : code IA opérationnel en 20 minutes. Version publiable : deux semaines de plus — feel, performance, niveaux, UI.

Prototype : l’IA accélère. Production : prudence.

Tâches répétitives vs créativité centrale

Critère plus direct.

Tâches répétitives : faible valeur créative, chronophages, répétitives. Dialogues PNJ en masse, descriptions d’objets, noms de succès.

Créativité centrale : haute valeur, âme du jeu. Branches narratives, innovation mécanique, personnalité des personnages.

Répétitif → IA, gain de temps sans perte de qualité.
Central → vous, avantage compétitif du jeu.

Chez NetEase : remplissage à l’IA, narration centrale en main propre. Gain de temps sans sacrifier la créativité.

J’ai écrit un système de dialogues PNJ, ~100 lignes. Bavardages quotidiens, apartés hors intrigue — IA, 15 minutes. Intrigue principale, répliques clés, tournants émotionnels — moi, deux jours.

Répétitif avec l’IA, central par vous. C’est la division la plus efficace.

Tableau de décision simple :

Trois questions à chaque tâche :

1. Y a-t-il une réponse absolue ?
2. Faut-il mon jugement esthétique ?
3. Prototype ou production ?

Les réponses deviennent claires.

Cas pratiques — frontières par métier

Cadre posé, voyons l’application par métier.

Chaque métier a des tâches différentes, donc des frontières IA différentes.

Game design

Le game designer couvre un large spectre ; l’IA a de nombreuses entrées.

Cas NetEase : en brainstorming, décomposition des besoins et première rédaction, bot en écoute, puis code prototype exécutable. Usage typique — transformer une idée en quelque chose de vérifiable rapidement.

Mais le cœur du métier reste la décision créative : univers, gameplay central, structure narrative. L’IA ne peut pas, vous devez.

Un game designer a généré 10 propositions de gameplay avec l’IA, puis en a approfondi 3. Rôle de l’IA : « élargir », pas « décider ».

Frontières IA pour le game design :

• IA : découpage des besoins, première rédaction, notes de brainstorming, code prototype
• Vous : univers, gameplay central, décisions créatives, structure narrative

Rédaction / narrative design

Frontières relativement nettes.

NetEase : remplissage à l’IA, narration centrale en main propre, puis calibration sur la sortie IA.

Concrètement :

• IA : dialogues quotidiens PNJ, descriptions d’objets, noms de succès, textes de quêtes
• Vous : intrigue principale, répliques clés, textes d’univers, tournants émotionnels

Pour un système de dialogues PNJ : bavardages et apartés sans enjeu narratif — IA, 15 minutes (« il fait beau », « les affaires marchent mal »). Intrigue, répliques du antagoniste, dialogues porteurs de personnalité — moi, car chaque mot porte de l’émotion.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Le remplissage IA fait gagner du temps, pas de l’émotion. La valeur du texte, c’est l’émotion — à garder sous votre contrôle.

Programmation

Métier le plus intensif en IA, aussi le plus controversé.

GDC : 36 % utilisent l’IA, surtout pour code et workflow, pas pour la génération d’assets. Acceptation relativement haute, mais avec limites.

Recommandation ACM : les développeurs expérimentés supervisent le code IA pour éviter les failles. Pas une interdiction, une revue après usage.

Frontières pour les programmeurs :

• IA : complétion de code, réponses API, calculs, validation de prototype
• Vous : architecture, logique complexe, optimisation performance, sécurité, maintenance long terme

Le cas Reddit « tout supprimer » est l’anti-exemple : code qui tourne, architecture enchevêtrée, impossible d’évoluer.

Mon habitude : l’IA pour le cadre, moi pour la logique centrale et l’architecture. Fonctions simples, code répétitif, recherche doc → IA. Architecture système, chemins critiques, sécurité → moi.

Art

Métier le plus prudent avec l’IA.

Reddit : l’art IA « ne suit pas une direction artistique fixe ».

Zhihu : erreurs d’anatomie, retouches pro nécessaires.

Frontières pour les artistes :

• IA : art temporaire en prototype, assets de demo, aplats de remplacement
• Vous : correction anatomique, cohérence de style, qualité visuelle, art de sortie

Demo avec avatars IA : styles incohérents, suppression, vrai artiste. Leçon : IA en demo oui, sortie officielle non.

La valeur centrale de l’art, c’est la cohérence. L’IA mélange les styles ; retoucher coûte plus cher que dessiner. Pas de solution pour l’instant.

Tableau comparatif par métier :

Plus la créativité est faible, plus l’acceptation est haute. Plus elle est centrale, plus la prudence est forte.

Chez NetEase : direction à 47 %, terrain à 29 %. Les équipes opérationnelles connaissent mieux les limites — usage quotidien, elles savent ce qui tient la route.

Conclusion

Revenons au développeur Reddit qui a tout supprimé pour repartir de zéro. Ce n’est pas un rejet de l’IA, c’est trouver la bonne frontière.

Le blog Sealos résume : l’IA est un « outil », pas un « architecte ». L’outil abaisse la barrière ; l’architecte fixe la direction. Le développeur solo reste directeur créatif ; l’IA n’est qu’un accélérateur.

Le modèle le plus efficace ? GDC et NetEase convergent : IA pour le répétitif + vous pour la créativité centrale.

Ce n’est pas « tout à l’IA » ou « jamais l’IA ». C’est une division — confier ce qui doit l’être, garder ce qui ne doit pas.

Trois habitudes de jugement :

1. Distinction connaissance vs conception. D’abord : y a-t-il une réponse standard ? Sinon, réfléchir soi-même.

2. Distinction prototype vs production. Prototype : oser l’IA. Production : contrôle strict.

3. À chaque usage IA, se demander : valeur créative élevée ? Jugement esthétique requis ? Impact sur la maintenance long terme ?

L’IA ne répond pas à ces questions. C’est la compétence centrale du développeur solo — le jugement.

Le jugement vient de l’expérience. Utiliser l’IA n’accumule pas le jugement, seulement la dépendance. Le jugement ne se construit qu’en jugeant.

L’IA est un bon outil — ne la laissez pas juger à votre place.

Pour le « comment » concret avec l’IA, consultez l’article 13 de cette série « Développer un petit jeu Cocos avec l’IA : mon workflow complet et comparaison d’efficacité », qui détaille les méthodes. Pour apprendre à rédiger des besoins pour l’IA, voir l’article 14 « Rédiger des besoins de développement de jeux pour l’IA : scènes, nœuds, composants, interactions ». Cet article pose le cadre de décision ; les suivants détaillent la pratique.