Reprendre une application mobile ratée

Il existe une catégorie de projets dont personne ne parle sur les sites d’agences, parce qu’elle ne fait pas rêver : les applications qui existent déjà, qui coûtent de l’argent, et que plus personne ne veut ouvrir.

C’est pourtant une part importante de ce qui arrive sur notre bureau. Un dirigeant a payé, l’application est en ligne, elle ne fonctionne qu’à moitié, et la personne qui l’a construite ne répond plus. La question n’est plus « comment faire une application », elle est devenue « qu’est-ce que je fais de celle-là ».

La méthode qui suit est celle qu’on applique avant de s’engager sur quoi que ce soit. Elle est reproductible, et vous pouvez en faire passer la plus grande partie à n’importe quel prestataire que vous consultez.

Les quatre façons dont une application finit à l’abandon

Elles n’ont pas le même pronostic, et c’est la première chose à établir.

Le prestataire a disparu

Fin de contrat mal négociée, société liquidée, freelance qui a changé de métier. Le code existe quelque part, mais les accès, les comptes et les clés sont dispersés. C’est le cas le plus fréquent, et paradoxalement le plus réparable : le problème est administratif avant d’être technique.

Le développeur interne est parti

Une seule personne connaissait le projet, rien n’était documenté, et l’application tourne encore sur des services dont personne ne connaît le mot de passe. Le risque ici s’appelle l’expiration : un certificat qui périme, une clé qui tourne, et l’application s’arrête d’un coup.

Le prototype no-code a atteint son plafond

Il a rendu un vrai service pendant deux ans. Puis le nombre d’utilisateurs a augmenté, les performances se sont effondrées, et la fonctionnalité demandée n’est pas possible dans l’outil. Le code n’est pas récupérable, mais les données et les règles métier le sont, et elles valent souvent plus cher que le code.

L’application a été livrée puis jamais entretenue

Elle fonctionnait le jour de la publication. Deux ans plus tard, elle plante sur les versions récentes du système, elle sera refusée à la prochaine mise à jour, et sa note est descendue. Le code est peut-être bon : c’est le processus qui n’existait pas.

Avant le code : qui possède quoi

C’est l’étape que tout le monde saute, et celle qui bloque le plus de projets. Une reprise techniquement simple peut être impossible pendant six mois parce qu’un compte est au nom d’une société qui n’existe plus.

Faites l’inventaire avant tout le reste. Sept éléments, et pour chacun la seule bonne réponse est « au nom de mon entreprise, et j’ai les accès ».

Élément	Pourquoi c’est bloquant si vous ne l’avez pas
Le compte App Store Connect	Sans lui, aucune mise à jour n’est possible. Un transfert d’application entre comptes Apple exige la coopération active du détenteur actuel
Le compte Google Play Console	Même logique. Le transfert est payant et demande les deux parties
Le certificat de signature Android	Le plus dangereux. Un fichier perdu et vous ne pouvez plus jamais mettre à jour l’application existante. Il faut republier sous un autre identifiant et repartir de zéro utilisateurs
L’identifiant DUNS de l’entreprise	Nécessaire pour un compte développeur d’organisation
Le dépôt de code, avec son historique	Un code livré en archive, sans historique, est un code qu’on ne peut ni comprendre ni reprendre proprement
Le projet back-end (base de données, serveur, hébergement)	Souvent créé sur le compte personnel du prestataire. À migrer, et ça se prépare
Les clés des services tiers (paiement, cartes, envoi d’e-mails, notifications)	Une clé qu’on ne contrôle pas est une panne programmée

Le certificat de signature Android mérite qu’on s’y arrête, parce que c’est la seule ligne de ce tableau qui soit irréversible. Si le prestataire l’a perdu et que la signature n’a pas été confiée à Google, l’application publiée est définitivement figée. Il faut en republier une nouvelle, sous un nouvel identifiant, et redemander à chaque utilisateur de la réinstaller. Le coût se trouve dans la base d’utilisateurs qu’on ne récupère pas, pas dans le développement.

C’est la première question à poser, avant même de savoir si le code est bon.

Ce qu’on regarde dans le code, et ce que ça révèle

Un audit sérieux tient en un à trois jours selon la taille du projet. Il ne s’agit pas de lire tout le code, mais de sonder huit points qui prédisent le reste.

Est-ce que ça compile. On récupère le projet, on suit la procédure fournie, et on essaie de produire une application installable. Si personne n’y arrive en une journée sur une machine neuve, c’est déjà l’information principale : le projet n’était pas reproductible, donc pas maintenable.
L’écart entre le code et ce qui est publié. On compare la version du dépôt avec la version en ligne sur les stores. Un écart de plusieurs versions signifie qu’une partie du travail réel n’a jamais été rendue.
Les dépendances. On liste les bibliothèques externes et leur date de dernière mise à jour. Une bibliothèque abandonnée depuis trois ans dans un chemin critique est une dette qui se paiera à la prochaine version du système.
Les secrets en dur. Clés d’API, mots de passe, jetons d’accès écrits directement dans le code. C’est courant, c’est grave, et ça se répare vite. Ça dit surtout quelque chose sur le niveau de rigueur de l’ensemble.
Les règles de sécurité du back-end. Le test le plus rentable de tout l’audit : est-ce qu’un utilisateur peut lire les données d’un autre utilisateur. Sur les projets repris, la réponse est oui plus souvent qu’on ne l’imagine, et personne ne s’en était aperçu.
Les tests automatisés. Leur nombre compte moins que leur existence. Zéro test signifie que chaque modification future est un pari, et que le coût de la moindre évolution est majoré d’une phase de vérification manuelle complète.
La séparation des couches. Est-ce que la logique métier est mélangée à l’affichage. Quand elle l’est, on ne peut pas changer un écran sans risquer de casser une règle de gestion, et la reprise coûte le prix d’une réécriture partielle.
Le taux de plantage réel. Les consoles Apple et Google le publient. Un taux au-dessus de 1 % est visible par les utilisateurs et il explique à lui seul la note du store.

Reprendre ou réécrire : où passe la ligne

C’est la décision qui pèse le plus lourd, et elle ne relève pas du goût.

Regardez d’abord le socle. Si l’architecture générale est cohérente, même imparfaite, on reprend. Du code mal rangé, des écrans laids, des dépendances anciennes, des tests absents : tout ça se répare, c’est du travail. Un modèle de données qui ne correspond pas au métier réel, non. C’est une fondation, et une fondation ne se redresse pas.

Regardez ensuite la nature de l’outil. Un prototype no-code arrivé à son plafond ne se reprend pas, puisqu’il n’y a pas de code à reprendre. Ce qui se récupère, ce sont les données, les règles métier et surtout deux ans d’apprentissage sur ce dont les utilisateurs ont réellement besoin. C’est un actif considérable, et il rend le projet de réécriture beaucoup plus sûr qu’un projet parti d’une page blanche.

Regardez enfin le nombre de bases de code. Une application maintenue en deux versions séparées, une iOS et une Android, coûtera deux fois plus cher à faire évoluer, pour toujours. Quand la reprise implique de toute façon un travail lourd, c’est le moment de trancher cette question, plutôt que trois ans plus tard.

Un repère utile pour arbitrer : quand le coût estimé de la reprise dépasse la moitié de celui d’une réécriture, la réécriture est presque toujours le meilleur achat. Les ordres de grandeur d’une construction neuve sont détaillés dans combien coûte une application mobile en 2026. Vous partez avec un périmètre connu, des utilisateurs réels, des données existantes et une liste de défauts déjà identifiés. C’est la situation la plus confortable qui existe pour construire une application.

La note du store, et pourquoi elle ne se répare pas en un jour

Beaucoup de dirigeants pensent que corriger l’application fera remonter la note. Le mécanisme est différent.

La note affichée est une moyenne cumulée. Une application à 2,8 étoiles sur 4 000 avis ne remonte pas à 4,2 parce que la version corrigée est bonne : il faut un volume important de nouveaux avis positifs pour déplacer la moyenne. Sur les deux stores, il existe des mécanismes de réinitialisation de la note lors d’un changement majeur de version, mais ils se pilotent, ils ne s’obtiennent pas par accident.

Ce qui fait réellement remonter une note, dans l’ordre : faire baisser le taux de plantage sous 1 %, répondre publiquement aux avis négatifs existants, puis demander l’avis au bon moment, c’est-à-dire juste après que l’utilisateur a obtenu ce qu’il était venu chercher, jamais au lancement de l’application.

Comptez plusieurs mois, et prévoyez-le dans le plan. Une note basse coûte des téléchargements tous les jours, et c’est souvent le poste le plus chiffrable de tout le dossier : multipliez le manque à gagner quotidien par le nombre de jours déjà écoulés.

Côté calendrier, une reprise décale la première phase : la récupération des accès précède toute écriture de code. Le détail est dans combien de temps il faut pour développer une application mobile.

La liste à envoyer à votre ancien prestataire

Copiez-collez ce message. Il obtient en une fois ce qu’on met sinon trois semaines à récupérer par petits bouts, et sa précision décourage les réponses évasives.

Bonjour,

Dans le cadre de la reprise du projet, merci de nous transmettre les éléments suivants :

L’accès au dépôt de code, avec l’historique complet des versions.

La procédure exacte pour produire une application installable à partir d’une machine neuve, et les versions d’outils utilisées.

Le transfert de propriété du compte App Store Connect et du compte Google Play Console vers notre entreprise, ou à défaut un accès administrateur.

Le fichier de signature Android et son mot de passe, ou la confirmation écrite que la signature est déléguée à Google Play.

Les accès administrateur au projet back-end, à la base de données et à l’hébergement.

La liste des services tiers utilisés, avec le compte de rattachement de chacun.

Les identifiants et clés d’API des services de paiement, de notifications et d’envoi d’e-mails.

Toute documentation existante, même partielle.

Merci de nous confirmer sous huit jours les éléments que vous pouvez transmettre et ceux que vous ne pouvez pas.

La dernière phrase est celle qui compte. Ce que le prestataire ne peut pas transmettre vous en apprend plus que tout le reste, et vous l’apprenez avant de signer avec quelqu’un d’autre.

Ce que coûte l’audit, et ce que coûte de s’en passer

Un audit se facture, et c’est normal : c’est du travail d’ingénierie, pas de la préparation commerciale. Il représente une fraction du projet, il se déduit du forfait si la reprise se fait, et il vous rend une réponse ferme sur ce qui est récupérable, un chiffre pour chacune des deux options, et la liste précise des accès manquants avec le temps qu’il faudra pour les obtenir.

Sans audit, le prestataire suivant doit chiffrer à l’aveugle. Un chiffrage à l’aveugle sur un projet existant est toujours l’un des deux : gonflé pour couvrir l’inconnu, ou sous-évalué et renégocié en cours de route. Les deux vous coûtent plus cher que l’audit.

Il y a aussi un coût qui n’apparaît sur aucune ligne comptable. Une application abandonnée pèse sur une équipe : plus personne n’ose y toucher, chaque demande d’évolution est repoussée, et le sujet devient un point d’inconfort permanent en réunion. Trancher, même par « on arrête », vaut mieux que laisser courir.

Par où commencer

Si vous êtes dans cette situation, faites ces trois choses cette semaine, avant même de consulter qui que ce soit :

Vérifiez au nom de qui sont vos deux comptes stores. C’est le seul point qui peut vous coûter votre base d’utilisateurs.
Envoyez la liste ci-dessus à votre ancien prestataire, avec un délai de huit jours.
Notez ce que la situation vous coûte par mois : téléchargements perdus, temps passé à contourner, clients qui ne reviennent pas. C’est ce chiffre qui décidera du périmètre, pas l’état du code.

Ensuite, on peut regarder ensemble. Le questionnaire de cadrage prend cinq minutes et prépare un appel de 45 minutes. Ce qu’on livre est décrit sur la page application mobile.

Questions fréquentes

Peut-on récupérer une application dont le prestataire a disparu ?

Dans la plupart des cas, oui, mais le blocage est administratif avant d’être technique. Tout dépend de qui détient le compte App Store Connect, le compte Google Play et le certificat de signature Android. Le code, lui, se retrouve presque toujours.

Que se passe-t-il si le certificat de signature Android est perdu ?

C’est le seul point sans retour. Si la signature n’a pas été déléguée à Google Play, l’application publiée ne peut plus jamais être mise à jour. Il faut en republier une nouvelle sous un autre identifiant et redemander à chaque utilisateur de la réinstaller, donc repartir de zéro utilisateurs.

Faut-il reprendre le code existant ou tout réécrire ?

Du code mal rangé, des écrans laids, des dépendances anciennes et des tests absents se réparent. Un modèle de données qui ne correspond pas au métier réel ne se redresse pas. Quand le coût estimé de la reprise dépasse la moitié de celui d’une réécriture, la réécriture est presque toujours le meilleur achat.

Comment remonter la note d’une application mal notée sur les stores ?

En faisant d’abord passer le taux de plantage sous 1 %, puis en répondant publiquement aux avis négatifs, et enfin en demandant l’avis juste après que l’utilisateur a obtenu ce qu’il cherchait. La note est une moyenne cumulée : comptez plusieurs mois.

Peut-on migrer une application no-code vers une vraie application ?

Le code d’un outil no-code n’est pas récupérable, mais les données, les règles métier et l’apprentissage sur les besoins réels des utilisateurs le sont. C’est un actif qui rend la réécriture beaucoup plus sûre qu’un projet parti d’une page blanche.

En résumé

Établissez d’abord qui possède quoi : comptes stores, certificat de signature Android, dépôt, back-end, clés tierces. C’est là que se trouvent les blocages irréversibles.
Le certificat de signature Android perdu est le seul point sans retour : il oblige à republier et à repartir de zéro utilisateurs.
Un audit de un à trois jours répond à la vraie question : reprendre ou réécrire.
Ce qui se répare, c’est du code mal rangé. Ce qui ne se répare pas, c’est un modèle de données qui ne correspond pas au métier.
Au-delà de la moitié du coût d’une réécriture, la reprise n’est plus le bon achat.
Une note de store basse remonte en plusieurs mois, et seulement si le taux de plantage passe sous 1 %.