Ce que ça coûte vraiment de shipper en solo

7Sail est un studio solo. Plusieurs titres publiés, un site, un blog, une routine de production qui tourne. Et sur le dernier jeu publié, un roguelite, les compteurs de la plateforme sont restés plats.

Je pose ces chiffres d'entrée parce que tout le reste de l'article en dépend. Pas pour m'en plaindre : des lancements invisibles, l'industrie en produit des milliers par an, le mien n'a rien d'exceptionnel. Mais on ne peut pas parler du coût réel de shipper en solo en laissant croire que ça se passe bien. Ça ne se passe ni bien ni mal : ça se passe comme pour presque tout le monde, c'est-à-dire dans le silence. Le sujet, c'est ce qu'on fait de ce silence.

L'intuition dit qu'un studio qui ne vend rien ne dépense rien. C'est faux. Les outils s'empilent, et presque tous sont des abonnements : la génération d'assets qui remplace le pixel artist que je ne suis pas, l'hébergement du site et du blog, l'écosystème autour du moteur. Aucun poste n'est déraisonnable pris isolément ; chacun a été choisi, comparé, justifié. Mais la somme est récurrente, et elle tombe tous les mois face à une colonne recettes qui, elle, ne bouge pas.

Ce n'est pas un problème de montant, c'est un problème de structure : les charges d'un studio solo sont des flux, ses recettes sont des événements. Tant qu'aucun événement n'arrive, le flux continue. Un studio qui ne compte pas ça ne sait littéralement pas ce que chaque jeu lui coûte.

Le poste le plus lourd n'apparaît sur aucun relevé : c'est le temps. Chaque semaine passée à polir un titre que presque personne n'a téléchargé est une semaine que je ne passe pas sur le flagship du studio, une application plus ambitieuse, aujourd'hui en pause faute de testeurs. L'arbitrage existe que je le regarde ou non ; le regarder est la seule différence entre arbitrer et subir.

Ma réponse est une règle bête : WIP=2. Deux projets en phase de finition maximum, en même temps, et pas un de plus. Ce n'est pas de la méthode pour la méthode, c'est un plafond de dette d'attention. Quand un troisième projet me démange, la règle m'oblige à nommer celui qui sort. Ça fait mal exactement là où il faut.

Face à des compteurs plats, deux réflexes se présentent, et ils sont symétriques. Tout arrêter : le marché a parlé, inutile d'insister. Ou foncer tête baissée : la persévérance finit toujours par payer, il suffit d'y croire plus fort.

Les deux sont confortables parce que les deux dispensent de la même chose : mesurer. Arrêter sans mesurer, c'est jeter le travail sans savoir ce qu'il valait. Continuer sans mesurer, c'est transformer un projet en loterie où l'on rachète un ticket chaque semaine. La question qui dérange, celle que les deux extrêmes esquivent, tient en deux morceaux : qu'est-ce que je mesure exactement, et à quelle date est-ce que je décide ?

Ma réponse tient dans des bornes écrites avant l'émotion. Le plan de release du roguelite tient sur une page et contient trois choses qu'aucun de mes anciens plans n'avait. Un budget exprimé en sessions de travail, pas en features : quand les sessions sont consommées, le plan s'arrête. Une fin explicite, écrite noir sur blanc : au lancement, le créneau libéré revient au flagship. Et un seuil de traction fixé avant de voir les chiffres, jamais ajusté après coup pour valider ce que j'avais de toute façon envie de faire.

Une règle de studio complète le dispositif, la règle du juge : un projet n'est fini que lorsqu'un externe non-complice a donné quelque chose en échange. De l'argent, du temps, un retour argumenté. Tant que ce n'est pas arrivé, le projet n'est pas fini, il est juste arrêté.

Des compteurs plats, ce n'est pas le bilan d'un échec. C'est une mesure, et une mesure ne devient un échec que si l'on refuse de la lire. La lucidité économique n'est pas un vernis de gestionnaire plaqué sur le métier : c'est une compétence de studio au même rang que le code, et elle s'apprend de la même façon. En pratiquant sur ses vrais résultats. Même modestes. Surtout modestes.