Aylin Yazıcı, consultante chez Deconstructor of Fun et responsable du développement commercial chez Ciao Games, a publié en juillet 2026 une analyse comparative entre développement interne et achat pour les studios de jeux (The Hidden Cost of Studio Engineering). Elle y soutient que les développements d'ingénierie internes coûtent presque toujours plus cher que ce que croient les studios qui les réalisent, et propose un calculateur du coût total de possession pour le prouver. Elle s'appuie sur son expérience au sein de plusieurs studios, dont un qu'elle a dirigé, ainsi que sur des audits de diligence raisonnable menés auprès des équipes techniques centrales de plusieurs grands éditeurs de jeux free-to-play.

Indirectement, cela permet à n'importe quel studio de chiffrer une décision qui se prend généralement à l'instinct. Nous avons donc appliqué son calculateur à un cas bien précis : l'adoption d'Agones.

L'illusion comptable s'aggrave lorsque le logiciel est gratuit

Sega a enregistré une dépréciation d'actif de 200 millions de dollars sur Rovio dans ses résultats du troisième trimestre. Yazıcı ouvre son analyse sur ce chiffre, en observant que l'équipe technique interne de Rovio y a contribué. Son autre exemple est le licenciement par Microsoft de l'équipe technique d'id Software, les créateurs de Doom, Quake et Wolfenstein.

Elle décrit ensuite la réunion que tous les studios ont déjà connue. La démo se passe bien, le produit est solide, l'équipe censée l'utiliser en veut. Et puis un ingénieur principal ou un directeur technique lâche la phrase : « Pourquoi ne pas le construire nous-mêmes ? » L'outil tiers est abandonné, un projet interne est lancé et, comme elle l'écrit, « personne ne fait jamais le calcul des coûts réels ».

Son diagnostic est d'ordre comptable. Une licence apparaît sur une ligne budgétaire et nécessite une approbation. Un développement interne se dilue dans les salaires existants et les cycles de sprint.

« La comptabilité donne l'impression que les développements internes sont gratuits, alors qu'ils ne le sont pas. »

Agones est l'exemple parfait de ce phénomène poussé à l'extrême, car le logiciel est véritablement gratuit. Il n'y a pas de devis à comparer, pas de ligne budgétaire à approuver, et donc aucun moment où quiconque est contraint de produire un chiffre.

Agones n'est pas le projet. C'est la plateforme qui l'entoure qui l'est.

Adopter Agones ne signifie pas écrire un orchestrateur. Cela signifie exploiter une plateforme d'orchestration, comme le projet se décrit lui-même : « une plateforme open source de mise à l'échelle et d'orchestration de serveurs de jeux dédiés multijoueurs s'appuyant sur Kubernetes ».

Le mot d'ordre est plateforme. Agones gère les pods GameServer, les Fleets et le FleetAutoscaler. Tout ce dont une plateforme a également besoin, c'est à vous de le fournir : provisionnement et mise à l'échelle des nœuds, registre d'images et circuit de distribution, surveillance et journalisation, gestion de la capacité tampon, secrets, CI/CD dans le cluster, gestion des états et accès à la base de données pour l'attribution, alertes, et un ingénieur d'astreinte lorsque le remplissage d'une flotte s'interrompt.

PUBG: BATTLEGROUNDS est un cas d'étude utile car KRAFTON en a publié les chiffres. Lors de leur session AWS re:Invent 2024, le responsable de l'équipe DevOps, JungHun Kim, a détaillé le temps de démarrage d'un serveur de session sur Agones en trois étapes : le provisionnement de l'instance (1 à 3 minutes), le bootstrapping de l'instance (2 à 3 minutes) et le provisionnement du pod (5 à 10 minutes). Au total, selon les propres termes de KRAFTON : « 10 à 15+ minutes ».

Deux autres projets ont suivi.

Le premier a remplacé Cluster Autoscaler et EKS NodeGroups par Karpenter, afin de supprimer la surcharge liée au groupe d'autoscaling et d'obtenir un provisionnement de nœuds sans groupe avec dimensionnement automatique, regroupement optimal (bin-packing) et détection de dérive.

Le second était un proxy de registre de conteneurs : Harbor, un compartiment de cache S3, CloudFront et un DaemonSet personnalisé ImagePuller qui télécharge l'image pendant que le nœud est encore en cours de bootstrapping. Le résultat mesuré par KRAFTON a été un temps de téléchargement réduit à 2 ou 3 minutes, et un démarrage global passant de « plus de 15 minutes » à « 3 à 4 minutes ».

Ce second projet n'est pas de la simple configuration. Il s'agit d'un système de distribution d'images, conçu et maintenu en interne. KRAFTON a également listé les inconvénients sur sa propre présentation : la concurrence du provisionnement était « difficile à gérer », et les ressources étaient « impossibles à ajuster de manière dynamique » avant Kubernetes 1.32 sur EKS.

L'orchestrateur n'était que le point de départ, pas l'intégralité du projet. L'analyse détaillée d'Edgegap sur ce que implique son exploitation est disponible dans The High Cost of Free Products: Agones.

L'intégration d'Agones coûte-t-elle vraiment 42 000 $ ?

Commençons par le chiffre qu'un studio inscrirait réellement dans son plan de projet. 42 000 $.

C'est le résultat du calculateur de Yazıcı appliqué à une adoption volontairement modeste : un développeur senior, un mois à plein temps, puis deux mois d'intégration et de tests plus légers. Le salaire de base est fixé à 135 000 $ par an, ce que le calculateur augmente à 169 000 $ une fois que l'on applique les 25 % de charges patronales.

Ce salaire est volontairement élevé. levels.fyi estime la rémunération totale moyenne d'un ingénieur logiciel de jeu vidéo à 96 542 $ et celle d'un ingénieur DevOps à 79 296 $. Les compétences réelles exigées par Agones concernent Kubernetes, Linux, Docker et containerd, un langage comme Go ou Python, en plus du réseau et de la sécurité ; nous avons donc modélisé le profil d'un spécialiste plutôt qu'un recrutement moyen. Considérez ce salaire comme une limite supérieure.

Ajoutez ensuite un ingénieur DevOps mobilisé à hauteur d'environ 30 à 50 % de son temps une fois le jeu lancé, et projetez le tout sur trois ans :

La réponse à la question du titre de cette section est donc oui, et cela ne représente que 7 % du coût global.

Deux nuances s'imposent, car elles font la différence entre un chiffre utile et un argumentaire marketing.

Premièrement, le coût d'opportunité relève du modèle du calculateur, pas d'une de nos mesures. La formule de Yazıcı, publiée dans la méthodologie du calculateur, est la suivante : coût annuel total de l'équipe multiplié par les années restantes après la fin du développement, en partant du principe qu'un ingénieur affecté à l'infrastructure est un ingénieur qui ne travaille pas sur le jeu. On peut contester le modèle, mais il faut le faire selon ces conditions.

Deuxièmement, cette ligne part du principe que l'ingénieur reste affecté à plein temps. Le développement prend 3 mois, ce qui laisse 2 ans et 9 mois sur la période, et le calculateur facture la totalité des 169 000 $ pour chacune de ces années. Notre scénario n'engage qu'entre 30 et 50 % d'une personne. Si l'on ajuste cette ligne à 40 %, le total sur trois ans s'établit plutôt aux alentours de 289 000 $.

Ce qui ne change pas dans les deux versions, ce sont les premiers 103 000 $ ou la proportion. L'intégration que tout le monde prévoit s'élève à 42 000 $. Tout ce qui suit représente entre deux et douze fois ce montant. Le calculateur lui-même souligne que la plupart des entreprises sous-estiment les coûts d'un facteur de 3 à 5.

La maintenance représente la majeure partie de la facture, pas le développement

C'est là que la plupart des estimations initiales de projets s'effondrent. « Le backend que vous lancez n'est pas le backend que vous conservez. » Les plateformes se mettent à jour, les SDK deviennent obsolètes, des failles de sécurité apparaissent, les versions de moteurs changent. Le calendrier de dépréciation de Google Play Games Services est un exemple concret de ce compte à rebours qui tourne, que le studio soit prêt ou non.

L'indicateur cité par Yazıcı, qu'elle attribue à des recherches de l'IEEE et à des analyses de Gartner, s'élève à 15 % à 25 % du coût de développement initial par an. Chaque année. Sans fin. Sur l'ensemble de la durée de vie d'un système, la maintenance consomme 60 % à 80 % du coût total du cycle de vie. Le développement initial ne représente qu'une part minoritaire de vos dépenses.

Une plateforme d'orchestration est une illustration particulièrement exigeante de ce principe. Les versions mineures de Kubernetes s'enchaînent à un rythme fixe et abandonnent le support des anciennes versions, les images de nœuds évoluent, les composants de CNI et d'ingress changent, et Agones suit sa propre grille de compatibilité Kubernetes. Le fait souligné par KRAFTON, à savoir que l'ajustement dynamique des ressources nécessitait Kubernetes 1.32 sur EKS, en est la preuve parfaite : une fonctionnalité bloquée derrière une mise à niveau de cluster que quelqu'un doit planifier, tester et exécuter.

Rien de tout cela ne peut être différé, car vous ne pouvez pas faire l'impasse sur un correctif de sécurité pour le processus qui lance vos parties. Comme le résume Yazıcı, « ce que vous achetez a déjà été testé au combat par d'autres ; ce que vous construisez, eh bien, c'est vous qui allez devoir le tester en direct auprès de vos utilisateurs. » Le guide d'Edgegap sur l'hébergement de serveurs de jeux évolutifs avec Docker ou Kubernetes détaille ces différents aspects.

L'évolution ne s'arrête jamais pour un jeu service

La maintenance permet de maintenir le système opérationnel. L'évolution englobe tout ce que l'on demande au système de faire alors qu'il n'a pas été conçu pour cela.

Les jeux service n'ont pas de fonctionnalités figées, un point que Deconstructor of Fun a longuement développé dans The Backend Jungle. Les nouveaux modèles de monétisation nécessitent une nouvelle logique, les nouvelles plateformes exigent de nouvelles intégrations, et les nouveaux comportements des joueurs font émerger de nouvelles exigences backend. « Chaque évolution est un mini-projet de développement financé par la même capacité d'ingénierie dont vous avez besoin pour le jeu lui-même », écrit Yazıcı.

Pour l'orchestration, les demandes sont prévisibles et infinies. Une nouvelle région. Le lancement sur une console avec des règles réseau différentes. Le cross-play. Un pic soudain d'audience provoqué par un créateur un mardi sans prévenir.

Il existe également une incompatibilité structurelle sous-jacente à la charge de travail. Comme le formule l'analyse d'Agones par Edgegap : « Kubernetes a été initialement conçu pour les technologies web. Celles-ci gèrent des milliers de connexions sans état, répondant à de petites requêtes en une fraction de seconde. Les serveurs de jeux sont à l'opposé de cette philosophie. Les serveurs de jeux et les relais ont un état et gèrent des connexions persistantes pendant 5 à 45 minutes. »

Ce qui a changé depuis le lancement d'Agones en 2018, c'est que les avantages des conteneurs recherchés par KRAFTON (standardisation, bin-packing et unité déployable unique) ne nécessitent plus d'exploiter la plateforme soi-même. C'est tout le principe de l'orchestration managée.

Le développement n'est que la moitié de l'équation

Tout ce qui précède représente le coût de construction et d'exploitation de la plateforme. Aucun de ces chiffres n'inclut la facture des serveurs eux-mêmes.

Cette distinction est cruciale car la tâche récurrente d'un orchestrateur n'est pas le déploiement, mais le taux de remplissage. Les serveurs sont facturés pour chaque heure d'existence, pas pour les joueurs présents dessus. Un nœud hébergeant deux parties alors qu'il pourrait en contenir six coûte exactement la même chose qu'un nœud complet, et la différence est de l'argent jeté par les fenêtres.

La mise à l'échelle dans les deux sens creuse cet écart. L'augmentation de la capacité se fait par instances entières ; ainsi, dès que la demande dépasse un seuil, vous payez pour un nœud complet afin de gérer le surplus. La réduction de la capacité ne peut pas se faire tant que les sessions déjà présentes sur un nœud ne sont pas terminées, car les parties ont un état ; vous continuez donc à payer pendant qu'il se vide. Un provisionnement lent accentue ces deux phénomènes : si la capacité met 10 à 15 minutes à devenir opérationnelle, vous devez conserver une réserve de sécurité active pour combler le manque, et une réserve est par définition inactive.

La diapositive des exigences de KRAFTON le mentionne directement, listant « la mise à l'échelle des ressources et la gestion des tampons pour répondre aux demandes » ainsi que « l'optimisation de l'efficacité des VM par le regroupement optimal des ressources » sous l'angle de l'efficacité des coûts, aux côtés de la standardisation et de l'évolutivité.

Un studio peut très bien sortir gagnant du calcul développement-achat et perdre de l'argent chaque mois sur l'utilisation réelle des serveurs. Pouvoir provisionner suffisamment vite pour ne pas avoir besoin d'une réserve d'attente est tout l'argument en faveur de l'orchestration de conteneurs juste-à-temps.

La ligne budgétaire qui fera débat

Sur les 567 000 $ modélisés, 464 000 $ représentent un coût d'opportunité. Yazıcı le qualifie à la fois de coût le plus élevé et de celui qu'aucun tableur ne capture, ce qui explique pourquoi son intégration dans son propre tableur est délibérée.

Son argument n'est pas que les studios devraient réduire leurs équipes d'ingénierie. C'est le contraire. « Vos meilleurs ingénieurs backend ne devraient pas passer du temps à coder un matchmaking qui existe déjà. » L'orchestration est un prérequis de base. Comme elle l'écrit : « Aucun joueur n'a jamais acheté un jeu parce que ses outils de matchmaking ou de Live Ops avaient été développés en interne. »

Ce coût se matérialise par des jeux qui sortent plus tard, avec moins de fonctionnalités Live Ops, sur un marché qui n'a pas attendu. Les ingénieurs de KRAFTON ont résolu leur problème de bootstrapping, et ils l'ont bien fait. Mais ils ont aussi passé tout ce temps à résoudre un problème de bootstrapping.

Pour les studios qui comparent le coût d'une alternative avec une ligne interne à six chiffres, Edgegap est gratuit pour démarrer avec un tarif unique pour toutes les localisations, et l'installation ne prend que quelques minutes pour les développeurs qui connaissent leur infrastructure. QLOUD Games a ainsi migré l'écosystème d'hébergement et d'orchestration de serveurs de jeu de Loftia vers Edgegap en moins de 24 heures.

La conclusion de Yazıcı est celle qui résume le mieux la situation : « L'achat d'infrastructures est une décision d'allocation de capital. Et comme toute décision d'allocation de capital, elle mérite une analyse rigoureuse plutôt qu'un choix par défaut basé sur l'argument