La décision de sauver ou de relancer un projet logiciel se prend rarement dans un cadre théorique. La plupart du temps, elle intervient sous la pression des délais, avec une équipe qui fait des heures supplémentaires depuis des mois et une direction qui exige des réponses. C'est précisément ce qui la rend dangereuse.
Un projet logiciel peut être sauvé s'il existe des tests, si l'architecture sépare les modules et si le modèle de données correspond, dans son essence, aux processus métier. Il est judicieux de repartir de zéro en cas de technologie totalement obsolète ou d'architecture qui ne peut pas être étendue. Les éléments à évaluer sont les suivants : sept critères, et la question de l'objectif prime toujours sur la question technique.
La question que l'on se pose trop tard dans un projet logiciel
Quiconque prend une décision sous pression a tendance soit à s'accrocher à un projet voué à l'échec parce qu'on y a déjà tant investi, soit à tout abandonner alors que la majeure partie du travail pourrait encore être sauvée. Ces deux erreurs coûtent du temps et de l'argent. Elles peuvent être évitées si la décision repose sur un ensemble de critères plutôt que sur l'ambiance qui règne dans la salle.
Sept critères pour la prise de décision dans un projet logiciel
Pour qu'un jugement soit solide, il faut apporter des réponses à sept questions, qui doivent être évaluées indépendamment les unes des autres.
- Qualité du code. Dans quelle mesure le code existant a-t-il été testé, documenté et est-il compréhensible pour quelqu'un qui ne l'a pas écrit lui-même ? Un système sans tests n'est pas automatiquement sans valeur, mais toute modification apportée à celui-ci devient un risque.
- Architecture. Le système peut-il être remplacé par parties, ou chaque composant est-il indissociablement lié à tous les autres ? Une structure monolithique n'est pas une condamnation à mort, mais elle limite la possibilité de corriger de manière ciblée les points faibles individuels.
- Modèle de données. La structure des données reflète-t-elle les processus métier réels, ou a-t-elle été étendue à plusieurs reprises de manière provisoire au cours du projet ? Un modèle de données déformé peut être corrigé. Mais cela coûte souvent plus cher que de développer à nouveau la partie concernée.
- Connaissances de l'équipe. Qui, au sein de l'équipe, comprend encore parfaitement le système ? En cas de forte rotation du personnel au cours du projet, ce chiffre diminue plus rapidement que ne le montre l'organigramme.
- Budget restant. Quel est le montant restant, et quel serait, de manière réaliste, le coût d'une modernisation par rapport à un nouveau développement ? Il serait utile de disposer ici d'une estimation approximative des coûts pour les deux options, et non d'un calcul théorique.
- Calendrier. Y a-t-il une date qui ne peut pas être reportée, par exemple parce qu'un ancien système doit être mis hors service à une date butoir ? Une telle date modifie considérablement le calcul.
- Situation contractuelle. Quelles sont les dispositions du contrat conclu avec un prestataire externe concernant la réception, l'exécution ultérieure et la résiliation ? Cette question détermine souvent les options qui s'offrent réellement, tant sur le plan juridique qu'économique.
| critère | Argument en faveur du sauvetage | Arguments en faveur d'un nouveau départ |
|---|---|---|
| Qualité du code | Tests disponibles, code lisible | pas de tests, personne ne comprend la logique |
| Architecture | Les modules sont remplaçables individuellement | tout changement a des répercussions sur l'ensemble du système |
| Modèle de données | reflète les processus à la base | agrandi à plusieurs reprises de manière provisoire |
| Connaissances de l'équipe | Plusieurs personnes connaissent ce système | Le savoir s'est perdu avec les départs |
| Technologie | est toujours mis à jour, développeurs disponibles | Langage ou base de données sans assistance technique |
| budget restant | suffit pour une réparation ciblée | de toute façon, cela ne suffit que pour une partie |
| Échéance | reportable | Date butoir liée à la mise hors service d'un ancien système |
Sauver ou relancer un projet logiciel d'un point de vue technique
La modernisation en vaut la peine lorsque la base de code est solide, c'est-à-dire lorsqu'il existe des tests, que l'architecture sépare les modules et que le modèle de données correspond, pour l'essentiel, aux processus métier. En revanche, le développement d’une nouvelle solution est le bon choix en cas de « sinistre technologique total », par exemple un langage de programmation ou une base de données qui n’est plus maintenu, ou encore une architecture qui ne peut fondamentalement pas être étendue (CodeGuides, 06/2026).
Cette règle semble plus simple qu'elle ne l'est dans la pratique. La plupart des projets se situent quelque part entre les deux, rarement à l'un ou l'autre des extrêmes, par exemple une architecture centrale solide comportant deux ou trois modules qui ont atteint leurs limites techniques. Dans de tels cas, un sauvetage partiel est souvent la bonne réponse : les composants centraux sont conservés, tandis que des domaines individuels, clairement délimités, sont reconstruits. Le Modèle 6R pour les anciens systèmes fournit les étapes intermédiaires nécessaires à cet effet.
Pourquoi des objectifs flous sont souvent plus problématiques qu'un code de mauvaise qualité
des échecs de projet sont dus à des objectifs flous, et non à la qualité technique. Ni la modernisation ni la reprise à zéro n'y changent quoi que ce soit tant que cet objectif fait défaut.
ODCUS, février 2026
C'est un point essentiel pour la décision de sauvetage. Si personne ne peut dire précisément ce que le système doit finalement apporter, les deux voies poursuivent le même objectif flou et finissent par échouer au même stade. La décision technique doit donc être précédée d'une décision de fond. Il faut une vision commune, consignée par écrit, de ce que le projet doit apporter. Si elle fait défaut, c’est le premier point à régler, et non le choix de la technologie.
Le piège du recrutement
Une pratique aggrave souvent la situation : le recrutement précipité d’un nouveau responsable technique en pleine crise. Le recrutement précipité d'un nouveau directeur technique (CTO) peut retarder un projet logiciel de 12 à 18 mois (Raphael Bauer, 05/2026), car un nouveau dirigeant doit d'abord comprendre le système, l'équipe et le contexte politique au sein de l'entreprise avant de pouvoir prendre des décisions. Cette période d’intégration intervient précisément à un moment où le projet dispose de moins de temps.
En revanche, ceux qui choisissent dans un premier temps de régler la question du sauvetage ou du redémarrage en faisant appel à une aide externe temporaire gagnent du temps sans s'engager immédiatement sur un recrutement permanent. Cet article explique comment établir un tel état des lieux. La première crise du projet.
Sept critères, une recommandation motivéeNous évaluons la base de code, le contrat et les compétences de l'équipe, puis nous fournissons une estimation des coûts pour les deux options, et pas seulement pour celle qui nous rapporte de l'argent.
Combien de temps l'évaluation devrait-elle durer ?
Pour les projets logiciels de taille moyenne, une évaluation complète des sept critères peut être réalisée en une à deux semaines, à condition d’avoir accès dès le départ au code, aux contrats et à l’équipe. Si l’accès est accordé par tranches, par exemple parce qu’un prestataire de services précédent hésite à ouvrir entièrement ses référentiels, l’évaluation s’éternise, tout comme l’incertitude au sein de l’équipe. Un calendrier clair, communiqué à toutes les parties prenantes, évite qu’une évaluation prévue pour deux semaines ne se transforme en une situation d’incertitude qui s’étend sur plusieurs mois.
Au final, dans le meilleur des cas, on aboutit à une recommandation motivée et chiffrée : coût estimé de la modernisation par rapport à celui d'un nouveau développement, risque résiduel dans les deux cas et indication claire quant à l'option réaliste en fonction du budget disponible. Une simple réponse par « oui » ou par « non », sans ces chiffres, sera difficilement compréhensible six mois plus tard.
Foire aux questions
Comment objectiver le choix entre sauver et redémarrer ?
Une évaluation indépendante des sept critères suivants : qualité du code, architecture, modèle de données, expertise de l'équipe, budget restant, calendrier et situation contractuelle, idéalement réalisée par une personne n'ayant pas participé au projet jusqu'à présent. Une notation par critère rend la décision compréhensible et évite que l'attachement personnel au système actuel ou la frustration à son égard ne faussent l'évaluation.
Que peut-on réellement récupérer lors d'un redémarrage ?
Souvent plus que prévu. Un modèle de données fonctionnel, une expertise documentée sur les processus métier, des modules individuels stables et, surtout, les enseignements tirés par l'équipe des erreurs commises peuvent être réutilisés dans un nouveau projet. Un nouveau départ signifie rarement repartir de zéro.
Qui devrait prendre cette décision ?
L'évaluation technique doit être effectuée par une personne indépendante et expérimentée sur le plan technique. La décision elle-même doit être prise au niveau de ceux qui sont responsables du budget et des délais, c'est-à-dire généralement conjointement par la direction générale et la direction informatique. Un CTO par intérim peut assumer ces deux rôles à titre temporaire : évaluation et accompagnement de la mise en œuvre.
La prochaine étape
Dans le cadre de cette décision, torck assume la responsabilité du projet en cours, allant au-delà d’un simple rôle de conseil externe. La direction technique et la mise en œuvre sont alors regroupées entre les mains d’un seul acteur, avec ses propres équipes de développement à Maxhütte-Haidhof, Vienne et Rabat en arrière-plan. Prenez rendez-vous pour un premier entretien sans engagement, afin de classer ensemble la base de code et les options.
German 
English 
French