Comment on est passé de six plateformes à deux

Quand je suis arrivé chez Chantelle comme directeur de l’ingénierie, le parc comptait six plateformes qui faisaient le travail que deux pouvaient faire. Personne ne l’avait voulu ainsi. Elles s’étaient accumulées au fil des acquisitions, des projets stratégiques et de contrats fournisseurs devenus moins pertinents avec le temps. Le coût annuel tournait autour de 4 M€. Quand nous avons eu terminé, il était d’environ 3 M€, quatre de ces plateformes avaient disparu et la disponibilité n’était jamais descendue sous 99,99 %.

Le chiffre sur la page d’accueil, c’est la partie facile à dire. L’histoire, c’est ce qui a pris cinq ans.

On n’économise pas en décidant d’économiser

Toute consolidation commence par un tableur qui promet d’importantes économies. Beaucoup finissent pourtant par un changement de plateforme qui coûte plus cher que le système remplacé. Le piège consiste à tout traiter comme une seule migration : choisir la plateforme cible, fixer une date de bascule, geler les améliorations pendant dix-huit mois puis risquer un lancement global qui finit soit en retard, soit en incident.

On ne l’a pas fait. On l’a traitée comme une décision de portefeuille prise en continu, pas comme un projet avec une ligne d’arrivée. Pour chaque plateforme, la question n’était pas « est-ce l’avenir » mais « combien coûte son maintien, combien rapporte-t-elle, et qu’est-ce qui casse si elle part ». Certaines des six étaient peu coûteuses à faire tourner et portaient un vrai chiffre d’affaires. Celles-là, on les garde. D’autres étaient chères, à moitié maintenues, et dupliquaient une capacité qu’on avait déjà ailleurs, en mieux. Celles-là, on les supprime, mais seulement une fois que ce qu’elles faisaient vit ailleurs et a fait ses preuves en production.

On supprime des plateformes, pas des capacités

Une capacité dont l’entreprise dépend ne disparaît pas parce qu’une plateforme disparaît. Elle se déplace. La séquence est donc toujours la même. Trouver où la capacité existe déjà en meilleure forme, ou construire le plus petit pont qui lui permet de vivre là. Déplacer le trafic sans bruit, tranche par tranche, en surveillant le SLO tout du long. Ce n’est qu’une fois que l’ancienne plateforme ne sert plus rien qu’on la décommissionne. À ce moment-là, l’éteindre est un non-événement, et c’est exactement ce qu’on veut. Un décommissionnement qui semble dramatique, c’est qu’on est allé trop vite.

Parfois, déplacer la capacité veut dire la construire. Notre boutique américaine avait un programme de fidélité à points, et l’outil vers lequel on nous a orientés ne pouvait pas répondre aux exigences, alors on a construit le nôtre sur GCP plutôt que de plier l’entreprise à un outil. C’est ça, la discipline : la plateforme est jetable, la capacité ne l’est pas.

L’Europe, c’était la moitié facile

Le parc européen était surtout du Magento, en édition Enterprise sous licence. Chaque site avait son propre code, sa propre version, son propre frontend et son propre hébergement, si bien que rien ne pouvait être mutualisé et que le moindre changement obligeait un ingénieur à réapprendre les spécificités de ce projet-là. C’est ça qui rendait l’ancien parc coûteux : pas une grosse ligne, mais le même travail fait de six façons légèrement différentes. La première migration, de Magento 1 Enterprise vers Magento 2 Open Source, avait eu lieu juste avant mon arrivée, et elle avait pris à une équipe dédiée près d’un an et une bascule de deux jours pour le site français. Mon travail, c’était de rendre le reste routinier, et on l’a fait : l’Allemagne, le Danemark et les Pays-Bas sont passés sur la plateforme Magento 2 Open Source mutualisée entre l’automne 2021 et le début 2022, en moins d’un an, avec un temps d’arrêt quasi nul. Se débarrasser de la licence Enterprise au passage a été une part discrète de l’économie.

La surprise venait du calendrier, pas de la technique. Même un changement de plateforme bien mené perturbe le référencement naturel et payant pendant plusieurs jours ou semaines, le temps que les moteurs de recherche comprennent la nouvelle architecture. Chaque migration devait donc trouver une fenêtre sans promotion en cours. Coordonner ces fenêtres entre les pays et le calendrier marketing a demandé plus de travail que la migration elle-même.

Les États-Unis, la moitié difficile, et on s’est trompé d’abord

Les États-Unis ne voulaient pas de Magento, jugé lourd et daté. Nous avons donc comparé les meilleures solutions du marché pour construire une vitrine SaaS reliée à un lac de données sur GCP, avec BigQuery, Firestore, Cloud Functions et Pub/Sub. Nous avons présélectionné trois plateformes, puis les parties prenantes ont voté avant le début du développement.

Six mois plus tard, la solution retenue s’est révélée inadaptée aux exigences fiscales américaines. Nous avons basculé vers notre second choix, BigCommerce, avec une architecture découplée (headless). Le projet, initialement estimé entre six et neuf mois, en a pris dix-huit. Nous avons perdu du temps et deux prestataires, et l’intégration s’est révélée plus difficile que prévu.

Pendant tout ce temps, je maintenais sous perfusion la plateforme qu’on quittait. Le vieux Magento 1 devait rester sûr et debout pendant que les États-Unis construisaient son remplaçant : correctifs de sécurité de MageOS, pare-feu dédié devant, montée de PHP en 7.4, et versions de Solr, de base de données et de cache à garder à jour à mesure que notre fournisseur cloud retirait celles dont il dépendait. Garder en vie et en sécurité la chose qu’on essaie de tuer, c’est l’impôt ingrat de toute longue migration, et il est rarement au plan.

La fin, c’était la bonne partie. Quand les États-Unis ont enfin basculé, ça a basculé en douceur, et le chiffre d’affaires a crû à deux chiffres après la bascule. Les dix-huit mois n’ont pas été gâchés. C’était le prix d’une destination juste plutôt que rapide.

Protéger l’équipe et le SLO pendant que le coût baisse

Voici ce que personne ne met dans le business case : la consolidation est surtout un problème de leadership, pas de technique. Les mouvements techniques sont connus. Le plus dur, c’est que chaque plateforme a des gens attachés à elle, et « on consolide » ressemble beaucoup à « on coupe » si on ne dit pas clairement le contraire, et tôt.

Alors on a été explicite. Le but était de dépenser moins à faire tourner le parc pour dépenser plus à construire les parties qui comptaient, et de donner aux ingénieurs moins de systèmes mais plus profonds à maîtriser, au lieu de six systèmes superficiels à surveiller. C’est un meilleur poste, pas un poste plus petit. Le SLO était le garde-fou qui rendait tout ça sûr. 99,99 % de disponibilité n’est pas ici une métrique de vanité, c’est le contrat qui nous a permis d’aller vite : tant qu’on pouvait retirer du coût sans bouger ce chiffre, on avait la permission de continuer. Il n’a jamais bougé, et ce n’est pas de la chance. C’est le résultat direct d’une migration par tranches, jamais en big-bang, et du fait de ne jamais décommissionner quoi que ce soit qui faisait encore un vrai travail.

Ce que je dirais à qui affronte le même parc

Ne vous laissez pas séduire par l’élégante architecture cible sur le slide. La valeur n’est pas dans la destination, elle est dans le chemin qu’on prend pour y arriver sans rien casser en route. Consolidez en continu. Déplacez les capacités avant de retirer les plateformes. Défendez un vrai chiffre de fiabilité et traitez-le comme un point d’arrêt absolu. Soyez honnête avec votre équipe sur le pourquoi. Et soyez honnête avec vous-même quand un fournisseur était le mauvais choix, car les six mois passés à l’admettre coûtent moins cher que les deux ans passés à faire semblant.

À mon départ, la dernière des six plateformes était en maintenance, avec une migration vers Magento 2 prévue en novembre. Réduire les coûts annuels d’un million d’euros tout en maintenant une disponibilité de 99,99 % n’a rien d’un sprint héroïque. C’est un programme de cinq ans, méthodique et bien conduit. C’est le type de transformation que je souhaite diriger de nouveau dans mon prochain poste à temps plein.