Ce guide ordonne les phases de création d’un jeu vidéo. Il n’est pas universel — chaque projet a ses particularités — mais il donne un cadre de référence utile pour situer où vous en êtes et ce qui vient après. Lisez-le comme une carte, pas comme un plan.
Phase 1 — Concept et vertical slice : cadrer avant de construire
La phase de concept est la moins chère et la plus décisive. C’est là qu’on répond à la question : “Est-ce que ce jeu est jouable de façon intéressante pendant 30 minutes ?” La réponse à cette question ne peut pas venir d’un document — elle vient d’un prototype.
Un vertical slice est un prototype fonctionnel d’une tranche représentative du jeu final : un niveau complet, ou une séquence de 10 minutes qui couvre les principales mécaniques. Il est suffisamment poli pour que le playtest révèle des problèmes de game design réels, pas des problèmes de prototype. C’est le livrable qui décide si on continue ou si on pivote.
Erreur classique : passer six mois à écrire un GDD détaillé avant de faire un prototype. Le GDD ne révèle pas les problèmes de game feel. Le prototype, oui. Voir Du pitch au vertical slice.
Phase 2 — Pré-production : décisions structurantes
La pré-production est le moment où on prend les décisions qui seront coûteuses à changer en production : choix du moteur, architecture du code, pipeline d’assets, tone of voice, plateformes cibles. Ces décisions méritent du temps et une documentation claire.
C’est aussi le moment de faire un scope réaliste. Pas le scope optimiste (“si tout va bien, on finit en 8 mois”), mais le scope réaliste avec buffer (“si on compte les retards habituels, c’est plutôt 14 mois”). Le scope irréaliste est la principale cause de projets non terminés dans l’indie. Voir Scope creep : comment le voir venir et Calendrier réaliste.
Phase 3 — Production : itérer sur ce qui existe
En production, la règle est simple : tout ce qui n’est pas en jeu n’existe pas. Le concept parfait sur papier, la feature en cours de développement, le niveau dans un état “presque fini” — tant que ce n’est pas dans une build jouable, ça ne contribue pas au jeu. Cette discipline change la façon d’organiser le travail.
Les playtests réguliers (idéalement toutes les deux semaines sur une build à jour) sont le mécanisme de correction le plus efficace. Pas les playtests avec vos amis qui sont gentils. Les playtests avec des joueurs qui ne vous connaissent pas et qui sont dans votre public cible. Voir Playtests : protocoles pour apprendre vraiment.
Sujets de production à lire dans l’ordre :
- Game feel : inputs, feedback et lisibilité
- Narration et systèmes
- Économie de jeu
- UI/UX : HUD, menus et accessibilité
- Audio : musique, SFX et mix
- Art direction sous contrainte de budget
Phase 4 — QA et builds : la qualité avant le marketing
La QA n’est pas une phase terminale qu’on fait “quand le jeu est fini”. C’est une pratique continue depuis le début de la production. En production indie, ça ressemble à : des tests de smoke sur chaque build, des sessions de régression avant chaque milestone, et une base de bugs tenue à jour même si c’est juste un Notion ou un Trello.
La release d’un jeu bugué est irréversible en termes de réputation sur Steam. Les reviews de lancement pèsent énormément sur l’algorithme, et une vague d’avis négatifs au lancement liée à des bugs est très difficile à corriger après. Voir QA et builds : qualité avant marketing.
Phase 5 — Publishing et lancement
La page Steam, le trailer, les relations presse, la communauté — tout ça devrait idéalement commencer à exister six mois avant le lancement, pas la semaine avant. Le marketing d’un jeu indie est un travail de fond, pas une campagne ponctuelle. Voir Publishing et store pages et Communauté early access.
Après : le post-mortem et la suite
Le post-mortem est un exercice d’apprentissage, pas une autoflagellation. Ce qui a bien marché, pourquoi, et comment on le reproduit. Ce qui n’a pas marché, pourquoi, et ce qu’on change pour la prochaine fois. Fait sérieusement, c’est l’un des meilleurs investissements pour un projet suivant. Voir Post-mortem : apprendre d’un projet terminé.
Et la santé des équipes — Santé des équipes : rythme soutenable — parce qu’un jeu terminé par une équipe détruite par le crunch n’est pas vraiment un succès.