Prestataire disparu : les 10 premiers jours pour reprendre votre application
Votre agence a fermé, votre développeur ne répond plus, et votre application tourne sans que personne sache la modifier. En dix jours, vous pouvez sécuriser vos accès, récupérer le
Reprise d'application : par où commencer
Une reprise d'application commence par les accès, pas par le code. Tant que les comptes développeur, l'hébergement et le nom de domaine sont au nom de votre ancien prestataire, c'est lui qui contrôle votre application, même s'il ne répond plus. Le code vient ensuite, puis le contrat, puis l'audit. Le prix arrive en dernier, une fois le code ouvert et compilé.
Nous sommes une agence de développement installée à Cesson-Sévigné, à côté de Rennes. Nous n'avons jamais refusé une reprise de code. Ce plan en dix jours est celui que nous suivons quand une entreprise nous appelle avec une application orpheline.
“« Nous n'avons jamais refusé une reprise de code. Mais nous n'en avons jamais chiffré une sans l'avoir ouverte. »
Hari Annadourai, dirigeant de Caliblock
Les quatre situations qu'on rencontre
- L'agence a fermé, parfois sans prévenir ses clients.
- Le développeur indépendant ne répond plus, ou a changé de métier.
- La relation s'est arrêtée sans passation : personne n'a pensé à demander les accès.
- Le prestataire répond, mais ne livre plus, ou conditionne la remise du code à un paiement contesté.
Les trois premières se traitent avec ce plan. La quatrième aussi, mais le contrat y prend une place plus grande, et un avocat peut devenir nécessaire.
Jour 1 : vérifier la situation du prestataire
Avant d'écrire à qui que ce soit, regardez où en est la société de votre prestataire, sur l'Annuaire des entreprises ou au BODACC. Une société en liquidation judiciaire n'est plus représentée par son dirigeant mais par le liquidateur : c'est à lui qu'il faut adresser vos demandes.
Rassemblez ensuite ce que vous avez déjà : le contrat, les devis signés, les factures, et la liste des accès qui sont réellement à votre nom. Cette liste est souvent plus courte qu'on ne le pense.
Jours 1 et 2 : sécuriser les accès
C'est l'étape la plus urgente. Tant qu'un seul compte critique reste hors de vos mains, une erreur de paiement ou un mot de passe oublié peut suffire à faire tomber l'application.
| Accès | Pourquoi il est critique | S'il n'est pas à votre nom |
|---|---|---|
| Compte développeur Google Play | Il permet de publier les mises à jour Android | Demander un transfert vers votre compte |
| Compte Apple Developer | Il permet de publier les mises à jour iOS | Demander un transfert vers votre compte |
| Hébergement et base de données | L'application et ses données y tournent | Récupérer un accès administrateur, puis migrer si besoin |
| Nom de domaine | Il porte le site, l'API et souvent les e-mails | Faire changer le titulaire du domaine |
| Services tiers : paiement, envoi d'e-mails, notifications, cartes | Une clé expirée peut couper une fonction sans prévenir | Créer vos propres comptes et remplacer les clés |
| Dépôt de code | C'est l'application elle-même | Récupérer le dépôt complet, avec son historique |
Pour chaque accès récupéré, changez le mot de passe, activez la double authentification, et ajoutez un second administrateur de confiance. Une reprise qui recrée la même dépendance à une seule personne n'a rien réglé.
Les comptes développeur : le point qui décide de tout
Une application publiée sur le compte de votre prestataire peut être transférée sur le vôtre, en gardant ses utilisateurs, ses statistiques, ses notes et ses avis. Mais chez Google comme chez Apple, c'est le titulaire du compte d'origine qui doit lancer le transfert.
Si votre prestataire est encore joignable, c'est la première chose à lui demander, avant même le code. S'il ne l'est plus, il ne reste qu'à publier une nouvelle fiche sur votre propre compte : l'application repart alors sans ses avis, et ses utilisateurs actuels ne reçoivent pas les mises à jour tant qu'ils n'ont pas installé la nouvelle version. C'est le scénario que tout ce plan cherche à éviter.
Jours 2 et 3 : récupérer le code source, avec son historique
Demandez le dépôt complet, pas une archive zip. L'historique des modifications dit qui a changé quoi et quand, et c'est souvent la seule documentation qui existe. Une archive sans historique oblige à tout redécouvrir.
Avec le dépôt, il faut aussi la configuration de compilation, la liste des variables d'environnement, les éventuels scripts de déploiement, et toute documentation, même partielle. Les secrets eux-mêmes (clés d'API, mots de passe de base de données) seront de toute façon remplacés : on ne réutilise pas les clés d'un prestataire parti.
Jour 3 : relire le contrat, et la question de la propriété du code
Avoir payé le développement ne suffit pas toujours à posséder le code. Les droits sur un logiciel appartiennent en principe à celui qui l'a écrit, donc à votre prestataire, sauf si le contrat prévoit leur cession. Et le Code de la propriété intellectuelle encadre strictement ces cessions : les droits cédés et leur domaine d'exploitation doivent être délimités. Sans clause de cession claire, vous pouvez n'avoir qu'un droit d'utilisation.
Cherchez aussi une clause de réversibilité, qui organise la remise du code et des accès en fin de contrat. Si le contrat est muet, ou si le prestataire conteste, faites relire la situation par un avocat avant d'engager des frais de reprise. Nous pouvons vous dire ce que le code contient, pas trancher qui en est propriétaire.
Jours 4 et 5 : faire compiler le code
C'est le test qui décide de la suite. Un code qui ne compile pas n'est pas un code qu'on peut maintenir, et tant que le dépôt n'a pas été ouvert et compilé, personne ne peut sérieusement annoncer un prix. Un prestataire qui le fait quand même vous annonce surtout qu'il ne l'a pas regardé.
Les causes d'échec sont presque toujours les mêmes : une version du langage ou du framework abandonnée depuis longtemps, des bibliothèques qui n'existent plus, des fichiers de configuration absents du dépôt. Chacune se corrige, mais chacune a un coût, et c'est ici qu'on le mesure.
Jour 6 : vérifier la signature et la publication
Sur Android, une application est signée. Si elle utilise le service de signature de Google Play, c'est Google qui conserve la clé de signature de l'application : la clé d'envoi, elle, peut être réinitialisée depuis la Play Console si elle a été perdue. Si la clé était gérée par le prestataire et qu'elle a disparu, les mises à jour sur la même fiche deviennent impossibles.
Sur iOS, les certificats se régénèrent depuis le compte développeur. Tout revient donc, encore une fois, à la question du compte. C'est aussi le moment de vérifier que l'application respecte les exigences actuelles des magasins : une application qui n'a pas été mise à jour depuis longtemps peut ne plus être installable par de nouveaux utilisateurs.
Jours 7 et 8 : auditer le code
L'audit ne cherche pas à juger le travail du prestataire précédent. Il répond à cinq questions :
- Le code est-il lisible et organisé, ou faudra-t-il le comprendre fichier par fichier ?
- Existe-t-il des tests, et passent-ils ?
- Quelles dépendances sont obsolètes, et lesquelles présentent des failles connues ?
- Où sont hébergées les données, et qui y a accès ?
- Qu'est-ce qui casse en premier si personne ne touche à rien pendant six mois ?
La dernière question est la plus utile pour un dirigeant. Elle transforme un audit technique en liste de priorités.
Jours 9 et 10 : chiffrer et décider
À ce stade, il n'y a plus que trois options, et l'audit dit laquelle s'applique.
| Option | Quand c'est la bonne | Ce que ça implique |
|---|---|---|
| Maintenir | Le code compile, il est lisible, les dépendances sont à jour ou presque | Un contrat de maintenance, avec une première mise à niveau légère |
| Remettre à niveau | Le code est sain, mais plusieurs versions de retard s'accumulent | Un chantier ponctuel, puis la maintenance |
| Réécrire | Chaque correction en casse une autre, ou le code est introuvable | Un nouveau projet, en gardant l'application actuelle en vie jusqu'à la bascule |
La réécriture n'est jamais notre premier réflexe. Une application qui tourne a une valeur, et il est presque toujours moins cher de la remettre en état que de tout refaire.
Côté prix, nos contrats de maintenance vont de 390 à 1 490 € HT par mois, avec un engagement de douze mois, et nos interventions hors forfait sont facturées 450 € HT la journée. Le chiffrage de la remise à niveau, lui, ne se donne qu'après les étapes précédentes.
Ce que dix jours ne permettent pas
- Corriger tout ce que l'audit a trouvé. Dix jours servent à savoir, pas à tout réparer.
- Récupérer un compte développeur sans l'accord de son titulaire. Dans ce cas, la nouvelle fiche reste la seule voie sûre.
- Reconstituer un code perdu. Si le dépôt n'existe plus, on repart du comportement de l'application, et c'est une réécriture.
- Régler un litige avec le prestataire. C'est le travail d'un avocat, pas d'une agence de développement.
Reprise d'application à Rennes : pourquoi nous venons à votre bureau
La récupération des accès se fait mieux côte à côte. Ce sont des mots de passe, des comptes d'administration et des codes de double authentification : les faire circuler par e-mail pendant une reprise ajoute un risque au problème. Installés à Cesson-Sévigné, nous faisons cette séance dans vos locaux, à Rennes et dans les environs, avec la personne de votre équipe qui garde le contrôle des comptes.
Pour les entreprises plus éloignées, dans le Grand Ouest ou ailleurs, tout se fait à distance, avec la même méthode. Nos équipes travaillent en Flutter pour le mobile, en React et Node.js pour le web, en Next.js pour les sites. Pour une autre technologie, l'audit dit franchement si nous sommes les bons interlocuteurs.
Ce qu'il faut retenir
- Une reprise d'application commence par les accès : comptes développeur, hébergement, domaine, services tiers.
- Le transfert d'une application vers votre compte doit être lancé par le titulaire du compte d'origine.
- Récupérez le dépôt de code complet, avec son historique, pas une simple archive.
- Avoir payé le développement ne vaut pas toujours propriété du code : relisez la clause de cession.
- Aucun prix sérieux avant que le code ait été ouvert et compilé.
