La version 9.1 renforce trois leviers très concrets pour les e‑commerçants : une logistique plus réaliste (plusieurs transporteurs dans une même commande via des expéditions), des promotions plus lisibles et une vitrine modernisée avec le thème Hummingbird v2 (performance, SEO, accessibilité, mobile).

Deux nouveautés importantes sont encore proposées comme fonctionnalités expérimentales : l’expédition avec plusieurs transporteurs et le nouveau système de promotions. Elles peuvent être activées, mais il est recommandé de les tester en préproduction avant de décider de les utiliser en production.

À partir de PrestaShop 9.1, le thème Hummingbird devient le nouveau thème de référence, même s’il reste possible de continuer à utiliser le thème Classic. Ce nouveau thème met l’accent sur la performance, le SEO grâce aux données structurées, l’accessibilité (avec plus de 95 % des critères EAA respectés) ainsi que sur l’intégration d’un mode sombre.

Si vous voulez en savoir plus sur cette version, je vous invite à lire mon article Découvrez PrestaShop 9, une version majeur performante.

Pour un marchand, l’enjeu est surtout opérationnel : il est important de tester les parcours principaux du site, de vérifier que les modules essentiels fonctionnent correctement (paiement, livraison, promotions) et de préparer la communication client, notamment pour expliquer les livraisons en plusieurs colis ou les règles de promotions plus claires.

Les nouveautés logistiques sur PrestaShop 9.1

Le changement principal côté logistique est l’introduction d’une logique d’expéditions au sein d’une commande : une même commande peut regrouper plusieurs expéditions, potentiellement avec des transporteurs différents, sans qu’elle soit dupliquée.

Bénéfices concrets pour le marchand (et pour le client)

La promesse est de supprimer une limite historique (“1 commande = 1 transporteur”) qui créait de la confusion : affichage incomplet au checkout, duplication automatique de commande, messages/e‑mails peu compréhensibles, surcharge de gestion côté service client.

Avec la gestion par expéditions, l’objectif annoncé est triple : ne plus dupliquer les commandes quand plusieurs transporteurs sont nécessaires, rendre le choix et l’affichage des transporteurs plus clair (nom, délai, etc.), et rendre l’information transporteur cohérente sur les points de contact (confirmation, détail commande, facture/BL, e‑mails).

En back‑office, le marchand est censé pouvoir fractionner une préparation en plusieurs expéditions (split) et aussi regrouper (merge) si besoin, directement depuis la fiche commande.

Cas d’usage “marchand” où cela change vraiment la vie

Le scénario de référence est le panier “mixte” (ex. meuble en transport spécialisé + petit article en transport standard) : auparavant le système cherchait une combinaison “best carrier” mais pouvait afficher un seul transporteur, puis dupliquer la commande.

À partir de là, on peut raisonnablement viser (à valider en test) des usages très fréquents en e‑commerce : expéditions partielles (produit en stock + produit en réassort), multi‑colis, “dropship” partiel, ou préparation différenciée selon les contraintes transporteur. La 9.1 pose explicitement une base “plus claire” et “plus scalable” autour des expéditions.

Limites actuelles et points de vigilance

Cette fonctionnalité est explicitement indiquée comme work in progress et disponible via une fonctionnalité expérimentale activable.

Point important : l’équipe indique améliorer l’interface tout en conservant la logique de sélection actuelle (combinaison “meilleur prix/note”). En clair, vous devez vérifier que vos règles de transport (prix, zones, délais, gratuité) produisent bien le résultat attendu quand plusieurs expéditions s’appliquent.

Il reste aussi des éléments listés comme “à finaliser” (ex. certains ajustements back‑office, affichage multitransporteur dans e‑mails, mise à jour des factures, gestion de cas limites) : c’est précisément ce qui doit être challengé par vos scénarios de boutique en préproduction.

Bonne nouvelle côté risque : tant que la fonctionnalité n’est pas activée, le comportement actuel reste inchangé, ce qui permet un test progressif sans impact sur la boutique de vente.

Actions à mener par le marchand (pratiques et non techniques)

Commencez par qualifier vos “vrais” besoins : combien de commandes/mois nécessitent (ou bénéficieraient) de plusieurs transporteurs ? Quels produits déclenchent des contraintes ? Créez 5 à 10 paniers types représentatifs (volumineux + standard, stock mixte, pays différents).

Ensuite, testez en préproduction en visant trois points : lisibilité au checkout (transporteurs/délais), clarté de la fiche commande en back‑office (préparation/suivi), cohérence des messages envoyés au client (e‑mails, documents).

Enfin, préparez la communication client “simple” si vous adoptez la logique multi‑expéditions : une phrase dans les pages Livraison / FAQ / e‑mails (“Votre commande peut arriver en plusieurs colis, à des dates différentes”), pour réduire les tickets “où est mon colis ?”.

Nouveau système de promotions dans Prestashop 9.1

L’objectif annoncé est d’avoir des promotions plus simples à créer, plus claires à relire (listes + détails) et plus prévisibles quand plusieurs remises cohabitent dans le panier en évitant des conflits et des soucis de performance observés avec l’empilement de règles.

Le système est restructuré autour de 4 types qui définissent “où” la remise s’applique :

• Catalog Discount : remise au niveau produit ou segment de catalogue (catégorie, marque, critères…), en montant ou en pourcentage, elle peut s’appliquer autant de fois que le produit apparaît au panier.
• Cart Discount : remise au niveau montant du panier (hors livraison), en montant ou en pourcentage.
• Free Shipping : livraison offerte avec une règle structurante : une seule remise de ce type peut s’appliquer par commande.
• Free Gift : ajout d’un produit offert (avec une exclusion annoncée : les produits personnalisables ne sont pas concernés).

Ordre d’application et compatibilités : ce que vous devez retenir

L’ordre d’application affiché est : Catalogue → Panier → Livraison offerte (priorité haute) → Cadeau.

Deux points très utiles pour un marchand : que la promo soit automatique ou via code promo ne change pas l’ordre d’application (“usage mode independence”), lorsque plusieurs promos du même type sont éligibles, elles s’appliquent selon un système de priorité, puis à défaut selon la date de création.

Enfin, le système annonce une réévaluation dynamique des remises à chaque modification de commande ou application de code (ce qui vise à réduire les “surprises” quand le panier change).

Exemples marketing concrets (et faciles à traduire en paramétrage)

Exemple “acquisition” : -10% sur une catégorie “Nouvelle collection” (Catalog Discount) + -5€ dès 60€ d’achat (Cart Discount). Résultat attendu : la remise produit se voit au niveau des lignes, puis la remise panier s’applique sur le total hors livraison.

Exemple “conversion” : livraison offerte à partir de 80€ (Free Shipping) combinée à une remise catalogue légère. À cause de la priorité élevée de la livraison offerte, vous devez tester soigneusement la marge globale quand plusieurs promos s’additionnent.

Exemple “panier moyen” : cadeau (Free Gift) au‑delà de 120€ ou pour l’achat d’un produit déclencheur (ex. un kit), afin d’augmenter la valeur perçue sans casser le prix. Le système prévoit des conditions de déclenchement liées au contenu du panier (présence de produits, quantités, montant) et aussi des conditions liées à la livraison (pays, transporteur) : utile si vous financez un cadeau seulement sur certaines zones.

Statut et adoption (à comprendre comme marchand)

Le nouveau système est indiqué comme en cours de stabilisation et activable via une fonctionnalité expérimentale dans l’administration.

Il est aussi précisé que ces 4 types “se branchent” sur le système existant, ce qui vise à préserver la compatibilité et à sécuriser l’existant : vos promos actuelles doivent rester “safe”, mais l’usage du nouveau moteur doit être validé avec vos scénarios réels.

Erreur SQL cart_rule_type doesn’t exist

Lors de l’activation, j’ai rencontré des erreurs en back-office au niveau des remises, car la nouvelle table n’existait pas. J’avais effectué une mise à jour de PrestaShop 9 vers 9.1 via le module Upgrade.

Table 'ps_cart_rule_type' doesn't exist

Vous devez alors créer la table en question mais ce n’est pas tout, cette information va être manquante dans plusieurs autres tables des réductions.

voici la requête globale à exécuter pour remettre la partie cart_rule au niveau du site PrestaShop 9.1 de référence.

Elle reprend ce qu’on voit dans ton export :

• cart_rule doit contenir id_cart_rule_type et minimum_product_quantity
• il faut aussi cart_rule_type, cart_rule_type_lang et cart_rule_compatible_types
• cart_rule_type contient 5 types de base (free_shipping, cart_level, order_level, product_level, free_gift)

Voici un script à utiliser pour vous aider, cependant cela a fonctionné pour moi sur mon test, à voir si le problème est différent selon les boutiques :

START TRANSACTION;

/* =========================================================
   1) Mise à niveau de ps_cart_rule
   ========================================================= */

/* Corrige le type si la colonne existe déjà */
ALTER TABLE `ps_cart_rule`
  MODIFY COLUMN `id_cart_rule_type` int(10) UNSIGNED DEFAULT NULL;

/* Ajoute minimum_product_quantity si besoin */
ALTER TABLE `ps_cart_rule`
  ADD COLUMN `minimum_product_quantity` int(10) UNSIGNED NOT NULL DEFAULT 0;

/* Ajoute l'index si besoin */
ALTER TABLE `ps_cart_rule`
  ADD KEY `id_cart_rule_type` (`id_cart_rule_type`);

/* Initialise les anciennes règles panier */
UPDATE `ps_cart_rule`
SET `id_cart_rule_type` = 2
WHERE `id_cart_rule_type` IS NULL OR `id_cart_rule_type` = 0;

/* =========================================================
   2) Table ps_cart_rule_type
   ========================================================= */

DROP TABLE IF EXISTS `ps_cart_rule_type`;

CREATE TABLE `ps_cart_rule_type` (
  `id_cart_rule_type` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `discount_type` varchar(128) NOT NULL,
  `is_core` tinyint(1) UNSIGNED NOT NULL DEFAULT 0,
  `active` tinyint(1) UNSIGNED NOT NULL DEFAULT 1,
  `date_add` datetime NOT NULL,
  `date_upd` datetime NOT NULL,
  PRIMARY KEY (`id_cart_rule_type`),
  UNIQUE KEY `discount_type` (`discount_type`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

INSERT INTO `ps_cart_rule_type`
(`id_cart_rule_type`, `discount_type`, `is_core`, `active`, `date_add`, `date_upd`)
VALUES
(1, 'free_shipping', 1, 1, '2026-04-03 15:53:25', '2026-04-03 15:53:25'),
(2, 'cart_level', 1, 1, '2026-04-03 15:53:25', '2026-04-03 15:53:25'),
(3, 'order_level', 1, 1, '2026-04-03 15:53:25', '2026-04-03 15:53:25'),
(4, 'product_level', 1, 1, '2026-04-03 15:53:25', '2026-04-03 15:53:25'),
(5, 'free_gift', 1, 1, '2026-04-03 15:53:25', '2026-04-03 15:53:25');

ALTER TABLE `ps_cart_rule_type`
  AUTO_INCREMENT = 6;

/* =========================================================
   3) Table ps_cart_rule_compatible_types
   ========================================================= */

DROP TABLE IF EXISTS `ps_cart_rule_compatible_types`;

CREATE TABLE `ps_cart_rule_compatible_types` (
  `id_cart_rule` int(10) UNSIGNED NOT NULL,
  `id_cart_rule_type` int(10) UNSIGNED NOT NULL,
  PRIMARY KEY (`id_cart_rule`, `id_cart_rule_type`),
  KEY `id_cart_rule` (`id_cart_rule`),
  KEY `id_cart_rule_type` (`id_cart_rule_type`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

/* =========================================================
   4) Table ps_cart_rule_type_lang
   ========================================================= */

DROP TABLE IF EXISTS `ps_cart_rule_type_lang`;

CREATE TABLE `ps_cart_rule_type_lang` (
  `id_cart_rule_type` int(10) UNSIGNED NOT NULL,
  `id_lang` int(10) UNSIGNED NOT NULL,
  `name` varchar(254) NOT NULL,
  `description` text DEFAULT NULL,
  PRIMARY KEY (`id_cart_rule_type`, `id_lang`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

/* Remplit pour toutes les langues présentes sur ton site */
INSERT INTO `ps_cart_rule_type_lang` (`id_cart_rule_type`, `id_lang`, `name`, `description`)
SELECT 1, l.id_lang, 'On free shipping', 'Discount that provides free shipping to the order'
FROM `ps_lang` l
UNION ALL
SELECT 2, l.id_lang, 'On cart amount', 'Discount applied to cart'
FROM `ps_lang` l
UNION ALL
SELECT 3, l.id_lang, 'On total order', 'Discount applied to the order'
FROM `ps_lang` l
UNION ALL
SELECT 4, l.id_lang, 'On catalog products', 'Discount applied to specific products'
FROM `ps_lang` l
UNION ALL
SELECT 5, l.id_lang, 'On free gift', 'Discount that provides a free gift product'
FROM `ps_lang` l;

COMMIT;

Thème Hummingbird v2

À partir de 9.1, le thème Hummingbird devient le thème par défaut, tout en permettant de conserver Classic si vous le souhaitez.

Bénéfices vitrine (UX, SEO, accessibilité) utiles pour un marchand

PrestaShop met en avant quatre bénéfices directement “business” : rapidité/performance (expérience client + référencement), SEO facilité via structure et données structurées, accessibilité (>95% des critères de l’European Accessibility Act), prise en charge du mode sombre.

Sur l’accessibilité, le contexte réglementaire renforce l’intérêt marchand : la Commission européenne cite explicitement les plateformes de commerce électronique parmi les services visés par l’acte législatif européen sur l’accessibilité, entré en vigueur en juin 2025.

Côté France, l’administration rappelle aussi l’entrée en vigueur (juin 2025) d’exigences nouvelles d’accessibilité sur certains produits et services. Cela concerne pour le moment des très gros e-commerce mais ce n’est pas à négliger.

Impact visuels avec Hummingbird sur PrestaShop

Les pages produits, catégories, pages CMS et modules natifs sont automatiquement adaptés à la nouvelle structure.

La documentation 9.1 précise aussi un point opérationnel : les nouvelles installations en 9.1 partent sur Hummingbird par défaut, tandis que les boutiques qui mettent à jour depuis 9.0.x conservent leur thème actuel.

Enfin, il est explicitement mentionné qu’Hummingbird introduit des différences de compatibilité par rapport à Classic : côté marchand, cela se traduit par un impératif simple, vérifier que vos modules front (réassurance, avis, cross‑sell, paiement express, chat, etc.) s’affichent au bon endroit, sans dégrader le mobile.

Faut-il migrer sur PrestaShop 9.1 ?

Si vous voulez mon avis, c’est clairement le bon moment pour envisager le passage à PrestaShop 9. Cette version gagne en stabilité, en performance et apporte de vraies améliorations concrètes pour les e-commerçants.

Cela dit, une mise à jour ne s’improvise pas. Il est essentiel de prendre certaines précautions : réaliser des tests en préproduction, valider le processus de mise à jour et s’assurer que tout fonctionne correctement avant toute mise en ligne.

Un point de vigilance important concerne vos modules : vérifiez en priorité la compatibilité de vos solutions de paiement et de livraison, mais aussi de tous les outils clés de votre boutique (marketing, ERP, connecteurs…).

Ces vérifications sont d’autant plus importantes si vous êtes dans une démarche de refonte.

Une fois ces étapes sécurisées, vous pourrez profiter pleinement des nouveautés de PrestaShop 9.1 et faire évoluer votre boutique dans de bonnes conditions.