Dette technique : pourquoi livrer des features n'est pas toujours la bonne décision

Par Antoine Rakotomanga · 10 février 2026 · 5 min de lecture · Aussi sur LinkedIn ↗

Dans beaucoup de projets .NET, continuer à livrer des nouvelles features n'est pas toujours la bonne décision.

Quand vous arrivez sur un projet avec de l'expérience, vous voyez très vite, techniquement, ce qui va poser problème. Le vrai sujet devient : comment rendre ces problèmes visibles à des décideurs dont la vision du projet se limite à la roadmap et aux features ?

Les premiers signaux : ce qui a été repoussé

Quand vous arrivez sur un projet .NET, les premiers signaux sont souvent les mêmes. Il y a d'abord ce qui a été repoussé dans le temps :

une version .NET dépassée, hors support ;
des dépendances obsolètes ou plus maintenues ;
des migrations connues mais toujours reportées.

Ça, ce sont des choix. Discutables, mais compréhensibles dans un contexte de priorisation.

Puis ce qui relève de la qualité du socle

code mal organisé, difficile à maintenir, duplication ;
architecture bancale ;
absence de tests unitaires ;
peu ou pas de logs, aucune vision claire de ce qui se passe en prod ;
erreurs non gérées qui peuvent faire crasher l'application.

Là, on ne parle plus d'optimisation : on parle de fragilité. Techniquement, ce ne sont pas encore des incidents tant que la prod tient. Mais ce sont des signaux faibles que les développeurs connaissent.

Et les signaux humains, qu'on oublie toujours

aucune doc, ou une doc qui date de 3 ans ;
un dev qui part = sa connaissance part avec ;
des devs qui ne connaissent que « leur » partie du projet ;
le « on verra plus tard » qui date de 2021 ;
les tests commentés « temporairement » ;
le fichier que personne ne veut toucher.

Tout ça impacte le projet, les délais, la qualité et la motivation. Et chacun reste dans son coin, comme si tout allait bien.

Chaque feature augmente le risque

Dans cet état, chaque nouvelle feature livrée augmente le risque en production. Une journée investie aujourd'hui pour stabiliser et sécuriser l'existant, c'est plusieurs jours évités plus tard en hotfix et refactoring d'urgence : un message que j'ai souvent dû faire passer en mission.

Ne pas le dire, c'est aussi faire un choix. Même si ça implique de challenger la roadmap auprès de son N+1 ou N+2. Et ce n'est pas un caprice de dev : c'est une question de fiabilité et de capacité à intervenir rapidement, sereinement, en production.

Comment le rendre visible côté business

Sur les projets où je suis passé, j'ai remarqué que ces sujets deviennent réellement audibles quand on arrête d'en parler comme des « problèmes techniques ».

À retenir : à partir du moment où la discussion porte sur la fiabilité, l'image de l'entreprise, l'impact utilisateur et les jours-homme perdus, le message est mieux compris, et surtout mieux écouté.

Cet article est tiré d'une de mes publications LinkedIn : rejoignez la discussion ↗