La plupart des applications à moitié finies arrivent de la même façon. Un freelance a disparu. Un code a été hérité et personne ne le comprend. Ou un build IA est arrivé à « presque fini » puis a simplement cessé d'avancer. Les trois sont courants, et les trois sont en général récupérables. La première étape n'est jamais plus de code : c'est un regard honnête sur ce que vous avez vraiment.
Pourquoi les projets s'arrêtent
Les projets échouent rarement pour une seule raison spectaculaire. Ils s'arrêtent parce que le périmètre a gonflé sans que le budget suive, parce que ce n'était pas la bonne personne aux commandes, parce qu'il n'y a jamais eu de cahier des charges clair, ou parce que le fondateur et le développeur ont lentement cessé de se comprendre. Et de plus en plus, ils s'arrêtent au mur des 80% : un build IA ou no-code qui a l'air presque terminé mais ne peut pas passer en production, un écart que nous couvrons dans du prototype IA au produit réel.
Étape une : l'audit
Avant que quiconque promette un délai, il faut lire le code. Un vrai audit répond honnêtement à une courte liste de questions :
- Peut-on le faire tourner ? Un build qui ne marche que sur le portable du dernier développeur est un signal d'alerte, et il est réparable.
- Est-il lisible ? Un code clair et conventionnel peut être repris. Un enchevêtrement écrit dans l'urgence ne le peut parfois pas, et cela change le calcul.
- Vos données sont-elles en sécurité ? Clés exposées, bases ouvertes et sauvegardes manquantes sont les premières choses à trouver et les premières à corriger.
- Qu'est-ce qui est réellement fait ? « Fini à quatre-vingt-dix pour cent » veut souvent dire que les parties visibles marchent et que les parties difficiles ont été sautées. L'audit sépare les deux.
- Quel est le chemin le plus rapide et le plus sûr ? Le but de l'audit est une décision, pas un rapport.
Sauver, refaire la fondation, ou repartir
Un audit mène à l'un de trois résultats, et être honnête sur lequel, c'est toute la valeur :
- Sauver. La fondation est saine et le travail est vraiment bien avancé. Nous le finissons, le durcissons et le lançons. C'est le meilleur cas, et le plus fréquent.
- Refaire la fondation. L'interface et l'idée méritent d'être gardées, mais la tuyauterie en dessous non. Nous gardons ce qui est bon et refaisons le reste, ce qui est souvent plus rapide que de le démêler.
- Repartir. Parfois la route la plus rapide est vraiment un build propre, en utilisant l'ancien travail comme brief détaillé. Nous ne le disons que quand c'est vrai, parce que c'est la réponse la moins bienvenue.
« Presque fini » est l'endroit le plus cher où un projet puisse rester. Le coût, c'est l'élan que vous perdez pendant qu'il attend.
Gérer la reprise en toute sécurité
Si un développeur précédent est hors circuit, protéger votre projet passe avant tout nouveau travail. Cela veut dire récupérer le code source, les comptes d'hébergement et de domaine et les clés de services à votre nom, changer les mots de passe et les clés que l'ancienne équipe connaissait, et écrire comment tout cela tourne pour que vous ne soyez plus jamais à une personne près d'être bloqué. Si vous ne pouvez pas récupérer le code du tout, un audit vous dira honnêtement combien doit être reconstruit.
Ce que coûte un sauvetage
Un audit est un travail petit et à périmètre fixe, et il vaut la peine en soi : même si vous emmenez les conclusions ailleurs, vous saurez enfin ce que vous avez. La finition ou la reconstruction qui suit dépend entièrement de ce que l'audit trouve, et c'est justement pour ça que personne ne devrait le chiffrer à l'aveugle. Méfiez-vous de qui annonce un prix avant d'avoir vu le code, dans un sens comme dans l'autre.
Comment éviter d'en avoir besoin la prochaine fois
- Commencez par un cahier des charges clair et écrit. Même une page. C'est ce contre quoi vous construisez et mesurez.
- Travaillez par jalons. De petits livrables visibles repèrent un projet qui dérive avant qu'il ne soit perdu.
- Possédez tout dès le premier jour. Votre code, vos comptes, vos clés, à votre nom.
- Choisissez une stack éprouvée. Une technologie répandue veut dire que la personne suivante peut la reprendre s'il le faut.
En résumé
Un build à l'arrêt est rarement aussi cassé qu'il en a l'air de l'extérieur. La plupart sont à un audit clair et un effort ciblé du lancement. La pire chose à faire est de le laisser à « presque fini », ou de verser encore de l'argent dans l'approche qui l'a arrêté. Si c'est là que vous en êtes, commencez par l'audit, et si vous pesez plutôt un nouveau build, voici ce que coûte un MVP en 2026.
