Reprendre un projet de développement raté : méthode et étapes

Reprendre un projet de développement raté commence par une décision business, jamais par une revue de code. On rétablit d'abord le résultat que le projet devait produire, on audite l'existant à froid, on tranche entre reprendre et repartir, puis on relance par petites livraisons vérifiables. Le code n'est presque jamais le vrai problème.

Je suis Boris Bembinoff, fondateur de JUNR, un studio de développement sur mesure pour les PME de 11 à 50 salariés en phase de structuration. Reprendre un projet planté, en sauver la valeur ou décider proprement de l'arrêter, c'est l'un des cas qui reviennent le plus souvent à ma table. Voici la méthode que j'applique, étape par étape, et la façon de trancher la seule question qui compte vraiment : reprendre l'existant ou repartir de zéro.

Qu'est-ce qu'un projet de développement raté ?

Un projet de développement raté est un projet qui a cessé de produire de la valeur alors qu'il continue de consommer du temps et de l'argent. Concrètement : des livraisons en retard chronique, un périmètre qui gonfle sans jamais sortir, du code que plus personne n'ose toucher, un prestataire injoignable ou un dirigeant qui ne sait plus ce qu'il achète. Le budget monte, l'outil ne sort pas.

Un projet planté n'est pas un projet en difficulté passagère. Un projet en difficulté a un cap et rate une échéance. Un projet raté, lui, a perdu son cap : personne dans la pièce ne sait dire, en une phrase, la décision business que l'outil est censé rendre possible. C'est cette différence qui commande toute la suite.

Pourquoi un projet de développement échoue-t-il vraiment ?

Un projet de développement échoue rarement à cause du code, et presque toujours à cause d'une décision business qui n'a jamais été prise. La technique est réparable : on relit, on réécrit, on teste. Ce qui ne se répare pas tout seul, c'est un projet lancé sans réponse claire à la question « qu'est-ce que cet outil doit changer, pour qui, et mesuré comment ».

Le Standish Group suit les projets logiciels depuis les années 1990 dans son CHAOS Report. Son constat, répété d'édition en édition : une minorité seulement des projets tiennent à la fois le budget, le délai et le périmètre promis. La majorité dérape sur au moins un des trois. Votre projet planté n'a donc rien d'une anomalie honteuse. C'est même la norme silencieuse d'un secteur qui préfère ne pas trop en parler.

Vous allez me dire que c'est de l'agile : on avance par itérations, on ajuste en cours de route, c'est normal que ça bouge. Sauf que l'agile fait bouger une décision qui existe. Itérer, c'est ajuster un cap qu'on a posé. Dériver, c'est avancer sans cap à ajuster. On corrige un cap. On ne corrige pas une absence de cap. Et le flou, lui, arrange tout le monde un temps : il protège le prestataire qui « avance » et rassure le dirigeant qui « voit des écrans ». Puis la facture tombe.

La méthode en 5 étapes pour reprendre un projet planté

Reprendre un projet planté suit cinq étapes, et les quatre premières se règlent sans écrire une ligne de code. La méthode va de la décision business vers la technique, jamais l'inverse. On rétablit le cap, on regarde l'existant en face, on tranche, on cadre petit, puis on relance.

Étape 1 : rétablir la décision business que le projet devait servir

Rétablir la décision business est la première étape, avant tout audit technique. Avant de rouvrir le moindre fichier, je pose trois questions au dirigeant :

• À quoi saura-t-on que c'est réglé ? Si la réponse est une fonctionnalité, on n'y est pas encore. Si c'est un résultat opérationnel (« je ne perds plus deux jours par mois », « mes commerciaux arrêtent de ressaisir »), on tient le vrai objectif.
• Qu'est-ce que ça vous coûte, aujourd'hui, concrètement ? Un problème sans coût n'est pas un problème, c'est un agacement. Cette question fixe aussi le budget raisonnable de la reprise.
• Vous me demandez de reprendre un outil. Qu'essayez-vous vraiment d'obtenir ? C'est là que le besoin exprimé et le besoin réel se séparent.

Tant que ces trois réponses ne sont pas écrites noir sur blanc, réparer le code revient à rénover une maison sans savoir qui va y habiter. À presque chaque premier rendez-vous, c'est cette phrase qui manque, pas les compétences techniques.

Étape 2 : auditer l'existant sans tomber amoureux ni le brûler

Auditer l'existant, c'est mesurer ce que le code déjà écrit vaut réellement, sans s'y attacher par principe ni le jeter par dépit. On regarde trois choses : ce qui tourne en production et rend service, ce qui est récupérable moyennant travail, et ce qui coûtera plus cher à sauver qu'à refaire. Le piège existe des deux côtés : le dirigeant qui veut « rentabiliser » tout l'existant, et le prestataire qui veut tout réécrire parce que c'est plus confortable pour lui. Premier réflexe concret, avant même de lire une ligne : sécuriser les accès aux dépôts de code et aux identifiants, qui disparaissent vite quand un prestataire s'en va.

Étape 3 : trancher entre reprendre l'existant et repartir de zéro

Trancher entre reprendre et repartir se décide sur un seul critère : le coût de reprise comparé au coût de reconstruction, à valeur égale livrée. Si récupérer l'existant coûte durablement moins cher que repartir, on reprend. Sinon on repart, et ce n'est pas un aveu d'échec, c'est une décision assumée. Le détail de cet arbitrage tient dans le tableau plus bas.

Étape 4 : cadrer un périmètre livrable en quelques semaines

Cadrer un périmètre livrable, c'est choisir la plus petite version de l'outil qui produit un résultat réel, et la fixer. Pas la moitié du projet initial : la première brique qui, seule, change quelque chose au quotidien. Un projet planté a presque toujours grossi sans jamais sortir. On inverse la logique : on sort petit, vite, et on vérifie. La discipline du périmètre est ce qui sépare une reprise d'une rechute.

Étape 5 : relancer par petites livraisons vérifiables

Relancer par petites livraisons, c'est reprendre le développement en livrant des morceaux que vous pouvez tester vous-même, à intervalle court. Chaque livraison répond à une question simple : est-ce que ça marche, oui ou non, pour un usage réel. C'est là que le « nous » reprend la main : l'équipe JUNR construit et livre par incréments, et vous gardez à chaque étape la preuve que le budget produit quelque chose. Tout le contraire du tunnel de six mois qui accouche de la moitié du promis.

Reprendre l'existant ou repartir de zéro ?

Reprendre l'existant est le bon choix quand le code en place est maintenable et qu'une équipe extérieure peut le comprendre. Repartir de zéro s'impose quand sauver revient à payer deux fois. Le critère n'est jamais émotionnel (« on a déjà tant investi »), il est comptable : coût de reprise contre coût de reconstruction, pour la même valeur livrée.

Critère	Reprendre l'existant	Repartir de zéro
État du code	Lisible, documenté, repris par une autre équipe en quelques jours	Illisible, non documenté, compris de son seul auteur
Décision produit	Un cap existait, il faut le réaligner	Aucun cap n'a jamais été écrit
Socle technique	Stack moderne, encore soutenue	Techno obsolète ou impasse de maintenance
Périmètre encore utile	Une partie tourne déjà en production et sert	Rien de stable en production, tout est à valider
Coût comparé	Reprise durablement moins chère que reconstruire	Sauver coûte autant ou plus que refaire proprement
Délai avant valeur	Court : on capitalise sur l'acquis	La base ralentit plus qu'elle n'aide
Risque de replanter	Faible si la cause était le pilotage	Élevé si on repart sans changer de méthode

Un piège fausse presque toujours ce calcul, et il porte un nom : le biais des coûts irrécupérables. Vous avez payé six mois de développement, alors vous voulez sauver les six mois. Je comprends. Sauf que l'argent dépensé ne revient pas parce qu'on s'entête. La seule question qui vaille : à partir d'aujourd'hui, quel chemin coûte le moins cher pour arriver au résultat dont vous avez besoin ? Le passé ne vote pas. Et quand on reprend, notre rôle n'est pas de vous vendre la refonte la plus impressionnante. C'est de trouver le chemin le plus court vers le résultat, le plus rentable, pas le plus gros chantier.

Les erreurs courantes quand on reprend un projet raté

L'erreur la plus courante en reprise de projet, c'est de recommencer par le code au lieu de la décision business. Les reprises que je vois replanter une deuxième fois partagent presque toutes les mêmes réflexes.

• Relancer le développement avant d'avoir réécrit, en une phrase, ce que l'outil doit changer.
• Vouloir sauver tout l'existant pour « ne pas avoir payé pour rien ». L'argent déjà dépensé ne reviendra pas, il ne doit pas commander la suite.
• Reprendre le périmètre initial en entier, celui-là même qui a fait couler le projet.
• Changer de prestataire sans changer de cadre. Le même flou confié à une nouvelle équipe produit exactement le même résultat, en plus cher.
• Confondre activité et avancement : des écrans qui bougent ne prouvent pas qu'une décision a été prise.

Questions fréquentes

Combien de temps prend la reprise d'un projet planté ?

La reprise d'un projet planté produit un cadrage exploitable en quelques jours à quelques semaines, bien avant la première ligne de code reprise. Le diagnostic, décision business et audit de l'existant, va vite. Ce qui prend du temps, c'est la reconstruction éventuelle, et sa durée dépend directement de l'arbitrage reprendre ou repartir. Méfiez-vous de quiconque chiffre une reprise sans avoir regardé l'existant.

Faut-il jeter tout le code de l'ancien prestataire ?

Non, jeter tout le code de l'ancien prestataire par principe est une erreur aussi coûteuse que tout garder. La bonne décision se prend brique par brique : ce qui tourne et rend service reste, ce qui coûte plus à sauver qu'à refaire part. On juge le code sur sa maintenabilité, pas sur l'identité de qui l'a écrit.

Peut-on reprendre un projet sans les développeurs d'origine ?

Oui, on peut reprendre un projet sans ses développeurs d'origine, à une condition : que le code soit lisible et documenté par une autre équipe. C'est même le test décisif d'un projet sain. Un code que seul son auteur comprend n'est pas un actif, c'est une dépendance. Chez JUNR, on livre justement du code qu'une équipe extérieure peut reprendre à tout moment.

En résumé

Reprendre un projet de développement raté, c'est d'abord rétablir une décision business, puis laisser cette décision commander la technique. Les cinq étapes : rétablir le cap, auditer l'existant à froid, trancher entre reprendre et repartir, cadrer un périmètre qui sort vite, relancer par petites livraisons vérifiables. Le code se répare. Le flou, non : il se décide.

Un projet à l'arrêt que vous n'osez plus rouvrir ? Parlons de votre cas concret, en 30 minutes et sans engagement : je vous dis franchement s'il faut le reprendre ou repartir, et pourquoi.