The Dead Masked Company, c'est en ce moment quatre projets actifs : A Matter of Choice, Cendrelune, AbcDonjon et Price Comparator. Quatre codebases, quatre comptes développeur sur les stores, quatre séries de retours utilisateurs à traiter. Le tout en solo, en parallèle d'une activité principale.
Gérer plusieurs projets en développement solo est une compétence distincte du développement lui-même. Voici ce que j'ai appris — parfois à la dure.
L'illusion du multitâche
La tentation naturelle du développeur solo avec plusieurs projets est de passer de l'un à l'autre selon l'humeur. Un bug sur Cendrelune le matin, une feature sur AbcDonjon l'après-midi, une mise à jour de la page web le soir. C'est séduisant — on a l'impression de tout faire avancer.
En réalité, chaque changement de contexte coûte cher. Reprendre un projet après quelques heures d'absence, c'est re-charger en mémoire : l'état du code, les décisions en cours, le prochain objectif. Ce coût de rechargement peut représenter 20 à 30 minutes de productivité perdues à chaque transition.
« Le multi-projet ne tue pas la productivité. Ce qui la tue, c'est de changer de projet plusieurs fois par jour sans discipline. »
La règle des blocs hebdomadaires
La solution que j'ai adoptée : attribuer à chaque projet un bloc hebdomadaire dédié. Un projet principal par semaine, avec des créneaux fixes pour la maintenance des autres. Concrètement : lundi et mardi sur le projet prioritaire du mois, mercredi sur les corrections urgentes de maintenance, jeudi-vendredi sur un second projet actif.
Cette cadence n'est pas rigide — une deadline store, un bug critique ou un retour utilisateur urgent peuvent tout bouleverser. Mais avoir une structure par défaut évite la paralysie de la page blanche : le matin, je sais sur quoi je travaille.
Un projet prioritaire par trimestre
Tous les projets ne peuvent pas être prioritaires en même temps. J'ai adopté une règle simple : un seul projet reçoit 70 % de mon attention créative par trimestre. Les autres sont en maintenance mode — correctifs uniquement, pas de nouvelles features.
Cette règle force à terminer. L'ennemi numéro un du développeur solo n'est pas le manque de temps — c'est le syndrome du « presque fini » sur dix projets simultanément. Concentrer l'énergie créative sur un seul projet à la fois permet de sortir des versions entières plutôt que d'accumuler des travaux à 80 %.
La documentation comme mémoire externe
Quand on revient sur un projet après trois semaines d'absence, la mémoire fait défaut. Qu'est-ce qui était en cours ? Quelle décision avais-je prise sur ce bug ? Pourquoi cette architecture ?
La solution : traiter le README et les commentaires de commit comme une mémoire externe. Chaque session de travail se termine par un message de commit descriptif — pas « fix bug » mais « corrige le calcul du gain hors-ligne quand le tick dépasse 24h ». Chaque décision technique non triviale mérite une note dans le README.
La maintenance : le travail invisible
Chaque application sur les stores génère un flux continu de travail invisible : mises à jour des SDKs, compatibilité avec les nouvelles versions iOS/Android, corrections de bugs remontés par les utilisateurs, réponses aux avis. Ce travail ne produit pas de nouvelles features — mais le négliger dégrade lentement la qualité perçue.
J'estime ce travail de maintenance à environ 20 % du temps total pour quatre projets actifs. C'est du temps à budgéter explicitement dans la planification hebdomadaire — pas à traiter comme un « bonus » si le reste avance bien.
Savoir quand abandonner
Tous les projets ne méritent pas d'exister indéfiniment. Un projet qui ne trouve pas son public après un an de présence sur les stores, malgré des itérations honnêtes, consomme du temps qui pourrait aller ailleurs. La décision d'archiver un projet est difficile — mais c'est parfois la bonne décision stratégique.
Je n'en suis pas encore là avec les projets actuels. Mais je garde cette option ouverte — parce que la liberté de l'indie dev, c'est aussi ça : choisir sur quoi dépenser son énergie.