Reprendre une application abandonnée ou bloquée par un autre prestataire : la méthode complète

Les signes qu'une application doit être reprise

Une application se retrouve souvent orpheline sans que personne ne l'ait décidé. Le prestataire ne répond plus, l'agence a fermé, le développeur interne est parti ou le projet s'est arrêté à mi-chemin. Le dirigeant se retrouve avec un produit qui a coûté cher et qu'il ne peut plus faire évoluer.

Les signaux d'alerte les plus fréquents :

• Personne dans l'entreprise ne sait où se trouve le code source à jour.
• L'application n'est pas publiée, ou elle a été retirée des stores après un refus de mise à jour.
• Les comptes Apple, Google, d'hébergement ou de base de données sont au nom du prestataire.
• Chaque petite modification prend des semaines ou casse autre chose.
• Des utilisateurs signalent des bugs de connexion, de paiement ou de notifications.
• Vous ignorez qui peut lire les données de vos clients.

Si vous cochez deux de ces lignes, la reprise doit commencer par un état des lieux, avant toute promesse de nouvelle fonctionnalité.

Étape 1 : récupérer tous les accès à votre nom

La première étape n'a rien de technique. Il s'agit de reprendre le contrôle de ce qui vous appartient. Sans ces accès, aucun prestataire sérieux ne peut garantir la suite.

La check-list des accès

• Le dépôt du code source (GitHub, GitLab ou autre), avec l'historique complet.
• Le compte Apple Developer et la console Google Play, ouverts au nom de votre entreprise.
• Le service de build, par exemple Expo et EAS pour une application React Native.
• La base de données et l'authentification : Supabase, Firebase ou serveur dédié.
• L'hébergement de l'API et du back-office, et le nom de domaine.
• Les clés des services tiers : paiement, notifications push, envoi d'emails, cartes, IA.

Pourquoi les comptes stores doivent être à votre nom

Une application publiée sous le compte d'un prestataire lui appartient aux yeux d'Apple et de Google. Le transfert est possible, mais il demande sa coopération. Ouvrez vos propres comptes développeur au nom de la société et faites publier les futures versions dessus. Relisez aussi votre contrat : la cession des droits sur le code et les livrables doit y figurer.

Étape 2 : l'audit du code, de la sécurité et des dépendances

Une fois les accès en main, l'audit répond à une seule question : peut-on bâtir sur cette base ? Il couvre trois volets.

Le code et la capacité à le reconstruire

Le développeur vérifie que le projet se compile à partir du dépôt, sans fichier caché sur le poste de l'ancien prestataire. Il regarde l'organisation du code, les doublons, les parties mortes et la présence ou non de tests.

La sécurité

C'est le volet le plus souvent négligé. On contrôle les règles d'accès à la base de données, les clés secrètes présentes dans l'application, l'authentification, les droits des différents rôles et le stockage des fichiers. Apple exige aussi qu'un utilisateur puisse supprimer son compte depuis l'application. Le détail des contrôles figure dans notre guide pour sécuriser une application générée par IA, qui s'applique à toute application.

Les dépendances

Une application qui n'a pas bougé depuis longtemps accumule des bibliothèques obsolètes. Les stores imposent régulièrement des versions minimales de SDK. Une montée de version peut être simple ou casser une partie de l'application : l'audit le chiffre avant que vous ne vous engagiez.

Corriger, moderniser ou reconstruire : comment décider

L'audit débouche sur l'une de ces trois voies, souvent combinées par module :

1. Corriger quand la base est saine : on ferme les failles, on répare les bugs, on publie.
2. Moderniser quand la structure tient mais que les dépendances ou certaines briques sont dépassées.
3. Reconstruire une partie quand un module est irrécupérable, par exemple un back-office sans contrôle d'accès ou un paiement mal intégré.

Les critères qui pèsent dans la décision : la gravité des failles, la qualité du modèle de données, le coût d'une montée de version, et ce que vos utilisateurs utilisent réellement. Une reconstruction totale se justifie rarement quand les données et les écrans principaux sont exploitables.

Le cas Style224 : de l'application bloquée à l'App Store

Style224 est une application de réservation beauté. Elle existait déjà, mais elle n'était ni sécurisée ni publiée sur les stores. Ascendia a d'abord mené un audit de sécurité et corrigé 8 failles critiques.

Le travail a ensuite porté sur ce qui manquait pour une mise en ligne sérieuse : notifications push, tri des prestataires par distance, messagerie, suppression de compte, mise en ligne du serveur et version web. L'application a été approuvée sur l'App Store, disponible dans 148 pays, et publiée sous le compte du client. Le détail est sur la page Style224, application reprise et publiée.

La même logique s'applique à un site : un site d'actualité piraté chaque semaine a été migré de Joomla vers Webflow après un audit de sécurité du contenu importé.

Les erreurs à éviter lors d'une reprise

• Ajouter des fonctionnalités avant l'audit. Chaque nouvel écran construit sur une base fragile augmente la facture de la correction.
• Accepter une publication sous le compte du nouveau prestataire. Vous reproduiriez le blocage d'origine.
• Oublier les données. Une sauvegarde complète de la base doit exister avant le premier changement.
• Négliger les utilisateurs actuels. Une mise à jour qui déconnecte tout le monde ou perd des réservations coûte de la confiance.
• Tout réécrire par principe. Le code existant contient souvent des règles métier que personne n'a documentées.
• Repartir sans maintenance. Une application non suivie redevient orpheline à la prochaine exigence des stores.

Combien coûte une reprise et comment se passe la suite

Le prix d'une reprise dépend entièrement de l'état du code, que personne ne connaît avant l'audit. Chez Ascendia, la reprise est donc sur devis, après un audit et une démo gratuits. Le calendrier est fixé à ce moment-là, par étapes validées. La maintenance qui suit va de 50 € à 300 € par mois selon le périmètre : mises à jour des dépendances, suivi des exigences des stores, corrections.

Pour situer les ordres de grandeur d'un projet complet, lisez combien coûte une application mobile, et découvrez notre offre de création d'application mobile ou de logiciel sur mesure si votre outil est une application web.

Votre application est bloquée chez un ancien prestataire ? Demandez votre audit gratuit : nous faisons l'état des lieux des accès, du code et de la sécurité, et vous dites quoi faire en premier.