L'avenir du développement de jeux est-il un pipeline construit autour d'équipes de cinq personnes, de cycles de prototype de quatre mois et d'une communauté de joueurs triée sur le volet qui détermine quelles idées avancent ?

Avalanche Studios semble le penser. Dans un récent portrait sur gamesIndustry.biz, la Chief Publishing Officer Emma Farrow a décrit exactement ce modèle : les jeux qui ne font pas leurs preuves sont éliminés, et l'élimination est considérée comme la preuve que le processus fonctionne. Comme l'a formulé Michael Duning-PTC en observant l'article :

« Les idées qui survivent sont celles qui font leurs preuves. »

Ce qui suit est notre lecture de ce que ce modèle de développement implique pour la décision développer ou acheter en matière d'infrastructure de serveurs de jeux. Il s'agit du point de vue de Mathieu Duperré, fondateur et PDG chez Edgegap, plutôt que d'une affirmation sur ce qu'Avalanche a dit ou fait.

Une chaîne de production fondée sur l'échec attendu

L'approche d'Avalanche est un transfert direct de la discipline du développement mobile vers le PC et les consoles. Supercell est l'exemple canonique du mobile :

• plusieurs petites équipes,

• une élimination agressive,

• le succès occasionnel qui finance tout le reste.

Sur leurs 10 derniers jeux à un moment donné, sept ont été abandonnés au stade du prototype, deux en lancement progressif, et un (Clash Royale) a été lancé mondialement. Farrow décrit structurellement la même chose, simplement pour des publics PC et console.

La logique est saine. Valider la créativité très tôt pendant que les équipes sont petites permet de garder les questions coûteuses à bas prix. Est-ce que c'est amusant ? Y a-t-il un public pour cela ? Il vaut mieux répondre à ces questions au quatrième mois avec cinq personnes qu'au trente-sixième avec deux cents. Et lorsqu'un prototype meurt, Farrow le présente comme la preuve que le processus fonctionne, et non comme un signe d'efforts gaspillés.

Ce changement de perspective est important.

Dans ce modèle, l'argent dépensé sur des prototypes qui ne sortent pas n'est pas du gaspillage. C'est le coût pour trouver celui qui le sera.

Le calcul d'infrastructure que la plupart des studios ratent

Voici où la question développer ou acheter pour les serveurs de jeux devient intéressante.

L'infrastructure provisionnée traditionnellement (instances réservées, capacité achetée à l'avance, flottes dédiées) est conçue pour un jeu connu avec une charge soutenue à long terme. Elle s'amortit bien lorsqu'un titre tourne pendant des années. Elle s'amortit mal lorsque le résultat attendu est que la plupart des projets soient annulés.

Un studio qui fait tourner trois prototypes en parallèle, chacun avec un test de jeu communautaire mensuel, fait face à une question différente de celle d'un studio qui lance un seul jeu service. La question n'est pas « comment faire évoluer notre capacité au lancement ». C'est « comment éviter de payer des serveurs pour des jeux qui ne sortiront jamais ». Ce sont des problèmes différents, et la plupart des solutions d'hébergement traditionnelles sont conçues pour répondre au premier.

L'orchestration à la demande change le calcul. Un prototype qui exécute environ 100 heures de tests communautaires en ligne par mois coûte quelques dollars sur une plateforme à l'usage, bien loin des centaines ou des milliers qu'impliquent des capacités réservées. Ce n'est pas une amélioration marginale. C'est une autre catégorie d'engagement financier, qui rend économiquement cohérent le fait de faire tourner quatre ou cinq prototypes en parallèle plutôt que téméraire. Le calculateur de tarifs d'Edgegap concrétise cela : les studios peuvent tester combien coûteraient leurs heures de test réelles avant de s'engager dans quoi que ce soit.

Le problème d'une équipe de cinq personnes

Il y a une deuxième implication, moins liée à l'argent qu'au temps et à la lourdeur organisationnelle.

Une équipe de prototype de cinq personnes compte un programmeur, un designer, peut-être un généraliste qui porte plusieurs casquettes. Il n'y a pas de place pour un ingénieur d'infrastructure dédié. Si la mise en place de tests multijoueur exige une configuration Kubernetes, la gestion d'un registre de conteneurs ou la négociation de capacité réservée, l'une de deux choses se produit. Le prototype renonce purement et simplement aux tests multijoueur, ce qui produit un signal plus faible lors du test communautaire. Ou bien l'équipe attend le DevOps central, ce qui tue discrètement la vitesse d'itération sur laquelle tout le modèle repose.

Il y a aussi la question de ce que signifie réellement « construire sa propre solution » à grande échelle. Les plateformes d'orchestration open source comme Agones nécessitent une expertise Kubernetes approfondie pour fonctionner correctement, une maintenance continue et du temps d'ingénierie dédié rien que pour le faire fonctionner. Les studios qui investissent dans cette infrastructure la justifient parfois en la considérant comme amortissable entre plusieurs projets. Mais dans un modèle où la plupart des projets meurent, ces « services centraux » sont quand même imputés en interne à chaque prototype, ce qui augmente le coût de chaque petit pari et relève le seuil de revenus qu'un jeu doit atteindre avant d'être rentable. C'est l'inverse de ce qu'exige l'itération rapide.

L'orchestration en libre-service et à la demande supprime ce goulot d'étranglement. L'équipe prototype déploie un serveur, lance le playtest, puis passe à autre chose. Aucun ticket n'est ouvert. Pas d'attente. Et si le jeu est abandonné au quatrième mois, aucune dette d'infrastructure n'est reportée. La plateforme d'orchestration d'Edgegap démarre les serveurs de jeu à partir d'un état froid en moyenne en 3 secondes, ce qui est le genre de délai dont a réellement besoin une petite équipe qui organise une session de playtest à durée limitée.

Une opinion éclairée : ce que cela signifie pour le développement interne ou l'achat

Pour être clair, il s'agit de notre point de vue plutôt que d'un schéma établi à l'échelle du secteur.

À notre avis, les studios qui choisissent de faire de nombreux petits paris choisissent aussi implicitement d'acheter plutôt que de construire l'infrastructure, qu'ils l'aient formulé ainsi ou non. Construire une infrastructure de serveurs sur mesure n'a de sens économique que si un grand jeu amortira cet investissement sur un long horizon. Un modèle qui suppose que la plupart des projets échouent par conception se trouve structurellement au mauvais endroit pour construire.

Nous voyons cela à l'œuvre chez des studios sur la plateforme d'Edgegap. Halfbrick Studios, l'éditeur derrière Fruit Ninja, a utilisé l'orchestration à la demande pour Thrill of the Fight 2, un titre à budget plus modeste qui avait besoin d'une véritable infrastructure multijoueur sans équipe DevOps dédiée pour la faire tourner. Un petit jeu, traité avec le même sérieux infrastructurel qu'un grand, sans la structure de coûts d'un gros jeu. C'est le modèle. Certains des plus grands studios du monde, ceux dont vous reconnaîtriez immédiatement le nom, utilisent la même approche pour exactement la même raison : une production variable exige des coûts variables, et l'alternative consiste à payer une infrastructure pour des jeux qui ne sortent jamais.

Les studios qui le comprennent tôt mènent des cycles de prototypage plus légers. Ceux qui ne le comprennent pas supportent des coûts d'infrastructure sur des jeux qui ne sortent jamais, ce qui rend tout le modèle d'itération rapide plus coûteux qu'il ne devrait l'être. L'industrie mobile l'a appris au fil des années d'itération. Les studios PC et console qui adoptent la même philosophie de développement n'ont pas à l'apprendre à la dure.

—

Cet article s'inspire du reportage de Lewis Packwood et le cite, publié sur GamesIndustry.biz le 10 mars 2026, ainsi que de l'observation de Michael Duning-PTC, publiée sur LinkedIn. Tous les droits relatifs au contenu original appartiennent à leurs détenteurs respectifs.