Sylius 2 : est-ce que mon back-office va changer ?
Oui, votre back-office va changer d'apparence avec Sylius 2, mais pas de logique. L'interface passe de Semantic UI et jQuery à Bootstrap 5 et Symfony UX : les écrans sont redessinés, plus aérés, plus réactifs. Vos produits, commandes, clients, promotions et canaux restent les mêmes, rangés aux mêmes endroits du menu. Ce qui demande du travail, ce sont les écrans que vous avez fait personnaliser : ils sont à reprendre.
Je suis Pierre-Arthur Demengel, développeur Sylius indépendant à Metz, et j'ai mené des montées de version Sylius en production. C'est souvent la première question que me pose un dirigeant, parce que le back-office est l'outil de travail quotidien de ses équipes. La réponse tient en deux parties : ce que Sylius change pour tout le monde, et ce que votre projet ajoute.
Qu'est-ce qui change dans l'administration Sylius 2 ?
Le guide officiel UPGRADE-2.0 est explicite : toutes les classes CSS de Semantic UI ont été remplacées par celles de Bootstrap, les composants JavaScript ont été réécrits, et jQuery a disparu au profit de Symfony UX et Stimulus, avec des composants « live » qui se mettent à jour sans recharger la page. Le paquet d'interface de l'administration déclare aussi le kit Tabler, construit sur Bootstrap 5. Concrètement, vos équipes verront une nouvelle mise en page, de nouveaux formulaires et de nouvelles listes.
Plusieurs mécanismes internes ont été remplacés. Les routes « partielles » qui affichaient des morceaux d'écran ont été supprimées et remplacées par des composants Twig. Les routes Ajax de l'administration, celles qui alimentaient les recherches de produits, de taxons ou de groupes de clients dans les formulaires, ont été retirées. La route des statistiques du tableau de bord aussi : le tableau de bord est reconstruit avec les nouveaux composants. Pour un utilisateur, ces changements sont invisibles, sauf si un développement maison s'appuyait dessus.
Qu'est-ce qui ne change pas pour vos équipes ?
Le modèle de données de Sylius reste le même. Un produit a toujours ses variantes, ses options, ses attributs, ses taxons et ses prix par canal. Une commande garde ses paiements, ses expéditions et ses états. Les promotions conservent leurs règles et leurs actions. La migration de la base se fait sur place, sans ressaisie : je l'explique dans l'article sur la conservation de la base de données.
Les grandes sections du menu sont toujours là : catalogue, ventes, clients, marketing, configuration. Une personne qui sait créer un produit, rembourser une commande ou programmer une promotion en Sylius 1 saura le faire en Sylius 2, après un temps d'adaptation aux nouveaux écrans. Le plus simple pour le vérifier est d'ouvrir la démonstration officielle de l'administration Sylius 2, dont les identifiants sont affichés sur la page de connexion, et de refaire les gestes du quotidien.
Que deviennent les écrans d'administration personnalisés ?
C'est là que se loge le travail. Sur les boutiques que j'ai migrées, le back-office personnalisé est rarement spectaculaire, mais il est partout : un champ ajouté sur la fiche produit, une colonne de plus dans la liste des commandes, un bouton d'export, un onglet métier, une entrée de menu vers un écran maison. Chacun de ces ajouts reposait sur un mécanisme de Sylius 1 qui a changé.
| Personnalisation Sylius 1 | Ce qu'elle devient en Sylius 2 |
|---|---|
| Gabarit Twig de l'administration surchargé | Découpé en Twig Hooks, réécrit avec les classes Bootstrap |
| Bloc ajouté par template event ou Sonata Block | Hookable déclaré dans la configuration des Twig Hooks |
| Entrée de menu ajoutée sur sylius.admin.main | Même logique, sur l'alias sylius_admin.main, seul valable en 2.0 |
| Script jQuery dans un formulaire | Contrôleur Stimulus ou composant live |
| Filtre de grille de type entities | Filtre entity, avec une option fields |
| Appel Ajax vers une route d'administration retirée | Autocomplétion Symfony UX ou composant Twig |
La conséquence pour vous est simple : le coût de cette partie dépend du nombre d'écrans touchés, pas de Sylius. J'en détaille la mécanique dans le guide pratique des Twig Hooks et dans l'article sur la personnalisation de l'administration Sylius.
Comment savoir ce qui va changer dans votre back-office ?
Je procède en deux temps. D'abord un inventaire technique : je lance Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store, qui repère les gabarits surchargés, les template events, les classes Semantic UI, les menus et les grilles à reprendre, avec une estimation en heures par problème. Ensuite un inventaire d'usage : je demande à chaque service quels écrans il ouvre tous les jours et ce qu'il y fait. Les deux listes ne se recoupent jamais parfaitement, et c'est l'écart qui est instructif. Un écran personnalisé que personne n'utilise plus peut être abandonné au lieu d'être réécrit.
Si vous voulez cette double liste pour votre boutique, je vous la remets dans le diagnostic de migration offert : rapport de l'outil, écrans à reprendre classés par importance, et estimation en jours.
Faut-il refaire le back-office à l'identique ?
Pas forcément. La migration est l'occasion de faire le tri. Certains développements maison de Sylius 1 compensaient un manque de la version de l'époque, que Sylius 2 couvre désormais avec ses composants standard. D'autres ajoutaient des boutons que l'équipe a cessé d'utiliser. Reproduire tout à l'identique coûte plus cher et vous prive des améliorations de la nouvelle interface.
Ma règle est la suivante : on garde ce qui sert un geste quotidien ou une obligation (préparation, facturation, service client), on simplifie ce qui peut l'être avec l'existant, et on supprime le reste après validation par les personnes concernées. La question de l'accompagnement des équipes se traite à part, dans l'article sur la formation des équipes au back-office Sylius 2.
Ce que je vous propose
Le support de sécurité de Sylius 1.14 s'arrête le 31 décembre 2026. Plus tôt vous savez ce que deviendra votre back-office, plus tôt vous pouvez préparer vos équipes et arbitrer ce qui mérite d'être refait. Je lance l'analyseur sur votre projet, je liste les écrans d'administration concernés, et je vous rappelle sous 24 heures ouvrées pour commenter le rapport. Le diagnostic est offert et il vous appartient, même si vous confiez ensuite la migration à quelqu'un d'autre.