Comment reprendre un logiciel abandonné par son prestataire ?
Le freelance ne répond plus, l'agence a fermé ou la relation est rompue. Le logiciel tourne encore, et c'est maintenant qu'il faut agir, avant la première panne.
Oct 29, 2026
Pour reprendre un logiciel abandonné par son prestataire, suivez six étapes dans cet ordre : récupérer les accès, sécuriser une copie du code et des données, vérifier que vous êtes propriétaire du code, faire auditer le code, stabiliser la production, et seulement ensuite reprendre les évolutions. L'ordre compte : la plupart des reprises qui tournent mal commencent par une évolution demandée au nouveau prestataire avant que quiconque ait vérifié qu'on pouvait redéployer l'application.
Nous reprenons ces projets régulièrement chez Reflekt Lab, studio de développement basé à Bordeaux. Voici la méthode que nous appliquons, et ce que vous pouvez faire vous-même avant d'appeler qui que ce soit.
Les signes qu'un logiciel est abandonné
Vous êtes probablement dans ce cas si l'un de ces points vous parle :
- le développeur freelance ne répond plus aux messages, ou répond « la semaine prochaine » depuis deux mois ;
- l'agence a fermé, été rachetée, ou a réaffecté l'équipe qui connaissait votre projet ;
- la relation est rompue, avec un litige sur une facture ou une recette jamais signée ;
- votre associé technique est parti, et personne en interne ne sait déployer ;
- personne ne sait plus qui paie l'hébergement ni où sont les sauvegardes.
L'application fonctionne encore, c'est ce qui rend la situation trompeuse. Elle tournera jusqu'à l'expiration d'un certificat, d'un nom de domaine ou d'une carte bancaire enregistrée chez l'hébergeur.
Étape 1 : récupérer les accès
C'est l'urgence. Avant la technique, il faut savoir qui détient les clés. Faites la liste et mettez chaque compte à votre nom, ou au minimum ajoutez-vous comme administrateur :
| Accès | Où le trouver | Pourquoi c'est urgent |
|---|---|---|
| Nom de domaine | Registrar (OVHcloud, Gandi, Ionos…) | S'il expire, le site et souvent les courriels s'arrêtent |
| Hébergement et serveurs | Console de l'hébergeur ou du cloud | La facture tombe sur la carte du prestataire, qui peut la résilier |
| Base de données | Hébergeur, ou service managé | Ce sont vos données métier |
| Dépôt de code | GitHub, GitLab, Bitbucket | Sans l'historique, l'audit est beaucoup plus lent |
| Services tiers | Paiement, envoi de courriels, cartographie, IA | Des clés d'API au nom du prestataire peuvent être révoquées |
Si le prestataire est joignable, demandez ces transferts par écrit, en un seul courriel, et gardez sa réponse. S'il ne l'est plus, l'hébergeur et le registrar ont des procédures de changement de titulaire sur justificatif.
Étape 2 : sécuriser une copie complète
Dès que vous avez un accès, faites une copie de tout, avant de toucher à quoi que ce soit : le dépôt Git complet avec son historique, une sauvegarde de la base de données, les fichiers déposés par les utilisateurs, et la configuration du serveur. Rangez-la chez vous, pas chez le prochain prestataire.
Cette copie vous protège de deux risques réels : une résiliation de l'hébergement par l'ancien prestataire, et une erreur pendant la reprise.
Étape 3 : vérifier que le code vous appartient
C'est la question que nous posons avant même de lire le code, parce qu'une reprise sans droits est juridiquement fragile.
En droit français, payer un développement ne suffit pas à en devenir propriétaire. Un freelance ou une agence reste titulaire des droits d'auteur sur le code qu'il écrit, sauf cession écrite. L'article L131-3 du Code de la propriété intellectuelle impose que chaque droit cédé (reproduction, modification, adaptation) soit mentionné distinctement, avec son étendue, sa destination, son lieu et sa durée. Seul le logiciel créé par un salarié dans l'exercice de ses fonctions revient d'office à l'employeur.
Relisez donc le contrat, le devis signé ou les conditions générales du prestataire. Trois cas se présentent :
- Une clause de cession complète des droits existe : vous pouvez confier le code à un autre prestataire.
- Le contrat ne prévoit qu'une licence d'utilisation : vous pouvez utiliser le logiciel, pas forcément le faire modifier par un tiers. Il faut négocier une cession, souvent possible à l'amiable.
- Il n'y a pas de contrat écrit : la situation est floue. Un avocat en droit de l'informatique tranchera plus vite que vous.
Si le code a été déposé chez un tiers de confiance, comme l'Agence pour la protection des programmes (APP), le contrat de dépôt prévoit souvent sa remise en cas de défaillance du prestataire. Vérifiez-le.
Étape 4 : faire auditer le code
Un audit de code source répond à une question simple : peut-on faire évoluer ce logiciel sans tout casser, et à quel prix ? Il regarde l'architecture, la dette technique, les failles de sécurité, les dépendances obsolètes, la présence de tests et la façon dont l'application se déploie.
Le livrable utile n'est pas une note globale, c'est une liste : ce qui est sain, ce qui se reprend, ce qui doit vraiment être réécrit, avec une estimation pour chaque point. Chez Reflekt Lab, cet audit coûte 2 500 € HT forfaitaires et prend deux à cinq jours. Vous pouvez vous arrêter là et confier la suite à qui vous voulez.
Méfiez-vous d'un prestataire qui chiffre une reprise sans avoir lu le code, et plus encore de celui qui propose une réécriture complète dès le premier rendez-vous.
Étape 5 : stabiliser avant de faire évoluer
C'est l'étape que tout le monde veut sauter, et celle qui évite la panne du lundi matin. Avant la première évolution, le nouveau prestataire doit pouvoir :
- reconstruire et redéployer l'application à partir du dépôt, sans l'ancien développeur ;
- restaurer une sauvegarde et vérifier qu'elle fonctionne vraiment ;
- lancer des tests sur les parcours critiques : la commande, la facturation, la connexion ;
- être alerté quand l'application tombe, plutôt que de l'apprendre par un client.
Tant que ces quatre points ne sont pas acquis, chaque modification est un pari.
Étape 6 : reprendre les évolutions
Une fois la production stable, la reprise devient un projet ordinaire. Mettez en place un contrat de maintenance (ce qu'on appelle aussi la TMA, tierce maintenance applicative) qui couvre les corrections, les mises à jour de sécurité et un volume d'évolutions. Vérifiez qu'il vous laisse partir : les accès restent à votre nom, le code dans votre dépôt, et la documentation à jour. Sinon, vous recréez exactement la dépendance qui vous a mis dans cette situation.
Réécrire ou reprendre ?
Reprendre, presque toujours. Une réécriture jette le travail déjà payé, prend des mois avant la première mise en production, et redécouvre un par un les cas particuliers que l'ancien code gérait déjà. Elle se justifie sur un composant précis : une technologie qui n'est plus maintenue, un module que personne ne peut tester, une faille de sécurité structurelle. L'audit vous dit lesquels.
Le cas des applications générées avec l'IA (Lovable, Bolt, Cursor, Replit) est un peu différent : le code existe, mais souvent personne ne l'a jamais relu. La méthode reste la même, et l'audit pèse encore plus lourd.
Pour aller plus loin
L'offre complète, avec les prix et les étapes, est sur notre page reprise de code. Le contrat qui suit la reprise est détaillé dans tierce maintenance applicative. Et si vous vous demandez s'il vaut mieux repartir de zéro, combien coûte un logiciel sur mesure donne les ordres de grandeur.