Combien va me coûter la migration Sylius 2 ?
Le coût d'une migration Sylius 1.x vers 2.x se calcule en jours de travail, et ce nombre dépend de votre code bien plus que de Sylius : gabarits surchargés, plugins tiers, logique de commande et de paiement, API, présence de tests. Je ne publie pas de prix moyen, parce qu'il serait faux pour la plupart des boutiques. Le budget se construit poste par poste à partir d'un inventaire du projet, converti en jours, multiplié par le tarif journalier de qui fait le travail, auquel s'ajoutent le temps de recette de vos équipes et parfois l'hébergement.
Je suis développeur e-commerce indépendant à Metz, spécialiste de Sylius, et j'ai mené des montées de version 1.x vers 2.x de boutiques en production. Cet article ne vous donnera pas de montant. Il vous donnera mieux : la liste des postes qui composent un budget de migration, ce qui fait grossir chacun, et la méthode pour obtenir un chiffre défendable devant un associé ou un directeur financier.
Pourquoi aucun prix sérieux ne peut être donné sans voir le code ?
Le guide officiel UPGRADE-2.0 prévient lui-même que même une application à peine personnalisée demandera des ajustements manuels. Ensuite, tout dépend de ce que votre projet utilise. Une boutique restée proche du standard traverse la plupart des ruptures sans effort. Une plateforme qui a surchargé des dizaines de gabarits, écrit ses propres transitions de commande et branché un ERP sur l'API les paie toutes. Les deux chantiers n'ont aucune commune mesure, alors qu'ils partent de la même version.
Un devis donné sans lire le code n'est donc qu'une supposition, avec une marge de sécurité pour couvrir ce que le prestataire ne sait pas. Vous payez cette marge, que le risque se réalise ou non.
Quels postes composent le budget d'une migration Sylius 2 ?
Voici la grille que j'utilise pour découper un budget. Chaque ligne se chiffre séparément, ce qui permet de voir où partent les jours et de décider ce que l'on peut retirer.
| Poste | Ce qu'il contient | Ce qui le fait grossir |
|---|---|---|
| Préparation sur la 1.14 | Dernier correctif 1.14, montée de PHP, suppression des dépréciations | Une version de départ antérieure à la 1.14 |
| Interface et gabarits | Thème en Bootstrap 5, gabarits découpés en Twig Hooks, administration | Beaucoup de gabarits surchargés et de jQuery maison |
| Commande et paiement | Passage de winzou à Symfony Workflow, passerelles de paiement | Règles métier branchées sur les états de commande, passerelle sur mesure |
| Plugins | Mise à jour, remplacement ou réécriture | Plugins abandonnés ou maison |
| API | Passage à API Platform 4, retests des clients connectés | Front headless, application mobile, ERP branché sur l'API |
| Données et comptes | Migrations de base, contrôle des comptes clients et des mots de passe | Données anciennes ou incohérentes |
| Recette | Vérification des parcours qui rapportent de l'argent | Aucun test automatisé |
| Bascule et suivi | Répétitions, mise en production, retour arrière prêt, surveillance | Gros volume de données, trafic continu |
Les deux lignes qui surprennent le plus les dirigeants sont les plugins et la recette. Un plugin abandonné peut peser plus lourd que tout le reste, et une boutique sans tests demande de tout revérifier à la main après chaque correction. Le détail de la durée est traité dans l'article sur l'estimation du chantier en jours.
Quel budget prévoir pour une migration Sylius 1.x vers 2.x ?
Le budget se construit en quatre couches. La première est le nombre de jours de développement, issu de l'inventaire. La deuxième est une réserve explicite pour les zones d'incertitude : code que personne ne connaît plus, plugin dont l'éditeur promet une version 2 sans date, règle métier implicite. Je liste ces zones une par une au lieu d'ajouter une marge globale, pour que vous sachiez ce que vous provisionnez. La troisième est le temps de vos équipes, qui valident les parcours en recette et répondent aux questions métier. La quatrième regroupe les frais annexes : environnement de recette, éventuel déménagement d'hébergement si votre serveur ne propose pas PHP 8.3, licences de plugins payants.
Pour l'ordre de grandeur, le seul repère honnête que je donne est en durée : de quelques semaines pour une boutique proche du standard à plusieurs mois pour un projet très personnalisé. Multipliez ensuite les jours par le tarif journalier de votre prestataire, et vous avez votre budget.
Les coûts internes qu'on oublie
Le budget d'un prestataire ne couvre jamais tout. Pendant le chantier, quelqu'un chez vous doit tester les commandes, les promotions, les factures, les exports. Les évolutions de la boutique doivent être gelées ou limitées, sinon chacune sera développée deux fois. Ces coûts ne figurent sur aucun devis, mais ils pèsent sur votre trimestre. Mieux vaut les prévoir que les subir.
Si vous voulez ce chiffrage pour votre boutique plutôt que pour une boutique moyenne, je vous remets un diagnostic de migration offert : rapport de l'outil, liste des plugins à remplacer, postes classés par gravité et estimation en jours.
Comment réduire la facture sans prendre de risque ?
Le premier levier est l'automatisation. Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store et sur GitHub, applique plus de 40 corrections automatiques, que je relis ensuite. Ce qui est mécanique ne doit pas être facturé comme du travail manuel.
Le deuxième levier est le tri. Une fonctionnalité qui ne sert plus coûte moins cher à supprimer qu'à migrer, et un plugin maison peut parfois être remplacé par une fonction native ou un plugin maintenu. Le troisième levier est le découpage : supprimer les dépréciations de la 1.14 et remplacer un plugin abandonné sont des travaux livrables en production avant la migration. Le LegacyShopBridgePlugin permet aussi, dans certains cas, de garder l'ancien front boutique sur une application Sylius 2 et d'étaler la reprise du thème.
Un levier, en revanche, est à proscrire : rogner la recette. C'est là que naissent les régressions qui coûtent des commandes, bien plus cher que les jours économisés.
Que coûte le fait d'attendre ?
Le budget ne se compare pas à zéro. La 1.14 cesse de recevoir des correctifs de sécurité le 31 décembre 2026, et chaque fonctionnalité ajoutée en 1.x d'ici là augmente le périmètre à migrer. Je détaille ce calcul dans l'article migrer maintenant ou plus tard, et la question des postes qui peuvent bouger après la migration dans l'article Sylius 2 va-t-il augmenter mes coûts.
Ce que je vous propose
Je lance Sylius Upgrade Analyzer sur votre projet, je complète à la main ce que l'outil ne mesure pas, comme la recette, les données et les plugins sans version 2, et je vous remets une estimation en jours, poste par poste, avec les zones d'incertitude nommées. Je vous rappelle sous 24 heures ouvrées pour la commenter. Vous appliquez ensuite le tarif de qui vous voulez, et vous décidez en connaissance de cause, avant l'échéance du 31 décembre 2026.