Fin du Support Sylius 1.14 en Decembre 2026 : Pourquoi Migrer Maintenant
Le compte a rebours est lance. Depuis le 31 decembre 2025, Sylius 1.14 LTS n'est plus maintenu fonctionnellement — seuls les patchs de securite critiques sont encore publies, et ce jusqu'en decembre 2026. Apres cette date, votre boutique e-commerce sera livree a elle-meme face aux vulnerabilites. Si vous etes CTO, responsable technique ou gerant d'un e-commerce sous Sylius, cet article detaille les risques concrets et le plan d'action pour migrer vers Sylius 2.0 avant qu'il ne soit trop tard.
La timeline complete du support Sylius
Pour comprendre l'urgence, posons les dates officielles :
- 12 novembre 2024 : sortie de Sylius 2.0, premiere version majeure depuis des annees
- 31 decembre 2025 : fin du support de maintenance de Sylius 1.14 LTS. Plus aucun bug fix fonctionnel, plus de mise a jour de dependances, plus de nouvelles fonctionnalites backportees
- Decembre 2026 : fin du support securite de Sylius 1.14 LTS. Plus aucun patch, meme pour les failles critiques
A la date d'ecriture de cet article (mai 2026), il reste environ 7 mois de couverture securite. En soustrayant le temps necessaire a la migration, aux tests, et au deploiement en production, la fenetre d'action effective est encore plus courte.
Ce que "support securite uniquement" signifie vraiment
Beaucoup de decideurs sous-estiment ce que cette phase implique concretement :
- Aucun bug fonctionnel corrige : si vous decouvrez un comportement errone dans le checkout, le calcul de promotions, ou la gestion des stocks, vous devez le corriger vous-meme
- Aucune mise a jour de dependances : les dependances de Sylius 1.14 (Symfony 6.4, Doctrine, Twig, etc.) evoluent, mais Sylius ne met plus a jour ses
composer.jsonpour les suivre. Les incompatibilites s'accumulent - Seules les CVE critiques sont patchees : et encore, uniquement celles reportees a l'equipe Sylius. Les failles dans les dependances transitives (jQuery, Semantic UI, SwiftMailer) ne sont pas couvertes
- Aucune garantie de reactivite : le support securite est un engagement de bonne volonte, pas un SLA. Le delai entre la decouverte d'une faille et la publication du patch peut etre de plusieurs semaines
Les risques concrets de rester sur Sylius 1.x apres decembre 2026
1. Exposition aux vulnerabilites sans recours
Une boutique e-commerce traite des donnees sensibles : noms, adresses, emails, historiques d'achats, et souvent des tokens de paiement. Une faille non patchee dans le framework expose l'ensemble de ces donnees. Apres decembre 2026, si une CVE est publiee contre Sylius 1.x ou l'une de ses dependances legacy :
- Pas de patch officiel
- Vous devez analyser la faille, developper le correctif, le tester et le deployer vous-meme
- Cout typique d'un correctif de securite urgent par un prestataire : 3 000 a 15 000 euros selon la complexite, sans compter la perte de CA pendant l'interruption
2. Dependances obsoletes et dangereuses
Sylius 1.x embarque des composants en fin de vie qui ne recevront plus de patchs :
- SwiftMailer : abandonne depuis decembre 2021. Remplace par
symfony/mailerdans Sylius 2.0. Toute faille dans SwiftMailer ne sera jamais corrigee - jQuery + Semantic UI : le frontend admin et shop de Sylius 1.x repose sur jQuery et Semantic UI. Semantic UI n'est plus maintenu activement. jQuery, bien que stable, accumule des vecteurs d'attaque XSS quand il est couple a des plugins non maintenus
- winzou/state-machine-bundle : ce bundle, central dans Sylius 1.x pour la gestion des commandes et paiements, a une base d'utilisateurs restreinte et un mainteneur unique. Son avenir a long terme est incertain
- API Platform 2.7 : la branche 2.x est en fin de vie. Les correctifs de securite ne sont plus garantis
3. Conformite et assurances
Les audits de conformite (PCI-DSS pour le paiement, RGPD pour les donnees personnelles) exigent que les composants logiciels soient maintenus et a jour. Utiliser un framework en fin de vie est un signal d'alerte pour les auditeurs et peut :
- Bloquer votre certification PCI-DSS
- Augmenter vos primes d'assurance cyber-risque
- Engager votre responsabilite en cas de fuite de donnees (obligation de moyens RGPD)
4. Dette technique exponentielle
Plus vous attendez, plus la migration coute cher. Chaque mois qui passe, c'est :
- Du code custom ecrit contre des API internes de Sylius 1.x qui changent dans 2.0
- Des plugins tiers qui arretent de supporter la version 1.x et se concentrent sur 2.0
- Des developpeurs Sylius sur le marche qui se forment sur 2.0 et perdent l'expertise 1.x, rendant le recrutement plus difficile
- L'accumulation de workarounds pour compenser les bugs non corriges en 1.x
L'ampleur des changements dans Sylius 2.0
Sylius 2.0 n'est pas une mise a jour mineure. C'est une refonte en profondeur de plusieurs couches du framework :
Frontend : Bootstrap 5 + Symfony UX
Tout le frontend (admin et shop) est reconstruit avec Bootstrap 5 et les composants Symfony UX (Turbo, Stimulus). Semantic UI et jQuery sont completement supprimes. Chaque template Twig surcharge dans votre projet doit etre reecrit.
Templates : Twig Hooks
Le systeme de sylius_template_event et sonata_block_render_event est remplace par les Twig Hooks natifs. Chaque surcharge de template et chaque evenement de bloc doit etre converti en hook.
State machines : Symfony Workflow
winzou/state-machine-bundle est remplace par Symfony Workflow. Si vous avez des callbacks custom sur les transitions de commandes, paiements ou expeditions, ils doivent etre migres en EventSubscribers.
Emails : symfony/mailer
SwiftMailer est remplace par symfony/mailer. Toute la couche d'envoi d'emails doit etre adaptee.
API : API Platform 4
API Platform 2.7 est remplace par la version 4. Les DataProviders, DataPersisters, DataTransformers sont supprimes au profit de StateProviders et StateProcessors. Les groupes de serialisation sont prefixes avec sylius:.
Paiements : Payment Requests
Un nouveau systeme de Payment Requests est introduit aux cotes de Payum, offrant une alternative plus moderne pour l'integration des passerelles de paiement.
Auditer votre projet en 5 minutes
Avant de planifier quoi que ce soit, vous avez besoin d'un diagnostic precis. Le Sylius Upgrade Analyzer est un outil CLI open-source que j'ai developpe specifiquement pour cet audit. Il scanne votre codebase et produit un rapport detaille en quelques secondes :
# Installation
composer require --dev pierre-arthur/sylius-upgrade-analyzer
# Lancement de l'audit
vendor/bin/sylius-upgrade-analyzer sylius-upgrade:analyze
L'outil execute 49 analyseurs couvrant chaque aspect de la migration : templates, state machines, emails, API, plugins, configuration, classes supprimees, services renommes, routes retirees. Chaque probleme est classifie en BREAKING, WARNING ou SUGGESTION, avec une estimation en heures et un lien vers la documentation.
Pour les corrections automatiques, 41 auto-fixers sont integres :
# Voir les corrections sans les appliquer
vendor/bin/sylius-upgrade-analyzer sylius-upgrade:analyze --fix --dry-run
# Appliquer les corrections automatiques
vendor/bin/sylius-upgrade-analyzer sylius-upgrade:analyze --fix
Plan de migration en 4 phases
Voici un plan d'action realiste pour migrer avant decembre 2026 :
Phase 1 : Audit et estimation (1 semaine)
- Executer le Sylius Upgrade Analyzer sur votre projet
- Recenser les plugins tiers et verifier leur compatibilite 2.0
- Estimer le budget et le calendrier avec l'equipe technique
- Identifier les risques bloquants (plugin sans version 2.0, integration ERP critique, etc.)
Phase 2 : Preparation sur Sylius 1.14 (2-4 semaines)
- Mettre a jour vers Sylius 1.14 LTS si ce n'est pas deja fait
- Adopter les couches de compatibilite 2.0 disponibles en 1.14 : Symfony Workflow (cohabitation), Twig Hooks (cohabitation), nouvelles conventions de nommage
- Appliquer les auto-fixers du Sylius Upgrade Analyzer pour les corrections simples
- Ecrire des tests fonctionnels sur les parcours critiques (checkout, paiement, expedition) si ce n'est pas deja fait
Phase 3 : Migration vers Sylius 2.0 (3-8 semaines selon complexite)
- Basculer le
composer.jsonvers Sylius 2.0 - Migrer les templates Twig surcharges vers les Twig Hooks
- Finaliser la migration des state machines vers Symfony Workflow
- Adapter les integrations API (si frontend headless)
- Migrer les emails de SwiftMailer vers symfony/mailer
- Tester chaque parcours fonctionnel en environnement de staging
Phase 4 : Deploiement et stabilisation (1-2 semaines)
- Deployer en production sur un creneau a faible trafic
- Monitorer les logs, les erreurs, et les performances pendant 48h
- Corriger les regressions eventuelles
- Former l'equipe aux nouveaux outils (admin Bootstrap, Stimulus, etc.)
Le cout de l'inaction
Remettre la migration a plus tard semble economiser de l'argent a court terme. En realite, c'est l'inverse :
| Scenario | Cout estime |
|---|---|
| Migration planifiee maintenant (mai-sept 2026) | Budget maitrise, equipe disponible, delais confortables |
| Migration precipitee (oct-dec 2026) | Surcharge de 30 a 50% (urgence, moins de prestataires disponibles en fin d'annee) |
| Migration apres decembre 2026 | Cout de migration + cout des patchs de securite custom + risque juridique + perte de confiance client en cas de breach |
| Pas de migration | Faille de securite inevitable, cout de remediation imprevisible (5 000 a 100 000+ euros selon la gravite), impact reputation |
Agir maintenant
Si vous gerez un projet Sylius 1.x en production, voici ce que vous pouvez faire des aujourd'hui :
- Lancez un audit avec le Sylius Upgrade Analyzer — c'est gratuit, open-source, et ca prend 5 minutes
- Partagez le rapport avec votre direction ou votre client pour debloquer le budget
- Planifiez la migration en suivant les 4 phases decrites ci-dessus
- Contactez un specialiste si vous avez besoin d'accompagnement. En tant que developpeur specialise Sylius en Grand-Est et Wallonie, j'accompagne les equipes techniques dans cette transition — de l'audit initial au deploiement en production
Le support securite de Sylius 1.14 s'arrete dans 7 mois. Le meilleur moment pour commencer la migration etait hier. Le deuxieme meilleur moment, c'est maintenant.
