Skip to main content
note

Pourquoi les développeurs n’aiment pas maintenir des projets "legacy"

27 octobre 2025 lrtrln Ligne ouverte
Pourquoi les développeurs n’aiment pas maintenir des projets "legacy"

Pourquoi la maintenance reste-t-elle le parent pauvre du développement, alors qu’elle concentre l’essentiel du travail réel ? Entre culture du neuf, fatigue technique et logique économique, décryptage d’un mal structurel.

Le mythe du créateur

Dans l’imaginaire collectif du dev, l’histoire d’un nouveau projet commence toujours par une scène glamour : écran vide, techno fraîche, architecture en lévitation. Le moment où “je construis, je crée, j’innove”. Ce récit flatte l’ego, alimente les keynotes et déclenche les bons posts LinkedIn avec gifs de fusées

En revanche, la maintenance arrive comme une zone d’ombre : éléments imposés, dette implicite, code existant à dompter. C’est le terrain où l’on hérite, où l’on répare, où l’on retient des briques qui s’effritent.

Cette dichotomie reflète une vraie tension :

  • création = visible, valorisée, cool
  • entretien = silencieux, moins considéré, mais tout aussi crucial

Quelques données

Ces chiffres suggèrent que ce n’est pas seulement une question d’envie : il existe un vrai frein structurel à l’entretien des projets.

Pourquoi ça coince ?

  • Le développeur se retrouve souvent dans un rôle de “gardien” plutôt que de “créateur” : modifier, corriger, adapter plutôt que bâtir.
  • La reconnaissance est asymétrique : « hey, j’ai livré une v1 de toute beauté » fait plus mousser que « j’ai maintenu la v1 pendant 19 mois sans aucun incident ».
  • Le plaisir diffère : le neuf électrise, l’entretien exige une énergie lente, rarement visible.

La réalité structurelle

Si les développeurs rechignent à maintenir les projets, ce n’est pas seulement une question d’ego, d’envie ou motivation : c’est une conséquence directe de la manière dont les organisations conçoivent le cycle de vie logiciel.

La prime au neuf

  • Les budgets, les plannings et les discours valorisent la livraison initiale, pas la continuité.
  • Un projet neuf permet de communiquer, de recruter, de montrer.
  • Un projet maintenu… se contente de “fonctionner”.
  • Dans les appels d’offres comme dans les plans de financement, la ligne “maintenance” est souvent compressée, sous-estimée ou confiée à des prestataires de second plan.

L’économie du logiciel rémunère l’instantané, pas la persistance.

Des contraintes systémiques

  • La maintenance est perçue comme un centre de coût, non un investissement.
  • Peu de gouvernances techniques intègrent des budgets préventifs (mise à jour des dépendances, refactoring, documentation).
  • Les décisions de court terme (pile technologique à la mode, architecture rapide à livrer) se paient plus tard en dette.
  • Dans les entreprises produit, les équipes changent souvent : le contexte se perd, la transmission se délite.

Selon le 2023 Developer Survey, près de 60 % des devs citent le code hérité comme leur principale frustration.
Et d’après Software Improvement Group, 70 % du coût total d’une application part dans sa maintenance.

Deux chiffres qui traduisent un décalage clair entre les discours et la réalité budgétaire.

Le cercle vicieux

La maintenance est clairement dévalorisée, elle attire moins d’attention et de moyens. Résultat : les projets vieillissent vite, deviennent instables, et les développeurs les fuient… confirmant la prophétie. Ce n’est pas qu’un problème individuel, mais un biais structurel : tout pousse à repartir de zéro plutôt qu’à préserver.

La fatigue technique

La maintenance peut user, non par manque de compétence, mais d’élan. Lire, comprendre, adapter un code qui n’est pas le sien demande une énergie différente : lente, analytique, souvent ingrate et besogneuse.

Le coût cognitif du vieux code

Chaque ligne héritée peut devenir un véritable jeu d’énigme : pourquoi ce choix ? quelles contraintes ? quel effet domino et effet de bord en cascade si je touche à ça ?
Le développeur se retrouve dans une posture d’archéologue, fouillant des couches de logique et de compromis. Ce travail exige de la rigueur et de la patience, mais ne procure pas le même feedback immédiat qu’un nouveau développement.

  • JetBrains (2023) estime que 45 % du temps des devs part dans la lecture/compréhension du code existant.
  • Et selon le State of DevOps 2024, les équipes chargées de dette technique ont 40 % de risque en plus d’épuisement.

Une gratification différée

Corriger un bug, optimiser un script, documenter une API : ces tâches sont nécessaires, mais invisibles. Elles stabilisent, mais n’exalte pas. Cette asymétrie de reconnaissance crée une forme de fatigue symbolique : le sentiment de produire, mais sans “livrer”.

La dette mentale

Travailler sur un projet vieillissant (legacy), c’est aussi accumuler de la tension invisible :

  • dépendances fragiles ou cassées ;
  • versions incompatibles ;
  • outils obsolètes ou non maintenus ;
  • manque de documentation ou de tests.

Chaque contournement devient un micro-stress. Et à force de colmater, l’esprit s’épuise à compenser les failles d’un système plutôt qu’à le faire évoluer.

Changer le regard

Si le développement veut se rapprocher d’une forme de maturité, il doit réhabiliter la continuité comme une compétence noble, non comme une corvée.

Réapprendre à valoriser le soin

Maintenir, ce n’est pas forcement réparer : c’est prendre soin d’un système. Mettre à jour une dépendance, simplifier une architecture, documenter un module, ce sont des actes de conservation. Ils préservent la valeur initiale et prolongent l’utilité du code. Dans une logique de sobriété, cette approche est presque politique : ne pas jeter ce qui fonctionne encore.

La durabilité, ici, ne tient pas au matériau du code, mais à l’attention qu’on lui porte.

Vers une écologie logicielle

Un logiciel bien entretenu consomme moins : moins de builds, moins d’incidents, moins de redéploiements inutiles. L’écoconception passe autant par le design initial que par la gestion de la durabilité du projet. Les métriques de performance devraient inclure la longévité et la réparabilité du code autant que sa rapidité d’exécution.

Quelques leviers possibles :

  • intégrer la maintenance au budget initial ;
  • suivre la dette technique comme un indicateur vital ;
  • documenter pour transmettre, pas seulement pour livrer ;
  • ralentir volontairement : le “moins mais mieux” en stratégie, et non en faiblesse.

Une esthétique du durable

Il y a une forme d’élégance dans un projet qui traverse les années sans se désagréger et s’éroder de toute part. Cette esthétique-là ne se mesure pas au nombre de fonctionnalités, mais à la stabilité et à la lisibilité du code. Elle rejoint les principes d’architecture sobre : simple, réparable, transmissible.

En bref

La tech idéalise le nouveau. Le marché, les méthodes, les discours d’équipes glorifient le lancement, l’instantanéité, le “go live”. La maintenance, elle, glisse dans une zone périphérique : nécessaire mais invisible, cruciale mais reléguée. Et pourtant, c’est là que se concentrent le coût réel, la valeur durable et la mémoire technique d’un projet.

Dans d’autres métiers, on parlerait sans hésiter de gestion du patrimoine. Préserver, transmettre, faire durer. En tech, la tentation inverse domine : raser pour reconstruire, changer de pile comme on change de moodboard, sacrifier l’existant sur l’autel de la hype et du “tout nouveau tout beau”. Chaque refonte hâtive, chaque framework remplacé parce qu’une nouveauté scintille quelque part, alourdit la dette écologique, Étire la fatigue des équipes et efface une partie du travail déjà accompli.

Le code n’a pas forcement besoin d’un rajeunissement permanent, ni d’un renouvellement pavlovien dès qu’un nom circule sur les réseaux sociaux. Il a besoin d’être compris, accompagné, soigné. De circuler entre les mains sans se dégrader. Peut-être qu’un jour, on célébrera autant la longévité qu’un lancement. Peut-être qu’on applaudira le projet qui traverse les années sans s’effondrer, autant que celui qui arrive avec son cortège de nouveautés brillantes.

Et ce jour-là, maintenir ne sera plus vécu comme une contrainte, mais comme un geste de maturité : l’art de faire durer ce qui fonctionne encore. Mais sans doute dans une réalité parallèle.