Algeria AgencyApplication mobile
Une application publiée : ce qu’elle coûte à garder en vie
Le développement a une fin. L’application n’en a pas : elle vieillit toute seule, sur des téléphones que vous ne pouvez plus atteindre.
Un site web qui n’est pas touché pendant deux ans continue de s’afficher. Une application mobile qui n’est pas touchée pendant deux ans cesse de fonctionner, et parfois cesse d’être téléchargeable. Ce n’est pas une différence de qualité, c’est une différence de nature : l’une est servie depuis chez vous, l’autre est installée chez quelqu’un d’autre, sur un système que ni vous ni votre client ne contrôlez.
C’est la ligne du budget que presque personne ne présente au moment du devis, parce qu’elle ne produit rien de visible. Elle ne fait pas de nouvelle fonction, elle ne se démontre pas, et son seul résultat observable est que rien ne casse.
Cet article décrit cette ligne : ce qui vieillit, qui décide du calendrier, ce que coûte une année, et à quel moment il est raisonnable d’arrêter. L’article qui l’accompagne traite de l’adoption — le poids, les permissions, le premier lancement — et rien de cela n’est repris ici.
Il ne contient aucun graphique, et la première section explique pourquoi le chiffre que vous cherchez en arrivant ici ne peut pas exister sous la forme d’une moyenne.
Une application publiée ne vous appartient plus tout à fait
Le jour de la publication, votre logiciel se divise en deux. Il y a la version que vous avez, dans votre dépôt, que vous pouvez corriger cet après-midi. Et il y a les copies installées, qui sont chez des gens, dans l’état où elles étaient au moment du téléchargement, et sur lesquelles vous n’avez aucun pouvoir direct.
Cette seconde moitié est celle qui produit les incidents. Un défaut corrigé chez vous reste actif chez tous ceux qui n’ont pas mis à jour, c’est-à-dire, au début, la quasi-totalité. Un site n’a pas ce problème : la correction est vue par le visiteur suivant, et il n’existe pas de version ancienne encore en circulation.
La conséquence pratique est un renversement de priorité. Sur un site, on corrige puis on prévient. Sur une application, on prévient d’abord, parce que le délai entre la correction et son arrivée chez l’utilisateur se compte en jours et dépend de son téléphone, de sa connexion et de ses réglages.
Retenez cette phrase pour tout ce qui suit : vous ne corrigez jamais une application, vous en publiez une nouvelle et vous attendez. Toutes les décisions de cette page découlent de ce délai et de son incertitude.
Pourquoi il n’y a pas de coût annuel moyen
La question qui amène ici est légitime : combien coûte une application par an ? Il n’y a pas de réponse chiffrée honnête, et la raison n’est pas la même que pour d’autres sujets de ce blog. Ce n’est pas un chiffre que quelqu’un garde, ni un chiffre mal défini : c’est un chiffre qui n’est pas une propriété du marché.
Le coût dépend de trois choses que vous choisissez et d’aucune que nous observons. Le nombre de plateformes, parce que deux systèmes veulent deux calendriers et deux travaux. L’étendue des fonctions, parce que ce qui touche au paiement, à la localisation ou à la caméra vieillit plus vite que ce qui affiche du texte. Et la vitesse à laquelle votre métier change, parce que c’est elle qui décide si vous publiez quatre fois par an ou une fois tous les deux ans.
Un prestataire qui répond par un pourcentage du coût de développement répond à une autre question. Ce pourcentage circule, il est commode, et il suppose que l’entretien est proportionnel à la construction — ce qui est faux dans les deux sens : une application simple sur deux plateformes coûte plus à tenir qu’une application riche sur une seule.
Ce que nous pouvons faire, et ce que la section 8 détaille, c’est décomposer la ligne en postes que vous pouvez estimer vous-même. Une somme que vous avez construite vaut mieux qu’une moyenne que vous ne pouvez pas vérifier, et elle a l’avantage de rester juste quand votre périmètre change.
Les versions dans la nature, et pourquoi elles restent
À tout moment, votre application existe en plusieurs versions simultanées chez vos utilisateurs, et la répartition ne dépend pas de vous. Certains ont la dernière, beaucoup ont celle d’il y a trois mois, et une poignée a la première, qu’ils ont installée le jour de la sortie et jamais mise à jour depuis.
Les raisons sont banales et aucune n’est corrigeable par du code. La mise à jour automatique est parfois désactivée, souvent parce qu’elle consomme des données que la personne paie. Le téléphone n’a plus assez d’espace libre. Le système est trop ancien pour la version récente. Ou l’application n’a pas été ouverte depuis longtemps, et rien ne déclenche la mise à jour.
Ce que cela impose est une discipline plutôt qu’un outil : toute modification de votre côté doit continuer de fonctionner avec les anciennes versions pendant un temps. Le cas qui fait mal est le serveur : changer la forme d’une réponse casse instantanément toutes les copies installées qui attendaient l’ancienne forme, et elles ne se corrigeront pas toutes seules.
La règle simple, qui coûte peu si elle est prise tôt, est de n’enlever jamais un champ et de n’en changer jamais le sens — on en ajoute. Une application est le seul logiciel de votre parc dont les anciens clients ne peuvent pas être mis à jour de force, ce qui fait de la compatibilité ascendante une contrainte réelle plutôt qu’une élégance.
Le calendrier qui n’est pas le vôtre
Les deux magasins d’applications publient des exigences techniques qui évoluent, et ils fixent des dates. Passé une échéance, une application qui ne les respecte pas n’est plus mise à jour, puis n’est plus téléchargeable par de nouveaux utilisateurs. Rien de tout cela ne dépend de ce que vous faites : votre application n’a pas bougé, l’exigence a bougé.
C’est la différence la plus mal comprise entre une application et un site. Personne ne vous retire un site parce qu’il est ancien. Une application, oui, et le préavis est réel mais il tombe dans une boîte mail que quelqu’un doit lire, souvent celle du compte éditeur plutôt que celle du dirigeant.
Il en découle une obligation minimale, indépendante de toute nouvelle fonction : ouvrir le projet au moins une fois par an, le recompiler avec les outils du moment, le tester et le republier. Une application qui ne reçoit rien pendant deux ans n’est pas économe, elle est en sursis.
Cette obligation est aussi la raison pour laquelle un projet d’application ne se termine jamais vraiment. Un devis qui présente un prix de développement sans dire ce qui se passe l’année suivante décrit la moitié du produit, et c’est la moitié la moins chère.
La clé de signature : l’objet le plus dangereux du projet
Chaque application publiée est signée par une clé, et cette clé est l’identité de l’application aux yeux du système. Une mise à jour signée par une autre clé n’est pas une mise à jour : c’est une autre application, que vos utilisateurs devraient installer à côté de la première, en perdant leurs données et leur historique.
La conséquence tient en une phrase : perdre la clé, c’est perdre la continuité de l’application, pas seulement un fichier. Le cas typique n’est pas dramatique en apparence — un prestataire qui change, un ordinateur remplacé, un ancien salarié — et il ne se découvre qu’au moment de la mise à jour suivante, parfois deux ans après la perte.
La clé doit donc vivre dans un endroit qui appartient à l’entreprise, pas au prestataire, et être sauvegardée séparément du dépôt de code. C’est un secret, pas un fichier de projet : il ne se stocke pas à côté des sources, où il finit dans la première copie du dossier que quelqu’un fera.
Vérifiez cela maintenant si vous avez déjà une application, en posant une question précise à qui la maintient : où est la clé de signature, qui y a accès, et où est sa sauvegarde. Une réponse hésitante est un problème à traiter cette semaine, parce que sa gravité n’augmente pas mais son coût de réparation, lui, devient infini le jour où la clé n’existe plus.
Le compte éditeur, et à qui il appartient vraiment
Une application est publiée sous un compte éditeur, et ce compte porte un nom, une adresse et des coordonnées bancaires. Il est le propriétaire de la présence de votre application, au même titre qu’un nom de domaine l’est pour un site.
L’erreur fréquente est de laisser ce compte au nom du prestataire, parce que c’est plus rapide au démarrage et qu’il en possède déjà un. Cela fonctionne parfaitement tant que la relation dure, et cela devient un blocage complet le jour où elle s’arrête : le transfert d’une application d’un compte à un autre est possible mais lourd, et il exige la coopération de la partie dont vous vous séparez.
La règle est la même que pour le nom de domaine, l’hébergement et le compte publicitaire, et elle est aussi ennuyeuse à appliquer : ce qui porte votre nom au public est ouvert par vous, payé par vous, et vous invitez le prestataire dessus. L’inverse est une facilité de démarrage dont vous payez le prix à la fin.
Le même raisonnement vaut pour les autres accès que le projet accumule : le service qui envoie les notifications, l’outil qui reçoit les rapports de plantage, le stockage des fichiers. Faites-en la liste une fois, avec pour chacun le compte propriétaire — c’est une heure de travail qui vaut son prix le jour d’un changement de prestataire.
Ce qui casse sans que personne y touche
Le classement utile des pannes d’une application n’est pas technique, il est causal, parce qu’il désigne qui doit agir. Trois catégories suffisent, et deux d’entre elles ne viennent pas de vous.
La première est le système qui change. Une nouvelle version du téléphone modifie une règle — l’accès à un dossier, le comportement en arrière-plan, l’affichage sous une encoche — et une application écrite avant cesse de se comporter comme prévu. Elle n’a pas bougé ; le sol a bougé.
La deuxième est le service tiers qui change. Une passerelle de paiement, une carte, un fournisseur d’envoi de messages modifie son interface ou retire une version ancienne. C’est la panne la plus brutale parce qu’elle est instantanée, totale, et souvent annoncée dans une documentation que personne de votre côté ne suit.
La troisième seulement est votre propre modification, et c’est la moins fréquente une fois l’application stabilisée. Cette proportion est ce qui rend l’entretien contre-intuitif : la majorité du travail annuel répond à des événements extérieurs, ce qui explique qu’une application à laquelle « on ne touche pas » consomme quand même du budget.
Trier les plantages : trois questions, dans l’ordre
Un outil de rapport de plantage produit une liste longue et démoralisante, et la lire de haut en bas est le meilleur moyen de passer une semaine sur un défaut qui touche deux personnes. Trois questions, posées dans cet ordre, remettent la liste à l’endroit.
Combien d’utilisateurs distincts, et non combien d’occurrences ? Un plantage qui se répète cent fois chez la même personne est un cas particulier ; le même qui touche cent personnes une fois est une priorité. Les deux apparaissent avec le même total dans la plupart des outils.
À quel endroit du parcours ? Un plantage au démarrage ou au paiement vaut vingt plantages sur un écran secondaire, parce qu’il n’a pas de contournement : la personne ne peut rien faire d’autre, et elle désinstalle. Un plantage sur un écran qu’on peut quitter coûte de l’agacement, pas un client.
Et sur quelles versions ? Un défaut qui n’existe que sur des copies anciennes est déjà corrigé — la question devient la diffusion de la mise à jour, qui est le sujet de la section 9, et non une nouvelle correction. Le trier autrement fait réparer deux fois la même chose.
Le support d’une version que vous ne pouvez plus corriger
Vous recevrez des messages d’utilisateurs décrivant un problème que vous avez réglé il y a deux mois. Ils n’ont pas tort, et leur dire « c’est corrigé » est une réponse fausse de leur point de vue, puisque chez eux, ce n’est pas corrigé.
La réponse utile tient en deux temps : dire que la correction existe, puis expliquer précisément comment l’obtenir, avec les gestes réels du téléphone plutôt que le mot « mettez à jour ». La moitié des gens à qui l’on dit de mettre à jour ne savent pas où se trouve le bouton, et l’autre moitié pense l’avoir déjà fait.
Il faut aussi savoir quelle version la personne utilise, ce qui suppose de l’afficher quelque part dans l’application, sur un écran que le support peut faire ouvrir en une phrase. Sans cela, chaque conversation commence par une enquête de dix minutes, répétée à chaque appel.
Enfin, ce flux de messages est une mesure gratuite de la diffusion de vos versions, et la seule que vous obtiendrez sans instrumentation. Si les plaintes portant sur un défaut ancien continuent trois mois après sa correction, votre problème n’est pas ce défaut, c’est que vos mises à jour n’arrivent pas.
Ce que coûte une année, honnêtement décomposé
Faute de moyenne utilisable, voici la décomposition qui permet d’estimer soi-même. Elle a quatre postes et chacun se chiffre séparément, ce qui rend la somme discutable ligne par ligne plutôt qu’en bloc.
Le poste obligatoire est la remise à niveau annuelle : recompiler avec les outils du moment, corriger ce que les nouvelles exigences imposent, tester sur des appareils récents, republier. Il existe même si vous ne demandez rien, et il est le seul qui ne se négocie pas.
Le deuxième est la réaction aux pannes extérieures décrites en section 6, qui est imprévisible en date et assez prévisible en volume : un service tiers qui compte dans votre application finira par changer. Le troisième est le support, qui dépend du nombre d’utilisateurs et non de la complexité. Le quatrième, seul optionnel, est l’évolution : les fonctions que vous décidez d’ajouter.
Présenter ces quatre lignes séparément change la conversation, et c’est la raison d’être de cette section. Un client peut choisir de ne rien faire évoluer pendant un an ; il ne peut pas choisir de ne pas faire la première ligne, et un devis qui les mélange laisse croire le contraire.
Forcer la mise à jour : le seul levier, et son prix
Il existe un moyen de reprendre la main sur les copies installées : faire vérifier par l’application, au démarrage, qu’elle n’est pas trop ancienne, et bloquer l’usage tant que la mise à jour n’est pas faite. C’est le seul levier réel, et il est brutal.
Son coût est direct et immédiat. Vous arrêtez une personne qui voulait se servir de votre application, dans un moment que vous n’avez pas choisi, et vous lui demandez un téléchargement qui consomme des données qu’elle paie, sur une connexion qui n’est peut-être pas bonne. Une partie n’ira pas au bout, et une partie de ceux-là ne reviendra pas.
Il se justifie donc dans deux cas seulement, et il est bon de les écrire à l’avance plutôt que de décider dans l’urgence : quand l’ancienne version est devenue dangereuse — une faille, une fuite de données — et quand elle est devenue fausse, par exemple en affichant des prix ou des conditions qui n’existent plus.
Pour tout le reste, l’invitation vaut mieux que le blocage : un bandeau qui propose la mise à jour, répété, et qui laisse continuer. La différence entre les deux est celle entre une application qui vous protège et une application qui vous punit, et vos utilisateurs la ressentent exactement ainsi.
Ce que nous faisons, et ce que nous refusons
Notre part est l’entretien lui-même : la remise à niveau annuelle avant l’échéance plutôt qu’après, la compatibilité ascendante côté serveur, le tri des plantages selon les trois questions de la section 7, l’écran qui affiche la version pour le support, et l’inventaire des comptes et de la clé de signature. Ce sont des obligations récurrentes, pas un projet, et nous les présentons comme telles dans un devis.
Nous refusons d’annoncer un coût annuel en pourcentage du développement. Ce n’est pas de la prudence commerciale : le chiffre existe dans la profession, il est facile à prononcer, et il suppose une proportionnalité qui n’existe pas. Nous chiffrons les quatre lignes de la section 8, séparément, et vous pouvez en refuser une.
Nous refusons aussi de conserver votre clé de signature et vos comptes éditeur à notre nom, y compris quand c’est vous qui le proposez pour aller plus vite. C’est la commodité qui coûte le plus cher au moment d’un changement de prestataire, et un fournisseur qui l’accepte se rend difficile à quitter — ce qui n’est pas une qualité que nous voulons avoir.
Enfin, une partie de cette page ne demande aucun développement et vaut d’être faite cette semaine, sans nous : demander où se trouve votre clé de signature et sa sauvegarde, vérifier au nom de qui est le compte éditeur, et afficher le numéro de version quelque part dans l’application. Les trois prennent une journée et retirent les trois blocages les plus chers de cette page.
Questions fréquentes
Faut-il vraiment republier une application si on ne change rien ?
Oui, au moins une fois par an. Les magasins font évoluer leurs exigences techniques et fixent des dates : passé l’échéance, une application non conforme ne peut plus être mise à jour, puis n’est plus téléchargeable par de nouveaux utilisateurs. Votre application n’a pas bougé, l’exigence a bougé. C’est le seul poste d’entretien qui ne se négocie pas.
Que se passe-t-il si on perd la clé de signature ?
Vous perdez la continuité de l’application, pas seulement un fichier. Une mise à jour signée par une autre clé est traitée comme une application différente : vos utilisateurs devraient l’installer à côté de l’ancienne et perdraient leurs données. La clé doit vivre chez vous, sauvegardée séparément du dépôt de code, et sa perte ne se découvre généralement qu’à la mise à jour suivante.
Pourquoi des utilisateurs signalent-ils un bug déjà corrigé ?
Parce que la correction est chez vous et pas chez eux. Vos copies installées existent en plusieurs versions simultanées, et beaucoup restent anciennes : mise à jour automatique désactivée pour économiser des données, mémoire pleine, système trop ancien, ou application pas ouverte depuis longtemps. Répondez en expliquant les gestes concrets pour mettre à jour, jamais par « c’est déjà corrigé ».
Le compte éditeur peut-il rester au nom du prestataire ?
Il peut, et c’est la facilité de démarrage la plus coûteuse à la fin. Le compte porte la présence publique de votre application comme un nom de domaine porte celle d’un site. Le transfert vers un autre compte est possible mais lourd et exige la coopération de la partie dont vous vous séparez. Ouvrez-le vous-même et invitez le prestataire dessus.
Faut-il forcer la mise à jour ?
Dans deux cas seulement : quand l’ancienne version est devenue dangereuse — une faille, une fuite — ou fausse, par exemple en affichant des prix qui n’existent plus. Le blocage arrête quelqu’un qui voulait se servir de votre application et lui impose un téléchargement qu’il paie en données ; une partie n’ira pas au bout. Partout ailleurs, un bandeau répété qui laisse continuer vaut mieux.
Combien coûte la maintenance d’une application par an ?
Il n’y a pas de moyenne honnête, parce que ce n’est pas une propriété du marché mais une fonction de vos propres choix : le nombre de plateformes, l’étendue des fonctions sensibles, et la vitesse à laquelle votre métier change. Un pourcentage du coût de développement suppose une proportionnalité qui n’existe pas. Chiffrez plutôt quatre lignes séparées : remise à niveau annuelle, réaction aux pannes extérieures, support, évolutions.
Où nous intervenons
Trois questions à qui maintient votre application — où est la clé de signature, où sont les comptes éditeur, qui reçoit les avis de dépréciation — décident de sa survie.
- Nous faisons la remise à niveau avant l’échéance annoncée, pas après le retrait.
- Nous laissons la clé de signature et les comptes éditeur à votre nom.
- Nous affichons le numéro de version sur un écran que votre support sait faire ouvrir.
Nous ne réduirons pas l’entretien à un pourcentage du budget initial : ce chiffre circule, il rassure, et il ne correspond à rien de mesurable.
À lire ensuite
Application mobile : son poids et ses demandes décident plus que ses fonctions
Ce qui fait abandonner une application se joue avant la première fonction : le téléchargement, l’inscription, les permissions.Développement logiciel : le cahier des charges que vous écrivez n’est pas celui dont vous avez besoin
Personne ne sait ce qu’il veut avant de l’avoir utilisé. Un cahier des charges complet écrit avant est un pari rédigé au présent.Le POC qui ne partira jamais : les signes, dès la semaine deux
Un pilote qui échoue le fait rarement à la fin. Il le fait la deuxième semaine, en silence, et tout le monde continue trois mois.
Parlons de votre projet
Un audit gratuit, sans engagement : nous regardons votre présence en ligne et nous vous disons ce qui coince.