Reprendre un projet mobile abandonné : l'audit avant le devis

Réponse courte

Pour reprendre un projet d'application mobile abandonné, commence par obtenir le dépôt de code, les accès au backend et aux stores, puis fais auditer le produit avant de demander un prix de reprise. Le brief prévoit un audit de cinq à dix jours, avec une enveloppe indicative de 3 000 à 5 000 € HT. Le résultat doit comparer deux scénarios : conserver le code exploitable ou reconstruire les parties fragiles. Un forfait signé avant cette lecture repose sur des hypothèses invisibles. Si le dépôt n'est pas accessible, la première mission consiste à récupérer les actifs du projet, pas à promettre une date de livraison.

Un projet bloqué n'est pas forcément un code perdu

Un prestataire qui s'arrête laisse parfois une application propre et mal transmise. Ailleurs, les écrans semblent avancés mais la connexion, les données ou la publication n'ont jamais été terminées. Le degré de finition visuelle ne dit presque rien sur l'effort restant. Une vidéo de démonstration ne remplace ni un build reproductible ni un accès aux environnements.

Demande d'abord une chronologie simple : qui a développé quoi, quelle version a été testée sur téléphone, quels bugs sont connus et quels paiements ont déjà été faits ? Rassemble ensuite les livrables promis au contrat. Le premier obstacle est souvent administratif : dépôt Git au nom de l'ancien prestataire, base Supabase sur son compte, certificats de signature inconnus. Notre article sur la propriété du code d'une application mobile détaille les questions à poser.

Ne confonds pas « le code existe » et « l'entreprise peut le faire évoluer ». Sans accès aux services et sans moyens de produire une nouvelle version, le dépôt seul ne suffit pas. À l'inverse, un projet peu documenté peut rester récupérable si le code démarre, les données sont intactes et le parcours principal fonctionne.

Les huit points que l'audit doit couvrir

Un bon audit aboutit à des preuves, pas à une note vague. Il commence par l'accès : dépôt, historique, branches, licences et comptes détenus par le client. Il vérifie ensuite si un autre développeur peut installer le projet et produire un build à partir d'instructions écrites.

Les six autres points sont la stack et ses dépendances, le backend et les données, la qualité du code, les tests, la sécurité, puis la publication. Pour chaque point, demande un constat, son impact et une action proposée. « Dépendances anciennes » est trop imprécis ; il faut savoir lesquelles bloquent une mise à jour ou la publication. « Pas de tests » n'est pas un verdict suffisant si le parcours critique peut être couvert avant la reprise.

Point	Preuve attendue
Accès	Dépôt et comptes consultables par le propriétaire du produit
Documentation	Installation et build reproductibles
Stack	Versions, dépendances à risque et effort de mise à jour
Backend	Schéma, sauvegardes, API et droits d'accès
Code	Parcours métier traçable et composants compréhensibles
Tests	Ce qui est couvert et ce qui doit l'être avant livraison
Sécurité	Secrets, authentification et permissions revus
Stores	Identifiants, signatures et capacité de publier une mise à jour

Une capture d'écran ne prouve pas qu'une app se construit encore. L'auditeur doit lancer le projet, examiner un parcours complet et noter tout prérequis manquant. Le cadrage mobile servira ensuite à convertir ces constats en périmètre de reprise.

Reprendre ou recommencer : la décision économique

Le bon critère n'est pas le montant déjà dépensé. Cet argent ne revient pas. Compare le coût restant pour rendre l'app publiable avec celui d'une reconstruction ciblée, en incluant les risques de maintenance après sortie. Une base de données saine et un backend lisible peuvent valoir la peine d'être conservés même si le client mobile doit être refait. Un pack Care (290 €, 590 € ou 1 190 € par mois selon le niveau) prend ensuite le relais pour les mises à jour OS, les corrections et la supervision continue.

Je garderais le code si le parcours principal fonctionne, que le projet se construit, que les dépendances sont maintenues et que les accès appartiennent au porteur du produit. Je proposerais une reconstruction ciblée si chaque correction casse une autre zone, si les secrets sont dispersés ou si personne ne peut expliquer les données. L'audit doit dire quels modules survivent, lesquels partent et pourquoi.

Évite le faux dilemme « tout garder ou tout jeter ». Il est souvent possible de conserver le schéma de données et les intégrations stables, tout en reconstruisant les écrans et le flux de connexion. Le rapport doit chiffrer ces variantes sur le même périmètre fonctionnel. Sans cette comparaison, une recommandation de « tout refaire » peut surtout refléter la préférence du nouveau prestataire.

Les comptes stores changent la stratégie

Une app déjà publiée possède une fiche, des avis, un identifiant et parfois des abonnements. Il faut savoir qui détient le compte développeur avant d'annoncer que la reprise sera une simple mise à jour. Apple décrit un transfert officiel qui conserve la disponibilité, les notes et les avis. Google décrit aussi le transfert d'app entre comptes développeur. Ces procédures ont des conditions à vérifier selon l'app.

Si le compte initial est inaccessible, le plan peut demander une nouvelle publication. Cela change le calendrier, la communication et parfois la continuité des abonnements. L'audit doit donc examiner les signatures, les identifiants, les comptes de paiement et les accès aux notifications. Une app non publiée évite certains problèmes de transfert, mais elle a encore besoin d'un compte client pour la première sortie.

Chez Inyka, le code d'un nouveau projet va dans le dépôt du client dès le premier jour. Pour une reprise, le premier objectif est de rétablir cette maîtrise : accès du propriétaire, inventaire des secrets et capacité de produire un build sans dépendre de l'ancien prestataire.

Quel prix demander, et quand ?

Le brief propose 3 000 à 5 000 € HT comme enveloppe de cadrage pour cinq à dix jours d'audit. Cette fourchette sert à comparer des propositions ; elle ne constitue pas un tarif fixe Inyka publié. Le devis doit préciser le périmètre inspecté, les accès nécessaires, les vérifications réellement exécutées et la forme du rapport. Pour un projet sans dépôt ni accès aux services, une mission de récupération peut précéder l'audit technique.

Après le rapport, demande deux estimations sur les mêmes fonctionnalités : reprise du code exploitable et reconstruction ciblée. Chaque estimation doit prévoir tests, corrections, publication et remise des accès. Le guide des prix d'applications mobiles donne un repère pour comparer cette somme à un nouveau développement.

Un prix fixe peut être pertinent une fois les inconnues levées. Avant l'audit, mieux vaut un périmètre borné de diagnostic qu'un forfait de « sauvetage » rempli d'exclusions. Aucun studio sérieux ne sait promettre combien de jours il reste à un projet qu'il n'a pas ouvert.

Ce qu'Inyka peut reprendre

Inyka intervient sur des applications mobiles React Native et Expo, avec leur backend et un éventuel back-office attaché. La première phase vérifie le code, les données et la publication. Si une partie de l'app doit être reconstruite, un devis fixe peut suivre une fois le périmètre établi. Le dépôt et les accès sont remis au propriétaire du produit.

Nous ne vendons pas de reprise complète d'une application iOS native complexe en Swift ou d'un système relevant de la santé certifiée, de la banque ou de l'assurance. Dans ces situations, un diagnostic limité peut aider à documenter le problème, mais il ne devient pas une promesse de développement hors périmètre.

Le rapport doit rester utile même si le porteur de projet choisit un autre prestataire. Il doit contenir les constats vérifiables, les risques, les actions prioritaires et la comparaison économique. C'est ce qui distingue un audit d'une simple étape commerciale.

Cinq erreurs fréquentes avant la reprise

Payer une refonte avant de récupérer les accès. Le nouveau studio ne peut pas publier une mise à jour ni mesurer l'état du backend. Commence par demander la restitution contractuelle des dépôts, comptes et données, puis fais consigner ce qui reste inaccessible.

Confondre ancienneté et inutilisabilité. Une dépendance ancienne peut parfois être mise à jour sans refaire l'app. À l'inverse, un dépôt récent peut cacher un flux de paiement fragile. L'audit doit estimer l'effort de correction sur des parcours réels.

Lire seulement l'écran d'accueil. Les problèmes surgissent souvent à la récupération de compte, à la synchronisation ou au refus d'un paiement. Exige au moins un parcours complet, depuis une installation propre jusqu'à l'action principale.

Faire de la documentation le seul verdict. Un README absent ralentit la reprise, mais ne rend pas forcément le code mauvais. Demande une démonstration du build et des données, puis chiffre le travail de documentation manquante.

Reporter la sécurité après la sortie. Des clés visibles dans le dépôt ou des comptes partagés continuent de poser problème même si l'interface fonctionne. L'audit doit prévoir la rotation des accès et un propriétaire pour chaque secret avant une nouvelle publication.

Ce qu'Inyka refuse sur un projet abandonné

Un forfait de reprise de tout le produit après une seule démonstration. La démonstration montre le résultat apparent, pas l'état du code, des données et des comptes.
Une mission ouverte sans livrable ni limite de diagnostic. L'audit doit déboucher sur un rapport et une décision, même si cette décision est de reconstruire.
La conservation de chaque ligne déjà payée pour « rentabiliser » l'ancien budget. Le coût passé n'améliore pas la qualité du code restant.
La prise en charge complète d'un projet natif pur complexe ou d'un produit relevant des exclusions réglementées d'Inyka. Le périmètre mobile React Native doit rester explicite.

Checklist de transmission à demander à l'ancien prestataire

Un dossier de reprise peut être préparé avant même de choisir un auditeur. Demande une réponse écrite pour chaque élément :

Adresse du dépôt Git, droits d'administration et branches de publication.
Dernier build installable et version réellement soumise aux stores.
Liste des services externes, avec le propriétaire de chaque compte.
Documentation des environnements de développement, test et production.
Schéma de la base, sauvegarde récente et procédure de restauration.
Emplacement des secrets, certificats et clés de signature, transmis par un canal sûr.
Liste des bugs connus et des fonctions restées inachevées.
Accès aux comptes Apple et Google ou procédure de transfert engagée.
Historique des paiements, abonnements ou achats intégrés si l'app en utilise.
Factures, contrats et clauses de propriété ou de licence des composants.

Si une pièce manque, note son absence au lieu de la remplacer par une supposition. Une archive de code sans historique, par exemple, autorise peut-être un build mais prive l'auditeur des raisons derrière certains changements. Le rapport doit alors distinguer ce qui est vérifié, ce qui est probable et ce qui reste impossible à conclure.

FAQ

Peut-on auditer une app sans accès au dépôt ? On peut examiner le produit visible et les contrats, mais pas juger sérieusement la qualité du code. Il faut d'abord récupérer le dépôt ou constater par écrit qu'il est perdu.

Un audit oblige-t-il à confier la reprise au même studio ? Non. Demande un rapport exploitable et la liste des accès au nom du client. Un autre studio doit pouvoir refaire les contrôles et discuter la recommandation.

Combien de temps prend la décision reprise ou reconstruction ? Le brief prévoit cinq à dix jours pour un audit avec les accès disponibles. La récupération d'un compte ou de secrets manquants peut rallonger ce délai.

Que faire des accès encore détenus par l'ancien prestataire ? Dresse une liste des comptes et des personnes autorisées, puis demande un transfert ou une délégation officielle. Après récupération, renouvelle les secrets qui ont été partagés inutilement.

Faut-il payer de nouveau pour des fonctions déjà développées ? Seulement si elles doivent être corrigées ou reconstruites. Le rapport doit distinguer le travail conservé du travail à refaire, sans se laisser guider par le montant historique du projet.

Le rapport doit-il contenir un devis détaillé ? Il doit au moins donner les scénarios, leurs hypothèses et les travaux prioritaires. Le devis ferme vient ensuite, quand le périmètre retenu et les accès sont connus.

Comment traiter les données d'une app encore utilisée ? Travaille d'abord sur une copie contrôlée et documente la sauvegarde. Les corrections sur la production demandent un responsable, un créneau et un retour arrière.

Puis-je changer de prestataire si l'ancien contrat n'est pas terminé ? La question dépend des clauses signées. Rassemble le contrat, les livrables et les accès pour obtenir un avis juridique si nécessaire, sans demander au nouveau studio de trancher un litige contractuel.

Faire lire le projet avant de signer

Si ton application est bloquée, rassemble le dépôt, les accès et le dernier build, puis présente le projet à Inyka pour cadrer son audit. La première décision à acheter est « reprendre quoi ? », pas un nouveau calendrier promis à l'aveugle.

Réserver un appel découverte de 30 minutes pour présenter les actifs disponibles et les accès manquants.