Sylius 2 : mes promotions et tarifs fonctionneront-ils ?

Oui, vos promotions, coupons et prix par canal sont conservés lors de la migration vers Sylius 2 : ce sont des données, reprises avec la base, et le moteur de promotions de Sylius garde les mêmes principes de règles et d'actions. Ce qui peut ne plus fonctionner comme avant, ce sont les règles commerciales programmées par votre développeur (règle de promotion maison, tarif par client, remise par quantité) et tout code qui s'appuyait sur des classes déplacées. La seule garantie sérieuse est de rejouer vos paniers réels et de comparer les montants au centime.

Je suis Pierre-Arthur Demengel, développeur Sylius indépendant, et je considère les règles commerciales comme la zone la plus sensible d'une migration. Une erreur d'affichage se voit tout de suite. Une remise qui ne se cumule plus correctement, elle, peut passer inaperçue pendant des semaines et se répéter sur chaque commande.

Les règles de promotions seront-elles conservées ?

Les promotions natives, oui. Une promotion panier dans Sylius se compose de règles (montant du panier, quantité, groupe de clients, produit ou taxon présent, pays de livraison, énième commande) et d'actions (remise fixe ou en pourcentage sur la commande ou sur les articles, remise sur la livraison). Elle porte ses canaux, ses dates, sa priorité, son caractère cumulable ou exclusif et, si besoin, ses coupons. Tout cela est stocké en base et repris tel quel. Les promotions catalogue, qui modifient le prix affiché d'un ensemble de produits, sont reprises de la même façon.

Pour votre équipe marketing, rien n'est à ressaisir. Les écrans de création et de modification des promotions sont redessinés, comme le reste de l'administration, mais une promotion programmée pour les soldes reste programmée.

Les tarifs spécifiques fonctionneront-ils comme avant ?

Il faut d'abord savoir d'où ils viennent. Sylius gère nativement un prix par variante et par canal, avec un prix barré facultatif et un historique des prix qui sert à afficher le prix le plus bas des trente derniers jours. Ces prix sont repris. Le guide officiel UPGRADE-API-2.0 précise que la configuration de cet historique est désormais portée par le canal, et que les prix par canal se consultent sous la variante dans l'API.

Les tarifs par client, par groupe de clients ou par volume relèvent le plus souvent d'un plugin ou d'un développement spécifique. C'est sur eux que porte le risque. Un plugin de tarification doit exister en version compatible Sylius 2 : la méthode de vérification est décrite dans l'article sur les plugins compatibles Sylius 2. Un développement maison, lui, doit être relu et testé.

Qu'est-ce qui change pour les règles commerciales sur mesure ?

Le guide officiel UPGRADE-2.0 liste plusieurs changements dans le moteur de promotions. Des classes ont changé d'espace de noms, comme le vérificateur de règle sur le total des articles, déplacé du composant Promotion vers le composant Core. D'autres ont été supprimées, des formulaires ont été déplacés entre les bundles, et des constructeurs de services liés aux promotions catalogue ont changé de signature. Une règle ou une action maison qui étendait ces classes ne démarre plus, ou pire, se comporte différemment.

Autre point à connaître : un correctif de sécurité publié dans la version 2.0.16 rend atomique le comptage des utilisations d'une promotion, pour éviter que des commandes simultanées dépassent la limite d'un coupon. Il décore un service existant. Si votre projet avait lui-même modifié ce service, la combinaison doit être vérifiée.

Enfin, toute règle déclenchée par un changement d'état de commande, comme un bon d'achat offert après paiement ou un avoir à l'annulation, dépend de la machine à états, qui passe de winzou à Symfony Workflow. Ce sujet est traité dans l'article sur les commandes, paiements et promotions après la migration.

Pour repérer ce code, je lance Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store. Il signale les classes supprimées ou déplacées, les services renommés et les callbacks winzou, avec une estimation en heures. Si vous voulez savoir ce qu'il trouve sur vos règles commerciales, c'est le point de départ du diagnostic de migration offert.

Comment tester les promotions avant la bascule ?

Je construis avec vous une matrice de paniers. Chaque ligne est un cas réel : un client particulier sans coupon, un client professionnel de tel groupe, un panier au-dessus du seuil de livraison offerte, deux promotions qui se cumulent, un coupon expiré, une promotion catalogue sur un produit déjà soldé, une livraison vers un autre pays. Je rejoue chaque panier sur la version 1.14 et sur la version 2, sur la même copie de données, et je compare les sous-totaux, les remises, la TVA, les frais de port et le total au centime.

Je complète par un relevé des promotions et coupons actifs avant et après la migration, avec leurs compteurs d'utilisation, et par un passage en revue des promotions programmées pour les semaines suivant la bascule. Une opération commerciale prévue juste après la mise en production mérite un test dédié. La démarche de recette complète est décrite dans l'article sur comment tester une migration Sylius 1 vers 2.

Ce que je vous propose

Je lance l'analyseur sur votre projet, je relève les règles, actions et tarifs portés par du code maison ou par des plugins, et je vous remets un rapport commenté avec une estimation en jours. Je vous rappelle sous 24 heures ouvrées. Avec la fin du support de sécurité de Sylius 1.14 le 31 décembre 2026, mieux vaut connaître tôt l'effort sur vos règles commerciales que de le découvrir pendant les soldes.