E-commerce Drupal 11 — E-commerce — Œuvres d'art

Les Atamanes — migration Drupal 10 vers 11 d'une boutique d'art bilingue

Migration vers Drupal 11 d'un site e-commerce d'œuvres d'art bilingue sous Drupal Commerce : revue de code approfondie (cœur, modules communautaires et sur mesure), montée de PHP et Symfony, réécriture des modules non maintenus, passage au JavaScript natif et optimisation des performances.

Le contexte

Les Atamanes est une boutique en ligne d’œuvres d’art. Il y a deux ans, j’ai refondu le site en une plateforme e-commerce complète permettant l’achat des œuvres en ligne, en français comme en anglais, sur la base de Drupal Commerce. Depuis, j’en assure la maintenance et les montées de version : d’abord sous Drupal 9, puis Drupal 10, et aujourd’hui Drupal 11.

Une base saine, mais un changement de socle. Fonctionnellement, le site était globalement prêt. Ce qui rend la migration vers Drupal 11 exigeante, c’est le changement de version de PHP et de Symfony qui l’accompagne : il impose de vérifier en profondeur le code du cœur, celui des modules de la communauté et celui des modules sur mesure. Les modules custom n’ont d’ailleurs pas été les plus compliqués à traiter — ils étaient globalement prêts.

Une revue de code outillée. L’IA a été d’un grand soutien pour mener une solide revue de code et identifier les points de friction et les dépréciations à traiter, en complément du module d’analyse de migration fourni par la communauté Drupal. Croiser les deux approches — l’outil communautaire spécialisé et la revue assistée — a permis de cartographier précisément le travail à faire avant d’y toucher.

Réinternaliser ce qui n’est plus maintenu. J’ai constaté à cette occasion que certains modules n’étaient plus maintenus. J’ai donc pris la décision de les réécrire en modules sur mesure, afin d’assurer la continuité de l’ensemble et de ne pas laisser une brique fragile décider de l’avenir du site.

Un front sans jQuery. Côté interface, les évolutions du moteur de gabarits et surtout la disparition définitive de jQuery — actée dans Drupal 11 — obligent à se plonger dans l’API JavaScript native de Drupal 11. La couche front a été reprise en conséquence.

Performance. Cette évolution a aussi été l’occasion de bénéficier des gains de performance de PHP 8.4 et de revoir le front pour obtenir de meilleurs résultats sur les Core Web Vitals de Google. Le projet a été mené à bien : la version actuellement en ligne tourne sous Drupal 11.

Ce qui devait être résolu

  • Faire évoluer une boutique d'œuvres d'art en ligne vers la dernière version de Drupal sans interrompre la vente ni dégrader l'expérience d'achat, en français comme en anglais

  • Absorber un changement de version de PHP et de Symfony qui impose de vérifier en profondeur le cœur de l'application, les modules de la communauté et les modules sur mesure

  • Assurer la continuité de fonctionnalités reposant sur des modules de la communauté devenus non maintenus

  • Adapter la couche front aux évolutions du moteur de gabarits et à la disparition définitive de jQuery

  • Profiter de la migration pour améliorer les temps de chargement et les indicateurs de performance mesurés par Google (Core Web Vitals)

Ce qui a été livré

  • Migration complète vers Drupal 11 : cœur applicatif, modules de la communauté et modules sur mesure

  • Revue de code approfondie des points de friction et des dépréciations, conduite avec l'appui de l'IA en complément du module d'analyse de migration de la communauté Drupal

  • Réécriture en modules sur mesure des composants dont le module d'origine n'était plus maintenu, pour garantir la continuité du site

  • Refonte de la couche front en JavaScript natif de Drupal 11 (fin de la dépendance à jQuery) et mise à jour des gabarits Twig

  • Montée à PHP 8.4 et optimisation du front pour de meilleurs résultats Core Web Vitals

  • Mise en production de la version Drupal 11 après validation en préproduction

Le résultat

Le site est en production sous Drupal 11 et continue de vendre des œuvres d'art en ligne, en français comme en anglais. La migration a été menée sans rupture de service : les fonctionnalités portées par des modules non maintenus ont été réinternalisées en développement sur mesure pour sécuriser leur avenir, et la couche front a été modernisée en JavaScript natif. La montée à PHP 8.4 et le travail sur le front se traduisent par de meilleurs indicateurs de performance.