Comment fabrique-t-on un jeu vidéo ? Le pipeline complet

Entre l’idée et le bouton « Nouvelle partie »

Quand un joueur lance un jeu, presque tout le travail qui l’a rendu possible est devenu invisible. Le personnage répond à la manette, les portes s’ouvrent au bon moment, la musique accompagne la scène, les menus fonctionnent, les ennemis réagissent, les textes sont traduits et la sauvegarde retrouve normalement sa partie là où il l’avait laissée.

Rien de tout cela n’existait dans la première idée.

Au départ, un jeu peut tenir dans quelques phrases : un personnage, une mécanique, une ambiance, parfois une image ou un prototype grossier. Il faut ensuite transformer cette intention en milliers d’éléments capables de fonctionner ensemble. Code, animations, interfaces, niveaux, dialogues, effets visuels, sons, systèmes de sauvegarde, intelligence artificielle, données, outils internes et règles de gameplay finissent par former un seul objet que le joueur perçoit comme une expérience continue.

C’est à cela que sert le pipeline de production.

Le terme peut donner l’impression d’une chaîne de montage où une idée passerait proprement d’un département au suivant jusqu’à devenir un jeu terminé. La réalité est beaucoup plus mouvante. On prototype, on teste, on revient sur une mécanique, on modifie une animation parce qu’elle gêne le gameplay, on reconstruit une zone parce que les joueurs s’y perdent, puis on découvre qu’une fonctionnalité conçue depuis six mois coûte trop cher pour ce qu’elle apporte.

Unity présente d’ailleurs le cycle général d’un projet en quatre grandes phases — préproduction, production, postproduction puis opérations — mais ce découpage sert surtout à situer le projet. À l’intérieur, conception, programmation, création de contenu et tests avancent par itérations successives.

Un pipeline décrit donc moins l’ordre absolu des tâches que la manière dont une équipe transforme progressivement l’incertitude en quelque chose de jouable, testable puis publiable.

---

1. Le concept — déterminer ce que l’on cherche réellement à fabriquer

Créer un jeu ne commence pas nécessairement par un document de cent pages. Cela peut commencer par une mécanique, une sensation, un personnage, une situation ou même une contrainte technique.

Un jeu de plateforme peut naître d’un type de déplacement particulièrement agréable. Un jeu narratif peut partir d’une relation entre deux personnages. Un puzzle game peut exister d’abord comme une règle griffonnée dans un carnet. Dans tous les cas, la première difficulté consiste à distinguer l’idée séduisante du jeu que l’on peut réellement construire.

Le concept doit progressivement répondre à quelques questions simples : que fait le joueur ? Pourquoi a-t-il envie de recommencer ? Qu’est-ce qui distingue cette expérience d’une autre ? À quel public s’adresse-t-elle ? Sur quelles machines doit-elle fonctionner ? Et surtout, quelle taille de projet l’équipe peut-elle raisonnablement produire avec son temps, ses compétences et son budget ?

C’est ici qu’apparaît souvent la notion de core loop, la boucle d’actions que le joueur répétera tout au long de l’expérience. Dans un jeu de course, conduire, améliorer puis reprendre la piste peut former une boucle. Dans un RPG, explorer, combattre, obtenir des ressources et faire progresser son personnage en constitue une autre.

Une bonne idée de jeu ne se résume donc pas à son univers. « Un RPG dans une ville cyberpunk » décrit un cadre. Il faut encore découvrir ce que le joueur fera réellement pendant vingt minutes, puis pendant dix heures.

---

2. La préproduction — résoudre les gros problèmes avant qu’ils deviennent chers

La préproduction est la période pendant laquelle le projet cherche sa forme.

Le game design précise les règles, les contrôles, les systèmes de progression, les interactions et l’équilibre général. La direction artistique cherche une identité visuelle compatible avec le projet. Les développeurs évaluent les besoins techniques. La production commence à estimer les ressources, les dépendances et les étapes nécessaires.

Selon les équipes, ces informations peuvent être regroupées dans un Game Design Document, dans un wiki interne, dans un outil de gestion de projet ou dans plusieurs documents spécialisés. Leur forme importe moins que leur fonction : garder une vision suffisamment claire pour que plusieurs personnes puissent construire le même jeu sans en avoir chacune une version différente dans la tête.

La préproduction sert aussi à définir ce que le projet ne fera pas.

C’est beaucoup moins spectaculaire, mais souvent plus utile.

Un inventaire peut être supprimé. Une ville ouverte peut devenir une succession de zones. Dix personnages jouables peuvent redevenir trois. Une technologie séduisante peut être abandonnée si son coût technique dépasse son intérêt réel.

Le scope — le périmètre du projet — commence ici à devenir une contrainte créative.

---

3. Le prototype — vérifier l’idée avant de construire le jeu

Une mécanique décrite sur papier peut sembler excellente jusqu’au moment où quelqu’un pose les mains dessus.

C’est précisément le rôle du prototype.

Il ne cherche pas à être beau. Il cherche à répondre à une question.

Le déplacement est-il agréable ? Ce système de combat fonctionne-t-il réellement ? La caméra permet-elle de lire correctement l’action ? Cette génération procédurale produit-elle des niveaux intéressants ? Cette mécanique de dialogue reste-t-elle compréhensible lorsque plusieurs variables commencent à interagir ?

Unity recommande justement de commencer petit et de prototyper afin d’identifier ce qui constitue réellement le cœur de l’expérience et de tester différentes approches avant de s’engager dans la production complète. Un prototype rapide peut même être volontairement jetable : son rôle est de valider une hypothèse, pas nécessairement de devenir la fondation technique définitive du jeu.

Cette distinction évite une erreur classique : passer plusieurs semaines à produire de belles textures, des animations propres et une interface complète pour découvrir ensuite que la mécanique centrale n’est tout simplement pas très intéressante.

Le prototype accepte donc d’être laid pour permettre au jeu final d’avoir une chance d’être bon.

Du prototype à la vertical slice

Lorsque les principales idées commencent à tenir debout, certaines équipes produisent une vertical slice.

Contrairement au prototype brut, celle-ci cherche à représenter une petite portion du jeu proche de la qualité finale. Gameplay, direction artistique, interfaces, audio et principaux systèmes doivent y fonctionner ensemble. Unity définit ainsi la vertical slice comme une petite partie jouable montrant les systèmes, fonctionnalités et éléments artistiques majeurs du projet ; elle peut aussi servir à présenter le jeu à un éditeur ou à des investisseurs.

Un prototype demande :

« Est-ce que cette idée fonctionne ? »

Une vertical slice demande plutôt :

« Sommes-nous capables de produire ce jeu de cette manière et à ce niveau de qualité ? »

La différence paraît subtile. Pour un projet qui va mobiliser plusieurs dizaines de personnes pendant plusieurs années, elle ne l’est pas du tout.

---

4. La production — lorsque toutes les disciplines commencent à se rencontrer

Une fois la direction suffisamment validée, le projet entre réellement en production.

C’est généralement la période la plus longue et celle qui mobilise le plus grand nombre de personnes. Le code se développe, les niveaux se construisent, les personnages prennent forme, les interfaces apparaissent, les animations remplacent les mouvements provisoires et les premières minutes convaincantes doivent progressivement devenir des heures de jeu cohérentes.

Le terme « production » masque pourtant une difficulté essentielle : tout avance en parallèle.

Cette séparation reste théorique. Dans la pratique, chaque domaine dépend des autres.

Un animateur doit connaître la vitesse réelle du personnage. Un level designer doit savoir jusqu’où celui-ci peut sauter. Le sound designer doit recevoir les événements nécessaires pour déclencher ses sons. Le programmeur doit savoir quelles variations d’animation seront utilisées. L’artiste environnement doit respecter des contraintes de performance qui dépendront elles-mêmes des plateformes ciblées.

Un jeu n’est donc pas produit par une succession de spécialistes travaillant chacun dans leur coin. Il se construit par circulation constante de contraintes et d’informations.

---

5. Programmation et systèmes — construire les règles invisibles

Une grande partie du développement consiste à transformer les intentions du game design en systèmes capables de fonctionner de manière fiable.

Le joueur appuie sur une touche : que se passe-t-il ?

Un ennemi voit le joueur : comment le sait-il ?

Une quête se termine : quelles données doivent être mises à jour ?

Un objet est ramassé : où son état est-il enregistré ?

Le personnage meurt : que doit conserver la sauvegarde ?

La programmation gameplay donne vie aux interactions directement ressenties par le joueur, mais d’autres développeurs peuvent travailler sur le moteur, le réseau, les outils internes, les performances, les interfaces, les systèmes de build ou encore l’intelligence artificielle.

Plus le projet grandit, plus l’architecture du code devient importante. Une fonctionnalité qui marche parfaitement dans une petite démonstration peut devenir pénible à maintenir lorsqu’elle doit interagir avec cinquante autres systèmes.

C’est aussi pour cela que le prototype et le code de production ne poursuivent pas toujours le même objectif : le premier doit apprendre vite, le second doit continuer à fonctionner lorsque le projet grossit.

---

6. Direction artistique, 2D et 3D — donner une cohérence au monde

La production visuelle ne consiste pas simplement à « faire de beaux graphismes ».

La direction artistique définit un langage commun : proportions, formes, palettes, matériaux, niveau de détail, éclairage, architecture, costumes, effets visuels et lisibilité doivent sembler appartenir au même univers.

Le concept art explore avant que la production coûte cher. Un personnage peut être dessiné sous plusieurs formes avant que l’équipe choisisse celle qui sera réellement modélisée. Un décor peut être testé en quelques peintures rapides avant qu’un environnement complet soit construit en 3D.

Pour un personnage 3D, la chaîne peut ensuite passer par la modélisation, la sculpture, la retopologie, les UV, les textures, les matériaux, le rigging puis l’animation. Un environnement suit d’autres besoins : modules architecturaux, végétation, accessoires, terrains, matériaux, éclairage et optimisation doivent former un ensemble réutilisable.

La technologie intervient constamment dans ces choix. Une cape magnifique qui traverse le personnage pendant chaque combat n’est pas vraiment terminée. Une forêt spectaculaire qui fait tomber le jeu à quinze images par seconde non plus.

La création visuelle doit donc trouver son équilibre entre intention artistique, gameplay et contraintes techniques.

---

7. Level design — transformer les systèmes en situations

Une mécanique n’existe réellement que lorsqu’un joueur rencontre une situation qui lui permet de l’utiliser.

C’est là que le level design devient essentiel.

Le level designer organise les espaces, les distances, la circulation, les objectifs, les rencontres, les ressources et le rythme. Un couloir peut préparer une surprise. Une arène peut offrir plusieurs positions tactiques. Une falaise peut orienter le regard vers la prochaine destination sans afficher une énorme flèche lumineuse.

Les premiers niveaux sont souvent construits en greybox ou blockout : des volumes simples remplacent temporairement murs, bâtiments ou obstacles. L’objectif est de vérifier les proportions et le gameplay avant d’investir dans la finition artistique.

L’environnement pourra ensuite être habillé, éclairé, sonorisé et enrichi sans perdre la structure qui le rend jouable.

Cette étape montre bien pourquoi un niveau n’est pas simplement un décor. C’est une architecture de décisions.

---

8. Audio, musique et voix — construire ce que l’image ne suffit pas à raconter

Un jeu muet révèle rapidement combien le son porte une partie de l’expérience.

Un bruit confirme qu’une attaque a touché sa cible. Une variation musicale annonce un danger avant même que le joueur le voie. Une ambiance situe un lieu. Une interface devient plus lisible grâce à quelques retours sonores correctement placés.

Le travail audio commence donc bien avant l’enregistrement final des bruitages.

Sound designers, compositeurs, programmeurs audio et comédiens peuvent intervenir selon l’échelle du projet. Le son doit ensuite être intégré au moteur afin de réagir au contexte : distance, espace, état du combat, surface sous les pieds, météo ou situation narrative.

La musique elle-même peut devenir dynamique. Plutôt que de jouer une piste fixe, le moteur peut mélanger plusieurs couches et faire évoluer l’arrangement selon ce qui se passe à l’écran.

Le joueur n’en connaît généralement pas le système.

Il entend simplement que « ça fonctionne ».

C’est souvent le meilleur compliment que puisse recevoir un pipeline bien intégré.

---

9. Intégration et outils — l’endroit où le pipeline peut sauver ou détruire du temps

Dès qu’une équipe grandit, produire les éléments du jeu ne suffit plus. Il faut aussi savoir les faire circuler.

Qui possède la dernière version du personnage ?

Comment nommer les fichiers ?

Que se passe-t-il lorsque deux personnes modifient la même scène ?

Comment transformer automatiquement le code et les ressources en version jouable ?

Comment vérifier qu’un nouveau fichier n’a pas cassé le projet ?

Contrôle de version, conventions de nommage, gestion des assets, outils d’import, automatisation et systèmes de build deviennent alors une partie essentielle du développement.

La documentation d’Unreal Engine regroupe précisément ces sujets dans son pipeline de production : collaboration et contrôle de version, gestion des ressources, automatisation de l’éditeur, stockage, déploiement et infrastructure de build servent à maintenir un flux de travail viable lorsque le projet et l’équipe prennent de l’ampleur. Epic souligne également l’intérêt des pipelines automatisés de build et de test pour réduire le temps entre une modification et sa vérification.

Ce travail est rarement visible dans une bande-annonce.

Il peut pourtant déterminer si une équipe perd dix minutes ou deux heures chaque fois qu’elle veut tester une modification.

Sur plusieurs années de production, ces petites frictions deviennent gigantesques.

---

10. Tester — découvrir le jeu que l’équipe a réellement fabriqué

Développer un jeu pendant des mois crée un problème assez prévisible : l’équipe finit par connaître son propre projet beaucoup trop bien.

Elle sait où aller.

Elle connaît les commandes.

Elle comprend les règles.

Elle sait que ce petit symbole à droite signifie qu’il faut maintenir une touche pendant deux secondes.

Un nouveau joueur, lui, ne sait rien de tout cela.

Les tests servent précisément à confronter le jeu à cette réalité.

Le QA cherche notamment les bugs, crashes, blocages de progression et comportements inattendus. Les playtests observent davantage l’expérience : les joueurs comprennent-ils l’objectif ? Utilisent-ils la mécanique comme prévu ? Une zone est-elle trop difficile ? Une interface provoque-t-elle des erreurs ?

Unity distingue ainsi les tests permettant de confirmer que l’expérience répond aux exigences techniques, ceux qui révèlent des comportements inattendus et les tests utilisateurs qui évaluent ce que l’expérience produit réellement auprès de son public.

Le résultat peut être inconfortable.

Une mécanique que l’équipe adore peut ne pas fonctionner.

Un tutoriel jugé évident peut perdre la moitié des joueurs.

Une arme secondaire peut devenir beaucoup plus puissante que prévu.

Mais découvrir ce problème pendant un playtest reste préférable à le découvrir dans dix mille avis publiés le jour de la sortie.

---

11. Accessibilité — penser dès la conception à celles et ceux qui joueront

L’accessibilité ne se résume pas à ajouter quelques options dans les menus juste avant la sortie.

Taille des textes, contraste, sous-titres, remappage des commandes, alternatives aux informations uniquement sonores ou visuelles, réduction de certaines contraintes motrices et réglages de difficulté peuvent toucher directement la conception de l’interface et du gameplay.

Ils deviennent donc beaucoup plus simples à intégrer lorsqu’ils sont considérés suffisamment tôt.

Le programme de formation de Unity consacré à l’accessibilité place explicitement cette réflexion dès la préproduction et recommande de maintenir des cycles de retour et d’évaluation tout au long du développement. Les Xbox Accessibility Guidelines sont elles aussi destinées aux designers, développeurs et équipes de test plutôt qu’à une simple vérification finale.

Il ne s’agit pas seulement d’une couche supplémentaire du pipeline.

C’est une manière de vérifier à qui l’expérience reste réellement accessible.

---

12. Optimisation — faire fonctionner le jeu dans le monde réel

Sur la machine du développeur, une scène peut fonctionner parfaitement.

Puis arrivent la console ciblée, l’ordinateur minimum recommandé, le téléphone qui chauffe et la zone du jeu contenant trois fois plus d’ennemis que le test initial.

L’optimisation cherche à maintenir l’expérience dans les limites du matériel.

Le rendu graphique doit respecter le budget disponible. Les textures consomment de la mémoire. Les animations, la physique, l’IA et les effets visuels utilisent du temps processeur. Les chargements dépendent du stockage et de la manière dont les données sont organisées.

Les équipes utilisent donc des outils de profiling afin d’identifier les véritables points coûteux plutôt que d’optimiser au hasard.

Cela peut conduire à simplifier une géométrie, réduire certaines textures, employer des niveaux de détail, limiter des calculs, modifier des systèmes de streaming ou revoir complètement une fonctionnalité.

L’objectif n’est pas d’obtenir « les meilleurs graphismes possibles ».

Il est d’obtenir la meilleure expérience que les plateformes ciblées peuvent réellement maintenir.

---

13. Localisation — lorsqu’un jeu doit survivre à une autre langue

Traduire un jeu ne consiste pas simplement à remplacer une phrase française par sa version anglaise ou japonaise.

La longueur change.

Les alphabets changent.

Le sens de lecture peut changer.

Les voix doivent parfois être réenregistrées.

Les images peuvent contenir du texte.

Certaines références culturelles nécessitent une adaptation.

L’interface conçue pour un mot de six lettres peut soudain devoir en afficher vingt-deux.

La localisation doit donc être testée dans le jeu lui-même.

Les exigences de certification Xbox incluent par exemple la vérification des langues prises en charge, de l’affichage correct du texte localisé et de la stabilité du jeu lorsque les paramètres linguistiques changent.

Plus le projet prévoit tôt cette réalité, moins il découvrira à la fin que son magnifique bouton n’a physiquement pas la place d’accueillir sa traduction allemande.

---

14. Build, certification et publication — transformer le projet en produit distribuable

Un projet fonctionnant dans l’éditeur n’est pas encore le jeu que le public téléchargera.

Il faut produire une build.

Le moteur rassemble alors le code et les ressources nécessaires à une plateforme précise, prépare les données, les optimise puis génère les fichiers qui pourront être installés et exécutés.

La documentation Unreal distingue notamment les opérations de compilation, préparation des ressources, staging, empaquetage, déploiement et exécution. Epic indique également que l’empaquetage intervient pendant la production et les tests, pour la distribution finale puis pour les mises à jour après publication.

Sur console, une étape supplémentaire apparaît : la certification.

Le constructeur vérifie que le jeu respecte ses exigences techniques et fonctionnelles. Sur Xbox, cela couvre notamment la stabilité, les différents modes de jeu, les profils, le multijoueur, les langues, les contenus téléchargeables et différentes situations liées au fonctionnement de la plateforme.

Pendant ce temps, il faut aussi préparer tout ce qui entoure le logiciel : pages de boutique, captures, bandes-annonces, classifications d’âge, prix, métadonnées et communication.

La sortie est un événement visible.

Elle représente pourtant surtout le moment où tout le travail invisible du pipeline doit enfin fonctionner chez quelqu’un qui ne possède ni l’éditeur, ni les outils internes, ni le développeur assis à côté pour expliquer pourquoi il faut cliquer ici.

---

15. Après la sortie — parce qu’un jeu terminé continue souvent à bouger

Autrefois, graver un jeu sur une cartouche ou un disque imposait une frontière assez nette. Une fois le produit fabriqué et distribué, corriger une erreur devenait difficile, parfois impossible.

La distribution numérique a largement déplacé cette limite.

Correctifs.

Mises à jour.

DLC.

Nouvelles saisons.

Événements.

Équilibrage.

Contenu supplémentaire.

Maintenance des serveurs.

Le pipeline continue donc souvent après la publication.

Unity inclut d’ailleurs une phase d’operations après la production et la postproduction, tandis qu’Unreal décrit explicitement la postproduction comme une période où l’empaquetage sert notamment à distribuer correctifs et nouveaux contenus.

Pour un jeu solo relativement fermé, cette phase peut se limiter à quelques correctifs.

Pour un MMO ou un jeu-service, elle peut durer des années et employer une partie importante de l’équipe d’origine.

La sortie n’est alors plus vraiment la fin du pipeline.

Elle en change simplement le rythme.

---

Le pipeline complet en un coup d’œil

Les étapes se chevauchent et leur ordre varie selon les projets, mais le mouvement général peut se résumer ainsi :

Ce tableau ressemble à une ligne droite parce qu’un tableau est obligé de ranger ses affaires quelque part.

Une production réelle ressemble davantage à un réseau de boucles. Tester peut renvoyer au game design. L’optimisation peut modifier l’art. Une contrainte de localisation peut faire évoluer l’interface. Un prototype peut condamner une fonctionnalité avant même que la production commence.

C’est normal.

---

Un jeu indépendant et un AAA suivent-ils vraiment le même pipeline ?

Pas de la même manière, mais ils rencontrent beaucoup des mêmes problèmes.

Un développeur solo peut concevoir, programmer, dessiner, tester et publier son jeu lui-même. Dans un grand studio, ces responsabilités peuvent être distribuées entre des centaines de personnes et plusieurs entreprises situées dans différents pays.

La différence porte surtout sur l’échelle et la spécialisation.

Pourtant, même le plus petit jeu doit répondre aux mêmes questions fondamentales : est-ce jouable, compréhensible, techniquement viable et suffisamment terminé pour être partagé ?

Le pipeline change de taille.

La nécessité d’itérer, elle, reste.

---

Ce qu’un pipeline cherche réellement à protéger

On pourrait regarder toutes ces étapes et conclure que fabriquer un jeu vidéo consiste surtout à gérer beaucoup de fichiers, de tâches et de réunions.

Ce serait oublier pourquoi le pipeline existe.

Il ne sert pas à rendre la création bureaucratique. Il sert à permettre à des formes de création très différentes de se rencontrer sans détruire ce que les autres viennent de construire.

Le game designer travaille sur une règle. Le développeur lui donne un comportement. L’animateur lui donne un mouvement. Le sound designer lui donne une réponse sonore. Le level designer crée une situation où cette règle devient intéressante. Les tests révèlent ensuite ce que personne n’avait prévu.

La fabrication d’un jeu se trouve dans cette circulation.

Un modèle 3D isolé n’est pas encore un personnage. Une ligne de code isolée n’est pas encore une mécanique. Une carte remplie de pièces n’est pas encore un niveau.

Ils le deviennent lorsqu’ils commencent à répondre les uns aux autres.

C’est probablement la meilleure manière de regarder un pipeline de jeu vidéo : non comme une chaîne qui transforme mécaniquement une idée en produit, mais comme une organisation qui permet à des centaines de décisions créatives et techniques de finir par produire une seule expérience cohérente.

Et lorsque le joueur appuie enfin sur « Nouvelle partie », tout ce travail peut disparaître derrière quelque chose de beaucoup plus simple : le jeu répond, le monde tient debout, et l’on peut enfin commencer à jouer.