Reprendre une application mobile déjà en production : le cas Par2

Ce cas client est différent des autres publiés ici, et autant le dire tout de suite : nous n’avons pas créé cette application. Elle a été développée par une autre équipe, publiée sur l’App Store et Google Play, et elle avait déjà ses utilisateurs quand elle nous a été confiée.

Il s’agit de Par2, une application de rencontre destinée à la communauté du golf : découverte de profils, mise en relation, messagerie, forums, événements, abonnement. Une application complète, avec de vraies personnes derrière.

Ce qui suit est le déroulé d’une reprise. C’est une situation beaucoup plus fréquente qu’on ne le croit, et rarement racontée.

Reprendre, ce n’est pas recommencer

Le premier réflexe, quand on hérite d’une application qu’on n’a pas écrite, c’est de vouloir tout refaire. C’est aussi le plus coûteux.

Une application en production, ce n’est pas seulement du code : ce sont des utilisateurs installés, des habitudes prises, des comportements validés par l’usage et une quantité de petites décisions que personne n’a documentées mais qui ont leur raison d’être. Une réécriture met des mois à retrouver tout ça, et pendant ces mois, les utilisateurs n’ont ni nouveauté ni correctif.

On a donc gardé la base et travaillé dedans, dans un ordre précis. Cet ordre est le vrai sujet de cet article.

Premier temps : les accès aux données

Une application de ce type range ses données (profils, photos, messages) dans une base hébergée. Qui a le droit de lire quoi, qui a le droit d’écrire quoi : cela se décrit dans un jeu de règles, et c’est ce jeu de règles qui protège les utilisateurs.

C’est le premier poste qu’on a traité, avant toute nouvelle fonctionnalité. Chaque règle a été reprise et calée sur ce que l’application fait réellement, puis couverte par des tests automatisés pour qu’une modification ultérieure ne puisse pas la desserrer sans qu’on le voie.

L’ordre des priorités est important, et il est contre-intuitif vu du client, qui attend en général des fonctionnalités : c’est le seul chantier dont le coût augmente avec le temps. Chaque fonctionnalité ajoutée avant lui est une fonctionnalité de plus à reprendre après.

Deuxième temps : un environnement de recette

Deuxième chantier invisible, et deuxième condition pour avancer sans rien casser : pouvoir essayer quelque chose sans le faire sur les comptes réels.

Un environnement de recette isolé a donc été monté : ses propres données, sa propre base, et un jeu d’essai qu’on peut remettre à zéro autant de fois qu’on veut. Avec, par-dessus, des garde-fous techniques qui empêchent une session de test de parler à la production, même par erreur.

C’est trois ou quatre jours de travail qui ne produisent rien de visible pour l’utilisateur, et qui changent tout : à partir de là, chaque correctif peut être vérifié avant d’être livré, au lieu d’être un pari.

Troisième temps : fiabiliser, par petits morceaux

Une fois qu’on peut tester, on peut réparer. Cette phase a porté sur les parcours qui comptent le plus dans une application de mise en relation : l’inscription, qui est la toute première chose que voit un nouvel utilisateur, les écrans de mise en relation, les notifications dans chaque langue proposée, et la robustesse face à des données incomplètes, qui sont la première cause d’écran figé dans n’importe quelle application.

Rien de spectaculaire, et c’est le propos : ce sont des corrections ordinaires, livrées une par une, chacune vérifiable en recette avant d’atteindre les utilisateurs.

Ce qui a été ajouté ensuite

Une reprise n’a d’intérêt que si elle débouche sur du neuf. Une fois les fondations saines, le produit a avancé.

Un module golfs et événements. L’application dispose désormais d’un annuaire de clubs avec fiches détaillées, favoris, filtres persistants et tri par distance, plus un agenda de compétitions et d’animations, trié par proximité. C’est le même annuaire que celui du site public, alimenté par les gérants de clubs eux-mêmes.

Un travail sur les langues. L’application est passée de deux à six langues, arabe compris, ce qui a demandé de gérer la lecture de droite à gauche : l’interface entière se retourne, et il a fallu que ce basculement tienne d’un lancement à l’autre. Les autorisations système demandées par le téléphone (localisation, photos, notifications) ont été traduites elles aussi, ce que presque personne ne fait.

Des choses moins spectaculaires mais utiles : la rétention au moment de la suppression de compte (proposer une pause plutôt qu’un adieu, et recueillir le motif), une page pour proposer une fonctionnalité, une analyse du parcours de découverte des profils sur données réelles, et des versions livrées régulièrement plutôt qu’au coup par coup.

Ce qu’il faut retenir si vous héritez d’une application

Si une application vous arrive entre les mains sans son équipe d’origine, quatre points de ce cas valent d’être retenus :

1. Ne réécrivez pas tout. Une application en production a des utilisateurs, des comportements validés par l’usage, et une valeur qu’une réécriture met des mois à retrouver.
2. Commencez par les accès aux données, avant la moindre nouveauté. C’est le seul chantier dont le coût augmente avec le temps.
3. Offrez-vous un environnement de recette. Sans lui, chaque correction est un pari et chaque livraison une angoisse.
4. Faites établir un état des lieux écrit. Quelques jours d’audit disent si la base est saine, réparable ou perdue. C’est la dépense la plus rentable de toute l’opération, y compris quand la conclusion est « il faut recommencer ».

Et pour votre projet

Notre offre publique porte sur les sites internet, avec des prix affichés et un devis gratuit sous 24 h : tout est sur la page création de site internet.

Une application mobile existante, sa reprise ou sa maintenance, ça se regarde au cas par cas. Si vous êtes dans cette situation, écrivez-nous en décrivant l’existant : on vous dira franchement ce qu’on en pense, y compris si la réponse est que ce n’est pas pour nous.

Questions fréquentes

Faut-il tout réécrire quand on reprend une application existante ?

Presque jamais. Une réécriture complète coûte des mois, fait perdre au passage des comportements que personne n'avait documentés, et laisse les utilisateurs sans nouveautés ni correctifs pendant ce temps-là. La bonne méthode consiste à sécuriser les accès aux données d'abord, se donner un moyen de tester ensuite, puis avancer par petits morceaux livrables.

Par quoi commence-t-on quand on hérite d'une application inconnue ?

Par les accès aux données, avant toute nouvelle fonctionnalité. C'est le seul chantier dont le coût augmente avec le temps : chaque fonctionnalité ajoutée avant lui est une fonctionnalité de plus à reprendre après. Vient ensuite un environnement de test séparé, sans lequel la moindre vérification se ferait sur les comptes réels.

Peut-on tester une application sans toucher aux données réelles ?

Oui, en montant un environnement de recette avec ses propres données, isolé de la production, et un jeu d'essai qu'on peut remettre à zéro. C'est un investissement de quelques jours qui se rembourse dès le premier correctif qu'on ose livrer sereinement.

Que coûte une reprise d'application par rapport à un développement neuf ?

Cela dépend entièrement de l'état du code, et cela s'évalue avant de s'engager : un audit de quelques jours dit si la base est saine, réparable ou perdue. Dans la majorité des cas, la reprise revient nettement moins cher qu'un développement neuf, parce que le produit existe déjà, qu'il a des utilisateurs et que ses fonctionnalités ont été validées par l'usage.

Faites-vous du développement d'applications mobiles ?

Notre offre publique porte sur les sites internet, dont les prix sont affichés. Une application mobile, sa reprise ou sa maintenance se traitent au cas par cas, après un échange sur l'existant. Parlez-nous de votre situation, on vous dira franchement si c'est pour nous ou pas.