Migration PrestaShop vers Sylius : guide & méthode pour un e-commerce B2B exigeant

Les symptômes se ressemblent d’un dossier à l’autre. Les overrides s’empilent, le tunnel de commande casse à chaque montée de version, et la moindre demande du commerce se heurte à une limite de la plateforme.

Arrive alors la question que vous vous posez peut-être aujourd’hui : faut-il migrer vers Sylius ? Dans la grande majorité des dossiers que nous instruisons, la réponse ne se joue pas sur un critère technique mais sur un calcul business.

Nous vous proposons ici ce que nous observons sur le terrain depuis 16 ans auprès des ETI industrielles et des organisations B2B : les signaux qui doivent vous alerter, ce que la migration change concrètement, et la méthode projet que nous appliquons pour la mener sans perdre le chiffre d’affaires, le référencement ni les équipes en route.

PrestaShop fait très bien son travail au démarrage. Les difficultés apparaissent plus tard, quand l’activité change d’échelle.

Votre catalogue passe de 500 à 15 000 références. Vos prix deviennent conditionnels. Vos clients B2B réclament des comptes multi-profils, des workflows de validation et des bons de commande. Votre ERP doit synchroniser stocks et tarifs en temps réel. À ce stade, sécuriser une évolution prend plus de temps que la développer.

Le coût cesse alors d’être seulement financier :

• Côté organisation : tout repose sur une ou deux personnes, le savoir reste dans les têtes, et plus personne n’ose lancer une mise à jour.
• Côté commerce : les évolutions traînent, des opportunités passent, et les concurrents équipés d’une plateforme solide avancent plus vite.
• Côté technique : les Core Web Vitals se dégradent, les overrides s’accumulent, le front reste collé au back, et rien ne s’industrialise.

Vous n’osez plus mettre à jour

C’est le signal que nous rencontrons partout. Les mises à jour sont repoussées parce que le risque perçu dépasse le bénéfice attendu. La compétence de votre équipe n’est pas en cause : ce qui manque, ce sont les tests automatisés, la chaîne d’intégration continue et un environnement de pré-production fiable. Chaque montée de version ressemble alors à un pari.

Sur nos projets Sylius, nous industrialisons ce socle dès les premières semaines, avec des tests, des analyseurs de code et un déploiement automatisé. Les mises à jour redeviennent une procédure, et non un événement.

Vos règles métier ne rentrent plus dans les cases

En B2B, les besoins qui font craquer une plateforme standard reviennent toujours : tarifs contractuels et grilles par volume, conditions par typologie de client, workflows de commande avec validation multi-rôles, devis et bons de commande, accès distincts pour l’acheteur, le valideur et l’administrateur, catalogue technique avec compatibilités, documents et historique des références.

Chez Soprofen, le catalogue de pièces détachées 4Roll demande une recherche par modèle de volet, par année de fabrication et par type de panne, tout en gardant trouvables les anciennes références du catalogue AVS Store. Nous sommes très au-delà d’un module de recherche : il s’agit de logique métier, et elle se code.

Votre SI devient le produit, et l’e-commerce son interface

Passé un certain niveau de maturité, votre e-commerce devient l’interface transactionnelle du système d’information : l’ERP pour les stocks, les prix, les conditions et la facturation, le PIM pour les données produit, le CRM pour les comptes et l’historique, sans oublier la logistique, les transporteurs, le paiement et le marketing automation.

Quand ces flux ne sont pas fiables, la facture se paie en temps passé par vos équipes, pas en tickets de bug.

Chez M-Extend, leader des chargeurs frontaux pour tracteurs, le portail B2B Sylius que nous avons développé dialogue en temps réel avec leurs ERP, PIM et CRM. Les commandes remontent directement, les stocks se synchronisent, et les prix contractuels s’affichent sans ressaisie.

Sylius est une plateforme e-commerce open source bâtie sur Symfony. Nous détaillons ses atouts sur notre page agence Sylius ; ce qui nous occupe ici, c’est ce qu’elle change le jour où vous quittez PrestaShop.

La différence tient à l’architecture. Avec un CMS classique, vous empilez des modules et des overrides au-dessus d’un noyau monolithique, jusqu’au jour où une incompatibilité fait tomber l’édifice. Avec Sylius, l’e-commerce se construit comme un produit logiciel : chaque brique est indépendante, testable et remplaçable, et vos règles métier vivent dans du code que l’on peut relire.

C’est aussi ce qui nous permet de capitaliser : nous avons développé nos propres bundles Symfony et Sylius pour les projets B2B, dont un thème Tailwind et DaisyUI open source. La tarification conditionnelle, en particulier, se modélise finement sans plugin de contournement.

Ce que le rachat de PrestaShop a changé en 2026

L’écosystème a bougé, et plus vite que prévu. Le rachat de PrestaShop par le groupe polonais cyber_Folks, via sa filiale Cyber_Pixel, a été finalisé le 18 février 2026 pour 53,7 millions d’euros, avec Sylius et BitBag associés à l’opération.

Le changement le plus parlant est humain. Mikołaj Król, dirigeant de Sylius, a pris la direction générale de PrestaShop, accompagné de Damian Murawski, cofondateur de BitBag, à l’exploitation, et d’Olivier Binet à la direction. La feuille de route présentée le 31 mars 2026 assume la priorité : réduire la dette technique, terminer la migration vers Symfony, fiabiliser les montées de version, et livrer des fonctionnalités attendues de longue date, dont le tunnel de commande en une page, le multi-transporteur et des capacités B2B.

La réorganisation avance, et le produit avec elle : PrestaShop 9.1 est sortie depuis, avec le thème Hummingbird 2.0, le support de PHP 8.5 et de Symfony 6.4 LTS, une API d’administration plus complète, et deux fonctionnalités encore expérimentales, le multi-transporteur et le nouveau gestionnaire de remises.

Les volumes ne pardonnent pas

Sur nos projets Sylius, nous avons déjà traité des catalogues de plusieurs dizaines de milliers de références, des historiques de commandes à six chiffres et des bases de configuration de plusieurs millions de lignes. À cette échelle, une migration ne se résume plus à un export suivi d’un import : elle devient un chantier de performance, de qualité de données et de stratégie de tests.

Trois choses la sécurisent : des imports batchés et incrémentaux que l’on peut rejouer, du traitement asynchrone pour les opérations lourdes (Symfony Messenger), et un plan de recette construit sur des cas métier plutôt que sur une liste de vérifications techniques.

Les fonctionnalités invisibles qui changent tout

Sur 4Roll, pour Soprofen, séparer le stock disponible et le hors stock dans une même commande n’apparaît dans aucune démonstration produit. C’est pourtant ce détail qui décide du service rendu aux artisans du réseau et des coûts logistiques. Ce sont ces arbitrages-là qui font la différence entre un portail utilisé et un portail contourné, et nous les racontons dans notre retour d’expérience sur la refonte e-commerce de Soprofen.

« On migre l’historique jusqu’à telle date. » « On garde les URLs qui performent. » « On ne change les gabarits que si le bénéfice est mesurable. » Chaque étape produit un livrable, et rien n’avance dans le flou. L’objectif est une V1 utile et stable, pas une V1 exhaustive.

Étape 1. Diagnostic et cadrage

Avant la première ligne de code, nous auditons l’existant (fonctionnalités, modules, dette technique, performance), puis nous animons des ateliers métier pour rendre explicites les règles qui ne le sont pas. En parallèle, nous cartographions les flux ERP, PIM et CRM, et nous arbitrons un périmètre de V1 réaliste.

Cette phase de cadrage AMOA est systématique chez nous. C’est l’investissement le plus rentable du projet, et celui que l’on regrette toujours d’avoir sauté.

Étape 2. Référencement et visibilité

Une bonne partie du retour sur investissement se joue ici. Nous inventorions les URLs qui performent, nous décidons de ce que l’on conserve, fusionne ou supprime, nous construisons un plan de redirections 301 testable, nous fixons les gabarits (balise title, méta-description, structure des titres, données structurées) et nous contrôlons les Core Web Vitals.

Nous vérifions aussi que vos pages de preuve, expertises, réalisations, témoignages et contact, restent cohérentes et accessibles depuis la nouvelle arborescence.

Étape 3. Le socle Sylius

Nous montons les environnements de développement, de pré-production et de production, la chaîne d’intégration et de déploiement continus, les tests et les analyseurs de code, puis les rôles et permissions du back-office. C’est là que la migration se gagne : une fois la qualité et le déploiement industrialisés, les évolutions suivantes coûtent moins cher et font courir moins de risques.

Étape 4. La reprise de données

C’est le chantier que tout le monde sous-estime. Il couvre le transactionnel (clients, adresses, commandes selon arbitrage), le catalogue (produits, variantes, attributs, taxons, médias) et les contenus marketing (pages, promotions, règles, avis).

Notre règle est simple : une reprise de données s’industrialise. Scripts d’import rejouables, table de correspondance des identifiants et des URLs, contrôles de cohérence sur les doublons, les champs obligatoires et les prix, puis un essai à blanc sur un échantillon avant la montée en charge. C’est ce qui évite de découvrir qu’un script à l’aise sur 1 000 produits s’effondre à 80 000.

Étape 5. Les fonctionnalités spécifiques

Espace client B2B et B2C, recherche à facettes, tunnel de commande multi-scénarios, interconnexions avec le SI, documents techniques. Côté architecture, nous privilégions les briques maintenables : traitements asynchrones, intégrations découplées, journalisation et traçabilité pour diagnostiquer vite une fois en exploitation.

Étape 6. Recette et mise en ligne

Recette interne d’abord, puis recette client sur les parcours critiques mis à plat. Viennent ensuite les tests de charge, la vérification du tracking et le contrôle du référencement (indexation, redirections, gabarits, Core Web Vitals). Le jour du basculement, nous déroulons une liste de contrôle préparée des semaines plus tôt.

Étape 7. La stabilisation

Nous prévoyons systématiquement quatre à huit semaines après la mise en ligne : surveillance, correctifs rapides, optimisation de la conversion et lancement de la feuille de route V2.

Cette phase décide de la suite. Une plateforme livrée puis laissée en l’état se dégrade au rythme de son écosystème, alors qu’une plateforme pilotée continue de gagner du terrain. Chez Airbus Space Digital, ce pilotage se traduit par une dizaine de fonctionnalités livrées chaque mois. Chez Tryba, il dure depuis bientôt dix ans, et les tests A/B comme l’analyse qualitative y nourrissent chaque arbitrage. C’est ce régime que nous installons après la bascule, avec de la maintenance évolutive et de l’optimisation continue pilotée par la donnée.

Après 16 ans de refontes et de migrations chez des ETI, les mêmes pièges reviennent. Nous préférons les nommer plutôt que les contourner.

Les plus coûteux tiennent en deux familles. Les pièges de périmètre d’abord : vouloir tout migrer plutôt que migrer ce qui sert, sous-estimer la qualité des données, découvrir les cas métier au moment de la recette, et traiter l’ERP, le PIM et le CRM une fois le reste terminé. Les pièges de mise en ligne ensuite : changer les URLs sans stratégie, oublier de recetter le tracking, et ne pas budgéter la stabilisation.

La parade tient dans notre façon de cadrer : ateliers métier dès le départ, plan de référencement traité comme un lot à part entière, reprise de données industrialisée, budget de stabilisation inclus au devis, et surveillance active après la bascule.

Deux objections reviennent dans presque tous les comités de pilotage.

« On migre tout l’historique, sinon ce n’est pas propre »

L’intention rassure, le résultat déçoit. Vous importez des données dont personne ne se sert, vous alourdissez le modèle, et vous payez des semaines de tests pour un bénéfice faible. La décision que nous prenons le plus souvent consiste à migrer l’utile, c’est-à-dire les clients actifs, les commandes récentes et les référentiels, puis à archiver le reste avec un accès interne.

« On refait le front et on change les URLs »

C’est la combinaison qui fait le plus de dégâts quand elle est mal cadrée. Nous stabilisons d’abord les gabarits, nous fixons les schémas d’URL, nous ne changeons que ce que nous pouvons justifier, et nous redirigeons le reste en 301.

Une migration réussie se joue rarement sur le seul talent de l’équipe de développement. Elle se joue sur la présence de trois profils autour de la table.

Le métier (ADV, commerce, logistique) tranche les cas limites, valide les règles de gestion et teste les parcours critiques. Le SI (DSI, responsable ERP, PIM ou CRM) pose les contraintes réelles, valide les flux et les formats, et sécurise l’interopérabilité. Le marketing digital (acquisition, référencement) protège la visibilité acquise, valide le plan de redirections et suit le tracking et la performance après la bascule.

Sans ces trois profils, vous obtiendrez une migration techniquement correcte et opérationnellement décevante.

• Objectifs business priorisés. Une liste d’objectifs classés, pas un inventaire de fonctionnalités.
• Règles métier écrites. Prix, rôles, workflows de validation.
• Cartographie du SI complète. ERP, PIM et CRM : flux, formats, fréquences.
• Inventaire des URLs et plan de redirections 301. Prêt et testé avant la mise en ligne.
• Stratégie de reprise de données testée. Sur un échantillon, aux volumes réels, validée par le métier.
• Plan de test complet. Fonctionnel, performance, tracking, référencement.
• Budget de stabilisation. Quatre à huit semaines après la mise en ligne.
• Équipe projet au complet. Le métier, le SI et le marketing digital.

Quand la plateforme est stable et bien intégrée au système d’information, vous pouvez investir dans ce qui fera la différence sur douze à vingt-quatre mois : automatisation marketing, contenu assisté par l’IA avec validation humaine, searchandising plus fin, et assistance conversationnelle connectée au catalogue, aux stocks et aux conditions commerciales.

L’ordre compte. Comme nous l’écrivions dans notre guide de cadrage IA, l’IA ne compense jamais une base de données mal structurée : c’est la migration qui rend ces briques possibles, pas l’inverse.