Medusa 2.19.0 est sortie le 13 août 2026 et devient la version courante de la plateforme. Le titre officiel de la version — « Mise à jour Vite v7, export des stocks, adresses de livraison personnalisées » — résume l’essentiel : une importante mise à niveau de l’infrastructure et plusieurs fonctionnalités utiles au quotidien pour votre équipe opérationnelle.
Si vous exploitez une activité e-commerce sur Medusa, il n’est pas nécessaire de lire chaque ligne du changelog. Trois points sont essentiels : ce que votre équipe y gagne, ce qui peut cesser de fonctionner, et les questions à poser à vos développeurs avant toute intervention en production. C’est l’objet de cet article.
En résumé
Pour les opérations, c’est utile. Vous pouvez désormais exporter le stock au format CSV, expédier à des adresses différentes de l’adresse de livraison du client, et choisir si le client reçoit un email lors de la modification de sa commande. Ces trois points éliminent des contournements manuels que les équipes subissaient.
Pour l’IT et la sécurité, c’est un plus. Medusa propose désormais un fournisseur d’authentification OIDC générique, ce qui permet de placer les connexions du personnel derrière votre système d’identité existant.
À anticiper. Cette version introduit trois changements officiellement qualifiés de majeurs, ainsi que de nouveaux prérequis pour votre environnement d’hébergement et les navigateurs utilisés pour accéder au tableau de bord d’administration. Rien de dramatique, mais à éviter de découvrir un vendredi après-midi.
Ce que vos responsables boutique remarqueront en premier
Commençons par là, car c’est le changement qui risque le plus de générer un message Slack surpris dès le premier jour.
Medusa 2.19 met à jour le tableau de bord d’administration vers Vite 7.3.6 et React Router 7.18.2 — des versions récentes des outils de base du tableau de bord. Conséquence directe : les versions minimales de navigateur évoluent :
| Navigateur | Avant | Nouveau minimum requis |
|---|---|---|
| Chrome | 87 | 107 or newer |
| Edge | 88 | 107 or newer |
| Firefox | 78 | 104 or newer |
| Safari | 14 | 16 or newer |
Pour la plupart des équipes, cela ne change rien : tout poste avec un navigateur qui se met à jour automatiquement dépasse déjà ces versions. Mais deux cas restent fréquents dans la distribution et le commerce de gros :
- Postes partagés ou verrouillés. Terminaux d’entrepôt, ordinateurs en magasin proches du point de vente, et tout poste où la version du navigateur est figée par l’IT.
- Mac anciens. Safari 16 nécessite macOS Big Sur ou ultérieur. Un responsable boutique sur un Mac trop ancien devra passer à Chrome ou Firefox, ou changer de machine.
Avant de procéder à la mise à niveau, prenez cinq minutes pour vérifier : sur quelles machines votre équipe se connecte-t-elle réellement à l’interface d’administration, et quels navigateurs y sont installés ? Repérer un poste obsolète maintenant coûte bien moins cher que de le découvrir lorsqu’il sera impossible de traiter un retour.
La même mise à niveau relève aussi la version minimale de Node.js requise sur votre environnement serveur à ^20.19.0, ^22.12.0 ou une version LTS plus récente. Les versions 20.0–20.18 et 22.0–22.11 de Node ne sont plus prises en charge. Ce n’est pas à vous de corriger cela directement, mais il est pertinent de poser la question à votre hébergeur : sommes-nous sur une version de Node prise en charge ?
L’export d’inventaire est enfin disponible
Si vous avez déjà eu besoin de vos niveaux de stock actuels dans un tableur — pour un échange avec un fournisseur, un inventaire, une réunion de planification ou simplement pour votre comptable — vous connaissez la procédure : demander à un développeur d’exécuter une requête, ou copier les chiffres manuellement depuis le tableau de bord.
Medusa 2.19 permet désormais d’exporter les articles d’inventaire au format CSV, depuis le tableau de bord d’administration ou via l’API. Le fonctionnement est identique à celui déjà utilisé pour l’export des produits et des commandes, donc toute personne ayant déjà exporté l’un ou l’autre s’y retrouvera facilement.
C’est une petite fonctionnalité qui réduit nettement la sollicitation de votre équipe technique par les opérations. La réconciliation de stock en masse, les rapports fournisseurs et la planification d’inventaire deviennent accessibles en autonomie.
Les expéditions peuvent désormais partir vers une autre adresse
Voici une situation que la plupart des boutiques en croissance rencontrent : un client commande un article, mais celui-ci doit être expédié depuis un autre lieu que votre entrepôt — un fournisseur, un fabricant, un prestataire logistique — ou livré à une adresse différente de celle indiquée sur la commande.
Jusqu’ici, il fallait contourner le problème. En 2.19, lors de la création d’une expédition, vous pouvez indiquer une adresse de livraison distincte de celle de la commande, et transmettre des données complémentaires au prestataire logistique en même temps.
Ce que cela permet concrètement :
- Drop-shipping. Orientez une expédition vers l’adresse d’un fournisseur sans modifier la commande du client.
- Gestion multi-entrepôts et 3PL. Fournissez à votre partenaire logistique l’adresse exacte et les instructions nécessaires à l’expédition.
- Exigences spécifiques des prestataires. Le champ
additional_datapermet à votre équipe de transmettre des métadonnées transporteur ou partenaire — numéros de référence, consignes de traitement, codes client — sans devoir modifier le code à chaque nouvelle demande.
Si une partie de votre catalogue est expédiée depuis un site qui ne vous appartient pas, c’est la nouveauté de la 2.19 à signaler à vos développeurs.
Vous contrôlez les emails lors des modifications de commande
Les modifications de commande font partie du quotidien du service client : un client appelle pour ajouter un article, changer une taille ou retirer un produit avant expédition. Jusqu’à présent, il n’était pas possible d’ajuster le comportement des notifications liées à ces modifications.
Les workflows de modification de commande respectent désormais les préférences de notification : lorsque votre équipe modifie une commande, elle peut choisir d’envoyer ou non une notification au client — comme c’est déjà le cas pour d’autres opérations sur les commandes dans Medusa.
L’intérêt ici est de pouvoir juger au cas par cas. Certaines modifications justifient un email — le client doit être informé si un article en rupture est retiré. D’autres sont des corrections internes qui ne feraient que générer de la confusion et des tickets support si elles arrivaient dans la boîte de réception du client. Permettre à votre équipe de choisir réduit discrètement le volume de sollicitations.
Les connexions du personnel peuvent passer par votre fournisseur d’identité
Medusa 2.19 ajoute un fournisseur d’authentification OIDC générique. OIDC (OpenID Connect) est la norme ouverte utilisée par la plupart des systèmes d’identité d’entreprise, ce qui permet désormais d’intégrer Medusa au même système de connexion que celui déjà utilisé par votre équipe.
Pourquoi un CEO e-commerce devrait s’intéresser à une fonctionnalité qui semble purement technique :
- L’offboarding devient effectif. Lorsqu’une personne quitte l’entreprise, la suppression de son compte central coupe aussi son accès à l’admin. Plus besoin de traquer des accès orphelins avec droits de remboursement.
- Votre politique de sécurité existante s’applique. MFA obligatoire, expiration de session, règles d’accès conditionnel — tout est appliqué à un seul endroit, sans avoir à le réimplémenter pour chaque système.
- Les audits sont facilités. « Comment contrôlez-vous l’accès à votre interface d’administration e-commerce ? » devient une question simple quand la réponse est « comme pour tous nos autres accès ».
C’est une base, pas une intégration prête à l’emploi — le raccordement à votre fournisseur d’identité reste à réaliser par votre équipe technique. Mais c’est la brique qui devait exister en premier, et elle est désormais disponible.
La recherche passe côté serveur
L’authentification n’est pas le seul élément technique refondu en 2.19. Cette version modifie aussi la façon dont la recherche fonctionne dans l’admin — la barre que votre équipe utilise plusieurs fois par jour.
La 2.19 introduit un module de recherche avec un endpoint de recherche côté serveur, ainsi qu’un DSL — une méthode structurée pour définir la construction des index de recherche — et la recherche dans l’admin utilise désormais ce nouvel endpoint.
Medusa n’a pas publié de chiffres de performance à ce sujet, donc méfiez-vous de toute promesse de vitesse lue ailleurs. Ce qui est certain, c’est que la recherche s’effectue désormais côté serveur via un module dédié, et non plus comme auparavant — c’est l’architecture à privilégier si votre catalogue est volumineux ou en croissance. Si votre équipe trouvait la recherche dans l’admin lente sur un gros catalogue, c’est la version où la base technique a changé : il vaut la peine de tester à nouveau après mise à niveau.
Les trois changements majeurs, en termes clairs
Les notes de version signalent trois changements majeurs. Voici ce que chacun implique concrètement.
1. Mise à niveau vers Vite 7 et React Router 7. Déjà abordé ci-dessus : les prérequis navigateur et Node évoluent. Le risque concerne les éventuelles extensions personnalisées du tableau de bord d’administration ; elles peuvent nécessiter une mise à jour. Demandez à vos développeurs si vous en avez.
2. Suppression de quatre méthodes d’options produit du SDK JS. Les méthodes de création, modification, récupération et suppression d’options produit ont été retirées ; il faut désormais passer par la méthode générale de mise à jour produit. Seul le code personnalisé ou les intégrations utilisant ces méthodes sont concernés. C’est un changement ciblé, mais si vous avez une synchronisation PIM ou un outil de gestion de produits en masse, il faut vérifier.
3. Les totaux panier et commande sont désormais inclus par défaut. Auparavant, demander tous les champs d’un panier ou d’une commande ne renvoyait pas les totaux calculés. Désormais, ils sont inclus. Ce comportement par défaut est plus intuitif, mais ces requêtes sont donc plus lourdes qu’avant. Medusa recommande de ne demander que les champs nécessaires, et non tout — si votre vitrine ou une intégration récupère massivement paniers et commandes, il faut surveiller les performances après la mise à niveau.
Un point de détail à noter : la documentation Medusa présente les mises à jour comme rétrocompatibles pour permettre une migration progressive, alors que ces notes de version signalent explicitement trois changements majeurs. Les deux sont vrais selon le contexte — la plateforme ne supprime rien sans préavis, mais cette version impose des actions précises à certaines équipes. Fiez-vous aux notes de version plutôt qu’aux indications générales.
Questions à poser à votre équipe avant la mise à niveau
Vous n'avez pas besoin d'assurer vous-même la montée de version. Vous devez en revanche veiller à ce que les bonnes questions soient posées. Voici celles qu'il vaut la peine de formaliser :
- Sommes-nous sur une version de Node prise en charge (^20.19.0, ^22.12.0 ou LTS plus récente), et si non, quelle est la feuille de route ?
- Quels navigateurs notre équipe utilise-t-elle pour accéder à l’interface d’administration ? Y a-t-il des usages en dessous de Chrome 107 / Edge 107 / Firefox 104 / Safari 16 ?
- Avons-nous développé des extensions personnalisées pour le tableau de bord d’administration ? Ont-elles été testées avec Vite 7 et React Router 7 ?
- Notre code utilise-t-il des méthodes SDK product-option qui ont été supprimées ?
- Demandons-nous tous les champs sur les paniers ou commandes à un endroit quelconque ? Si oui, quel impact la modification des totaux a-t-elle sur les temps de réponse ?
- Avons-nous testé cela sur un environnement de préproduction fidèle à la production, y compris l’exécution des migrations de base de données ?
- Quel est notre plan de retour arrière si un problème survient après la mise en production ?
La procédure de mise à jour de Medusa est brève : mettre à jour les versions des paquets @medusajs/*, réinstaller, lancer les migrations — mais « brève » ne veut pas dire « à faire sans test sur une boutique en production ».
Faut-il mettre à jour ?
Oui, selon un calendrier adapté.
Les fonctionnalités opérationnelles de la version 2.19 visent à simplifier le quotidien plutôt qu’à ajouter des capacités à maîtriser : export d’inventaire, adresses d’expédition flexibles, gestion des notifications — votre équipe les adoptera naturellement. Le fournisseur OIDC devient pertinent dès que la gestion des accès et les audits deviennent des sujets concrets : pour la plupart des entreprises e-commerce en croissance, ce moment arrive plus tôt qu’on ne le pense.
Les changements majeurs sont ciblés et bien documentés. Le vrai risque n’est pas l’échec de la mise à jour, mais qu’on n’ait pas vérifié le navigateur du poste en entrepôt, ou qu’une extension d’administration sur-mesure, laissée de côté depuis huit mois, cesse soudain de charger.
Déployez en préproduction, passez en revue les sept questions ci-dessus, puis programmez la mise à jour en production un matin où vos développeurs sont présents et le volume de commandes faible. C’est tout le plan.
Questions fréquentes
Quelles nouveautés dans Medusa 2.19 ?
Export des articles du stock au format CSV depuis le tableau de bord d’administration ou l’API, adresses de livraison personnalisées, préférences de notification lors de la modification de commandes, fournisseur d’authentification OIDC générique, et un nouveau module de recherche avec passage de la recherche admin vers un endpoint backend.
Quelles sont les versions minimales de navigateur et de Node requises pour Medusa 2.19 ?
Le tableau de bord d’administration requiert désormais Chrome 107, Edge 107, Firefox 104 ou Safari 16 ou version ultérieure. L’environnement serveur nécessite Node.js ^20.19.0, ^22.12.0 ou une version LTS plus récente ; Node 20.0–20.18 et 22.0–22.11 ne sont plus pris en charge.
Quels sont les changements majeurs dans Medusa 2.19 ?
Trois. La mise à niveau vers Vite 7 et React Router 7 relève les prérequis navigateur et Node, quatre méthodes d’options produit ont été supprimées du JS SDK au profit de la méthode générale de mise à jour produit, et les totaux panier/commande sont désormais inclus par défaut lors de la récupération de tous les champs.
Mes extensions personnalisées du tableau de bord risquent-elles de cesser de fonctionner ?
C’est possible. Le passage à Vite 7 et React Router 7 est le principal risque : toute extension personnalisée du tableau de bord d’administration devra peut-être être adaptée. Demandez à vos développeurs si vous en utilisez, et testez-les avant toute mise à jour.
Dois-je passer à Medusa 2.19, et comment procéder ?
Oui, selon un calendrier adapté. Déployez d’abord en préproduction, passez en revue les sept points de contrôle avant mise à jour, puis planifiez la mise à jour en production : mettez à jour les versions des packages Medusa, réinstallez, lancez les migrations — idéalement un matin, avec vos développeurs disponibles et un faible volume de commandes.
Sources
Vous exploitez une boutique sous Medusa ?
Nous prenons en charge le développement Medusa pour les boutiques où le passage en préproduction, l’audit des extensions et la fenêtre de mise à jour sont des tâches suivies — par nos soins. C’est la même rigueur que pour des projets comme la boutique multi-régions d’AURA&CO sur Medusa 2.18. Si vous préférez déléguer la mise à jour 2.19, contactez-nous.