Aller au contenu
Le Môle Web

Après le lancement : la vraie vie d’une application mobile

Applications smartphone. 1 août 2026. 5 min de lecture.

Le jour de la mise en ligne est un départ

Une application n’est pas un objet fini, posé une fois pour toutes. C’est une chose vivante, installée dans un environnement qui change en permanence : systèmes d’exploitation, appareils, règles des stores, attentes des utilisateurs. Ce qui fonctionnait parfaitement en mars peut être refusé en novembre, sans que vous ayez touché à une seule ligne.

Les quatre forces qui érodent une application

  • Les systèmes avancent. Chaque version majeure modifie des comportements : permissions, notifications, affichage, sécurité. Une application non entretenue se dégrade d’abord visuellement, puis fonctionnellement.
  • Les stores relèvent leurs exigences. Passé un certain délai, les nouvelles soumissions et les mises à jour sont refusées. Une application figée finit par ne plus pouvoir être corrigée du tout, ce qui est le pire des scénarios.
  • Les dépendances vieillissent. Une faille découverte dans une brique tierce devient votre problème, immédiatement.
  • Le parc d’appareils se renouvelle. Une interface pensée il y a deux ans peut mal se comporter sur un appareil sorti l’an dernier.

Conséquence : une application sans maintenance a une durée de vie utile d’environ dix-huit à vingt-quatre mois. Passé ce délai, la remettre à niveau coûte souvent plus cher que de l’avoir entretenue.

Ce que contient un accompagnement sérieux

  • Correctif : anomalies, plantages, régressions signalées par les utilisateurs.
  • Adaptatif : compatibilité avec les nouvelles versions d’OS, les nouveaux appareils, les nouvelles exigences des stores. C’est le poste le plus prévisible et le plus indispensable.
  • Sécurité : mise à jour des dépendances, correction des vulnérabilités, gestion des certificats.
  • Évolutif : nouvelles fonctionnalités. C’est la seule part véritablement optionnelle, et celle qui fait grandir le produit.
  • Supervision : surveillance des serveurs, des taux d’erreur, des temps de réponse et des sauvegardes.

L’ordre de grandeur admis dans le métier est de quinze à vingt-cinq pour cent du coût de développement initial par an, hors évolutions majeures. S’y ajoutent les coûts fixes que nous détaillons dans l’article sur le budget. Ce chiffre n’est pas une punition : c’est le prix d’un objet qui continue d’exister.

Mesurer, mais pas n’importe quoi

Après le lancement, la tentation est de regarder le nombre de téléchargements. C’est le chiffre le moins utile de tous. Quatre indicateurs comptent réellement :

  • La rétention à sept et trente jours : la proportion d’utilisateurs encore présents. C’est la vraie mesure de l’utilité perçue.
  • Le taux de complétion du parcours clé : combien de personnes vont au bout de l’action centrale.
  • Le taux de plantage, à suivre par version et par modèle d’appareil.
  • Le point d’abandon exact : l’écran précis où les gens s’arrêtent. C’est là que se cache le chantier suivant.

Un mot sur les outils de mesure : ils collectent des données personnelles, doivent figurer dans votre déclaration sur les stores, et méritent d’être choisis en connaissance de cause. Nous y consacrons un article sur les alternatives européennes.

La dette technique, expliquée simplement

À chaque fois que nous choisissons la solution rapide plutôt que la solution juste, pour tenir une date ou économiser trois jours, nous empruntons. Le code fonctionne, mais il devient plus difficile à faire évoluer. Ce n’est pas une faute : emprunter est parfois la bonne décision. Le problème n’est pas la dette, c’est la dette jamais remboursée.

Le symptôme est reconnaissable entre tous : pourquoi cette petite modification coûte-t-elle si cher ? Elle coûte cher parce qu’elle traverse dix endroits qui auraient dû n’en faire qu’un. La bonne pratique consiste à consacrer une part régulière du budget d’évolution à l’assainissement plutôt qu’à l’ajout. Ce travail ne se voit pas : il maintient la vitesse.

Un cycle de vie sain

Les quatre premières semaines servent à corriger les urgences révélées par le contact avec de vrais utilisateurs. Il y en a toujours. Les deuxième et troisième mois servent à analyser les usages, et nous découvrons presque toujours que les gens n’utilisent pas l’application comme prévu. C’est une bonne nouvelle : c’est de l’information.

La première évolution arrive vers le quatrième ou le sixième mois, fondée sur les usages observés et non sur les intuitions de départ. Chaque année ensuite, une mise à niveau technique et un remboursement partiel de la dette. Et tous les trois à quatre ans, une refonte partielle ou complète. Ce n’est pas un échec, c’est un rythme normal, exactement comme pour un site internet.

Notre façon de faire

Nous avons choisi d’avoir peu de clients pour avoir beaucoup de relation. Concrètement, cela veut dire que nous sommes là après, pas seulement avant : le même interlocuteur, du premier échange à la troisième année. Pas de ticket anonyme, pas de changement d’équipe, pas de surcouche vendue au moment du renouvellement.

Un projet web ou mobile n’est pas une livraison, c’est une trajectoire. Notre page maintenance et suivi détaille cet accompagnement, et nous auditons volontiers une application existante avant toute proposition.

Nous utilisons des cookies pour améliorer votre expérience. Vous pouvez accepter, refuser ou personnaliser vos préférences.

Préférences de confidentialité

Choisissez les catégories de cookies que vous souhaitez activer. Vous pouvez modifier votre choix à tout moment.