Quels risques de régression avec Sylius 2 ?
Oui, une migration de Sylius 1.x vers Sylius 2 comporte des risques de régression fonctionnelle, et ils se concentrent là où votre boutique s'écarte du standard : gabarits surchargés, règles branchées sur les états de commande et de paiement, plugins tiers, API et e-mails. Les régressions dangereuses ne sont pas celles qui font planter le site, mais celles qui passent inaperçues pendant des jours : une promotion qui ne s'applique plus, un e-mail de confirmation qui ne part pas, un export vers l'ERP vide. On les maîtrise par un inventaire du code avant le chantier et une recette des parcours qui rapportent de l'argent.
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 uniquement à la question du risque : où il se trouve, comment le mesurer, et ce qu'il veut dire pour vous en tant que dirigeant. La méthode de test détaillée fait l'objet d'un article séparé.
Qu'appelle-t-on une régression fonctionnelle dans une migration Sylius 2 ?
Une régression, c'est une fonctionnalité qui marchait en 1.14 et qui ne marche plus, ou plus de la même façon, en version 2. Elle ne vient pas d'un bug de Sylius en lui-même : elle vient du fait que votre code s'appuyait sur quelque chose qui a changé. Le guide officiel UPGRADE-2.0 le dit sans détour : même une application à peine personnalisée demande des ajustements manuels avant de pouvoir tourner à nouveau.
Il faut distinguer deux familles. Les régressions bruyantes provoquent une erreur visible : une page qui renvoie une erreur 500, un service introuvable au démarrage, un formulaire qui refuse de s'afficher. Elles sont gênantes mais faciles à repérer, souvent dès le premier lancement. Les régressions silencieuses, elles, laissent la boutique tourner normalement en apparence. Le client commande, paie, reçoit une page de remerciement, et c'est trois jours plus tard que le service client découvre que les confirmations ne partaient plus. Ce sont elles qui coûtent du chiffre d'affaires et de la confiance.
Où se cachent les risques de régression lors d'une migration Sylius ?
Chaque grande rupture de la version 2 crée une zone de risque, mais seulement si votre projet l'utilise. Voici la grille que j'applique pour situer une boutique.
| Zone | Ce qui change en Sylius 2 | Régression typique |
|---|---|---|
| Gabarits | Les template events disparaissent au profit des Twig Hooks | Un bloc personnalisé de la fiche produit ou du panier ne s'affiche plus, sans erreur |
| Commandes | Symfony Workflow devient l'adaptateur par défaut à la place de winzou | Un traitement déclenché au paiement ou à l'expédition ne s'exécute plus |
| Paiement | Les passerelles Stripe et PayPal Express du cœur sont retirées, les Payment Requests arrivent | Un moyen de paiement disparaît du tunnel ou une notification de paiement n'est plus traitée |
| Promotions | Certaines classes de règles sont supprimées ou déplacées | Une règle de promotion sur mesure ne s'évalue plus |
| E-mails | SwiftMailer remplacé par symfony/mailer, gestionnaires d'e-mails de commande retirés | Confirmation de commande ou d'expédition non envoyée |
| Routes et JavaScript | Des routes de la boutique sont supprimées, jQuery laisse la place à Symfony UX | L'ajout au panier en Ajax ou le résumé du panier ne répond plus |
| API | API Platform 2.7 laisse la place aux versions suivantes, pare-feux renommés | Une application mobile ou un ERP n'arrive plus à s'authentifier |
Ce tableau explique pourquoi deux boutiques sur la même version n'ont pas le même niveau de risque. Une boutique proche du standard traverse la plupart de ces lignes sans dommage. Une boutique qui a branché sa logistique sur les transitions winzou et ses remises B2B sur des règles maison les traverse toutes. L'inventaire de ces zones est justement ce que fait Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store : ses 49 analyseurs signalent les gabarits, classes, routes et plugins concernés avant que le chantier ne commence.
Quelles régressions coûtent le plus cher au chiffre d'affaires ?
Pour un dirigeant, toutes les régressions ne se valent pas. Un libellé mal traduit dans l'administration se corrige en quelques minutes. Les régressions qui touchent l'argent se classent dans cet ordre de gravité : le paiement qui échoue ou n'est pas enregistré, la commande enregistrée mais dans un mauvais état, la promotion mal calculée, et la communication avec vos outils (ERP, logistique, comptabilité).
La plus pernicieuse est la commande dans un mauvais état. Avec le passage à Symfony Workflow, une règle métier qui réagissait à un événement winzou peut cesser d'être appelée. La commande existe, le client a payé, mais l'ordre d'expédition n'est jamais parti vers l'entrepôt. Rien ne plante : il faut aller vérifier les états, un par un, sur des commandes de test. C'est pour cela que je traite à part la question de savoir comment garantir que commandes, paiements et promotions continuent de fonctionner.
Viennent ensuite les régressions de référencement, qui ne cassent pas les ventes du jour mais celles des mois suivants : une adresse de page qui change, une balise qui disparaît d'un gabarit réécrit. Elles relèvent d'une vérification spécifique, différente de la recette fonctionnelle.
Comment réduire le risque de régression avant d'écrire une ligne de code ?
Le risque se réduit surtout en amont. Je commence par trois actions. D'abord, l'inventaire automatique du code, qui transforme une inquiétude diffuse en liste de points précis classés par gravité. Ensuite, la liste écrite de ce que la boutique fait réellement : moyens de paiement actifs, promotions en cours, modes de livraison, e-mails envoyés, flux vers les outils externes. Cette liste paraît évidente, elle n'existe presque jamais par écrit, et c'est elle qui sert de référence pendant la recette. Enfin, la suppression des dépréciations sur la 1.14, livrée en production avant la migration : chaque correction faite à ce stade est testée dans des conditions réelles, sans attendre la grande bascule.
Si votre boutique n'a pas ou peu de tests automatisés, ce n'est pas un motif d'abandon, mais il faut le compenser. J'explique comment dans l'article sur la question de migrer sans couverture de tests complète.
Si vous voulez savoir où se situent ces zones de risque dans votre propre boutique, c'est exactement l'objet du diagnostic de migration offert : je lance l'analyseur sur votre projet, je le complète par une lecture humaine de vos règles métier et je vous remets un rapport commenté.
Ne pas migrer, est-ce moins risqué ?
C'est la tentation naturelle quand on découvre la liste des risques. Mais la 1.14 cesse de recevoir des correctifs de sécurité le 31 décembre 2026. Votre boutique ne s'arrêtera pas le lendemain, et c'est justement le piège : le risque change de nature. Au lieu d'un risque de régression, que l'on peut tester et maîtriser avant la mise en ligne, vous portez un risque de sécurité, que vous ne maîtrisez pas, puisqu'une faille découverte ensuite n'aura plus de correctif officiel.
Un risque de régression se traite par une méthode : inventaire, recette, répétition sur une copie des données réelles, retour arrière prêt. Un risque de sécurité non corrigé se traite au mieux par de la surveillance. Entre les deux, le premier est le plus gérable, à condition de lui donner le temps nécessaire et de ne pas compresser la recette pour tenir une date.
Ce que je vous propose
Avant de vous engager, sachez précisément où votre boutique risque de casser. Je lance Sylius Upgrade Analyzer sur votre code, j'ajoute ce que l'outil ne voit pas (vos règles métier, vos flux vers l'ERP, vos e-mails), et je vous remets un rapport commenté avec les zones à risque et une estimation en jours. Je vous rappelle sous 24 heures ouvrées après votre demande. Avec l'échéance du 31 décembre 2026, c'est le bon moment pour le faire.