Projet logiciel bloqué : dette technique, reprise ou réécriture ? 6 vérifications avant de décider

Un projet logiciel bloqué donne presque toujours envie de tout jeter et de repartir de zéro. C'est parfois la bonne décision. Mais c'est rarement la première à prendre, et c'est souvent la plus chère. Avant de décider, il faut comprendre pourquoi le projet est bloqué, et ce qui, dans l'existant, a encore de la valeur.

Ce guide explique ce qu'est la dette technique, comment la reconnaître, et les six vérifications que nous faisons pour trancher entre réparer, reprendre ou réécrire.

01Qu'est-ce que la dette technique ?

La dette technique désigne l'ensemble des raccourcis pris pendant le développement d'un logiciel : code écrit trop vite, absence de tests, documentation manquante, dépendances jamais mises à jour. Comme une dette financière, elle n'est pas un problème en soi au départ. Elle le devient quand les intérêts s'accumulent : chaque nouvelle fonction prend plus de temps, chaque mise en ligne casse quelque chose, et plus personne n'ose modifier le code.

Les signes qui ne trompent pas

• Les délais de chaque évolution s'allongent sans raison apparente.
• Corriger un bug en crée un autre ailleurs.
• Une seule personne comprend le code, ou plus personne.
• Les mises à jour de sécurité sont repoussées faute de temps.
• Le projet ne peut plus être installé sur une machine neuve.

02Les 6 vérifications avant de décider

1. Le projet se reconstruit-il encore ?

Premier test : peut-on reconstruire le projet à partir du dépôt, sur une machine neuve, en suivant une procédure écrite ? Si personne n'y arrive, le problème vient d'abord d'un manque de documentation et de configuration, pas forcément d'un mauvais code. C'est souvent réparable rapidement.

2. Qu'est-ce qui fonctionne en production ?

Listez ce que les utilisateurs utilisent réellement aujourd'hui. Une partie qui tourne, qui encaisse et que les clients connaissent a de la valeur, même si son code n'est pas parfait. La jeter, c'est perdre des années de corrections invisibles.

3. Les données sont-elles saines ?

La base de données est souvent l'élément le plus précieux d'un logiciel. Sa structure est-elle cohérente ? Des sauvegardes existent-elles et ont-elles été testées ? Une base saine permet de reconstruire autour sans rien perdre ; une base incohérente doit être traitée en priorité, quelle que soit la décision.

4. Les dépendances sont-elles à jour ?

Versions de frameworks dépassées, bibliothèques abandonnées, services tiers fermés : ces points expliquent très souvent pourquoi plus rien ne passe. Ils se mettent à jour par étapes, sans tout refaire.

5. La sécurité est-elle sous contrôle ?

Mots de passe en clair, clés d'API dans le code, accès administrateur partagés, absence de mises à jour : ces failles se traitent en premier, avant toute nouvelle fonctionnalité.

6. Combien coûte chaque option ?

Comparez trois scénarios chiffrés : réparer l'existant, le reprendre en le modernisant par morceaux, ou réécrire. Sans chiffres, la décision repose sur une impression, et l'impression pousse presque toujours à tout refaire.

03Réparer, reprendre ou réécrire : le tableau de décision

La reprise progressive a un avantage décisif : le service reste en ligne pendant tout le chantier. On remplace les parties fragiles une à une, en commençant par celles qui bloquent, et chaque étape est mise en ligne après vérification.

04Pourquoi tout réécrire est rarement la bonne idée

Une réécriture complète repart d'une page blanche, mais pas d'un problème simple. Le logiciel existant contient des centaines de cas particuliers découverts avec le temps : un format de date inattendu, un client qui paie autrement, une exception métier. Réécrire, c'est devoir tous les redécouvrir. Pendant ce temps, l'ancien logiciel doit continuer à tourner et à évoluer, et l'équipe se retrouve à maintenir deux produits à la fois.

05Pourquoi ajouter des développeurs ne suffit pas

Face à un projet en retard, le réflexe est souvent de renforcer l'équipe. C'est rarement efficace à court terme : les nouveaux arrivants doivent comprendre un code mal documenté, et ceux qui le connaissent passent leur temps à les former. Fred Brooks l'a formulé dès 1975 : ajouter des personnes à un projet logiciel en retard le retarde encore. La priorité n'est pas d'aller plus vite, mais de remettre le projet dans un état où il peut avancer.

06Les questions à poser à votre équipe actuelle

• Combien de temps faut-il pour installer le projet sur un nouveau poste ?
• Existe-t-il des tests automatiques, et que couvrent-ils ?
• Quelle est la procédure de mise en ligne, et qui peut la lancer ?
• Quelles dépendances ne sont plus à jour, et pourquoi ?
• Quelle partie du code personne n'ose toucher ?

Les réponses, ou leur absence, disent beaucoup de l'état réel du projet.

07Prioriser après l'audit

Un bon audit ne se contente pas de lister les problèmes : il les classe. Voici la grille que nous utilisons.

08Combien de temps prend une reprise ?

Il n'existe pas de durée type : tout dépend de la taille du code, de l'état des données et de l'urgence. Ce qui est certain, c'est qu'une reprise progressive livre de la valeur dès les premières semaines (sécurité, stabilité), là où une réécriture ne livre souvent qu'à la fin. Les délais précis sont donnés dans le diagnostic, étape par étape.

09Comment se passe une reprise progressive

1. Audit : lecture du code, des données, de l'hébergement et des accès, avec un diagnostic écrit.
2. Sécuriser : accès récupérés, sauvegardes en place, failles fermées.
3. Stabiliser : bugs bloquants corrigés, mises en ligne de nouveau fiables.
4. Faire avancer : une feuille de route claire, puis les nouvelles fonctions.

10Le rôle de l'audit

Ces six vérifications, c'est précisément ce que couvre un audit de reprise : un diagnostic écrit, les priorités classées de l'urgent au confort, et le coût de chaque option. Vous décidez ensuite en connaissance de cause, et le rapport vous appartient, que vous continuiez avec nous ou non.

11Questions fréquentes