Reprendre une application abandonnée par son prestataire.
Récupérer vos accès, vérifier vos droits, sécuriser l'existant,
puis choisir entre reprise, modernisation ou refonte.
Votre application tourne, vos clients l'utilisent… mais le prestataire qui l'a construite ne répond plus. Liquidation, départ d'un freelance, agence rachetée : la situation est fréquente, et des entreprises publient régulièrement ce type de demande sur les plateformes de prestataires. Bonne nouvelle : dans la plupart des cas, une application se reprend. Voici l'ordre dans lequel procéder.
1. Faire l'inventaire de ce que vous détenez
Avant toute chose, listez ce qui est à votre nom… et ce qui ne l'est pas.
- Le code source : un dépôt Git (GitHub, GitLab, Bitbucket) au nom de votre entreprise, ou au minimum une archive récente.
- L'hébergement : serveurs, cloud, base de données. Qui paie la facture, qui détient les accès administrateur ?
- Le nom de domaine et les DNS : chez quel registrar, à quel nom, quelle date d'expiration ?
- Les comptes des stores (App Store, Google Play) pour une application mobile : le compte développeur doit être celui de l'entreprise.
- Les services tiers : envoi d'e-mails, paiement, cartographie, notifications, statistiques. Chacun a ses clés et sa facturation.
- La documentation et les contrats : cahier des charges, devis signés, factures, contrat de maintenance.
Un élément resté au nom de l'ancien prestataire n'est pas perdu pour autant : sa récupération devient simplement la priorité n° 1.
2. Vérifier vos droits sur le code
En France, payer le développement d'un logiciel ne suffit pas à en devenir propriétaire. 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 ; il ne vise pas un prestataire indépendant. Sans cession écrite, chaque droit cédé faisant l'objet d'une mention distincte (article L131-3), les droits restent en principe chez l'auteur.
Relisez votre contrat et vos conditions générales : une clause de cession de droits ou de réversibilité change tout. En cas de doute, faites-le relire par un juriste avant d'engager des frais.
3. Sécuriser l'existant, tout de suite
Une application sans prestataire est une application sans pompier. Avant même l'audit, quatre gestes réduisent fortement le risque :
- Changer les mots de passe et révoquer les accès de l'ancien prestataire : hébergement, dépôt de code, stores, services tiers.
- Faire une sauvegarde complète de la base de données et des fichiers, et vérifier qu'elle se restaure.
- Contrôler les dates d'expiration du nom de domaine et des certificats.
- Mettre en place une surveillance minimale : une alerte si le site ou l'API tombe.
4. Faire auditer le code et l'infrastructure
Un audit de quelques jours répond à la seule question qui compte : peut-on repartir de l'existant ? Il passe en revue l'architecture, la qualité du code, les dépendances obsolètes ou vulnérables, la sécurité, les tests, le déploiement et les coûts d'hébergement.
Le livrable doit être lisible par un dirigeant : un état des lieux, des risques classés, un plan chiffré. Voir notre audit de code.
5. Reprendre, moderniser ou refaire ?
| Ce que l'audit constate | Décision conseillée |
|---|---|
| Architecture saine, dette localisée, dépendances faciles à mettre à jour | Reprendre : remise en état, documentation, puis évolutions |
| Logique métier fiable, mais framework ou langage en fin de support | Moderniser par étapes, module par module, sans interruption de service |
| Code inexploitable, failles de conception, données mal séparées | Refaire, en conservant les données et les règles métier |
Une refonte complète ne se justifie que si elle coûte moins cher que la reprise sur plusieurs années, maintenance comprise.
6. Organiser la reprise
- Un dépôt de code au nom de l'entreprise, avec son historique
- Un environnement de recette séparé de la production
- Un déploiement automatisé (CI/CD) et réversible
- Des sauvegardes testées et une supervision
- Une documentation à jour : installation, architecture, procédures
- Un contrat de maintenance (TMA) clair : délais, périmètre, prix
7. Éviter que cela se reproduise
Dans vos prochains contrats de développement, exigez :
- une cession de droits écrite sur le code et les livrables ;
- une clause de réversibilité : remise du code, des accès et de la documentation en fin de contrat ;
- des comptes au nom de l'entreprise (hébergement, domaine, stores, services tiers), le prestataire n'y étant qu'invité ;
- une documentation livrée avec chaque version.
FAQ
Questions fréquentes.
Combien coûte la reprise d'une application ?
Elle commence par un audit au forfait, en général quelques jours de travail. Le coût de la reprise dépend ensuite de l'état du code : le rapport d'audit le chiffre poste par poste.
Combien de temps faut-il pour reprendre une application ?
Les mesures de sécurisation prennent quelques jours. La remise en état et la mise en place d'un déploiement fiable prennent ensuite quelques semaines, selon la taille de l'application.
L'ancien prestataire refuse de transmettre le code : que faire ?
Rassemblez le contrat, les factures et les échanges, puis consultez un juriste : la réponse dépend des clauses de cession et de réversibilité. En parallèle, sécurisez tout ce que vous contrôlez déjà : domaine, hébergement, base de données.
Faut-il prévenir les utilisateurs ?
Pas si la reprise se fait sans interruption, ce qui est l'objectif. En revanche, si des données personnelles ont pu être exposées, le RGPD impose de documenter l'incident et, selon le risque, de le notifier à la CNIL dans les 72 heures.
Votre application est orpheline ?
Décrivez-nous la situation. Premier avis gratuit sous 24 h, et un audit au forfait si besoin.