Migrer vers Sylius 2 maintenant est-il plus rentable ?
Le plus souvent, oui : migrer maintenant coûte moins cher que migrer plus tard, parce que le chantier ne rétrécit pas avec le temps. Chaque évolution développée sur la 1.x devra être portée, l'écart avec les versions 2.x suivantes grandit, et à partir du 31 décembre 2026 la 1.14 ne reçoit plus de correctifs de sécurité. Attendre n'a de sens financier que si la boutique va être remplacée ou fermée à court terme, ou si la migration est déjà datée et que l'attente sert à la préparer.
Je suis développeur e-commerce indépendant à Metz, spécialiste de Sylius. La question « maintenant ou plus tard » est celle que les dirigeants me posent le plus souvent, et c'est une bonne question : une migration est une dépense réelle, et la reporter libère de la trésorerie. Encore faut-il savoir ce que coûte ce report.
Pourquoi le coût d'une migration augmente-t-il avec le temps ?
Pour quatre raisons, qui s'additionnent. La première est le code ajouté entre-temps. Chaque fonctionnalité développée sur la 1.14, chaque gabarit surchargé, chaque nouveau plugin rejoint le périmètre à migrer. Vous la payez une fois pour la créer, une seconde fois pour la porter.
La deuxième est la cible qui avance. Selon le cycle de publication officiel de Sylius, une version mineure sort en général tous les trois à six mois. Plus vous attendez, plus il y a de fichiers UPGRADE à appliquer après la 2.0, et plus la version cible exige un socle récent : la 2.3 demande PHP 8.3.
La troisième est le socle qui vieillit. D'après le calendrier officiel de PHP, PHP 8.1 ne reçoit plus de correctifs et PHP 8.2 n'en recevra plus après le 31 décembre 2026. Rester en 1.x n'empêche donc pas de toucher au serveur : vous y viendrez de toute façon. La quatrième est l'écosystème. Les éditeurs de plugins et de modules de paiement concentrent leurs efforts sur Sylius 2, et les développeurs qui connaissent les subtilités de la 1.x se tournent vers la version 2. Le jour où vous lancerez le chantier, les ressources pour la 1.x seront plus rares.
Que coûte de rester sur Sylius 1.14 après le 31 décembre 2026 ?
La boutique continuera de fonctionner. Mais chaque faille publiée sur les versions maintenues devra être évaluée sur votre code, puis corrigée à la main si elle vous concerne, sans correctif officiel. Il faut ajouter le coût des mesures de protection : dernier correctif 1.14 appliqué, accès à l'administration restreint, sauvegardes testées, surveillance des annonces de sécurité. Ces mesures réduisent le risque, elles ne le suppriment pas.
Le coût le plus lourd est celui qui ne se voit pas : l'incident. Une boutique compromise, c'est une fermeture le temps de comprendre, des clients à prévenir, des obligations de déclaration, une réputation à rétablir. Multipliez votre chiffre d'affaires quotidien par quelques jours d'arrêt et comparez au coût du chantier : c'est souvent ce calcul qui décide.
| Scénario | Ce que vous payez | Ce que vous risquez |
|---|---|---|
| Migrer maintenant | Le chantier, une fois, sur le périmètre actuel | Une bascule à planifier hors période forte |
| Migrer dans quelques mois, sous surveillance | Le chantier, plus les mesures de protection en attendant | Une faille pendant la période sans correctif |
| Attendre sans date | Rien tout de suite, puis un chantier plus gros | Un incident, et une migration faite dans l'urgence |
| Refondre ou changer de plateforme | Un projet neuf, la reprise des données et des URL | Les habitudes de travail des équipes à reconstruire |
Dans quels cas attendre se défend-il ?
Attendre est raisonnable dans trois situations. Si la boutique va être fermée ou remplacée dans les mois qui viennent, migrer n'a pas de sens. Si la migration est décidée, chiffrée et datée, quelques mois sous surveillance renforcée sont un risque assumé, pas un oubli. Enfin, si vous êtes en pleine période forte, on ne bascule pas une boutique au milieu des fêtes : on prépare le chantier sur une branche séparée, et on met en production après le pic, au moment où vous vendez le moins.
Attendre ne veut d'ailleurs pas dire ne rien faire. Supprimer les dépréciations de la 1.14, monter la version de PHP, remplacer un plugin abandonné sont des travaux utiles en soi, livrables en production avant la migration. Ils réduisent le chantier final et étalent la dépense. La question du report est traitée en détail dans l'article peut-on reporter la migration sans risque.
Si vous voulez savoir combien de jours représente le chantier aujourd'hui, avant qu'il ne grossisse, je vous remets un diagnostic de migration offert, fondé sur votre code.
Comment faire le calcul pour votre boutique ?
Le calcul tient sur une page. D'un côté, le coût de la migration maintenant, en jours, issu d'un inventaire du code ; la méthode est dans l'article sur le budget d'une migration Sylius 2. De l'autre, le coût de la migration plus tard : les mêmes jours, plus le portage de tout ce qui sera développé d'ici là, plus les mesures de protection pendant l'attente. Ajoutez enfin une ligne pour le risque d'incident, exprimée en jours de chiffre d'affaires perdus, et une ligne pour les projets que vous ne pouvez pas lancer tant que la boutique reste sur un socle en fin de vie.
Ce calcul ne demande pas de chiffre inventé, seulement les vôtres. Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store et sur GitHub, fournit la première ligne : il mesure le code à migrer et l'estime en heures. Le reste vient de vos comptes.
Ce que je vous propose
Mesurez d'abord ce que votre boutique vous coûte par an, avec le calculateur de l'audit de boutique. Demandez ensuite le diagnostic de migration offert : je lance l'analyseur sur votre projet, je complète ce qu'il ne voit pas, et je vous rappelle sous 24 heures ouvrées avec une estimation en jours. Vous saurez alors ce que coûte le fait de migrer maintenant, ce que coûte le fait d'attendre, et vous pourrez choisir avant le 31 décembre 2026 plutôt que de subir l'échéance.