Migrer vers Sylius 2 sans perturber vos équipes ?
Pour migrer vers Sylius 2 sans perturber vos équipes commerciales et opérationnelles, on construit la nouvelle version à côté de la boutique actuelle, on limite les évolutions pendant le chantier, on confie la recette à un référent par service sur des créneaux courts et planifiés, et on bascule à un moment calme, loin des temps forts commerciaux. Vos équipes continuent de vendre et d'expédier sur la 1.14 jusqu'au dernier moment : on ne leur demande que quelques heures de vérification, au bon moment.
Je suis développeur Sylius indépendant, et sur les boutiques que j'ai migrées, ce ne sont presque jamais les sujets techniques qui inquiètent le plus les équipes. Ce sont les questions pratiques : est-ce que je vais pouvoir travailler pendant ce temps, est-ce que mes écrans vont changer, qui prévenir si quelque chose ne va pas. Voici l'organisation que je mets en place pour y répondre.
Pourquoi une migration Sylius 2 peut-elle gêner les équipes ?
Parce qu'elle touche les outils qu'elles utilisent tous les jours. Le guide officiel UPGRADE-2.0 remplace l'interface d'administration par une nouvelle, en Bootstrap 5 et Symfony UX, revoit la gestion des états de commande avec Symfony Workflow et change l'envoi des e-mails. Votre service client, votre préparation de commandes et votre équipe marketing travaillent dans ces écrans et avec ces e-mails.
La gêne ne vient donc pas du code, mais du calendrier et de la communication. Une bascule placée en pleine période de soldes, une recette demandée la veille pour le lendemain ou un nouvel écran découvert le matin de la mise en ligne suffisent à rendre le projet impopulaire, même s'il est techniquement réussi.
Quand planifier la migration dans l'année commerciale ?
Commencez par poser sur un calendrier vos temps forts : soldes, fêtes, salons, lancement de collection, clôture comptable, inventaire. La bascule doit tomber en dehors de ces périodes, avec quelques semaines de marge après elle pour corriger sereinement.
L'échéance compte aussi. Selon le cycle de publication de Sylius, Sylius 1.14 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026. Pour beaucoup de boutiques, cette date tombe juste après la période la plus chargée de l'année. Viser une bascule en pleine fin d'année pour tenir la date serait la pire option. Il vaut mieux basculer avant le pic de fin d'année quand c'est possible, ou planifier sereinement le début d'année en renforçant la surveillance. Je détaille ces arbitrages dans l'article sur la durée d'une migration.
Comment travailler pendant le chantier sans gêner la boutique ?
Une boutique en ligne qui ne bouge pas
Le développement se fait sur une branche et un environnement séparés. La boutique en 1.14 continue de tourner normalement : vos équipes prennent les commandes, gèrent le catalogue et lancent leurs opérations comme d'habitude. Rien ne change pour elles tant que la bascule n'a pas eu lieu.
Des évolutions limitées
Chaque nouvelle fonctionnalité développée sur la 1.14 pendant le chantier doit être reportée sur la version Sylius 2. Je conseille donc de limiter les évolutions aux correctifs urgents et de prévenir le développeur des opérations commerciales prévues, une promotion inhabituelle ou un nouveau mode de livraison, pour qu'elles soient testées aussi sur la nouvelle version.
Un référent par service
Nommez une personne par service concerné : commercial, service client, logistique, comptabilité. Elle connaît les gestes qui comptent dans son métier, elle fait la recette sur son périmètre et elle relaie l'information à ses collègues. C'est beaucoup plus efficace que de solliciter toute l'équipe.
Comment faire une recette qui ne prend pas des journées entières ?
La recette métier est le seul moment où vos équipes travaillent vraiment sur la migration. Pour qu'elle reste courte, je prépare avec chaque référent une liste écrite de scénarios tirés de son quotidien : passer une commande avec un code promo, rembourser un client, préparer une expédition, exporter les ventes du mois. La version Sylius 2 tourne sur une copie de vos données réelles, ce qui permet de vérifier des cas concrets et non des exemples inventés.
Les séances sont planifiées à l'avance, sur des créneaux courts, en dehors des pics de la semaine. Les écarts sont notés dans un seul endroit, corrigés, puis revérifiés au créneau suivant. Ce que les tests automatisés couvrent déjà n'est pas redemandé aux équipes. La méthode complète est dans l'article sur comment tester une migration Sylius 1 vers 2, et la prise en main du nouvel écran d'administration dans celui sur la formation des équipes au back-office.
Si vous voulez savoir combien de temps prendra ce chantier et combien de séances de recette prévoir, le diagnostic de migration offert vous donne une estimation en jours sur votre propre code.
Comment préparer le jour de la bascule et la semaine qui suit ?
Annoncez la date aux équipes plusieurs semaines à l'avance, avec l'heure de la fenêtre et ce qui sera indisponible pendant ce temps. La bascule se fait au moment où vous vendez le moins, après des répétitions sur une copie de la production, avec un retour arrière prêt. Le déroulé est décrit dans l'article sur la bascule sans coupure.
Le lendemain, les référents refont rapidement leurs scénarios principaux sur la boutique en ligne. Pendant les jours qui suivent, je surveille les commandes et les erreurs, et chaque référent dispose d'un canal direct pour signaler un écart. Une courte période de vigilance rassure davantage les équipes que n'importe quelle promesse faite avant la mise en ligne.
Ce que je vous propose
J'organise chaque migration autour de votre calendrier commercial, pas l'inverse. Le point de départ est un diagnostic offert : je lance Sylius Upgrade Analyzer sur votre projet, je vous remets un rapport commenté avec une estimation en jours, puis on fixe ensemble une fenêtre de bascule qui épargne vos temps forts. Avec la fin des correctifs de sécurité de Sylius 1.14 au 31 décembre 2026, mieux vaut choisir cette fenêtre maintenant que la subir en fin d'année. Je vous rappelle sous 24 heures ouvrées.