Migration Sylius 2 : prioriser un parc de boutiques

Une agence priorise la migration de ses boutiques Sylius 1.x en trois temps : un inventaire précis de chaque projet, un score de risque qui croise l'exposition et la complexité technique, puis un ordre de passage qui commence par une boutique pilote simple pour roder la méthode avant les boutiques critiques. Avec la fin du support de sécurité de Sylius 1.14 le 31 décembre 2026, chaque boutique du parc doit avoir une date et un plan écrit, partagé avec le client.

Pourquoi une agence ne peut-elle pas migrer ses boutiques au fil de l'eau ?

Parce que les échéances tombent en même temps pour tout le parc, alors que l'équipe capable de faire une migration Sylius 2 est limitée. Migrer au fil des demandes, c'est découvrir la boutique la plus difficile en dernier, souvent trop tard. Le tableau ci-dessous reprend les dates du cycle de versions officiel, recoupées avec endoflife.date.

Le piège classique : oublier les boutiques déjà passées en 2.0 ou 2.1. Elles ne sont plus couvertes non plus. Leur montée vers la 2.2 ou la 2.3 est plus légère qu'un passage depuis la 1.14, mais elle appartient au même planning. Autre point souvent oublié : l'échéance du 31 décembre tombe en pleine saison commerciale, période où aucune boutique ne veut d'une bascule.

Quel inventaire faire de son parc Sylius ?

Une ligne par boutique, dans un tableur partagé. Chaque colonne doit se remplir à partir d'une source vérifiable, pas de mémoire.

Comment construire un score de risque par boutique ?

Notez chaque boutique sur deux axes séparés. L'urgence mesure ce que la boutique risque à rester en l'état ; la complexité mesure l'effort de migration. Les mélanger dans une seule note fait disparaître l'information utile.

Une boutique à forte urgence et faible complexité passe vite. Une boutique à forte urgence et forte complexité démarre tout de suite, même si elle finit tard. Une boutique à faible urgence et faible complexité sert de pilote. Les autres se planifient ensuite, en surveillant les dates de la 2.x choisie.

Comment l'analyse multi-projets accélère-t-elle l'inventaire ?

Remplir les colonnes techniques à la main pour dix boutiques prend des jours. J'ai créé Sylius Upgrade Analyzer pour ce travail : outil en ligne de commande open source, sous licence MIT, qui analyse les projets Sylius 1.0 à 1.14 et propose une analyse multi-projets. Ses 49 analyseurs couvrent les gabarits, les dépréciations, les plugins, les grilles et API Platform ; il vérifie les plugins contre le Sylius Store et Packagist. Les exports JSON ou CSV s'agrègent dans votre tableur, et le planificateur de sprints donne une première découpe du travail.

Pour une agence, un détail compte : l'outil s'exécute en local, le code de vos clients ne part chez aucun service tiers. Sa limite est tout aussi nette : il lit le code, pas le contexte commercial. La saisonnalité, l'appétit du client pour le risque et le budget restent votre travail. Pour transformer ses résultats en jours, voyez la méthode d'estimation d'un chantier de migration.

Dans quel ordre migrer les boutiques ?

Commencez par une boutique pilote : peu de plugins, code propre, client compréhensif. Elle sert à écrire votre procédure interne, à mesurer le temps réel et à repérer les pièges propres à votre façon de développer. Les montées de version Sylius 1.x vers 2.x que j'ai menées en production confirment ce point : la première boutique coûte toujours plus que les suivantes.

Regroupez ensuite les boutiques qui partagent les mêmes plugins ou le même socle maison. Un plugin interne porté une fois sert à tout le groupe, et c'est là que l'agence gagne vraiment du temps. Pour les plugins tiers, la méthode de tri est dans l'article sur la compatibilité des plugins avec Sylius 2. Lancez en parallèle, dès maintenant, le chantier de la boutique la plus complexe : c'est elle qui risque de dépasser l'échéance. Enfin, placez chaque bascule hors des pics de vente du client, avec une procédure de retour arrière, comme décrit dans la bascule en production sans coupure.

Choisissez aussi une version cible commune quand c'est possible, pour ne maintenir qu'un socle. Les critères de choix entre 2.2 et 2.3 sont détaillés dans l'article sur la version cible.

Comment l'annoncer aux clients finaux ?

Un message court, écrit, envoyé à chaque client avant la fin de l'année. Il dit ce qui change et quand, avec la date officielle et sa source ; ce que cela implique pour sa boutique, à partir de l'inventaire et non d'un discours général ; les options réelles, y compris rester en 1.14 avec un risque documenté ; le calendrier proposé, la période de gel des évolutions et la recette attendue de son côté.

Si le client refuse, faites valider ce choix par écrit et adaptez le contrat de maintenance. Une agence ne peut pas promettre des correctifs de sécurité sur une version que l'éditeur ne maintient plus.

Quand sous-traiter la migration en marque blanche ?

Quand votre équipe n'a pas encore pratiqué les Twig Hooks, Symfony Workflow et API Platform 4 sur une vraie boutique, ou quand le nombre de projets dépasse votre capacité d'ici l'échéance. En sous-traitance en marque blanche, je travaille sous votre nom : vous gardez la relation, le planning et la facturation, un accord de confidentialité encadre l'accès au code. Sylius propose aussi un audit de migration officiel, sans prix ni délai publiés.

Sous-traiter n'a pas d'intérêt si votre équipe a déjà migré une boutique comparable et dispose du temps nécessaire : gardez alors le savoir en interne. Dans les deux cas, la première étape est la même. Je lance l'analyse sur votre parc et je vous remets un diagnostic de migration Sylius 2 offert, boutique par boutique, avec une estimation en jours pour bâtir votre ordre de passage.