Sylius 2 est-il assez stable pour la production ?
Oui, Sylius 2 est suffisamment stable pour la production. La 2.0 est sortie en novembre 2024, la branche a depuis connu plusieurs versions mineures et des correctifs publiés à un rythme régulier, et des boutiques tournent dessus. La vraie question n'est pas la stabilité du cœur, mais trois choix qui vous appartiennent : la version que vous visez (ni la 2.0 ni la 2.1), la maturité des plugins dont vous dépendez, et la qualité de la recette faite sur votre propre boutique.
Je suis développeur Sylius indépendant et je conseille la même chose à chaque dirigeant qui me pose cette question : on ne juge pas la stabilité d'une plateforme dans l'absolu, on la juge sur sa boutique, avec ses plugins et ses données. Voici les faits officiels, puis la méthode.
Que dit le calendrier officiel de Sylius ?
Le cycle de publication publié par Sylius donne une image claire de la maturité de la branche 2.x. Chaque version mineure a une période de maintenance, pendant laquelle tous les bugs peuvent être corrigés, puis une période où seules les failles de sécurité le sont.
| Version | Sortie | Fin des correctifs de sécurité | Pour une boutique en production |
|---|---|---|---|
| 2.0 | 12 novembre 2024 | 28 février 2026 | À ne pas viser |
| 2.1 | 4 juin 2025 | 30 septembre 2026 | À ne pas viser |
| 2.2 | 17 décembre 2025 | Mars 2027 | Cible possible si le serveur ne peut pas passer en PHP 8.3 |
| 2.3 | 28 septembre 2026 | Support actif en cours | Cible que je recommande |
Ce calendrier dit deux choses. D'abord, Sylius 2 n'est plus une nouveauté : il y a eu près de deux ans de vie de la branche, avec plusieurs versions mineures, avant même l'échéance de la 1.14. Ensuite, la stabilité dépend de la version choisie : une version dont le support de sécurité est terminé n'est pas une option sérieuse, même si elle a été stable à sa sortie. Sur la 2.0, une faille récente n'est d'ailleurs corrigée qu'à partir de la 2.1.17.
Stable ne veut pas dire sans correctifs
Une plateforme stable est une plateforme qui reçoit des correctifs, pas une plateforme qui n'en reçoit plus. La politique officielle prévoit des versions correctives toutes les trois à six semaines environ, selon le volume de corrections. La page des versions du dépôt Sylius montre d'ailleurs que les branches maintenues sont souvent publiées le même jour, ce qui permet à une boutique de suivre les correctifs sans changer de version mineure.
Certains de ces correctifs touchent directement le commerce. Les notes de la version 2.0.16, dans le guide UPGRADE-2.0, mentionnent par exemple la correction d'une situation de concurrence qui permettait à des commandes simultanées de dépasser la limite d'utilisation d'une promotion, et celle d'une redirection ouverte. C'est exactement le genre de correctif que vous voulez recevoir. Pour un dirigeant, la conséquence est simple : la stabilité en production, c'est une boutique sur une version maintenue, et un prestataire qui applique les correctifs régulièrement.
Où se situe le vrai risque de stabilité avec Sylius 2 ?
Sur les boutiques que j'ai migrées, les instabilités viennent rarement du cœur de Sylius. Elles viennent de trois endroits.
Les plugins tiers
Le cœur est maintenu par l'éditeur, les plugins par des auteurs très divers. Certains ont publié une version Sylius 2 solide, d'autres une version récente peu éprouvée, d'autres aucune. Un plugin de paiement, de livraison ou de synchronisation peu mûr est le premier facteur d'instabilité. Je les vérifie un par un, comme décrit dans l'article sur les plugins compatibles Sylius 2.
Le socle technique
Sylius 2.0 exige PHP 8.2 au minimum et abandonne Symfony 5.4, la 2.3 demande PHP 8.3. Un hébergement mal mis à niveau, une extension PHP manquante ou une configuration de cache non revue provoquent des erreurs que l'on attribue à tort à Sylius.
Le code sur mesure
Votre propre code, réécrit pour les Twig Hooks, Symfony Workflow ou les Payment Requests, est neuf. C'est lui qui doit faire ses preuves, et c'est lui que la recette doit éprouver en priorité. J'en détaille les zones dans l'article sur les risques de régression.
Si vous voulez savoir lequel de ces trois points pèse le plus chez vous, le diagnostic de migration offert y répond : je passe en revue vos plugins, votre socle et votre code sur mesure avant toute décision.
Comment vérifier que Sylius 2 est stable sur votre boutique ?
La seule preuve qui compte est celle obtenue sur votre projet. Je la construis en trois étapes. La version Sylius 2 tourne d'abord sur un environnement qui reproduit la production : même version de PHP, même base de données, même configuration de cache et de files de messages. Elle est ensuite alimentée par une copie des données réelles, pour que les volumes, les produits à nombreuses déclinaisons et les vieux comptes clients soient de la partie. Enfin, les parcours qui rapportent de l'argent sont joués et rejoués, puis la bascule elle-même est répétée.
Après la mise en ligne, je garde une surveillance renforcée sur les erreurs, les paiements en attente et les e-mails pendant les premiers jours, puis j'applique les correctifs publiés sur la branche choisie. C'est cette routine, plus que le numéro de version, qui fait une boutique stable.
Ce que je vous propose
Si vous hésitez à migrer parce que Sylius 2 vous semble trop récent, le calendrier officiel a déjà tranché : la 1.14 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026, alors que la branche 2.x est publiée et maintenue. Je lance Sylius Upgrade Analyzer, l'outil open source que j'ai publié sur le Sylius Store, sur votre projet, je vérifie la maturité de vos plugins et je vous conseille la version cible adaptée à votre hébergement. Vous recevez un rapport commenté avec une estimation en jours, et je vous rappelle sous 24 heures ouvrées.
