Sylius 2 : mes équipes devront-elles être formées ?
Oui, vos équipes auront besoin d'une prise en main, mais pas d'une formation lourde. Le back-office Sylius 2 garde la même logique que Sylius 1 (catalogue, commandes, clients, promotions), dans une interface redessinée. Le vrai besoin n'est pas d'apprendre Sylius : c'est de vérifier, service par service, que chaque geste quotidien fonctionne et convient sur la nouvelle version, puis de laisser chacun pratiquer avant la bascule.
Je suis Pierre-Arthur Demengel, développeur Sylius indépendant, et sur les montées de version que j'ai menées, les difficultés des équipes ne venaient presque jamais de Sylius lui-même. Elles venaient d'un écran personnalisé déplacé, d'un bouton d'export qui n'était plus au même endroit, ou d'un raccourci que personne n'avait pensé à documenter. C'est donc là qu'il faut concentrer l'effort.
Faut-il vraiment former ses équipes au back-office Sylius 2 ?
Il faut distinguer deux choses. L'interface standard change d'habillage : Sylius 2 remplace Semantic UI par Bootstrap 5 et Symfony UX, comme le décrit le guide officiel UPGRADE-2.0. Les menus, les listes et les formulaires sont redessinés, mais un produit reste un produit et une commande reste une commande. Pour cette partie, quelques séances de pratique suffisent en général.
Les écrans propres à votre boutique, eux, sont réécrits pendant la migration : champs ajoutés, colonnes de liste, exports, onglets métier. Ils peuvent changer de place ou de forme. C'est sur eux que porte l'essentiel de l'accompagnement. Je décris ce qui change à l'écran dans l'article mon back-office va-t-il changer ; ici, je me concentre sur la façon de préparer les personnes.
Comment vérifier que les parcours du back-office conviennent aux équipes ?
Lister les gestes métier, service par service
Avant d'ouvrir le moindre écran, je demande à chaque service de décrire ses tâches régulières avec ses mots. La préparation dira « je filtre les commandes payées du jour, j'imprime les bons, je passe l'expédition en envoyée ». Le service client dira « je retrouve une commande par le nom du client, je fais un remboursement, je renvoie l'e-mail de confirmation ». Le catalogue dira « je crée un produit avec ses déclinaisons, je change un prix, je range un produit dans une catégorie ». Cette liste devient le plan de recette du back-office.
Faire tester par ceux qui travaillent avec
Chaque geste est ensuite rejoué par la personne qui le fait réellement, sur un environnement de recette alimenté par une copie des données de production. C'est indispensable : sur une base de démonstration vide, on ne voit ni les volumes, ni les filtres utiles, ni les cas tordus. Un développeur peut confirmer qu'un écran fonctionne. Seul l'utilisateur peut dire qu'il lui faut désormais trois clics au lieu d'un pour une tâche qu'il répète cent fois par jour.
Traiter les écarts avant la bascule
Les remarques se classent en trois familles : ce qui est cassé (à corriger), ce qui est moins pratique qu'avant (à arbitrer, parfois une colonne ou un filtre de grille suffit) et ce qui est simplement différent (à expliquer). Je relance la même recette après correction, jusqu'à ce que chaque référent valide ses gestes. La méthode générale de test est détaillée dans l'article sur comment tester une migration Sylius 1 vers 2.
Comment préparer les collaborateurs au changement ?
Le premier levier est d'annoncer tôt. Montrer l'interface Sylius 2 dès le début du chantier, par exemple sur la démonstration officielle de l'administration, désamorce l'inquiétude. Les équipes voient que leur outil reste reconnaissable et peuvent poser leurs questions bien avant la date.
Le deuxième levier est de s'appuyer sur des référents. Une personne par service, impliquée dans la recette, devient le relais naturel de ses collègues. Elle connaît les nouveaux écrans, elle a vu les corrections arriver, et elle répond plus vite qu'un prestataire extérieur aux questions du quotidien.
Le troisième levier est un support court et concret. Je préfère une fiche par geste métier, avec les captures de vos propres écrans prises sur la recette, à un manuel générique. Elle se rédige au fil des tests, à partir des questions réellement posées. Enfin, il faut prévoir la période qui suit la bascule : une présence renforcée les premiers jours, un canal simple pour remonter un blocage, et une revue des remarques à la fin de la première semaine. L'organisation du chantier côté équipes est traitée plus largement dans l'article sur organiser la migration sans perturber les équipes.
Quels pièges éviter ?
Le premier piège est de faire tester le back-office par le seul responsable technique. Il connaît le code, pas les habitudes de la préparatrice ou du conseiller client. Le second est de tester sur une base vide : les problèmes de lisibilité et de lenteur n'apparaissent qu'avec vos volumes. Le troisième est d'oublier les comptes administrateurs eux-mêmes. Sylius 2 retire les champs locked, expiresAt et credentialsExpireAt des utilisateurs et s'appuie sur le hacheur de mots de passe de Symfony : je vérifie que chaque compte administrateur se connecte sur la recette avant le jour J, pour que personne ne découvre le problème le matin de la bascule.
Dernier piège, plus discret : former trop tôt. Une séance faite trois mois avant la mise en production s'oublie. La bonne fenêtre est la recette finale, quand les écrans sont stabilisés, et les jours qui précèdent la bascule.
Ce que je vous propose
Pour préparer vos équipes, il faut d'abord savoir quels écrans vont changer. Je lance Sylius Upgrade Analyzer, l'outil que j'ai créé et publié sur le Sylius Store, sur votre projet, et je vous remets un diagnostic de migration offert : écrans d'administration personnalisés à reprendre, plugins concernés et estimation en jours. Avec l'échéance du 31 décembre 2026 pour la sécurité de Sylius 1.14, c'est ce qui vous permet de planifier la recette des équipes au bon moment. Je vous rappelle sous 24 heures ouvrées.