Vaincre l'obsolescence logicielle - Partie 1 : Le constat
L’Obsolescence Logicielle, ce “Silent Killer” qui étouffe votre produit
Imaginez que vous achetez une voiture neuve, que vous la garez dans un garage hermétique et que vous n’y touchez pas pendant 5 ans. Le jour où vous tournerez la clé, elle ne démarrera probablement pas (batterie à plat, joints séchés, huile figée).
Le logiciel fonctionne exactement de la même manière. Un logiciel qui ne bouge pas est un logiciel qui pourrit.
Dans nos métiers, nous sommes obsédés par la “Dette Technique” liée à la qualité du code que nous écrivons. Mais il existe une dette plus insidieuse, invisible et pourtant mortelle : l’Obsolescence Logicielle.
L’Illusion de la Stabilité : “Pourquoi introduire un risque inutile ?”
C’est l’argument massue, l’objection qu’on a entendue en réunion :
“Attends, tout fonctionne parfaitement en prod là. Pourquoi on irait mettre à jour cette librairie et risquer de tout casser ? On a d’autres priorités business.”
Cette objection est légitime : mettre à jour un composant qui fonctionne, c’est effectivement introduire un risque de régression. C’est le fameux adage “If it ain’t broke, don’t fix it”.
Pourtant, en ingénierie logicielle, ce raisonnement est un piège. Le risque zéro n’existe pas, vous avez seulement le choix entre deux natures de risques radicalement différentes :
| Critère | Mise à jour (Maintenance) | Non-mise à jour (Dette) |
|---|---|---|
| Nature du risque | Risque connu, daté, testable | Risque latent, continu, invisible |
| Déclenchement | Déclenché volontairement (choisi) | Subi à un moment imprévisible (crise) |
| Cadre de gestion | Encadré par CI, tests, rollback | Découvert en prod ou lors d’un incident |
| Impact technique | Corrige des bugs et des failles | Accumule bugs, failles et incompatibilités |
En résumé : «Les mises à jour sont un risque ponctuel et maîtrisable. L’obsolescence est un risque structurel et incontrôlable.»
Ne pas mettre à jour, ce n’est pas “rester stable”, c’est accumuler du risque silencieux. C’est laisser s’installer un “Silent Killer” qui va frapper votre organisation sur trois fronts.
Les 3 Symptômes de la Gangrène Logicielle
1. La double peine RH : Fuite des talents et Recrutement impossible
Pour un développeur passionné, travailler sur une stack obsolète n’est pas juste ennuyeux, c’est une menace pour sa carrière.
- Rétention : Vos meilleurs éléments finiront par partir, refusant de sacrifier leur employabilité à maintenir des “technos zombies”.
- Recrutement : C’est là que le bât blesse le plus. Dans la guerre des talents actuelle, la stack technique est un critère de choix décisif. Une offre d’emploi mentionnant “Java 8” ou “AngularJS” aujourd’hui agit comme un repoussoir.
2. Le blocage de la Roadmap (Symptôme Business)
C’est le scénario catastrophe du Product Owner. Vous voulez lancer une nouvelle fonctionnalité clé, mais l’équipe technique vous répond : “Impossible, il faut d’abord migrer le framework, ça va prendre 3 mois”. Résultat : Le Time-to-Market explose. Vous ne pilotez plus le produit, c’est la dette technique qui dicte votre calendrier.
Cas concret rencontré chez mon client (et probablement chez vous) : Le “Move to Cloud”.
Ce que je décris ici n’est qu’un exemple parmi tant d’autres, car je suis certain que cette situation est la norme dans énormément d’entreprises aujourd’hui. Nous avons des applications stratégiques que nous voulons migrer dans le Cloud.
La cible exige un runtime minimum en Java 11, mais nos applications tournent encore en Java 8.
Il ne s’agit pas de jeter la pierre : historiquement, la gestion de l’obsolescence n’a jamais été une priorité culturelle dans le développement logiciel.
On construisait pour que ça marche, pas pour que ça évolue indéfiniment.
Cependant, le résultat aujourd’hui est que la marche est trop haute pour être franchie simplement.
Nous sommes contraints de dépêcher une équipe entière de jusqu’à sept personnes à temps plein (un chef de projet, un lead dev, trois développeurs, deux testeurs) pendant en moyenne un an uniquement pour réaliser la migration et, surtout, mener les campagnes de tests de non-régression titanesques nécessaires.
Le coût est exorbitant : 7 ans-hommes investis sans aucune nouvelle fonctionnalité livrée, juste pour rattraper le retard accumulé et avoir le droit d’aller dans le Cloud.
3. La roulette russe sécuritaire (Symptôme Management)
C’est le risque le plus grave. Une dépendance non mise à jour (comme Log4j ou Next.js) est une porte ouverte dans votre système d’information.
Résultat : Votre actif logiciel devient un passif juridique. Le risque n’est plus technique, il est existentiel pour l’entreprise.
Le Piège de l’EOL (End of Life) : “On a encore le temps ?”
Il existe une idée reçue tenace chez les décideurs : “Le danger commence quand le support s’arrête. Tant que l’éditeur supporte la version, on est tranquilles.” C’est faux. Attendre la date officielle de fin de support (EOL) pour agir est une stratégie perdante.
Le jour où le support s’arrête, le risque devient ingérable (plus de patchs, plus de support éditeur).
Attendre la fin du support force des migrations brutales (“Big Bang”). Retenez cette formule : Mettre à jour avant l’EOL, c’est une maintenance. Mettre à jour après l’EOL, c’est une crise.
L’Angle Mort : L’Infrastructure et les Logiciels Tiers
L’obsolescence ne s’arrête pas aux frontières de votre code source. Elle contamine également toute la couche basse que vous ne développez pas, mais que vous opérez :
-
L’Infrastructure : Vos versions de Kubernetes, vos OS serveurs (Linux), vos images Docker.
-
Les Logiciels Tiers : Vos bases de données (PostgreSQL, MySQL), vos serveurs d’applications.
Conclusion de la Partie 1
Le diagnostic est sans appel : l’immobilisme technologique est un leurre qui transforme vos actifs logiciels en passifs toxiques. Le coût de l’inaction (départs, failles, blocages) est toujours supérieur au coût de la maintenance.
Mais une fois ce constat posé, comment agir ? Faut-il tout réécrire tous les 5 ans ? Certainement pas.
Dans la partie suivante, nous verrons qu’il existe une approche théorique et des outils pour transformer cette fatalité en processus maîtrisé : la Rénovation Continue.
← Retour au blog