La gestion des branches est l'une de ces pratiques qui est bien comprise au sein des grands studios et presque entièrement non documentée partout ailleurs. Les équipes qui l'ont mise en place l'écrivent rarement, car elle a été construite une fois pour toutes puis est devenue invisible. Les équipes qui ne l'ont pas s'en rendent généralement compte à un moment inopportun.

Cet article rassemble les pratiques courantes en un seul endroit :

• La première moitié couvre la poignée de concepts qu'il convient de comprendre avant de construire quoi que ce soit.

• La seconde moitié décrit trois structures concrètes à différents niveaux de ressources disponibles : une pour un développeur solo, une pour une équipe de travail, et une pour un studio disposant d'un processus de publication formel.

Trois plutôt qu'une seule, car la bonne structure dépend du temps d'ingénierie que vous pouvez y consacrer. Un processus conçu pour un studio de cinquante personnes sera discrètement abandonné par une équipe de trois. Il n'y a pas de réponse unique correcte ici, et une sur-ingénierie précoce a un coût réel. La structure qui fonctionne est celle que votre équipe suivra réellement.

Ce que signifie la gestion des branches

Si l'on écarte les outils, le problème se résume à trois éléments.

• Un artefact est une image de serveur construite. Une fois qu'il existe, il ne change jamais.

• Un pointeur est un nom indiquant quel artefact est actuel pour un public donné. « Production » est un pointeur, pas une chose.

• Une décision est l'acte de déplacer un pointeur d'un artefact à un autre.

Tout le reste n'est que de l'outillage enveloppé autour de ces trois éléments.

Certaines plateformes vous fournissent des branches nommées et un bouton de promotion. D'autres vous fournissent des versions et vous laissent décider de la signification des noms. Dans les deux cas, vous assemblez les trois mêmes pièces, et les approches ci-dessous diffèrent principalement par le degré de formalisme qui entoure la troisième.

Une distinction fait l'essentiel du travail ici : L'artefact est immuable ; le pointeur ne l'est pas. La plupart des accidents de publication proviennent de la confusion entre les deux.

Concepts à connaître avant de choisir

Une version, plusieurs destinations

La même image qui s'exécute en test est l'image qui doit s'exécuter en production.

Pas une reconstruction à partir du même commit, pas une recompilation avec des drapeaux différents, les mêmes octets. Reconstruire par destination introduit un écart entre ce qui a été validé et ce qui a été livré, et cet écart est invisible jusqu'à ce que quelque chose en dépende. Les équipes convergent rapidement vers cela, car l'alternative est une catégorie de bug qui ne se reproduit nulle part ailleurs que devant les joueurs.

Unicité des tags

Un tag réutilisé cesse d'être un identifiant pour devenir une étiquette.

« Nous avons déployé la v2.3 » est une déclaration précise jusqu'à ce que quelqu'un pousse une image différente sous le même tag, point auquel elle décrit deux builds selon le moment où vous posez la question. Attacher quelque chose d'unique à chaque tag, un numéro de build ou un hash de commit, préserve la capacité de répondre à cette question plus tard. Cela ne coûte rien au moment de la construction et est difficile à intégrer après coup.

Un détail ici est facile à rater. Un tag comme prod-2026.09.14-v2.3.0 semble logique, mais il place la destination à l'intérieur de l'identifiant, ce qui signifie que le build approuvé par l'AQ n'est pas le build qui est livré. Garder l'environnement en dehors du tag (2026.09.14-v2.3.0) et plutôt dans le pointeur est ce qui rend la promotion possible sans reconstruction.

Les pointeurs et ce qu'ils désignent

Une fois l'artefact figé, vous avez besoin de quelque chose de muable pour indiquer lequel est actif.

C'est le pointeur, et sur la plupart des plateformes, il s'agit d'une version nommée, d'une branche ou d'une valeur de configuration lue par votre matchmaker. Son seul rôle est d'être modifiable, rapidement et de manière réversible, ce qui permet aux deux concepts suivants de fonctionner.

Comment les choses avancent

Rien ne devrait passer du test à la production sur une minuterie, lors d'une fusion (merge) ou comme effet secondaire d'autre chose.

La promotion fonctionne mieux en tant qu'action propre, distincte de la construction et du déploiement, car cette séparation est ce qui permet à une personne ou à une vérification de s'interposer entre un build et ses joueurs. Les équipes divergent sur la question de savoir qui l'exécute. Elles s'accordent généralement à dire qu'il doit s'agir d'un acte identifiable unique plutôt que d'une propriété émergente du pipeline.

Revenir à un build précédent

Faire un retour en arrière (rollback) signifie remettre les joueurs sur le build qui était actif auparavant. La rapidité avec laquelle cela se produit dépend d'un choix fait plus tôt : si l'artefact précédent existe toujours dans un endroit accessible.

Si c'est le cas, le retour en arrière est le même changement de pointeur que la promotion, exécuté en sens inverse. Quelques secondes, et rien de nouveau ne peut casser. Si ce n'est pas le cas, le retour en arrière passe par un travail de construction (build job), ce qui prend le temps d'une construction et peut échouer de différentes manières. La différence ne réside pas dans l'outillage ou la compétence. Elle réside dans le fait de savoir si l'ancien build a été conservé.

Conserver une poignée de builds récents coûte de l'espace de stockage sur le registre. La plupart des équipes trouvent cela moins cher que l'alternative.

Où réside la configuration

Certains paramètres diffèrent entre le test et la production : les régions dans lesquelles s'exécuter, la base de données à interroger, les clés à utiliser. Ces valeurs peuvent soit être intégrées au build, soit lui être fournies au démarrage.

Intégrées, le build de test et le build de production sont deux builds différents, et « une version, plusieurs destinations » cesse discrètement d'être vrai. Fournies au démarrage, généralement sous forme de variables d'environnement, un build unique reste valide partout.

La conclusion est simple. Si vous vous retrouvez à construire deux fois parce que deux environnements ont besoin de paramètres différents, c'est que les paramètres ne sont pas au bon endroit.

Builds froids et fenêtres de cache

Les plateformes qui distribuent des builds dans le monde entier gardent ceux récemment utilisés prêts à s'exécuter, et laissent ceux inutilisés quitter cet état de préparation. Un build que personne n'a déployé depuis un certain temps peut avoir besoin d'être récupéré à nouveau avant de pouvoir démarrer, ce qui ajoute du temps au premier déploiement après une période calme.

Cela importe surtout pour le retour en arrière, car le build que vous souhaitez récupérer est par définition un build que vous avez arrêté de déployer. Sur Edgegap, les images mises en cache expirent après 72 heures consécutives sans déploiement, de sorte qu'un build resté inactif pendant un long week-end est froid le lundi.

Les équipes soucieuses de la vitesse de retour en arrière déploient soit occasionnellement le build précédent pour le maintenir prêt, soit acceptent le délai et s'organisent en conséquence. Les deux options sont raisonnables. Ce qui est dommageable, c'est de ne pas savoir laquelle vous avez choisie.

Trois autres éléments méritent d'être nommés sans s'y attarder. Les builds clients et les versions de serveurs évoluent ensemble, donc une promotion est aussi une décision de compatibilité. Le nettoyage du registre a besoin d'une limite minimale ainsi que maximale, car « supprimer tout ce qui a plus de 30 jours » finit par supprimer l'élément vers lequel vous vouliez revenir. Et ce que vous voulez réellement après un incident est précis : quelle image, promue par qui, quand.

Approche 1 : Deux versions et une règle

Pour les développeurs solos et les équipes de deux ou trois personnes, où la décision de publication se prend dans la tête d'une seule personne.

À cette échelle, le goulot d'étranglement n'est pas la coordination, c'est la mémorisation. Il n'y a pas d'équipe d'AQ pour valider ni de second ingénieur pour détecter une erreur, la structure doit donc être suffisamment simple pour qu'il soit plus difficile de l'ignorer que de la suivre. Deux versions, c'est à peu près la plus petite structure possible tout en restant une structure.

    Tags       2026.09.14-1, 2026.09.14-2, 2026.09.15-1

    Pointeurs   test  ->  2026.09.15-1

               prod  ->  2026.09.14-2

Ce que cela évite, c'est la défaillance spécifique d'un build non révisé atteignant les joueurs.

Ce que cela ne vous donne pas, c'est un historique expliquant pourquoi une promotion a eu lieu ou ce qui a changé.

À trois personnes, c'est généralement suffisant, car il suffit de demander. Cela cesse de fonctionner à peu près au moment où la réponse à « qui a promu ceci ? » n'est plus évidente.

La configuration devrait prendre moins d'une heure. Le coût continu est d'une minute ou deux par publication.

Approche 2 : La CI détient le Staging, une personne détient la Production

Pour les équipes dans des studios de cinq à trente personnes environ, où les builds dépassent l'attention d'une seule personne.

Une fois que les builds se produisent plus rapidement que quiconque ne peut les suivre, la séparation utile n'est pas d'avoir plus d'environnements. La séparation préférable est entre ce qui est automatisé et ce qui reste manuel. Automatiser tout jusqu'à la production élimine la monotonie. Laisser la dernière étape manuelle permet de garder une personne dans la boucle au seul moment où une erreur coûte cher. Cette asymétrie est l'idée directrice, et l'essentiel de la structure ci-dessous existe pour la soutenir.

    Tags       v1.4.2-a91c3f      (semver + hash de commit court, généré par la CI)

    Pointeurs   dev      ->  construit à chaque push sur une branche de fonctionnalité

               staging  ->  mis à jour automatiquement lors de la fusion sur main

               prod     ->  mis à jour uniquement par un job de CI déclenché manuellement

• Les tags proviennent de la CI, jamais d'une personne : Le numéro de version indique à un humain ce qui a changé. Le hash rend le build reproductible à partir du seul tag, ce qui est plus important qu'il n'y paraît.

• La fusion sur main met à jour staging automatiquement, et rien d'autre n'est automatique. La production est mise à jour par un job distinct, déclenché manuellement, qui prend un tag en entrée et l'inscrit sur le pointeur prod. Deux propriétés découlent de l'acheminement par la CI plutôt que par un tableau de bord : la promotion est enregistrée, tout comme l'identité de la personne qui l'a déclenchée. C'est l'essentiel d'une piste d'audit gratuite.

• Bon à savoir sur la couche plateforme ici. Sur Edgegap, les versions d'applications sont muables, de sorte que mettre à jour prod pour pointer vers un nouveau build est une mise à jour d'une version existante plutôt qu'un nouvel objet. C'est pratique, et c'est aussi pourquoi acheminer le changement via la CI est important. Le changement lui-même ne laisse aucune trace. Le job qui l'a effectué en laisse une.

  • Note : Edgegap expose également un indicateur is_active sur les applications et les versions, documenté comme une protection contre les erreurs de développement. Il est utile de l'intégrer au processus de gestion des incidents, car désactiver une mauvaise version est plus rapide que de décider vers quoi revenir, et ces deux décisions n'ont pas à se faire dans la même minute. La plateforme d'orchestration expose les deux via la même API que le job de promotion utilise déjà.

• Le nettoyage devient une tâche planifiée plutôt qu'une corvée mensuelle : Le format que la plupart des équipes souhaitent est « supprimer les versions de plus de trente jours, jamais moins que les dix dernières, et jamais rien de référencé par un déploiement actif ». Edgegap ne dispose pas d'un moteur de politique de rétention aujourd'hui, cela est donc écrit via l'API plutôt que configuré. Environ un après-midi de travail, et la règle d'exclusion est la partie qui mérite le plus d'attention.

• Les builds clients et les versions de serveurs évoluent toujours ensemble : Les équipes de cette taille maintiennent généralement la version de prod précédente déployable pendant une fenêtre de tir après la promotion, afin que les joueurs sur un client obsolète ne soient pas bloqués en cours de session.

L'avantage est que personne n'a besoin de se souvenir de quoi que ce soit, et l'historique de ce qui a été livré existe sans que personne n'ait à le maintenir.

Ce que cela ne fait toujours pas, c'est empêcher une promotion qui n'aurait pas dû avoir lieu. Il y a un humain dans la boucle, et les humains approuvent des choses.

La configuration devrait prendre environ une journée de travail pour un ingénieur backend. Le coût continu est proche de zéro.

Approche 3 : Promotion auditable

Pour les studios ayant des opérations en direct (live-ops), des exigences de conformité ou un processus de publication antérieur au choix de l'infrastructure.

À cette échelle, le processus de publication existe généralement déjà, défini par des personnes qui ne travaillent pas sur l'infrastructure, et le rôle de la plateforme est de s'y intégrer plutôt que de le remplacer. Cela change la question de conception. Le but n'est plus de garder le processus léger, mais de rendre chaque étape inspectable, car quelqu'un finira par demander ce qui a été livré, quand, et avec l'approbation de qui, et « je m'en souviens » ne résiste pas à la question.

    Tags       v1.4.2-a91c3f        (alias lisible par l'humain)

    Identité   sha256:9f2c...       (ce sur quoi les déploiements s'alignent réellement)

    Pointeurs   staging      ->  digest

               prod-canary  ->  digest

               prod         ->  digest, modifié uniquement par un commit révisé et fusionné

• Les digests plutôt que les tags : Un tag est une étiquette choisie par un humain, et les humains peuvent déplacer les étiquettes. Un digest est un hash de contenu et ne peut pas être déplacé. Les studios qui associent les déploiements à des digests traitent les tags purement comme des alias lisibles par l'humain. C'est le plus grand saut qualitatif en matière de rigueur disponible, et cela ne coûte rien de plus qu'un changement dans ce que la CI enregistre.

• Versions déclarées en tant que code : Gérer les versions via Terraform ou l'API plutôt que via un tableau de bord transforme une promotion en un changement révisé et fusionné avec un auteur, un horodatage et un diff. Le processus d'approbation existant du studio s'applique alors automatiquement, car la promotion est une pull request comme une autre. Les deux voies existent sur Edgegap, et c'est à ce niveau que cela importe le plus. Pour la couche inférieure, le guide d'Edgegap sur l'hébergement de serveurs de jeu évolutifs avec Docker ou Kubernetes explique comment les conteneurs eux-mêmes sont construits et exécutés.

• Des étapes de validation avant le déplacement du pointeur : Un test d'endurance (soak test), un test de charge (load benchmark), une validation de l'AQ enregistrée dans un format lisible par machine. La distinction importante réside entre un processus que les gens suivent et un processus que le pipeline impose. Le second survit à une mauvaise semaine.

• Canary : Un pointeur distinct qui reçoit une petite partie du trafic réel avant la promotion complète. Soyez lucide sur ce que cela implique : acheminer les joueurs vers une version spécifique de serveur est une chose que les studios construisent aujourd'hui dans leur propre couche de matchmaking ou de session, et non quelque chose que les plateformes d'orchestration vous fournissent généralement. Une version distincte, une règle d'acheminement qui vous appartient, et une fenêtre d'observation avec une définition convenue de ce qui est propre.

• Signature et provenance : Images signées à la construction, signatures vérifiées à la promotion, promotion refusée en cas d'échec de la vérification. C'est de plus en plus une exigence de conformité plutôt qu'un confort, en particulier pour les studios qui publient sur console.

• Rétention avec exclusions : Nettoyage automatique comme dans l'approche 2, avec une règle stricte stipulant que rien de ce qui est référencé par un pointeur actif ou canary ne peut être supprimé, et avec la suppression elle-même consignée dans les logs.

Tout cela est réalisable sur n'importe quelle plateforme qui expose des versions et une API, et rien de tout cela n'est réalisable sans des directives claires et une connaissance pratique du processus interne du studio.

Le temps que cela prend dépend entièrement de ce à quoi ressemble déjà ce processus.

Choisir entre ces approches

Le signal utile n'est pas directement la taille de l'équipe. C'est la fréquence à laquelle la réponse à « qui a promu ceci, et pourquoi » nécessite de demander à quelqu'un.

Lorsque la réponse est évidente parce que vous êtes trois, l'approche 1 n'est pas un compromis, elle est correcte. Lorsque vous vous surprenez à poser la question, l'approche 2 est amortie en un mois environ. Lorsque quelqu'un en dehors de l'équipe d'ingénierie a besoin de la réponse, vous êtes déjà dans le territoire de l'approche 3, que vous l'ayez construite ou non.

Il y a un compromis derrière tout cela qu'il convient d'énoncer clairement. Une plateforme qui vous impose un pipeline prédéfini vous évite cette décision mais vous prive de la possibilité de faire différemment. Une plateforme qui vous fournit des versions et une API vous demande de choisir, ce qui n'est un fardeau que si personne ne choisit. La plupart des équipes mécontentes de l'un ou l'autre de ces arrangements y sont parvenues par défaut plutôt que par décision.

Choisissez-en une délibérément, et comme pour tout développement logiciel, attendez-vous à faire une itération, soit à grande échelle, soit une fois que le processus se sera solidifié. Une première structure claire est ce qui rend la seconde plus facile à construire.