Votre boutique est-elle concernée par Sylius 2 ?
Votre boutique est concernée par la migration Sylius 2 si elle tourne sur une version 1.x de Sylius, quelle qu'elle soit : la 1.14, dernière version 1.x, ne reçoit plus de correctifs de sécurité après le 31 décembre 2026, et les versions antérieures n'en reçoivent déjà plus. Une boutique en 2.0 ou en 2.1 est concernée elle aussi, par une montée de version plus légère. Pour le savoir, il suffit de vérifier le numéro de version dans le projet, puis de mesurer ce que votre code personnalisé implique.
Beaucoup de dirigeants ne savent pas sur quelle version tourne leur boutique, et c'est normal : ce n'est pas leur métier. Le site a été construit par une agence ou un freelance, il fonctionne, et la question ne s'est jamais posée. Voici comment répondre en quelques minutes, puis comment évaluer si votre migration sera un petit chantier ou un gros projet.
Comment savoir sur quelle version de Sylius tourne ma boutique ?
La version se lit dans le code, pas dans l'interface publique. La méthode la plus simple consiste à demander à votre développeur ou à votre agence de lancer composer show sylius/sylius à la racine du projet. La commande show est documentée dans la documentation officielle de Composer. Sans accès à la ligne de commande, on peut aussi ouvrir le fichier composer.lock et chercher le paquet sylius/sylius : le champ version donne le numéro exact.
Si le numéro commence par 1, votre boutique est concernée par la migration. S'il commence par 2.0 ou 2.1, elle est concernée par une mise à jour vers une version 2.x encore maintenue. Le cycle de publication officiel de Sylius donne les dates : la 1.12 n'a plus de correctifs de sécurité depuis le 31 décembre 2024, la 1.13 depuis le 30 avril 2025, la 2.0 depuis le 28 février 2026 et la 2.1 depuis le 30 septembre 2026. La 1.14 en reçoit jusqu'au 31 décembre 2026.
Si personne ne peut vous donner ce numéro, c'est déjà une information importante : cela signifie que vous n'avez plus la maîtrise technique de votre boutique. Récupérer l'accès au code et à l'hébergement devient alors la toute première étape.
Toutes les boutiques Sylius 1.x sont-elles concernées de la même façon ?
Non. Toutes doivent migrer, mais l'ampleur du chantier varie énormément. Le guide officiel UPGRADE-2.0 prévient dès le début qu'une application même peu personnalisée demandera des ajustements manuels avant de fonctionner à nouveau. Le reste dépend de ce que votre boutique a ajouté au Sylius d'origine.
Le plus simple est de vous poser quelques questions. Votre boutique a-t-elle un design sur mesure, construit en surchargeant les gabarits Twig de Sylius ? Si oui, l'interface est à reprendre, car Sylius 2 abandonne Semantic UI et jQuery au profit de Bootstrap 5 et de Symfony UX. Utilise-t-elle des plugins tiers, pour le paiement, la livraison, les avis ou la facturation ? Chacun doit exister en version compatible. Votre processus de commande a-t-il été adapté, avec des états ou des actions automatiques après un paiement ou une expédition ? Ce code repose sur une machine à états qui change par défaut en Sylius 2. Enfin, la boutique est-elle reliée à un ERP, à une application mobile ou à un front séparé par l'API ? Le passage d'API Platform 2.7 aux versions récentes impose alors de retester ces échanges.
Chaque « oui » ajoute un poste au chantier. Une boutique qui répond « non » partout reste concernée, mais sa migration sera courte.
Quels signes montrent que la migration sera lourde ?
Sur les boutiques que j'ai migrées, trois signaux annoncent un chantier plus long. Le premier est une version de départ ancienne : en dessous de la 1.14, il faut d'abord rejoindre la 1.14, et en dessous de la 1.10 la question d'une reconstruction se pose. Le deuxième est un plugin abandonné par son éditeur, sans version pour Sylius 2, qu'il faudra remplacer ou réécrire ; l'article sur la compatibilité des plugins avec Sylius 2 explique comment le vérifier. Le troisième est un serveur encore en PHP 8.1, alors que Sylius 2 exige PHP 8.2 et que la 2.3 demande PHP 8.3.
À l'inverse, une boutique en 1.14 à jour, sans dépréciations, avec peu de surcharges et des plugins officiels, part avec une longueur d'avance.
Comment mesurer précisément l'ampleur du chantier ?
Les questions ci-dessus donnent une tendance. Pour un inventaire réel, il faut analyser le code. C'est pour cela que j'ai créé Sylius Upgrade Analyzer, un outil open source sous licence MIT publié sur le Sylius Store. Il s'exécute en local sur le projet, sans que le code quitte votre machine, et passe 49 analyseurs sur les gabarits, les plugins, les dépréciations, les paiements et l'API. Chaque problème détecté reçoit une estimation, et le rapport donne un total en heures par catégorie.
Si vous ne voulez pas l'installer vous-même, je le fais pour vous dans le cadre d'un diagnostic de migration offert : je lance l'outil, je complète à la main ce qu'il ne voit pas, et vous savez précisément à quel point votre boutique est concernée. Pour passer ensuite de cet inventaire à une durée, la méthode est détaillée dans l'article sur l'estimation d'une migration en jours.
Ce que je vous propose
Si votre boutique tourne sur une version 1.x, elle est concernée, et l'échéance du 31 décembre 2026 approche. Le plus utile n'est pas de s'inquiéter, c'est de savoir. Je lance Sylius Upgrade Analyzer sur votre projet, je vous remets un rapport commenté avec la version de départ, les points sensibles et une estimation en jours, et je vous rappelle sous 24 heures ouvrées. Le diagnostic est offert, et le rapport vous appartient, même si vous confiez ensuite la migration à quelqu'un d'autre.