# Modèle game design document : un GDD tenu sur une page URL: https://auxworld.app/fr/journal/modele-game-design-document Type: blog Locale: fr Published: 2026-10-27 Updated: 2026-10-29 --- > Un modèle de game design document d'une page pour créateurs indés : sept blocs, quoi couper, et comment documenter un monde généré par prompt. Le modèle game design document qu'il te faut tient sur une seule page, puis grandit seulement quand le jeu le mérite. Commence par sept blocs : le pitch, la boucle de jeu, les verbes du joueur, le monde, les systèmes, le périmètre et les questions ouvertes. Remplis-les en une soirée. Coupe tout ce que tu ne peux pas tester en prototype ce mois-ci. Le reste de cet article est le modèle lui-même, avec les parties que la plupart des guides oublient. ## Pourquoi la plupart des GDD meurent en deuxième semaine Imagine le GDD de 40 pages. Belle couverture, sommaire, un chapitre de lore que personne n'a demandé. En deuxième semaine, le prototype a dérivé et le document est devenu un fossile. C'est le vrai échec. Pas les sections manquantes, mais un fichier qui cesse d'être vrai. Un GDD est un outil de travail, plus proche d'un journal de modifications que d'une bible. Si le document et le build ne disent plus la même chose, c'est le document qui perd, et les gens arrêtent de l'ouvrir. Donc la question n'est pas « que doit contenir un game design document ? ». C'est « quel est le plus petit document que je vais réellement garder honnête ? » ![Croquis au tableau blanc d'une boucle de jeu, dessinée en quatre cases reliées par des flèches](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/7165e4-core.webp) ## Le modèle de GDD en une page, bloc par bloc Copie ce plan. Chaque bloc fait deux à cinq lignes, jamais plus au premier passage. - **Pitch.** Une phrase qu'un inconnu pourrait répéter. « Une ville portuaire en coopération où la marée redessine la carte chaque nuit. » - **Boucle de jeu.** Ce que le joueur fait, encore et encore, en moins d'une minute. Dessine-la comme un cercle de verbes. - **Verbes du joueur.** Cinq à huit actions. Pas des fonctionnalités. Des verbes : grimper, échanger, se cacher, bifurquer, réparer. - **Monde.** Lieu, ambiance, trois règles toujours vraies. La météo compte comme une règle. - **Systèmes.** Les deux ou trois mécaniques qui rendent les verbes intéressants. Économie, furtivité, artisanat, tout ce qui porte la boucle. - **Périmètre.** Ce qui sort, ce qui est coupé, ce qui est un bonus. Mets une date à côté de chaque élément. - **Questions ouvertes.** La liste honnête de ce que tu ne sais pas encore. C'est le bloc le plus précieux de la page. Remarque ce qui manque : la monétisation, le plan marketing, le chapitre sur le passé du personnage. Ils vont dans des fichiers séparés, écrits quand le prototype aura prouvé la boucle. La plupart des modèles publiés commencent par eux, et c'est précisément pour cela que ces documents ne sont jamais terminés. Si tu as besoin d'une structure plus longue pour une équipe qui doit valider, le [guide GitBook sur la rédaction d'un game design document](https://www.gitbook.com/blog/how-to-write-a-game-design-document) détaille la liste classique des chapitres. Son conseil de partir d'une version d'une page, puis d'ajouter du détail au fil des prototypes, est le bon réflexe. ## Ce que la section boucle de jeu doit vraiment dire Pas d'adjectifs. Écris la boucle comme une phrase avec un chronomètre. `Fouiller pendant 40 secondes -> porter la récupération jusqu'au ponton -> échanger contre une amélioration -> la marée bouge, la carte change -> recommencer`Lis-la à voix haute. Si une étape te paraît morte, tu tiens ta première tâche de prototype. Si chaque étape sonne bien mais que tu ne sais pas dire pourquoi le joueur revient, la boucle n'a pas de raison d'être. Ajoute-la comme question ouverte au lieu de l'enterrer sous de la prose. Un test que j'aime : la phrase de boucle doit tenir sur une seule ligne. Si elle demande un paragraphe, ce sont deux boucles, et tu es en train de concevoir deux jeux. ## Quelles sections tu peux couper sans regret Sois impitoyable. En solo ou à deux, tu peux souvent supprimer ces éléments dès le premier jour : - **Biographies complètes des personnages.** Garde un nom, un désir, un défaut. Écris le reste quand le personnage apparaît dans un build. - **Descriptions détaillées des niveaux.** Décris les règles du niveau, pas les pièces. - **Chapitres plateformes et monétisation.** Mets-les de côté tant que la boucle ne fonctionne pas. - **Bible artistique.** Trois images de référence et une palette. C'est tout. Si tu fais un jeu de jam en 72 heures, le pitch, la boucle et les verbes forment ton document entier. Garde la liste complète si tu as un éditeur, un parcours de certification console, ou des prestataires qui ne peuvent pas te poser de questions à minuit. Le [PDF de modèle de game design document d'Unity](https://connect-prd-cdn.unity.com/20201215/83f3733d-3146-42de-8a69-f461d6662eb1/Game-Design-Document-Template.pdf) est une bonne référence pour voir comment les mécaniques et le comportement des objets s'écrivent une fois qu'une équipe est impliquée. Lis-le comme un catalogue, pas comme une checklist. ## Où garder le document, et ce que ton moteur change Là où tu l'éditeras chaque jour. Ça paraît évident, jusqu'à ce que tu voies combien de GDD vivent dans un PDF que personne ne peut comparer. Choisis un outil qui te donne des titres, une base de données pour les tâches et un historique des versions. Une application de notes adossée à une base fonctionne bien, parce que tes questions ouvertes et ta liste de périmètre deviennent des éléments suivis au lieu de puces qui pourrissent. Un Markdown dans le dépôt est l'autre bonne réponse. Il vit à côté du code, il se compare proprement dans un diff, et personne n'oublie de le mettre à jour pendant une pull request. Le coût : tes coéquipiers non techniques n'y toucheront pas. Quel que soit ton choix, place la page d'une seule face en haut et renvoie vers des fichiers plus profonds. La page est la carte. Les fichiers sont le territoire. ![Ordinateur portable affichant un village brumeux généré, posé à côté d'un carnet de croquis](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/21d264-world.webp) Le moteur change un peu ce que tu écris. Il décide quels verbes sont bon marché et lesquels coûtent cher, donc tes blocs systèmes et périmètre doivent le dire clairement. Si tu travailles dans un moteur 3D complet avec un gros pipeline d'assets, le périmètre a besoin d'une ligne par catégorie d'assets, car le contenu est l'endroit où les calendriers meurent. Si tu veux un moteur open source sans calcul de redevances à suivre, ton bloc périmètre devient plus simple : pas de ligne de licence, mais une vraie note sur les fonctionnalités que tu construiras toi-même. Et si le jeu est en 2D avec des mécaniques serrées, la section boucle porte presque tout. Les petits jeux lisibles se prêtent à de petits documents lisibles. Le but n'est pas de désigner un gagnant. C'est que « moteur et outils » ne soit pas une ligne jetable. Elle doit lister ce que le moteur rend facile, ce qu'il rend pénible, et ce que tu refuseras de construire. ## Comment écrire un GDD pour un monde qui se génère tout seul C'est le trou que presque tous les modèles laissent. Ils supposent que tu places chaque arbre à la main. Quand un monde est généré à partir d'un prompt, le document change de forme. Tu ne décris plus des pièces. Tu décris des contraintes : ce qui doit être vrai dans chaque monde que le moteur peut produire, et ce qui a le droit de varier. Ajoute deux blocs à ta page : - **Contraintes du monde.** Les règles qui ne peuvent pas casser. « Chaque village a de l'eau à moins de deux minutes de marche. » « Aucun lieu de quête sans issue. » - **Graines de prompt.** Les prompts exacts que tu as utilisés, enregistrés dans le document. Voici à quoi ressemble une graine en pratique : `un village portuaire brumeux à marée basse, un seul phare, escaliers étroits, ponts de corde entre les toits, personne en vue pour l'instant`Garde le prompt, garde ce qui est revenu, et note ce que tu bifurquerais. Le prompt est à la fois ta spécification et ton journal de modifications. Bifurque, change une seule chose, observe ce qui se passe, puis écris le delta dans le document. Cette habitude rend un monde généré raisonnable, et elle donne à tes coéquipiers quelque chose de concret à critiquer au lieu d'une impression vague. Une précaution : la qualité de génération varie beaucoup d'un outil à l'autre, et certaines fonctions sont encore en bêta dans l'industrie. Note la version et la date à côté de chaque graine, pour savoir si un résultat est reproductible ou si c'est un coup de chance. ## Un test rapide de la boucle avant d'écrire plus Voici le déroulé du soir que je suivrais sur une idée neuve. - Écris le one-pager en 30 minutes. Ne le relis pas. - Transforme le pitch et les trois règles du monde en prompt, puis génère une première passe de l'espace. - Parcours la boucle de jeu dans cet espace, à la main ou dans un prototype grossier. - Marque chaque étape qui t'a paru morte. Elles vont dans les questions ouvertes. - Coupe un verbe. Coupe toujours un verbe. La coupe est la partie que les gens sautent. Un document de design qui ne fait que grandir est une liste de souhaits. Retirer un verbe oblige les autres à porter plus de poids, et cela révèle en général quel système faisait réellement le travail. ![Panneau de liège couvert de fiches reliées par une ficelle rouge, une fiche en train d'être épinglée](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/0dac63-cards.webp) ## Garder le document vivant après la deuxième semaine Trois habitudes, aucune n'a besoin d'héroïsme. **Date chaque question ouverte.** Si une question a plus de trois semaines et reste ouverte, réponds-y, ou admets que tu l'évites. **Mets à jour le document dans la même session que le build.** Pas plus tard. Plus tard, c'est là que le fossile se forme. Une modification de deux lignes à la fin d'une session coûte une minute. **Garde une liste d'idées tuées en bas du document.** Elle t'évite de rediscuter la même mécanique chaque mois, et il est étonnamment motivant de voir combien tu as livré en disant non. Quand quelqu'un rejoint le projet, donne-lui d'abord la version d'une page et observe où il se perd. Chaque question de confusion est une ligne manquante dans le document. Si tu es seul ou en binôme, le one-pager à sept blocs plus une liste de graines de prompt suffit pour le premier mois. Si tu as une équipe, garde le one-pager comme porte d'entrée et ajoute des fichiers séparés pour les systèmes et le contenu, au fur et à mesure que le prototype les justifie. Si tu as un éditeur, donne-lui la version longue, mais garde ton one-pager comme la version à laquelle tu fais confiance. Ouvre une page blanche ce soir et écris le pitch. Une phrase. Puis la boucle, avec un chronomètre. Si tu n'arrives pas à finir ça en une demi-heure, l'idée reste un rêve, et c'est utile à savoir avant de passer un mois dessus. ## FAQ ### Combien de pages doit faire un game design document ? Une page suffit pour commencer : sept blocs, deux à cinq lignes chacun. Tu ajoutes des pages seulement quand un prototype ou une équipe en a besoin. ### Quels sont les sept blocs d'un GDD en une page ? Le pitch, la boucle de jeu, les verbes du joueur, le monde, les systèmes, le périmètre et les questions ouvertes. ### Faut-il inclure la monétisation dans le GDD ? Pas au début. Range-la dans un fichier séparé, à écrire une fois que la boucle de jeu fonctionne en prototype. ### Comment documenter un monde généré par prompt ? Ajoute deux blocs : les contraintes du monde, qui ne peuvent pas casser, et les graines de prompt exactes, avec la version de l'outil et la date. ### Où garder un game design document ? Là où tu l'éditeras chaque jour. Une application de notes adossée à une base, ou un Markdown dans le dépôt, fonctionnent bien. Un PDF se compare mal. ### Quand mettre à jour le GDD ? Dans la même session que le build. Un GDD qui n'est pas mis à jour devient vite un fossile.