Checklist : 49 Points de Controle pour Auditer un Projet Sylius 1.x Avant Migration

Avant de lancer la migration de votre projet Sylius 1.x vers 2.0, un audit methodique est indispensable. J'ai organise les 49 points de controle du Sylius Upgrade Analyzer en 5 familles thematiques. Pour chaque point : la severite, le temps de correction estime, et comment l'outil automatise la detection.

Comment utiliser cette checklist

Chaque point est marque avec un niveau de severite :

• BREAKING — Bloquant. La migration echouera ou l'application sera inutilisable sans correction.
• WARNING — Non bloquant mais produit de la dette technique, des deprecations ou des comportements degrades.
• SUGGESTION — Amelioration recommandee pour adopter les bonnes pratiques Sylius 2.0.

Lancez d'abord l'analyse automatisee :

composer require --dev pierre-arthur/sylius-upgrade-analyzer
vendor/bin/sylius-upgrade-analyzer sylius-upgrade:analyze

Puis parcourez cette checklist pour comprendre chaque point du rapport et prioriser les corrections.

Famille 1 : Templates & Frontend (14 analyseurs)

C'est la famille la plus volumineuse car la migration frontend est le chantier le plus impactant.

1. BREAKING — Template Overrides Count : nombre de fichiers dans templates/bundles/SyliusShopBundle/ et SyliusAdminBundle/. Chaque override doit etre verifie et potentiellement converti en Twig Hook. Temps : 30min-2h par override selon la complexite.
2. BREAKING — Semantic UI Classes Detection : scan de toutes les classes ui button, ui form, ui grid, etc. dans les templates Twig et fichiers CSS/SCSS. Temps : 5-15min par fichier concerne.
3. BREAKING — jQuery Usage Detection : detection de $(, jQuery(, $.ajax dans les fichiers JS et les blocs <script> Twig. Temps : 15-45min par script a reecrire en Stimulus.
4. WARNING — Semantic UI Module Init : appels d'initialisation Semantic UI (.dropdown(), .modal(), .tab(), .accordion()). Temps : 10min par module a convertir.
5. WARNING — Gulp/Grunt Detection : presence de gulpfile.js ou Gruntfile.js indicant un pipeline d'assets non-standard. Temps : 2-4h pour migrer vers Webpack Encore.
6. WARNING — Custom Webpack Config : divergences par rapport a la configuration Encore standard de Sylius 2.0. Temps : 1-3h selon les personnalisations.
7. BREAKING — Twig Block Overrides : blocs Twig surcharges qui n'existent plus dans les templates Sylius 2.0. Temps : 30min-1h par bloc.
8. SUGGESTION — Twig Hook Migration Candidates : overrides simples (ajout de contenu) convertibles directement en Twig Hooks. Temps : 15min par hook.
9. WARNING — Inline JavaScript : blocs <script> inline dans les templates Twig au lieu de controleurs Stimulus. Temps : 15-30min par bloc.
10. WARNING — Custom Fonts via Semantic UI : detection de themes Semantic UI custom (fichiers .variables et .overrides). Temps : 1-2h pour migrer vers des variables SCSS Bootstrap.
11. SUGGESTION — Image Asset Pipeline : images referencees via l'ancien pipeline d'assets Sylius. Temps : 30min.
12. WARNING — Third-Party jQuery Plugins : plugins jQuery tiers dans package.json (select2, slick, datatables...). Temps : 1-3h par plugin a remplacer.
13. SUGGESTION — Responsive Breakpoints : breakpoints Semantic UI custom qui different de ceux de Bootstrap 5. Temps : 1h.
14. SUGGESTION — CSS Custom Properties : opportunite de migration vers des variables CSS natives. Temps : 30min-1h.

Famille 2 : Deprecations & Breaking Changes (15 analyseurs)

Le coeur de la migration backend. Chaque point correspond a une API, un composant ou un comportement modifie dans Sylius 2.0.

15. BREAKING — Winzou State Machine Usage : detection de winzou_state_machine dans les configs YAML et les injections de StateMachineInterface. Temps : 2-4h pour migrer chaque workflow custom vers Symfony Workflow.
16. BREAKING — Winzou Callbacks : callbacks custom enregistres dans les transitions winzou. Chacun doit devenir un event subscriber Symfony Workflow. Temps : 1-2h par callback.
17. BREAKING — Winzou Guards : guards de transition bases sur des callbacks de service. Doivent etre convertis en expressions Symfony ou event listeners. Temps : 30min-1h par guard.
18. BREAKING — SwiftMailer Usage : detection de Swift_Message, Swift_Mailer et configuration swiftmailer:. Temps : 1-2h pour migrer vers symfony/mailer.
19. BREAKING — Payum Custom Gateways : passerelles Payum custom (Actions, GatewayFactories). Fonctionnent encore mais a auditer. Temps : 2-8h par passerelle si migration vers Payment Requests.
20. BREAKING — Stripe/PayPal Core Removal : dependance aux passerelles Stripe ou PayPal retirees du core. Temps : 2-4h pour installer un plugin de remplacement.
21. BREAKING — Removed Classes : utilisation de classes PHP supprimees dans Sylius 2.0 (controllers, form types, events renommes). Temps : 15-30min par occurrence.
22. BREAKING — Removed Services : services du container supprimes ou renommes. Temps : 10-20min par service.
23. WARNING — Deprecated Method Calls : appels a des methodes marquees @deprecated dans Sylius 1.x. Temps : 10min par occurrence.
24. WARNING — Symfony Deprecations : deprecations Symfony 6.4 qui deviennent des erreurs dans Symfony 7. Temps : variable.
25. BREAKING — Removed Routes : routes Sylius supprimees ou renommees dans 2.0. Temps : 15min par route.
26. WARNING — Event Name Changes : evenements Sylius renommes. Temps : 10min par listener.
27. BREAKING — PHP Version Compatibility : verification que le code est compatible PHP 8.2+ (requis par Sylius 2.0). Temps : variable selon l'etat du code.
28. WARNING — Doctrine Mapping Changes : modifications de mapping Doctrine dans les entites Sylius. Temps : 30min-1h.
29. SUGGESTION — PHP Attributes Migration : annotations Doctrine/Symfony convertibles en PHP 8 attributes. Temps : auto-fixable.

Famille 3 : Plugins (8 analyseurs)

Les plugins tiers sont souvent le point de blocage le plus imprevisible.

30. BREAKING — Plugin Compatibility Check : verification de chaque plugin Sylius dans composer.json contre la base de compatibilite 2.0. Temps : 15min par plugin incompatible (recherche d'alternative).
31. BREAKING — Abandoned Plugins : plugins plus maintenus (pas de commit depuis 12+ mois). Temps : 2-8h pour forker ou remplacer.
32. WARNING — Plugin Template Overrides : plugins qui overrident des templates Sylius (double couche d'override). Temps : 1-2h par plugin concerne.
33. WARNING — Plugin Service Overrides : plugins qui decorent ou remplacent des services Sylius core. Temps : 1h par service concerne.
34. BREAKING — Plugin Winzou Dependencies : plugins qui ajoutent des callbacks winzou. Temps : 2h par plugin.
35. SUGGESTION — Plugin Marketplace Availability : verification de la presence sur le marketplace officiel Sylius. Temps : 5min par plugin.
36. WARNING — Plugin Symfony Version Constraints : plugins avec des contraintes Symfony incompatibles avec 6.4/7.x. Temps : variable.
37. WARNING — Plugin API Platform Compatibility : plugins qui etendent l'API Sylius via API Platform 2.7. Temps : 2-4h par plugin.

Famille 4 : Grid & Resource (6 analyseurs)

Le systeme de grilles et ressources Sylius a ete modernise dans la version 2.0.

38. BREAKING — Grid Configuration Format : grilles YAML utilisant l'ancien format de configuration. Temps : 15-30min par grille.
39. WARNING — Custom Grid Actions : actions de grille custom utilisant des classes supprimees. Temps : 30min par action.
40. WARNING — Custom Grid Filters : filtres de grille custom a adapter au nouveau format. Temps : 30min par filtre.
41. BREAKING — Resource Configuration : configuration des ressources Sylius (modeles, controllers, repositories) utilisant l'ancien format. Temps : 20min par ressource.
42. SUGGESTION — Grid to Twig Component : grilles admin convertibles en composants Twig pour plus de flexibilite. Temps : 1h par grille.
43. WARNING — Custom Resource Actions : actions de ressources custom utilisant le routing ancien format. Temps : 20min par action.

Famille 5 : API Platform (6 analyseurs)

La migration d'API Platform 2.7 vers 4 est un chantier a part entiere.

44. BREAKING — API Platform Annotations : annotations @ApiResource, @ApiFilter, @ApiProperty a migrer vers les PHP 8 attributes et la nouvelle syntaxe AP4. Temps : 15-30min par entite API.
45. BREAKING — Custom Data Providers : Data Providers AP 2.7 a migrer vers des State Providers AP 4. Temps : 1-2h par provider.
46. BREAKING — Custom Data Persisters : Data Persisters AP 2.7 a migrer vers des State Processors AP 4. Temps : 1-2h par persister.
47. WARNING — API Serialization Groups : groupes de serialisation modifies dans Sylius 2.0. Temps : 30min-1h pour adapter.
48. WARNING — Custom API Endpoints : endpoints API custom utilisant les operations AP 2.7. Temps : 30min par endpoint.
49. BREAKING — API Platform Configuration : fichiers de configuration api_platform.yaml utilisant des cles AP 2.7 supprimees. Temps : 1-2h.

Tableau recapitulatif des estimations

Famille	Analyseurs	BREAKING	WARNING	SUGGESTION	Temps moyen (projet type)
Templates & Frontend	14	4	6	4	15-40h
Deprecations & Breaking Changes	15	9	5	1	10-30h
Plugins	8	3	4	1	5-20h
Grid & Resource	6	2	3	1	3-10h
API Platform	6	4	2	0	5-15h
Total	49	22	20	7	38-115h

Ces estimations concernent un projet Sylius de taille moyenne. Un projet simple (peu de customisations, peu de plugins) peut etre dans la fourchette basse. Un projet enterprise avec des dizaines de plugins et un storefront fortement customise peut depasser les 150h.

Les 41 auto-fixers

Parmi les 49 analyseurs, 41 disposent d'un auto-fixer qui peut appliquer la correction automatiquement :

# Appliquer tous les auto-fixers disponibles
vendor/bin/sylius-upgrade-analyzer sylius-upgrade:fix

# Appliquer uniquement les fixers d'une famille
vendor/bin/sylius-upgrade-analyzer sylius-upgrade:fix --family=templates
vendor/bin/sylius-upgrade-analyzer sylius-upgrade:fix --family=deprecations
vendor/bin/sylius-upgrade-analyzer sylius-upgrade:fix --family=plugins
vendor/bin/sylius-upgrade-analyzer sylius-upgrade:fix --family=grid
vendor/bin/sylius-upgrade-analyzer sylius-upgrade:fix --family=api

# Mode dry-run : voir ce qui serait modifie sans appliquer
vendor/bin/sylius-upgrade-analyzer sylius-upgrade:fix --dry-run

Les auto-fixers couvrent les corrections mecaniques : renommage de classes, remplacement de methodes depreciees, conversion d'annotations en attributes, mise a jour de configurations YAML. Les 8 points sans auto-fixer sont ceux qui necessitent une decision humaine (choix de plugin de remplacement, reecriture de logique metier custom).

Workflow d'audit recommande

1. Installer l'outil : composer require --dev pierre-arthur/sylius-upgrade-analyzer
2. Lancer l'analyse : vendor/bin/sylius-upgrade-analyzer sylius-upgrade:analyze
3. Lire le rapport : le rapport liste chaque point avec sa severite, le fichier concerne, et l'estimation de temps
4. Prioriser : traitez d'abord les BREAKING, puis les WARNING, puis les SUGGESTION
5. Appliquer les auto-fixers : sylius-upgrade:fix --dry-run puis sylius-upgrade:fix
6. Corriger manuellement : les 8 points restants qui necessitent une decision humaine
7. Relancer l'analyse : verifiez que le compteur de problemes descend a zero
8. Generer le rapport PDF : pour les parties prenantes et la documentation du projet

Quand faire appel a un expert ?

L'outil automatise la detection, mais certains cas necessitent de l'expertise :

• Votre projet a plus de 30 template overrides et vous hesitez entre les conserver ou migrer vers les Twig Hooks
• Vous avez des passerelles de paiement Payum custom et vous voulez evaluer la migration vers Payment Requests
• Plusieurs plugins critiques n'ont pas de version compatible et vous devez decider entre forker, remplacer ou reecrire
• Votre storefront est fortement customise avec du jQuery complexe et vous avez besoin d'un plan de migration frontend structure
• Vous voulez une estimation fiable a presenter a votre direction ou a votre client

J'accompagne des equipes en Grand-Est (France) et en Wallonie (Belgique) sur ces migrations. Mon approche : audit automatise avec Sylius Upgrade Analyzer, rapport detaille avec estimations chiffrees, et accompagnement technique sur les points complexes. Contactez-moi pour discuter de votre projet.

Conclusion

Les 49 points de controle couvrent l'integralite de ce qui doit etre verifie avant une migration Sylius 2.0. L'automatisation via Sylius Upgrade Analyzer reduit l'audit de plusieurs jours a quelques minutes, et les 41 auto-fixers prennent en charge les corrections mecaniques. Il reste toujours une part de travail humain pour les decisions d'architecture et les reecritures de logique metier, mais le gros du travail ingrat est automatise. Lancez l'analyse, lisez le rapport, et vous saurez exactement ou vous en etes.