Reprise d'application mobile abandonnée

Trois choses à retrouver avant le code

Quand un prestataire ou un développeur part, on pense au code. Mais le code est rarement ce qui bloque en premier. Ce qui bloque, c'est l'accès : le compte développeur Apple et le compte Google Play au nom de qui l'application est publiée, les certificats et clés de signature sans lesquels aucune nouvelle version ne peut être installée, et l'hébergement du backend, dont la facture arrive parfois chez l'ancien prestataire. Tant que ces trois choses ne sont pas à votre nom, personne ne peut publier quoi que ce soit, nous compris.

C'est donc par là qu'on commence, et on le fait avec vous : la liste de ce qu'il faut récupérer, à qui le demander, et quoi faire si l'ancien prestataire ne répond plus. Dans la plupart des cas, Apple et Google ont une procédure de transfert quand l'entreprise prouve qu'elle est propriétaire de l'application.

Les cas qu'on rencontre

• Le prestataire a fermé — le code est sur un dépôt dont vous avez peut-être l'accès, les comptes stores sont au nom d'une société qui n'existe plus. C'est le cas le plus long sur la partie administrative, mais il se règle.
• Le développeur interne est parti — tout est à votre nom, mais personne ne sait plus faire tourner le projet. En général, une semaine suffit pour le remettre en état de compiler et documenter ce qui manquait.
• L'application n'a pas été mise à jour depuis deux ou trois ans — elle tourne encore, mais Apple ou Google menacent de la retirer, ou une mise à jour du système l'a cassée. Il faut souvent monter plusieurs versions d'un coup.
• Vous n'avez pas le code — seulement l'application publiée. On peut récupérer beaucoup de choses de l'application elle-même : les écrans, les parcours, les appels au backend. On repart alors sur une base propre, en React Native, en reproduisant ce qui existe avant d'améliorer.
• L'application a été faite avec un générateur ou une plateforme sans code — le code n'est pas exportable, ou pas exploitable. Le choix est entre rester sur la plateforme et la reconstruire ; on chiffre les deux.

Reprendre tel quel, ou réécrire

Après l'état des lieux, on vous donne une réponse simple : soit le code est reprenable, et on le reprend ; soit il ne l'est pas, et on vous dit pourquoi, avec le coût d'une réécriture en face du coût d'une reprise. Un code est reprenable quand il compile, quand ses dépendances existent encore, et quand un développeur qui ne l'a pas écrit peut y faire une modification sans tout casser. Beaucoup d'applications abandonnées remplissent ces trois conditions ; on ne réécrit pas par confort.

Quand on reprend, on documente ce qu'on trouve, on met en place ce qui manquait pour que l'application se construise et se publie sans intervention manuelle, et on laisse le tout chez vous. Le jour où vous changez de prestataire, ou recrutez en interne, le projet est transmissible. On a repris un prototype en données simulées pour l'emmener en production, et un système d'information de trente ans en le modernisant par morceaux : la méthode est la même.

Questions fréquentes

Nous n'avons plus aucun contact avec l'ancien prestataire. C'est bloquant ?

Non. C'est plus long sur la partie comptes et certificats, mais Apple et Google ont des procédures pour les entreprises qui prouvent qu'elles sont propriétaires de l'application. On vous accompagne dedans.

Combien coûte une reprise ?

L'état des lieux est à prix fixe : 1 900 € HT, cinq jours, rapport écrit avec les options chiffrées. Il est déduit si on continue ensemble. La reprise elle-même dépend de l'état du code, et c'est précisément ce que l'état des lieux établit.

L'application doit rester disponible pendant la reprise ?

Oui, elle reste sur les stores. On ne retire rien. La première version qu'on publie remplace l'ancienne sans interruption pour les utilisateurs.

Et si l'application est en Flutter, en natif, ou en Ionic ?

On fait l'état des lieux et la récupération des accès de la même façon. Pour la suite, on vous dit si la reprise dans la technologie actuelle est raisonnable ou si une réécriture en React Native coûte moins cher à terme. On ne pousse pas la réécriture quand elle n'est pas nécessaire.