Giphar a entamé une transformation numérique d'ampleur avec SAP S/4HANA, STMS et Google Cloud pour soutenir sa croissance et moderniser son système d'information. Au cœur de ce chantier, une passerelle Java critique qu'il était impossible d'éteindre, même une heure.
01Pourquoi la migration d'un monolithe critique peut s'avérer périlleuse
Sur le sujet, la littérature est abondante et plutôt unanime : il faut avancer par petites étapes. Dans les faits, trois pièges reviennent projet après projet.
On réécrit tout en parallèle pendant dix-huit mois, on gèle les évolutions de l'ancien système, puis on bascule un week-end. Le jour J, la nouvelle plateforme découvre des règles métier que personne n'avait documentées. Et l'ancienne a pris un an de retard fonctionnel.
Les services vivent dans des dépôts et des conteneurs séparés, mais partagent la même base de données et s'appellent en cascade, de façon synchrone. On cumule la complexité réseau des microservices et le couplage du monolithe. Le pire des deux mondes, et une dette technique au carré.
Plus discret : on découpe selon l'organigramme technique (persistance, service, exposition) en ignorant les frontières métier. Les services obtenus changent toujours ensemble, ce qui annule le bénéfice attendu.
Alors, par où commencer quand l'arrêt de service est inenvisageable ?
02Le contexte : un bus d'échange au cœur de l'approvisionnement des officines
Un monolithe Java qui fait tout
Giphar est un groupement de pharmacies d'officine, dont la centrale gère la logistique et l'approvisionnement de plusieurs plateformes pharmaceutiques. Au centre du dispositif, une passerelle d'intégration développée en Java 7 transmet à l'ERP SAP l'ensemble des demandes d'approvisionnement des officines en médicaments.
Devenue critique pour tout le réseau, cette plateforme gère les interactions vitales des officines : consultation du catalogue, passage des commandes, acquittement et récupération de l'état des demandes (le « vidage »). Sous le capot, elle regroupe cinq grandes briques.
Répliquée depuis SAP toutes les cinq minutes, elle répond aux demandes d'information produit des logiciels de pharmacie, notamment la consultation du catalogue.
Il applique les règles de gestion entre la source et la destination et orchestre le cycle de vie des demandes : commandes, acquittements, statuts.
Ils assurent une communication normée et asynchrone avec les LGO (Logiciels de Gestion d'Officine). La norme impose deux instances en mode actif/passif : une seule communique avec SAP à un instant donné.
Ils portent les échanges avec l'ERP, dont la mécanique complexe de reprise sur incident.
Il trace tout ce qui transite par la plateforme.
Autrement dit, la passerelle supporte toute l'activité de l'entreprise. On ne l'éteint pas pour la refaire.
La double contrainte : le cloud et un nouvel ERP
L'équipe en charge de la maintenance du bus assurait déjà son dépannage, ses performances et ses évolutions réglementaires. Deux chantiers sont arrivés en même temps : migrer l'application vers le cloud, et adapter le bus au nouvel ERP, avec un protocole d'échange revu et une authentification modernisée.
Chacun de ces chantiers, pris seul, justifie un projet. Les mener ensemble multiplie les risques, car une anomalie en production peut venir de l'infrastructure, du nouveau contrat ERP ou du code. Le parti pris a été d'utiliser cette contrainte comme levier : puisque la connexion ERP devait être réécrite de toute façon, autant l'extraire du monolithe à cette occasion.
03Choisir le premier microservice : la couture la plus utile
Nous conseillons souvent de chercher la première extraction là où trois conditions se croisent.
Le composant de web services SAP était déjà identifiable dans le code.
La connexion devait changer à court terme, nouvel ERP oblige.
Les échanges étaient spécifiés par l'éditeur de l'ERP.
Extraire un module que personne ne touche rapporte peu. Extraire le module le plus intriqué du code coûte trop cher pour un premier pas.
La démarche suit une logique proche du strangler fig pattern décrit par Martin Fowler : le nouveau service grandit à côté de l'ancien code, le trafic lui est confié progressivement, et la partie équivalente du monolithe s'éteint quand plus rien ne l'appelle. Concrètement, le cœur de routage continue de décider où part chaque message. Seule la destination change : il appelle désormais le microservice de connexion ERP à la place du module SAP interne.
Le cœur de routage envoie désormais les messages vers le microservice. L'ancien chemin reste disponible : si un indicateur dérive, on y revient par configuration, sans redéploiement.Avant la migration, le cœur de routage appelait le module SAP interne au monolithe. C'est aussi le chemin de repli, prêt à reprendre le trafic à tout moment.
Laisser le nouveau service lire directement les tables du monolithe « pour aller plus vite ». C'est le chemin le plus court vers le monolithe distribué. Le service doit posséder ses données ou passer par une interface explicite.
04Moderniser l'authentification sans casser les appelants
L'ancienne passerelle et le nouvel ERP ne parlaient plus le même langage en matière d'authentification. Le microservice de connexion ERP encapsule ce changement : il gère l'obtention et le renouvellement des jetons auprès de l'ERP, et expose à la passerelle une interface simple.
Ce choix confine la modernisation de la sécurité à un seul composant, testé isolément. Le jour où l'ERP fera encore évoluer son mécanisme, un seul service sera à modifier.
05Industrialiser avant de découper : conteneurs et pipeline CI/CD
Extraire des microservices sans chaîne de déploiement automatisée revient à multiplier le nombre de livraisons manuelles. Le move2cloud a donc commencé par la conteneurisation de l'application et la mise en place d'un pipeline CI/CD industrialisé, avant même le premier découpage.
Pour un service Java, un Dockerfile multi-étapes reste la base la plus saine. En voici un exemple générique :
# Étape 1 : compilation
FROM maven:3.9-eclipse-temurin-17 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn -q dependency:go-offline
COPY src ./src
RUN mvn -q package
# Étape 2 : image d'exécution, légère et sans privilèges
FROM eclipse-temurin:17-jre
WORKDIR /app
COPY --from=build /app/target/erp-connector.jar app.jar
USER 1001
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]Le pipeline enchaîne ensuite des étapes classiques.
Le passage d'un code Java 7 à un socle conteneurisé soulève aussi la question de l'obsolescence. La montée de version de la JVM se traite plus sereinement dans un service extrait, avec un périmètre de tests restreint, que dans le monolithe entier.
06Découper, valider, basculer
La méthode tient en trois verbes. Leur ordre compte autant que leur contenu.
Découper par périmètre
Les bascules ont été planifiées périmètre par périmètre. Chaque périmètre correspond à un type de flux ou à un ensemble d'appelants qu'on peut faire passer sur le nouveau chemin sans toucher aux autres. Le flux de commande, le plus critique, n'a pas été le premier servi : on gagne beaucoup à roder la mécanique sur des flux moins exposés.
Valider chaque étape avant la suivante
Chaque étape a été sécurisée avant d'ouvrir la suivante, avec des tests de charge et de non-régression à grande échelle. Sur un bus d'échange, la non-régression se pense en flux de bout en bout : les mêmes messages rejoués sur l'ancien et le nouveau chemin doivent produire les mêmes effets côté ERP et la même réponse côté officine, dans le même délai.
Les tests de charge, eux, servent surtout à vérifier le comportement aux limites : un ERP qui répond lentement, le déclenchement du mode dégradé au bon seuil, la resynchronisation d'un gros volume de commandes accumulées au retour du service. Ces scénarios se rejouent difficilement en production. Mieux vaut les maîtriser en amont.
Basculer progressivement
La mise en production s'est faite de façon progressive, en lien étroit avec les équipes de Giphar. Le principe est simple : le routage oriente un périmètre vers le nouveau service tout en gardant l'ancien chemin disponible. Si un indicateur dérive, on revient en arrière par configuration, sans redéploiement.
Une bascule réussie se prépare aussi côté humain. Ces détails évitent les décisions improvisées à 23 heures :
07Résultats de la migration monolithe microservices
Le projet a mené la double transformation, move2cloud et transition ERP, en trois mois. Les bascules se sont déroulées sans incident et le service est resté continu. Les deux premiers microservices sont en production, la connexion ERP en tête.
Au-delà des chiffres, la plateforme a gagné en performance et en capacité de montée en charge grâce au socle conteneurisé, et en sécurité grâce à l'authentification modernisée. Surtout, la suite devient plus simple : chaque nouvelle extraction réutilisera le pipeline, les pratiques de contrat et la mécanique de bascule déjà éprouvées.
Trois enseignements nous semblent transposables à d'autres contextes.
- Saisir le changement imposé
Un nouvel ERP, une réglementation, une fin de support : un changement subi est souvent la meilleure occasion d'extraire un premier service.
- Traiter le contrat d'interface comme un livrable
Il mérite d'être versionné et testé, au même titre que le code.
- Industrialiser d'abord, découper ensuite
Le pipeline de déploiement vient en premier. Le découpage s'appuie dessus.
Ntico Projets Digitaux
Moderniser vos applications critiques avec Ntico
Chez Ntico, nous accompagnons nos clients dans la maintenance et la modernisation de leurs applications les plus sensibles, avec une conviction : une application critique se transforme par étapes, avec le métier à bord.
Ce projet s'inscrit dans notre expertise en développement et architecture, aux côtés d'autres réalisations à découvrir dans nos cas clients.
Vous envisagez de faire évoluer un monolithe qui ne peut pas s'arrêter ? Nos architectes seront ravis d'en discuter avec vous.
