Migration Sylius 2 sans coupure : la bascule
Pour migrer vers Sylius 2 sans couper la boutique, on ne touche pas à la production pendant le chantier : on construit la version Sylius 2 à côté, on la répète sur une copie des données réelles, puis on bascule dans une fenêtre courte avec un retour arrière prêt. Vos clients continuent de commander sur la 1.14 jusqu'au dernier moment. Seule la bascule impose un bref gel des commandes, planifié au creux du trafic.
Je suis développeur Sylius et Symfony indépendant, et j'ai mené des montées de version 1.x vers 2.x de boutiques en production. Sur un projet public, la boutique belge Coucouroucoucou, je reprends environ 15 000 commandes sur Sylius avec 14 écrans d'administration sur mesure, et la nouvelle version est en recette avant sa mise en production ; le détail est dans l'étude de cas. Voici la méthode, avec ses points de contrôle et ses limites.
Pourquoi ne pas migrer directement la boutique en ligne ?
Parce que Sylius 2 n'est pas un correctif qu'on applique un soir. Le guide officiel UPGRADE-2.0 remplace l'interface (Bootstrap 5 et Symfony UX à la place de Semantic UI et jQuery), la machine à états des commandes, la couche API, l'envoi des e-mails et une partie des routes. Le code de la boutique change en profondeur, et la base de données aussi.
Une migration en place laisse la boutique dans un état intermédiaire tant que le chantier dure. Si une étape échoue, il n'y a plus de version stable sur laquelle revenir. La règle est donc simple : la production reste intacte jusqu'au jour de la bascule, et tout le travail se fait sur une branche et un environnement séparés.
Comment préparer la bascule pendant que la boutique tourne ?
Un environnement Sylius 2 identique à la production
La nouvelle version doit tourner sur un serveur de préproduction configuré comme la production : même version de PHP, mêmes workers, mêmes tâches planifiées, même configuration de cache. Une différence d'environnement découverte le jour J coûte bien plus cher qu'une semaine de préparation.
Des répétitions sur une copie des données réelles
C'est le cœur de la méthode. Je récupère une copie récente de la base de production, j'y applique les migrations, puis je déroule les parcours réels : commande, paiement, remboursement, connexion client, administration. Chaque répétition est chronométrée, ce qui donne la durée réelle du gel le jour J.
Deux points de données méritent une attention particulière. D'abord, les migrations Doctrine ont été régénérées en 2.0 : les anciens fichiers sont supprimés et leur contenu regroupé en une seule migration. Il faut vérifier sur la copie que l'historique de vos propres migrations reste cohérent. Ensuite, l'encodeur et le sel ont été retirés des entités utilisateur au profit du hacheur de mots de passe de Symfony. Si certains mots de passe anciens ne portent pas le nom de leur algorithme, il faut configurer migrate_from, sans quoi des clients ne pourront plus se connecter. Ce genre d'erreur ne se voit pas en développement avec des comptes de test.
Un gel des évolutions
Pendant le chantier, toute évolution livrée sur la 1.14 doit être reportée sur la branche Sylius 2. Je limite donc la production aux correctifs urgents. Moins il y a d'écart entre les deux branches, moins la bascule réserve de surprises.
Comment se déroule le jour de la bascule ?
Le jour J ne doit contenir aucune découverte. On rejoue une procédure déjà répétée, avec des critères de réussite fixés à l'avance.
| Moment | Action | Critère de réussite | En cas d'échec |
|---|---|---|---|
| Veille | Annonce interne, vérification des sauvegardes, préproduction validée | Restauration testée, procédure relue | On reporte, rien n'a été touché |
| Début du gel | Page de maintenance, arrêt des tâches planifiées et des workers | Plus aucune commande en cours | On rouvre la boutique 1.14 |
| Sauvegarde | Copie complète de la base et des fichiers envoyés | Sauvegarde lisible et horodatée | On rouvre la boutique 1.14 |
| Migration | Déploiement du code Sylius 2, migrations Doctrine, vidage du cache | Migrations terminées sans erreur | Restauration de la sauvegarde et du code 1.14 |
| Contrôle | Commande test réelle, paiement, e-mail, connexion d'un ancien compte | Tous les parcours passent | Restauration, analyse à froid |
| Réouverture | Levée de la maintenance, relance des workers et des tâches | Premières commandes clients reçues | Correctif ciblé, plus de retour arrière simple |
Comment revenir en arrière si quelque chose casse ?
Le retour arrière se prépare avant, pas pendant. Il repose sur deux éléments : l'ancienne version du code, conservée prête à redéployer, et la sauvegarde de la base prise au début du gel. Encore faut-il avoir déjà restauré cette sauvegarde au moins une fois ; je détaille pourquoi dans l'article sur les sauvegardes et le test de restauration.
Il faut aussi nommer le point de non-retour. Tant qu'aucune commande client n'a été passée sur Sylius 2, revenir en arrière ne fait rien perdre. Dès que de vraies commandes arrivent, restaurer l'ancienne base les effacerait. Je fixe donc avec le client une règle écrite : quels critères déclenchent le retour arrière, qui décide, et jusqu'à quelle heure. Après ce moment, on corrige en avant.
Peut-on migrer progressivement plutôt qu'en une fois ?
En partie. Le dépôt officiel LegacyShopBridgePlugin permet à une application Sylius 2 d'utiliser l'ancienne boutique 1.x : il restaure les template events, des contrôleurs retirés et les blocs Sonata. On migre alors le cœur et l'administration d'abord, puis le front ensuite.
Cette option a un prix. Elle réintroduit des briques que Sylius 2 a supprimées, demande une configuration manuelle des gabarits et des assets, et la compatibilité des plugins tiers reste à vérifier un par un. C'est un pont temporaire, pas une destination. Elle vaut surtout pour un thème boutique très personnalisé dont la refonte ne tiendrait pas dans le calendrier. Pour la migration complète de l'interface, voyez le guide sur le front Bootstrap et Stimulus.
Que vérifier dans les jours qui suivent la bascule ?
Une boutique qui affiche sa page d'accueil n'est pas une boutique qui fonctionne. Je surveille en priorité les notifications du prestataire de paiement, car un webhook qui échoue laisse des commandes payées en attente. Viennent ensuite les e-mails transactionnels, puisque SwiftMailer a laissé la place à symfony/mailer, puis les intégrations qui consomment l'API, les tâches planifiées et les journaux d'erreurs.
Côté référencement, des routes ont été supprimées en 2.0 : toute URL publique qui change doit recevoir une redirection, et la Search Console doit être suivie de près. La checklist de mise en production Sylius reprend ces contrôles.
Quand faut-il accepter une coupure ?
Parfois, un gel plus long est le choix raisonnable. Si la reprise des données dure plusieurs heures malgré l'optimisation, ou si le prestataire de paiement impose une reconfiguration manuelle, mieux vaut annoncer une fenêtre de maintenance nocturne que forcer une bascule éclair risquée. L'objectif n'est pas zéro seconde d'arrêt, c'est zéro commande perdue et zéro client bloqué. Avec la fin du support de sécurité de la 1.14 le 31 décembre 2026, la tentation de précipiter la bascule existe ; elle ne justifie pas de sauter les répétitions.
La durée du gel se mesure pendant les répétitions, et la durée du chantier en amont s'estime à partir du code, comme je l'explique dans l'article sur l'estimation en jours. Pour commencer, je lance Sylius Upgrade Analyzer sur votre projet, j'identifie ce qui pèse sur la bascule (données, paiement, plugins, API) et je vous remets un diagnostic de migration offert avec une estimation en jours.