Sur un projet mobile free-to-play, le premier livrable qui fait gagner (ou perdre) du temps à toute l’équipe, c’est le GDD. Un game design document mal structuré génère des allers-retours entre game designers, développeurs et product managers pendant des semaines. À l’inverse, un GDD orienté production accélère chaque sprint et réduit les décisions prises à l’instinct.
GDD game design pour le mobile : ce que les stores imposent au document
On commence souvent un GDD par les mécaniques de gameplay, la direction artistique ou le level design. Sur mobile, la première contrainte vient d’ailleurs : les politiques de publication de Google Play et de l’App Store.
A voir aussi : Comment fonctionne un forfait mobile ?
Depuis 2023-2024, Google Play exige une transparence accrue sur les mécaniques de monétisation de type loot box, avec affichage obligatoire des probabilités de drop et du contenu aléatoire. Apple impose de son côté des règles strictes sur les écrans de paywall, les parcours d’abonnement et la facilité de résiliation.
Concrètement, cela signifie que le GDD doit intégrer les spécifications légales et UI des écrans de monétisation avant même le prototypage. Un oubli à ce stade peut entraîner un rejet en review ou un déréférencement sur un marché entier, notamment en Europe et en Asie.
A lire aussi : Quel logiciel pour récupérer photos supprimées définitivement iPhone en 2026 ?
Dans le document, on réserve une section dédiée qui décrit chaque écran de paiement, les messages légaux associés, les flux de souscription et de résiliation, et les probabilités affichées pour tout contenu aléatoire. Ce n’est pas un ajout cosmétique : c’est une condition d’acceptation.
Structure d’un GDD orienté monétisation et KPI
Les studios free-to-play rentables ont fait évoluer le GDD classique vers un document hybride, à mi-chemin entre cahier des charges game design et plan produit. Depuis 2024, la majorité des GDD de jeux mobiles performants incluent explicitement les KPI de monétisation à suivre et les tests A/B prévus dès la conception.
Les sections produit à intégrer au document
Un GDD mobile qui ne parle que de gameplay rate sa cible. Voici les blocs opérationnels qu’on retrouve dans les documents de studios structurés :
- Boucle économique complète : sources de monnaie (soft et hard currency), puits de dépense, courbe de progression et points de friction volontaires qui orientent vers l’achat
- KPI cibles par phase de lancement : ARPU, LTV, churn payant, taux de conversion IAP ou abonnement, payback d’acquisition utilisateur
- Plan de tests A/B sur les offres, les prix et les placements publicitaires, avec une cadence d’itération de deux à quatre semaines inscrite directement dans le calendrier de production
- Spécifications des écrans de paywall conformes aux exigences des stores (messages légaux, parcours de résiliation, affichage des probabilités de drop)
Ce découpage permet au product manager et au game designer de travailler sur le même document au lieu de maintenir deux fichiers parallèles qui divergent après le premier sprint.
Lier le gameplay au modèle économique dans le même fichier
La tentation classique consiste à documenter le gameplay dans le GDD et la monétisation dans un « monetization deck » séparé. En pratique, ça crée un angle mort : les level designers conçoivent des niveaux sans connaître les points de conversion, et le product manager découvre trop tard qu’un niveau clé détruit la rétention.
On lie chaque mécanique de gameplay à son impact économique directement dans la section concernée. Par exemple, la description d’un système d’énergie inclut le temps de recharge, le coût de recharge en hard currency, et le test A/B prévu sur ce ratio.
Documenter le level design et le gameplay pour une équipe mobile
Sur un jeu narratif ou épisodique, beaucoup de GDD restent trop abstraits au niveau des scènes et des interactions. On se retrouve avec des directions générales (« le joueur explore la zone et résout une énigme ») qui ne permettent pas de créer des tâches claires pour le développement.
Un GDD opérationnel décompose chaque niveau ou épisode en blocs actionnables :
- Objectif du joueur dans la scène (ce qu’il doit accomplir pour progresser)
- Mécaniques actives (interactions, compétences utilisées, objets requis)
- Critères de réussite et d’échec, avec les conséquences sur la progression
- Points de monétisation ou de rétention intégrés à la scène (publicité récompensée, achat contextuel, cliffhanger de session)
Chaque scène documentée doit pouvoir devenir un ticket de production sans reformulation. Si le game designer doit réexpliquer oralement ce qu’il a écrit, le GDD a échoué dans sa fonction première.
Outils et format du GDD : choisir en fonction de la taille du projet
Le format du document compte autant que son contenu. Un GDD de soixante pages en PDF figé devient obsolète après deux semaines de développement. Les retours varient sur ce point selon la taille de l’équipe et la durée du projet.
GDD vivant ou document figé
Pour une équipe de moins de cinq personnes, un document collaboratif (Notion, Google Docs, Confluence) suffit. L’avantage : chaque modification est versionnée et visible par tous. On évite le syndrome du « j’ai la bonne version sur mon bureau ».
Pour les projets plus ambitieux avec plusieurs niveaux de conception (game design, level design, narrative design), un wiki structuré avec des pages liées fonctionne mieux qu’un document linéaire. Le game designer principal maintient une page d’index, et chaque concepteur enrichit sa section sans casser la cohérence globale.
Ce qu’on garde hors du GDD
Un piège fréquent consiste à transformer le GDD en fourre-tout. Les spécifications techniques pures (architecture serveur, choix de moteur, pipeline d’assets) relèvent d’un document technique séparé. Le GDD décrit ce que le joueur vit, pas comment le code fonctionne. Le lien entre les deux se fait par des références croisées, pas par de la duplication.
Itération du GDD en production mobile
Un GDD game design pour le mobile n’est jamais terminé à la sortie de pré-production. Les données de jeu en soft launch modifient les hypothèses de conception, parfois radicalement. Un niveau pensé comme un pic de difficulté devient un point de churn si le taux d’abandon dépasse les seuils fixés dans le document.
Le GDD intègre un cycle de mise à jour aligné sur les sprints de production, généralement toutes les deux à quatre semaines. Chaque itération met à jour les KPI observés, les résultats des tests A/B, et ajuste les mécaniques de gameplay ou les prix en conséquence.
Ce fonctionnement transforme le GDD d’un document de conception statique en un outil de gestion produit. Le game designer ne rédige pas un cahier des charges qu’il jette par-dessus le mur : il maintient un référentiel vivant que toute l’équipe, du développement à la production, consulte et enrichit à chaque cycle.
Un GDD mobile bien construit se reconnaît à un critère simple : six mois après le lancement, l’équipe l’utilise encore.
