Freelance disparu : la marche à suivre pour sauver votre projet tech en 30 jours

Ce qui se joue vraiment dans les 30 jours qui suivent la disparition d'un freelance

Votre freelance ne répond plus depuis deux semaines. Le dernier message portait sur un correctif urgent, resté sans réponse. Un client attend une livraison qui n'arrive pas, la trésorerie ne tient plus très longtemps, et vous n'êtes même pas certain d'avoir encore accès à votre propre code. C'est la scène que vivent la plupart des fondateurs qui tapent « mon freelance a disparu » ou « mon freelance ne répond plus » dans un moteur de recherche à onze heures du soir.

Le premier réflexe, presque toujours, est de vouloir trancher vite : relancer un appel d'offres, recruter un nouveau développeur en urgence, ou décider sur le champ de tout reconstruire pour ne plus dépendre de ce qui a été laissé. Ce réflexe est compréhensible, il est aussi prématuré. Avant de décider quoi que ce soit sur le plan technique, il faut d'abord établir ce que vous possédez réellement, ce à quoi vous avez accès, et ce que contient le projet abandonné. Sans cette étape, toute décision se prend à l'aveugle.

Ce n'est pas non plus une situation à traiter seul dans l'urgence sans méthode. Les trente jours qui suivent la disparition d'un prestataire suivent en général la même séquence, quel que soit le secteur : reprendre l'accès, auditer ce qui existe, prioriser ce qui doit fonctionner en premier, puis décider comment continuer. Sauter une étape pour aller plus vite rallonge presque toujours le délai final.

Attendre un retour du freelance avant d'agir est la pire des options, même si elle paraît la plus prudente sur le moment. Chaque semaine de silence supplémentaire réduit vos chances de récupérer un accès à l'amiable, complique la relation avec votre propre client si une échéance est en jeu, et laisse le doute s'installer sur ce que contient réellement le projet. Agir vite ne veut pas dire agir dans la panique, ça veut dire commencer par ce qui est actionnable dès aujourd'hui, indépendamment de ce que le freelance décide de faire ou non.

Le premier obstacle n'est jamais le code, c'est l'accès

Avant de juger la qualité de ce qui a été développé, vérifiez d'abord ce à quoi vous avez réellement accès. Un nombre significatif de projets bloqués ne le sont pas pour des raisons techniques, mais parce que l'hébergement, le nom de domaine, le dépôt de code ou les identifiants de base de données ont été créés au nom personnel du freelance, sur un compte que vous ne contrôlez pas. Tant que cet accès n'est pas repris, aucun audit ni aucune décision de sauvetage n'a de sens.

La liste à établir en premier tient en quelques lignes : qui détient le compte d'hébergement et le nom de domaine, où se trouve le dépôt de code source et sous quel compte, qui a la main sur les variables d'environnement et les identifiants de base de données, quels outils tiers (paiement, e-mailing, authentification) sont connectés au projet et sous quel accès. Rassemblez en parallèle vos preuves de propriété : contrat de prestation, factures, échanges par e-mail. Ce sont ces preuves qui vous permettront de faire valoir votre demande auprès d'un hébergeur ou d'un registrar si le freelance reste injoignable.

Si le contrat initial prévoyait une cession de droits sur le code produit, ce point seul suffit dans la plupart des cas à débloquer un accès auprès d'un support technique, même sans coopération du prestataire. Si aucun contrat écrit n'existait, la situation se complique, mais elle n'est pas nécessairement bloquée : les factures et les échanges peuvent suffire à démontrer une relation commerciale et un droit d'usage. Dans les cas les plus tendus, une mise en demeure rédigée par un avocat accélère souvent la restitution des accès, sans que cela retarde la partie technique du dossier.

Un audit honnête, pas un jugement sur la qualité du code

Une fois l'accès repris, la tentation suivante est de lire le code ligne par ligne pour se faire une opinion. C'est une perte de temps dans une situation où chaque jour compte. Un audit utile ne cherche pas à noter le travail du freelance précédent, il cherche à répondre à une seule question : les deux ou trois parcours qui font tourner votre activité peuvent-ils tenir en production, oui ou non. Le reste du code peut attendre.

Cette question prend tout son sens quand le projet a été construit à grande vitesse avec l'aide de l'intelligence artificielle, sans conception préalable du modèle de données ni des règles métier. C'est une situation de plus en plus fréquente parmi les projets qui finissent bloqués avant leur mise en production.

« Le vibe coding sans cadrage égale bombe à retardement. Un freelance plus une IA sans conception égale dette technique qui bloque la mise en prod. »

Un audit ciblé sur les parcours critiques révèle en quelques jours si les blocages sont concentrés sur des zones précises (ce qui est le cas le plus fréquent) ou si le problème touche les fondations mêmes du projet, modèle de données incohérent sur l'ensemble du produit, architecture incapable d'encaisser un usage réel. Le premier cas se répare. Le second demande une reconstruction ciblée, rarement une reconstruction totale. Notre article sur la dette technique invisible produite par le vibe coding détaille les signaux qui permettent de distinguer les deux situations avant même de lancer l'audit.

Prioriser par impact business, pas par propreté du code

La question qui doit trancher n'est pas « ce code est-il propre », c'est « qu'est-ce qui doit absolument fonctionner pour que mon contrat, mon lancement ou mon chiffre d'affaires tienne ». Chez Leando, on appelle ça la priorisation par impact business : classer les corrections par ce qu'elles protègent commercialement, jamais par ce qui semble techniquement le plus urgent à corriger en premier. Ce principe exclut une chose précise : refactorer une zone du code parce qu'elle est mal écrite, si elle ne bloque rien de critique pour votre activité.

Ce recadrage va souvent à l'encontre de l'instinct d'un développeur, qui a tendance à vouloir corriger ce qui saute aux yeux techniquement, pas ce qui compte le plus commercialement. En situation de reprise, c'est le business qui doit diriger la technique, jamais l'inverse. Une fonctionnalité imparfaite mais non critique peut rester en l'état plusieurs semaines de plus sans conséquence. Un parcours qui conditionne un contrat ne peut pas attendre un jour de plus que nécessaire.

Pour aller plus loin sur les critères qui distinguent une stabilisation ciblée d'une reconstruction complète, une fois l'audit réalisé : refaire ou sauver un projet en crise, les critères qui doivent trancher.

Ce que ça a donné quand on n'a pas cédé au réflexe de tout reconstruire

Une startup sport-tech est arrivée dans cette situation exacte : une application développée par un freelance qui avait massivement utilisé l'IA sans cadrage préalable, une mise en production impossible malgré plusieurs tentatives, et un contrat avec Decathlon en jeu. Le budget restant ne permettait aucune reconstruction complète. L'audit a montré que les blocages critiques se concentraient sur un nombre restreint de zones, un modèle de données mal pensé et quelques parcours mal gérés, pendant que l'essentiel du reste fonctionnait.

La priorisation par impact business a suivi le principe posé plus haut : les corrections nécessaires à la mise en production des parcours liés au contrat Decathlon sont passées en premier, le reste du code, imparfait mais non bloquant, est resté en l'état. Aucune ligne n'a été réécrite par souci d'élégance technique, seulement là où le contrat l'exigeait. Résultat : une mise en production réussie là où elle était jugée impossible quelques semaines plus tôt, et un contrat préservé. Les fondateurs ont résumé le contraste avec le prestataire précédent en une phrase spontanée : « jour et nuit ». Ce cas illustre aussi une réalité que beaucoup de fondateurs découvrent après coup, un projet repris n'a rien à gagner à repartir sans documentation, comme le montre notre article sur ce que les freelances livrent rarement au-delà du code.

Si vous êtes actuellement dans cette situation, ne commencez pas par juger le code laissé derrière lui. Commencez par dresser la liste précise de ce à quoi vous n'avez pas accès, contactez les supports techniques concernés avec vos preuves de propriété dès aujourd'hui, et faites auditer uniquement les deux ou trois parcours qui conditionnent votre revenu ou votre contrat le plus critique avant de décider quoi que ce soit sur le reste.