Quand le marché accélère et que votre système freine
De nouveaux acteurs arrivent sur le marché avec une capacité d'exécution impressionnante. Ils innovent vite, livrent souvent, et proposent des produits simples à utiliser, qui évoluent en permanence. Pendant ce temps, de nombreuses entreprises historiques voient leur rythme ralentir. Les cycles de livraison s'allongent, les changements deviennent risqués, et les équipes passent plus de temps à contourner les problèmes qu'à créer de la valeur.
Ce décalage ne se limite pas aux produits. Il se manifeste aussi dans les équipes. Ceux qui restent sont souvent ceux qui sont là depuis longtemps, parce qu'ils ont appris à naviguer dans la complexité du système. Mais même des profils expérimentés qui arrivent repartent rapidement. Non pas par manque de compétence, mais parce que l'environnement les empêche de produire efficacement.
C'est généralement à ce moment-là que la décision tombe : il faut moderniser.
L'intention est bonne. Mais dans la majorité des cas, la manière de l'aborder condamne le résultat.
Le piège : penser que la modernisation est un problème technique
Dans beaucoup d'organisations que j'ai accompagnées, la modernisation est pensée comme un projet que l'on pourrait cadrer et livrer en quelques mois. L'arrivée de l'IA a renforcé cette idée : certains imaginent qu'il serait possible de "traduire" l'existant dans une technologie moderne rapidement.
Ce raisonnement repose sur une erreur fondamentale.
Le legacy n'est pas du code ancien. C'est l'accumulation, sur des années, de règles métier, de compromis, d'exceptions et de décisions organisationnelles. Une complexité profondément ancrée dans le fonctionnement de l'entreprise.
- Automatiser un système mal compris, c'est industrialiser ses défauts.
Ce que vos clients perçoivent vraiment
Vos clients ne voient pas votre stack technique. Ils ne choisissent pas un produit parce qu'il est basé sur une technologie plus récente.
En revanche, ils perçoivent immédiatement la complexité des parcours, la lenteur des évolutions et la fréquence des anomalies.
- Un lead time trop long, c'est une incapacité à répondre au marché.
- Un taux d'échec élevé, c'est une perte de confiance.
Les nouveaux entrants gagnent rarement grâce à leur technologie seule. Ils gagnent parce qu'ils livrent mieux.
Ce qui fait réellement la différence
Les travaux du DORA (DevOps Research and Assessment) permettent de mesurer cette performance à travers quatre indicateurs simples :
- Le lead time : le temps pour répondre à un besoin.
- La fréquence de déploiement : la vitesse d'apprentissage.
- Le taux d'échec des changements : l'impact sur la qualité.
- Le temps de restauration : la capacité à réagir.
Les organisations les plus performantes ne choisissent pas entre vitesse et stabilité. Elles construisent un système qui permet les deux.
À ce stade, beaucoup pensent encore que le problème est technique. C'est souvent ici que le sujet bascule vers le leadership.
Ce que je vois souvent sur le terrain
J'ai vu ce schéma se reproduire plusieurs fois.
On monte une équipe d'experts techniques pour porter la modernisation. Elle définit des standards, formalise des bonnes pratiques, parfois même des skill.md. Elle choisit un sujet à moderniser rapidement, souvent avec l'IA, pour démontrer que c'est possible.
Sur le papier, tout est cohérent.
Dans la réalité, le métier est absent.
Dans un cas concret, cette approche a mobilisé 3 experts techniques et 5 managers pendant 6 mois avec un objectif clair : améliorer la capacité de livraison.
Au bout de 6 mois, rien n'avait changé.
Pourquoi ? Parce que pendant ce temps, les demandes métier continuaient d'arriver et restaient prioritaires. Et surtout, parce que personne ne travaillait réellement sur les flux, les usages ou la valeur.
On parlait technologie. Pas produit.
- Moderniser sans le métier, ce n'est pas accélérer. C'est courir dans la mauvaise direction.
- Sans le métier, vous n'avez pas un projet de modernisation. Vous avez un projet de réécriture.
Le vrai problème
Le risque n'est pas d'échouer techniquement.
Le risque, c'est de reconstruire sans rien changer.
- Même organisation.
- Même priorisation.
- Mêmes dépendances.
- Et au final, un système plus moderne, mais tout aussi lent.
J'ai vu des organisations investir massivement dans des réécritures, pour retrouver quelques années plus tard les mêmes blocages.
Parce que le problème n'était pas dans le code.
La question que peu d'organisations veulent vraiment se poser
Et si le problème n'était pas votre logiciel, mais la manière dont vous prenez vos décisions ?
Moderniser impose des choix.
- Protéger du temps.
- Accepter l'incertitude.
- Réduire les dépendances.
- Donner plus d'autonomie aux équipes.
- Beaucoup d'organisations échouent non pas parce qu'elles ne savent pas quoi faire, mais parce qu'elles refusent d'en payer le prix.
Et l'IA dans tout ça ?
L'IA est un levier puissant.
Je l'utilise moi-même pour accélérer la compréhension, générer des tests, explorer des solutions.
Mais elle ne remplace pas :
- La compréhension du métier.
- Les choix d'architecture.
- Les arbitrages organisationnels.
- L'IA ne supprime pas la complexité. Elle la rend plus rapide à produire.
Dans une organisation fluide, c'est un accélérateur. Dans une organisation bloquée, c'est un amplificateur de problèmes.
Conclusion
Moderniser un logiciel n'est pas un sujet technique.
C'est un sujet de lucidité.
Un système legacy est rarement un problème technique. C'est le reflet fidèle des décisions qui l'ont construit.
- Le code n'est que la conséquence. Le vrai legacy, ce sont les décisions.
Pour aller plus loin
- Accelerate
- Architecture Modernization
- Thoughtworks
- Travaux du DORA (DevOps Research and Assessment)
Ressources liées
IA, Legacy et rentabilité : pourquoi vous accélérez peut-être… dans la mauvaise direction — comprendre pourquoi accélérer sans compréhension peut amplifier le legacy.
Quand les contournements deviennent la stratégie — identifier les dérives qui transforment les compromis en système permanent.
Mesurer l'impact réel de l'IA — piloter la performance de delivery avec des indicateurs lisibles.