Maintenir une application mobile : le budget qu'on oublie toujours

Le devis couvre la construction. La mise en production se passe bien. Six mois plus tard, tout le monde a oublié le projet — jusqu’au jour où l’application ne se lance plus sur les téléphones neufs, ou refuse d’accepter une mise à jour.

Ce moment arrive systématiquement. Voici ce qui le provoque et ce que coûte de l’éviter.

Pourquoi le mobile est différent du web

Une application web déployée sur un serveur qu’on ne touche pas continue de fonctionner indéfiniment. Elle vieillit, elle accumule des failles, mais elle tourne.

Une application mobile, non. Elle s’exécute sur un appareil dont le système est mis à jour sans qu’on ait son mot à dire, et elle est distribuée par un magasin dont les règles changent.

Trois choses évoluent en permanence sous vos pieds :

Le système d’exploitation. iOS et Android publient chacun une version majeure par an, adoptée très vite du côté d’Apple — la majorité du parc bascule en quelques mois. Chaque version modifie des comportements : une autorisation devient plus stricte, une interface système change de hauteur, une pratique tolérée cesse de l’être.

Les règles des magasins. Elles évoluent avec des échéances fermes. Une version minimale d’outillage à respecter, une nouvelle déclaration obligatoire sur les données, un format de publication imposé. Passé l’échéance, on ne peut plus publier de mise à jour — ce qui signifie qu’on ne peut plus corriger le moindre bug.

Les dépendances. Les bibliothèques utilisées évoluent, certaines sont abandonnées. Une bibliothèque non maintenue finit par ne plus se compiler avec l’outillage exigé.

Aucun de ces trois points ne dépend de vous. C’est ce qui rend ce budget subi plutôt que choisi — et c’est exactement pour cela qu’il doit être provisionné.

Ce que contient l’entretien minimal

Voici ce que je considère comme le plancher, en dessous duquel l’application se dégrade.

Une campagne de test à chaque version majeure de système, deux fois par an. Installer les préversions dès l’été, faire tourner l’application, relever ce qui a changé. La détection précoce évite le scénario le plus désagréable : découvrir un dysfonctionnement le jour de la sortie publique, quand des milliers d’utilisateurs basculent en même temps.

Une montée de version des dépendances par semestre. Pas parce que c’est vertueux, mais parce que l’écart se paye. Six montées mineures étalées sur trois ans se passent sans incident ; une montée de trois ans d’un coup est un chantier à part entière, avec des changements d’interface en cascade.

Une surveillance des rapports de plantage. Les magasins fournissent gratuitement le taux de plantage par version et par modèle d’appareil. Le regarder une fois par mois prend dix minutes et évite de découvrir par un commentaire public qu’une catégorie de téléphones ne peut plus ouvrir l’application.

Une veille sur les échéances des magasins. Les annonces sont publiées longtemps à l’avance, avec des dates. Quelqu’un doit les lire, sinon l’échéance devient une urgence.

L’ordre de grandeur

Pour une application métier de taille moyenne, en multiplateforme, je provisionne quinze à vingt-cinq jours par an, hors nouvelles fonctionnalités.

Cette fourchette se décompose à peu près ainsi : la moitié pour les deux campagnes de test système et les corrections associées, un quart pour les montées de dépendances, le reste pour les mises en conformité des magasins et le suivi des plantages.

En natif sur deux plateformes, cette charge est à peu près doublée : chaque test, chaque correction, chaque montée se fait deux fois. C’est l’argument le plus solide en faveur du multiplateforme sur une application métier, et il ne porte pas sur le coût de construction mais sur celui de possession.

Ces chiffres sont des ordres de grandeur issus de projets que nous suivons ; ils varient fortement selon le nombre d’intégrations et la richesse de l’interface. Ce qui ne varie pas, c’est que ce budget n’est jamais nul.

Photo : The World is a Stage — licence CC0.

Ce qui se passe quand on ne le fait pas

La dégradation n’est pas progressive, et c’est ce qui la rend piégeuse.

Année 1 : rien de visible. L’application fonctionne, personne ne se pose de question.

Année 2 : quelques comportements étranges sur les appareils récents. Un écran mal aligné, une autorisation qui ne se demande plus au bon moment. Des plaintes isolées, qu’on classe.

Année 3 : une échéance de magasin arrive. Pour republier, il faut monter l’outillage. Monter l’outillage impose de monter les dépendances, dont deux ne sont plus maintenues. Le projet ne compile plus.

À ce stade, la remise à niveau représente couramment plusieurs semaines de travail — soit davantage que les trois années d’entretien qu’on a évitées. Et pendant cette remise à niveau, aucune correction ne peut être publiée, y compris urgente.

C’est le scénario que je vois le plus souvent quand on nous demande de reprendre une application existante. Il n’est jamais dû à de la négligence : simplement, personne n’avait inscrit cette ligne au budget.

Comment le rendre prévisible

Trois pratiques transforment ce coût subi en coût planifié.

Inscrire deux créneaux fixes dans l’année. Un en septembre pour la version d’iOS, un au printemps pour Android. Ces créneaux existent dans le calendrier, qu’il y ait ou non quelque chose à corriger. Un créneau planifié coûte deux fois moins cher qu’une urgence.

Automatiser la compilation et les tests. Une chaîne qui compile l’application à chaque modification et signale immédiatement une dépendance cassée fait gagner un temps considérable. C’est aussi ce qui permet de produire une version de test en quelques minutes plutôt qu’en une demi-journée.

Documenter la chaîne de publication. Où sont les comptes, qui détient la clé de signature, quelles sont les étapes exactes. Cette page évite qu’un départ ne bloque toute publication — la situation la plus coûteuse et la plus évitable de toutes.

Photo : Flat Lay Photos — licence CC0.

Ce qu’il faut sauvegarder ailleurs que sur un poste

Une application mobile dépend de secrets qui ne sont pas dans le code, et dont la perte a des conséquences très différentes selon l’élément.

La clé de signature Android est la plus critique. Elle prouve que la mise à jour vient du même éditeur. La perdre signifie ne plus jamais pouvoir mettre à jour l’application publiée : il faudrait créer une nouvelle fiche et demander à tous les utilisateurs de réinstaller.

Les certificats et profils Apple expirent chaque année et se régénèrent, ce qui les rend moins dramatiques — à condition d’avoir accès au compte qui les porte.

Les accès aux comptes développeur eux-mêmes, avec l’authentification à deux facteurs associée. C’est le point de blocage le plus fréquent : le second facteur est rattaché au téléphone d’une personne qui a quitté l’entreprise.

Ces trois éléments doivent vivre dans le coffre de l’entreprise, avec au moins deux personnes capables d’y accéder. C’est une précaution de dix minutes qui évite des situations sans solution propre.

Le signal qui indique qu’il faut agir

Il en existe un, simple et fiable : le temps qu’il faut pour publier une correction d’un caractère.

Sur une application entretenue, il se compte en heures — on modifie, la chaîne compile, on soumet. Sur une application laissée de côté, la même correction demande d’abord de remettre l’environnement de compilation en état, ce qui prend des jours.

Je recommande de mesurer ce délai une fois par an, en publiant une correction mineure réelle. C’est un exercice peu coûteux qui révèle immédiatement l’état de santé du projet, bien avant que l’échéance d’un magasin ne le fasse à votre place.

Ce que je recommande d’inscrire au contrat

Sur toute application mobile, je pousse pour que la maintenance figure dès le contrat initial, avec un contenu explicite plutôt qu’un forfait vague.

Le minimum utile tient en quatre lignes : les deux campagnes annuelles de compatibilité système, la mise en conformité avec les exigences des magasins, la surveillance mensuelle des plantages, et un volume de jours réservé pour les corrections.

Ce qui doit être exclu et dit clairement : les nouvelles fonctionnalités, qui relèvent d’un autre budget et d’une autre discussion.

Cette distinction paraît administrative. Elle est en réalité ce qui protège l’application : sans elle, le budget de maintenance est absorbé par des évolutions, et le travail de fond — celui qui n’intéresse personne et qui garde l’application publiable — n’est jamais fait.