C'est une situation plus fréquente qu'on ne le croit, et toujours angoissante : le prestataire qui a développé votre logiciel n'est plus là. Il a fermé, changé d'activité, ne répond plus à vos mails, ou la relation s'est dégradée au point de rompre. Votre application continue de tourner — pour l'instant — mais plus personne ne sait comment elle fonctionne, et la moindre panne vous laisse sans recours. Voici la marche à suivre pour reprendre la main.
Étape 1 : établir ce qui vous appartient, puis le sécuriser
C'est l'urgence absolue, avant même de comprendre le code — et elle commence par une lecture, pas par une action technique : relisez votre contrat. En droit français, le logiciel développé par un prestataire externe est protégé par le droit d'auteur, et ces droits ne vous sont transférés que si le contrat contient une clause de cession expresse. Sans elle, le code reste juridiquement la propriété du prestataire, même si vous l'avez intégralement payé. Beaucoup de contrats de développement n'en ont pas, et c'est là que se joue une bonne partie de la reprise : savoir si vous devez récupérer ce qui est à vous, ou négocier ce qui ne l'est pas encore.
Une fois ce point clarifié, sécurisez sans attendre les actifs qui ne dépendent pas de cette clause : vos données, les comptes ouverts à votre nom (hébergement, services de paiement, API, envoi d'emails) et vos noms de domaine — à condition qu'ils aient bien été enregistrés à votre nom, ce qui n'est pas toujours le cas. Trop d'entreprises découvrent trop tard que leur domaine ou leur dépôt de code étaient au nom du prestataire. Sur ces questions, un avis juridique rapide vaut la peine ; nous y contribuons côté technique en identifiant précisément quels actifs existent et où ils se trouvent.
La checklist des actifs à récupérer
Voici ce que nous passons en revue en premier, dans l'ordre où les mauvaises surprises arrivent. Pour chaque ligne, la question est la même : à quel nom est-ce enregistré, et qui détient l'accès administrateur ?
| Actif | Où chercher | À vérifier |
|---|---|---|
| Code source | Où chercher : Dépôt Git (GitHub, GitLab, Bitbucket…), parfois seulement sur le serveur ou le poste du prestataire. | À vérifier : Propriétaire du dépôt, droits d'administration, présence de la dernière version réellement déployée. |
| Hébergement et serveurs | Où chercher : Compte chez l'hébergeur ou le cloud (OVH, Scaleway, AWS…), accès SSH, console d'administration. | À vérifier : Titulaire du compte et de la facturation, accès racine, sauvegardes et leur emplacement. |
| Base de données | Où chercher : Sur le serveur applicatif ou chez un service managé. | À vérifier : Identifiants administrateur, export complet récent et restaurable, données personnelles concernées. |
| Noms de domaine et DNS | Où chercher : Bureau d'enregistrement (registrar) et gestionnaire de zone DNS, parfois distincts. | À vérifier : Titulaire administratif du domaine, date d'expiration, accès pour modifier les enregistrements. |
| Comptes tiers et clés d'API | Où chercher : Paiement, envoi d'emails, SMS, cartographie, authentification, analytics. | À vérifier : Titulaire de chaque compte, moyen de paiement rattaché, possibilité de régénérer les clés. |
| Emails transactionnels | Où chercher : Service d'envoi (Resend, Brevo, SendGrid…) et domaine expéditeur. | À vérifier : Authentification du domaine (SPF, DKIM), compte à votre nom, historique des envois. |
| Magasins d'applications | Où chercher : Comptes développeur Apple et Google si une application mobile existe. | À vérifier : Titulaire du compte, certificats et clés de signature, sans lesquels aucune mise à jour n'est possible. |
| Documentation et environnement | Où chercher : Fichiers de configuration, variables d'environnement, procédures de déploiement. | À vérifier : Capacité à redéployer le logiciel à partir de zéro sans l'ancien prestataire. |
Un conseil pratique : changez les mots de passe et régénérez les clés d'accès dès que vous détenez les comptes, et faites une sauvegarde complète avant toute autre action. Rien de ce qui précède ne demande de comprendre le code.
Étape 2 : auditer l'existant
Une fois les actifs sécurisés, on établit un diagnostic : comment le logiciel est-il construit, dans quel état est le code, quelles sont les dépendances, où sont les risques ? L'absence de documentation — le cas le plus courant — ralentit ce travail mais ne le bloque pas : une grande partie de la connaissance se reconstitue en lisant le code et en observant le fonctionnement réel. À l'issue de cet audit, vous disposez enfin d'une vision claire de ce que vous possédez.
Combien de temps, et combien ? L'audit de reprise commence par notre pack de cadrage de 3 jours (3 000€ HT) : état des lieux hiérarchisé, risques, plan d'action et ordre de grandeur budgétaire — le détail est sur notre page Tarifs. Un logiciel vaste ou très ancien peut demander davantage ; l'audit se compte alors en semaines, pas en mois.
Étape 3 : ne pas céder à la tentation de tout jeter
Face à un code qu'on découvre imparfait, le réflexe est de vouloir tout réécrire. C'est rarement la bonne réponse. Un logiciel qui fonctionne, même mal codé, contient tout ce que le prestataire a compris de votre métier au fil des années — et qu'il a emporté avec lui. Ce capital de connaissance n'existe plus que dans le code. Tout jeter, c'est perdre cette valeur et la redécouvrir douloureusement en production. La bonne approche est de conserver et sécuriser ce qui peut l'être, puis de moderniser progressivement ce qui le justifie vraiment — après avoir tranché, une fois l'audit fait, s'il faut conserver ce logiciel ou le remplacer.
Étape 4 : reprendre le pilotage durablement
Reprendre un logiciel, ce n'est pas seulement récupérer du code : c'est retrouver la capacité de le faire évoluer sereinement. L'objectif final est votre autonomie — ne plus jamais dépendre d'un prestataire unique dont le départ vous mettrait en danger. C'est là qu'une direction technique à temps partagé prend tout son sens : un interlocuteur senior qui pilote votre produit dans la durée, en direct ou avec une équipe qu'il vous aide à constituer.
Prévenir la prochaine fois : trois clauses et une habitude
La reprise coûte toujours plus cher que la prévention. Pour le prochain contrat de développement — ou pour régulariser le prestataire actuel pendant que la relation est bonne —, trois clauses et une habitude suffisent à vous protéger.
Une clause de cession des droits, expresse et détaillée : l'article L131-3 du Code de la propriété intellectuelle exige que chaque droit cédé soit mentionné distinctement, avec son étendue, sa destination, son lieu et sa durée. Une phrase vague du type « le client devient propriétaire des développements » ne suffit pas — et comme la portée exacte de ce formalisme pour un contrat de développement est débattue devant les tribunaux, faites relire la clause par un juriste plutôt que de la recopier. Une clause de réversibilité : à la fin du contrat, le prestataire remet le code, la documentation, les accès et assure une passation, dans un délai et à un prix convenus d'avance. Un séquestre du code pour les logiciels critiques : une copie du code source déposée chez un tiers de confiance — en France, l'Agence pour la Protection des Programmes propose ce service —, remise au client si le prestataire disparaît ou cesse d'honorer le contrat.
Et l'habitude : tous les comptes à votre nom, dès le premier jour. Hébergement, domaine, dépôt de code, services tiers : vous êtes titulaire, le prestataire est invité avec les droits dont il a besoin. Cela ne coûte rien, et c'est ce qui transforme un départ de prestataire en simple changement d'interlocuteur.
Le vrai résultat d'une reprise : ne plus dépendre de personne
La reprise est possible dans la très grande majorité des cas, même sans la coopération de l'équipe précédente, et même sans documentation. Mais récupérer le code n'est que le début : le vrai résultat d'une reprise réussie, c'est qu'aucune personne, interne ou externe, ne détienne plus seule la clé de votre activité. Comptes à votre nom, documentation vivante, au moins deux personnes capables d'intervenir sur chaque zone critique — c'est ce que nous laissons derrière nous à la fin d'une mission, et c'est à cette aune que vous devriez juger tout prestataire.
Questions fréquentes
Que faire en premier quand un prestataire nous lâche ?
Relire votre contrat, puis sécuriser les actifs. Le contrat d'abord, parce qu'en droit français les droits sur un logiciel développé par un prestataire externe ne vous sont transférés que par une clause de cession expresse : sans elle, le code reste juridiquement au prestataire. Ensuite, récupérer les accès aux serveurs, à la base de données, aux noms de domaine et aux comptes tiers ouverts à votre nom, et faire une sauvegarde complète. Tout le reste — comprendre le code, décider quoi en faire — peut attendre quelques jours ; pas la sécurisation.
Et si l'ancien prestataire refuse de coopérer ?
Cela arrive, et c'est précisément pour cela qu'un tiers indépendant est utile. On commence par établir ce qui vous revient de droit — données, accès, domaines, et le code si le contrat le prévoit — puis on organise la transition dans des conditions professionnelles, avec un avis juridique si la propriété du code est contestée. Dans la plupart des cas, la reprise est possible même sans la collaboration de l'équipe précédente : le logiciel qui tourne contient déjà l'essentiel de ce qu'il faut savoir.
Qui peut reprendre une application web développée par une agence ?
Une autre agence, un développeur indépendant, ou une direction technique externalisée qui audite d'abord puis constitue l'équipe adaptée. Trois critères pour choisir : la capacité à auditer un code qu'on n'a pas écrit, l'indépendance — celui qui évalue votre logiciel ne doit pas avoir intérêt à vous vendre sa réécriture — et l'engagement à vous rendre autonome : documentation, accès à votre nom, pas de nouvelle dépendance à un prestataire unique.
Combien de temps prend une reprise de logiciel ?
La sécurisation des accès et un premier diagnostic prennent quelques jours. Reprendre sereinement le pilotage et corriger les irritants majeurs se compte en quelques semaines. La modernisation de fond, si elle est nécessaire, s'étale ensuite par paliers — mais vous n'êtes plus jamais dans l'urgence ni dépendant d'un prestataire unique.