Sylius 2 : mes clients gardent-ils comptes et commandes ?

Oui, vos clients conservent leurs comptes et leurs historiques de commandes : une migration Sylius 1 vers 2 garde la base de données existante et la fait évoluer, elle ne repart pas de zéro. Adresses, commandes passées, montants, statuts et paniers enregistrés restent en place. Le seul vrai point de vigilance est la connexion : Sylius 2 change la manière de vérifier les mots de passe, et c'est ce point que je teste en priorité sur de vrais comptes avant la bascule.

Perdre l'historique d'un client fidèle, ou l'obliger à recréer un compte, est une faute que l'acheteur pardonne mal. C'est aussi un sujet de conformité, puisque ces données sont des données personnelles. Voici ce que devient chaque élément du compte client, et comment je m'assure que rien ne se perd.

Que deviennent les comptes clients pendant la migration Sylius 2 ?

Les comptes clients sont des lignes dans la base de données de votre boutique. Le chantier de migration ne les recopie pas dans un nouveau système : il applique à la base existante les migrations Doctrine prévues par Sylius pour passer au schéma de la version 2. Le guide officiel UPGRADE-2.0 indique que les migrations de la version 2.0.0 ont été regroupées et qu'elles se jouent avec la commande doctrine:migrations:migrate. La gestion des anciennes migrations de votre projet est un sujet technique à part, traité dans l'article sur les anciennes migrations Doctrine.

Concrètement, un client qui se connecte après la bascule retrouve son nom, ses adresses enregistrées, ses commandes passées avec leurs montants et leurs statuts, et son groupe de clients s'il en a un. La question plus large de la conservation de toutes les données, catalogue compris, est traitée dans l'article sur la conservation de la base de données.

Les mots de passe : le vrai point de vigilance

C'est ici que se joue l'expérience de vos clients. Sylius 2 retire le sel et l'encodeur des entités utilisateur, et s'appuie désormais sur les hacheurs de mots de passe configurés dans Symfony. Le guide officiel demande de vérifier les empreintes stockées : le nom de l'algorithme est enregistré avec chaque mot de passe, et si certains comptes anciens ne l'ont pas, il faut configurer l'option migrate_from.

Ce mécanisme est documenté par Symfony dans la section Password Migration : l'ancien algorithme reste accepté pour vérifier le mot de passe, puis, à la connexion réussie, Symfony peut re-hacher le mot de passe avec l'algorithme actuel. Le client ne voit rien, il tape son mot de passe habituel et se connecte.

Si cette configuration est oubliée ou mal faite, la conséquence est brutale : une partie de vos clients, souvent les plus anciens et donc les plus fidèles, ne peut plus se connecter. Ils doivent passer par « mot de passe oublié », et certains abandonnent. C'est pour cela que je teste la connexion sur une copie de la production avec des comptes de différentes époques, créés sous des versions successives de la boutique. Les aspects plus techniques des firewalls et des utilisateurs sont détaillés dans l'article sur les changements de sécurité de Sylius 2.

Ce qui change autour du compte client

Quelques fonctions liées au compte évoluent. Le guide officiel indique que la réinitialisation du mot de passe par code PIN a été supprimée, avec son e-mail et l'action correspondante. Si votre boutique, ou une application mobile connectée à l'API, utilisait ce parcours, il doit être remplacé par la réinitialisation par lien.

Les e-mails liés au compte changent de moteur : SwiftMailer est remplacé par symfony/mailer. L'e-mail de bienvenue, la vérification de l'adresse et le lien de réinitialisation doivent être relus et testés. Enfin, les pages de l'espace client sont reconstruites avec le nouveau thème, comme le reste du front boutique. Leur contenu reste le même, mais toute personnalisation ajoutée par votre agence, comme un suivi de colis ou un téléchargement de facture, doit être reprise.

Sylius Upgrade Analyzer, l'outil que j'ai créé et publié sur le Sylius Store, signale dans votre code l'usage de l'ancien encodeur, du sel, du parcours par code PIN et des envois SwiftMailer. Si vous voulez connaître ces points pour votre boutique avant de vous engager, c'est l'objet du diagnostic de migration offert.

Et les factures, les avoirs, les points de fidélité ?

Ces éléments ne font pas partie du cœur de Sylius : ils sont souvent fournis par des plugins. Les données restent dans la base, mais leur affichage dépend du plugin. Il faut donc vérifier, pour chacun, qu'une version compatible Sylius 2 existe et qu'elle sait toujours lire les données créées par l'ancienne version. Une facture d'il y a trois ans que le client ne peut plus télécharger est un problème réel, surtout pour une clientèle professionnelle qui en a besoin pour sa comptabilité.

Comment je vérifie que rien ne se perd

Avant la bascule, je fais des répétitions sur une copie récente de la base de production. Je compare le nombre de clients, de commandes, d'adresses et de paiements avant et après migration. Je contrôle quelques comptes réels de bout en bout : connexion, historique, détail d'une ancienne commande, téléchargement d'un document, nouvelle commande. Le jour J, c'est la base de production à jour qui est sauvegardée puis migrée, selon la méthode décrite dans l'article sur la bascule sans coupure.

Ce que je vous propose

Je lance Sylius Upgrade Analyzer sur votre projet, je repère tout ce qui touche aux comptes, aux mots de passe et aux documents clients, et je vous remets un diagnostic offert commenté avec une estimation en jours. Je vous rappelle sous 24 heures ouvrées. Les correctifs de sécurité de Sylius 1.14 s'arrêtent le 31 décembre 2026 : vos données clients méritent une migration préparée, pas improvisée.