Le design de ma boutique va-t-il changer avec Sylius 2 ?

Pas forcément. Le code du thème est réécrit parce que Sylius 2 abandonne Semantic UI au profit de Bootstrap 5, mais l'apparence peut rester la même. C'est une décision que vous prenez, pas une conséquence imposée par la version.

Faut-il prévenir mes clients avant la migration ?

Un message n'est utile que si la boutique doit fermer quelques minutes pendant la bascule, ou si vous profitez de la migration pour changer le design. Si l'apparence et les parcours restent identiques, la plupart des clients ne remarqueront rien.

Mes clients devront-ils recréer leur compte ?

Non. Les comptes sont dans la base de données, qui est conservée et migrée. Le point sensible est la vérification des mots de passe, que je teste sur une copie de vrais comptes avant la bascule.

Peut-on profiter de la migration pour refaire le design ?

C'est possible, puisque le thème est de toute façon repris. Je conseille pourtant de séparer les deux quand le calendrier est serré : migrer à l'identique, puis faire évoluer le design ensuite, pour savoir d'où vient un éventuel problème.

Sylius 2 : mes clients verront-ils une différence ?

Si la migration est bien menée, vos clients ne doivent voir presque aucune différence : mêmes adresses de pages, même catalogue, mêmes comptes, même parcours d'achat. Ce qui change en profondeur, c'est le code qui fabrique les pages, pas ce que l'acheteur voit. Les seules différences visibles sont celles que vous décidez d'introduire, ou celles qui trahissent une recette insuffisante.

Je suis développeur Sylius indépendant et j'ai mené des montées de version Sylius en production. La question des clients revient à chaque premier rendez-vous, souvent formulée par le dirigeant avant même la question du coût. Elle est légitime : un client qui ne retrouve plus ses repères achète moins. Voici ce qui change réellement, ce qui ne doit pas bouger, et comment je m'assure que rien ne bouge sans votre accord.

Qu'est-ce qui change vraiment sur le site avec Sylius 2 ?

Sylius 2 remplace le socle technique de l'interface. Le guide officiel UPGRADE-2.0 décrit l'abandon de Semantic UI et de jQuery au profit de Bootstrap 5, de Symfony UX et de Stimulus, ainsi que la fin des surcharges de gabarits classiques remplacées par les Twig Hooks. Plusieurs routes d'ajout au panier en Ajax sont aussi supprimées, puisque le panier repose désormais sur des composants Twig.

Pour un dirigeant, la traduction est simple : le thème de votre boutique doit être réécrit. Réécrit ne veut pas dire redessiné. On peut reproduire à l'identique les couleurs, la typographie, la disposition des fiches produits et le pied de page, avec un code neuf. C'est exactement ce que je propose par défaut, parce que c'est la manière la plus sûre de migrer : le client ne perçoit rien, et toute anomalie se repère facilement en comparant l'ancienne et la nouvelle version côte à côte.

Ce que vos clients ne doivent jamais remarquer

Certaines choses ne doivent pas changer du tout, et je les traite comme des critères de réussite du chantier plutôt que comme des détails. Les adresses des pages d'abord : une fiche produit qui change d'URL perd son historique dans Google et casse les liens partagés. Je traite ce sujet en détail dans l'article sur le référencement pendant une migration Sylius 2.

Viennent ensuite les comptes clients et l'historique des commandes, qui vivent dans la base de données. La base est conservée et migrée, donc un client retrouve ses commandes passées et ses adresses. Le point de vigilance concerne la vérification des mots de passe, que j'explique dans l'article sur la conservation des comptes et des historiques.

Enfin, les habitudes d'achat : l'emplacement du bouton d'ajout au panier, les filtres de catégorie, le mini panier, la recherche. Une boutique qui fonctionne bien a souvent été ajustée pendant des années sur ces points. Les perdre par inadvertance pendant une réécriture du thème est le risque le plus réel pour vos ventes.

Les différences qui peuvent apparaître, et comment les éviter

Sur les boutiques que j'ai migrées, les écarts visibles viennent rarement de Sylius lui-même. Ils viennent du code personnalisé qui n'a pas été repéré. Un petit script jQuery qui affichait un délai de livraison sous le prix, une surcharge de gabarit qui ajoutait un badge « nouveauté », un plugin qui insérait un bloc d'avis clients : avec Sylius 2, tout ce qui s'appuyait sur Semantic UI, jQuery ou les anciens événements de gabarits doit être repris, sinon il disparaît sans bruit.

C'est pour cela que je commence toujours par un inventaire. Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store, compte les gabarits surchargés, les classes Semantic UI, les appels jQuery et les plugins concernés. Chaque élément de la liste correspond à quelque chose que vos clients voient peut-être aujourd'hui, et qui doit être reproduit. Si vous voulez savoir combien de points de ce type contient votre boutique, le diagnostic de migration offert vous donne cette liste, avec une estimation en jours.

Il existe aussi des différences fonctionnelles plus subtiles. Le panier de Sylius 2 se met à jour par des composants interactifs plutôt que par des appels Ajax écrits à la main : le comportement attendu reste le même, mais il faut vérifier les cas limites, comme un code promo appliqué puis retiré, ou une quantité modifiée sur mobile. Le détail du parcours d'achat est traité dans l'article sur le tunnel de commande sous Sylius 2.

Comment vérifier qu'aucun client ne verra la différence ?

Ma méthode tient en trois contrôles. Premier contrôle, la comparaison visuelle : je fais tourner l'ancienne boutique et la nouvelle sur les mêmes données, et je compare les pages clés (accueil, catégorie, fiche produit, panier, compte, chaque étape du paiement) sur ordinateur et sur mobile. Toute différence est soit corrigée, soit validée par vous.

Deuxième contrôle, les parcours réels : une commande complète avec un compte existant, une commande en invité, un code promo, un remboursement côté administration. Ce sont les gestes qui rapportent de l'argent, ils doivent fonctionner à l'identique.

Troisième contrôle, les e-mails. Sylius 2 remplace SwiftMailer par symfony/mailer, comme le précise le guide officiel. La confirmation de commande, l'avis d'expédition et la réinitialisation de mot de passe sont des points de contact directs avec vos clients : je vérifie leur contenu et leur mise en forme avant la bascule.

Faut-il en profiter pour changer le design ?

C'est une tentation compréhensible : puisque le thème est réécrit, pourquoi ne pas le moderniser au passage ? C'est faisable, et parfois judicieux si le design date. Mais cela change la nature du projet. Un client qui voit une nouvelle boutique peut être dérouté, et si les ventes baissent après la mise en ligne, vous ne saurez pas si la cause est technique ou visuelle.

Quand l'échéance du 31 décembre 2026, date de fin des correctifs de sécurité de Sylius 1.14, laisse peu de marge, je conseille de migrer à l'identique d'abord, puis de faire évoluer le design dans un second temps sur une base saine. Quand le calendrier le permet, les deux peuvent avancer ensemble, avec une recette plus longue.

Ce que je vous propose

Si vous voulez savoir précisément ce que vos clients risquent de voir changer, je lance Sylius Upgrade Analyzer sur votre projet, je repère ce qui touche au front boutique et je vous remets un diagnostic offert, commenté, avec une estimation en jours. Je vous rappelle sous 24 heures ouvrées pour en parler. Vous saurez ce qui sera reproduit à l'identique, ce qui demande une décision de votre part, et combien de temps il faut prévoir avant le 31 décembre 2026.