Reprendre une application abandonnée par son prestataire

Le scénario est fréquent : l’application a été livrée, elle sert, puis le prestataire disparaît. Il a fermé, changé de métier, ou ne répond plus. Rien ne casse le premier mois. Puis un utilisateur signale un bug, Apple ou Google annonce une nouvelle exigence, un service tiers change ses conditions, et l’entreprise découvre qu’elle ne sait ni où est le code ni qui détient les comptes.

La bonne nouvelle : une application abandonnée se reprend presque toujours. La condition : procéder dans le bon ordre.

Ce qui fait exister une application

Avant de parler de code, il faut faire l’inventaire de tout ce dont l’application a besoin pour tourner. La liste est plus longue qu’on ne le pense.

• Le code source, et surtout son dépôt complet, avec l’historique des modifications et la façon de le construire.
• Les comptes développeur Apple et Google, qui détiennent la fiche, les avis et les utilisateurs de l’application, comme l’explique publier sous son propre compte développeur.
• L’hébergement et la base de données, avec leurs sauvegardes.
• Le nom de domaine et la configuration DNS.
• Les services branchés : envoi d’e-mails, notifications, paiement, cartes, analyse d’audience, chacun avec son compte et sa facture.
• Les clés et secrets qui relient tout cela, et qu’il faudra changer.

Pour chaque ligne, une seule question : est-ce à votre nom, ou à celui du prestataire ?

Ce qui vous appartient vraiment

C’est souvent la surprise. En France, l’article L113-9 du Code de la propriété intellectuelle attribue à l’employeur les droits sur les logiciels créés par ses salariés dans l’exercice de leurs fonctions. Cette dévolution automatique ne concerne pas les logiciels développés par des consultants ou des prestataires, rappelle l’avocate Garance Mathias dans un dossier consacré aux droits sur le logiciel. Pour le code d’un prestataire, c’est donc le contrat qui organise la cession des droits.

Les comptes se récupèrent mieux qu’on ne le croit, à condition que leur titulaire coopère. Apple prévoit le transfert d’une application vers un autre compte : pendant et après le transfert, l’application garde ses avis et ses notes, et les utilisateurs continuent de recevoir les mises à jour, selon l’aide d’App Store Connect. Google Play transfère de même les utilisateurs, les statistiques de téléchargement, les notes et les avis vers le nouveau compte, après une vérification de son équipe, d’après l’aide de la Play Console. Si le titulaire a disparu pour de bon, il reste souvent à republier l’application sous un nouveau compte, en repartant de zéro sur les avis.

Les échéances qui n’attendent pas

Une application qui tourne n’est pas une application qu’on peut mettre à jour. Apple et Google relèvent régulièrement leurs exigences, et une application qu’on ne sait plus reconstruire avec les outils récents finit bloquée.

1. 28 avril 2026

   Les applications envoyées à Apple doivent être construites avec Xcode 26 et le kit de développement d’iOS 26, selon la page des exigences d’Apple.

2. 31 août 2026

   Sur Google Play, les nouvelles applications et les mises à jour doivent cibler Android 16, et une application existante qui ne cible pas au moins Android 15 cesse d’être proposée aux nouveaux utilisateurs des versions récentes d’Android, d’après l’aide de la Play Console.

3. 1er novembre 2026

   Fin de la prolongation que Google accorde sur demande aux applications qui ont besoin de plus de temps.

Concrètement, la première mise à jour d’une application abandonnée depuis un an ou deux n’est presque jamais une petite correction : c’est une remise à niveau des outils et des bibliothèques. Mieux vaut le savoir avant de promettre un correctif pour la semaine suivante. C’est l’un des postes décrits dans le budget de maintenance d’une application.

Reprendre sans tout casser

Nous appliquons à une application les trois règles de notre méthode de reprise d’actifs numériques : mesurer avant de toucher, sécuriser avant d’améliorer, réduire le périmètre avant de travailler dessus.

1. 01Mesurer.

   Qui s’en sert, combien de fois, pour quoi faire ? Quelles fonctions servent vraiment ? Une copie complète du code et de la base, datée, sert de point de départ.

2. 02Sécuriser.

   Récupérer les accès, ajouter un second administrateur sur chaque compte, changer toutes les clés et mots de passe que l’ancien prestataire connaissait, vérifier que les sauvegardes existent et se restaurent.

3. 03Faire l’état des lieux.

   Le code se construit-il ? Avec quelles versions ? Y a-t-il des tests ? Les règles d’accès aux données tiennent-elles ? Ce dernier point se vérifie avec la liste de la sécurité d’une application.

4. 04Réduire.

   Les fonctions que personne n’utilise ne méritent pas d’être remises à niveau. Les retirer allège tout le reste.

L’ordre compte. Corriger un bug avant d’avoir changé les clés, c’est travailler sur une application dont quelqu’un d’autre détient encore les accès. Remettre à niveau avant d’avoir mesuré, c’est payer pour des écrans que personne n’ouvre.

Reprendre, refaire une partie ou remplacer

L’état des lieux oriente vers l’une des trois voies. Aucune n’est meilleure par principe.

Une troisième voie existe : remplacer l’application par un logiciel du marché, si le besoin s’est banalisé depuis le premier développement. La grille de sur mesure ou outil du marché s’applique telle quelle. Et si le back-end est un service comme Supabase ou Firebase, sa reprise suit les mêmes règles que le reste, avec les points propres à chacun décrits dans Supabase, Firebase ou serveur à soi.

Éviter que ça se reproduise

Une application se transmet bien quand elle a été pensée pour l’être. Trois points suffisent à changer la situation la prochaine fois.

• Tout à votre nom dès le départ : comptes développeur, hébergement, domaine, services tiers, dépôt de code. Le prestataire travaille avec des accès que vous pouvez retirer.
• Une cession des droits écrite au contrat, sur le code comme sur la documentation.
• Une application qui se construit et se vérifie toute seule.

Ces exigences s’écrivent dans le cahier des charges de l’application, et elles pèsent peu sur le prix d’une application au regard de ce qu’elles évitent. Les autres sujets du parcours ont leur article : la maquette cliquable, PWA ou application native, l’application des équipes terrain et son mode hors connexion, les notifications, l’abonnement, le portail client, l’IA dans une application, low-code ou code et le vibe coding, dont les applications générées sans relecture sont souvent celles qu’il faut reprendre.

Notre développement d’applications commence par un cadrage écrit, aussi pour une application existante à reprendre.

Questions fréquentes

Sources

1. Solutions Numériques, les droits de propriété intellectuelle sur le logiciel (nouvel onglet)solutions-numeriques.com
2. Aide App Store Connect, transfert d’une application (nouvel onglet)developer.apple.com
3. Aide Play Console, transférer des applications (nouvel onglet)support.google.com
4. Apple Developer, exigences à venir (nouvel onglet)developer.apple.com
5. Aide Play Console, niveau d’API cible (nouvel onglet)support.google.com