Cet article est le volet technique de notre étude de cas sur la sortie de G.R.A.M.S Styling de WooCommerce. La migration est en cours : la stack décrite ici est construite, chargée avec les vraies données, et tourne derrière Cloudflare Access jusqu’au lancement.
Avant et après
Sous WooCommerce, un seul serveur PHP faisait tout : il générait chaque page, faisait tourner la base de données et hébergeait des dizaines de plugins pour les devises, la livraison, les options produit, le cache, la recherche, les e-mails, la synchronisation marketplace et bien plus. Chaque fonctionnalité était le code de quelqu’un d’autre, avec un seul processus et une seule table d’options en base pour tout le monde, et chaque visiteur attendait ce serveur.
La nouvelle architecture sépare trois choses. La vitrine tourne sur Cloudflare Workers, au plus près du visiteur, et sert des pages en cache. Le moteur e-commerce, Medusa, tourne sur un petit serveur et ne répond qu’aux requêtes qui en ont besoin : paniers, paiement, comptes, administration. Tout ce qui est propre à cette boutique est écrit sous forme de modules Medusa, versionnés et testés comme n’importe quel autre code. Le schéma ci-dessus montre les deux installations côte à côte.
Le moteur e-commerce : Medusa v2
Medusa nous a donné les briques dont une boutique a besoin, et rien d’autre : régions et devises, paniers, commandes, expéditions, clients, une interface d’administration et un système de modules pour étendre le tout. Il tourne sous forme de stack Docker Compose avec Postgres et Redis, gérée par Coolify sur un serveur 2 vCPU. Un workflow GitHub Actions construit et analyse l’image à chaque merge, et le serveur se contente de la récupérer : un déploiement prend environ une minute et demie. La base de données est exportée toutes les heures et copiée hors site, et la restauration a été testée.
Le comportement propre à la boutique repose sur un ensemble de modules sous licence MIT, que nous avons écrits pour qu’ils soient réutilisables sur d’autres boutiques Medusa :
- Des frais de livraison calculés à partir du poids du panier et d’une grille tarifaire par pays, selon les règles que la boutique a toujours appliquées.
- Des options produit (kits de montage, flasques, accessoires) sous forme de vraies variantes avec leur propre prix.
- Les paiements PayPal et Revolut via les SDK officiels, avec webhooks vérifiés et remboursements.
- Les mots de passe clients vérifiés contre les hachages WordPress à la première connexion, puis mis à niveau en silence, pour que personne n’ait rien à réinitialiser.
- Les e-mails transactionnels via la boîte mail que la boutique utilise déjà.
- Cloudflare Turnstile sur chaque formulaire public, avec refus par défaut en production.
- Des outils de commande : capture, expédition avec suivi, formats de colis prédéfinis, colis par commande, notes d’équipe.
- Un tableau de production d’atelier par site, où les commandes marketplace arrivent sous forme de cartes.
- Des devis transporteurs en direct, la réservation en un clic et le stockage des étiquettes.
- Un petit CMS pour les pages, les textes du site, le blog et la galerie de voitures clients, avec traductions.
- Des flux produits pour Google Merchant Center, Meta et Pinterest.
- Un assistant boutique IA qui associe une voiture et une pièce à la bonne catégorie et aux bonnes variantes, avec un sélecteur simple en solution de repli.
La vitrine : Next.js 16 sur Cloudflare Workers
La vitrine est une application Next.js App Router déployée comme Cloudflare Worker, avec des pages mises en cache en périphérie et revalidées en arrière-plan, si bien que le moteur e-commerce ne voit qu’une petite part du trafic. L’URL porte le marché (/uk, /eu, /us, et des variantes linguistiques comme /eu-fr), avec canonical et hreflang par marché. Le middleware gère les redirections depuis l’ancienne boutique, la suggestion de région selon le pays, le cookie de langue et les en-têtes de sécurité.
Le blog est un site statique distinct, reconstruit automatiquement quand un rédacteur enregistre un article dans l’administration Medusa. Le tableau des ateliers est une page statique derrière Cloudflare Access.
Comment les données ont migré
Chaque enregistrement importé depuis WooCommerce conserve son identifiant d’origine dans ses métadonnées, si bien que la comparaison entre l’ancienne et la nouvelle boutique peut être relancée à tout moment : produits, variantes, prix, poids, clients, commandes, paiements, remboursements et numéros de suivi ont été vérifiés par identifiant, et la dernière exécution n’a montré aucun écart sur les prix. Les commandes passées sur l’ancienne boutique avant le lancement sont importées une à une.
Ce que nous referions
C’est l’architecture que nous proposons désormais à toute entreprise qui a besoin d’une boutique à portée mondiale, rapide grâce au réseau edge et ciblée par marché, avec la qualité d’une boutique de niveau Shopify et sans pourcentage prélevé sur chaque vente. Le headless était le bon choix pour ce catalogue. Les règles d’expédition, les options et les finitions du propriétaire n’entraient dans aucune plateforme hébergée, et les écrire sous forme de petits modules a permis de tester chacun séparément. Placer la vitrine sur Workers a supprimé toute une catégorie de travail d’hébergement. Et conserver les anciens identifiants a fait de chaque audit un script plutôt qu’une supposition.