Faut-il remplacer des plugins par le natif de Sylius 2 ?

Oui, il faut remplacer un plugin par une fonctionnalité native de Sylius 2 chaque fois que le cœur couvre vraiment votre besoin, car chaque plugin en moins est un paquet de moins à maintenir et à faire évoluer. Mais la liste est plus courte qu'on l'imagine : Sylius 2 change surtout l'outillage technique, pas le périmètre fonctionnel de la boutique. Dans plusieurs cas, c'est même l'inverse, car le cœur a retiré des fonctions qu'un plugin doit désormais apporter.

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. La revue des plugins est toujours l'un des premiers sujets que j'ouvre. Cet article ne refait pas le guide de compatibilité des plugins, déjà détaillé dans l'article pour vérifier et remplacer vos plugins : il répond à une seule question, celle du natif.

Qu'est-ce que Sylius 2 apporte vraiment en natif ?

Le guide officiel UPGRADE-2.0 décrit avant tout un changement de socle : Bootstrap 5 et Symfony UX à la place de Semantic UI et jQuery, les Twig Hooks à la place des template events, Symfony Workflow par défaut à la place de winzou, les Payment Requests à côté de Payum, symfony/mailer à la place de SwiftMailer, symfony/clock à la place de sylius/calendar. Ce sont des outils pour les développeurs. Pour un dirigeant, ils ne remplacent aucun plugin métier du jour au lendemain.

Ils changent pourtant la donne pour une catégorie de plugins : ceux qui n'existaient que pour contourner une limite technique de Sylius 1.x. Un petit plugin qui servait à injecter un bloc dans une page, à ajouter un champ de recherche automatique dans l'administration ou à brancher un comportement sur un événement peut souvent être remplacé par quelques lignes de configuration dans votre propre code. Les Twig Hooks permettent d'ajouter, de retirer ou de réordonner un bloc sans surcharger tout un gabarit, et l'administration s'appuie sur Symfony UX Autocomplete pour ses champs de recherche.

Les versions 2.x suivantes ajoutent aussi des fonctions ciblées. Le fichier UPGRADE-2.3 introduit par exemple un champ trackUsage sur les promotions et les coupons, qui permet de les utiliser sans incrémenter leur compteur d'utilisation, et de nouveaux événements de panier déclenchés après l'enregistrement en base, pratiques pour envoyer un panier à un outil marketing sans risque d'envoyer une donnée non enregistrée. Si un plugin maison faisait l'un de ces deux travaux, vérifiez s'il reste utile sur la 2.3.

Quels plugins sont déjà devenus natifs ?

Le cas le plus net est antérieur à Sylius 2. Le guide UPGRADE-1.13 indique qu'à partir de la 1.13, la fonctionnalité du plugin d'historique des prix, utilisé pour afficher le prix le plus bas des trente derniers jours exigé par la directive Omnibus, est incluse dans le cœur. Si votre boutique a encore l'ancien plugin installé, c'est un remplacement à faire, avec le guide de passage dédié, avant même d'aborder la version 2.

Pour le reste, la tendance est moins à l'intégration dans le cœur qu'à la publication de plugins officiels. Sur Packagist, le 4 novembre 2026, sylius/wishlist-plugin est publié en v1.4.0 pour Sylius ^2.0.7 et sylius/product-bundle-plugin en v1.1.0 pour Sylius ^2.1. Un plugin officiel n'est pas du natif, mais il est maintenu par l'éditeur de Sylius au rythme de ses versions. Remplacer un plugin tiers abandonné par son équivalent officiel est souvent une excellente affaire.

Dans quels cas le natif est-il un leurre ?

Le premier piège est de croire que Sylius 2 fait plus que Sylius 1.x sur tous les plans. Le guide est explicite : les passerelles Stripe et PayPal Express sont retirées du cœur, et seule la méthode de paiement hors ligne reste fournie par défaut. Une boutique qui utilisait ces passerelles natives en 1.x doit au contraire ajouter un plugin, par exemple le plugin PayPal officiel, publié pour Sylius 2.

Le deuxième piège est la fonctionnalité native qui fait presque la même chose. Un plugin de promotion avancée, un CMS, un module B2B ou une intégration ERP répondent à des règles métier précises. La fonction native qui s'en rapproche peut laisser de côté une règle que votre équipe commerciale utilise tous les jours sans même la nommer. Remplacer sans faire la liste exacte de ce que le plugin fait, c'est découvrir l'écart en production.

Le troisième piège concerne les données. Un plugin stocke ses informations dans ses propres tables. Le remplacer par une fonction native ou par un autre plugin implique de reprendre ces données, de vérifier leur format et de prévoir le cas des commandes passées sous l'ancien système. C'est un vrai poste du chantier, à chiffrer.

Comment trier vos plugins avant la migration ?

Pour chaque plugin, je pose les mêmes questions, dans cet ordre, et je m'arrête à la première réponse positive.

La fonctionnalité sert-elle encore ? Les statistiques d'usage et l'avis de l'équipe qui utilise l'administration tranchent souvent. Un plugin inutilisé se supprime, c'est le remplacement le moins cher.

Le cœur de la version cible couvre-t-il exactement le besoin ? Si oui, on retire le plugin et on configure le natif, en reprenant les données si nécessaire.

Existe-t-il un plugin officiel ou un plugin tiers publié en version stable pour Sylius 2 ? Si oui, on compare son périmètre avec l'existant avant de choisir.

Reste-t-il seulement l'adaptation ? Alors on porte le plugin, en interne ou avec un prestataire, selon les critères que je décris dans l'article sur l'adaptation d'un plugin par votre équipe.

Pour la partie technique de ce tri, j'utilise Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store. Il croise chaque plugin du composer.json avec le Sylius Store et Packagist pour savoir s'il existe une version compatible, et signale les passerelles de paiement retirées du cœur. Le jugement fonctionnel, lui, se fait avec vous. C'est précisément ce que contient le diagnostic de migration Sylius 2 que je propose.

Ce que je vous propose

Une migration est le meilleur moment pour alléger une boutique : chaque plugin conservé devra être maintenu sur toutes les versions 2.x suivantes. Mais un remplacement mal préparé coûte plus cher qu'une adaptation. Avec la fin du support de sécurité de Sylius 1.14 le 31 décembre 2026, ce tri mérite d'être fait maintenant, pendant qu'il reste du temps pour reprendre les données proprement.

Je lance Sylius Upgrade Analyzer sur votre projet, je passe chaque plugin au crible de ces questions et je vous remets un diagnostic offert : ce qu'on garde, ce qu'on remplace, ce qu'on supprime, avec une estimation en jours.