Cet article a été écrit à l’origine en italien par Paolo Gambardella. Il a été traduit par un agent d’intelligence artificielle et peut contenir des inexactitudes.
Les stores sont submergées de jeux. On le voit tous, et c’est une conséquence directe de quelque chose d’évident : faire un jeu simple est devenu rapidement accessible. Godot, Unity, asset stores, IA pour le code, tutoriels YouTube pour n’importe quoi. Le temps de développement s’est compressé de manière brutale. Et du coup, tout le monde s’y met.
Le résultat, c’est un déluge. Des clones, des jeux générés avec des pipelines semi-automatisées, des produits assemblés plutôt que conçus. Chacun de ces jeux a la même caractéristique : il est fait vite, avec une petite équipe ou en solo, avec peu d’investissement par unité.
Quand tout le monde fait la chose facile, la chose difficile prend de la valeur. Même Roblox le démontre, avec sa nouvelle stratégie de miser sur les jeux HD. Si les jeux simples deviennent une commodité, alors les jeux qui exigent quelque chose qu’on ne génère pas automatiquement deviennent rares.
Ce qui me trotte dans la tête
Les équipes du futur proche ont une caractéristique nouvelle : elles peuvent être vraiment cross-fonctionnelles. Pas dans le sens galvaudé qu’on entend en entreprise depuis des années. De façon concrète, pratique, radicale.
Des exemples.
-
Un designer n’a plus besoin d’attendre un programmeur pour construire un prototype. Avec les outils d’aujourd’hui, il peut construire quelque chose de fonctionnel en quelques heures. Il peut tester sa boucle de jeu avant même que la réunion avec la tech team soit mise au calendrier.
-
Un artiste peut implémenter directement dans le moteur sans attendre le support des tech artists. L’artiste qui comprend un peu comment fonctionne le moteur n’est plus une exception exotique, c’est une ressource normale.
-
Un writer peut tester sa narration dans une build fonctionnelle sans ouvrir un ticket et attendre que l’équipe gameplay lui « trouve un créneau dans le prochain sprint ».
Les rôles ne disparaissent pas. C’est la bonne excuse qui disparaît.
Attention : je ne dis pas que les rôles spécialisés vont devenir inutiles. Un tech artist expérimenté fait des choses qu’un artiste avec shader graph ne fera jamais. Un programmeur senior résout des problèmes qu’un designer avec un assistant IA ne sait même pas formuler.
Le point est ailleurs. La barrière de transfert entre les rôles s’abaisse. Et avec elle disparaît aussi l’excuse la plus confortable de l’industrie : ce n’est pas mon problème.
Si avant tu pouvais rester dans ta niche confortable et attendre que quelqu’un d’autre fasse sa part, aujourd’hui le contexte est en train de changer. L’équipe qui s’assoit et attend le « blocage du programmeur » quand le designer pourrait prototyper, ou le « blocage du tech artist » quand l’artiste pourrait implémenter, c’est une équipe qui gaspille du temps de façon artificielle.
L’agilité n’est pas une valeur abstraite. C’est la capacité concrète de faire passer une idée du cerveau à un écran fonctionnel dans le moins de temps possible, avec les ressources disponibles. Aujourd’hui, ces ressources ont changé.
Ce qui est difficile à copier
Il y a une question sous-jacente à tout ça : qu’est-ce qu’on ne peut pas automatiser ou cloner ?
La réponse que je me suis donnée : une équipe qui fonctionne vraiment bien ensemble, sur une vision qui vaut vraiment la peine d’être développée, avec suffisamment de compétences qui se recoupent pour ne dépendre d’aucun goulot d’étranglement unique.
Cette combinaison-là, on ne peut pas la copier. Impossible à générer avec un prompt.
Et c’est exactement cette combinaison qui est nécessaire pour faire les jeux qui, dans les prochaines années, auront le plus de chances de s’en sortir. Qu’est-ce que ça veut dire concrètement ? Que les boîtes les plus intelligentes seront capables de garder leurs talents, plutôt que de les traiter comme des bêtes de somme pour ensuite tout licencier une fois le titre sorti.