Qu'est-ce qui vous empêche de migrer vers Sylius 2 ?

Ce qui empêche le plus souvent de lancer une migration Sylius 2, ce n'est pas la technique : c'est l'incertitude. On ne sait pas combien elle coûtera, on dépend d'une agence qui ne se manifeste pas, on craint qu'un plugin ne suive pas ou que la boutique casse en pleine saison. Chacun de ces freins se lève de la même façon : en remplaçant l'inconnu par un inventaire précis de votre projet, puis par un plan découpé en étapes que vous maîtrisez.

J'échange avec des dirigeants dont la boutique tourne en Sylius 1.x. Presque tous savent qu'il faudra migrer avant ou peu après le 31 décembre 2026, date de fin des correctifs de sécurité de la 1.14 selon le cycle de publication officiel de Sylius. Peu ont lancé le chantier. Voici les freins que je rencontre le plus, et pour chacun ce qui permet concrètement d'avancer.

Le budget : comment décider sans connaître le coût ?

C'est le frein numéro un, et il est légitime. Une migration ne rapporte pas de nouvelle fonctionnalité visible, et personne ne veut signer un chèque en blanc. Le problème, c'est qu'aucun prestataire sérieux ne peut donner un coût sans lire votre code : deux boutiques sur la même version peuvent demander des chantiers sans commune mesure, selon les gabarits surchargés, les plugins et le code branché sur les commandes et les paiements.

La façon de lever ce frein est d'inverser l'ordre. On ne décide pas d'abord pour chiffrer ensuite : on chiffre d'abord, poste par poste, puis on décide. Le chantier se découpe aussi naturellement. La montée de PHP, le dernier correctif 1.14 et la suppression des dépréciations se livrent en production avant la migration, et chacune de ces étapes réduit déjà le risque. Je détaille les facteurs de coût dans l'article sur le budget d'une migration Sylius 2.

L'agence : que faire quand on dépend d'un prestataire ?

Deuxième frein, très fréquent : la boutique a été construite par une agence qui a changé d'équipe, qui ne répond plus vite, ou qui propose une migration sans détailler ce qu'elle contient. Le dirigeant n'a pas les moyens techniques de juger, et il attend.

La première chose à vérifier, c'est que vous avez bien accès à votre propre boutique : le dépôt du code source, la base de données, l'hébergement et les comptes des services tiers. Sans ces accès, vous ne pouvez rien faire, avec personne. Avec eux, vous retrouvez votre liberté de choix. Un diagnostic indépendant vous permet ensuite de comparer la proposition de votre agence à un inventaire objectif. J'aborde ce cas en détail dans l'article sur la migration quand on dépend d'une agence externe.

Les plugins : et si un module indispensable ne suit pas ?

Beaucoup de boutiques reposent sur des plugins tiers pour le paiement, la livraison, les avis clients ou les exports. La crainte est simple : si l'un d'eux n'existe pas pour Sylius 2, toute la migration est bloquée. En réalité, un plugin manquant n'est pas un mur, c'est un poste de travail. Soit un plugin équivalent existe déjà pour Sylius 2, soit on reprend son code dans le projet, soit on constate que la fonctionnalité ne sert plus et on la retire.

Ce qui compte, c'est de le savoir avant de commencer, pas au milieu du chantier. Sylius Upgrade Analyzer, l'outil que j'ai créé et publié sur le Sylius Store, croise chaque plugin de votre composer.json avec le Sylius Store et Packagist pour savoir s'il existe une version compatible. La démarche complète est décrite dans l'article sur la compatibilité des plugins avec Sylius 2.

La peur de casser : comment protéger les ventes ?

C'est le frein le plus émotionnel, et le plus compréhensible. La boutique fait vivre l'entreprise. L'idée d'une mise en ligne ratée, d'un tunnel de commande bloqué ou de paiements refusés suffit à repousser la décision d'un trimestre, puis d'un autre.

La réponse tient dans la méthode. Le chantier se fait sur une branche et un environnement séparés, pendant que la production continue de vendre en 1.14. Les parcours qui rapportent de l'argent, recherche, panier, paiement, e-mails, factures, sont testés à chaque étape. La bascule est répétée sur une copie de vos vraies données, puis faite à l'heure la plus calme, avec un retour arrière prêt. C'est ce que je décris dans l'article sur la bascule sans coupure.

Si l'un de ces freins vous concerne, le moyen le plus rapide de le lever est de le confronter à votre code réel. C'est exactement l'objet du diagnostic de migration offert : je lance l'analyseur, je relève les plugins, les surcharges et les points sensibles, et vous recevez une estimation en jours.

Le manque de temps : qui va piloter le chantier ?

Dernier frein, souvent tu : personne en interne n'a le temps de suivre une migration. Le responsable technique est absorbé par le quotidien, l'équipe commerciale prépare la prochaine saison. Une migration bien organisée ne demande pourtant pas une mobilisation permanente. Elle demande surtout des moments précis : valider le plan, participer à la recette des parcours métier, choisir la date de bascule. Le reste relève du prestataire. Je montre comment caler ces moments sans perturber l'activité dans l'article sur l'organisation de la migration sans perturber les équipes.

Ce que je vous propose

Tous ces freins ont un point commun : ils se nourrissent de ce qu'on ne sait pas encore. Le premier pas est donc d'obtenir une image exacte de votre boutique, sans engagement. Je lance Sylius Upgrade Analyzer sur votre projet, je vous remets un rapport commenté avec les plugins à remplacer, les postes classés par gravité et une estimation en jours, et je vous rappelle sous 24 heures ouvrées. Le diagnostic est offert. Avec lui en main, vous pourrez décider sereinement avant le 31 décembre 2026, avec moi ou avec un autre prestataire.