Le devis disait dix-huit lakhs de roupies — environ 20 000 dollars — et quatre mois. Personne n'a menti. L'app est sortie, elle fonctionnait, tout le monde était content.
Ce que le devis ne disait pas : la même app coûte de l'argent chaque année ensuite, qu'on ajoute une seule fonctionnalité ou aucune — et que cette somme, sur la durée de vie normale d'une app, dépasse ce que vous avez payé pour la construire.
Les coûts qui arrivent, que vous fassiez quelque chose ou non
C'est la catégorie qui surprend, parce qu'elle n'est pas optionnelle et ne produit rien qu'un utilisateur remarquerait.
Les versions d'OS, deux fois par an, pour toujours. iOS et Android sortent chacun une version majeure par an, et chacune change quelque chose. Un modèle de permissions se durcit, une API est dépréciée, une règle d'exécution en arrière-plan change, une convention d'interface évolue. Votre app doit être testée contre chaque version et généralement ajustée. Sautez un cycle et vous accumulez une dette qui finit par imposer un projet plus gros.
Les règles des stores. Les deux stores relèvent périodiquement leurs exigences minimales — versions SDK cibles, déclarations de confidentialité, divulgations de données. Ratez une échéance et votre app n'accepte plus de mises à jour, puis finit par être retirée. C'est non négociable, et ça arrive selon le calendrier de quelqu'un d'autre.
L'usure des dépendances. Chaque bibliothèque de votre build a son propre cycle de versions et ses propres alertes de sécurité. Une version majeure de framework peut se transformer en quinze jours de démêlage — et plus vous reportez, pire c'est : l'écart entre votre version et l'actuelle ne fait que grandir.
Certificats et comptes. Frais de programme développeur, certificats de signature, identifiants de notifications push. Chacun expire, et chaque expiration casse quelque chose bruyamment si personne ne surveillait.
Rien de tout cela ne livre une fonctionnalité. Tout cela est obligatoire pour rester dans les stores.
Fig. — Seule la dernière bande est optionnelle. Le reste arrive selon le calendrier de quelqu'un d'autre.
Les coûts de fonctionnement
L'infrastructure backend est le poste évident — généralement modeste à faible usage, non linéaire à l'échelle. L'erreur est de budgéter à partir des chiffres de la semaine de lancement plutôt que de la charge que vous espérez.
Les services tiers s'accumulent en silence. Notifications push, analytics, rapport de crashs, cartes, envoi de SMS ou d'e-mails, authentification, hébergement d'images. Chacun est bon marché seul. Ensemble, ils forment une ligne mensuelle que la plupart des équipes ne savent pas détailler de mémoire — et elle grandit avec l'usage au lieu de rester plate.
Le monitoring est le poste que les équipes suppriment puis regrettent. Le rapport de crashs et la surveillance de performance coûtent quelque chose ; ne pas les avoir signifie apprendre l'existence d'un crash par un avis une étoile, une semaine après son début.
Le travail que personne ne chiffre
Le tri des crashs. Même une app bien construite produit des crashs sur des combinaisons appareil-OS que personne n'a testées. Quelqu'un doit les regarder chaque semaine, décider lesquels comptent, et corriger ceux-là. Ignorez-le et votre note sur les stores s'érode, d'une façon coûteuse à inverser.
Les escalades de support. Pas le support de premier niveau — celles qui atteignent un ingénieur parce que la réponse exige de lire des logs. Volume faible, coût d'interruption élevé.
Les rejets de validation. Même des mises à jour de routine sont parfois rejetées, occasionnellement pour des raisons qui demandent une vraie conversation avec un examinateur. Imprévisible et inévitable.
Les correctifs de sécurité. Une vulnérabilité divulguée dans une bibliothèque dont vous dépendez n'est pas du travail planifié. C'est du travail que vous faites cette semaine-là.
Qui fait le travail compte plus que ce qu'il coûte
La question du coût arrive généralement avant la question plus difficile : qui va faire ça ?
L'agence qui a construit l'app est la réponse par défaut, et l'arrangement fonctionne si les termes sont convenus dès le départ. Ce qui crée des ennuis, c'est le vide : le projet se termine, le contrat de maintenance n'a jamais été signé, et six mois plus tard une version d'OS casse quelque chose. Vous voilà en train de négocier une intervention d'urgence avec une équipe passée à d'autres clients, au tarif que l'urgence justifie.
Recruter en interne a du sens à partir d'une certaine taille — et cette taille est plus grande que la plupart des fondateurs l'imaginent. Un développeur mobile seul qui entretient une seule app coûte cher par unité de travail et reste fragile : quand il part, personne d'autre ne peut livrer une version, et vous découvrez que le certificat de signature était sur sa machine.
Le juste milieu pragmatique, pour la plupart des petits produits, est un contrat récurrent modeste avec l'équipe qui a construit — dimensionné pour le travail prévisible : versions d'OS, échéances des stores, mises à jour de dépendances, tri des crashs — les nouvelles fonctionnalités étant chiffrées à part. Cela transforme un coût d'urgence imprévisible en un coût mensuel ennuyeux, et c'est exactement le but.
Quel que soit votre choix, assurez-vous que les comptes vous appartiennent. L'adhésion au programme développeur, les certificats de signature, l'infrastructure backend, les comptes des services tiers. Les équipes qui sautent cette étape découvrent, lors d'une passation, que leur app appartient juridiquement au compte d'un ancien prestataire — et cette conversation-là coûte cher.
Budgéter honnêtement
L'heuristique courante du secteur : quinze à vingt pour cent du coût de construction initial par an, pour la seule maintenance, avant toute nouvelle fonctionnalité. Le chiffre varie avec la complexité, mais c'est une hypothèse de planification bien meilleure que le zéro qu'utilisent implicitement la plupart des premiers budgets.
Plus utile encore : partez sur une durée de vie de trois à cinq ans, et attendez-vous à un coût total de possession proche du double du coût de construction. Si cela change la pertinence du projet, mieux vaut le savoir avant de commencer qu'en deuxième année.
Et budgétez la réécriture. Toute app atteint le point où l'accumulation de changements d'OS, de dérive des dépendances et de dette de conception rend le travail incrémental plus lent qu'un redémarrage. Typiquement au bout de quatre à six ans. Ce n'est pas un échec d'ingénierie ; c'est le cycle de vie normal, et prétendre le contraire signifie seulement que la réécriture arrivera en urgence plutôt qu'en plan.
Ce qui réduit vraiment la facture
Moins de dépendances. Chaque bibliothèque est une obligation de maintenance permanente en échange d'une économie temporaire. Importer un paquet pour éviter d'écrire quarante lignes est généralement un mauvais échange sur cinq ans.
Des tests automatisés autour des parties qui cassent en silence — paiements, authentification, synchronisation, tout ce qui touche à l'argent ou à l'état. Vous ne testez pas tant la justesse que la mise à jour d'OS qui change le comportement en dessous.
Une vraie chaîne CI. Si livrer un correctif exige une personne précise avec un portable configuré d'une façon précise, votre temps de réaction à un problème urgent se mesure à la disponibilité de cette personne.
Et moins de fonctionnalités. Celle-là, personne ne veut l'entendre. Chaque écran livré est un écran à tester contre chaque version d'OS tant que l'app existe. La fonctionnalité la moins chère à entretenir est celle que vous avez décidé de ne pas construire — la deuxième moins chère, celle que vous avez retirée quand les analytics ont montré que personne ne l'utilisait.
Posséder une app à bas coût commence avant la première ligne — c'est ainsi que nous cadrons les projets, et notre calculateur de coûts montre les chiffres derrière.
