Refonte d'application ratée : que faire maintenant ?

Quand une refonte d'application a échoué (budget dépassé, app instable, refus des stores, prestataire injoignable), il ne faut ni relancer tout de suite un nouveau développement, ni abandonner l'app. La bonne séquence tient en trois étapes : récupérer les accès et le code, faire auditer l'application par un tiers indépendant, puis décider s'il faut la sauver, la refaire en partie ou la refaire entièrement. Les 48 premières heures servent surtout à sécuriser ce qui vous appartient.

Comment savoir dans quelle situation se trouve votre application ?

Une refonte d'application ratée se reconnaît à ses symptômes, et chaque symptôme appelle une première action différente.

Plusieurs lignes s'appliquent souvent à la fois. Pour les blocages des stores, voyez le blocage Google Play lié au niveau d'API cible et le refus Apple 4.2.

Que faire dans les 48 premières heures après un projet raté ?

Dans les 48 premières heures, l'objectif n'est pas de réparer l'app mais de reprendre le contrôle : vérifier que chaque accès critique est à votre nom. Tant que le code ou les comptes dépendent d'une seule personne extérieure, toute décision reste fragile.

Le code source

Le code source est le texte qui fait fonctionner votre application : sans lui, aucune correction ni mise à jour n'est possible. Demandez un accès propriétaire au dépôt plutôt qu'une archive, car l'historique aide à comprendre ce qui a été fait. Sur GitHub, selon la documentation officielle, le transfert d'un dépôt conserve l'historique, les tickets et les demandes de modification.

Les comptes App Store et Google Play

Chez Apple, le titulaire du compte, l'Account Holder, est selon la documentation Apple la personne qui renouvelle l'adhésion et accepte les accords juridiques au nom de l'organisation. Si c'est votre prestataire, il a la main sur votre app.

Si l'app est publiée sur le compte du prestataire, un transfert est possible, mais exige sa coopération. Selon l'aide App Store Connect, l'Account Holder d'origine lance le transfert, celui du compte destinataire l'accepte, et l'app conserve ses avis et notes. Chez Google, selon l'aide Play Console, le propriétaire du compte d'origine fait la demande, le compte cible l'approuve, et utilisateurs, notes et avis suivent l'app.

La clé de signature Android

Une app Android est signée avec une clé numérique qui prouve à Google que la mise à jour vient bien de vous. Selon l'aide Play Console, avec Play App Signing, Google peut réinitialiser une clé d'importation perdue ; une clé de signature gérée soi-même et perdue, en revanche, ne peut pas l'être. Sans Play App Signing, récupérer ce fichier et son mot de passe est une urgence.

Domaines, serveurs et services tiers

Un domaine au nom du prestataire ou un serveur payé par sa carte peuvent couper votre app du jour au lendemain. Demandez aussi la liste des clés d'API (les codes qui permettent à l'app de parler à un service) : elles se cachent souvent hors du dépôt.

Contrats et propriété du code

Avoir payé une application ne signifie pas en posséder les droits. Selon Bpifrance Création, sans contrat de cession explicite, le prestataire reste propriétaire du code livré. L'article L131-3 du Code de la propriété intellectuelle exige que chaque droit cédé soit mentionné distinctement et délimité ; l'attribution automatique prévue par l'article L113-9 ne concerne que les salariés. Cherchez la clause de cession dans votre contrat et, si elle est absente ou floue, consultez un avocat avant d'engager de gros travaux. Cet article ne constitue pas un avis juridique.

Que faire si le prestataire a abandonné l'application ?

Reprendre une application abandonnée par son prestataire reste possible dans la plupart des cas, à condition de récupérer d'abord le code source et les comptes de publication. Sans code source, l'app ne peut plus être mise à jour : il faut l'obtenir ou repartir sur une nouvelle app.

Si les comptes sont à vous mais que le code manque, la situation est sérieuse mais gérable ; si tout est chez le prestataire, elle devient en partie juridique. Une fois le code récupéré, le vrai test est simple : un nouveau développeur doit réussir à recompiler et publier l'app depuis sa propre machine.

Pourquoi faire un audit indépendant avant de dépenser plus ?

Un audit indépendant avant toute nouvelle dépense évite de refinancer un projet sans savoir ce qui ne va pas. Sans avoir lu le code, aucun prestataire ne peut sérieusement chiffrer une reprise.

L'audit de récupération, aussi appelé audit d'urgence, sépare les faits du ressenti : il dit ce qui fonctionne, ce qui est fragile et ce qui manque, et vous permet de comparer des propositions sur une base commune. Exigez un rapport utilisable par n'importe quelle équipe. C'est mon avis de praticien : quelques jours d'audit coûtent bien moins cher que quelques semaines de développement dans la mauvaise direction.

Que vérifie un audit de récupération d'application ?

Un audit de récupération vérifie que vous pouvez reprendre l'application en main, mesure son état réel et chiffre les options. Il couvre en général :

1. Les accès : sont-ils tous disponibles et à votre nom ?
2. La publication : l'app peut-elle être recompilée et envoyée sur les stores à partir du dépôt ?
3. Les versions et dépendances : le framework (React Native, Expo, Capacitor…) et les bibliothèques sont-ils maintenus et compatibles avec les exigences actuelles d'Apple et de Google ?
4. La stabilité : quels écrans plantent, sur quels appareils ?
5. La sécurité : des clés secrètes sont-elles exposées, les données des utilisateurs protégées ?
6. La lisibilité, les tests et la documentation : un nouveau développeur peut-il modifier le code sans tout casser ?

Le livrable doit être lisible par un non-technicien : une synthèse, des risques classés par priorité et une recommandation chiffrée. C'est le périmètre de notre Audit de reprise d'application, à 1 500€ HT en 5 jours ouvrés.

Comment reconnaître une application mal construite ?

Une application mal construite se reconnaît à ses effets : chaque correction en provoque une autre et personne n'explique simplement comment elle fonctionne. Les signaux qui doivent alerter :

• une petite modification demande toujours plusieurs jours ;
• les mêmes bugs reviennent après avoir été « corrigés » ;
• un seul développeur sait publier l'app ;
• l'app repose sur des versions anciennes que personne n'ose mettre à jour.

Pris ensemble, ces signes indiquent que la dette technique, l'accumulation de raccourcis à rembourser plus tard, freine déjà votre produit. Pour un diagnostic plus complet, voyez les 10 signes d'une application mobile mal construite.

Faut-il sauver l'application ou la refaire ?

Le choix entre sauver, refaire en partie ou refaire une application dépend de l'état réel du code, de ce que vous avez pu récupérer et de l'écart avec vos besoins. Il se décide après l'audit, jamais sur une impression.

Refaire n'est pas forcément le plus sûr : une reconstruction doit retrouver toutes les règles métier de l'ancienne app, souvent non documentées. Nous détaillons les critères de choix dans Refaire son application de zéro ou la sauver ?

Que faire après une migration d'application ratée ?

Après une migration ratée, la première question est de savoir quelle version tourne réellement en production et si vous pouvez encore la mettre à jour. Les cas les plus fréquents :

• Montée de version React Native ou Expo restée à mi-chemin, souvent autour du passage à la New Architecture, devenue obligatoire.
• Migration Cordova ou Ionic vers Capacitor inachevée, avec des plugins non remplacés.
• Sortie du no-code incomplète, où des règles métier ou des données manquent (voir notre guide pour quitter Bubble).

Gardez l'ancienne version en état de marche tant que la nouvelle n'est pas validée, et faites auditer le chemin restant avant de relancer les travaux. Pour React Native, notre guide Migration React Native qui a mal tourné détaille le plan de rattrapage.

Se faire accompagner après une refonte ou une migration ratée

L'Audit de reprise d'application de GUIGUI Tech est l'audit de récupération décrit plus haut : 1 500€ HT, livré en 5 jours ouvrés, pour une app React Native, Expo, Capacitor, Ionic ou Cordova, une application web React, Next.js ou Vue.js, ou du code généré avec Lovable ou Bolt. Il comprend la check-list de récupération des accès, la revue du code et de l'architecture, une vérification rapide de la sécurité, l'état des dépendances et de la conformité aux stores, un verdict (sauver, reprendre en partie ou refaire) avec un plan chiffré et priorisé, un rapport PDF et un appel de restitution d'une heure. Il est déduit du prix final si vous confirmez les travaux dans les 30 jours.

Selon le verdict, la suite peut être une mise en conformité Google Play et App Store (à partir de 2 500€ HT, 1 à 3 semaines) si l'urgence est un blocage des stores, une mise à jour Expo SDK et New Architecture (à partir de 6 500€ HT, 2 à 4 semaines) ou une migration React Native complète (à partir de 18 000€ HT, 4 à 8 semaines) pour une app React Native restée sur une ancienne version, ou une migration vers Capacitor (à partir de 9 500€ HT) pour une app Cordova ou Ionic. Si votre app React Native fonctionne et doit seulement monter de version, l'Audit Migration React Native, au même prix, suffit. Pour une app Bubble, Adalo ou FlutterFlow, l'offre Sortir du no-code commence par un audit de faisabilité à 800€ HT en 2 jours.