Votre application existe, elle a des utilisateurs, mais le prestataire qui l’a développée ne répond plus. Ou chaque évolution prend des semaines et coûte trop cher. Ou vous n’êtes plus certain de savoir où se trouve le code. La question est donc simple : quelqu’un d’autre peut-il reprendre cette application, et à quel prix ? Rares sont les agences qui y répondent franchement, parce que la réponse honnête commence par « ça dépend de ce que l’on trouve ».
Chez Playmoweb, la reprise d’une application existante est pourtant l’une des demandes les plus fréquentes en avant-vente, et l’une des moins bien documentées. En plus de 12 ans d’applications mobiles, web et IoT à Angers, nous avons audité de nombreux projets hérités, repris certains, refondu d’autres et parfois déconseillé la reprise. Voici la méthode que nous appliquons : signaux d’alerte, éléments à récupérer, déroulé et coût de l’audit, grille de décision et budgets.
Sommaire
Une reprise d’application existante se décide lorsque plusieurs signaux s’accumulent. Voici ceux que nous rencontrons le plus souvent, par ordre de gravité.
Vous n’avez pas accès au code ni aux comptes stores. C’est le signal le plus grave. En effet, si le dépôt de code, le compte Apple Developer et la console Google Play sont au nom du prestataire, vous ne possédez pas votre application : vous la louez sans le savoir. Le jour où le prestataire disparaît, l’application disparaît donc avec lui.
Il n’existe aucune documentation. Pas de schéma d’architecture, pas de procédure de mise en production. Autrement dit, tout est dans la tête d’une personne : le savoir n’est pas capitalisé, il est otage.
Les dépendances sont obsolètes. Les stores relèvent leurs exigences chaque année. Par exemple, depuis avril 2026, Apple n’accepte plus les applications qui ne sont pas compilées avec le SDK iOS 26. De même, depuis le 31 août 2026, Google Play exige Android 16 (API 36) pour toute nouvelle version. Une application dont la chaîne de build n’a pas bougé depuis deux ans ne peut donc plus être mise à jour sans travail préalable.
Un seul développeur connaît le projet. Freelance isolé, ou agence où une seule personne a touché au code. Le risque n’est pas la compétence, mais la continuité.
Les coûts d’évolution explosent. Quand une modification mineure coûte plusieurs jours, c’est en général le symptôme d’une dette technique lourde ou d’une absence de tests.
Un seul de ces signaux justifie un audit, tandis que deux ou plus justifient de préparer la reprise.
Avant de parler technique, parlez propriété. Tant que la relation avec le prestataire actuel n’est pas rompue, vous êtes en position de récupérer ce qui vous appartient. Après la rupture, en revanche, c’est plus long, plus cher, parfois impossible. Voici l’inventaire à établir.
Si vous ne pouvez rien récupérer, l’application peut être republiée sous un nouvel identifiant, mais vous perdrez vos avis et vos utilisateurs devront réinstaller. C’est dans ce cas un scénario de réécriture, pas de reprise.
C’est le point que tout le monde oublie. En droit français, en effet, le prestataire reste titulaire des droits sur le code qu’il a écrit tant qu’aucune cession écrite n’a été signée. L’article L131-3 du Code de la propriété intellectuelle exige que chaque droit cédé fasse l’objet d’une mention distincte et que le domaine d’exploitation soit délimité en étendue, destination, lieu et durée. Autrement dit, une facture « développement de l’application » ne vaut pas cession. Si la clause manque à votre contrat, faites-la donc signer avant la rupture.
Aucune agence sérieuse ne s’engage sur une reprise sans avoir lu le code. L’audit technique de reprise transforme ainsi « on verra » en chiffres. Chez Playmoweb, il suit cinq axes.
1. Lecture du code et de l’architecture. Quelles technologies, quelle séparation entre l’interface, la logique métier et les données ? Un code lisible et structuré se reprend. À l’inverse, un code monolithique sans convention se réécrit souvent plus vite qu’il ne se comprend.
2. Dette technique. Versions des frameworks et des bibliothèques, écart avec les exigences des stores, composants abandonnés par leur éditeur. Nous listons ensuite ce qu’il faut mettre à niveau avant toute nouvelle fonctionnalité.
3. Sécurité. Clés en dur dans le code, données personnelles stockées en clair, échanges non chiffrés, API sans authentification. Dès lors que l’application manipule des données clients, cet axe peut à lui seul faire basculer la décision.
4. Tests et qualité. Tests automatisés, périmètre couvert, intégration continue. Sans tests, chaque évolution devra être vérifiée à la main, si bien que la maintenance renchérit durablement.
5. Chaîne de build et déploiement. Peut-on, depuis un poste neuf, compiler l’application et la livrer sur les stores ? C’est le test de vérité. Si la réponse est non, la reprise commence alors par là.
L’audit livre enfin un rapport écrit : état des lieux, risques classés par gravité, recommandation (reprendre, refondre en partie, réécrire) et chiffrage de chaque scénario. Comptez 3 à 10 jours de travail selon la taille de l’application, soit un budget de l’ordre de 2 à 6 k€ (estimation Playmoweb, à confirmer selon le périmètre). C’est le meilleur investissement du projet, car il évite de dépenser 50 k€ sur une base qui ne le méritait pas. De même, il évite de réécrire une base qui fonctionnait. Notre offre d’audit technique couvre ce périmètre.
La tentation de l’agence qui reprend est de tout réécrire : c’est plus confortable pour elle. Celle du client, en revanche, est de tout garder : c’est moins cher à court terme. En réalité, la bonne réponse se trouve dans une grille à cinq critères.
| Critère | Reprendre en l’état | Refondre en partie | Réécrire |
|---|---|---|---|
| Âge du code | Moins de 3 ans, mis à jour régulièrement | 3 à 5 ans, mises à jour irrégulières | Plus de 5 ans sans mise à niveau |
| Technologie | Standard et maintenue (Kotlin, Swift, KMP, Flutter à jour) | Standard mais versions en retard | Framework abandonné, hybride obsolète, outil propriétaire |
| Documentation | Existante, même partielle | Absente mais code lisible | Absente et code illisible |
| Dette technique et tests | Quelques mises à niveau, tests présents | Modules à reprendre, tests partiels | Dette généralisée, aucun test, failles de sécurité |
| Coût de remise à niveau | Inférieur à 20 % du coût d’une réécriture | Entre 20 et 50 % | Supérieur à 50 % : la réécriture devient alors plus rationnelle |
Les critères se cumulent : par exemple, un code de 4 ans bien documenté et testé se reprend sans difficulté. La refonte partielle est d’ailleurs le scénario que nous recommandons le plus souvent. Elle conserve ce qui fonctionne (souvent le backend) et remplace la brique la plus dégradée (souvent l’application mobile). Quand la réécriture s’impose sur iOS et Android, c’est l’occasion de passer sur Kotlin Multiplatform, qui permet d’économiser 20 à 40 % par rapport à deux développements natifs séparés.
Voici les ordres de grandeur que nous observons. Ils dépendent fortement de ce que l’audit révèle, d’où son importance.
| Scénario | Contenu | Budget indicatif | Délai |
|---|---|---|---|
| Audit de reprise | Code, sécurité, tests, chaîne de build, rapport chiffré | 2 à 6 k€ | 1 à 3 semaines |
| Reprise en l’état et mise à niveau | Accès, mise à jour des SDK et dépendances, chaîne de build, conformité stores, publication | 5 à 15 k€ | 3 à 6 semaines |
| Refonte partielle | Réécriture d’un ou plusieurs modules, tests, correction des failles, backend conservé | 15 à 60 k€ | 2 à 5 mois |
| Réécriture complète | Nouveau développement, migration des données et des utilisateurs, double run | 25 à 200 k€ et plus, comme une application neuve | Selon le périmètre |
| Maintenance après reprise | Correctif, mises à jour stores, petites évolutions | 15 à 25 % du coût initial par an | En continu |
Important : ces fourchettes couvrent le développement et la mise à niveau. Elles n’incluent pas les abonnements aux services tiers ni le temps de recette de vos équipes. Elles excluent également les frais de comptes stores (99 dollars par an chez Apple, 25 dollars une seule fois chez Google). Pour situer ces chiffres, notre guide du coût d’une application mobile en 2026 détaille les fourchettes par type de projet. Par ailleurs, notre article sur le coût de maintenance d’une application mobile explique ce que recouvrent les 15 à 25 % annuels.
Les premiers mois après une reprise coûtent plus cher que la vitesse de croisière, car l’équipe découvre le code en le corrigeant. Prévoyez un budget de démarrage majoré plutôt qu’un forfait mensuel figé dès le premier jour.
Réécrire par réflexe. C’est le piège numéro un, et il vient souvent du prestataire repreneur, car un développeur préfère toujours son code à celui d’un autre. Exigez que la recommandation de réécriture soit justifiée par l’audit, critère par critère, et chiffrée face au scénario de reprise.
Sous-estimer la migration des données et des utilisateurs. Une réécriture ne se limite pas à recoder les écrans. Il faut également reprendre les comptes existants, les mots de passe (souvent impossibles à migrer tels quels, ce qui impose une réinitialisation), l’historique, les abonnements en cours, les jetons de notifications push. C’est pourtant régulièrement le poste que personne n’avait budgété.
Oublier la période de double run. Entre la publication de la nouvelle version et l’extinction de l’ancienne, les deux coexistent : deux backends, deux versions à supporter, des utilisateurs qui ne mettent pas à jour. Cette période dure plusieurs semaines : elle doit donc être chiffrée dès le devis.
Ne pas sécuriser la propriété intellectuelle. Sans cession écrite conforme à l’article L131-3, vous ne possédez pas le code. Le même piège vous attend d’ailleurs avec le nouveau prestataire : exigez une clause de cession explicite dès la signature.
Rompre avant d’avoir récupéré. L’ordre compte : inventaire, récupération des accès, transfert des comptes stores, quelques heures de passation si l’ancien prestataire est joignable, puis seulement fin de la relation.
Si vous répondez non à l’une de ces questions, ne signez rien avant d’avoir la réponse. Une reprise bien préparée coûte quelques semaines de méthode, alors qu’une reprise improvisée peut coûter l’application. Notre agence de développement d’applications mobiles accompagne ces transitions, de l’audit à la maintenance.
Votre prestataire ne répond plus, ou votre application vous échappe ? Contactez-nous pour un échange gratuit et sans engagement : nous vous dirons franchement si elle mérite d’être reprise, et à quel prix. 👉 playmoweb.com/nous-contacter