Durée d'une migration Sylius 2 : estimer en jours

Une migration Sylius 1 vers 2 n'a pas de durée standard : elle se compte en jours de développement, et ce nombre dépend de votre code bien plus que de Sylius. Quatre facteurs font l'essentiel de l'écart : la version de départ, le volume de gabarits et de services surchargés, les plugins tiers, et l'usage de l'API ou des paiements. Le seul chiffre fiable sort d'un inventaire de votre projet, converti en jours puis complété par la recette et la bascule.

Je suis développeur Sylius et Symfony indépendant, et j'ai déjà mené des montées de version 1.x vers 2.x de boutiques en production. Je ne vous donnerai donc pas de moyenne : deux boutiques sur la même version peuvent demander des chantiers sans commune mesure. Je vous donne en revanche la méthode que j'applique pour transformer un projet en estimation défendable, et les pièges qui font déraper un calendrier.

Pourquoi personne ne peut donner une durée sans voir votre code ?

Sylius 2.0 n'est pas une mise à jour de routine. Le guide officiel UPGRADE-2.0 décrit un changement de socle complet : Semantic UI et jQuery remplacés par Bootstrap 5 et Symfony UX, suppression des template events et de SyliusUiBundle, Symfony Workflow à la place de winzou par défaut, API Platform 2.7 remplacé par la version 4, SwiftMailer remplacé par symfony/mailer, services privés par défaut, des dizaines de routes supprimées.

Chacune de ces ruptures ne coûte que si votre projet l'utilise. Une boutique restée proche du standard traverse la plupart d'entre elles sans effort. Une boutique qui a surchargé des dizaines de gabarits Twig, écrit ses propres transitions winzou et exposé une API à une application mobile les paie toutes. Le temps d'une migration est donc le reflet exact de votre personnalisation, et un devis donné sans lire le code est une supposition.

Autre point qui surprend : il n'existe pas de raccourci automatique pour le cœur. Le paquet sylius/sylius-rector ne propose pas de jeu de règles pour migrer un projet 1.14 vers 2.0 ; ses règles visent les plugins et Sylius Plus. Le gros du travail reste manuel.

Qu'est-ce qui fait varier la durée d'une migration Sylius 2 ?

Voici la grille que j'utilise pour situer un projet avant même de chiffrer. Elle ne donne pas de jours, elle dit où les jours vont se loger.

Les deux lignes qui surprennent le plus les dirigeants sont les plugins et les tests. Un plugin abandonné peut à lui seul peser plus lourd que tout le reste. Et sans tests, chaque correction doit être vérifiée à la main, ce qui rallonge la recette bien plus que le développement.

Comment estimer le chantier en jours, étape par étape ?

Partir de la version réelle

Le chemin officiel est fixe : monter en 1.14, supprimer ses dépréciations, passer en 2.0, puis appliquer les fichiers UPGRADE suivants jusqu'à la version visée. Si vous êtes sur une version antérieure à la 1.14, cette première marche fait partie du chantier et doit être chiffrée à part.

Inventorier automatiquement le code

C'est l'étape qui transforme une impression en liste. J'ai créé pour cela Sylius Upgrade Analyzer, un outil open source sous licence MIT qui s'exécute en local sur votre projet, avec la commande vendor/bin/sylius-upgrade-analyzer sylius-upgrade:analyze --target-version=2.3. Ses 49 analyseurs couvrent les gabarits et l'interface, les dépréciations, les plugins, les grilles et ressources, et API Platform. Chaque problème détecté porte une estimation en minutes, et le rapport donne un total en heures par catégorie. Le code source est public sur GitHub.

Convertir en jours de calendrier

Un total d'heures n'est pas une date. L'option --sprint-plan, associée à --velocity, répartit le travail en sprints selon le nombre d'heures réellement disponibles par sprint. C'est ce chiffre qui compte : un développeur à mi-temps sur votre projet ne livre pas au même rythme qu'un développeur dédié. Fixez la vélocité honnêtement, pas celle que vous espérez.

Ajouter ce qu'aucun outil ne mesure

L'analyse statique voit le code, pas votre métier. Il faut ajouter à la main la recette fonctionnelle de vos parcours de commande, la migration et le contrôle des données, l'adaptation des plugins sans version 2, les réglages d'hébergement si la version cible exige un PHP plus récent, et la préparation de la mise en production. Je les chiffre séparément, ligne par ligne, pour que vous voyiez ce qui relève du code et ce qui relève de la vérification.

Si vous voulez contrôler le périmètre point par point, la checklist d'audit en 49 points reprend les mêmes familles de risques.

La version cible change-t-elle la durée ?

Oui. Viser directement la dernière version évite de refaire une montée de version quelques mois plus tard, mais elle impose ses propres prérequis. Le tableau reprend le calendrier publié sur la page cycle de publication de Sylius et sur endoflife.date.

Viser la 2.3 ajoute souvent une mise à niveau de PHP côté serveur, mais retire une étape future. Je détaille cet arbitrage dans l'article sur le choix de la version cible.

Que faire si le calendrier ne tient pas avant le 31 décembre 2026 ?

La 1.14 cesse de recevoir des correctifs de sécurité le 31 décembre 2026. Si l'estimation dépasse cette date, ne compressez pas la recette pour tenir un jalon : c'est précisément là que naissent les erreurs coûteuses, celles que je décris dans les dix erreurs de migration les plus fréquentes. Votre boutique ne s'arrêtera pas le 1er janvier.

Il vaut mieux découper. Supprimer les dépréciations de la 1.14 est un travail utile en soi, livrable en production avant la migration. Remplacer un plugin abandonné peut aussi se faire en amont. Pendant la période sans correctif, renforcez la surveillance des dépendances et de l'hébergement, et documentez la décision. Un chantier découpé et livré par étapes vaut mieux qu'un chantier unique bâclé.

Ce que l'estimation ne vous dira pas

Une estimation reste une estimation. Elle se trompe surtout sur trois points : le code que personne ne connaît plus, les règles métier implicites que l'équipe découvre en recette, et les plugins dont l'éditeur promet une version 2 sans date. Je signale ces zones d'incertitude explicitement plutôt que de les noyer dans une marge.

Dans certains cas, la bonne réponse n'est pas de migrer. Si la boutique est très ancienne, peu personnalisée ou si son modèle commercial a changé, repartir d'une installation Sylius 2 propre et reprendre les données peut coûter moins cher que de faire évoluer un code fatigué. L'estimation sert aussi à prendre cette décision. Reste ensuite à organiser la mise en production, que je traite dans l'article sur la bascule sans coupure.

Si vous voulez un chiffre fondé sur votre code plutôt que sur une moyenne, je lance Sylius Upgrade Analyzer sur votre projet, je complète à la main ce que l'outil ne voit pas, et je vous remets un diagnostic de migration offert avec une estimation en jours. Vous décidez ensuite, avec moi ou sans moi.