Reprendre une application mobile existante, ce que nous vérifions avant de dire oui
Votre application tourne, l'équipe qui l'a écrite n'est plus là, et vous cherchez à qui confier la suite. Avant de faire auditer une seule ligne de code, regardez ce que vous détenez réellement. Une pièce de ce dossier ne se rachète pas.
Ce que vous détenez, et ce qui ne se rachète pas
Une application mobile ne se résume pas à son code. Derrière elle se tiennent un compte App Store Connect, un compte Google Play, une clé de signature Android, un projet de base de données, un nom de paquet, un dépôt de code et les droits qui vont avec. Chacune de ces pièces a un détenteur. Ce n'est pas forcément vous.
Le périmètre réel se mesure mieux sur un projet livré. AquaPro Manager est une plateforme pour les professionnels de la piscine : une application Flutter utilisée en tournée par les techniciens, un back-office Next.js pour les gérants, une base Cloud Firestore sous les deux, une connexion par code à usage unique, App Check, et Stripe pour les abonnements. Reprendre ce produit, c'est reprendre chacune de ces briques et les accès qui vont avec, dont deux qui facturent et un qui décide si vos utilisateurs pourront encore se connecter demain.
Un fichier livré n'est pas un droit cédé. L'article L131-3 du code de la propriété intellectuelle le dit sans détour : « La transmission des droits de l'auteur est subordonnée à la condition que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte de cession et que le domaine d'exploitation des droits cédés soit délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée » (article L131-3, Légifrance). Sans clause de cession écrite et délimitée dans votre contrat, avoir payé le développement et reçu les sources ne règle donc pas tout. Nous ne sommes pas juristes. Nous savons reconnaître le moment où il faut en consulter un, et c'est celui-là.
Qui détient la clé de signature de votre application Android ?
Celui qui a publié la première version, sauf si l'application est passée par Play App Signing. Dans ce cas Google conserve la clé de signature et le développeur ne détient qu'une clé d'envoi, remplaçable. Sinon, cette clé vit dans un fichier sur le poste de quelqu'un, et elle vaut votre fiche Google Play tout entière.
La documentation Android ne laisse aucune marge d'interprétation : « If you lose access to your app signing key or your key is compromised, Google cannot retrieve the app signing key for you, and you will not be able to release new versions of your app to users as updates to the original app » (signature d'application, documentation Android). La même page décrit la conséquence pratique : une version signée par un autre certificat oblige à changer de nom de paquet, et l'utilisateur installe alors une application entièrement nouvelle.
Traduit en conséquences pour vous : vos avis, vos installations et votre classement restent sur une fiche que vous ne pourrez plus mettre à jour. Aucun budget ne rachète cela. C'est le seul point capable de rendre une reprise sans objet, et il passe donc avant la lecture du code.
Quand l'application est bien passée par Play App Signing, la situation se répare : la même documentation indique qu'une clé d'envoi perdue ou compromise se remplace en demandant une réinitialisation dans la Play Console. La protection tient donc à l'accès au compte qui porte l'application, bien plus qu'à un fichier posé sur un disque.
Peut-on transférer une application vers un autre compte développeur ?
Oui. Les deux boutiques prévoient un transfert officiel, qui conserve la fiche, ses notes et ses avis. Il se demande depuis le compte d'origine, il est encadré par des critères précis, et il ne déplace pas tout : une partie de vos données reste derrière. Comptez-le comme une procédure administrative, avec ses délais.
Chez Apple, les critères sont énumérés et se vérifient avant de lancer la demande. L'application doit avoir au moins une version déjà publiée sur l'App Store, ne pas être en précommande, et ne pas se trouver dans un état incompatible avec le transfert, notamment en cours de revue ou en attente de publication. Les identifiants des achats intégrés ne doivent pas entrer en collision avec ceux d'une application du compte destinataire (critères de transfert d'application, App Store Connect). Un projet qui vient d'envoyer une mise à jour en revue attend donc la fin de cette revue.
Chez Google, la demande exige deux pièces que personne n'a sous la main : les identifiants de transaction des frais d'inscription du compte d'origine et du compte destinataire, à retrouver dans les courriels de leurs titulaires respectifs. Plusieurs éléments ne suivent pas l'application : les groupes de test, à recréer, les promotions, les rapports d'export en masse, de ventes estimées et de versements, et les commandes passées avant le transfert, qui restent sur le compte d'origine. Google examine ces demandes sous deux jours ouvrés (transférer des applications vers un autre compte, aide Google Play).
Notre position vaut pour un projet neuf comme pour un projet hérité : les comptes développeur s'ouvrent au nom du client, jamais au nom du prestataire. Nous l'arrêtons au cadrage. Un transfert réussi reste un transfert qu'il aurait mieux valu ne pas avoir à faire.
Faut-il reprendre le code ou le réécrire ?
Reprendre, quand l'application se construit sur une machine neuve à partir du dépôt, que ses dépendances sont encore maintenues, et que la couche de données est séparée des écrans. Réécrire, quand aucune des trois conditions n'est remplie. Le framework, Flutter ou React Native, n'entre pas dans cette décision.
Les applications laissées de côté un an butent rarement sur leur code. Elles butent sur les exigences des boutiques, qui ont continué d'avancer sans elles. Google impose un niveau d'API cible minimal pour accepter la moindre mise à jour, et l'échéance en cours est datée et citée dans notre article sur les règles de publication sur l'App Store et Google Play. La conséquence tombe au plus mauvais moment : le jour où vous avez un correctif urgent à livrer, il faut d'abord remonter toute la chaîne de compilation. Ce lot arrive avant la première fonctionnalité, et il explique souvent l'écart entre le devis attendu et le devis reçu.
Il nous arrive de conclure qu'il faut réécrire. Notre cas le plus net est un back-office web et non une application mobile, mais le raisonnement est le même. Cockpit, un tableau de bord de pilotage marketing pour PME et agences, existait déjà quand nous sommes intervenus : son architecture était difficile à maintenir, et la mission a été une refonte complète du back-office vers API Platform en Symfony, avec OAuth2 et des droits d'accès par rôle. Le temps de chargement du tableau de bord a baissé de 60 %. Reprendre morceau par morceau aurait coûté plus longtemps pour un résultat plus fragile.
Voici la limite de notre méthode, et elle est gênante commercialement. Nous ne savons pas répondre à cette question en réunion, ni devant une démonstration, ni en lisant une documentation que personne n'a tenue à jour depuis la livraison. Il faut cloner le dépôt, construire l'application, la faire tourner, ouvrir la couche de données. Ce sont quelques jours que le client paie avant la moindre fonctionnalité nouvelle, et c'est la ligne la plus difficile à faire accepter. Nous la maintenons, parce qu'un chiffrage donné sans ce travail est une loterie.
Ce que nous regardons dans les premiers jours
L'audit se fait sur des faits vérifiables. Cinq relevés, dans cet ordre :
- l'application se construit-elle sur une machine neuve, à partir du dépôt seul, sans fichier transmis par message privé ;
- le binaire obtenu correspond-il à la version en ligne, ou le dépôt est-il en retard sur la boutique ;
- quelles dépendances ne reçoivent plus de mise à jour, et lesquelles bloquent le niveau d'API cible exigé ;
- existe-t-il des tests, et que couvrent-ils réellement ;
- quels comptes tiers l'application appelle, qui les détient, et qui reçoit leurs factures.
Le dernier relevé produit le plus de surprises. Une application appelle souvent un projet de base de données, un service de notifications, un fournisseur de paiement et une clé d'API ouverte au nom personnel d'un développeur parti depuis. Tant que ces détenteurs ne sont pas identifiés, aucune date de mise en ligne ne tient.
Voici, pour comparaison, un projet qu'une autre équipe reprendrait sans douleur. Sur Daiky, l'application Flutter d'analyse des ingrédients cosmétiques publiée sur l'App Store, le code est organisé en couches distinctes, écrans, providers, repositories et services, pour que la logique d'analyse reste testable indépendamment de l'interface. App Check a été activé dès le départ, et l'internationalisation posée avant la première version. Ces trois choix ne relèvent pas du raffinement : leur absence est ce qui rend une reprise longue.
Questions fréquentes
Le prestataire précédent peut-il refuser de livrer le code source ?
Et si la clé de signature Android a été perdue ?
Faut-il tout réécrire quand on change d'équipe ?
Combien de temps avant la première mise à jour publiée ?
À votre place, nous ferions trois choses avant même de demander un devis de reprise. Retrouver le contrat et vérifier s'il contient une clause de cession de droits. Vérifier qui est titulaire des deux comptes développeur, en vous connectant plutôt qu'en le demandant. Et vérifier si l'application Android est passée par Play App Signing, parce que cette seule réponse change la nature du projet.
Un prestataire sérieux vous demandera ces trois éléments au premier rendez-vous. Les avoir en main raccourcit la suite, et c'est le point de départ de nos missions de développement d'application mobile.
