Ton développeur a disparu ? Comment reprendre un projet web abandonné

Image : wocintechchat.com — Openverse (by)

Il y a un scénario que j’entends trop souvent. Un fondateur, un gérant de PME, un indie builder qui a investi plusieurs milliers d’euros dans un projet web. Et un matin, plus de nouvelles. Le développeur ne répond plus. L’agence a fermé. Le freelance est passé à autre chose. Et toi, tu te retrouves avec un site en prod dont tu ne contrôles rien, un code que tu n’as jamais vu, et une boule au ventre.

Ce n’est pas une situation rare. C’est même tellement fréquente que j’ai décidé d’écrire ce guide une bonne fois pour toutes.

Le scénario classique : quand le projet t’échappe

Il existe plusieurs variantes du même problème.

L’agence qui ferme. Tu avais signé avec une petite agence web locale. Ils faisaient du bon travail, la relation était sympa. Et puis, sans prévenir, le site vitrine disparaît, les mails rebondissent, et tu réalises que personne ne t’a jamais donné accès au dépôt Git. Ni à l’hébergeur. Ni au registrar du domaine.

Le freelance injoignable. Celui-là est encore plus courant. Un développeur en mission longue, souvent recommandé par un ami, qui gère tout : le code, le déploiement, les accès. La relation est informelle, la confiance est là, les contrats sont flous. Et un jour il change de vie, déménage à l’autre bout du monde, ou simplement arrête de répondre parce qu’il a trouvé un CDI.

Le code inaccessible. Parfois le développeur est encore là, mais le code ne l’est pas vraiment. Il est sur son ordinateur perso. Ou sur un compte GitHub à son nom. Ou dans un environnement de déploiement auquel tu n’as jamais eu accès. Tu paies l’hébergement depuis trois ans sans savoir ce qui tourne dessus.

Ces trois situations ont un point commun : elles révèlent une dépendance totale à une seule personne, sans filet. Et quand cette personne disparaît, tu te retrouves à reprendre un projet web dans le flou le plus complet.

Ce qui est frustrant, c’est que la plupart du temps, ce n’est pas de la mauvaise foi. C’est juste que personne n’a posé les bonnes questions au départ. Ni toi, ni lui.

La checklist de récupération : reprends le contrôle point par point

Avant même de penser à la technique, il faut sécuriser les accès. C’est la priorité absolue. Voici dans quel ordre attaquer.

1. Le nom de domaine

C’est le plus critique. Si tu perds le contrôle du domaine, tu perds tout.

• Identifie le registrar (OVH, Gandi, Namecheap, GoDaddy…). Tu peux utiliser who.is pour retrouver le registrar via le WHOIS.
• Vérifie si le domaine est à ton nom ou à celui du développeur. Si c’est à son nom, tu as un problème.
• Si le domaine est à ton nom mais que tu n’as pas les accès au compte, contacte le support du registrar avec tes justificatifs (SIRET, pièce d’identité, factures).
• Si le domaine est au nom du développeur, la situation est plus complexe. Selon les registrars, tu peux initier un transfert si tu as des preuves de paiement. Dans les cas extrêmes, un avocat peut être nécessaire.

Action immédiate : vérifie la date d’expiration du domaine. Si elle approche, c’est urgent.

2. L’hébergement

• Identifie où le site est hébergé. Regarde les DNS (via MXToolbox ou similaire), les factures de carte bancaire, les anciens mails.
• Hébergeurs courants : OVH, Infomaniak, Scaleway, AWS, Vercel, Netlify, DigitalOcean, Heroku.
• Contacte le support avec tes justificatifs. La plupart des hébergeurs ont des procédures de récupération de compte si tu peux prouver que tu es le propriétaire légitime.
• Si l’hébergement est payé par le développeur et refacturé, il a probablement la main. Négocie un transfert ou prépare-toi à migrer.

3. Le code source

C’est souvent là que ça coince.

• Est-ce que tu as un dépôt Git quelque part ? GitHub, GitLab, Bitbucket ?
• Si le dépôt est sous le compte du développeur, demande-lui un transfert de propriété (GitHub permet ça facilement).
• Si tu n’as aucun accès au code, tu peux parfois extraire les fichiers directement depuis le serveur si tu as accès SSH ou FTP à l’hébergement.
• En dernier recours : un développeur expérimenté peut reconstruire une partie du code à partir du site en production (pour le front) ou de la base de données (pour la logique métier).

4. La base de données

• Identifie le type de base de données (MySQL, PostgreSQL, MongoDB…).
• Récupère un dump complet dès que possible. C’est tes données : commandes, utilisateurs, contenus. Tout.
• Stocke ce dump dans plusieurs endroits. Maintenant.

5. Les services tiers

Fais la liste de tout ce qui gravite autour du projet :

• Compte email (Google Workspace, Zoho…)
• Outils d’analytics (Google Analytics, Plausible…)
• Passerelle de paiement (Stripe, PayPal…)
• Services d’envoi d’emails (Mailchimp, Brevo, Postmark…)
• CDN, services de fichiers (Cloudflare, AWS S3…)
• Certificats SSL

Pour chacun, vérifie qui est propriétaire du compte et si tu as les accès.

Comment évaluer si le code est reprenable : l’audit

Tu as récupéré le code. Maintenant la vraie question : est-ce que c’est récupérable, ou est-ce que c’est un tas de dette technique déguisé en projet ?

Un audit de code n’est pas une opération mystérieuse. C’est une évaluation structurée qui répond à une question simple : est-ce que je peux travailler avec ça, et à quel coût ?

Ce qu’on regarde en premier

La structure du projet. Est-ce que ça ressemble à quelque chose de reconnaissable ? Un framework connu (Laravel, Symfony, Rails, Next.js, Django…) ou un truc fait maison avec des conventions inventées ? Les projets sur des frameworks standards sont infiniment plus faciles à reprendre.

La gestion des dépendances. Est-ce qu’il y a un package.json, un composer.json, un requirements.txt ? Est-ce que les versions sont fixées ou flottantes ? Est-ce que les dépendances sont à jour ou vieilles de trois ans avec des failles de sécurité connues ?

La présence de tests. Zéro test = zéro filet de sécurité pour modifier quoi que ce soit. Ce n’est pas rédhibitoire, mais ça multiplie le risque de chaque intervention.

La documentation. Un README qui explique comment lancer le projet localement, c’est le minimum. S’il n’existe pas, chaque développeur qui reprend perd des heures à reconstituer l’environnement.

Les variables d’environnement et la configuration. Est-ce que les clés API sont dans le code (mauvais signe) ou dans des fichiers .env séparés ? Est-ce que les credentials de production sont hardcodés quelque part ?

L’historique Git. S’il existe, il est précieux. Il montre comment le projet a évolué, qui a fait quoi, et souvent explique des choix qui semblent arbitraires.

Les signaux d’alarme

• Du code copié-collé partout sans abstraction
• Des fonctions de 500 lignes
• Pas de séparation entre la logique métier et la présentation
• Des requêtes SQL construites par concaténation de chaînes (injection SQL potentielle)
• Des mots de passe en clair dans la base de données
• Un framework ou un langage en fin de vie (PHP 5, Angular 1…)
• Aucun système de déploiement documenté

Ce qu’un audit réaliste produit

Un bon audit te donne :

1. Une évaluation honnête de l’état du code (note globale + détail par zone)
2. Une liste des risques de sécurité immédiats
3. Une estimation du temps nécessaire pour remettre le projet en état de marche
4. Une recommandation claire : reprendre ou repartir

C’est ce dernier point qui compte le plus.

Repartir de zéro vs réparer : comment décider

C’est la décision la plus difficile, et c’est souvent celle où les gens se trompent. Soit parce qu’ils sont attachés à ce qui a été fait, soit parce qu’ils veulent éviter le coût d’une réécriture.

Voici les critères pour décider honnêtement.

Réparer vaut le coup si…

• Le code est sur un framework moderne et maintenu
• La logique métier est complexe et bien implémentée (même si le reste est brouillon)
• La base de données est propre et les données sont précieuses
• Le projet tourne en production avec des utilisateurs actifs qu’on ne peut pas se permettre de perdre
• L’estimation de reprise est inférieure à 40% du coût d’une réécriture complète

Repartir de zéro vaut le coup si…

• Le code est illisible, non documenté, et personne ne comprend comment il fonctionne
• La stack technologique est obsolète et ne sera plus maintenue
• Il y a des failles de sécurité structurelles impossibles à corriger sans tout réécrire
• Le projet a évolué dans une direction différente de ce qui a été codé, et la dette est trop lourde
• L’estimation de reprise dépasse 60-70% du coût d’une réécriture

La zone grise (entre 40% et 60%)

C’est là que ça devient subjectif. Dans ce cas, je regarde un critère supplémentaire : la vélocité future. Est-ce qu’en réparant, on va pouvoir avancer normalement dans six mois ? Ou est-ce qu’on va passer les deux prochaines années à contourner des problèmes hérités ?

Si la réponse est “on va souffrir longtemps”, la réécriture est souvent le meilleur investissement à long terme, même si elle fait mal à court terme.

Un point important : “repartir de zéro” ne veut pas dire ignorer l’existant. On peut réécrire proprement en gardant la logique métier, les données, et les apprentissages du premier projet. Ce n’est pas jeter, c’est reconstruire sur des bases saines.

Comment éviter que ça se reproduise

C’est la partie que tout le monde zappe parce qu’on est soulagé d’avoir résolu la crise. Et c’est exactement pour ça que le même problème se reproduit.

La propriété du code

C’est non-négociable : le code produit pour toi doit t’appartenir. Pas à l’agence, pas au freelance. À toi.

Concrètement :

• Le dépôt Git doit être sur un compte que tu contrôles (ou sur un compte d’organisation dont tu es admin)
• Le contrat doit mentionner explicitement le transfert de propriété intellectuelle du code
• Si un développeur refuse ces conditions, c’est un signal d’alarme

Les accès : la règle des trois

Pour chaque service critique (domaine, hébergement, dépôt de code, base de données), tu dois avoir :

1. Tes propres accès admin
2. Un accès de secours stocké dans un gestionnaire de mots de passe (Bitwarden, 1Password…)
3. Un contact support chez le prestataire si jamais tu perds tout

Ne délègue jamais la propriété d’un compte critique. Délègue l’accès, pas la propriété.

La documentation minimale

Tu n’as pas besoin d’une documentation exhaustive. Tu as besoin d’un README qui répond à ces questions :

• Comment lancer le projet en local ?
• Quels sont les services tiers utilisés et comment les configurer ?
• Comment déployer en production ?
• Quelle est l’architecture globale en deux paragraphes ?

Exige ce document à la fin de chaque phase de développement. Pas à la fin du projet, parce que la fin du projet n’arrive jamais vraiment.

Les sauvegardes

Mets en place des sauvegardes automatiques de ta base de données, indépendamment de ce que fait ton développeur. La plupart des hébergeurs proposent ça nativement. Active-le. Teste-le.

Les revues régulières

Tous les six mois, fais un point sur :

• Est-ce que tous les accès sont à jour ?
• Est-ce que les dépendances sont maintenues ?
• Est-ce que la documentation est encore juste ?

Ce n’est pas du micro-management. C’est de l’hygiène.

Le contrat

Je ne suis pas avocat, mais voici ce qu’un contrat de développement web devrait contenir au minimum :

• Clause de propriété intellectuelle (le code t’appartient à la livraison)
• Obligation de livraison du code source et des accès
• Clause de documentation
• Conditions de fin de mission (passation, délai de réponse…)

Si tu travailles avec un freelance sans contrat, tu prends un risque. Pas parce que les freelances sont malhonnêtes, mais parce qu’en cas de problème, tu n’as aucun recours.

Ce que j’ai appris de ces situations

J’ai repris des projets dans cet état. Des fois c’était récupérable. Des fois j’ai dû annoncer à un client que six mois de travail et 30 000€ n’étaient pas sauvables.

Ce que j’ai remarqué, c’est que le problème technique n’est presque jamais le vrai problème. Le vrai problème, c’est que la relation entre le client et le développeur n’a jamais été structurée pour protéger les deux parties. Le client n’a pas demandé les accès parce qu’il faisait confiance. Le développeur n’a pas documenté parce que personne ne lui a demandé. Et quand la relation se termine, il n’y a rien pour assurer la continuité.

Ce n’est pas une question de compétence ou de bonne volonté. C’est une question de structure.

La bonne nouvelle, c’est que c’est entièrement évitable. Pas avec des outils compliqués, pas avec des processus lourds. Juste avec quelques règles simples posées dès le départ.

Tu es dans cette situation en ce moment ?

Si tu lis cet article parce que tu es en train de vivre exactement ça, voici ce que je te conseille de faire maintenant, dans l’ordre :

1. Sécurise le domaine. C’est la priorité absolue.
2. Récupère une sauvegarde de la base de données si tu as accès à l’hébergement.
3. Documente tout ce que tu sais : les accès que tu as, les services que tu utilises, les contacts que tu peux encore joindre.
4. Fais évaluer le code avant de décider quoi que ce soit.

Si tu veux qu’on regarde ça ensemble, je fais des audits de code et des reprises de projet. Tu peux réserver un créneau ici pour qu’on fasse le point sur ta situation.

Et si tu n’es pas encore dans cette situation mais que tu veux t’assurer de ne jamais y arriver : même lien.

Tu as vécu une situation similaire ? Comment tu t’en es sorti ? Je suis curieux d’entendre ce qui a marché (ou pas) de ton côté.