La plupart des applications meurent après leur lancement. Non pas parce que l’idée était mauvaise, mais parce que quelqu’un considérait le « lancement » comme la ligne d’arrivée. La fête a lieu, l'équipe fait la fête, le budget est finalisé et six mois plus tard, l'application est pleine de bugs, plante sur les nouvelles versions du système d'exploitation et perd des utilisateurs sans que personne ne comprenne pourquoi.
La maintenance des applications n’est pas un détail technique. C'est la partie du cycle de vie qui décide si le produit générera de la valeur pendant des années ou deviendra un coût enterré. Et presque personne ne prévoit cela avant de commencer.
Ceux qui n’ont jamais créé de logiciel ont tendance à imaginer qu’une application terminée est comme un bâtiment livré : vous coupez la bande et elle reste là, fonctionnant. La réalité ressemble plus à un jardin. Si vous arrêtez d’en prendre soin, il ne reste plus le même, il se dégrade.
Qu'est-ce que la maintenance des applications, en réalité ?
La maintenance ne consiste pas seulement à « réparer ce qui tombe en panne ». Ce n’est qu’un des quatre types, et probablement le moins important à long terme.
La maintenance corrective corrige les défauts. Adaptatif maintient l'application en marche lorsque l'environnement change, les nouvelles versions d'iOS et d'Android, les modifications d'API tierces et les nouveaux modèles d'appareils. Le parfait améliore ce qui existe déjà à partir d'une utilisation réelle. Et la prévention réduit les risques futurs : refactorisation, mise à jour des bibliothèques, réduction de la dette technique.
L’erreur classique de gestion est de financer uniquement les mesures correctives. Le résultat est une application qui continue d’éteindre les incendies et n’évolue jamais. Lorsque vous comprenez que les mesures adaptatives et préventives sont obligatoires et non facultatives, la conversation sur la budgétisation change complètement.
Pourquoi l'environnement impose la maintenance
Une application mobile ne vit pas seule. Il s'appuie sur des dépendances externes qui changent sans demander la permission.
Apple et Google publient chaque année de nouvelles versions de leurs systèmes et exigent périodiquement que les applications publiées répondent aux exigences mises à jour en matière de SDK, de confidentialité et d'autorisations. Si vous n'effectuez pas la mise à jour, la boutique cesse simplement d'accepter les nouvelles versions et, dans les cas extrêmes, supprime l'application.
Ajoutez à cela les dépendances externes : passerelles de paiement, fournisseurs de connexion, services de cartographie, SDK d'analyse. Chacun d’eux évolue, déprécie les points de terminaison et modifie les règles. Votre application peut être parfaitement codée et rester en panne parce qu’un fournisseur a modifié quelque chose de son côté.
C'est pourquoi la maintenance adaptative est inévitable. Vous ne contrôlez pas le sol sur lequel vous marchez.
La thèse : la maintenance se décide lors de la planification, pas plus tard
Voici l’idée centrale de ce texte. La qualité et le coût de maintenance d’une application sont définis bien avant l’apparition du premier utilisateur. Ils sont une conséquence des décisions prises au départ.
Architecture propre, tests automatisés, choix conscient des dépendances, observabilité dès le début, tout cela constitue, en pratique, un investissement dans une maintenance future bon marché. L’inverse est également vrai : la précipitation et les raccourcis du début se transforment en dette technique qui facture des intérêts pendant des années.
Quand quelqu'un me présente la chronologie d'une application et qu'il n'y a aucune indication sur ce qui se passe après le lancement, je sais déjà ce qui va se passer. Le produit naîtra et, silencieusement, commencera à pourrir.
Que prévoir avant de se lancer
Pensez sur trois fronts dès la conception du projet. Tout d'abord, la continuité : qui maintiendra l'application, avec quelle capacité et quel budget récurrent. Deuxièmement, observabilité : comment saurez-vous que quelque chose s'est cassé avant que l'utilisateur ne se plaint, rapports d'erreur, journaux, métriques d'utilisation. Troisièmement, la prévisibilité technique : une documentation minimale, des normes de code et des tests qui permettent à quelqu'un d'autre de comprendre le système sans archéologie.
Aucun de ces fronts n’est coûteux lorsqu’il est planifié. Ils coûtent tous très cher une fois improvisés plus tard.
La maintenance comme problème de gestion, pas seulement comme code
Dans le secteur public, ce point est particulièrement sensible. Une mairie qui embauche une application de services aux citoyens, planifiant des rendez-vous, délivrant des documents, produisant des rapports, doit comprendre qu'elle prend un engagement continu et qu'elle n'achète pas un produit fermé.
Le schéma qui se répète est triste : le contrat couvre le développement, les changements de direction, le budget de maintenance n'est pas renouvelé et deux ans plus tard, l'application est abandonnée dans le magasin avec des critiques d'une étoile. Le citoyen perd, tout comme sa confiance dans le gouvernement numérique.
La maintenance, dans ce contexte, est la continuité du service public. Cela doit être défini dans un contrat, dans un budget pluriannuel et dans des responsabilités claires. Le traiter comme une dépense occasionnelle, c’est garantir l’échec.
Les erreurs les plus courantes commises par ceux qui ignorent la maintenance
La première est de confondre maintenance et inactivité. "L'application est prête, vous n'avez pas besoin d'y toucher." Il n’existe pas d’application arrêtée, il existe une application dont on ne s’occupe plus et qui se dégrade lentement.
La seconde est de ne rien mesurer. Sans rapports d’erreur et sans mesures d’utilisation, vous êtes aveugle. Découvrez les problèmes grâce à des évaluations en magasin, lorsque le mal est déjà fait.
La troisième consiste à considérer les dépendances comme éternelles. Les bibliothèques obsolètes accumulent des failles de sécurité, un risque direct du point de vue de la LGPD lorsqu'il s'agit de données personnelles. La maintenance préventive est aussi une question de sécurité.
Clôture
Le lancement d’une application est le début de sa durée de vie et non la fin du projet. L’application qui survit n’est pas la plus jolie le jour du lancement, c’est celle qui a été conçue pour être maintenue.
Planifier la maintenance dès le début n’est pas du pessimisme. C'est la maturité. C'est reconnaître que les logiciels vivent en mouvement et que prendre soin de ce que vous construisez vaut autant que le construire.
Si vous êtes sur le point d’investir dans une application et que le plan se termine au lancement, cela vaut la peine de repenser avant de souscrire. J'ai d'autres textes sur le blog sur le cycle de vie des produits numériques et la dette technique, et, s'il s'agit d'un problème spécifique à votre organisation, c'est le type de conversation qui porte ses fruits.
A lire aussi
- Maintenance des applications mobiles : les étapes indispensables pour ne pas perdre le contrôle
- Planification de la maintenance des applications : un guide rapide à mettre en pratique -Validation d'idée d'application : ce qu'une entreprise doit décider avant d'investir
- Cycle de vie des produits digitaux : tendances et étapes essentielles -A quoi sert une application mobile : ce que les petites équipes doivent évaluer avant d'investir
- Applications de publication : les étapes incontournables dont personne ne vous parle
