Le jour du lancement est traité comme la ligne d'arrivée, à juste titre — c'est le jalon visible, ce qu'on célèbre et rapporte. Pour une app, c'est plutôt la ligne de départ d'un engagement différent et continu, car contrairement à un site web qui reste globalement immobile jusqu'à ce que quelqu'un le change délibérément, une app vit à l'intérieur de deux systèmes d'exploitation et deux stores d'applications qui continuent de changer, que l'entreprise le veuille ou non.
Les mises à jour du système d'exploitation ne sont pas optionnelles à suivre
Les deux principales plateformes mobiles publient des mises à jour annuelles, et chacune peut changer le comportement du code existant — une permission auparavant accordée automatiquement nécessite désormais une demande explicite, une API dont l'app dépend est dépréciée avec un compte à rebours avant suppression, une taille d'écran ou un schéma d'interaction que l'interface supposait n'est plus valable sur les nouveaux appareils. Une app qui n'est pas activement maintenue ne se casse pas forcément le jour où une nouvelle version d'OS sort, mais elle accumule de petites fissures à chaque version, et le jour où quelque chose casse de façon visible, c'est généralement parce que plusieurs cycles de mises à jour de petits changements se sont accumulés sans être traités.
Les changements de politique des stores arrivent sans préavis et avec une échéance
Les règles de revue des stores d'applications changent selon leur propre calendrier, pas celui de l'entreprise, et une mise à jour de politique peut exiger un changement dans la façon dont l'app demande une permission, présente un abonnement, ou traite un type de données spécifique — avec une échéance de conformité attachée, après laquelle l'app peut être entièrement retirée du store jusqu'à sa correction. Ce n'est pas une catégorie de risque hypothétique ; c'est une part routinière du fait d'opérer dans un store d'applications, et une app que personne ne surveille pour ces changements ne les découvre que lorsqu'elle a déjà été retirée ou signalée, ce qui est une façon bien plus perturbatrice d'apprendre une mise à jour de politique que de lire un journal des modifications à l'avance.
La charge de support ne s'arrête pas au lancement
Chaque vraie mise à jour de la plateforme sous-jacente, chaque nouvelle taille d'appareil, chaque cas limite qu'un vrai utilisateur découvre et que les tests n'avaient pas couvert, génère une question de support ou un rapport de bug, et le volume ne diminue pas après le lancement comme le calendrier d'un projet le laisse supposer — il passe de « bien réussir la première version » à « maintenir un produit vivant fonctionnel pour des gens qui en dépendent désormais », ce qui est un type de travail différent et continu, pas une version réduite du même projet fini.
Ce qu'un plan de maintenance doit réellement couvrir
Un plan réaliste prévoit des tests périodiques contre les nouvelles versions d'OS avant qu'elles ne deviennent obligatoires, pas après qu'un problème survienne ; un processus permanent de suivi des changements de politique des stores plutôt que de les découvrir via un avis de rejet ; et un canal de support réellement doté en personnel, pas un formulaire qui accumule silencieusement des messages non lus. Rien de tout cela n'a besoin d'être important — une petite allocation de temps régulière suffit généralement — mais cela doit exister comme un engagement défini et continu, pas comme la présomption qu'une app terminée le reste.
Pourquoi cela compte avant le lancement, pas après
Le coût réaliste de maintenir une app en vie mérite d'être compris avant que la première version ne soit livrée, pas après que le premier arriéré de support ou le premier rejet de store le rende inévitable — une app budgétée comme un projet ponctuel, sans allocation continue prévue, est une app qui soit se dégrade en silence, soit nécessite une correction plus importante et non planifiée plus tard, les deux coûtant plus cher que ce qu'aurait coûté la planification de la maintenance.
Cela s'inscrit aux côtés des autres questions de construire ou acheter abordées dans choisir comment construire un logiciel adapté à l'entreprise — une app n'est pas un livrable ponctuel, pas plus qu'un employé embauché n'est une embauche ponctuelle. Notre équipe mobile planifie l'engagement de maintenance en même temps que la construction, pas comme une idée ajoutée après coup une fois l'app déjà en ligne.
