Electrodepot - externalisation de la gestion des transporteurs
Magento 2.4 intègre nativement un système de gestion des transporteurs (carriers) qui permet de proposer différentes méthodes de livraison sans module tiers. Voici une explication structurée.
Dans Magento, un « transporteur » (carrier) est un composant qui calcule les frais de port et propose une ou plusieurs « méthodes » de livraison au client pendant le checkout. Lors de la passation de commande, Magento interroge tous les transporteurs actifs, collecte leurs tarifs (rates) et affiche au client la liste des options disponibles avec leur prix.
L'ensemble se configure depuis l'admin via Stores > Configuration > Sales > Méthodes de livraison (Shipping Methods), tandis que l'origine de l'expédition et les paramètres généraux se trouvent dans Sales > Paramètres de livraison (Shipping Settings).
Les Table Rates reposent sur une idée simple en apparence : un tableau où chaque ligne associe une destination à une condition et à un tarif. En pratique, c'est la combinatoire de ces éléments qui devient vite difficile à maintenir.
Une ligne de Table Rate croise toujours :
Le problème, c'est que ces dimensions ne s'additionnent pas, elles se multiplient. Si vous livrez dans 30 pays et que vous voulez 5 tranches de poids par pays, vous êtes déjà à 150 lignes. Ajoutez une granularité par région ou par code postal, et le tableau explose : on passe vite à plusieurs milliers de lignes pour une couverture fine.
Le tarif ne se choisit pas sur une valeur exacte mais sur un seuil minimum : Magento retient la ligne dont la condition (poids, montant…) est la plus élevée tout en restant inférieure ou égale à celle du panier. Concrètement, une ligne « à partir de 5 kg » couvre tout jusqu'à la ligne suivante.
Cela crée deux pièges classiques :
Pour éviter de tout lister, on utilise des astérisques * qui signifient « toutes les valeurs ». Mais cela introduit une hiérarchie de spécificité : une ligne précise (France / région Île-de-France) doit l'emporter sur une ligne générique (France / *). Bien doser le mélange de lignes précises et de lignes « fourre-tout » est délicat — trop de génériques et les tarifs fins ne s'appliquent jamais ; pas assez, et certaines destinations passent à travers les mailles.
Tout cela se gère via un import CSV, pas dans une interface visuelle. Une colonne mal nommée, un code pays au mauvais format, un séparateur décimal incorrect, ou un import qui remplace intégralement la grille existante au lieu de la compléter : autant d'occasions de casser silencieusement toute la tarification. Et comme il n'y a pas de validation métier (Magento ne vous prévient pas qu'il manque la tranche « 0 à 2 kg »), les erreurs ne se révèlent souvent qu'au moment où un client ne voit plus aucune option de livraison.
Pour dépasser les limites structurelles des Table Rates natives décrites plus haut, nous avons fait le choix de basculer vers une architecture en microservices entièrement externalisée. Plutôt que de confier la gestion tarifaire au cœur monolithique de Magento, la logique de calcul des frais de livraison est désormais déportée vers un service dédié, autonome et spécialisé, qui communique avec la boutique par l'intermédiaire d'API.
Cette communication s'établit dans les deux sens. Côté back-end, le service expose les tarifs et les règles de couverture à Magento au moment où celui-ci en a besoin, notamment lors du calcul des frais au checkout. Côté front-end, l'interface peut interroger directement le service pour afficher les options de livraison de manière fluide, sans dépendre entièrement des cycles de traitement internes de Magento. Cette séparation claire des responsabilités allège considérablement la plateforme et ouvre la voie à des évolutions indépendantes de chaque brique.
L'un des bénéfices les plus immédiats de cette bascule réside dans la rapidité d'exécution. En sortant du paradigme relationnel MySQL — sur lequel reposent traditionnellement les Table Rates, avec toutes les lourdeurs de requêtage qu'implique une grille de plusieurs milliers de lignes —, le microservice peut s'appuyer sur des mécanismes de stockage et d'indexation bien plus adaptés à ce type de recherche tarifaire. Les temps de réponse s'en trouvent nettement améliorés, et la montée en charge devient beaucoup plus sereine, y compris lorsque le volume de zones et de règles à gérer augmente fortement.
Au-delà de la performance, c'est l'expérience d'administration qui change radicalement. Là où la configuration native imposait de manipuler à l'aveugle des fichiers CSV sans aucun garde-fou, le système propose désormais une interface intégrée directement dans l'admin Magento, pensée selon des principes d'UX/UI soignés. Tout devient configurable simplement, de façon visuelle et intuitive : la définition des zones, l'attribution des tarifs et la gestion des conditions de déclenchement se font dans un environnement clair, sans nécessiter de connaissances techniques particulières ni de manipulations de fichiers fragiles.
Enfin, cette nouvelle approche répond frontalement au problème des trous dans la couverture de livraison, qui constituait l'un des principaux écueils des Table Rates. Plutôt que de laisser une destination passer silencieusement à travers les mailles du filet — avec pour conséquence la disparition pure et simple de l'option de livraison au moment du paiement —, le système met en évidence de manière explicite les zones non couvertes. L'administrateur dispose ainsi d'une vision d'ensemble de sa politique de livraison et peut identifier, puis combler, les éventuelles lacunes avant qu'elles ne se traduisent par une commande perdue.