Reprendre un projet logiciel abandonné par son prestataire : le plan de sauvetage

Pour reprendre un projet logiciel abandonné par son prestataire, procédez dans cet ordre : sécuriser les accès et les sauvegardes dans les premiers jours, rassembler tout ce qui a été produit, faire un état des lieux technique, puis décider entre finir, stabiliser ou reconstruire, et seulement ensuite choisir un repreneur et contractualiser. La question de la propriété du code se pose dès le début, mais sa réponse se trouve dans votre contrat, au cas par cas, pas dans les factures payées.

Cet article traite la situation d'urgence : le prestataire ne répond plus, a fermé, ou a rendu un travail inexploitable. Pour la vérification technique détaillée, lisez notre guide auditer une application existante. Pour éviter que cela se reproduise, notre article sur la réversibilité explique quoi prévoir au contrat.

Les situations que l'on rencontre

Un projet ne s'arrête pas toujours de la même manière, et la bonne réponse en dépend.

• Le freelance disparu : plus de réponse aux messages, plus de commits depuis des semaines. C'est la situation la plus fréquente, et souvent la plus urgente côté accès.
• L'agence qui ferme ou entre en procédure collective : l'interlocuteur devient un administrateur ou un liquidateur judiciaire.
• La rupture : désaccord sur le périmètre, sur un dépassement de budget, sur la qualité. Le prestataire existe encore, mais la relation est terminée.
• Le projet « fini » qui ne marche pas : livré, payé, mais instable, lent ou incomplet, et le prestataire ne corrige plus.
• Le départ interne : le développeur salarié ou l'associé technique qui portait tout est parti. Le problème est alors moins juridique, mais tout aussi pratique.

Certains signaux annoncent souvent l'abandon : livraisons repoussées sans explication, démonstrations remplacées par des captures d'écran, refus de donner accès au dépôt de code, factures d'avance de plus en plus pressantes. Si vous en reconnaissez plusieurs, appliquez dès maintenant la section suivante, sans attendre la rupture.

Les urgences des premiers jours

Un projet abandonné se dégrade vite, souvent sans bruit. Avant même de chercher un repreneur, sécurisez ce qui peut disparaître.

Faire l'inventaire des comptes

Listez tous les services sur lesquels repose l'application, et pour chacun, à quel nom il est ouvert, qui a les identifiants et quel moyen de paiement le règle :

• le nom de domaine et la zone DNS ;
• l'hébergement (serveur, cloud, plateforme) et la base de données ;
• le dépôt de code (GitHub, GitLab ou autre) ;
• les comptes Apple et Google pour une application mobile ;
• les services tiers : envoi d'e-mails, paiement en ligne, cartographie, stockage de fichiers, outils d'analyse ;
• la messagerie et les comptes d'administration de l'application elle-même.

Un service réglé par la carte bancaire personnelle d'un freelance qui ne répond plus peut s'arrêter à la prochaine échéance. Un nom de domaine qui expire peut être racheté par quelqu'un d'autre.

Récupérer une sauvegarde complète

Sans attendre la suite, récupérez une copie de la base de données, des fichiers téléversés par les utilisateurs et du code tel qu'il tourne en production. Si vous avez un accès administrateur à l'hébergement, faites-la vous-même ; sinon, demandez-la par écrit.

Garder une trace écrite

Notez les dates, conservez les échanges, envoyez vos demandes par écrit (e-mail, puis courrier recommandé si nécessaire). Ces traces serviront si la situation devient contentieuse, et elles aident votre avocat à vous conseiller.

Rassembler ce qui a été produit

Une fois les accès sécurisés, rassemblez tout ce qui a été produit pendant le projet, au-delà du code :

• le code source complet, avec son historique de versions si possible ;
• les maquettes et prototypes, même incomplets ;
• le cahier des charges, les comptes rendus et les échanges qui précisent les choix ;
• les identifiants et les secrets (clés d'API, mots de passe de services), qu'il faudra de toute façon renouveler ;
• les procédures de déploiement, ou à défaut une description de la façon dont l'application est mise en ligne ;
• la liste des anomalies connues et des fonctions non terminées.

Le code seul ne suffit pas. Un repreneur qui ignore comment l'application est déployée, ou pourquoi telle règle métier existe, avance à tâtons.

La question de la propriété du code

C'est la question que tout le monde pose, et celle où il faut le plus de prudence. Quelques repères, qui ne remplacent pas l'avis d'un avocat :

• en droit français, un logiciel développé par un salarié dans l'exercice de ses fonctions revient en principe à l'employeur ;
• un logiciel développé par un prestataire extérieur reste en principe à son auteur, sauf cession écrite qui précise l'étendue des droits cédés ;
• payer les factures ne suffit pas, à lui seul, à transférer les droits.

Concrètement, les droits sont définis au cas par cas dans le contrat. Relisez le contrat, les devis signés, les conditions générales du prestataire et les éventuels avenants. Notre article sur la propriété du code source détaille les cas de figure. Si le prestataire refuse de remettre le code ou conteste vos droits, consultez un avocat avant toute action : un repreneur ne doit pas travailler sur un code dont vous n'avez pas le droit de disposer.

Si le prestataire est en procédure collective, adressez-vous à l'administrateur ou au liquidateur désigné par le tribunal. Le délai pour déclarer vos créances est court et se compte à partir de la publication au BODACC : faites-vous accompagner sans attendre.

L'état des lieux : ce qui est réutilisable

Avant de décider quoi que ce soit, faites évaluer ce qui existe. L'objectif n'est pas de juger l'ancien prestataire, mais de répondre à trois questions :

1. Le code est-il complet et déployable ? Peut-on reconstruire l'application à partir du dépôt, sur un nouvel environnement, sans l'aide de l'ancien prestataire ?
2. Les fondations sont-elles saines ? Architecture, modèle de données, sécurité, dépendances à jour.
3. Quel est l'écart avec le besoin ? Ce qui fonctionne, ce qui manque, ce qui fonctionne mal.

Le premier test est le plus révélateur : un repreneur qui n'arrive pas à redéployer l'application à partir du code remis sait déjà que la reprise sera longue. Le détail des points à examiner (code, dépendances, sécurité, données, hébergement, documentation) est dans notre guide auditer une application existante.

Finir, stabiliser ou reconstruire

L'état des lieux débouche sur l'une de quatre décisions.

Deux pièges guettent cette décision.

Le coût déjà dépensé. « Nous avons déjà payé 60 % » n'est pas un argument technique. La seule question utile est le coût restant pour arriver à un outil fiable, dans chaque scénario.

La réécriture par principe. Un repreneur qui propose systématiquement de tout refaire, sans état des lieux, cherche peut-être d'abord à travailler sur sa propre technologie. À l'inverse, un code fragile qu'on s'acharne à finir coûte souvent plus que sa reconstruction. Notre article sur la dette technique aide à lire ce diagnostic.

Dans tous les cas, rien n'est perdu de ce qui a été appris : les maquettes, les règles métier, les données de test et les retours des premiers utilisateurs accélèrent n'importe quelle suite. Si la décision penche vers une reconstruction, ou si le besoin a évolué, le plus rassurant est de revoir le projet avant de réinvestir : un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés, peut partir de ce qui existe déjà (maquettes, écrans en ligne, cahier des charges).

Choisir le repreneur

Reprendre le code d'un autre est un exercice particulier. Quelques questions pour choisir :

• Exige-t-il un état des lieux avant de chiffrer ? Un prix ferme sans avoir vu le code est soit imprudent, soit gonflé pour couvrir l'inconnu.
• Connaît-il la technologie utilisée ? Ou propose-t-il d'emblée de tout migrer vers la sienne ?
• Dit-il clairement ce qu'il garantit ? Un repreneur s'engage sur ce qu'il corrige et développe, pas sur l'existant qu'il n'a pas écrit. C'est normal, à condition que la frontière soit écrite.
• Prévoit-il de rendre le projet autonome ? Dépôt et comptes à votre nom, documentation, procédure de déploiement : l'objectif est de ne plus jamais dépendre d'une seule personne.
• Comment est-il payé ? Une reprise peut se faire au forfait par étapes (état des lieux, stabilisation, évolutions), ce qui limite le risque. Notre article forfait ou régie détaille la différence.

Les clauses à ne plus oublier

La reprise est le bon moment pour écrire ce qui manquait dans le premier contrat :

• comptes, dépôt, domaine et hébergement au nom de votre entreprise ;
• remise du code et de la documentation à chaque étape, pas seulement à la fin ;
• droits sur le code définis au cas par cas dans le contrat, noir sur blanc ;
• une clause de réversibilité qui décrit la sortie, avant d'en avoir besoin.

Le calendrier type d'une reprise

Chaque projet est différent, mais l'enchaînement est presque toujours le même :

1. Sécurisation : accès, sauvegardes, transferts de comptes.
2. État des lieux : redéploiement à blanc, évaluation, rapport.
3. Décision : finir, stabiliser, reconstruire ou recadrer.
4. Stabilisation : corrections bloquantes, mises à jour de sécurité, tests sur les parcours critiques.
5. Reprise des évolutions, par petites livraisons visibles.

Chaque étape produit un résultat que vous pouvez juger avant de financer la suivante. C'est la meilleure protection contre un deuxième abandon.

Par où commencer

Commencez par l'inventaire des comptes, aujourd'hui, avant toute autre démarche. Le reste de la liste (sauvegarde, rassemblement des livrables, état des lieux) suit dans l'ordre, sans attendre d'avoir choisi un repreneur.