On a tous vécu ce moment : le GDD fait 40 pages, la pré-production se termine, et le lead dev demande « ok, on met quoi dans le sprint 1 ? ». Le GDD game design contient la vision, les systèmes, les références visuelles. Le backlog, lui, demande des tâches estimables, priorisées, assignables. Passer de l’un à l’autre ne se fait pas en copiant-collant des paragraphes dans Jira.
Découper un système de jeu en user stories exploitables
Prenons un cas concret : le GDD décrit un système de craft avec collecte de ressources, recettes combinatoires et progression par paliers. Tel quel, c’est un bloc de design. On ne peut ni l’estimer ni le prioriser.
A découvrir également : Comment enregistrer un fichier .pages en word ?
La première opération consiste à isoler les verbes d’action du joueur dans chaque système. Pour le craft : collecter, combiner, débloquer une recette, améliorer un objet. Chaque verbe correspond à une fonctionnalité unitaire, et chaque fonctionnalité se traduit en une ou plusieurs user stories.
On écrit alors des stories du type : « En tant que joueur, je peux combiner deux ressources de base pour obtenir un objet de tier 1. » Cette story est testable, estimable, et surtout indépendante du reste du système de craft. On peut la livrer sans que le déblocage de recettes avancées soit terminé.
A lire aussi : Quels sont les services proposés par un expert en informatique ?
Granularité : quand une story est trop grosse
Si l’estimation dépasse ce qu’on peut livrer en un sprint, la story est trop large. On la redécoupe. « Implémenter le système de craft » n’est pas une story, c’est un epic. Chaque story doit tenir dans un sprint unique.
La règle terrain : si un développeur ne peut pas expliquer en deux phrases ce qu’il va coder, la story manque de clarté. Retour au GDD, relecture du système, nouveau découpage.
Prioriser le backlog à partir des piliers du GDD
Le GDD contient généralement des piliers de design (les deux ou trois promesses fondamentales du jeu). C’est notre grille de priorisation naturelle, et on l’utilise avant tout framework type MoSCoW ou RICE.
Prenons un jeu dont les piliers sont « exploration libre » et « narration émergente ». Une feature de crafting décoratif qui ne sert ni l’un ni l’autre passe en priorité basse, même si elle est décrite en détail dans le GDD. À l’inverse, le système de navigation sur la carte, même esquissé en trois lignes dans le document, remonte en haut du backlog.
Séparer le « doit exister au prototype » du « enrichit la version finale »
Le backlog n’est pas la copie exhaustive du GDD, c’est un filtre. On classe les stories en trois niveaux :
- Core loop : les mécaniques sans lesquelles le jeu n’est pas jouable. Elles entrent dans les premiers sprints et constituent le prototype vertical.
- Systèmes secondaires : les features qui enrichissent l’expérience mais ne bloquent pas la boucle principale (personnalisation, succès, leaderboards).
- Polish et contenu : animations de feedback, variantes de niveaux, textes narratifs optionnels. Ces éléments arrivent en fin de production.
Cette hiérarchie évite un piège fréquent : commencer par une feature séduisante sur le papier (un mode photo, un éditeur de niveaux) alors que la boucle de gameplay principale n’est pas encore validée.
Structurer le backlog dans un outil de gestion de projet
Un fichier texte ou un wiki, c’est bien pour le GDD. Pour le backlog, on passe à un outil de suivi : Jira, Notion avec bases de données, Linear, ou même un tableur structuré sur GitHub Projects. L’outil importe moins que la structure.
Chaque item du backlog contient au minimum :
- Un titre explicite qui décrit l’action joueur (« Le joueur peut ramasser un objet au sol »)
- Un lien vers la section du GDD qui documente le système parent, pour que n’importe quel membre de l’équipe retrouve le contexte de design
- Des critères d’acceptation vérifiables : « L’objet disparaît de la scène, apparaît dans l’inventaire, un feedback sonore se déclenche »
- Une estimation en points ou en taille (S/M/L) validée par le développeur assigné
Sans critères d’acceptation, une story ne peut pas être testée, et une story non testable génère des allers-retours en review qui ralentissent tout le sprint.
Tracer l’origine de chaque story
On ajoute un champ « source GDD » (section ou numéro de page) à chaque story. Ce lien bidirectionnel permet deux choses : vérifier qu’aucun système décrit dans le GDD n’a été oublié lors du découpage, et identifier rapidement les stories orphelines (ajoutées en cours de route sans ancrage dans la vision initiale).
Maintenir la cohérence entre GDD et backlog pendant la production
Le GDD n’est pas figé. En production, les playtests révèlent qu’une mécanique ne fonctionne pas, qu’un système est trop complexe, qu’un pilier doit être ajusté. Le backlog évolue en parallèle, et c’est là que la dérive commence si on ne fait pas attention.
Chaque modification du GDD doit déclencher une revue du backlog associé. Concrètement, quand le game designer modifie une section du document, il tagge les stories liées pour revue. Le product owner (ou le lead, selon la taille de l’équipe) valide que les critères d’acceptation restent cohérents avec le nouveau design.
Le GDD vivant comme source de vérité
Sur les projets où le GDD reste un PDF figé envoyé par email en début de projet, les retours varient sur ce point, mais on constate souvent un décalage croissant entre ce qui est documenté et ce qui est réellement développé. Utiliser un format collaboratif (wiki, GitBook, Notion) permet à chaque membre de l’équipe de consulter la version à jour et de signaler les incohérences.
Le backlog reflète l’état actuel du projet. Le GDD reflète l’intention de design. Quand les deux divergent sans trace écrite, les arbitrages deviennent des conflits.
Erreurs fréquentes lors du passage GDD vers backlog
La première erreur consiste à transformer chaque phrase du GDD en ticket. Un GDD bien rédigé contient des intentions, des références, des notes d’ambiance. Tout cela n’a pas sa place dans un backlog. Seules les fonctionnalités joueur et les contraintes techniques deviennent des stories.
La deuxième erreur : créer le backlog seul. Le game designer découpe, mais l’estimation et la validation technique se font avec les développeurs. Un système décrit en cinq lignes dans le GDD peut représenter plusieurs semaines de travail, et inversement.
La troisième erreur concerne la granularité. Trop fin, le backlog devient ingérable (des centaines de micro-tickets). Trop grossier, il perd sa fonction de pilotage. On vise un backlog où chaque sprint contient entre huit et quinze stories, ajustable selon la taille de l’équipe.
Le passage du GDD au backlog n’est pas une formalité administrative. C’est le moment où la vision se confronte aux contraintes de production, où les priorités deviennent concrètes, et où l’équipe entière prend possession du projet. Un GDD game design bien découpé en backlog, c’est une production qui démarre avec une direction claire et des livrables vérifiables dès le premier sprint.
