Plateforme multi-site, multi-devise, multi-langue

Revendeur e-commerce de produits dématérialisés (licences logicielles), ~30 personnes. Suite à la migration du site français sur Laravel (phase 1), cinq sites internationaux (DE, NL, IT, ES, UK) continuaient de tourner sur l'ancien code PHP, partageant la même base de données que l'instance Laravel FR déjà en production. Chaque site disposait de son propre dossier de code, complété par des dossiers et fichiers communs à l'ensemble des sites.

La coexistence de deux systèmes distincts (l'instance Laravel FR et les cinq sites PHP legacy) imposait une double charge de maintenance sans point commun : toute évolution fonctionnelle devait être analysée, développée et testée séparément sur chaque environnement. Le code PHP legacy, écrit sans framework en procédural (PHP 5 et 7), réparti dans des dossiers par site et des fichiers communs non structurés, rendait chaque intervention chronophage. L'investigation d'un bug en production pouvait s'étendre sur plusieurs jours selon la complexité, faute de lisibilité et de centralisation du code.

La gestion de la TVA ajoutait une couche de complexité supplémentaire : variable selon la nature du produit, le profil du client (particulier ou entreprise), sa localisation et le lieu de consommation, elle était traitée de façon hétérogène d'un site à l'autre, sans logique centralisée ni garantie de cohérence entre les marchés.

Côté données clients, la situation était tout aussi problématique. Un même client réel pouvait posséder plusieurs comptes (un par site), avec un historique de commandes et de SAV fragmenté sur autant d'espaces clients distincts. Non seulement ces données n'étaient pas consolidées, mais la logique de fusion n'était pas triviale : il fallait identifier le compte de référence parmi plusieurs, et y rattacher l'ensemble de l'historique sans perte ni doublon. Cette fragmentation impactait directement l'expérience client et compliquait toute opération de support.

L'instance Laravel FR a été étendue pour prendre en charge le multi-langue, le multi-devise et la gestion de la TVA dans sa pleine complexité (variable selon le pays du client, la nature du produit et son lieu de consommation). Cette logique TVA a été implémentée à la fois côté front-end et dans l'API, pour garantir la cohérence entre l'affichage tarifaire et les données de facturation.

La page de paiement legacy a été maintenue ouverte le temps d'absorber les derniers renouvellements en attente. Elle a fait l'objet d'un travail spécifique : le routage vers le bon PSP (HiPay ou Payline) étant conditionné par le site_ID et le pays du client, la logique multi-PSP a été soigneusement préservée et rationalisée pour couvrir l'ensemble des marchés sans rupture de service.

La migration des comptes clients a été réalisée via un script sur mesure intégrant une logique de sélection du compte de référence : lorsqu'un client possédait plusieurs comptes (un par site), l'algorithme identifiait le compte le plus complet et y consolidait l'ensemble des données (commandes, SAV et historique). La complexité de ce script tenait à la nécessité de ne produire aucune perte de donnée tout en garantissant un compte unique et cohérent par client.

Enfin, pour structurer le code à l'échelle de plusieurs sites et éviter la duplication, plusieurs packages Laravel internes ont été développés : un package socle partagé entre le front-end et l'API (pkg-base), un moteur de redirection d'URLs piloté par la base de données via un back-office (pkg-redirect-engine), un package dédié à la gestion des paiements (pkg-payment, couvrant les PSP, les pages de retour et les webhooks), et un package regroupant les fonctionnalités communes aux sites front comme les middlewares et les appels à l'API (pkg-ecommerce).