Sylius 2 : comment chiffrer les développements spécifiques ?
On estime le coût des développements spécifiques à reprendre en trois temps : inventorier tout ce qui s'écarte du Sylius standard, rattacher chaque élément à la rupture de Sylius 2 qui le touche, puis le classer entre garder, adapter, remplacer ou supprimer avant de l'estimer en heures. Le total, converti en jours et complété par la recette de chaque fonctionnalité, donne le coût dès que vous l'appliquez au tarif journalier de votre prestataire. Sans inventaire, toute estimation du spécifique est une supposition.
Je suis développeur e-commerce indépendant à Metz, spécialiste de Sylius, et auteur de Sylius Upgrade Analyzer, un outil open source publié sur le Sylius Store. Cet article s'adresse surtout au responsable technique, mais la conclusion vaut pour le dirigeant : le spécifique est presque toujours ce qui fait l'écart entre deux budgets de migration.
Que faut-il compter comme développement spécifique ?
Tout ce qui n'est pas livré par Sylius ou par un plugin maintenu. Dans un projet Symfony classique, on le trouve à quelques endroits précis. Le dossier templates/bundles contient les gabarits qui remplacent ceux de Sylius, selon la convention de surcharge des bundles de Symfony. Le dossier src contient les entités étendues, les services décorés, les écouteurs d'événements, les contrôleurs et les commandes maison. Le dossier config porte les grilles d'administration, les ressources, les machines à états winzou et les passerelles de paiement. Les assets contiennent le JavaScript et le CSS du thème. Enfin, le composer.json révèle les plugins développés en interne, souvent déclarés en dépôt local.
Pour le dirigeant, la conséquence est simple : plus ces dossiers sont remplis, plus la migration coûte, quel que soit le nombre de produits ou de commandes de la boutique.
À quelle rupture de Sylius 2 chaque développement se rattache-t-il ?
Un développement spécifique ne coûte que s'il touche une rupture. Le guide officiel UPGRADE-2.0 les décrit en détail ; voici la correspondance que j'utilise pour classer un inventaire.
| Type de développement | Rupture Sylius 2 | Nature du travail |
|---|---|---|
| Gabarits Twig surchargés, template events | Twig Hooks, retrait des template events de SyliusUiBundle | Découper chaque surcharge en hooks |
| JavaScript jQuery, classes Semantic UI | Bootstrap 5, Symfony UX et Stimulus | Réécrire les comportements en contrôleurs Stimulus |
| Callbacks winzou sur commande, paiement, expédition | Symfony Workflow par défaut | Réécrire en écouteurs de transitions |
| Passerelle de paiement sur mesure | Payment Requests, Payum toujours possible | Adapter ou réécrire la passerelle |
| Ressources et filtres API | Nouvelle version d'API Platform | Migrer la configuration, retester les clients |
| E-mails personnalisés | symfony/mailer à la place de SwiftMailer | Changer les classes d'envoi |
| Appels au conteneur de services | Services privés par défaut | Passer par l'injection de dépendances |
| Classes du cœur étendues ou utilisées | Classes supprimées ou renommées | Trouver le remplaçant ou réécrire |
Chacune de ces lignes a son article détaillé : les Twig Hooks, le passage de winzou à Symfony Workflow, les classes supprimées. Ici, l'enjeu n'est pas de les corriger mais de les compter.
Comment estimer chaque élément en heures ?
L'inventaire automatique
C'est l'étape qui transforme une impression en liste. Sylius Upgrade Analyzer s'installe en dépendance de développement et se lance en local, sans envoyer le code ailleurs. Ses 49 analyseurs parcourent les gabarits, les dépréciations, les plugins, les grilles, les ressources et API Platform. Chaque problème détecté reçoit un niveau de complexité, de trivial à majeur, et une estimation en minutes ; le rapport totalise les heures par catégorie. Si votre projet a des motifs propres, des règles personnalisées permettent de leur attribuer votre propre durée. L'outil convertit enfin les heures en jours sur une base de sept heures, arrondie à la demi-journée supérieure, et l'option --sprint-plan associée à --velocity répartit le travail selon la capacité réelle de l'équipe. Le code source est public sur GitHub.
Le tri : garder, adapter, remplacer, supprimer
Avant d'additionner, posez une question au métier pour chaque développement : sert-il encore ? Une option de livraison abandonnée, un export que plus personne n'ouvre, une promotion d'il y a trois ans : supprimer coûte presque toujours moins cher que migrer. Ensuite, vérifiez si une fonction native de Sylius 2 ou un plugin maintenu fait désormais le travail. Ce tri est souvent le moyen le plus efficace de réduire un budget, et il se fait avant tout chiffrage.
Une incertitude par ligne, pas une marge globale
Certains éléments sont plus risqués que d'autres : du code que personne ne connaît plus, une règle métier sans test, une dépendance à un service externe. Je note un niveau de confiance sur chaque ligne plutôt que d'ajouter un pourcentage global au total. Le dirigeant voit ainsi ce qu'il provisionne, et pourquoi.
Si vous voulez que je mène cet inventaire pour vous, je vous remets un diagnostic de migration offert, avec le rapport commenté et une estimation en jours.
Ce que l'analyse statique ne voit pas
Un outil lit le code, pas votre métier. Il ne sait pas qu'un écouteur winzou déclenche l'envoi d'une commande à votre logisticien, ni qu'une surcharge de gabarit cache une règle tarifaire négociée avec un grand compte. Chaque développement spécifique doit donc recevoir, en plus de son estimation de code, un temps de recette : un scénario qui prouve que la fonctionnalité se comporte comme avant. Sur les boutiques que j'ai migrées, c'est ce temps de vérification, plus que le code, qui était sous-estimé dans les premières évaluations. Les méthodes de test sont détaillées dans l'article tester une migration Sylius 1 vers 2.
Un exemple de raisonnement
Prenons un cas fictif, pour la méthode. Une boutique calcule une date de livraison estimée quand la commande est validée, l'affiche dans le récapitulatif du tunnel et l'ajoute à l'e-mail de confirmation. Cela donne trois lignes d'inventaire. Le calcul, branché sur un callback winzou, devient un écouteur de transition Symfony Workflow. L'affichage, fait par une surcharge du gabarit de récapitulatif, devient un hook. L'ajout à l'e-mail suit le passage à symfony/mailer. Chaque ligne s'estime séparément, puis on ajoute un scénario de recette : commande validée, date correcte affichée et envoyée. Additionner ces lignes pour chaque fonctionnalité donne un coût que vous pouvez défendre, et que vous pouvez réduire en retirant ce qui ne sert plus.
Ce que je vous propose
Installez Sylius Upgrade Analyzer et lancez-le sur votre projet, ou laissez-moi le faire. Je complète l'inventaire avec ce que l'outil ne voit pas, je classe chaque développement entre garder, adapter, remplacer et supprimer, et je vous remets une estimation en jours poste par poste. Je vous rappelle sous 24 heures ouvrées pour la commenter. Avec la fin des correctifs de sécurité de la 1.14 au 31 décembre 2026, mieux vaut connaître le poids de votre spécifique dès maintenant.