Comment garantir commandes, paiements et promos Sylius 2 ?

On ne garantit pas que commandes, paiements et promotions fonctionnent après une migration Sylius 2 par une promesse, mais par une preuve : une liste écrite de scénarios tirés de votre activité réelle (vos moyens de paiement, vos promotions, vos modes de livraison), joués à l'identique sur la version 1.14 et sur la version 2 à partir de la même copie de données, puis comparés ligne à ligne. Si les totaux, les états de commande et les e-mails sont identiques, le processus de commande fonctionne. S'ils diffèrent, vous le savez avant vos clients.

Je suis développeur Sylius indépendant et le tunnel de commande est la partie que je teste en premier sur chaque montée de version. C'est là que se trouve votre chiffre d'affaires, et c'est aussi là que Sylius 2 change le plus de choses sous le capot.

Pourquoi le processus de commande est-il la zone la plus exposée ?

Parce que trois ruptures majeures de Sylius 2 le traversent en même temps. Le guide officiel UPGRADE-2.0 indique que l'adaptateur de machine à états par défaut passe de winzou à Symfony Workflow : c'est le mécanisme qui fait avancer une commande de « nouvelle » à « payée » puis « expédiée ». Le même guide retire du cœur les passerelles Stripe et PayPal Express et ajoute les Payment Requests, qui s'appuient sur Symfony Messenger. Enfin, plusieurs classes liées aux règles de promotion sont supprimées ou déplacées.

À cela s'ajoutent les e-mails : SwiftMailer laisse la place à symfony/mailer, et les gestionnaires d'e-mails de commande de la boutique et de l'administration sont retirés. Une confirmation de commande peut donc cesser de partir sans qu'aucune page n'affiche d'erreur. Pour un dirigeant, cela se résume simplement : la partie du site qui encaisse est aussi celle dont la mécanique change le plus.

Comment garantir que le processus de commande fonctionnera après la migration ?

La méthode tient en quatre temps. On fixe d'abord la référence : une liste de scénarios réels. On les joue ensuite sur la 1.14 pour enregistrer le résultat attendu. On les rejoue sur la version 2, sur la même copie de données. On compare enfin les résultats, et chaque écart devient un ticket à traiter avant la bascule.

Construire les scénarios à partir de vos vraies données

Je ne pars pas d'une liste théorique, je pars de votre base. Quels moyens de paiement ont été utilisés ces derniers mois ? Quels modes de livraison ? Quelles promotions sont actives, avec quelles conditions ? Avez-vous des clients professionnels avec des tarifs différents, plusieurs canaux de vente, plusieurs devises ? Chaque combinaison qui pèse dans vos ventes devient un scénario : client invité ou connecté, panier, adresse, livraison, paiement, confirmation.

Vérifier les états de commande, pas seulement la page de remerciement

Une page « merci pour votre commande » ne prouve rien. Pour chaque scénario, je contrôle l'état de la commande, l'état du paiement et l'état de l'expédition dans l'administration, puis je fais avancer la commande jusqu'au bout : paiement validé, expédition, annulation, remboursement si vous les pratiquez. C'est à ce moment qu'on découvre une règle métier qui était branchée sur une transition winzou et qui n'est plus appelée. La question de garder winzou pendant la transition est traitée dans l'article sur le passage de winzou à Symfony Workflow.

Comment s'assurer que les paiements fonctionnent toujours ?

Chaque moyen de paiement se teste en mode bac à sable chez le prestataire, et pas seulement le cas heureux. Il faut aussi jouer le paiement refusé, le paiement abandonné à mi-parcours, le retour du client après une authentification forte, et surtout la notification envoyée par le prestataire au serveur. C'est elle qui confirme réellement le paiement, et c'est souvent elle qui casse en silence. Sylius 2 ajoute une route dédiée aux notifications de paiement et des files Messenger pour les demandes de paiement : leur configuration fait partie de la recette.

Si votre boutique utilisait les passerelles Stripe ou PayPal fournies par le cœur de Sylius 1, il faudra passer par une intégration compatible Sylius 2. Le détail du changement est dans l'article consacré à Payum et les Payment Requests. Ce point mérite d'être tranché tôt, car il dépend parfois d'un éditeur de plugin et pas seulement de votre code.

Comment vérifier que les promotions donnent le même résultat ?

Les promotions et les coupons sont des données : ils sont repris avec la base. Le risque est ailleurs, dans les règles et actions développées sur mesure, et dans les promotions qui se combinent. Ma méthode est la comparaison chiffrée : pour chaque promotion active, le même panier est construit sur la 1.14 et sur la version 2, et je compare le sous-total, la remise, les frais de port, les taxes et le total. Un écart d'un centime est un écart. Je vérifie aussi les limites d'utilisation et les coupons à usage unique.

Un détail qui illustre l'intérêt de viser une version à jour : les notes de la version 2.0.16 dans le guide officiel mentionnent la correction d'une situation de concurrence qui permettait à des commandes simultanées de dépasser la limite d'utilisation d'une promotion. Une boutique qui fait des opérations commerciales limitées a tout intérêt à migrer vers une version 2.x récente et maintenue, pas vers une version figée.

Si vous voulez savoir quelles règles de commande, de paiement et de promotion de votre boutique sont concernées, c'est ce que je repère pendant le diagnostic de migration offert, avant même de chiffrer.

Que surveiller après la mise en ligne ?

La recette réduit le risque, la surveillance des premiers jours le referme. Je suis de près le nombre de commandes par heure comparé à une période équivalente, la part de paiements en attente qui ne passent jamais à l'état payé, les journaux d'erreurs, la file des messages en échec et l'envoi effectif des e-mails. Un écart dans l'une de ces mesures se voit en quelques heures, et se corrige avant qu'il ne coûte une journée de ventes. Pour la bascule elle-même, je renvoie à l'article sur la mise en production sans coupure.

Ce que je vous propose

Je commence par lancer Sylius Upgrade Analyzer, l'outil open source que j'ai publié sur le Sylius Store, sur votre projet. Il repère les transitions de commande, les passerelles de paiement et les règles de promotion à reprendre. J'y ajoute la liste de vos scénarios de commande réels, et je vous remets un rapport commenté avec une estimation en jours. Je vous rappelle sous 24 heures ouvrées. La 1.14 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026 : mieux vaut que votre tunnel de commande soit prouvé sur Sylius 2 avant cette date.