Replatforming, ou la fausse évidence du « on refait tout »

Lorsqu’une application devient difficile à maintenir survient souvent la grande idée “ne serait-ce pas le moment de tout refaire à partir from scratch ?”. Une nouvelle stack avec des bases propres et une architecture moderne. C’est séduisant mais c’est surtout souvent l’aveu d’une incapacité à gérer comme il se doit la maintenance d’un applicatif.

Dans la majorité des appels d’offres qui nous sont adressées, le replatforming est le symptôme d’un malaise : une application difficile à faire évoluer, des régressions fréquentes, des problèmes de performance. Une accumulation de frustrations qui mène toujours au même raisonnement : si tout est compliqué, c’est que la base est mauvaise — et si la base est mauvaise, il faut repartir de zéro.

Ce raisonnement est à priori imparable car il paraît logique et il promet une rupture nette. Il offre une issue à des équipes fatiguées par la maintenance… mais il repose sur une hypothèse pas très solide : que la cause racine vient principalement de la technologie,de l’implémentation et non de la réalité qu’elle modélise. Et à l’heure de l’intelligence artificiellle, qui permet de manière réellement des accélérations dans les étapes de build, ce type de raccourci est encore plus dangereux.

Le “code legacy” n’est pas complexe par accident. Il est complexe parce qu’il a vécu. Il est le reflet d’années de décisions métier, de cas particuliers, de compromis temporaires devenus permanents. Ce qui ressemble à du désordre est davantage une forme de mémoire.

Quand on replatforme, on ne supprime pas cette complexité. On la remet à zéro… pour mieux la redécouvrir. Et bien souvent dans des conditions identiques à celles du passé.

Le fait est que replatformer n’est pas un raccourci : c’est un détour coûteux. Un détour qui commence par une phase de ré-appropriation et de reconstruction de ce qui fonctionnait déjà. On redécouvre des règles implicites. On réimplémente des comportements que personne n’avait formalisés. On corrige des bugs pour la seconde fois… parce qu’ils avaient été corrigés une première fois, puis oubliés.

Pendant la durée du replatforming, la plateforme “legacy” continuera de fonctionner, et, la plupart du temps, d’évoluer. Très vite, il y aura le besoin d’ajuster le périmètre de la nouvelle plateforme qui accuse déjà du retard sur ce qu’il est censé remplacer.

Malheureusement dans bien des cas, c’est alors le moment où le projet commence à se tendre, qu’il s’agisse de temps ou de budget. Les arbitrages arrivent. On promettait une architecture propre, un scope riche, mais il faut livrer, et progressivement, le nouveau système commence à ressembler à l’ancien : imparfait et fragile.

Replatformer est valorisant et donne l’impression d’être en contrôle. Replatformer évite de faire un travail ingrat : celui de comprendre, lire, explorer, reconstituer les décisions passées, accepter que certaines parties du système sont là pour de bonnes raisons, même si elles sont mal exprimées.

Maintenir un système existant demande une forme de maturité technique et organisationnelle. Cela suppose d’accepter que le code parfait n’existe pas et que la valeur vient souvent de petites améliorations accumulées plutôt que de grandes ruptures. C’est aussi moins visible. Mettre en place une CI/CD, ajouter des tests là où ça casse vraiment, documenter les flux métier essentiels, isoler progressivement les zones les plus fragiles — rien de cela ne fait rêver mais pour autant cela fonctionne.

Comme je l’ai dit plus tôt, dans beaucoup de cas, les problèmes attribués à la “mauvaise stack” sont en réalité des problèmes de discipline :

• déploiements manuels,
• absence de tests,
• dépendances laissées à l’abandon,
• manque de documentation et connaissances non partagées,
• incapacité à remettre à plat les parcours et fonctions qui ne fonctionnent pas comme prévu, Changer de technologie ne résout aucun de ces sujets.

Il existe des situations où le replatforming est un bon choix : par exemple dans le cas d’une technologie réellement en fin de vie, ou si les compétences devenues introuvables, ou encore une architecture qui empêche structurellement toute évolution. Dans ces cas-là, la décision est rarement enthousiaste : elle est lucide car s’impose d’elle même et… douloureuse.

Au final, la question à se poser n’est pas “est-ce que ce serait mieux autrement ?” mais: “avons-nous réellement essayé de faire fonctionner ce que nous avons ?” Parfois, la réponse est oui, et le replatforming s’impose. Souvent, la réponse est non, et dans ce cas, reconstruire n’est pas une décision technique : c’est une fuite.