Plusieurs apps, un seul développeur : le vrai prix

Quand j'ai publié ma première app, je pensais que le plus dur était derrière moi. Écrire le code, passer la review d'Apple, voir l'icône apparaître sur l'App Store : c'était l'objectif, et il était atteint.

Puis il y a eu une deuxième app. Puis une troisième. Et j'ai compris que publier n'était pas la ligne d'arrivée. C'était le début d'un engagement.

Ce que personne ne compte

Une app publiée ne reste pas immobile. Autour d'elle, tout bouge.

Apple sort une nouvelle version d'iOS, et il faut vérifier que rien ne casse.
Une règle de review change, et une mise à jour qui serait passée hier est refusée aujourd'hui.
Un utilisateur signale un bug, et il mérite une réponse.
Une app passe sur Android, comme Laby Kids récemment, et chaque correction existe désormais en deux exemplaires.

Pris un par un, aucun de ces sujets n'est énorme. Le problème, c'est qu'ils se multiplient par le nombre d'apps. Et qu'en face, il n'y a qu'une seule personne.

Une seule personne, tous les rôles

Dans une équipe, ces tâches se répartissent. Quelqu'un code, quelqu'un teste, quelqu'un s'occupe des fiches App Store, quelqu'un répond au support.

Seul, je fais tout. Développeur, testeur, rédacteur des descriptions, graphiste des captures d'écran, support client, juriste du dimanche pour les mentions légales et les politiques de confidentialité.

Et je le fais sur le temps qui reste : le soir après le travail, et le week-end. Ce temps-là ne s'étire pas. Chaque heure passée à maintenir une app existante est une heure qui ne va pas à la suivante.

Ce que ça m'a appris

Cette contrainte m'a obligé à changer ma façon de construire.

Faire petit. Une app qui fait une chose bien coûte moins cher à maintenir qu'une app qui essaie de tout faire. Chaque fonctionnalité ajoutée est une fonctionnalité à faire vivre pendant des années.

Rester simple techniquement. Moins de dépendances, moins de surprises lors d'une mise à jour. Le code natif, sans couche intermédiaire, vieillit mieux.

Accepter de ne pas tout faire tout de suite. Toutes les idées de fonctionnalités ne méritent pas d'être construites. Beaucoup restent dans une note, et c'est très bien comme ça.

Écrire pour le moi de dans six mois. Quand je reviens sur une app après des semaines sur une autre, je ne me souviens de rien. Un code lisible et quelques notes claires me font gagner des soirées entières.

Alors pourquoi continuer ?

Parce que malgré tout ça, il y a quelque chose que je ne retrouve nulle part ailleurs.

Une idée naît un soir, souvent d'un problème très concret. Un jeu pour aider ma fille à apprendre ses tables. Un outil pour vérifier une app avant de la soumettre. Quelques semaines plus tard, cette idée existe. Elle tourne sur un téléphone. N'importe qui, n'importe où, peut la télécharger.

Il y a quelques années, ces idées seraient restées dans un coin de ma tête, comme je le racontais dans Forget you have no chance - go for it anyway. Aujourd'hui, elles sont sur l'App Store, à disposition de tout le monde.

Ce passage de l'idée à quelque chose de réel, que d'autres utilisent, c'est ce qui rend les soirées de maintenance supportables. Savoir qu'un enfant que je ne connais pas joue peut-être à Laby Kids en ce moment, ça compense largement une mise à jour iOS pénible.

Le bon équilibre

Je ne vais pas prétendre que la gestion est simple. Elle ne l'est pas, et elle le sera de moins en moins à mesure que les apps s'accumulent. Il faudra peut-être un jour choisir, et laisser une app de côté pour garder du temps pour les autres.

Mais la question n'est pas de savoir si c'est compliqué. La question est de savoir si ça en vaut la peine.

Pour moi, la réponse est oui. Donner vie à ses idées et pouvoir les partager avec tout le monde, c'est une chance. La maintenance est le prix à payer, et je le paie volontiers.