Sylius 2 : la gestion du catalogue sera-t-elle différente ?

Non, la logique de gestion du catalogue ne change pas avec Sylius 2 : vous gérez toujours des produits, des variantes, des options, des attributs, des taxons et des prix par canal, avec les mêmes règles. Ce qui change, ce sont les écrans de l'administration, redessinés avec Bootstrap 5 et Symfony UX, et tout ce qui alimente le catalogue de l'extérieur : plugins d'import, connecteur de PIM ou d'ERP, scripts maison. C'est là qu'il faut regarder.

Je suis Pierre-Arthur Demengel, développeur Sylius indépendant, et la personne qui gère le catalogue est souvent celle qui redoute le plus une migration : c'est elle qui passe ses journées dans les fiches produits. Voici ce qu'elle retrouvera, ce qu'elle devra réapprendre, et ce que l'équipe technique doit vérifier.

Qu'est-ce qui reste identique dans la gestion du catalogue ?

Le modèle de catalogue de Sylius est le même en version 1 et en version 2. Un produit porte des traductions, des images, des attributs et un classement dans un ou plusieurs taxons. Ses déclinaisons sont des variantes, générées à partir d'options (taille, couleur) et dotées chacune d'un code, d'un stock et d'un prix par canal. Les promotions catalogue modifient toujours le prix affiché selon une portée et une action. Les associations entre produits (produits similaires, accessoires) existent toujours.

Pour votre équipe, cela veut dire qu'aucun concept nouveau n'est à apprendre et qu'aucune donnée n'est à ressaisir. La reprise des fiches elles-mêmes est traitée dans l'article vais-je retrouver mes fiches produits.

Qu'est-ce qui change dans les écrans du catalogue ?

L'apparence et l'ergonomie. Le guide officiel UPGRADE-2.0 indique que les classes Semantic UI ont été remplacées par Bootstrap, que jQuery a été retiré au profit de Symfony UX et Stimulus, et que les routes Ajax de l'administration ont été supprimées. Parmi elles figurent celles qui servaient à générer le slug d'un produit ou d'un taxon, à rechercher un produit ou une variante par nom, à charger l'arbre des taxons et à afficher les formulaires d'attributs. Ces fonctions existent toujours pour l'utilisateur, mais elles reposent désormais sur des composants qui se mettent à jour sans recharger la page.

Concrètement, la fiche produit, la liste des produits, l'arbre des catégories et les champs de recherche ont une nouvelle présentation. Le plus parlant est d'essayer : la démonstration officielle de Sylius 2 permet à votre responsable catalogue de créer un produit à déclinaisons et de le ranger dans une catégorie, avant même que le chantier commence.

Les personnalisations du catalogue suivent-elles ?

Pas automatiquement. Sur les boutiques que j'ai migrées, le catalogue est l'une des zones les plus personnalisées : un champ métier sur la fiche produit, un type d'attribut maison, une colonne ajoutée dans la liste, un filtre de grille, un onglet dédié aux informations logistiques. La donnée elle-même est conservée, mais l'écran qui la montre doit être reconstruit avec les Twig Hooks et les formulaires de base que Sylius 2 place dans l'AdminBundle. Les filtres de grille de type entities, notamment, deviennent des filtres entity.

Pour le dirigeant, la conséquence est directe : chaque personnalisation du catalogue a un coût de reprise, et c'est le bon moment pour se demander lesquelles servent encore. Les listes d'administration sont expliquées dans l'article sur le Sylius Grid Bundle.

Et les imports, le PIM et les flux de produits ?

C'est le point que l'on oublie le plus souvent, parce qu'il ne se voit pas dans le back-office. Le catalogue d'une boutique est rarement saisi à la main : il arrive par un fichier, un PIM, un ERP ou un flux fournisseur. Trois cas se présentent.

Si l'import passe par un plugin, il faut une version compatible Sylius 2, ou un remplacement. La méthode est décrite dans l'article sur les plugins compatibles Sylius 2. Si l'import passe par l'API, le guide UPGRADE-API-2.0 liste des adresses modifiées : les images de produits sont désormais rattachées au produit, les valeurs d'options à leur option, les traductions à leur ressource principale, et un champ position apparaît sur les attributs et les images. Un connecteur qui appelait les anciennes adresses doit être adapté. Enfin, si l'import est un script maison qui écrit en base ou appelle des services Sylius, il faut le relire, puisque les services sont privés par défaut en 2.0 et que de nombreux identifiants ont changé.

Je repère ces dépendances avec Sylius Upgrade Analyzer, l'outil que j'ai créé et publié sur le Sylius Store : il signale les plugins sans version 2, les ressources API Platform personnalisées et les services appelés par leur ancien identifiant. Le reste se vérifie en rejouant un import réel sur une copie de la boutique.

Comment préparer votre responsable catalogue ?

Je lui demande trois choses en début de chantier : la liste de ses gestes réguliers (création de produit, ajout de déclinaisons, mise à jour des prix, rangement en catégorie, import), un échantillon de produits représentatifs, y compris les plus compliqués, et la description de chaque flux qui alimente le catalogue. Ce sont ces produits et ces gestes qui servent de recette. Une fois les écrans stabilisés, elle les rejoue sur la copie de la boutique, et chaque écart est corrigé ou expliqué avant la bascule.

Si vous voulez savoir ce que la migration implique pour votre catalogue, c'est précisément ce que couvre le diagnostic de migration offert.

Ce que je vous propose

Je lance l'analyseur sur votre projet, je relève les personnalisations du catalogue, les plugins d'import et les flux API à adapter, et je vous remets un rapport commenté avec une estimation en jours. Je vous rappelle sous 24 heures ouvrées. Avec la fin du support de sécurité de Sylius 1.14 le 31 décembre 2026, c'est la base pour décider ce que vous gardez, ce que vous simplifiez et quand vous migrez.