Un game design document (GDD) c'est littéralement la bible de votre jeu. C'est ce qui transforme « j'ai une idée cool » en « on sait ce qu'on va faire pendant les trois prochains ans ». Sans GDD, votre équipe tâtonne dans le noir. Avec un bon GDD, tout le monde avance dans la même direction.
Le problème ? Les GDD traditionnels sont souvent des monstres de cent pages que personne ne lit. J'ai vu ça en relisant mon travail sur un faux-amoureux où j'avais écrit 80 pages, et ensuite la moitié de l'équipe ignorait les règles de combat. En 2026, le mouvement agile dans le game dev a changé la donne : les GDD modernes sont vivants, concis, et ils évoluent avec votre projet. Ce qu'on va voir ici, c'est comment balancer structure et flexibilité.
Pourquoi un GDD, concrètement ?#
Si vous codez seul dans votre chambre, un GDD peut sembler overkill. Mais même en solo, c'est votre sauvegarde cérébrale. Trois mois plus tard, vous revisitez votre concept et vous vous souvenez de pourquoi ce système économique fonctionne d'une certaine façon. C'est la documentation qui sauve votre santé mentale.
En équipe, c'est critique : designers, programmeurs, artists ne parlent pas la même langue. Le GDD c'est votre traducteur commun. « Combien de temps fait un level ? » « Regarde la section 'Level Design', page 4. » Plus de débat, plus de flou.
Pour les investisseurs, les éditeurs ou les concours de game jam, c'est votre pitch documenté. « Regardez, on a pensé à tout. »
Structure minimale pour commencer#
La bonne nouvelle : vous n'avez pas besoin de tout en même temps. Voici une structure légère que vous pouvez étoffer au fur et à mesure :
Le One-Pager d'abord#
Avant même d'ouvrir un document de cent pages, commencez par une page. Une seule. Dedans :
- Titre du jeu
- Genre + hooks principaux (ce qui le rend unique)
- Plateforme (PC, consoles, mobile)
- Public cible (âge, type de joueur)
- Core gameplay loop en 2-3 phrases
- Aesthetic (graphismes, direction artistique)
- Influences (2-3 jeux auxquels on ressemble ou dont on s'inspire)
Exemple : « Neon Vault. Héist game en isométrie. PC/Switch. Joueurs 20-40 ans, fans de Hyper Light Drifter + Hades. Bande-son synthwave. Core loop : infiltrer un building futuriste, trouver les codes de sécurité, voler le truc, sortir sans être vu. Influences : Deus Ex (liberté tactique) + Hotline Miami (esthétique électro). »
Voilà. Vous tenez votre concept.
Les sections indispensables d'un GDD complet#
Une fois que le one-pager est validé, étendez-le en sections thématiques :
1. Overview & Creative Vision
Résumé général, tone du jeu, vision long terme. « Quel sentiment on veut que le joueur ressente ? » Angoisse ? Euphorie ? Paix ?
2. Core Systems
- Gameplay loop : qu'est-ce que le joueur fait, encore et encore ?
- Mécaniques principales : si c'est un jeu de combat, détail du système. Combien de boutons ? Cooldowns ? Timing-based ou pas ?
- Progression : comment le joueur progresse (XP, skill tree, déblocages) ?
- Économie : s'il y a des ressources/monnaie, comment ça fonctionne ?
3. World & Narrative (si pertinent)
- Décor/ambiance générale
- Histoire principale (sans spoilers, juste la prémisse)
- Arcs narratifs majeurs
- Personnages clés et leurs motivations
Pour un jeu sans narration (ex : un puzzle game), passez cette section.
4. Level Design
- Structure générale des niveaux
- Difficulté progressive
- Dimensions approximatives, longueur de session
- Points de sauvegarde
- Pièges spécifiques à éviter (trop facile, trop frustrant, etc.)
5. Art Direction
Pas une galerie, mais des directives :
- Palette de couleurs
- Style (réaliste, cartoon, pixel art, etc.)
- Inspirations visuelles
- Spécificités pour les assets (taille, résolution, format)
6. Audio
- Bande-son générale (ambient, thématique)
- SFX prioritaires (bruitages qu'on ne peut pas oublier)
- Voix ? Dialogue ?
- Tone sonore global
7. Technical Requirements
- Moteur (Unity, Godot, Unreal, etc.)
- Plateforme, résolution cible
- Performance min/recommandée
- API spécifiques (netcode, si multijoueur)
8. Schedule & Resources
- Timeline approximative (alpha, beta, launch)
- Taille de l'équipe
- Ressources budget, outils utilisés
Les erreurs de débutant que vous allez éviter#
Trop détaillé, trop tôt. Les débutants veulent écrire tous les dialogues, chaque stats d'ennemi, chaque texture. Stop. Un GDD ne remplace pas l'itération. Laissez de la place à la créativité en cours de route.
Pas assez de vision unifiée. À l'inverse, si votre GDD c'est « on va faire un jeu de plateforme », c'est trop vague. Vos designers et artistes vont prendre des directions complètement différentes. Soyez assez précis sur le tone, les mécaniques clés, l'esthétique.
Oublier la core loop. Vous pouvez avoir un univers magnifique, une histoire épique, mais si la core loop (l'action que le joueur répète toutes les cinq secondes) est chiante, c'est mort. Honnêtement, je sais pas trop quoi en penser des équipes qui testent ça que sur papier. (Les jeux qui foutent 10 heures sur la narration pour 5 secondes de gameplay ennuyeux, c'est comme acheter un livre culte qu'on ne peut pas feuilleter.) Prototypez en rapide, même dégueulasse, ça va vous sauver des mois de dev.
Écrire en solo. Le GDD doit être collaboratif, dès le départ. Laissez vos devs commenter, proposer des sections. Sinon, vous finirez avec un document parfait que personne ne va lire.
Graver dans le marbre. Un GDD vivant c'est un GDD qui change. Tous les mois, vous apprenez des choses. Mettez à jour le document. Marquez les changements en gras. Expliquez pourquoi vous avez pivoté.
Outils pratiques pour rédiger votre GDD#
Notion#
Notion est devenu le standard indie en 2026. Pourquoi ? Gratuit (ou cheap), collaboratif, flexible. Vous pouvez créer une base de données d'ennemis avec des propriétés (HP, dégâts, spawn rate), des pages liées, des timelines. L'écosystème Notion a aussi des templates publics de GDD prêts à utiliser. Cherchez sur le marketplace Notion ou Reddit r/gamedev.
Google Docs reste basique, mais efficace. Le commentaire en temps réel, le suivi des modifications, le partage facile, parfait pour un petit projet solo ou 2-3 personnes. Je préfère Notion pour la puissance, mais Google Docs pour le prototypage initial.
Exemples célèbres (et comment ils l'ont fait)#
Baldur's Gate 3#
Larian n'a pas publié son GDD complet, mais en interviews, Swen Vincke a expliqué qu'ils s'appuyaient sur un document vivant que toute l'équipe mettait à jour quotidiennement. Taille : environ 200 pages, mais structurées par système (combat, dialogue, progression, économie). J'ai changé d'avis sur les GDD de 200 pages : si c'est bien structuré et qu'il y a une culture de maintenance, ça marche. Larian a livré un jeu de 150+ heures cohérent, donc ils font quelque chose de juste.
Hades#
Supergiant Games a commencé avec un one-pager (jeu de roguelike en isométrie, thème mythologique grec, progression via défaite). Le reste s'est construit progressivement. Leur GDD était lean, mais leur prototypage était agressif.
Disco Elysium#
ZA/UM (avant le drame interne) avait un GDD massif centré sur la narration. Tous les dialogues étaient écrits, tracés sur une carte de dépendance (« ce dialogue ne s'unlock que si le joueur a 8 en Intellect »). C'est faisable à petite équipe si votre cœur c'est la narration.
Template de démarrage simplifié#
Vous pouvez copier-coller celui-ci et l'adapter :
# [Titre du jeu] GDD
## 1. Concept
- Genre : [...]
- Public : [...]
- Hooks : [...]
## 2. Core Loop
Le joueur fait ceci, encore et encore : [...]
## 3. Mécaniques principales
- [Mécanique 1] : Détail
- [Mécanique 2] : Détail
## 4. Progression
- Comment le joueur progresse : [...]
- Courbe de difficulté : [...]
## 5. Univers
- Ambiance générale : [...]
- Univers visuel : [...]
## 6. Niveaux (structure générale)
- Nombre de niveaux : [...]
- Longueur moyenne : [...]
- Progression : [...]
## 7. Timeline & Ressources
- Alpha : [mois]
- Beta : [mois]
- Launch : [mois]
- Équipe : [nombre de people + rôles]
## 8. Notes & Références
- Jeux inspirants : [...]
- Références visuelles : [...]
- Questions ouvertes : [...]
Imprimez ça, partagez-le avec votre équipe, complétez-le au fur et à mesure.
GDD agile vs GDD waterfall#
En 2026, beaucoup de studios indie optent pour l'agile : GDD court, mises à jour mensuelles, focus sur ce qu'on va faire en sprint. Waterfall c'est l'approche traditionnelle : tout planifier avant, puis exécuter.
Réalité : vous avez besoin des deux. Un GDD light (5-10 pages) pour la vision globale. Et des docs détaillées pour chaque système, au fur et à mesure que vous l'implémentez.
