Refaire ou sauver un projet en crise : les critères qui doivent trancher

Le réflexe en crise : tout raser

Un fondateur qui découvre que son produit ne peut pas passer en production a un réflexe presque universel : tout reprendre à zéro. Le code a été livré par un freelance ou une agence, souvent avec un usage massif de l'IA pour aller vite, et le résultat ne tient pas : bugs qui n'ont rien d'organique, architecture qui ne supporte aucune évolution, mise en production qui échoue à chaque tentative. Face à ce constat, l'instinct dit que rien n'est fiable, donc rien n'est récupérable.

Ce diagnostic instinctif arrive presque toujours au pire moment pour décider à froid : un contrat client dépend de la livraison, le budget initial a déjà été largement consommé, et l'équipe fondatrice découvre l'ampleur du problème sous la pression d'une échéance qui ne bougera pas. Ce n'est pas un contexte propice à une décision froide, c'est justement pour ça qu'il faut des critères posés à l'avance plutôt qu'une réaction dans l'instant.

Cet instinct est compréhensible. Il est aussi, la plupart du temps, une mauvaise décision business. Une reconstruction complète coûte en temps et en budget ce qu'une startup en crise n'a justement plus, et le contrat ou le client qui attendait une livraison n'attendra pas que le produit renaisse de zéro.

Il y a souvent une couche supplémentaire à ce réflexe : la relation avec le prestataire précédent s'est dégradée, la confiance a disparu, et « tout raser » devient aussi une manière symbolique de tourner la page. C'est une réaction humaine compréhensible, mais elle mélange une décision technique avec une décision émotionnelle, et ce mélange coûte cher quand le budget ne pardonne aucune erreur de priorisation.

Pourquoi « tout refaire » est rarement la bonne décision

Un code vibe-codé sans cadrage ne dégrade pas tout de façon uniforme. Il concentre en général ses dégâts sur quelques zones : un modèle de données mal pensé, des effets de bord non maîtrisés sur un parcours précis, une gestion d'erreurs absente là où elle serait critique. Le reste du code fonctionne souvent correctement, ou presque. Tout raser, c'est jeter aussi ce qui marche.

Le vrai risque n'est pas technique, il est de confondre la propreté du code avec l'objectif business. Un fondateur en crise n'a pas besoin d'un code exemplaire, il a besoin que le produit fonctionne à temps pour honorer un engagement. Ces deux objectifs se recoupent rarement autant qu'on l'imagine sous le coup du stress.

Il y a aussi un coût caché à la reconstruction complète que les fondateurs sous-estiment systématiquement : le temps. Refaire, même vite, prend des semaines pendant lesquelles rien n'est en production. Sauver, quand c'est possible, produit un résultat livrable en quelques jours sur les parcours qui comptent, et le reste peut être remis au propre ensuite, une fois la pression retombée.

Reconstruire à l'identique présente aussi un risque qu'on oublie souvent de nommer : celui de reproduire les mêmes erreurs, plus vite. Un cadrage bâclé la première fois ne devient pas meilleur parce qu'on recommence sous pression avec encore moins de temps. Sans un diagnostic qui explique pourquoi le code a dérapé, une deuxième tentative risque de dériver de la même façon, avec le budget en moins pour la corriger une troisième fois.

Les critères qui doivent trancher

Diagnostic honnête avant toute décision. Un audit du code, centré sur les parcours critiques, révèle en quelques jours ce qui est récupérable et ce qui ne l'est pas. La question n'est pas « ce code est-il propre », c'est « ce code peut-il tenir en production sur les scénarios qui comptent pour le business ». Ce sont deux questions différentes, et seule la seconde doit orienter la décision.

Priorisation par impact business, jamais par état technique. Tout ce qui touche au parcours qui conditionne un contrat ou un revenu passe en premier. Le reste attend. Cette hiérarchie va à l'encontre du réflexe naturel d'un développeur, qui a tendance à vouloir corriger ce qui est le plus visible techniquement, pas ce qui compte le plus commercialement. En situation de crise, le business doit diriger la technique, jamais l'inverse.

Budget disponible comme contrainte, pas comme détail. Une startup en crise a rarement la marge financière d'une reconstruction complète. Accepter cette contrainte dès le diagnostic évite de proposer un plan idéal mais inapplicable. La bonne solution est celle qui tient dans le budget réel, pas celle qui serait la plus élégante sur le papier.

Séparer l'urgent du reste, explicitement. Tout ne se règle pas en même temps, et vouloir tout stabiliser d'un coup dilue l'effort sur ce qui compte vraiment. Un plan de sauvetage sérieux distingue trois niveaux : ce qui bloque la mise en production et doit être corrigé immédiatement, ce qui fragilise le produit sans le bloquer et peut attendre quelques semaines, et ce qui relève du confort technique sans urgence business. Traiter les trois niveaux avec la même priorité revient à n'en traiter aucun correctement.

Cette hiérarchie explicite a un second bénéfice, moins évident mais tout aussi utile : elle rassure une équipe fondatrice en plein doute. Voir clairement que certains problèmes sont classés « non urgent » plutôt que simplement ignorés change la perception de la situation. Ce n'est plus le chaos, c'est un plan avec un ordre, même si tout n'est pas résolu le premier jour.

Ce que ça a donné sur un projet réel

Une startup sport-tech est arrivée avec une application vibe-codée par un freelance, une mise en production impossible, et un contrat avec Decathlon en jeu. Le budget était limité, sans marge pour une reconstruction complète. L'audit a montré que les blocages critiques se concentraient sur un nombre restreint de zones, pas sur l'ensemble du produit.

La décision a suivi les critères ci-dessus : pas de refonte totale, une priorisation stricte par impact sur le contrat en jeu, une remise au propre des zones critiques (modèle de données, effets de bord, architecture) sur les parcours qui comptaient. Le reste du code, imparfait mais non bloquant, est resté en l'état pour ne pas diluer l'effort sur ce qui ne mettait rien en péril à court terme.

Résultat : mise en production réussie là où elle était impossible quelques semaines plus tôt, et le contrat Decathlon préservé. Le budget initial, contraint dès le départ, a été respecté parce que le plan de sauvetage avait été dimensionné pour tenir dedans, pas pour atteindre un idéal technique hors de portée. Ce cas est documenté sur la page sauvetage vibe-code, mise en prod Startup Sportech.

« Sauver plutôt que refaire : avec un budget limité, la bonne approche est de stabiliser l'existant, pas de tout reconstruire. Le business drive la technique, pas l'inverse. »

Le retour des fondateurs, une fois le produit stabilisé, a été spontané : « jour et nuit » par rapport à l'implication du prestataire précédent. Ce cas illustre par la négative ce que le vibe coding sans cadrage produit en quelques semaines. Il illustre aussi, par la positive, qu'une crise technique n'est pas toujours une condamnation à tout reconstruire.

Ce type de situation dépasse le seul cas du vibe coding. Un projet repris après le départ d'un développeur, une agence qui a fermé en cours de mission, un freelance injoignable : le point commun n'est jamais la cause de la crise, c'est la tentation de répondre à l'urgence par une décision radicale plutôt que par un diagnostic. Le réflexe à corriger est le même, quelle que soit l'origine du problème. Pour comprendre comment cette dette technique se constitue en amont, les risques spécifiques aux projets IT pilotés par l'IA détaillent les signaux à surveiller avant qu'un projet bascule en crise.

Ce qu'il faut faire avant de décider

Si vous êtes face à un produit qui ne passe pas en production, résistez à la décision immédiate de tout raser. Faites d'abord réaliser un audit ciblé sur les deux ou trois parcours qui conditionnent votre revenu ou votre contrat le plus critique. Listez séparément ce qui bloque ces parcours précis et ce qui reste un problème de confort technique. Vous aurez alors une base factuelle pour décider, plutôt qu'une réaction sous le coup du stress qui peut coûter des semaines que vous n'avez pas.

Écrivez ensuite, noir sur blanc, le budget réel dont vous disposez et le délai que votre contrat ou votre trésorerie vous impose. Confrontez ces deux chiffres au plan de sauvetage proposé avant de le valider. Un plan qui dépasse l'un des deux n'est pas un mauvais plan technique, c'est un plan mal calibré pour la situation dans laquelle vous êtes. La bonne décision n'est jamais la plus propre dans l'absolu, elle est la plus adaptée à ce que vous pouvez réellement tenir.