Après le lancement : maintenance et gestion des versions
Le lancement n'est pas la ligne d'arrivée. Comment les mises à jour du système, les règles de version des stores et un calendrier maintiennent une app en vie.
Équipe rabbitclipPublié: 5 min de lecture
En bref
Une application mobile a besoin d'être mise à jour quelques fois par an après son lancement ; systèmes d'exploitation, règles des stores et bibliothèques évoluent tous, et une application laissée sans entretien finit par mal fonctionner ou par être retirée du store.
C'est là qu'elle diffère d'un site web. Une page web mise à jour pour une nouvelle version de navigateur continue en général de s'ouvrir sans problème ; une application mobile peut se retrouver décalée quand le système d'exploitation se met à jour, et une version laissée sans entretien peut sortir du store dès qu'une nouvelle règle minimale entre en vigueur.
Ce que la maintenance signifie vraiment
La maintenance consiste à maintenir à jour les bibliothèques de l'application, sa compatibilité avec le système d'exploitation et sa conformité aux règles du store ; c'est un travail distinct de l'ajout de nouvelles fonctionnalités, qui suit un calendrier régulier et prévisible.
Une application n'est pas un produit qu'on écrit une fois et qu'on laisse ; comme tout logiciel vivant, elle doit changer à mesure que son environnement change.
La distinction mérite d'être posée clairement : la maintenance maintient l'application telle qu'elle est ; le travail de nouvelles fonctionnalités la fait grandir. La même équipe peut faire les deux, mais il leur faut des lignes budgétaires séparées, sinon la maintenance perd discrètement à chaque fois face au travail de croissance.
Pourquoi les mises à jour du système créent de la pression
Apple et Google publient chacun une version majeure de système par an ; à chaque sortie, certaines API sont dépréciées et certains comportements de permission changent. Un code qui tournait bien l'année précédente peut se comporter de façon inattendue sur la nouvelle version.
C'est pourquoi l'application doit être testée contre chaque version majeure d'OS dès sa sortie ; retarder ce test tend à se traduire en plaintes des utilisateurs.
Une demande de permission qui tenait auparavant sur un seul écran peut par exemple se scinder en deux étapes sur une nouvelle version ; le code continue de tourner, mais l'utilisateur ne voit jamais l'écran attendu. Ce type de changement n'apparaît qu'à de vrais tests, jamais à une revue de code.
Les mises à jour obligatoires côté store
Google Play relève son niveau d'API cible minimum chaque année ; les applications laissées en dessous perdent la possibilité d'être nouvellement installées ou mises à jour. Cela signifie que l'application peut effectivement disparaître du store même si le code lui-même n'est pas cassé.
Du côté d'Apple, de la même façon, les applications compilées avec un ancien SDK finissent par ne plus être acceptées en soumission ; c'est pourquoi un cycle annuel de recompilation et de test fait partie du travail.
Comment mettre en place un calendrier de maintenance
Ce qui fonctionne en pratique, c'est de définir deux ou trois fenêtres de maintenance fixes par an : mises à jour de bibliothèques, tests d'un nouvel OS, vérifications de politique de store. En dehors de ces fenêtres, seul un bug véritablement critique déclenche une intervention urgente.
- Tests de compatibilité à la sortie d'une nouvelle version d'OS
- Une recompilation quand l'exigence d'API/SDK cible du store change
- Mises à jour de sécurité des bibliothèques tierces utilisées
- Revue régulière des retours utilisateurs et des rapports de plantage
Ce qui se passe sans maintenance
Dans le cas le plus léger, l'application ralentit peu à peu ou renvoie des erreurs sur certains écrans. Dans le pire des cas, le store la ferme aux nouveaux utilisateurs, voire la retire complètement, une fois que le niveau d'API cible devient trop obsolète. Les deux prennent du temps à corriger.
L'application revendeurs d'un atelier de meubles, laissée intacte pendant deux ans, a perdu la capacité d'être réinstallée quand Google Play a relevé son niveau d'API cible ; les revendeurs qui changeaient de téléphone ne pouvaient plus la réinstaller. La correction elle-même a pris une semaine, mais remarquer le problème a pris presque six mois, parce que personne ne vérifiait régulièrement.
Qui devrait porter la maintenance : en interne ou une agence
Dans une petite entreprise, dire à une personne « peux-tu aussi t'occuper de l'app » paraît simple, mais la maintenance finit coincée entre le vrai travail de cette personne et repoussée à chaque fois. C'est la façon la plus courante dont la maintenance cesse discrètement de se faire.
Le test de décision est le suivant : la charge annuelle de maintenance de l'application (tests, recompilation, vérifications de store) est-elle assez faible pour être une tâche régulière et répétable pour une seule personne, ou nécessite-t-elle son propre budget et calendrier. Si c'est le second cas, confier la maintenance à une équipe externe sous un arrangement permanent évite que le travail ne se perde dans les intervalles.
Erreurs fréquentes
L'erreur la plus fréquente consiste à traiter la maintenance selon le principe « on s'en occupera si quelque chose casse » ; les exigences des stores arrivent discrètement, sans problème évident au préalable, et l'application peut sortir du store avant que quiconque le remarque. La maintenance doit être planifiée, pas réactive.
La seconde consiste à ne tester une nouvelle version d'OS qu'une fois sa sortie officielle ; tester dès l'apparition de la bêta laisse le temps de repérer et corriger les problèmes avant que la version publique n'arrive.
- Ne se souvenir de la maintenance que lorsque quelque chose casse
- Ne tester un nouvel OS que sur sa version officielle
- Laisser la maintenance à une seule personne sans calendrier écrit
Le lancement n'est pas une fin ; c'est le début d'un cycle de maintenance régulier, et ce cycle se déroule sans surprises une fois qu'un calendrier défini le soutient. Si votre application n'a pas encore de calendrier de maintenance, cela vaut la peine d'en mettre un en place ensemble.
Questions fréquentes
Que se passe-t-il si une application n'est jamais mise à jour ?
Elle peut tourner sans problème un moment, mais dès que le système d'exploitation ou une règle de store change, elle se retrouve décalée et peut finir fermée aux nouvelles installations.
Combien de mises à jour par an suffisent pour la maintenance ?
En général deux ou trois mises à jour planifiées ; un bug sérieux reçoit une correction urgente en dehors de ce calendrier.
Faut-il tester l'application dès qu'un nouvel OS sort ?
Tester contre la version bêta, avant la sortie publique, permet de détecter les problèmes tôt plutôt qu'après que les utilisateurs les signalent.
Une application est-elle en danger sans accord de maintenance ?
Avec le temps, oui ; sans personne pour suivre cela, des exigences de store ou des changements d'OS peuvent passer inaperçus jusqu'à ce que l'application en soit affectée.
