Peut-on adapter soi-même un plugin Sylius 1.x à Sylius 2 ?
Oui, vous pouvez adapter vous-même un plugin Sylius 1.x à Sylius 2, à trois conditions : sa licence vous autorise à modifier le code, vous disposez d'un développeur à l'aise avec Symfony et Sylius, et vous acceptez de maintenir ce code ensuite. Techniquement, rien ne réserve ce travail à l'éditeur du plugin. La vraie question est économique : est-ce que l'adaptation coûte moins cher qu'un remplacement, et est-ce que vous voulez en porter la maintenance sur les versions 2.x suivantes ?
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. Dans cet article, je réponds à la question de la décision : faire soi-même ou non. La méthode technique de portage d'un plugin écrit pour votre boutique fait l'objet d'un article à part, sur la migration d'un plugin sur mesure, et la vérification de compatibilité des plugins tiers est traitée dans le guide pour vérifier et remplacer vos plugins.
Qui a le droit d'adapter un plugin Sylius 1.x ?
Avant la technique, la licence. Un plugin publié sur Packagist déclare sa licence dans son composer.json et dans un fichier LICENSE. La plupart des plugins open source de l'écosystème Sylius sont sous licence permissive, comme MIT : vous pouvez modifier le code, le garder privé ou le republier, tant que vous conservez la mention de copyright. C'est le cas du squelette officiel Sylius PluginSkeleton, publié sous licence MIT.
Un plugin commercial, acheté auprès d'un éditeur, obéit à son contrat. Certains interdisent la modification, d'autres la tolèrent mais retirent le support. Lisez ce contrat avant de mobiliser un développeur, et demandez à l'éditeur s'il prépare une version Sylius 2 : si elle sort dans votre calendrier, l'adaptation maison devient inutile.
Quelles compétences faut-il pour porter un plugin vers Sylius 2 ?
Un plugin Sylius est un bundle Symfony. Le porter demande donc d'abord de bien connaître Symfony : injection de dépendances, configuration des services, formulaires, événements, Twig. Sylius 2 a rendu les services privés par défaut, ce qui casse tout plugin qui allait chercher un service Sylius directement dans le conteneur. Votre développeur doit savoir remplacer ces appels par de l'injection propre.
Il faut ensuite connaître ce qui a changé côté Sylius. Le guide officiel UPGRADE-2.0 liste les ruptures qui touchent le plus les plugins : les template events et Sonata Blocks remplacés par les Twig Hooks, Semantic UI et jQuery remplacés par Bootstrap 5 et Symfony UX, winzou remplacé par défaut par Symfony Workflow, SwiftMailer remplacé par symfony/mailer, API Platform passé à une version majeure supérieure, et une longue liste de classes, de routes et d'identifiants de services supprimés ou renommés.
Enfin, il faut savoir tester. Un plugin qui s'installe sans erreur peut très bien casser à l'exécution : un bloc d'administration qui ne s'affiche plus parce que son point d'accroche n'existe plus, une règle métier qui ne se déclenche plus sur une transition de commande. Si votre équipe n'a jamais écrit de test fonctionnel sur Sylius, prévoyez du temps pour la recette.
Adapter soi-même ou faire appel à un prestataire : comment décider ?
Je pose quatre questions à chaque dirigeant qui envisage de faire le travail en interne.
Le plugin touche-t-il à l'argent ?
Un plugin qui ajoute un onglet dans l'administration ou un export de fichier est un bon candidat pour un portage interne. Un plugin qui intervient sur le panier, le calcul des promotions, le paiement ou les états de commande l'est beaucoup moins. Une erreur sur ces zones ne se voit pas toujours en recette et se paie directement en commandes perdues.
Le développeur a-t-il du temps réel ?
Un développeur interne qui gère déjà la production, le support et les demandes du marketing n'avance pas au rythme prévu. Estimez honnêtement les heures disponibles par semaine, pas celles que vous espérez.
Qui maintiendra le code ensuite ?
Adapter un plugin, c'est en devenir le mainteneur. Chaque version 2.x de Sylius peut demander des ajustements, et chaque version mineure publie son propre fichier UPGRADE à appliquer. Si personne en interne ne peut suivre ces mises à jour, l'adaptation crée une dépendance nouvelle au lieu d'en supprimer une. J'aborde ce point dans l'article sur la manière d'éviter la dépendance à un prestataire.
Existe-t-il une alternative déjà portée ?
Avant de réécrire, regardez si un autre plugin publié pour Sylius 2 couvre le même besoin, ou si la fonctionnalité sert encore. Sur les boutiques que j'ai migrées, la liste des plugins contient presque toujours un ou deux modules que plus personne n'utilise. Les supprimer est le portage le moins cher qui soit.
| Situation | Faire soi-même | Confier ou remplacer |
|---|---|---|
| Plugin d'administration simple, licence MIT | Bon candidat | Seulement si l'équipe manque de temps |
| Plugin de paiement ou de promotion | Risqué sans expérience Sylius | Recommandé |
| Plugin commercial au contrat restrictif | Impossible sans accord de l'éditeur | Remplacement à étudier |
| Plugin que l'éditeur portera bientôt | Inutile | Attendre la version officielle, si le calendrier le permet |
Comment savoir combien de travail représente le portage ?
Lire le code du plugin à la main donne une impression, pas un chiffre. J'utilise Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store. Lancé sur le projet qui embarque le plugin, il repère les surcharges de gabarits, les appels aux template events, les classes et routes supprimées, les services lus directement dans le conteneur, la configuration winzou et SwiftMailer, et attribue une estimation à chaque problème. Le code source est sur GitHub, et l'outil tourne en local : votre code ne sort pas de votre machine.
Ce rapport ne remplace pas le jugement, mais il change la discussion. Au lieu de « on devrait pouvoir le faire », vous savez quels fichiers bougent et quelle part du travail relève de corrections automatiques. C'est aussi la base pour comparer honnêtement adaptation interne, sous-traitance et remplacement. Si vous voulez cette lecture sur votre propre boutique, le diagnostic de migration Sylius 2 la fournit sans engagement.
Les pièges que je vois le plus souvent
Le premier piège est de modifier le plugin directement dans le dossier vendor. La modification disparaît à la prochaine installation des dépendances. Un fork déclaré comme dépôt dans le composer.json, ou un dossier dédié dans votre projet, est la seule façon propre de travailler.
Le deuxième est de porter le plugin sans le relier à une version précise de Sylius. Une contrainte trop large dans le composer.json laisse Composer installer une combinaison jamais testée. Fixez la version cible, par exemple 2.3, et testez sur celle-là.
Le troisième est de sous-estimer la partie visuelle. Un plugin qui affiche des écrans d'administration en Semantic UI doit voir ces écrans réécrits, et ce travail d'interface prend souvent plus de temps que la logique métier elle-même.
Ce que je vous propose
Adapter un plugin en interne est une option tout à fait valable, à condition de la choisir en connaissance de cause et pas par défaut. Le support de sécurité de Sylius 1.14 s'arrête le 31 décembre 2026 : c'est le bon moment pour trier vos plugins entre ceux à adapter, à remplacer et à supprimer.
Je lance Sylius Upgrade Analyzer sur votre projet, je regarde chaque plugin et je vous remets un diagnostic offert avec une estimation en jours, plugin par plugin. Si votre équipe peut porter une partie du travail, je vous le dis, et je vous indique laquelle.