Sylius 2 : que faire des commandes en cours à la bascule ?
On gère les commandes en cours en les laissant se terminer sur l'ancienne version avant de figer la boutique : on ferme les nouvelles commandes pendant une fenêtre courte, on attend que les paiements commencés soient confirmés ou expirés, on fige les statuts d'expédition, puis on migre la base à jour. Aucune commande n'est ressaisie, et chaque paiement reçu est rapproché d'une commande après la bascule. Les paniers ouverts sont le seul élément dont une petite partie peut être perdue, et cela se décide à l'avance.
La méthode générale de mise en production, avec ses répétitions et son retour arrière, est décrite dans l'article sur la bascule vers Sylius 2 sans coupure. Ici, je ne traite que ce qui est en mouvement au moment précis de la bascule : les paiements en attente, les paniers et les expéditions. C'est le moment où une commande peut se perdre entre deux versions, et c'est pour cela qu'il mérite une procédure à lui seul.
Pourquoi les commandes en cours posent-elles problème ?
Une commande Sylius n'est pas un objet figé : elle passe par des états successifs, du panier à la commande payée puis expédiée. Au moment où vous basculez, certaines commandes sont au milieu de ce parcours. Un client est sur la page de son prestataire de paiement. Un autre a validé sa commande mais la banque n'a pas encore confirmé. Votre équipe logistique est en train de marquer des colis comme expédiés.
Le risque n'est pas que ces commandes disparaissent : elles sont dans la base, qui est migrée. Le risque est qu'un événement arrive au mauvais moment, pendant que la base est figée ou juste après, sur une version qui ne sait pas le traiter. Et en Sylius 2, ce qui traite ces événements change. Le guide officiel UPGRADE-2.0 indique que l'adaptateur par défaut des transitions de commande passe de winzou à Symfony Workflow, que la configuration des états de paiement est déplacée et que les paiements s'appuient sur SyliusPayumBundle et sur les nouvelles Payment Requests.
Les paiements en attente : le point le plus sensible
C'est la catégorie qui demande le plus de soin. Quand un client paie par carte ou par un portefeuille en ligne, la confirmation arrive souvent par une notification envoyée par le prestataire à votre boutique. Si cette notification arrive pendant la fenêtre de bascule, la boutique ne peut pas la traiter. Si elle arrive juste après, elle frappe une nouvelle version dont les adresses ou la mécanique de paiement ont pu changer.
Ma procédure tient en trois temps. Avant la fenêtre, je ferme la prise de nouvelles commandes, ce qui arrête la création de nouveaux paiements, puis j'attends que les paiements déjà lancés aboutissent ou expirent. Je surveille pour cela la liste des paiements à l'état nouveau ou en cours de traitement dans l'administration. Pendant les répétitions, je vérifie aussi que les adresses de notification déclarées chez votre prestataire fonctionnent sur la version Sylius 2, ou qu'une redirection est prévue si elles changent. Après la bascule, je rapproche les paiements reçus chez le prestataire sur la période avec les commandes enregistrées, pour qu'aucun client ne soit débité sans commande payée.
Beaucoup de prestataires réessaient l'envoi d'une notification qui a échoué, mais la durée et le nombre d'essais varient d'un prestataire à l'autre. Je le vérifie dans leur documentation pour votre cas plutôt que de le supposer. Ce qui change sur les intégrations elles-mêmes est traité dans l'article sur vos moyens de paiement après la migration.
Les paniers ouverts : ce qui est conservé et ce qui ne l'est pas
Dans Sylius, un panier est une commande à l'état panier, enregistrée en base. Les paniers des clients connectés sont donc migrés avec le reste et retrouvés à la reconnexion. Les paniers des visiteurs non connectés sont rattachés à leur session : si les sessions sont stockées d'une manière qui ne survit pas à la bascule, ces paniers sont perdus. Sylius 2 reconstruit aussi le panier côté boutique avec des composants Twig, et le guide officiel supprime plusieurs routes Ajax de l'ancien panier.
Pour un dirigeant, l'enjeu est faible mais réel : quelques visiteurs devront remettre leurs articles dans le panier. Je le signale à l'avance, je choisis une heure de bascule où le trafic est au plus bas, et je décide avec vous s'il vaut la peine de conserver les sessions. Je profite aussi de la préparation pour nettoyer les paniers expirés, avec la commande prévue par Sylius pour cela, ce qui allège la base à migrer.
Les expéditions et les échanges avec la logistique
Les expéditions posent un problème différent : elles mettent souvent en jeu un outil externe, logisticien, transporteur ou ERP, qui lit ou écrit des statuts dans la boutique. Pendant la fenêtre de bascule, ces échanges doivent être suspendus. Je coupe les tâches planifiées d'export et d'import, et je demande à votre équipe de ne plus changer de statut dans l'administration jusqu'à la validation de la nouvelle version.
Les colis déjà préparés partent normalement : seul leur statut attend. Après la bascule, les échanges reprennent sur Sylius 2 et je vérifie que les commandes en attente d'expédition au moment du gel sont bien transmises, une fois et une seule. Un doublon d'envoi vers le logisticien est aussi coûteux qu'un oubli. Si vos règles d'expédition étaient branchées sur des callbacks winzou, elles doivent avoir été portées au préalable, comme l'explique l'article sur le passage de winzou à Symfony Workflow.
Le jour J, minute par minute
Je rédige pour chaque boutique une feuille de route de la fenêtre, validée pendant les répétitions : heure de fermeture des commandes, liste des paiements encore ouverts, arrêt des tâches planifiées, sauvegarde, migration, contrôles, réouverture. Chaque étape a un responsable et une durée mesurée. Le comptage des commandes et des paiements avant et après fait partie des contrôles, comme le rapprochement avec le prestataire de paiement.
Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store, repère dans votre code les transitions winzou personnalisées, les passerelles de paiement à reprendre et les routes supprimées. C'est la liste des mécanismes qui touchent aux commandes en cours. Si vous voulez la connaître pour votre boutique, elle fait partie du diagnostic de migration offert.
Ce que je vous propose
Je lance Sylius Upgrade Analyzer sur votre projet, j'identifie ce qui touche aux paiements, aux paniers et aux expéditions, et je vous remets un diagnostic offert commenté avec une estimation en jours. Je vous rappelle sous 24 heures ouvrées. Les correctifs de sécurité de Sylius 1.14 s'arrêtent le 31 décembre 2026 : une bascule préparée se planifie au creux de votre activité, pas dans l'urgence de fin d'année.