Votre développeur a abandonné le projet : plan de reprise d'un logiciel inachevé
Votre développeur ou votre agence a disparu en cours de projet : ce qu'il faut sécuriser en 72 heures, évaluer l'existant et choisir qui le terminera.
Points clés
- Dans les 72 premières heures, sécurisez les accès avant tout : nom de domaine, hébergement, dépôts de code, comptes App Store et Google Play, et chaque service tiers dont l'application dépend.
- Envoyez une demande écrite et datée du code, des identifiants et de la documentation. Cela ne coûte rien et comptera en cas de litige.
- « C'est fini à 80 % » n'est presque jamais vrai. Faites faire une évaluation indépendante de ce qui existe, de ce qui fonctionne et de ce qui manque, avant tout devis pour terminer.
- Trois options : terminer l'existant, stabiliser puis poursuivre par étapes, ou reconstruire ce qui ne peut pas être sauvé. C'est l'évaluation qui doit décider, pas l'exaspération.
- Choisissez la nouvelle équipe sur sa façon de traiter le code hérité : évaluation payante d'abord, constats honnêtes, livraisons progressives sur vos comptes.
Un développeur ne répond plus. Une agence se tait, ou ferme. Le projet est à moitié construit, le budget presque consommé et la date de lancement approche. C'est l'une des situations les plus stressantes pour un dirigeant, et les premiers jours déterminent ce qui pourra être sauvé. Ce guide reprend le plan que nous suivons quand un client arrive dans cette situation. Si l'ancien prestataire est encore joignable et coopératif, notre checklist de reprise d'application est un meilleur point de départ.
Les 72 premières heures : sécuriser les accès
Le code se récupère ou se réécrit. Un compte perdu, beaucoup moins facilement. Faites la liste et traitez-la aujourd'hui.
| Quoi | Pourquoi c'est important | Ce qu'il faut vérifier |
|---|---|---|
| Nom de domaine | Qui le contrôle contrôle votre site et vos e-mails | Qui est le titulaire chez le registrar ? Pouvez-vous vous connecter ? L'échéance est-elle proche ? |
| Hébergement et cloud (OVHcloud, AWS, Azure, Google Cloud, Vercel...) | L'application et sa base de données y tournent | À qui est le compte, et la carte de paiement ? Avez-vous un accès administrateur ? |
| Dépôts de code (GitHub, GitLab, Bitbucket) | Le code source et son historique | Le dépôt est-il dans votre organisation ou sur le compte personnel du développeur ? |
| Comptes des stores (Apple, Google Play) | Une application mobile est liée au compte développeur qui la publie | L'application a-t-elle été publiée sous le compte de votre société ? |
| Services tiers (paiement, envoi d'e-mails, cartographie, statistiques, authentification) | L'application s'arrête si une clé est révoquée ou une facture impayée | Quels services, quels comptes, où sont stockées les clés ? |
| Sauvegardes de la base | Vos données, si l'hébergement disparaît | Quand date la dernière sauvegarde, et pouvez-vous la télécharger ? |
Trois règles pratiques :
- Payez vous-même les factures. Si l'hébergement ou le domaine est réglé avec la carte du développeur, un impayé peut couper votre service. Demandez au fournisseur comment transférer le compte ou le service à votre société.
- Changez ce que vous pouvez. Pour chaque compte que vous contrôlez, renouvelez mots de passe et clés d'API, et retirez les accès des personnes parties.
- Ne supprimez rien pour l'instant. La nouvelle équipe aura besoin de tout l'historique pour comprendre ce qui a été construit.
Si l'application mobile a été publiée sous le compte personnel du développeur, les deux stores permettent de la transférer vers un autre compte sans perdre ses utilisateurs ni ses notes : voir la présentation du transfert d'app d'Apple et la page de Google sur le transfert d'applications vers un autre compte développeur. Dans les deux cas, c'est le titulaire actuel qui doit lancer le transfert : raison de plus pour garder une relation aussi courtoise que possible.
Formalisez votre demande par écrit
Même si le développeur ne répond plus, envoyez une demande écrite, courte et datée, par e-mail et par lettre recommandée avec accusé de réception. Demandez :
- le code source complet et l'accès aux dépôts ;
- tous les identifiants et clés d'API des services utilisés ;
- la documentation, les maquettes et tout ce qui a été livré ou payé ;
- l'état des factures éventuellement impayées.
Restez factuel et poli. Si la relation finit en litige, la trace de ce que vous avez demandé et quand comptera. Elle compte aussi pour la propriété : à qui appartient le code dépend de votre contrat, et notre guide sur la propriété intellectuelle du code explique pourquoi, en droit français, payer le code ne suffit pas à en devenir propriétaire. Pour des montants importants, consultez tôt un avocat.
Évaluez ce dont vous disposez vraiment
Une fois le code récupéré, résistez à la tentation de confier le projet au premier qui promet de « juste le finir ». Un projet inachevé est rarement aussi avancé que le dernier point d'étape le laissait croire. Les manques habituels :
- Des écrans sans la logique derrière. L'interface semble terminée, mais les formulaires n'enregistrent rien, les e-mails ne partent pas et le paiement n'est pas branché.
- Des fonctionnalités qui ne marchent qu'en démo. Données en dur, comptes de test, validations sautées.
- Aucun processus de déploiement. L'application tourne sur l'ordinateur du développeur ou sur un serveur configuré à la main, et personne ne sait publier une nouvelle version.
- Des pièces que personne n'a listées. Outils d'administration, réinitialisation de mot de passe, gestion des erreurs, sauvegardes, sécurité.
Une évaluation indépendante, généralement d'une à deux semaines, doit vous dire :
- Peut-on compiler et déployer l'application à partir du seul dépôt ?
- Ce qui fonctionne, testé de bout en bout, et ce qui ne fait que sembler fonctionner.
- La qualité et la sécurité du code, assez pour savoir si les fondations sont saines.
- Ce qui manque pour lancer, avec une estimation par partie.
- Une recommandation : terminer, stabiliser puis poursuivre, ou reconstruire certaines parties.
C'est le cœur d'un audit technique d'application web, centré sur une question : que faut-il pour mettre cela en ligne ?
Terminer, stabiliser ou reconstruire ?
| Option | Quand elle convient | Le risque |
|---|---|---|
| Terminer en l'état | Les fondations sont saines, le code lisible, et les manques sont des fonctionnalités, pas de la structure | Faible, si l'évaluation le confirme |
| Stabiliser, puis poursuivre | Le cœur fonctionne mais il y a des points faibles : pas de tests, déploiement fragile, failles de sécurité | Modéré ; il faut une équipe à l'aise avec le code hérité |
| Reconstruire certaines parties | Certaines zones sont irrécupérables, mais les modèles de données, les maquettes ou des modules peuvent être gardés | Modéré ; dérive du périmètre s'il n'est pas bien cadré |
| Tout reconstruire | Le code ne compile pas, la technologie est inadaptée, ou presque rien ne fonctionne | Élevé : cela prend plus de temps que prévu |
Après une mauvaise expérience, la réécriture complète est tentante, et généralement plus risquée qu'elle n'en a l'air. Notre guide reprendre ou réécrire détaille cette décision.
Choisir une équipe pour reprendre une application inachevée
Beaucoup d'agences aiment démarrer un projet neuf. Moins nombreuses sont celles qui savent reprendre le code à moitié construit de quelqu'un d'autre. En les comparant, cherchez :
- Une évaluation payante avant un devis ferme. Quiconque chiffre la « fin » d'une application sans lire le code devine.
- Des constats honnêtes, y compris sur ce qui est meilleur que prévu. Une équipe qui condamne tout ce qu'elle n'a pas écrit vend une réécriture.
- Une expérience du code hérité, avec des exemples vérifiables.
- Des livraisons progressives : de petites versions fonctionnelles dès les premières semaines, pas une grande révélation des mois plus tard.
- Tout sur vos comptes, pour que cela ne se reproduise pas. Voir comment choisir un prestataire de développement et notre guide pour repérer les équipes juniors et la sous-traitance cachée.
Éviter que cela se reproduise
- Dépôts, hébergement, domaines et comptes des stores au nom de votre société dès le premier jour, avec le développeur invité, et non l'inverse.
- Des livraisons régulières et fonctionnelles que vous pouvez voir et tester, pas des rapports d'avancement.
- Documentation et instructions de déploiement livrées à chaque jalon.
- Un contrat avec une cession de droits explicite, une clause de réversibilité et des personnes nommées.
- Pour un logiciel sous licence plutôt qu'en propriété, envisagez un séquestre de code source.
Questions fréquentes
Puis-je récupérer mon code si le développeur ne répond plus ? Si le code est sur un dépôt que vous contrôlez, vous l'avez déjà. S'il est sur le compte du développeur, envoyez une demande écrite et, à défaut de réponse, prenez conseil auprès d'un avocat : vos droits dépendent de votre contrat et de ce que vous avez payé.
Quelle part du budget initial est généralement perdue ? Cela varie énormément. C'est l'évaluation qui le dit : parfois l'essentiel du travail est réutilisable, parfois très peu. Ne vous fiez à aucune estimation faite avant que quelqu'un ait lu le code.
La nouvelle équipe doit-elle garder la même technologie ? En général oui, s'il s'agit d'une technologie courante et bien maintenue et que le code est correct. Changer de technologie transforme une reprise en réécriture.
Mon application est sur l'App Store sous le compte du développeur. Est-elle perdue ? Pas forcément. Apple et Google permettent de transférer une application vers un autre compte développeur en gardant ses utilisateurs et ses notes, mais c'est le titulaire actuel qui doit le lancer. S'il refuse, il faudra peut-être republier sous votre compte et migrer les utilisateurs.
FNB Solutions reprend les applications inachevées ou en difficulté : une courte évaluation payante d'abord, puis un plan pour stabiliser et livrer, avec tout sur vos comptes. Voir notre offre de reprise de logiciel, ou racontez-nous ce qui s'est passé.
Sources
- Apple, présentation du transfert d'app (aide App Store Connect)
- Google, transférer des applications vers un autre compte développeur (aide Play Console)
- Code de la propriété intellectuelle sur Légifrance, article L131-3 (forme des cessions de droits d'auteur)