tout beau, tout neuf

Le mythe du projet « tout beau, tout neuf » coûte chaque année des millions d'euros aux équipes d'ingénierie, non pas parce que les nouvelles technologies sont mauvaises, mais parce que nous les adoptons souvent pour de mauvaises raisons. Si vous avez déjà senti cette excitation en ouvrant un dépôt fraîchement initialisé, avec zéro dette technique, zéro dépendance obsolète et une CI qui passe en trente secondes, vous connaissez le piège. Mais en production, la nouveauté n'est pas une fonctionnalité.

Cet article n'est pas un plaidoyer pour rester bloqué sur des technologies vieillissantes. Il s'agit d'une analyse pragmatique du syndrome du « tout beau, tout neuf » appliqué à l'ingénierie logicielle, aux infrastructures cloud et aux architectures distribuées. Nous allons examiner pourquoi les équipes surinvestissent dans des réécritures neuves, comment mesurer le coût réel de ces décisions, et quelles stratégies concrètes permettent d'adopter des outils récents sans compromettre la stabilité des systèmes en production.

Mon point de vue est simple: un projet « tout beau, tout neuf » est un artefact séduisant mais rarement rentable à court terme. La maturité d'un système se mesure à sa capacité à évoluer, pas à son âge. Dans les sections suivantes, je vais m'appuyer sur des retours d'expérience réels, des références documentaires et des outils précis pour démontrer comment prendre des décisions techniques plus sobres et plus durables.

Pourquoi le « tout beau, tout neuf » fascine autant les développeurs

La première raison est cognitive: un nouveau projet offre une illusion de contrôle total. Il n'y a pas d'héritage imposé, pas de tests qui échouent mystérieusement, pas de code legacy dont personne ne veut prendre la responsabilité. Dans les équipes que j'ai accompagnées, cette sensation de table rase se traduisait souvent par une productivité initiale très élevée, suivie d'un plateau brutal dès que les contraintes métier réelles réapparaissaient.

La deuxième raison est culturelle. Les conférences, les réseaux sociaux techniques et les classements d'adoption valorisent systématiquement le nouveau framework, le nouveau runtime ou la nouvelle base de données. Le terme anglais shiny object syndrome décrit exactement ce comportement: l'attrait irrationnel pour ce qui brille, au détriment de ce qui fonctionne. Les résultats de l'enquête annuelle de Stack Overflow montrent que les développeurs citent régulièrement l'envie d'apprendre de nouveaux outils comme une motivation majeure, parfois devant la résolution de problèmes métier.

Enfin, il y a un biais de recrutement. Une offre d'emploi mentionnant une stack récente attire davantage de candidats. Une entreprise qui annonce une migration vers un outil « tout beau, tout neuf » envoie un signal de modernité. Mais ce signal marketing interne ne dit rien de la viabilité technique de la migration. J'ai vu des équipes lancer des réécritures complètes uniquement pour retenir des développeurs seniors qui s'ennuyaient, sans aucun objectif fonctionnel mesurable.

Le coût réel des réécritures « from scratch »

Une réécriture complète est l'exemple le plus extrême du syndrome « tout beau, tout neuf ». Elle consiste à jeter le code existant et à repartir de zéro, souvent avec un nouveau langage ou un nouveau framework. Le coût direct inclut les salaires des développeurs pendant des mois, mais le coût indirect est bien plus lourd: pendant la réécriture, l'ancien système continue de tourner en production, nécessitant maintenance et corrections de bugs, sans bénéficier des nouvelles fonctionnalités.

L'exemple le plus connu dans l'industrie est l'échec du projet Netscape 6, largement documenté par Joel Spolsky dans son essai Things You Should Never Do. Netscape a décidé de réécrire son navigateur entièrement à partir de zéro alors que Microsoft avançait à grande vitesse. Résultat: des années de retard, une perte de part de marché massive, et une leçon que l'industrie semble réapprendre tous les dix ans. En production moderne, ce scénario se répète avec des APIs internes, des backends monolithiques que l'on veut découper, ou des applications mobiles que l'on souhaite porter sur un nouveau framework.

• Pendant une réécriture, le système legacy consomme encore 30 à 50 % de la capacité de l'équipe selon plusieurs rapports d'ingénierie publiés par des entreprises comme Stripe ou GitHub.
• Les bugs corrigés dans l'ancien système doivent être reproduits dans le nouveau, sans quoi on régresse.
• Les tests de non-régression deviennent exponentiellement plus complexes car deux bases de code coexistent.

Un indicateur clé à suivre est le temps de bascule: combien de mois s'écoulent entre le premier commit du nouveau projet et le moment où il remplace réellement l'ancien en production? Dans les réécritures ratées, ce délai dépasse souvent dix-huit mois. À ce stade, la dette technique du nouveau code a déjà commencé à s'accumuler, et le projet « tout beau, tout neuf » n'est plus ni tout beau, ni tout neuf.

Dette technique versus enthousiasme du neuf: un arbitrage permanent

La dette technique n'est pas un ennemi à éradiquer, c'est un levier financier. Contracter une dette technique en choisissant une solution pragmatique permet de livrer plus vite, à condition de la rembourser plus tard. Le problème du « tout beau, tout neuf » est qu'il propose de rembourser la dette en rachetant toute la maison, au lieu de rénover les pièces une par une. Dans une architecture legacy, la dette est souvent concentrée sur quelques modules, pas uniformément répartie.

Une approche plus saine consiste à cartographier la dette technique avec des outils comme SonarQube, CodeScene ou les rapports de complexité cyclomatique. Ces outils mesurent la maintenabilité du code et identifient les zones critiques. En général, moins de 20 % des fichiers concentrent plus de 80 % de la complexité. Réécrire uniquement ces 20 % avec un design moderne donne souvent un gain de productivité équivalent à une réécriture complète, pour un coût cinq à dix fois inférieur.

J'ai vu ce phénomène sur un projet de refonte d'une API de gestion de commandes écrite en Java 8. L'équipe voulait tout réécrire en Kotlin avec une architecture hexagonale. Après analyse, nous avons constaté que seuls deux services (sur quatorze) causaient la majorité des incidents de production. Nous avons isolé ces services, les avons réécrits en Kotlin, et laissé le reste du système intact. Le résultat: une réduction de 70 % des incidents en trois mois, sans arrêt de production.

Cette approche incrémentale est directement inspirée du pattern Strangler Fig de Martin Fowler, qui recommande d'étouffer progressivement l'ancien système en construisant le nouveau autour de lui. C'est l'antidote le plus efficace au fantasme du « tout beau, tout neuf ».

Les pièges de la modernité: quand le nouveau fait régresser

Adopter une technologie récente ne garantit pas une amélioration. J'ai vu des équipes migrer d'une base de données relationnelle éprouvée vers une base NoSQL à la mode, uniquement parce que la nouvelle base était « tout beau, tout neuf ». Six mois plus tard, elles découvraient que leurs requêtes transactionnelles, qui nécessitaient des jointures et des garanties ACID, devenaient un cauchemar à implémenter. Le coût de retour en arrière était déjà prohibitif.

Un autre exemple classique est la migration d'un monolithe vers des microservices sans une réelle contrainte d'échelle. Selon le RFC 1925, « The Twelve Networking Truths », la vérité numéro onze affirme: « Every old idea will be proposed again with a different name and a different presentation