Migrer un socle Java EE sans interrompre la production

Par Cédric Barme · Fondateur de NSY

Les socles Java EE des institutions financières françaises ont souvent quinze ans d'histoire : des serveurs d'applications figés, des dépendances gelées, une dette qui rend chaque évolution plus coûteuse que la précédente. NSY conduit ces migrations depuis 2018 — sans big bang, sans interruption de service, avec la même personne du cadrage à la mise en production.

Le problème réel : la dette qui s'auto-entretient

Un socle Java EE vieillissant coûte de trois façons. D'abord en sécurité : les versions figées (JDK 8, serveurs d'applications hors support) accumulent des CVE non corrigées — un point que les audits ACPR et les exigences DORA ne laissent plus passer. Ensuite en recrutement : plus la pile vieillit, plus il est difficile de trouver des équipes pour la maintenir. Enfin en vélocité : chaque évolution métier exige des contorsions techniques croissantes.

Le réflexe du « grand remplacement » — tout réécrire — échoue dans la majorité des cas : le socle embarque des années de règles métier non documentées que la réécriture redécouvre dans la douleur. La voie que NSY pratique est incrémentale.

La démarche NSY, étape par étape

• Audit de l'existant — cartographie des modules, des dépendances (bibliothèques, drivers, brokers JMS), des flux entrants/sortants et des points de friction. Livrable : une carte des risques et une trajectoire chiffrée.
• Montée de version incrémentale — JDK d'abord (8 → 11 → 17/21), puis l'espace de noms Jakarta (javax → jakarta), puis le serveur d'applications (JBoss EAP, WildFly — voir l'expertise WildFly / JBoss). Chaque palier livre un système testable et réversible.
• Conteneurisation progressive — quand le contexte le justifie : passage sous OpenShift ou Kubernetes en préservant sessions, transactions distribuées et messagerie (expertise OpenShift).
• Industrialisation — CI/CD, tests de non-régression automatisés, observabilité. C'est ce qui empêche la dette de se reconstituer.

Comment la production reste intacte

La règle absolue : des bascules progressives, jamais de saut dans le vide. Environnements parallèles, réplication des flux (messagerie, données), tests de charge représentatifs du trafic réel, plans de retour arrière testés — pas seulement écrits. En environnement bancaire, cette discipline n'est pas un luxe : c'est la condition pour obtenir le feu vert des équipes risques.

Durées et ordres de grandeur

Un audit avec preuve de faisabilité tient en quelques semaines. La migration d'un cœur applicatif complet se compte en mois, par paliers dont chacun apporte de la valeur. NSY commence systématiquement par le cadrage court : vous repartez avec une trajectoire et un ordre de grandeur réalistes avant tout engagement long. Les questions fréquentes détaillent les cas types.

Pourquoi NSY

Cédric Barme est ingénieur logiciel depuis 2012, passé par la banque d'investissement (plateformes de trading et de risque temps réel) avant de fonder NSY en 2018. Les migrations Java EE menées depuis le sont dans des environnements régulés — ACPR, AMF, RGPD, DORA — où l'on ne « répare pas en marchant ». Modèle sans pyramide : la personne qui cadre la migration est celle qui la livre, avec trois clients en parallèle maximum.