Votre projet tech a 6 mois de retard : par où reprendre sans tout jeter

Pourquoi un projet prend-il 6 mois de retard sans que personne ne l'ait vu venir ?

Le retard n'apparaît jamais d'un coup. Il s'accumule, semaine après semaine, jusqu'à devenir visible. Dans la plupart des cas que je rencontre, les causes se répètent.

• Le périmètre bouge en permanence. Chaque réunion ajoute une exigence, aucune n'en retire. Le projet vise une cible qui recule.

• La dette technique n'est jamais remboursée. On code vite pour la démo, puis on construit dessus. Un jour, chaque modification en casse trois autres.

• Le bus-factor est de 1 sans que ce soit assumé. Une personne détient la connaissance clé, part ou décroche, et tout ralentit.

• Le "presque fini" masque le travail réel. Le dernier 20 % — tests, intégration, mise en production — représente souvent la moitié de l'effort.

Avant de reprendre, il faut nommer la cause dominante. On ne soigne pas un problème de périmètre avec plus de développeurs.

Comment faire un état des lieux honnête sans y passer un mois ?

L'objectif n'est pas un audit exhaustif. C'est une photographie suffisante pour décider. En quelques jours, je regarde trois choses.

• Ce qui tourne réellement en production — pas ce qui est censé fonctionner sur le poste d'un développeur.

• Le code qui porte la valeur métier versus le code accessoire. On garde le premier, on questionne le second.

• Les points de rupture : dépendances obsolètes, absence de tests sur les parcours critiques, secrets en clair, environnements non reproductibles.

À la fin, vous devez pouvoir répondre à une question simple : si je livrais demain, qu'est-ce qui casserait ? Cette liste devient votre plan de travail.

Faut-il tout réécrire ou récupérer l'existant ?

La réécriture totale est presque toujours une mauvaise idée. Elle repart de zéro sur un planning déjà en retard, jette la connaissance métier accumulée, et rejoue les mêmes erreurs. Je la réserve à des cas précis.

Récupérer l'existant quand…

• Le cœur métier fonctionne et rend service, même imparfaitement.

• Les problèmes sont localisés : un module, une couche, une intégration.

• Vous avez besoin de valeur en production sous quelques semaines, pas dans un an.

Réécrire une partie ciblée quand…

• Un composant précis coûte plus cher à maintenir qu'à remplacer.

• La technologie choisie est une impasse démontrée, pas une simple préférence.

La règle : on isole ce qui tient, on remplace ce qui bloque, morceau par morceau. Le système reste vivant pendant qu'on le répare.

Comment reconstruire un plan crédible qui tienne cette fois ?

Un plan qui a déjà dérapé de 6 mois n'inspire plus confiance. Il faut en produire un que l'on pourra vérifier vite.

• Gelez le périmètre. Aucune nouvelle fonctionnalité tant que le projet n'est pas de nouveau livrable. Ce gel est temporaire, mais il est non négociable.

• Définissez le plus petit incrément utile. Quelle version, même réduite, peut aller en production et rendre service ? Visez-la en premier.

• Travaillez par jalons de deux semaines. Chaque jalon produit quelque chose de démontrable. Un plan qui ne se vérifie qu'à la fin ne se vérifie jamais.

• Remettez un seul responsable de bout en bout. De la décision d'architecture au déploiement, une personne assume la continuité. C'est ce qui met fin aux transferts qui perdent l'information.

Ce plan ne promet pas de rattraper le retard d'un coup. Il promet de rendre chaque semaine mesurable — et c'est exactement ce qui manquait.

Quand faut-il arrêter le projet plutôt que le sauver ?

Sauver n'est pas toujours la bonne décision. Je le dis quand c'est le cas, parce que continuer coûterait plus cher que reconnaître l'impasse. Posez-vous ces questions.

• Le besoin métier initial existe-t-il encore, ou le marché a-t-il changé ?

• Le coût pour finir dépasse-t-il la valeur attendue une fois livré ?

• Existe-t-il une solution du marché qui couvre 80 % du besoin pour une fraction du budget restant ?

Un arrêt lucide vaut mieux qu'un acharnement coûteux. Mais dans la majorité des cas, un projet à 6 mois de retard n'est pas mort : il est mal piloté. Et cela, ça se répare.