winzou State Machine est-il supprimé de Sylius 2 ?

Non. Il n'est plus installé ni utilisé par défaut, mais Sylius 2 le propose toujours comme dépendance suggérée. Si vous installez les paquets winzou et réactivez le bundle, Sylius charge encore ses propres graphes au format winzou.

Peut-on avoir certains graphes sous winzou et d'autres sous Symfony Workflow ?

Oui. La couche d'abstraction de Sylius permet de choisir l'adaptateur graphe par graphe avec graphs_to_adapters_mapping. C'est même la façon la plus sûre de migrer progressivement, en commençant par les graphes que vous n'avez pas personnalisés.

Garder winzou rend-il la migration moins chère ?

Cela allège la première étape, puisque les transitions personnalisées n'ont pas à être réécrites tout de suite. Mais le travail n'est que déplacé : il faudra le faire plus tard, et entre-temps vous maintenez deux mécanismes.

Mes callbacks winzou fonctionneront-ils si je passe un graphe sous Symfony Workflow ?

Non. Les callbacks déclarés dans la configuration winzou ne s'exécutent que si le graphe utilise l'adaptateur winzou. Sous Symfony Workflow, ils doivent être réécrits en écouteurs d'événements, sinon ils sont simplement ignorés.

Peut-on garder winzou pendant la migration Sylius 2 ?

Oui, on peut conserver winzou State Machine pendant la migration vers Sylius 2 : Sylius 2 utilise Symfony Workflow par défaut, mais il garde winzou comme dépendance optionnelle et permet de choisir le moteur graphe par graphe. C'est une bonne solution de transition pour une boutique qui a beaucoup de règles métier branchées sur les états de commande, de paiement ou d'expédition. Ce n'est pas une destination : elle décale le travail, elle ne le supprime pas.

Je suis développeur Sylius indépendant et j'ai mené des montées de version 1.x vers 2.x de boutiques en production. Cet article répond à une seule question, garder winzou pendant la transition. La conversion elle-même, de la configuration winzou vers Symfony Workflow, est détaillée dans le guide migrer winzou vers Symfony Workflow.

Que dit la documentation officielle de Sylius sur winzou ?

Le guide UPGRADE-2.0 contient trois informations utiles. Le bundle winzou est retiré de la liste des bundles activés. Les paquets winzou/state-machine et winzou/state-machine-bundle passent dans la section des dépendances suggérées : si vous voulez continuer à les utiliser, il faut les installer vous-même. Enfin, l'adaptateur par défaut de la couche d'abstraction passe de winzou_state_machine à symfony_workflow.

Cette couche d'abstraction n'est pas nouvelle. Le fichier UPGRADE-1.13 explique que Sylius 1.13 a introduit le paquet sylius/state-machine-abstraction pour permettre une transition en douceur, avec le choix de l'adaptateur par graphe. En 1.13 et 1.14, winzou reste le défaut. En 2.0, c'est l'inverse.

J'ai vérifié dans le code de Sylius 2.3 : le cœur charge toujours ses propres graphes au format winzou si le bundle winzou est présent. Et le bundle winzou a reçu une nouvelle version en mars 2026 qui déclare la compatibilité avec Symfony 8. Garder winzou en Sylius 2 n'est donc pas un bricolage, c'est un chemin prévu.

Comment garder winzou pendant la transition ?

Trois étapes suffisent sur le plan technique. D'abord, installer les deux paquets winzou dans votre projet Sylius 2 et réactiver le bundle dans config/bundles.php. Ensuite, dire à Sylius quel moteur utiliser. La configuration se fait sous la clé sylius_state_machine_abstraction : l'option default_adapter fixe le moteur par défaut, et l'option graphs_to_adapters_mapping le fixe graphe par graphe, par exemple sylius_order_checkout: winzou_state_machine. Enfin, vérifier que tout votre code passe par l'abstraction.

Ce dernier point est celui qui coince. Le code qui appelle directement la fabrique de winzou contourne le choix de l'adaptateur. Il faut le faire passer par l'interface Sylius\Abstraction\StateMachine\StateMachineInterface, dont les méthodes can et apply prennent le nom du graphe en paramètre. C'est d'ailleurs un travail utile quoi qu'il arrive : une fois le code passé par l'abstraction, changer de moteur devient une ligne de configuration.

Quelle stratégie, graphe par graphe ?

Sylius gère plusieurs graphes : la commande, le tunnel de commande, le paiement de la commande, son expédition, le paiement, l'expédition, l'avis produit, la promotion catalogue, et en 2.x la demande de paiement. Sur la plupart des boutiques, seuls deux ou trois ont été personnalisés. C'est là que la migration par graphe prend tout son sens.

Je procède ainsi. Sur la 1.14, avant même de changer de version, je fais passer sous Symfony Workflow les graphes que le projet n'a jamais modifiés, et je teste. Ceux qui portent des règles métier restent sous winzou. La migration vers Sylius 2 se fait alors avec un périmètre réduit. Les graphes restants sont convertis un par un, après la mise en production, chacun avec sa propre recette.

Cette approche a un vrai intérêt pour le dirigeant : la partie la plus sensible, celle qui touche aux commandes et aux paiements, n'est pas réécrite en même temps que le reste du socle. Si un problème apparaît, on sait d'où il vient. C'est le genre d'arbitrage que je chiffre poste par poste dans le diagnostic de migration Sylius 2.

Quels sont les pièges quand on garde winzou ?

Les callbacks silencieusement ignorés

Avec winzou, les actions déclenchées par une transition, comme l'envoi d'un e-mail ou une synchronisation vers l'ERP, sont souvent déclarées dans la configuration du graphe. Elles ne s'exécutent que si ce graphe tourne sous winzou. Passez-le sous Symfony Workflow sans les réécrire, et rien ne plante : elles ne se déclenchent simplement plus. C'est le pire type de régression, parce qu'on la découvre quand un client réclame son e-mail de confirmation ou qu'un entrepôt ne reçoit plus de commandes.

La configuration en double

Sylius 2 ajoute ses propres écouteurs côté Symfony Workflow. Une personnalisation faite d'un seul côté donne deux comportements différents selon l'adaptateur. Je documente pour chaque graphe le moteur utilisé et l'endroit où vit sa logique.

Le provisoire qui dure

winzou n'est plus que suggéré. Les nouveautés de Sylius sont écrites d'abord pour Symfony Workflow, et chaque montée de version 2.x vous obligera à vérifier que le chemin winzou fonctionne toujours. Je fixe donc une date de fin à la transition dès le départ. Sylius Upgrade Analyzer, l'outil que j'ai créé et publié sur le Sylius Store, détecte les configurations winzou du projet et propose une conversion automatique de leur YAML vers Symfony Workflow, que je relis toujours à la main.

Pour vérifier que les commandes, les paiements et les promotions se comportent comme avant, quel que soit le moteur, la méthode de test est décrite dans l'article sur les commandes, paiements et promotions après la migration.

Ce que je vous propose

Garder winzou est souvent la meilleure façon de tenir l'échéance du 31 décembre 2026, fin du support de sécurité de Sylius 1.14, sans réécrire en urgence les règles qui touchent à votre chiffre d'affaires. Encore faut-il savoir quels graphes vous avez personnalisés et ce qu'ils déclenchent. Je lance l'analyse sur votre projet et je vous remets un diagnostic offert, avec la liste des graphes concernés, la stratégie conseillée et une estimation en jours.