Reprendre une application mobile qui ne marche pas : corriger, finir ou refaire ?

Reprendre une application mobile, c'est la corriger, la finir ou la refaire quand elle a déjà été développée mais ne fonctionne pas : buguée, jamais publiée, abandonnée par son développeur, ou trop mal codée pour continuer dessus. Ce guide explique comment évaluer une application existante, ce qu'il faut récupérer avant de payer qui que ce soit, et combien ça coûte réellement.

Ce que « reprendre une application mobile » veut dire

La reprise d'une application mobile, ce n'est pas repartir de zéro. C'est prendre une application qui existe déjà (publiée ou non, codée par un freelance, une agence ou un développeur qui a disparu) et la remettre dans un état qui fonctionne : corrigée, finie, publiée, maintenable.

Trois précisions utiles pour ne pas se tromper de sujet :

• Ce n'est pas un audit de sécurité. Une recherche sur « audit application mobile » ramène surtout des offres de pentest (recherche de failles de sécurité). La reprise, c'est un diagnostic fonctionnel et technique de l'existant, pas un test d'intrusion.
• Ce n'est pas forcément une refonte complète. Refaire l'application entière n'est qu'une des trois issues possibles. La plupart du temps, une partie du travail existant est récupérable.
• Ce n'est pas réservé aux applications catastrophiques. Une application avec un ou deux bugs bloquants, jamais publiée par manque de temps du développeur, ou juste jamais finalisée, relève aussi de la reprise.

Les 5 situations qui mènent à une reprise

En pratique, une reprise part presque toujours de l'une de ces cinq situations.

Votre application est pleine de bugs

Elle a été livrée, mais elle plante à la connexion, au paiement, sur Android, sur iOS, ou sur les deux. Chaque correction en fait apparaître d'autres. Le premier réflexe utile est de la tester comme un utilisateur, pas de lire le code, pour lister précisément ce qui casse. Voir : dette technique d'une application mobile.

Votre application n'a jamais été publiée

Développement payé, application « presque prête » depuis des mois, jamais soumise à l'App Store ou au Play Store, ou soumise puis refusée sans que personne ne s'en occupe ensuite.

Votre développeur a disparu

Il ne répond plus, ou une fois par mois. Vous ne savez pas précisément ce que vous possédez : le code, les comptes, les accès. Voir : développeur disparu, comment récupérer votre application.

Le code est illisible, personne ne veut le reprendre

Plusieurs développeurs ont regardé et ont tous répondu « il faut tout refaire ». C'est parfois vrai, parfois exagéré : la seule façon de savoir est de regarder, pas de deviner.

Apple ou Google ont refusé votre application

Un refus dans le Resolution Center, et le prestataire d'origine ne répond plus pour le corriger. Voir : application refusée par l'App Store, comment rebondir.

Avant tout : ce que vous devez récupérer

Avant même de penser au prix ou au planning, une règle simple évite la plupart des mauvaises surprises : ne jamais payer une dernière tranche « pour débloquer » un accès qui devrait déjà être à vous. Quatre éléments à vérifier en premier :

1. Le code source : sur un repository (GitHub, GitLab...) auquel vous avez un accès administrateur, à votre nom.
2. Les comptes Apple Developer et Google Play : au nom de votre entreprise, pas à celui du prestataire.
3. La base de données et le backend : savoir où sont hébergées les données de vos utilisateurs et qui peut y accéder.
4. Les outils tiers (paiement, emailing, notifications, analytics) : chaque compte doit être identifiable et transférable.

Le détail complet, avec ce que dit la loi quand rien n'a été écrit dans le contrat, est dans l'article sur la propriété du code source. Le guide gratuit reprend cette checklist en 10 minutes de lecture.

Comment évaluer une application qu'on vous confie

L'ordre compte. Chez Zuhd Studio, l'évaluation se fait toujours dans le même sens : d'abord l'usage, ensuite le code.

Étape 1, tester comme un utilisateur. Avant d'ouvrir la moindre ligne de code, l'application est testée comme le ferait quelqu'un qui la découvre : inscription, connexion, action principale, paiement si applicable, comportement hors-ligne, sur au moins deux appareils. C'est ce test qui sert de base au devis, pas la lecture du code.

Étape 2, lire le code après signature. Une fois le devis signé et le code transmis, l'architecture est examinée pour six signaux simples : présence de tests, documentation minimale (README), cohérence de l'architecture, absence de secrets codés en dur, historique Git exploitable, dépendances à jour ou non. Ce diagnostic ne change ni le prix ni le délai déjà signés : il détermine seulement si l'application se corrige ou se refait.

Garder, corriger ou refaire : la grille de décision

Trois issues possibles, selon ce que révèle le diagnostic :

• Garder et corriger : le code est structuré, les bugs sont localisés, la base est saine. C'est le cas le plus rapide.
• Finir : le code est correct mais incomplet (fonctionnalités manquantes, jamais publié, intégrations non terminées).
• Refaire en Flutter : le code est absent, illisible, ou construit sur un outil no-code qui ne s'exporte pas. Repartir sur une base saine est alors plus rapide que réparer.

Ce que cette décision ne change pas, chez Zuhd Studio : ni le prix, ni le délai. Les deux sont fixés après le test fonctionnel (étape 1), avant la lecture du code : la décision garder/corriger/refaire est ensuite une question technique, pas commerciale.

Combien coûte une reprise d'application mobile

Sur le marché, une reprise se facture généralement soit au temps passé (TJM), soit au forfait après un audit préalable, souvent payant. Chez Zuhd Studio, le prix est fixe et connu avant de signer : 9 500 €, payable en 3 fois (40 % à la signature, 30 % à la validation du design, 30 % à la validation du développement), quel que soit l'état du code trouvé après signature. Le détail des fourchettes de marché et de ce qui fait varier un devis est développé dans combien coûte la reprise d'une application mobile.

Combien de temps ça prend

Chez Zuhd Studio, une reprise prend 60 jours ouvrés, écrits au contrat, soit environ 12 semaines. Ce qui rallonge un délai, en général : des accès manquants à récupérer avant de commencer, des retours client tardifs sur le design ou les tests de fonctionnalités, et le temps de review d'Apple et Google au moment de la soumission (généralement 1 à 3 jours, parfois plus en cas de rejet à corriger).

Comment se passe une reprise chez Zuhd Studio

1. Semaine 1 : Audit et plan de sauvetage. Test fonctionnel de l'application, récupération des accès, décision de ce qui se garde, se corrige ou se refait.
2. Semaines 2 à 4 : Design. Maquettes Figma, 5 allers-retours inclus, validées avant la moindre ligne de code.
3. Semaines 5 à 11 : Développement. Chaque fonctionnalité est envoyée en vidéo ou accès direct pour validation avant de passer à la suivante.
4. Semaine 12 : Déploiement. Soumission App Store et Play Store, gestion des révisions, mise en ligne, transfert complet du code et des comptes.

À qui confier la reprise

Freelance, agence ou studio solo : chacun a un profil de risque différent (prix, disponibilité, nombre d'interlocuteurs). Le comparatif complet est dans freelance, agence ou studio, qui choisir. Chez Zuhd Studio, c'est une seule personne, du premier appel à la publication : pas d'agence, pas de plateforme de mise en relation.

Questions fréquentes

Pouvez-vous reprendre sans le code source ?
Oui, dans la plupart des cas. On repart de ce qui est récupérable (comptes, données, version publiée ou installée) et l'application est refaite en Flutter si le code n'est pas récupérable, au même prix fixe.

Et si je décide de tout arrêter après le diagnostic ?
Le test initial ne coûte rien et n'engage à rien. Le devis n'est signé que si vous décidez de continuer.

Le prix peut-il augmenter en cours de route ?
Non pour le périmètre signé. Seule une fonctionnalité en plus, hors devis initial, est chiffrée et facturée à part.