Remplacer ou faire évoluer : l’âge de votre plateforme est la mauvaise question.

Pourquoi la question est mal posée

« Notre plateforme a onze ans. » Cette phrase ouvre beaucoup de discussions de modernisation, et elle n’apporte presque aucune information utile. Des systèmes de vingt ans soutiennent chaque jour des opérations critiques sans dette ingérable. Des plateformes livrées il y a trois ans sont déjà impossibles à faire évoluer, parce que chaque changement touche à tout.

Ce qui rend une plateforme coûteuse n’est pas sa date de mise en service. C’est la difficulté à y introduire un changement sans effets de bord, la dépendance à quelques personnes qui seules comprennent certaines zones, et l’absence de frontières nettes entre ses parties. Martin Fowler décrit précisément ce mécanisme : des systèmes construits sur des décennies, modifiés par ajout successif de correctifs, chaque correctif rendant le suivant plus difficile — jusqu’au moment où l’organisation conclut qu’elle ne peut plus corriger et qu’il faut tout reprendre.

C’est exactement à ce moment que l’intuition devient dangereuse. Face à un système devenu opaque, il paraît raisonnable de penser qu’un redémarrage à neuf sera plus rapide qu’une réparation. L’hypothèse implicite est que l’on connaît ce que le système fait. Dans la plupart des cas, ce n’est pas vrai.

Ce qu’un remplacement complet fait payer deux fois

Un budget de remplacement couvre la construction du nouveau système. Il couvre rarement la deuxième dépense, qui est presque toujours la plus lourde : reconstituer ce que l’ancien système savait faire et que personne n’a écrit.

Ces règles existent pourtant, et elles sont précises. Une remise appliquée à un type de compte pour des raisons contractuelles oubliées. Un statut de commande qui déclenche une écriture comptable particulière en fin de mois. Un contournement mis en place il y a six ans pour un partenaire qui refuse un format standard. Aucune de ces règles n’apparaît dans un cahier des charges. Toutes réapparaissent en production, une à une, sous forme d’anomalies.

S’ajoutent trois coûts que les comparatifs oublient régulièrement : le maintien en condition opérationnelle de l’ancien système pendant toute la durée du projet, la double saisie ou la synchronisation des données pendant la bascule, et la période d’apprentissage des équipes, qui n’ont pas seulement changé d’outil mais aussi de manière de travailler.

Un remplacement n’échoue presque jamais sur la technique. Il échoue sur ce que l’ancien système savait et que personne n’avait écrit.

Quatre situations où remplacer est le bon choix

Ce constat n’est pas un plaidoyer pour conserver l’existant. Il existe des situations où le remplacement est la décision économique et prudente, et elles se reconnaissent à autre chose qu’un inconfort d’usage.

1. Le modèle de données ne peut plus porter le métier. Quand la structure interdit une réalité désormais centrale — plusieurs marchés, plusieurs marques, un nouveau type de client — aucun ajout ne contournera durablement la contrainte.
2. Le socle n’est plus soutenu. Une version de langage, de base de données ou de système sans correctifs de sécurité déplace la discussion du terrain du confort vers celui du risque.
3. La compétence a disparu du marché. Lorsque plus personne ne peut être recruté ni formé sur la technologie en place, la dépendance ne se mesure plus en dette technique mais en personnes.
4. Le coût de possession dépasse durablement celui d’une alternative. Licences, hébergement, contournements et heures de maintenance additionnés, comparés sur plusieurs années — pas sur le prix d’acquisition.

À l’inverse, une interface datée, une lenteur ponctuelle ou une frustration des équipes ne justifient pas un remplacement complet. Ce sont des symptômes qui se traitent très souvent sans toucher au socle, et à un ordre de grandeur de coût inférieur.

Le remplacement progressif n’est pas une demi-mesure

Entre conserver et tout refaire existe une troisième option, largement documentée sous le nom de patron du figuier étrangleur. Le principe : on place une couche d’interception devant le système existant, on développe une fonction à la fois en dehors de celui-ci, on redirige progressivement le trafic vers les nouveaux composants, et l’ancien système est retiré lorsqu’il ne sert plus rien.

Le centre d’architecture de Microsoft en décrit la mécanique et les conditions. Il insiste sur deux points souvent négligés. D’abord, la couche d’interception est une architecture de transition : elle a un coût propre, elle peut devenir un point de défaillance unique ou un goulot d’étranglement, et elle doit être retirée à la fin. Ensuite, les objets de l’ancien système ne sont supprimés qu’une fois le nouveau validé, car revenir en arrière après suppression suppose de restaurer les structures et de rejouer les données.

Le principal risque de cette approche est organisationnel, pas technique : une fois les fonctions les plus visibles modernisées, l’attention se déplace et la migration s’arrête en chemin. L’organisation se retrouve alors à maintenir deux systèmes au lieu d’un. Le retrait de l’ancien doit être un engagement daté, pas une intention.

Décider avec des critères, pas avec une impression

Les trois options se distinguent moins par leur coût total que par la manière dont ce coût se répartit dans le temps et par le risque qu’elles font porter aux opérations.

Avant d’arbitrer, une organisation gagne à répondre à trois questions simples, dans cet ordre : quelles opérations ne peuvent pas s’interrompre, même une journée ? quelles règles métier ne sont écrites nulle part ailleurs que dans le code ? et qu’est-ce qui, concrètement, sera possible dans douze mois et ne l’est pas aujourd’hui ?

La dernière question est la plus utile, parce qu’elle déplace la discussion de la technologie vers la capacité. Une plateforme ne se remplace pas parce qu’elle est vieille. Elle se remplace lorsque la conserver empêche l’organisation de faire quelque chose qu’elle a décidé de faire.