Reprendre un projet web laissé par un freelance : par où commencer

Quand un freelance quitte un projet, ne cherchez pas d'abord à améliorer quoi que ce soit : récupérez les accès, comprenez ce qui existe, puis seulement décidez. Le risque n'est pas que le code soit mauvais, c'est de ne pas savoir ce que vous possédez réellement.

L'analogie : reprendre un restaurant

Vous rachetez un restaurant. Avant de changer la carte, vous voulez les clés, savoir où se trouve le compteur électrique, qui sont les fournisseurs, et ce qu'il y a dans les frigos. Changer le menu vient après. Un projet web, c'est pareil : on commence par l'inventaire.

Étape 1 : récupérer les accès

C'est la priorité, car sans eux, on ne peut rien faire, et parfois on ne peut plus rien prouver. Faites la liste de tout ce que le projet utilise :

• Le code : le dépôt (l'endroit où il est stocké, par exemple GitHub) doit être à votre nom ou à celui de votre entreprise, pas sur le compte personnel du freelance.
• L'hébergement : le service qui fait tourner le site.
• Le nom de domaine : l'adresse du site, avec son registrar (l'organisme où il est enregistré).
• La base de données : là où vivent les données de vos utilisateurs.
• Les services tiers : paiement, envoi d'e-mails, authentification, statistiques.
• Les comptes administrateur de l'application elle-même.

Pour chacun, la question est la même : qui en est propriétaire ? Si c'est le freelance, demandez un transfert de propriété, pas seulement un mot de passe.

Étape 2 : se faire une idée de l'existant

Sans lire le code en détail, on cherche à répondre à quelques questions simples :

1. Comment l'application est-elle mise en ligne, et peut-on le refaire ?
2. Existe-t-il une copie de secours des données, et sait-on la restaurer ?
3. Y a-t-il une documentation, même sommaire ?
4. Des tests existent-ils pour s'assurer qu'une modification ne casse rien ?
5. Les secrets (clés, mots de passe de services) sont-ils rangés correctement ? Voir clé API exposée.

Rien de tout cela n'est un jugement sur le travail du freelance : c'est une photographie de départ.

Étape 3 : faire relire par quelqu'un d'extérieur

Une relecture indépendante dit ce qui est solide, ce qui est fragile, et ce qui est urgent. Elle évite deux erreurs fréquentes : tout jeter par réflexe, ou tout garder par peur. Pour trancher entre les deux, voir réécrire ou réparer.

Étape 4 : sécuriser avant d'ajouter

Avant de développer de nouvelles fonctionnalités :

• changez les mots de passe et les clés que le freelance connaissait ;
• retirez ses accès une fois le transfert terminé ;
• vérifiez qu'une sauvegarde existe ;
• vérifiez qui peut accéder à quelles données.

Ce n'est pas de la méfiance : c'est la même hygiène que lorsqu'un salarié change de poste.

Ce qu'il faut éviter

• Tout réécrire immédiatement, sans avoir compris ce qui existe.
• Attendre une panne pour découvrir qu'on n'a pas les accès.
• Laisser un accès ouvert à un ancien prestataire par simple oubli.
• Reprendre sans transmission. Si le freelance est encore joignable, une heure d'échange avec lui vaut souvent beaucoup de lecture de code.

À retenir

Reprendre un projet commence par un inventaire : les accès, les propriétaires, l'état réel du code. Les décisions viennent après. Ce qui compte d'abord, c'est de savoir ce que vous possédez et de pouvoir le faire fonctionner sans la personne qui l'a construit.

Et pour votre produit ?

Si vous héritez d'un projet et que vous ne savez pas par où prendre les choses, notre accompagnement de reprise de projet commence justement par cet inventaire, puis établit ce qui doit être stabilisé en premier. Un échange de 30 minutes permet de voir où vous en êtes et ce qui est faisable.