Migration Sylius 2 : peut-on la reporter sans risque ?

Vous pouvez reporter la migration Sylius 2 de quelques mois, mais pas sans risque. Après le 31 décembre 2026, Sylius 1.14 ne reçoit plus de correctifs de sécurité : la boutique continue de vendre, mais toute faille découverte ensuite reste ouverte. Un report n'est raisonnable que si la migration est déjà décidée, chiffrée et datée, et si vous renforcez la protection de la boutique en attendant. Reporter sans date, c'est accepter un risque qui grandit chaque mois.

Je comprends l'envie de repousser. La boutique fonctionne, les ventes tournent, et une migration ressemble à une dépense sans bénéfice visible. Mais la question n'est pas de savoir si la boutique marchera le 2 janvier : elle marchera. La question est de savoir qui portera le risque, et combien de temps. Voici ce qui change réellement, ce que coûte un report et comment le rendre acceptable s'il est inévitable.

Que se passe-t-il après le 31 décembre 2026 ?

Le cycle de publication officiel de Sylius fixe la fin des correctifs de sécurité de la 1.14 au 31 décembre 2026. La maintenance active, celle qui corrige les bogues, s'est déjà arrêtée fin 2025. À partir de 2027, plus aucune version 1.x ne sera maintenue.

Concrètement, rien ne casse ce jour-là. Mais dès qu'une faille sera publiée sur Sylius 2, les équipes de développement corrigeront la version 2, pas la 1.14. Or une faille publiée est aussi une notice pour les attaquants : elle dit où chercher. Votre boutique deviendrait alors une cible connue, avec une porte documentée et aucun correctif officiel.

Le même calendrier touche le serveur. Sylius 2 demande PHP 8.2 au minimum, et la page officielle des versions de PHP indique que PHP 8.2 lui-même ne recevra plus de correctifs de sécurité après le 31 décembre 2026. PHP 8.1, encore courant sur les boutiques 1.x, n'est déjà plus maintenu. Reporter la migration, c'est souvent aussi garder un serveur qui vieillit.

Quels sont les vrais risques d'un report ?

Le risque de sécurité

Une boutique traite des comptes clients, des adresses et des paiements. Une faille exploitée peut se traduire par une fuite de données personnelles, avec les obligations de notification que cela implique, ou par une boutique compromise qu'il faut fermer en urgence. Ce n'est pas certain, mais c'est un risque que vous ne pourrez plus réduire par une simple mise à jour.

Le risque technique qui s'accumule

Plus le temps passe, plus l'écart grandit. Les éditeurs de plugins publient leurs nouveautés pour Sylius 2, les prestataires de paiement font évoluer leurs intégrations, les bibliothèques arrêtent de supporter les anciennes versions de PHP. Un report ne fige pas le coût de la migration, il tend à l'alourdir. J'en parle plus en détail dans l'article sur l'intérêt de migrer maintenant plutôt que plus tard.

Le risque de calendrier

Beaucoup de boutiques 1.x arrivent à la même échéance, et les développeurs Sylius disponibles ne sont pas illimités. Une migration décidée dans l'urgence se fait dans de mauvaises conditions, souvent en sacrifiant la recette. C'est la source des erreurs que je décris dans les dix erreurs de migration les plus fréquentes.

Dans quels cas un report est-il acceptable ?

Un report devient une décision raisonnée quand trois conditions sont réunies. La migration est chiffrée, à partir d'une analyse du code et pas d'une impression. Elle a une date de démarrage et une date de bascule. Et la période d'attente est couverte par des mesures de protection concrètes. Sans ces trois éléments, ce n'est pas un report, c'est un abandon qui ne dit pas son nom.

Il y a aussi des raisons légitimes de décaler : une saison commerciale chargée, un changement d'ERP en cours, une décision stratégique à prendre sur l'avenir de la boutique. Dans ce cas, le plus utile est souvent de commencer par ce qui se fait sur la 1.14 sans risque : monter PHP, appliquer le dernier correctif, supprimer les dépréciations. Ce travail sert directement la migration et réduit déjà la surface exposée.

Pour savoir combien de temps la migration demandera réellement et choisir une date crédible, je lance Sylius Upgrade Analyzer sur votre projet et je vous remets un diagnostic de migration offert avec une estimation en jours.

Comment limiter le risque si vous restez sur Sylius 1.14 ?

La première mesure est d'être sur le dernier correctif de la 1.14, sur une version de PHP encore maintenue. Ensuite, je restreins l'accès à l'administration, par adresse IP ou par une authentification supplémentaire, pour que la partie la plus sensible ne soit pas exposée à tout internet. Je vérifie que les sauvegardes existent, qu'elles sont hors du serveur et surtout qu'elles se restaurent réellement. Enfin, quelqu'un doit surveiller les annonces de sécurité de Sylius, de Symfony et des plugins installés, et savoir quoi faire quand une faille vous concerne.

Ces mesures réduisent le risque, elles ne le suppriment pas. Elles ont aussi un coût, en temps de surveillance et d'intervention, qui s'ajoute chaque mois au coût de la migration restée à faire. Si la fin du support vous paraît encore abstraite, l'article sur la fin du support de Sylius 1.14 détaille ce qu'elle implique.

Ce que je vous propose

Reporter n'est pas une faute, reporter sans savoir l'est. Avant de décider, il vous faut un chiffre et une date. Je lance l'analyseur sur votre projet, je complète à la main ce que l'outil ne voit pas, et je vous remets un rapport commenté avec une estimation en jours et un calendrier compatible avec votre activité, que la bascule tombe avant ou après le 31 décembre 2026. Je vous rappelle sous 24 heures ouvrées, et le diagnostic est offert.