Un GDD qui traîne dans un Google Doc de cent pages, personne ne le lit. Ni le programmeur qui cherche la formule de dégâts, ni l’artiste qui veut savoir si le personnage porte une armure lourde ou légère. Le Game Design Document reste le pivot d’un projet de jeu vidéo, mais sa forme détermine s’il sera réellement consulté ou simplement archivé.
GDD lisible par des machines : le virage que la plupart des guides ignorent
Les ressources francophones sur le GDD game design insistent sur le caractère « vivant » du document. Peu abordent un changement de pratique plus profond : la tendance à rendre le GDD exploitable par des scripts et des pipelines de données, pas uniquement par des humains.
Concrètement, cela modifie la rédaction de plusieurs sections. Les tables de stats (cooldowns, coûts, drop rates) ne sont plus de simples illustrations. Elles deviennent des sections paramétriques exportables vers le moteur de jeu. Un développeur peut extraire une table de dégâts directement du document pour l’injecter dans un outil d’équilibrage, sans retranscription manuelle.
Pour que cela fonctionne, chaque feature, chaque mécanique et chaque ressource doit porter un identifiant stable (un ID unique). Ces identifiants relient le GDD au code côté devs et à la nomenclature d’assets côté artistes. Un concept artist qui ouvre la fiche « CHAR_KNIGHT_01 » retrouve immédiatement les contraintes visuelles, les animations requises et les références de la mécanique associée.
Documentation-as-code : versionner le GDD comme du code source
Une pratique en progression dans les studios indés consiste à stocker le GDD (ou ses fiches de features) dans le même dépôt que le code. Le document est alors versionné avec Git, et chaque modification passe par une pull request soumise à revue.
L’intérêt pour la lisibilité est direct. Un artiste environnement qui reçoit une notification de pull request sait qu’une fiche de niveau a changé. Il voit le diff : ce qui a été ajouté, ce qui a été retiré. Plus besoin de relire la section entière pour comprendre ce qui a bougé.
Les retours terrain divergent sur ce point. Les profils techniques adoptent le système sans friction. Les artistes et les narrative designers, habitués à des outils visuels, trouvent parfois le format Markdown ou plain text trop austère. Le format du GDD doit s’adapter aux profils qui le consultent, pas l’inverse. Certaines équipes maintiennent un hub visuel (Notion, wiki interne) synchronisé avec le dépôt de code, pour offrir deux points d’entrée vers la même information.
Structure d’un GDD game design orienté lecture transverse
La majorité des modèles de GDD proposent un découpage par thème : mécaniques, narration, progression, économie. Ce découpage convient au game designer qui rédige, mais il force les autres métiers à naviguer dans des sections qui ne les concernent pas.
Une alternative consiste à organiser le document par fiches de fonctionnalités autonomes. Chaque fiche couvre un périmètre précis (un système de combat, un biome, un menu d’inventaire) et contient tout ce dont chaque métier a besoin pour ce périmètre :
- Le pitch de la feature en deux phrases, avec ses piliers de design et la boucle de gameplay concernée
- Les contraintes techniques (performances, plateformes cibles, dépendances avec d’autres systèmes) destinées aux programmeurs
- Les références visuelles, la palette, les contraintes d’animation et la nomenclature d’assets pour les artistes
- Les données paramétriques (tables de valeurs, IDs, formules) dans un format structuré et exportable
Ce format par fiches réduit le temps de recherche. Un artiste VFX n’ouvre que la fiche « COMBAT_MAGIC_SYSTEM » au lieu de scanner un document de dizaines de pages.
Le journal de décisions comme filet de sécurité
Un élément souvent absent des GDD : le journal qui enregistre chaque décision de design et sa justification. Quand un artiste se demande pourquoi le style graphique a basculé du cel-shading vers du PBR réaliste, la réponse se trouve dans une entrée datée, pas dans la mémoire d’un lead absent ce jour-là.
Un GDD sans journal de décisions génère des débats déjà tranchés. Les équipes reviennent sur des arbitrages oubliés, perdent du temps à reconstituer le raisonnement initial. Le journal n’a pas besoin d’être long : une ligne par décision, avec la date, le contexte et le choix retenu.
Erreurs de lisibilité fréquentes dans un Game Design Document
Trois problèmes reviennent dans les GDD qui finissent ignorés par l’équipe :
- Le mur de texte sans hiérarchie visuelle. Un dev scanne, il ne lit pas ligne par ligne. Sans titres clairs, sans tableaux, sans mise en forme, l’information est techniquement présente mais inaccessible
- L’absence de distinction entre ce qui est validé et ce qui est en discussion. Mélanger des idées exploratoires et des spécifications finales dans la même section crée de la confusion, surtout pour les artistes qui engagent du temps de production sur un asset
- Des sections rédigées pour un seul métier sans pont vers les autres. Une description de mécanique purement abstraite (diagrammes logiques, pseudo-code) ne dit rien à un artiste sur ce qu’il doit produire visuellement
La solution passe rarement par plus de contenu. Elle passe par une meilleure segmentation : chaque information au bon endroit, avec le bon niveau de détail pour le lecteur visé.
Outils et formats pour un GDD partagé entre devs et artistes
Le choix de l’outil influence directement la lisibilité. Un GDD dans un document texte linéaire (Word, Google Docs) fonctionne en pré-production, quand le document fait quelques pages. Passé un certain volume, un hub modulaire remplace le document monolithique.
Notion, Confluence ou un wiki interne permettent de créer des fiches liées entre elles, avec des vues filtrées par métier. Un programmeur affiche les fiches par dépendance technique. Un artiste filtre par type d’asset. Le contenu est le même, la vue change.
Pour les équipes qui adoptent la documentation-as-code, des fichiers Markdown versionnés dans Git offrent la traçabilité maximale. Le compromis se situe entre la richesse visuelle (importante pour les artistes) et la rigueur de versionnement (prioritaire pour les devs). Les équipes les plus efficaces sur ce point maintiennent les deux en parallèle, avec une source unique de vérité synchronisée.
Le GDD parfait n’existe pas. Un document consulté quotidiennement par trois métiers différents, mis à jour à chaque décision, et structuré pour que chacun trouve son information en moins d’une minute, s’en approche suffisamment.
