Étiquette : E-commerce

Migration Sylius 1.x vers Sylius 2 : quand migrer et comment préparer son projet ?

Posted on by Dev Cyllene
Migration d’un projet e-commerce Sylius 1.x vers Sylius 2

Vous avez un projet e-commerce sous Sylius 1.x et vous vous demandez s’il est temps de passer à Sylius 2 ? La migration ne consiste pas simplement à mettre à jour une version. Selon votre architecture, vos développements spécifiques, vos plugins et vos intégrations avec le système d’information, elle peut nécessiter une adaptation plus ou moins importante de la plateforme.

Avant de migrer, il est donc essentiel d’auditer l’existant pour identifier ce qui peut être conservé, ce qui doit être adapté et ce qui peut être repensé.

à retenir

Faut-il migrer vers Sylius 2 ?
Oui, il est pertinent de préparer la migration d’un projet encore sous Sylius 1.x, notamment parce que Sylius 1.14 est désormais en phase de correctifs de sécurité uniquement. Mais la bonne trajectoire dépend de l’état réel de votre plateforme.

Faut-il refaire son e-commerce ?
Non. Une migration Sylius 2 ne nécessite pas systématiquement de repartir de zéro. Une partie des développements, données, parcours et intégrations peut être conservée si l’architecture le permet.

Quels sont les principaux points de vigilance ?
Les plugins, développements spécifiques, dépendances techniques, frontend, données et connexions avec l’ERP, PIM, CRM, WMS ou les solutions de paiement doivent être analysés avant la migration.

La migration peut-elle être l’occasion de faire évoluer la plateforme ?
Oui. Lorsque l’existant présente une dette technique ou que les besoins métier ont évolué, le passage à Sylius 2 peut être l’occasion de moderniser l’architecture, améliorer les performances et préparer les prochaines évolutions du e-commerce.

La première étape consiste donc à définir une trajectoire adaptée à votre projet : migrer, adapter, refactorer ou faire évoluer certaines briques plutôt que de reproduire automatiquement l’existant.

Votre projet Sylius 1.x arrive à un tournant

Un projet Sylius peut rester performant pendant plusieurs années. Mais les évolutions successives peuvent progressivement complexifier son architecture : développements spécifiques, plugins, dépendances, intégrations avec le système d’information ou règles métier historiques.

La question de la migration devient alors stratégique.

Sylius 1.14, dernière version de la branche 1.x, bénéficie désormais uniquement de correctifs de sécurité jusqu’en décembre 2026.

Pour les entreprises qui exploitent un e-commerce métier, l’enjeu n’est donc pas simplement de « passer à Sylius 2 », mais de déterminer comment faire évoluer la plateforme sans fragiliser l’existant.

Quand faut-il envisager une migration ?

À analyserQuestions à se poser
Code & architectureQuels développements spécifiques doivent être adaptés ?
PluginsSont-ils compatibles, maintenus ou à remplacer ?
DépendancesQuelles évolutions de PHP, Symfony et des composants sont nécessaires ?
FrontendPeut-il être conservé ou doit-il évoluer ?
DonnéesQuelles adaptations ou migrations sont nécessaires ?
Système d’informationLes flux ERP, PIM, CRM, WMS et paiement restent-ils compatibles ?
TestsLes parcours critiques sont-ils suffisamment couverts ?

Migration ou refonte : il ne faut pas forcément choisir

Une migration Sylius 2 peut suivre plusieurs trajectoires :

Migration de l’existant
Lorsque l’architecture est saine et que les besoins métier sont relativement stables.

Migration + évolution
Lorsque certaines briques doivent être modernisées ou que de nouvelles fonctionnalités sont prévues.

Refonte partielle ou complète
Lorsque l’architecture est devenue trop complexe, difficile à maintenir ou ne correspond plus aux enjeux actuels.

L’objectif n’est donc pas de reconstruire systématiquement votre e-commerce, mais de conserver ce qui crée de la valeur et de faire évoluer ce qui limite désormais votre plateforme.

Sylius 2 : transformer une migration technique en projet d’évolution

Le passage à Sylius 2 peut être l’occasion de repartir sur une base plus saine et de préparer les prochaines étapes de votre e-commerce.

La démarche peut être résumée en quatre étapes :

1. Auditer

Analyser la version actuelle de Sylius, l’architecture, les plugins, les développements spécifiques, les dépendances et les intégrations SI.

2. Arbitrer

Déterminer ce qui peut être conservé, adapté, remplacé ou repensé.

3. Migrer

Adapter les composants concernés et sécuriser les parcours critiques à travers les tests et la recette.

4. Faire évoluer

Profiter de cette nouvelle base pour traiter les évolutions métier : nouveaux parcours, performance, B2B, marketplace, multi-store ou nouvelles intégrations.

Une migration Sylius 2 réussie est donc une migration adaptée à votre projet, et non l’application d’une recette standard.

Vous avez déjà un projet Sylius ? Cyllene peut partir de l’existant

Cyllene accompagne aussi les entreprises qui disposent déjà d’une plateforme Sylius et souhaitent la faire évoluer.

Notre intervention peut couvrir :

  • Audit de l’existant : architecture, code, plugins, dépendances et intégrations ;
  • Définition de la trajectoire : migration, refactoring, évolution ou refonte ;
  • Migration et sécurisation : adaptations techniques, tests et recette ;
  • Évolutions métier : nouveaux parcours, fonctionnalités, performance et intégrations SI.

Cette approche permet également de reprendre un projet développé par une autre agence : l’objectif est d’abord de comprendre l’existant avant de décider ce qui doit évoluer.

Notre équipe Web à taille humaine réunit chefs de projet, experts UX/UI et développeurs Sylius/Symfony, avec la possibilité de mobiliser les expertises complémentaires du groupe en infrastructure, hébergement, cybersécurité, data ou IA.

Echanger avec un expert

Conclusion

Une migration Sylius 1.x vers Sylius 2 ne signifie pas nécessairement une refonte complète.

La bonne trajectoire dépend de votre version actuelle, de votre architecture, de vos plugins, de vos développements spécifiques et de votre système d’information.

L’audit permet de répondre à trois questions essentielles :

  • Que pouvons-nous conserver ?
  • Que devons-nous adapter ?
  • Que pouvons-nous améliorer ?

C’est à partir de ces réponses que peut être construit un plan de migration réaliste, maîtrisé et cohérent avec les évolutions futures de votre e-commerce.

Vous envisagez de migrer votre projet Sylius vers Sylius 2 ?

Commencez par identifier les impacts sur votre plateforme avant de lancer les développements.

Nos équipes peuvent auditer votre projet Sylius et vous aider à définir la trajectoire adaptée : migration, évolution, refactoring ou refonte. Demander un diagnostic de votre projet Sylius via le formulaire ci-dessous.

Quand passer d’une solution e-commerce standard à Sylius ?

Posted on by Dev Cyllene
Quand passer d’une solution e-commerce standard à Sylius ?

Votre solution e-commerce fonctionne, mais vos besoins évoluent. Faut-il continuer à faire évoluer l’existant ou envisager Sylius ?

Il n’existe pas de réponse universelle. Une solution standard reste pertinente lorsque les besoins sont courants, les règles métier simples et l’écosystème technique stable. À l’inverse, Sylius devient particulièrement intéressant lorsque le e-commerce doit porter des règles métier différenciantes, s’intégrer profondément au système d’information ou offrir davantage de maîtrise sur son architecture.

L’enjeu n’est donc pas de savoir si Sylius est « meilleur » qu’une solution standard. Il s’agit de déterminer à quel moment les besoins de l’entreprise justifient un socle plus flexible et plus personnalisable.

à retenir

  • Une solution standard reste pertinente pour des besoins e-commerce courants et peu différenciants.
  • Il n’est pas nécessaire de migrer vers Sylius uniquement parce que l’entreprise grandit.
  • Sylius devient pertinent lorsque les règles métier, les intégrations ou l’architecture deviennent structurantes.
  • La multiplication des contournements et développements spécifiques peut signaler que la plateforme actuelle n’est plus adaptée.
  • Le choix doit prendre en compte le métier, le SI, les performances, le TCO et la roadmap, pas uniquement les fonctionnalités du CMS.
  • Avant une migration, il faut comparer plusieurs trajectoires : optimiser l’existant, moderniser progressivement ou changer de plateforme.

Quand rester sur une solution e-commerce standard ?

Une solution standard peut parfaitement répondre aux besoins d’une entreprise lorsque son modèle commercial reste relativement simple.

Elle est notamment adaptée si :

  • le catalogue et les règles de prix sont standards ;
  • le parcours de commande ne nécessite pas de logique particulière ;
  • les besoins B2B restent limités ;
  • les intégrations avec l’ERP, le PIM ou le CRM sont simples et stables ;
  • les fonctionnalités nécessaires existent nativement ou via des extensions fiables ;
  • les évolutions peuvent être réalisées sans multiplier les développements spécifiques ;
  • la roadmap business reste compatible avec les capacités de la plateforme.

Dans ce contexte, changer de technologie apporterait parfois davantage de complexité que de valeur.

Une migration vers Sylius ne doit donc pas être considérée comme une étape obligatoire de la croissance d’un e-commerce.

Le sujet devient différent lorsque l’entreprise commence à adapter régulièrement son fonctionnement aux contraintes de sa plateforme.

Les premiers signaux qu’il est temps d’étudier Sylius

1. Vos règles métier deviennent un avantage concurrentiel

Votre e-commerce ne se contente plus de vendre un produit au prix affiché. Vous devez gérer, par exemple :

  • des tarifs différents selon les clients ;
  • des catalogues spécifiques ;
  • des comptes professionnels avec plusieurs utilisateurs ;
  • des règles de validation de commande ;
  • des workflows particuliers ;
  • des conditions commerciales négociées ;
  • des règles de disponibilité ou de livraison spécifiques.

Ces règles peuvent être essentielles au fonctionnement de l’entreprise.

Lorsqu’elles deviennent difficiles à implémenter avec les fonctionnalités natives de la plateforme, le problème n’est plus simplement fonctionnel : le socle technique peut commencer à contraindre le modèle commercial.

C’est l’un des contextes dans lesquels Sylius prend tout son intérêt. La plateforme est conçue comme un socle e-commerce flexible et personnalisable, permettant de construire les fonctionnalités nécessaires au projet sans repartir de zéro.

2. Les contournements se multiplient

Un autre signal est plus insidieux : votre site fonctionne, mais de moins en moins naturellement.

  • Une fonctionnalité nécessite un module.
  • Puis un développement spécifique.
  • Puis un second module pour faire fonctionner le premier.
  • Puis un contournement pour répondre à une incompatibilité.

À terme, chaque évolution demande davantage d’analyse, de tests et de maintenance.

Le problème n’est pas forcément le nombre de modules. C’est l’écart qui se creuse entre le fonctionnement attendu par l’entreprise et celui imposé par la plateforme.

Si cette situation vous parle, notre article sur les 10 signes qu’un CMS e-commerce freine votre croissance peut vous aider à objectiver le niveau de friction.

3. Votre e-commerce devient une brique stratégique du SI

Un e-commerce complexe ne fonctionne pas seul. Il doit échanger avec le :

  • ERP ;
  • PIM ;
  • CRM ;
  • WMS ;
  • système de pricing ;
  • gestion des stocks ;
  • outils marketing ;
  • marketplaces ou autres canaux.

Lorsque ces flux deviennent structurants, la question n’est plus seulement « quelles fonctionnalités propose mon CMS ? ».

Elle devient : Quelle place mon e-commerce doit-il occuper dans mon système d’information ?

Une architecture plus ouverte et personnalisable peut alors devenir pertinente.

C’est notamment l’approche mise en œuvre par Cyllene sur le projet Innelec : plateforme B2B basée sur Sylius, architecture API-first et intégrations avec le PIM, le CRM et SAGE.

4. Vous devez maîtriser davantage votre architecture

Certaines entreprises arrivent à un moment où elles veulent davantage de contrôle sur leur plateforme :

  • architecture technique ;
  • données ;
  • règles métier ;
  • évolutions ;
  • intégrations ;
  • performance ;
  • hébergement ;
  • dépendances vis-à-vis d’extensions ou d’éditeurs.

Sylius peut être pertinent dans ce contexte car il fournit un socle e-commerce open source basé sur Symfony, conçu pour être adapté à l’architecture et aux besoins du projet.

Mais cette liberté implique aussi davantage de responsabilités. Sylius n’est donc pas nécessairement le meilleur choix pour une entreprise qui recherche avant tout une solution prête à l’emploi avec un minimum de développement spécifique.

5. Votre roadmap évolue plus vite que votre plateforme

Vous prévoyez :

  • un nouveau modèle B2B ;
  • plusieurs pays ;
  • plusieurs marques ;
  • de nouveaux canaux ;
  • une nouvelle expérience client ;
  • de nouvelles intégrations ;
  • des parcours différents selon les profils.

Et chaque évolution nécessite de vérifier si la plateforme actuelle peut suivre.C’est souvent le véritable déclencheur.

Le bon moment pour étudier Sylius n’est pas lorsque votre plateforme est complètement bloquée. C’est lorsque vous constatez qu’elle risque de le devenir au regard de votre roadmap.

Standard ou Sylius : comment arbitrer ?

Votre situationSolution standardSylius
Besoins e-commerce courants✅ PertinentPossible, mais souvent inutile
Catalogue et prix simples✅ PertinentPossible
Règles métier spécifiques⚠️ À évaluer✅ Pertinent
B2B avec règles commerciales avancées⚠️ Limites possibles✅ Très pertinent
ERP/PIM/CRM fortement intégrés⚠️ À évaluer✅ Pertinent
Nombreux développements spécifiques⚠️ Risque de complexité✅ À étudier
Architecture API-first / headless⚠️ Selon solution✅ Pertinent
Forte maîtrise de l’architecture recherchée⚠️ Variable✅ Pertinent
Projet simple et rapide à déployer✅ Pertinent❌ Souvent disproportionné

Le critère déterminant n’est donc pas la taille de l’entreprise. C’est la complexité du modèle e-commerce et de son environnement.

Faut-il forcément migrer vers Sylius ?

Non. C’est même une question essentielle à se poser avant de lancer un projet de migration.

Trois scénarios peuvent être comparés :

1. Optimiser l’existant
La plateforme répond encore aux besoins et les limites peuvent être corrigées sans remettre en cause l’architecture.

2. Moderniser progressivement
Certaines briques peuvent être refondues ou découplées sans changer immédiatement toute la plateforme.

3. Repenser le socle e-commerce
Les contraintes métier, les intégrations et la roadmap justifient une nouvelle architecture. Sylius peut alors constituer une option pertinente.

Cette logique rejoint l’approche que Cyllene applique dans ses projets de replatforming : analyser l’existant avant de déterminer la trajectoire technique la plus adaptée.

Sylius n’est pas une fin en soi

Choisir Sylius uniquement parce qu’il est plus flexible que votre solution actuelle serait une mauvaise raison.

La question doit plutôt être : Quels besoins notre plateforme actuelle ne nous permet-elle plus de traiter correctement ? 

Puis : Ces besoins justifient-ils réellement une nouvelle architecture ?

C’est cette analyse qui permet d’éviter deux erreurs opposées : rester trop longtemps sur une plateforme qui freine le développement ou migrer vers une solution plus complexe sans besoin réel.

Sur le projet Bollinger, par exemple, le choix de Sylius répondait à des enjeux métier précis : simplification de l’administration, intégration du catalogue, optimisation des processus logistiques et personnalisation des processus métier.

Comment Cyllene vous aide à faire le bon choix ?

Le rôle d’un intégrateur ne devrait pas être de recommander systématiquement la technologie qu’il maîtrise. Il doit d’abord comprendre :

  • votre modèle commercial ;
  • vos règles métier ;
  • votre système d’information ;
  • vos contraintes techniques ;
  • votre roadmap ;
  • vos enjeux UX, SEO et performance ;
  • et le niveau de maîtrise que vous souhaitez conserver sur votre plateforme.

C’est précisément l’approche portée par Cyllene : accompagner des projets e-commerce B2B, B2C ou hybrides, en combinant expertise Sylius, architecture, UX/UI, développement et intégration au SI.

L’équipe Web s’appuie également sur les expertises complémentaires du groupe, qui compte plus de 400 experts dans les métiers du numérique.

L’objectif n’est donc pas de vous convaincre de passer à Sylius, mais de déterminer si Sylius est réellement le bon socle pour votre prochaine étape.

Echanger avec un expert

Conclusion

Passer d’une solution e-commerce standard à Sylius devient pertinent lorsque la complexité du métier, du SI ou de la roadmap justifie davantage de liberté architecturale.

Restez sur votre solution actuelle si elle répond efficacement à vos besoins et évolue sans friction excessive.

Envisagez Sylius lorsque les règles métier deviennent différenciantes, que les contournements se multiplient, que les intégrations deviennent structurantes ou que votre plateforme limite vos évolutions.

Le bon choix n’est pas nécessairement de changer de plateforme. C’est de choisir une architecture capable d’accompagner votre stratégie e-commerce.

Checklist migration Sylius : les contrôles à ne pas oublier

Posted on by Dev Cyllene
checklist-migration-sylius

Migrer un site e-commerce vers Sylius ne consiste pas uniquement à reprendre un catalogue et à refaire le front. Une migration peut impacter le SEO, les données clients, les commandes, les prix, les stocks, les flux ERP/PIM/CRM, le paiement, le tracking et les performances.

Pour éviter les mauvaises surprises au moment de la mise en production, voici les principaux contrôles à prévoir avant, pendant et après une migration Sylius.

à retenir

  • Une migration e-commerce doit couvrir à la fois les données, les flux, les parcours métier et le SEO.
  • Les redirections 301 et la reprise des données ne suffisent pas : il faut tester les échanges avec le SI.
  • La recette doit reproduire les principaux scénarios réels du site.
  • Un plan de rollback et un monitoring post-mise en ligne sont indispensables.
  • Plus le SI est complexe, plus la migration doit être préparée comme un projet d’intégration, et pas comme un simple changement de plateforme.
Téléchargez la checklist migration Sylius : 20 contrôles à valider avant la mise en production

1. SEO : protéger l’existant avant de migrer

Une migration Sylius peut être l’occasion d’améliorer la structure du site, mais elle peut aussi provoquer une perte de trafic si les fondamentaux SEO ne sont pas anticipés.

Avant la bascule, il faut notamment identifier les pages générant du trafic organique, les pages stratégiques et les principales URLs indexées.

À contrôler :

  • pages indexées et pages générant du trafic ;
  • titles, meta descriptions et H1 ;
  • balises canonical ;
  • sitemap XML et robots.txt ;
  • données structurées lorsque nécessaire ;
  • profondeur des pages et maillage interne.

L’objectif n’est pas nécessairement de conserver chaque élément à l’identique, mais de maîtriser ce qui change.

Pour aller plus loin, consultez notre guide sur la migration e-commerce sans perte SEO.

2. URLs et redirections : préparer le mapping avant la bascule

Si les URLs évoluent avec Sylius, il faut établir un mapping entre les anciennes et les nouvelles URLs.

Les redirections 301 doivent être définies avant la mise en production, puis testées.

Une attention particulière doit être portée aux :

  • fiches produits ;
  • catégories ;
  • pages éditoriales ;
  • anciennes URLs stratégiques ;
  • URLs supprimées ou fusionnées.

Il faut également éviter les chaînes de redirections et les redirections généralisées vers la homepage.

3. Catalogue : ne pas se limiter au nombre de produits

Une reprise catalogue réussie ne signifie pas seulement que “tous les produits sont là”.

Il faut contrôler les produits, variantes, catégories, attributs, médias, statuts, références et éventuelles données spécifiques au métier.

Le contrôle doit également porter sur les règles qui déterminent ce qui est affiché et vendu sur le site.

Dans un environnement connecté à un PIM, il faut notamment tester les flux de création, modification et suppression.

Notre article sur l’intégration de Sylius avec un ERP ou un PIM détaille les principaux points de vigilance.

4. Clients : reprendre les bonnes données

La migration doit définir précisément quelles données clients sont reprises :

  • comptes ;
  • coordonnées ;
  • adresses ;
  • groupes ;
  • données B2B ;
  • historiques utiles ;
  • préférences et consentements selon le périmètre.

La gestion des mots de passe mérite une attention particulière. Selon l’architecture de départ, leur reprise peut nécessiter une stratégie spécifique et un parcours de réactivation.

Pour un site B2B, il faut également tester les comptes sociétés, les rôles utilisateurs et les éventuelles règles d’accès.

5. Commandes : penser historique et nouveaux flux

L’historique des commandes doit être traité selon les besoins métier et les contraintes du projet.

Mais le point le plus important concerne surtout les nouvelles commandes après migration.

Il faut tester le parcours complet : visite → panier → commande → paiement → transmission au SI → préparation → livraison → changement de statut.

Une commande qui fonctionne sur le front mais qui n’est pas correctement transmise à l’ERP constitue évidemment un échec de migration.

6. Prix, promotions et règles commerciales

Le prix affiché doit être contrôlé dans tous les contextes prévus par le projet.

Selon le modèle commercial, cela peut inclure :

  • prix catalogue ;
  • tarifs négociés ;
  • prix par groupe ou compte client ;
  • remises ;
  • promotions ;
  • règles B2B ;
  • prix selon le pays ou le canal.

Pour un modèle B2B/B2C, la recette doit notamment vérifier qu’un même produit peut être proposé selon des conditions commerciales différentes, sans créer de conflit dans les données ou les flux.

7. Stocks et disponibilité

Le stock doit être testé de bout en bout.

Il faut vérifier :

  • la source de vérité du stock ;
  • la fréquence de synchronisation ;
  • les stocks par canal ou entrepôt ;
  • les règles de disponibilité ;
  • les mises à jour après commande ;
  • les cas d’erreur ou de rupture de flux.

Un stock correct dans Sylius mais incorrect dans l’ERP peut rapidement générer des commandes impossibles à honorer.

8. ERP, PIM et CRM : tester les flux, pas seulement les connexions

C’est souvent ici que se situe une grande partie de la complexité d’une migration e-commerce. La présence d’une API ou d’un connecteur ne signifie pas que l’intégration est correctement fonctionnelle.

Pour chaque flux, il faut définir :

source → données transmises → fréquence → transformation → destination → retour éventuel

Les principaux flux peuvent concerner les produits, prix, stocks, clients, commandes, factures, statuts ou données marketing.

Dans une architecture API-first, cette cartographie devient particulièrement importante car le e-commerce peut jouer le rôle de moteur connecté à plusieurs briques du SI.

9. Paiement et livraison

Chaque moyen de paiement doit être testé dans les principaux scénarios :

  • paiement accepté ;
  • paiement refusé ;
  • abandon ;
  • remboursement ;
  • retour de statut ;
  • erreur technique.

Même logique pour la livraison : zones, tarifs, transporteurs, règles de disponibilité et statuts doivent être vérifiés.

Une migration n’est réellement validée que lorsque le parcours transactionnel complet fonctionne.

10. Tracking et analytics

Le changement de plateforme peut casser une partie du tracking existant. Avant la mise en ligne, il faut inventorier puis tester :

  • Analytics ;
  • Google Tag Manager ;
  • événements ;
  • conversions ;
  • campagnes ;
  • pixels publicitaires ;
  • consentement ;
  • remontées e-commerce.

Il est également utile de comparer les données avant et après migration afin d’identifier rapidement une rupture de mesure.

11. Performance

Une migration vers Sylius doit aussi être l’occasion de vérifier les performances réelles du site. À mesurer notamment :

  • temps de réponse serveur ;
  • Core Web Vitals ;
  • temps de chargement des pages clés ;
  • performances du panier et du checkout ;
  • comportement lors des pics de trafic ;
  • charge générée par les appels aux systèmes externes.

La performance doit être testée dans des conditions représentatives, et pas uniquement sur une page isolée.

12. Sécurité

Avant la mise en production, contrôler notamment :

  • droits et rôles ;
  • accès aux environnements ;
  • secrets et clés API ;
  • certificats ;
  • sauvegardes ;
  • dépendances ;
  • exposition des interfaces ;
  • journalisation et monitoring.

Une migration est aussi un bon moment pour supprimer les anciens accès et composants devenus inutiles.

13. Recette : tester des parcours, pas uniquement des fonctionnalités

La recette doit reproduire les usages réels. Par exemple, plutôt que de tester séparément “ajouter au panier” et “payer”, il est préférable de tester un scénario complet :

un client B2B se connecte → consulte son catalogue → bénéficie de son tarif → commande → paie → la commande est transmise à l’ERP.

Les scénarios doivent couvrir les différents profils, pays, canaux et règles métier réellement utilisés.

14. Monitoring et rollback : prévoir l’après-migration

La migration ne s’arrête pas au moment où le site devient accessible. Les premiers jours doivent faire l’objet d’une surveillance renforcée :

  • erreurs 404 ;
  • erreurs serveur ;
  • commandes ;
  • paiements ;
  • flux ERP/PIM/CRM ;
  • trafic ;
  • indexation ;
  • performances.

Et surtout, un plan de rollback doit être défini avant la bascule : qui décide, dans quelles conditions et selon quelle procédure revenir à l’environnement précédent ?

La checklist migration Sylius à télécharger

Ces 20 contrôles constituent un socle pour préparer une migration e-commerce vers Sylius. Pour ne rien oublier, nous avons regroupé les principaux points de contrôle dans une checklist migration Sylius téléchargeable : SEO, URLs, catalogue, clients, commandes, prix, stocks, ERP, PIM, CRM, paiement, livraison, tracking, performance, sécurité, recette, monitoring et rollback.

Téléchargez la checklist migration Sylius : 20 contrôles à valider avant la mise en production

Une migration Sylius est aussi un projet d’intégration

Plus un e-commerce est connecté à son système d’information, plus la migration dépasse le simple changement de plateforme.

Le véritable enjeu consiste à préserver les données, les règles commerciales, les parcours clients et les flux qui font fonctionner le commerce au quotidien.

C’est notamment le cas des projets B2B ou B2B/B2C combinant ERP, PIM, CRM, règles tarifaires, stocks et processus métier spécifiques.

Chez Cyllene, cette approche s’inscrit dans une expertise Sylius dédiée aux projets e-commerce complexes, avec des compétences Web, architecture, développement, DevOps et production.

Besoin d’évaluer votre projet de migration ? Notre équipe peut réaliser un premier diagnostic de votre architecture, de vos flux et des principaux risques de migration.

Parler à un expert e-commerce

Découvrez notre réalisation B2B sous Sylius : Projet Innelec

Sylius B2B/B2C : gérer plusieurs modèles commerciaux

Posted on by Dev Cyllene
Sylius B2B/B2C : gérer plusieurs modèles commerciaux

Une même entreprise peut vendre aux particuliers et aux professionnels, partager un catalogue tout en appliquant des prix différents, ou encore proposer des parcours distincts selon le profil du client.

Ce type de modèle hybride devient rapidement complexe lorsqu’il faut également connecter le e-commerce à un ERP, un PIM, un CRM ou plusieurs canaux de vente.

Sylius permet de construire ces différents modèles commerciaux autour d’un même socle, avec des règles et des parcours adaptés aux besoins de l’entreprise.

à retenir

  • Un même e-commerce peut servir des clients B2B et B2C avec des règles commerciales différentes.
  • Le catalogue peut être commun, tout en proposant des prix, remises ou conditions spécifiques selon le client.
  • Les parcours B2B peuvent intégrer comptes entreprises, rôles, validations, commandes spécifiques ou demandes de devis.
  • Sylius permet de construire ces règles métier sur mesure plutôt que de multiplier les contournements.
  • L’enjeu devient particulièrement important lorsque le e-commerce doit communiquer avec un ERP, un PIM, un CRM ou plusieurs canaux.
  • Pour les entreprises hybrides, le choix de la plateforme doit donc se faire à partir du modèle commercial et du système d’information, pas uniquement des fonctionnalités e-commerce disponibles.

Pourquoi les modèles B2B et B2C sont-ils difficiles à faire cohabiter ?

Un site B2C classique peut fonctionner avec un catalogue, un prix public, un panier et un parcours de commande relativement standardisé.

Le B2B introduit généralement davantage de règles :

  • tarifs négociés ;
  • remises selon les volumes ;
  • catalogues spécifiques ;
  • comptes entreprises ;
  • plusieurs utilisateurs par compte ;
  • droits et permissions ;
  • validation des commandes ;
  • minimums de commande ;
  • conditions de livraison ou de paiement ;
  • demandes de devis ;
  • commandes récurrentes.

Une entreprise qui combine B2B et B2C doit alors faire cohabiter plusieurs logiques commerciales au sein d’une même plateforme.

Le défi n’est pas simplement de proposer deux types de comptes. Il consiste à déterminer quelles données, quelles règles et quels parcours doivent être communs ou différenciés.

Un même catalogue, mais pas nécessairement les mêmes prix

C’est l’un des cas les plus fréquents dans les modèles hybrides. Une entreprise peut disposer d’un catalogue produit commun à ses différents marchés, tout en appliquant des conditions commerciales différentes. Par exemple :

  • Client particulier : Prix public, promotions, paiement immédiat et parcours B2C.
  • Client professionnel : Tarif négocié, remise selon le volume, conditions contractuelles et possibilité de commande au nom d’une entreprise.

Le produit reste le même, mais la règle de prix dépend du contexte commercial.

La plateforme doit donc être capable de déterminer quel prix afficher et quelles règles appliquer selon le profil du client, son contrat, son volume d’achat ou son organisation.

Avec Sylius, ces logiques peuvent être développées spécifiquement pour correspondre au modèle commercial de l’entreprise.

Des parcours différents pour un même produit

Le modèle hybride ne concerne pas uniquement le prix. Le parcours de commande peut lui aussi varier.

Un particulier pourra ajouter un produit au panier et finaliser immédiatement son achat.

Un utilisateur professionnel pourra, selon son rôle :

  • ajouter plusieurs produits à une commande ;
  • demander un devis ;
  • soumettre une commande à validation ;
  • appliquer un centre de coûts ;
  • commander pour le compte d’une entreprise ;
  • retrouver ses commandes précédentes ;
  • bénéficier de conditions de livraison spécifiques.

La plateforme doit donc gérer des parcours différents sans nécessairement dupliquer tout le catalogue ou toute l’application.

C’est là que l’architecture devient déterminante.

Sylius comme socle pour plusieurs modèles commerciaux

L’intérêt de Sylius dans ce type de projet réside dans sa capacité de personnalisation.

Plutôt que de chercher à faire entrer tous les cas métier dans un fonctionnement standard, l’entreprise peut construire ses propres règles autour du socle e-commerce.

Cela peut concerner :

  • le pricing ;
  • les promotions ;
  • les comptes clients ;
  • les droits utilisateurs ;
  • les catalogues ;
  • les workflows ;
  • les commandes ;
  • les règles de livraison ;
  • les moyens de paiement ;
  • les parcours de validation.

Cette approche est particulièrement pertinente lorsque les règles commerciales constituent une partie importante de la valeur du e-commerce.

Elle rejoint également la logique API-first e-commerce : le moteur e-commerce peut communiquer avec les différentes briques du système d’information tout en faisant évoluer les différents composants de manière plus indépendante.

Et lorsque le catalogue est piloté par le PIM ou l’ERP ?

Dans une entreprise hybride, le e-commerce n’est généralement pas la seule source de données.

  • Le PIM peut gérer les informations produit.
  • L’ERP peut porter les stocks, les tarifs, les commandes ou certaines règles de gestion.
  • Le CRM peut centraliser les informations clients et commerciales.
  • Le e-commerce doit alors orchestrer ces données pour proposer une expérience cohérente aux différents profils.

Par exemple :

PIM → e-commerce
Produits, attributs, catégories, médias.

ERP → e-commerce
Stocks, tarifs, disponibilités, informations logistiques.

CRM → e-commerce
Clients, contacts, comptes professionnels.

E-commerce → ERP
Commandes, statuts et informations nécessaires aux traitements opérationnels.

Cette dimension devient particulièrement importante dans les projets où le e-commerce doit s’intégrer au cœur du SI. Notre guide sur l’intégration de Sylius avec un ERP ou un PIM détaille les principaux enjeux de ces architectures.

B2B + B2C : faut-il vraiment tout mutualiser ?

Pas nécessairement. L’objectif n’est pas de construire une expérience identique pour tous les clients. Il est plutôt de déterminer ce qui peut être mutualisé et ce qui doit rester spécifique.

Ce qui peut être partagé

Selon le projet :

  • catalogue produit ;
  • données produit ;
  • stocks ;
  • moteur de recherche ;
  • contenus ;
  • certaines briques du tunnel ;
  • commandes et données de référence ;
  • connexions avec le SI.

Ce qui peut être différencié

Selon le modèle commercial :

  • prix ;
  • promotions ;
  • droits utilisateurs ;
  • parcours de commande ;
  • moyens de paiement ;
  • conditions de livraison ;
  • validation des commandes ;
  • fonctionnalités du compte client.

Cette distinction permet d’éviter deux écueils : construire deux plateformes totalement indépendantes alors qu’une partie du socle pourrait être mutualisée, ou au contraire forcer des parcours B2B et B2C très différents dans un fonctionnement unique.

Plusieurs canaux : quand le modèle devient encore plus complexe

Le modèle hybride peut également s’étendre à plusieurs canaux de vente. Un même moteur e-commerce peut alimenter :

  • un site B2C ;
  • un portail B2B ;
  • une application ;
  • un espace client ;
  • des marketplaces ;
  • ou d’autres interfaces métier.

Dans ce contexte, une architecture API-first ou headless peut permettre de dissocier le moteur e-commerce des différentes expériences front-end.

Mais le headless n’est pas une finalité en soi. Comme expliqué dans notre article Qu’est-ce que le headless commerce ?, cette architecture apporte surtout de la valeur lorsque les besoins justifient cette séparation.

Innelec : un exemple de B2B complexe intégré au SI

innelec projet sylius

Ce projet B2B complexe sous Sylius illustre le type de complexité pour lequel cette approche prend tout son sens.

L’entreprise Innelec disposait de plus de 7 000 références et souhaitait moderniser sa plateforme B2B sous Magento 2.3.

La nouvelle plateforme repose sur Sylius, une architecture API-first et un développement 100 % sur mesure.

Elle échange notamment avec le PIM pour les données produits, le CRM pour les clients et contacts, ainsi qu’avec SAGE via un middleware spécifique pour les tarifs, taxes, transport et commandes.

Le projet devait également absorber des pics de trafic saisonniers et fonctionner 24/7.

Le sujet n’était donc pas simplement de créer un nouveau site e-commerce : il s’agissait de construire une brique e-commerce capable de s’intégrer au système d’information et de porter les règles métier de l’entreprise.

Bollinger : des règles métier au cœur du projet

bollinger projet Sylius

Le projet Bollinger constitue un autre exemple de plateforme B2B développée sous Sylius.

Le projet intègre notamment une synchronisation des produits en temps réel et un suivi des commandes, avec une architecture adaptée aux besoins spécifiques de l’entreprise.

Ce type de projet montre que la complexité d’un e-commerce ne se mesure pas uniquement au nombre de produits ou au trafic.

Elle peut surtout venir de la combinaison entre modèle commercial, processus métier, intégrations et parcours utilisateurs.

Quand Sylius devient-il pertinent pour un modèle hybride ?

Sylius devient particulièrement intéressant lorsque plusieurs de ces critères sont réunis :

SituationCe qu’il faut gérerSylius est-il pertinent ?
B2B + B2C avec catalogue communPrix, comptes, parcours et règles différentsOui
B2B + B2C avec tarifs négociésPrix par client, contrats, remises, conditions commercialesOui, particulièrement
B2B + B2C + ERP/PIMSynchronisation catalogue, stocks, commandes, clientsOui, particulièrement
B2B + B2C + règles métier avancéesValidation de commande, rôles, seuils, workflowsOui, particulièrement
B2B + B2C + plusieurs paysDevises, langues, fiscalité, catalogues et règles localesOui
B2B + B2C + plusieurs canauxSite, application, marketplaces, extranet…Oui, si l’architecture est pensée pour cela

Pour un projet essentiellement standard, une solution e-commerce plus directement configurable peut parfaitement convenir.

En revanche, lorsque plusieurs règles métier et plusieurs systèmes doivent fonctionner ensemble, la flexibilité de l’architecture devient un véritable critère de choix.

Le vrai sujet : adapter le e-commerce au modèle commercial

Pour une entreprise hybride, la question n’est finalement pas :

« Comment faire du B2B et du B2C sur le même site ? »

Mais plutôt : « Quelle architecture permet de faire fonctionner nos différents modèles commerciaux sans complexifier inutilement notre système d’information ? »

C’est cette question qui doit guider le choix de la plateforme, le niveau de personnalisation et les arbitrages entre standard et sur-mesure.

Sylius est particulièrement pertinent lorsque le e-commerce doit s’adapter aux règles métier de l’entreprise, tout en s’intégrant à un SI existant et en restant capable d’évoluer.

Pour aller plus loin sur le choix de l’architecture, consultez notre analyse e-commerce standard ou sur-mesure.

Vous avez un modèle B2B/B2C hybride ?

Avant de choisir une plateforme ou de lancer une refonte, il est utile de cartographier les règles commerciales, les parcours utilisateurs et les flux avec le SI.

C’est précisément l’objectif de notre diagnostic e-commerce : identifier les contraintes de votre existant et les options d’architecture adaptées à votre projet.

Combien coûte un projet Sylius ? Budget, facteurs de coût et fourchettes

Posted on by Dev Cyllene
Combien coûte un projet Sylius ? Budget, facteurs de coût et fourchettes

Combien coûte un projet Sylius ? C’est souvent l’une des premières questions posées lorsqu’une entreprise envisage une refonte ou une migration e-commerce.

Et la réponse « ça dépend » ne suffit pas lorsqu’il faut construire un budget, comparer plusieurs agences ou défendre un projet auprès d’une direction.

Un projet Sylius peut représenter quelques dizaines de milliers d’euros comme plusieurs centaines de milliers d’euros. La différence ne vient pas simplement de la technologie : elle dépend surtout de la complexité fonctionnelle, métier et technique du projet.

Voici les principaux facteurs à prendre en compte et des ordres de grandeur pour commencer à situer votre projet.

à retenir

  • Un projet Sylius simple peut se situer autour de 30 à 60 k€.
  • Un projet intermédiaire se situe plutôt autour de 60 à 120 k€.
  • Un projet e-commerce complexe peut atteindre 120 à 250 k€.
  • Les plateformes enterprise avec SI complexe, multi-site, B2B ou architecture headless peuvent dépasser 250 k€.
  • Le budget ne dépend pas uniquement du nombre de produits : UX/UI, règles métier, intégrations, migration, performance et DevOps peuvent peser fortement.
  • Un cadrage préalable permet de distinguer les fonctionnalités réellement nécessaires des contraintes héritées de l’existant.

Combien coûte réellement un projet Sylius ?

Sylius est une plateforme e-commerce open source, modulaire et fortement personnalisable. Elle permet de construire une plateforme adaptée aux besoins de l’entreprise sans repartir de zéro.

Mais cette flexibilité signifie aussi que le budget dépend largement de ce que l’on construit autour du socle.

À titre d’ordre de grandeur :

Type de projetBudget indicatif
Projet simple30 à 60 k€
Projet intermédiaire60 à 120 k€
Projet complexe120 à 250 k€
Plateforme enterprise250 k€ et +

Ces montants sont des fourchettes indicatives, et non des tarifs catalogue. Ils correspondent à des projets dont le périmètre peut fortement varier en fonction du niveau de personnalisation, du nombre d’intégrations, de la migration et des exigences d’exploitation.

Le bon réflexe consiste donc à partir de la complexité du projet plutôt que du seul choix de Sylius.

Projet Sylius simple : 30 à 60 k€

Un projet peut rester dans cette enveloppe lorsque le périmètre est relativement maîtrisé :

  • catalogue peu complexe ;
  • parcours d’achat standards ;
  • peu de règles métier spécifiques ;
  • une seule langue ou un périmètre international limité ;
  • peu d’intégrations ;
  • UX/UI relativement simple ;
  • pas de migration de données particulièrement lourde.

Dans ce contexte, Sylius sert principalement de socle e-commerce personnalisable.

Le budget peut toutefois augmenter rapidement si l’on ajoute une refonte UX/UI complète, plusieurs interfaces métier ou des développements spécifiques.

Projet Sylius intermédiaire : 60 à 120 k€

Cette catégorie correspond davantage à une entreprise qui souhaite une plateforme réellement adaptée à son activité.

On peut retrouver :

  • un catalogue important ou structuré ;
  • des règles de prix ou de promotion spécifiques ;
  • une refonte UX/UI ;
  • plusieurs moyens de paiement ou de livraison ;
  • des connexions ERP, PIM ou CRM ;
  • une reprise de données ;
  • plusieurs langues ou pays ;
  • des besoins SEO liés à la migration.

À ce stade, le budget ne correspond déjà plus au simple « développement d’un site ». Il finance une plateforme e-commerce intégrée au fonctionnement de l’entreprise.

Si votre projet consiste à remplacer une plateforme existante, notre article « PrestaShop vs Sylius ? » permet justement d’identifier les situations dans lesquelles une migration commence à devenir pertinente.

Projet Sylius complexe : 120 à 250 k€

C’est généralement ici que l’on retrouve les projets correspondant au positionnement de Sylius sur des environnements e-commerce complexes.

Le projet peut cumuler :

  • e-commerce B2B ;
  • comptes entreprises et droits utilisateurs ;
  • tarifs personnalisés ;
  • catalogues différenciés ;
  • workflows métier ;
  • ERP, PIM, CRM ou WMS ;
  • architecture API-first ;
  • plusieurs pays et devises ;
  • multi-site ;
  • reprise importante de données ;
  • exigences fortes de performance ;
  • besoin de développements sur mesure.

Le projet Innelec illustre ce niveau de complexité : plateforme B2B sur mesure sous Sylius, plus de 7 000 références, architecture API-first, intégrations PIM, CRM et SAGE via middleware, avec des règles commerciales et logistiques spécifiques.

Dans ce type de contexte, le budget doit être considéré comme celui d’un projet de transformation e-commerce, et non comme celui d’un simple changement de CMS.

Plateforme enterprise : 250 k€ et plus

Certains projets dépassent largement les 250 k€ lorsqu’ils deviennent de véritables plateformes digitales structurantes.

C’est notamment le cas lorsque plusieurs facteurs se cumulent :

  • plusieurs sites ou marques ;
  • plusieurs pays et devises ;
  • catalogue très important ;
  • règles commerciales complexes ;
  • architecture headless ;
  • nombreux systèmes connectés ;
  • exigences de disponibilité élevées ;
  • volumes de trafic importants ;
  • infrastructure spécifique ;
  • migration complexe ;
  • dispositif de TMA et d’exploitation important.

Le multi-site, le headless ou une architecture API-first ne doivent cependant pas être considérés comme des options obligatoires. Ils doivent répondre à un besoin réel.

Notre article « Qu’est-ce que le headless commerce ? » détaille justement les bénéfices mais aussi la complexité supplémentaire induite par cette architecture.

Quels sont les principaux facteurs qui font varier le prix ?

1. Le cadrage

Le cadrage permet de transformer les besoins métier en périmètre fonctionnel et technique. Il peut comprendre ateliers métiers, analyse de l’existant, architecture, spécifications, priorisation et estimation. Plus le projet est complexe, plus cette phase devient importante.

2. UX/UI

Une refonte graphique complète ne représente pas le même investissement qu’une adaptation légère d’une interface existante.

Recherche utilisateur, parcours, wireframes, design system, maquettes responsive et intégration peuvent faire varier significativement le budget.

3. Le catalogue

Le nombre de références n’est qu’un indicateur. Il faut aussi regarder les variantes, attributs, catégories, règles de prix, catalogues clients, contenus multilingues et médias.

Un catalogue de 10 000 références simples peut être moins complexe à gérer qu’un catalogue beaucoup plus petit avec de nombreuses règles métier.

4. Les règles métier

C’est souvent l’un des principaux facteurs de coût. Tarification personnalisée, comptes professionnels, minimums de commande, remises, workflows de validation, disponibilités ou règles de livraison nécessitent des développements spécifiques.

Le projet Bollinger en est un bon exemple : la plateforme B2B développée avec Cyllene intègre notamment l’ERP, le catalogue produit et des processus spécifiques de commande et de logistique.

5. Les intégrations

ERP, PIM, CRM, WMS, paiement, transporteurs, marketplaces ou outils métier : chaque interface ajoute du périmètre.

Mais c’est surtout la complexité des flux qui compte : fréquence, transformation des données, règles métier, gestion des erreurs et supervision.

Notre guide sur l’intégration de Sylius avec un ERP ou un PIM détaille ces différents enjeux.

6. La migration

Migrer ne signifie pas uniquement importer les produits. Il peut également être nécessaire de reprendre :

  • comptes clients ;
  • commandes ;
  • historique ;
  • catégories ;
  • contenus ;
  • promotions ;
  • données SEO.

La migration SEO doit elle aussi être anticipée : URL, redirections, indexation et patrimoine organique font partie du projet.

Notre guide « Migration e-commerce sans perte SEO » détaille cette méthode.

7. Headless et multi-site

Ces architectures peuvent apporter davantage de liberté, mais elles ajoutent également des composants, des interfaces et des besoins de maintenance. Il faut donc les considérer comme des choix d’architecture, pas comme des fonctionnalités à ajouter systématiquement.

8. Performance et DevOps

Une plateforme soumise à de forts volumes ou à des pics de trafic nécessite davantage de travail sur l’architecture, le cache, la base de données, le monitoring, les déploiements et l’infrastructure.

Le projet Innelec constitue ici un exemple concret : la nouvelle plateforme a permis de diviser par deux la charge serveur à infrastructure équivalente et d’absorber les pics saisonniers.

9. La TMA

Le budget initial n’est pas le seul coût à considérer. Une plateforme e-commerce doit ensuite évoluer : corrections, mises à jour, nouvelles fonctionnalités, sécurité, supervision et accompagnement métier.

Il est donc utile de comparer les projets sur leur TCO, et pas uniquement sur leur coût de lancement.

Notre article « Plateformes e-commerce : modules ou sur-mesure, quel coût ? » approfondit justement cette notion de coût d’évolution et de maintenance.

Sylius coûte-t-il plus cher qu’une plateforme standard ?

Pas nécessairement. Une plateforme standard peut être moins coûteuse à lancer lorsqu’elle répond directement aux besoins du projet.

En revanche, lorsque les besoins deviennent spécifiques, l’accumulation de modules, de développements et de contournements peut augmenter le coût de maintenance et d’évolution.

À l’inverse, Sylius permet de construire uniquement les fonctionnalités nécessaires et de conserver la maîtrise de l’architecture.

La question pertinente n’est donc pas seulement :

« Combien coûte Sylius ? »

Mais plutôt :

« Combien va coûter la plateforme dont mon entreprise a réellement besoin, à la conception puis dans la durée ? »

Comment obtenir un budget fiable ?

Une fourchette peut permettre de qualifier un projet, mais elle ne remplace pas un cadrage.

Avant de demander un devis, il est utile de documenter :

  1. votre plateforme actuelle ;

  2. votre catalogue ;

  3. vos règles métier ;

  4. vos systèmes connectés ;

  5. vos besoins B2B/B2C ;

  6. votre périmètre international ;

  7. vos objectifs UX/UI ;

  8. vos contraintes de performance ;

  9. vos données à migrer ;

  10. vos besoins d’exploitation et de TMA.

C’est aussi l’intérêt d’un diagnostic e-commerce : identifier les principaux postes de complexité avant de figer une architecture et un budget.

Obtenir mon diagnostic e-commerce

Conclusion

Un projet Sylius peut coûter 30 000 € comme plus de 250 000 €, selon son niveau de complexité.

La différence ne vient pas simplement de Sylius. Elle vient du projet que l’entreprise souhaite construire autour de la plateforme : expérience utilisateur, catalogue, règles métier, B2B, intégrations SI, migration, performance, infrastructure et évolutions futures.

Pour un e-commerce complexe, le bon réflexe n’est donc pas de rechercher le prix le plus bas, mais de comprendre ce que le budget couvre et quelle architecture il permet réellement de construire.

Chez Cyllene, nous accompagnons les projets Sylius de la conception à la mise en production et à la TMA, avec une approche associant pilotage, UX/UI, architecture, développement, DevOps et intégration au SI. Cette approche transverse est particulièrement adaptée aux projets e-commerce complexes B2B et B2C.

Vous avez un projet Sylius et souhaitez situer son niveau de complexité ? Demandez votre diagnostic e-commerce de 45 minutes.

Sylius et système d’information : quelle architecture pour un e-commerce complexe ?

Posted on by Dev Cyllene
Sylius et système d’information : quelle architecture pour un e-commerce complexe ?

ERP, PIM, CRM, DAM, logistique… un e-commerce complexe repose rarement sur une seule plateforme. La difficulté n’est donc pas seulement de choisir un moteur e-commerce performant, mais de réussir à l’intégrer dans un système d’information existant.

Dans ce contexte, Sylius peut jouer le rôle de moteur e-commerce connecté au SI, plutôt que de chercher à remplacer les applications qui gèrent déjà les données de l’entreprise.

La question centrale devient alors : qui possède quelle donnée, et comment la faire circuler entre les différents systèmes ?

à retenir

  • Un e-commerce complexe doit généralement dialoguer avec plusieurs briques du SI : ERP, PIM, CRM, DAM, logistique ou paiement.
  • Chaque système doit conserver un rôle clairement défini et, idéalement, une source de référence pour chaque donnée.
  • Sylius peut devenir le moteur e-commerce qui exploite et orchestre ces données.
  • Son approche API-first facilite les échanges avec les systèmes existants.
  • Cette architecture est particulièrement pertinente pour les e-commerces B2B et B2C complexes, avec des règles métier spécifiques.
  • Le choix d’un intégrateur Sylius doit donc prendre en compte à la fois la maîtrise de la plateforme et la capacité à comprendre le système d’information dans son ensemble.

Qu’est-ce qu’un SI e-commerce complexe ?

Un site e-commerce n’est souvent que la partie visible d’un écosystème beaucoup plus large.

Derrière une fiche produit peuvent se trouver un PIM, un ERP peut gérer le stock et les tarifs, un CRM les comptes clients et un DAM les médias.

On retrouve par exemple :

PIM → données produits, attributs, catégories

ERP → stocks, tarifs, commandes, facturation, règles de gestion

CRM → comptes clients, contacts, données commerciales

DAM → images, vidéos, documents

Sylius → catalogue e-commerce, parcours d’achat, panier, commandes, comptes et expérience utilisateur

Logistique / transporteurs → préparation, expédition, suivi

Le rôle du projet e-commerce est alors de faire fonctionner cet ensemble de manière cohérente.

Un e-commerce complexe n’a pas besoin de concentrer toute la donnée dans une seule plateforme. Il a besoin de faire circuler la bonne donnée entre les bons systèmes.

Sylius : le moteur e-commerce au cœur du SI

Sylius est particulièrement adapté à cette logique d’architecture.

Plutôt que de chercher à devenir l’ERP, le PIM ou le CRM de l’entreprise, Sylius peut se concentrer sur son rôle de plateforme e-commerce et communiquer avec les autres briques du système d’information.

On peut ainsi représenter simplement l’architecture :

PIM → SYLIUS ← CRM

ERP → SYLIUS → LOGISTIQUE

DAM → PIM → SYLIUS

Cette organisation permet de conserver les responsabilités de chaque outil tout en construisant une expérience e-commerce cohérente.

L’enjeu n’est donc pas de connecter un maximum de systèmes à Sylius, mais de définir quelles données doivent circuler, dans quel sens et pour quel usage.

Qui possède quelle donnée ?

C’est l’une des premières questions à poser lors d’une refonte e-commerce complexe.

Le PIM pour la donnée produit

Le PIM peut être le référentiel des informations produits :

  • désignations ;
  • descriptions ;
  • attributs ;
  • catégories ;
  • déclinaisons ;
  • informations multilingues ;
  • visuels et documents.

Ces données sont ensuite exploitées par Sylius pour alimenter le catalogue et les parcours de navigation.

PIM → Sylius → expérience e-commerce

L’ERP pour les données commerciales et opérationnelles

L’ERP peut rester la source de référence pour :

  • les stocks ;
  • les tarifs ;
  • les taxes ;
  • certaines règles commerciales ;
  • les commandes ;
  • les données nécessaires à la préparation et à la facturation.

Les flux peuvent fonctionner dans les deux sens.

ERP → Sylius : stocks, tarifs, règles de gestion…

Sylius → ERP : commandes, demandes de préparation…

L’objectif est d’éviter de créer plusieurs versions concurrentes d’une même donnée.

Le CRM pour les données clients

Le CRM peut gérer les informations liées aux clients et aux contacts :

  • comptes entreprises ;
  • utilisateurs ;
  • contacts ;
  • segmentation ;
  • informations commerciales ;
  • rattachement des utilisateurs à leur organisation.

Dans un environnement B2B, cette connexion devient particulièrement stratégique.

Un même compte peut avoir plusieurs utilisateurs, plusieurs niveaux de droits, des conditions tarifaires spécifiques ou encore des circuits de validation différents.

Sylius peut alors restituer ces règles dans le parcours e-commerce.

Le DAM pour les contenus

Le DAM peut centraliser les ressources médias utilisées dans le catalogue :

DAM → PIM → Sylius

Cette organisation permet de limiter la duplication des contenus et de conserver un référentiel cohérent.

Pourquoi l’API-first est importante dans une architecture Sylius ?

Lorsque plusieurs applications doivent communiquer, les échanges entre systèmes deviennent un sujet architectural à part entière.

Une approche API-first permet d’organiser ces échanges autour de services et d’API plutôt que de multiplier les dépendances directes entre applications.

Sylius peut ainsi communiquer avec :

  • un ERP ;
  • un PIM ;
  • un CRM ;
  • des services logistiques ;
  • des solutions de paiement ;
  • d’autres applications métier.

L’intérêt dépasse la simple connexion technique.

Une architecture bien conçue permet aussi de faire évoluer une brique du SI sans devoir reconstruire toute la plateforme e-commerce.

API-first ne signifie pas simplement “utiliser des API”. C’est une manière de concevoir un système dans lequel les différentes briques peuvent évoluer de façon plus indépendante.

Le cas particulier du e-commerce B2B

Les enjeux deviennent encore plus importants lorsque Sylius doit porter un e-commerce B2B.

Un client professionnel peut avoir :

  • plusieurs utilisateurs rattachés à une même entreprise ;
  • des catalogues spécifiques ;
  • des tarifs négociés ;
  • des règles de disponibilité ;
  • des conditions de paiement ;
  • des workflows de validation ;
  • des historiques de commandes ;
  • des règles de livraison spécifiques.

Ces informations peuvent provenir de plusieurs systèmes.

Le rôle de Sylius est alors de traduire ces données et ces règles métier dans une expérience e-commerce cohérente.

C’est ce qui distingue notamment une simple boutique en ligne d’une véritable plateforme e-commerce B2B.

Exemple concret : Innelec et une plateforme Sylius connectée au SI

Cas Innelec Sylius SI

Le projet mené pour Innelec illustre concrètement cette approche.

L’entreprise souhaitait moderniser sa plateforme B2B et remplacer une solution Magento 2.3 devenue obsolète. Le nouveau socle devait notamment gérer un catalogue de plus de 7 000 références, offrir une meilleure expérience aux partenaires professionnels et absorber les pics d’activité saisonniers.

La réponse s’est appuyée sur une plateforme B2B sur mesure basée sur Sylius et une architecture API-first. L’architecture intègre notamment :

PIM → Sylius

Récupération des produits, catégories, attributs, visuels et documents.

CRM → Sylius

Récupération des contacts et des clients.

SAGE → Sylius

Récupération des règles de gestion, tarifs, taxes et frais de port.

Sylius → SAGE

Transmission des commandes et des demandes de mise en préparation.

Les échanges avec SAGE passent par un middleware développé pour le projet.

Le projet montre bien l’intérêt d’une approche dans laquelle Sylius devient le moteur de l’expérience e-commerce sans chercher à remplacer les systèmes métier existants.

Le résultat : une plateforme plus performante et évolutive, avec notamment une charge serveur divisée par deux à infrastructure équivalente par rapport à la plateforme précédente.

L’équipe de Cyllene a pu comprendre nos besoins et mettre en place toutes les interfaces pour une parfaite intégration avec notre SI.
Mathieu Perchat DSI, Innelec

Une architecture e-commerce doit d’abord répondre aux règles métier

La technologie n’est qu’une partie du sujet.

Avant de développer les interfaces entre Sylius et les différents systèmes, il faut notamment déterminer :

  • Quelle donnée ?
  • Quelle source de référence ?
  • Quel système la consomme ?
  • Dans quel sens circule-t-elle ?
  • À quel moment ?
  • Que se passe-t-il en cas d’erreur ou d’indisponibilité ?

Ces questions sont essentielles pour éviter de reproduire dans Sylius des données ou des fonctionnalités qui doivent rester gérées par un autre système.

C’est également ce qui permet de construire une architecture durable, capable d’accompagner les évolutions futures de l’entreprise.

Sylius ne remplace pas votre SI : il s’y intègre

C’est probablement le point essentiel à retenir.

Sylius n’a pas vocation à remplacer votre ERP, votre PIM ou votre CRM.

Il peut devenir le moteur e-commerce qui exploite les données de ces différentes briques et porte les fonctionnalités propres au canal digital.

Cette approche est particulièrement pertinente lorsqu’une entreprise dispose déjà d’un système d’information structuré et souhaite faire évoluer son e-commerce sans remettre en cause l’ensemble de son architecture.

La refonte devient alors plus qu’un changement de CMS.

Il s’agit de concevoir une architecture e-commerce capable de s’intégrer au SI, de porter les règles métier et d’évoluer avec l’entreprise.

Pourquoi faire appel à un intégrateur Sylius ?

Pour un projet e-commerce complexe, la maîtrise de Sylius est indispensable. Mais elle ne suffit pas. L’intégrateur doit également comprendre :

  • les processus métier ;
  • les enjeux B2B ou B2C ;
  • l’architecture du SI ;
  • les flux de données ;
  • les contraintes de performance ;
  • les enjeux UX et conversion ;
  • les évolutions futures de la plateforme.

C’est l’approche portée par Cyllene, intégrateur Sylius, qui accompagne des projets e-commerce sur mesure et s’appuie sur les expertises complémentaires du groupe.

Cyllene dispose de plus de 400 experts dans différents métiers du numérique, notamment le web, la data, l’infrastructure, le cloud et la cybersécurité. Cette organisation permet de combiner une équipe Web à taille humaine pour piloter le projet avec les expertises complémentaires nécessaires lorsqu’un projet e-commerce doit s’intégrer à un SI plus large.

Pour aller plus loi, découvrez notre article : Comment choisir son intégrateur Sylius ?

Vous envisagez une création ou une refonte e-commerce sous Sylius ?

Échangez avec un expert Cyllene pour analyser votre architecture, vos contraintes SI et vos besoins d’intégration.

Migrer de Magento vers Sylius : méthode, étapes et bonnes pratiques

Posted on by Dev Cyllene
s

Migrer un e-commerce de Magento vers Sylius ne consiste pas simplement à changer de plateforme. Catalogue, comptes clients, commandes, tarifs, données, SEO, intégrations et règles métier doivent être analysés puis reconstruits sur le nouveau socle.

La vraie question est donc moins « comment migrer Magento vers Sylius ? » que « que faut-il conserver, repenser ou simplifier lors de la migration ? »

Pour un projet complexe, cette réflexion permet de transformer une migration technique en véritable projet de modernisation e-commerce.

à retenir

  • Une migration Magento vers Sylius doit commencer par un audit de l’existant, pas par le développement.
  • Toutes les données ne doivent pas nécessairement être reprises à l’identique : il faut distinguer l’indispensable du legacy.
  • Le SEO, les URLs et les redirections 301 doivent être intégrés au projet dès la conception.
  • Les intégrations ERP, PIM, CRM et autres systèmes métier constituent une partie majeure du chantier.
  • Sylius devient particulièrement pertinent lorsque le projet nécessite personnalisation, règles métier spécifiques et forte intégration au SI.
  • Le choix de l’intégrateur Sylius est déterminant pour sécuriser l’architecture, la migration des données et la mise en production.

Pourquoi quitter Magento ?

Magento peut parfaitement répondre aux besoins d’un e-commerce. La question se pose lorsque la plateforme ne correspond plus aux ambitions ou aux contraintes de l’entreprise.

Plusieurs signaux peuvent déclencher une réflexion :

  • les évolutions fonctionnelles deviennent longues et coûteuses ;
  • la dette technique s’accumule ;
  • les développements spécifiques sont difficiles à maintenir ;
  • les intégrations avec l’ERP, le PIM ou le CRM deviennent complexes ;
  • les performances nécessitent des optimisations répétées ;
  • le SI doit évoluer vers une architecture plus modulaire ;
  • les besoins B2B deviennent trop spécifiques pour le fonctionnement existant.

Dans ce contexte, une migration peut être l’occasion de repartir sur un socle plus flexible.

Sylius est notamment conçu pour les projets nécessitant une forte personnalisation et peut s’intégrer au cœur d’un écosystème composé d’un ERP, d’un PIM, d’un CRM ou d’autres applications métier.

Pour comprendre les bénéfices potentiels d’un tel changement, découvrez aussi notre article Quels gains attendre d’une migration vers Sylius ?

Dans quels cas Sylius est-il pertinent ?

Migrer vers Sylius n’a pas de sens uniquement parce qu’une entreprise utilise Magento.

Le choix devient particulièrement pertinent lorsque le projet cumule plusieurs facteurs de complexité :

  • règles métier spécifiques ;
  • catalogue complexe ;
  • besoins B2B ;
  • tarifs personnalisés ;
  • comptes entreprises et rôles utilisateurs ;
  • nombreuses intégrations ;
  • architecture API-first ;
  • plusieurs canaux ou interfaces ;
  • besoin de faire évoluer rapidement la plateforme.

C’est notamment le cas lorsqu’un e-commerce doit devenir une véritable brique du système d’information, plutôt qu’un outil isolé.

Pour un projet B2B, cette logique est particulièrement importante. Sylius pour le e-commerce B2B permet notamment de gérer des comptes entreprises, des tarifs spécifiques, des catalogues différenciés et des processus métier adaptés.

Que faut-il migrer de Magento vers Sylius ?

Une migration réussie ne consiste pas à reproduire Magento à l’identique.

La première étape consiste à cartographier l’existant et à déterminer, pour chaque donnée ou fonctionnalité, ce qui doit être :

conservé → transformé → remplacé → abandonné.

Catalogue produits

Le catalogue constitue généralement l’un des premiers chantiers.

Il faut identifier :

  • produits et variantes ;
  • catégories et arborescences ;
  • attributs ;
  • médias ;
  • références et EAN ;
  • descriptions ;
  • statuts ;
  • règles de visibilité ;
  • relations entre produits ;
  • données SEO.

Le mapping entre Magento et Sylius doit être défini avant les imports afin d’éviter de reproduire dans le nouveau système des structures devenues inutiles.

Clients et comptes

Les comptes clients doivent également être analysés :

  • comptes particuliers ;
  • comptes entreprises ;
  • adresses ;
  • groupes clients ;
  • rôles et permissions ;
  • historiques utiles ;
  • données de contact ;
  • consentements.

Pour un projet B2B, la migration doit aussi tenir compte de la structure organisationnelle : plusieurs utilisateurs peuvent être rattachés à une même entreprise et disposer de droits différents.

Commandes

La reprise de l’historique des commandes dépend des objectifs du projet.

Toutes les commandes historiques doivent-elles réellement être accessibles dans Sylius ? Ou certaines peuvent-elles être conservées dans un système d’archivage ou l’ERP ?

Cette décision permet parfois de réduire considérablement la complexité de la migration.

Prix et règles commerciales

C’est souvent l’un des points les plus sensibles. Il faut identifier :

  • prix catalogue ;
  • prix par groupe client ;
  • tarifs négociés ;
  • remises ;
  • prix par quantité ;
  • promotions ;
  • règles spécifiques ;
  • taxes ;
  • frais de livraison.

L’objectif n’est pas seulement de transférer les prix existants, mais de comprendre où doivent désormais être gérées les règles commerciales.

Données et contenus

La migration concerne également les contenus :

  • pages éditoriales ;
  • contenus SEO ;
  • articles ;
  • médias ;
  • données structurées ;
  • métadonnées ;
  • contenus multilingues.

C’est l’occasion de nettoyer les données obsolètes plutôt que de transférer automatiquement tout le patrimoine historique.

SEO et URLs : le chantier à ne surtout pas sous-estimer

Une migration Magento vers Sylius peut modifier l’architecture, les catégories, les URLs et les gabarits.

Le risque SEO ne vient donc pas du changement de technologie lui-même, mais d’une migration mal préparée.

Avant le développement, il faut notamment cartographier :

  • les URLs existantes ;
  • les pages générant du trafic ;
  • les pages positionnées ;
  • les backlinks ;
  • les pages stratégiques commercialement ;
  • les anciennes URLs produits et catégories.

Le plan de redirection 301 doit ensuite faire correspondre les anciennes URLs avec les nouvelles destinations pertinentes.

Cette phase doit être préparée suffisamment tôt pour être testée en préproduction.

Pour approfondir ce sujet, notre guide Migration e-commerce sans perte SEO : la méthode pour sécuriser une migration détaille les différentes étapes, du crawl initial au monitoring post-production.

Les intégrations : le vrai cœur de la migration

Un projet Magento vers Sylius dépasse généralement le périmètre du site. Le nouveau moteur e-commerce doit pouvoir communiquer avec les systèmes qui l’entourent :

PIM → Sylius
Produits, attributs, médias, catégories.

ERP → Sylius
Prix, stocks, règles commerciales, données logistiques.

CRM → Sylius
Clients, contacts, informations commerciales.

Sylius → ERP
Commandes, statuts, demandes de préparation.

Il faut donc cartographier chaque flux, son sens, sa fréquence, son format et son système source.

Une architecture API-first peut alors permettre de construire des échanges plus structurés et de faire évoluer les différentes briques indépendamment.

C’est particulièrement important lorsque le e-commerce doit s’inscrire dans un SI complexe. Intégrer Sylius à un ERP ou PIM permet d’approfondir les stratégies possibles pour sécuriser et automatiser ces flux.

Performances : ne pas simplement reproduire l’ancien site

Une migration est aussi l’occasion de revoir les choix techniques qui peuvent limiter les performances. Il faut définir dès la conception :

  • les objectifs de temps de réponse ;
  • les volumes de catalogue ;
  • les pics de trafic ;
  • les besoins de cache ;
  • les performances de recherche ;
  • les traitements asynchrones ;
  • les besoins d’infrastructure ;
  • les mécanismes de supervision.

L’objectif n’est pas seulement de faire fonctionner Sylius, mais de construire une plateforme capable d’absorber les évolutions futures.

Recette : tester le métier, la donnée et le SEO

La recette doit être organisée autour de plusieurs dimensions.

Fonctionnelle

Vérifier notamment :

  • navigation ;
  • recherche ;
  • catalogue ;
  • comptes clients ;
  • panier ;
  • commande ;
  • paiement ;
  • promotions ;
  • règles tarifaires.

Données

Comparer les données Magento avec celles présentes dans Sylius :

  • nombre de produits ;
  • variantes ;
  • clients ;
  • catégories ;
  • prix ;
  • stocks ;
  • commandes reprises.

Intégrations

Tester les flux avec chaque système connecté et les scénarios d’erreur.

SEO

Contrôler :

  • URLs ;
  • redirections 301 ;
  • canonical ;
  • robots.txt ;
  • sitemap ;
  • balises Title ;
  • H1 ;
  • données structurées ;
  • maillage interne ;
  • indexabilité.

Le staging doit donc être considéré comme un véritable environnement de recette, et non comme une simple version de démonstration.

Mise en production : préparer le jour J

La bascule doit être organisée comme une opération critique.

Avant le lancement :

  • sauvegarde des données ;
  • dernière synchronisation ;
  • gel des modifications ;
  • validation des flux ;
  • validation du plan de redirection ;
  • contrôle du tracking ;
  • validation du Go/No-Go.

Après la bascule :

  • vérifier les principales URLs ;
  • tester le parcours d’achat ;
  • contrôler les commandes ;
  • vérifier les flux ;
  • surveiller les erreurs 404 et 500 ;
  • contrôler l’indexation ;
  • suivre les performances et conversions.

Une migration ne s’arrête donc pas le jour de la mise en production.

Combien coûte une migration Magento vers Sylius ?

Il n’existe pas de tarif standard pour une migration Magento vers Sylius.

Le budget dépend notamment :

FacteurImpact sur le projet
Taille du catalogueVolume et complexité du mapping
Données clientsStructure et historique à reprendre
CommandesVolume et profondeur de l’historique
TarificationNombre et complexité des règles
IntégrationsERP, PIM, CRM, WMS, marketplaces…
Dette techniqueComplexité de l’existant
Front-endReprise ou refonte complète
SEOVolume d’URLs et niveau de patrimoine à préserver
Règles métierNiveau de développement spécifique

C’est pourquoi un chiffrage sérieux doit commencer par un audit de l’existant et une cartographie des flux et données.

L’objectif est également de distinguer ce qui doit absolument être migré de ce qui peut être simplifié ou abandonné.

Pourquoi choisir un intégrateur pour une migration Magento vers Sylius ?

Le choix de Sylius ne suffit pas à sécuriser une migration. Le projet nécessite de maîtriser simultanément :

  • l’architecture e-commerce ;
  • Symfony et Sylius ;
  • la reprise de données ;
  • les intégrations SI ;
  • le SEO ;
  • les performances ;
  • la recette ;
  • la mise en production.

Le rôle de l’intégrateur est précisément de faire le lien entre ces différents sujets.

Chez Cyllene, l’accompagnement couvre l’architecture, la conception, le développement, les intégrations, la recette, la mise en production et la TMA. Cyllene est également partenaire officiel Sylius et accompagne des projets B2B complexes, B2C à fort volume et marketplaces.

Innelec : un exemple concret de migration Magento 2.3 vers Sylius

Le projet de migration Magento vers Sylius, Innelec, permet de mesurer concrètement ce que représente une telle transformation.

L’entreprise disposait de plus de 7 000 références et souhaitait remplacer une plateforme B2B devenue obsolète, développée sous Magento 2.3.

Le nouveau dispositif repose sur une plateforme Sylius 100 % sur mesure et une architecture API-first, connectée notamment au PIM, au CRM et à SAGE via un middleware spécifique.

Les flux couvrent notamment les produits, les clients, les tarifs, les taxes, le transport et les commandes.

Le résultat est particulièrement intéressant dans le cadre d’une migration : à infrastructure équivalente, la charge serveur a été divisée par deux par rapport à l’ancienne plateforme Magento 2.3, tout en améliorant la recherche, le filtrage et l’expérience utilisateur.

Sylius nous a permis de créer des fonctionnalités très spécifiques dans un délai court. L'équipe de Cyllene a pu comprendre nos besoins et mettre en place toutes les interfaces pour une parfaite intégration avec notre SI.
Mathieu Perchat DSI Innelec

Migrer de Magento vers Sylius : ce qu’il faut retenir

Une migration Magento vers Sylius n’est pas une simple opération de remplacement de CMS.

C’est l’occasion de repenser le modèle e-commerce, de nettoyer les données, de revoir les intégrations et de construire une architecture capable d’accompagner les prochaines évolutions de l’entreprise.

La méthode repose sur quatre principes :

auditer → concevoir → migrer → sécuriser.

Et surtout, ne pas considérer la migration comme un projet uniquement technique. Catalogue, clients, commandes, prix, SEO, intégrations, performance et métier doivent être traités ensemble.

Pour un projet e-commerce complexe, le choix de l’intégrateur devient alors aussi important que le choix de la plateforme. Découvrez notre article sur Comment choisir son intégrateur Sylius en France ?

Sylius pour le e-commerce B2B : dans quels cas est-il pertinent ?

Posted on by Dev Cyllene
Sylius pour le e-commerce B2B pertinence

Le e-commerce B2B ne se résume pas à mettre un catalogue professionnel en ligne. Comptes entreprises, utilisateurs et droits d’accès, tarifs personnalisés, règles commerciales, workflows de validation ou encore connexion à l’ERP : les exigences peuvent rapidement dépasser les possibilités d’une plateforme standard.

Sylius est-il adapté au e-commerce B2B ? Et dans quels cas son approche devient-elle particulièrement pertinente ?

Construit sur Symfony et pensé pour être modulaire et personnalisable, Sylius permet de concevoir une plateforme adaptée aux processus métier de l’entreprise. Il trouve notamment sa place lorsque le e-commerce doit s’intégrer à un système d’information complexe, composé d’un ERP, d’un PIM, d’un CRM ou d’autres applications métier.

Pour accompagner ce type de projet, découvrez également notre expertise Sylius x Cyllene.

à retenir

  • Sylius est particulièrement adapté aux projets e-commerce B2B complexes et personnalisés.
  • Il permet de construire des expériences adaptées aux comptes entreprises, rôles utilisateurs, catalogues et tarifs spécifiques.
  • Il peut s’intégrer à un ERP, un PIM, un CRM et aux autres briques du système d’information.
  • Son architecture peut s’inscrire dans une approche API-first ou headless.
  • Sylius est particulièrement pertinent lorsque le e-commerce doit évoluer avec les processus métier et le SI de l’entreprise.

Pourquoi le B2B nécessite-t-il une plateforme e-commerce spécifique ?

Les processus d’achat professionnels sont souvent plus complexes que ceux du B2C.

Une entreprise peut par exemple avoir plusieurs utilisateurs utilisant le même compte, avec des niveaux de droits différents. Certains utilisateurs consultent le catalogue, d’autres passent commande, tandis qu’un responsable doit valider certains achats.

Les conditions commerciales peuvent également varier d’un client à l’autre :

  • tarifs négociés ;
  • remises selon les volumes ;
  • catalogues spécifiques ;
  • minimums de commande ;
  • conditions de livraison ;
  • règles de facturation ;
  • workflows de validation ;
  • demandes de devis ou commandes récurrentes.

À ces règles métier s’ajoutent souvent les contraintes du système d’information.

Le catalogue peut être géré dans un PIM, les stocks et commandes dans un ERP et les données commerciales dans un CRM.

La question n’est donc pas seulement de savoir si une plateforme possède des fonctionnalités B2B. Il faut surtout déterminer si elle peut s’adapter aux règles métier de l’entreprise et à son écosystème technique.

Sylius B2B : dans quels cas est-il pertinent ?

Gérer des comptes entreprises et plusieurs utilisateurs

Un e-commerce B2B peut nécessiter plusieurs utilisateurs rattachés à une même entreprise, avec des rôles et permissions différents.

Selon les besoins, la plateforme peut devoir gérer :

  • des droits d’accès différenciés ;
  • des responsables de compte ;
  • des circuits de validation ;
  • des historiques de commandes ;
  • des restrictions sur certains produits ou catalogues.

Avec Sylius, ces comportements peuvent être construits en fonction du modèle organisationnel de l’entreprise, plutôt que de chercher à faire entrer celui-ci dans un fonctionnement standardisé.

Gérer des catalogues et tarifs personnalisés

Le pricing constitue souvent un enjeu majeur du B2B.

Deux clients peuvent consulter le même produit tout en bénéficiant de conditions tarifaires différentes selon leur contrat, leur volume d’achat ou leur profil.

La plateforme peut ainsi devoir gérer plusieurs grilles tarifaires, des remises, des prix par quantité ou des catalogues réservés à certains clients.

La capacité à personnaliser ces règles devient alors un critère déterminant dans le choix de la plateforme.

Connecter le e-commerce au système d’information

Un e-commerce B2B fonctionne rarement seul. Il doit généralement échanger avec plusieurs applications :

PIM → e-commerce
Produits, descriptions, attributs, médias, catégories.

ERP → e-commerce
Stocks, prix, données logistiques ou règles commerciales.

CRM → e-commerce
Clients, contacts et informations commerciales.

E-commerce → ERP
Commandes, statuts et informations nécessaires aux traitements opérationnels.

C’est l’un des contextes dans lesquels une architecture API-first e-commerce prend tout son intérêt.

Sylius et API-first : quel intérêt pour un SI complexe ?

API-first consiste à concevoir les interfaces d’échange comme un élément central de l’architecture.

Dans un e-commerce B2B, cette approche permet notamment de faire communiquer le moteur e-commerce avec les différentes briques du SI et de faire évoluer celles-ci plus indépendamment.

Elle peut être particulièrement pertinente lorsque l’entreprise doit :

  • connecter plusieurs systèmes ;
  • alimenter plusieurs canaux ;
  • faire évoluer son front-end ;
  • ajouter de nouveaux services ;
  • remplacer progressivement certaines briques du SI.

Sylius peut ainsi jouer le rôle de moteur e-commerce au sein d’un écosystème plus large, aux côtés de l’ERP, du PIM, du CRM, du CMS ou de services métier.

Il faut toutefois distinguer les deux notions : Sylius est une plateforme e-commerce ; API-first est une approche d’architecture.

Gérer des règles métier spécifiques

La complexité d’un projet B2B se trouve souvent dans les processus métier.

Une commande peut être soumise à validation. Un utilisateur peut avoir un plafond d’achat. Un client peut accéder à certains produits uniquement. Une règle tarifaire peut dépendre du volume ou du contrat commercial.

Dans ce contexte, multiplier les contournements ou les modules pour reproduire chaque cas particulier peut rendre une plateforme difficile à maintenir.

L’intérêt de Sylius est de disposer d’un socle permettant de développer les règles métier spécifiques au fonctionnement de l’entreprise.

C’est donc particulièrement pertinent lorsque le e-commerce constitue une brique stratégique du système d’information et que les processus métier doivent pouvoir évoluer.

B2B et B2C : peut-on utiliser Sylius pour les deux ?

Oui, selon l’architecture retenue.

Certaines entreprises doivent faire cohabiter une activité B2B et une activité B2C, tout en partageant une partie de leur catalogue, de leurs stocks ou de leurs flux avec le SI.

Les parcours peuvent néanmoins rester différents : tarifs négociés et comptes entreprises côté B2B, parcours d’achat plus classique côté B2C.

La flexibilité de Sylius permet de construire ces expériences autour d’un même socle lorsque cela répond à la stratégie de l’entreprise.

Quand choisir Sylius pour un projet B2B ?

Sylius est particulièrement pertinent lorsque plusieurs de ces critères sont réunis :

Besoin du projet B2BProjet simpleProjet complexePourquoi Sylius devient pertinent
Tarifs et règles commerciales spécifiques🟡🟢Gestion de règles tarifaires sur mesure
Comptes entreprises et rôles utilisateurs🟡🟢Adaptation des droits et workflows aux organisations
Catalogues personnalisés🟡🟢Catalogues et accès différenciés selon les clients
Workflows métier spécifiques🔴🟢Développement de processus métier spécifiques
Intégration ERP / PIM / CRM🟡🟢Connexion avec un SI composé de plusieurs briques
Architecture API-first🟡🟢Échanges structurés avec les différents systèmes et canaux
B2B + B2C🟡🟢Parcours et règles différents sur un même socle
Plusieurs canaux ou interfaces🟡🟢Adaptation du moteur e-commerce à plusieurs expériences
Forte personnalisation métier🔴🟢Socle flexible permettant des développements sur mesure

À l’inverse, pour un projet B2B simple, avec peu de règles métier et peu d’intégrations, une solution standard peut être suffisante.

Le niveau de complexité du projet doit donc guider le choix de la plateforme.

Innelec : un exemple de plateforme B2B complexe sous Sylius

Site Innelec x Sylius

Le projet B2B sous Sylius, Innelec, illustre concrètement cette approche.

L’entreprise disposait de plus de 7 000 références et souhaitait moderniser sa plateforme B2B, auparavant développée sous Magento 2.3. L’objectif n’était pas simplement de changer de technologie : il fallait disposer d’un socle capable de répondre aux besoins métier d’Innelec tout en s’intégrant à son système d’information.

La nouvelle plateforme repose sur Sylius, une architecture API-first et une plateforme 100 % sur mesure. Elle échange notamment avec :

  • le PIM pour les données produits ;
  • le CRM pour les clients et contacts ;
  • SAGE, via un middleware spécifique, pour les règles de gestion, les tarifs, taxes, transport et commandes.

La plateforme doit également absorber des pics de trafic saisonniers et fonctionner 24/7.

Cette architecture a permis d’améliorer l’expérience utilisateur, la recherche et le filtrage, tout en divisant par deux la charge serveur à infrastructure équivalente par rapport à l’ancienne plateforme.

Ce projet montre surtout pourquoi Sylius peut être pertinent pour un e-commerce B2B complexe : le moteur e-commerce s’inscrit au cœur d’un système d’information interconnecté, avec des règles métier spécifiques et une architecture conçue sur mesure.

Et le projet Bollinger ?

Le projet Bollinger constitue un autre exemple de cette approche.

La plateforme B2B développée sous Sylius intègre notamment une synchronisation des produits en temps réel et un suivi des commandes, avec une architecture adaptée aux besoins spécifiques de l’entreprise.

Ces projets illustrent un même principe : la pertinence de Sylius ne dépend pas uniquement du nombre de produits ou du fait que le site soit B2B.

Elle dépend surtout de la complexité fonctionnelle, technique et métier du projet.

Le bon fonctionnement du projet a reposé sur une véritable collaboration et une co-construction efficace de la solution. Cyllene a démontré une réelle volonté de comprendre en profondeur les enjeux et de proposer une solution de bout-en-bout adaptée. Leur rigueur dans la gestion de projet et leur méthodologie ont été des facteurs clés de réussite.
Armelle Saint-Supéry Directrice des systèmes d'information et de la transformation digitale, Groupe Bollinger

Voir les références de Cyllene

Sylius B2B : ce qu'il faut retenir

Sylius est particulièrement intéressant lorsque l’entreprise cherche à construire un e-commerce B2B sur mesure, capable de s’adapter à ses règles commerciales et de s’intégrer durablement à son système d’information.

Comptes entreprises, pricing personnalisé, catalogues spécifiques, workflows, ERP, PIM, CRM ou architecture API-first : plus les besoins sont spécifiques, plus la flexibilité du socle devient importante.

Il ne s’agit donc pas de choisir Sylius parce qu’il serait « meilleur » qu’une plateforme standard dans tous les cas.

Il s’agit de déterminer si la complexité du métier et du SI justifie une plateforme plus flexible et personnalisable.

Pour une refonte ou une migration, l’analyse de l’existant permet justement d’identifier les limites de la plateforme actuelle et de déterminer quelle architecture sera la plus adaptée, notamment lors d’une [migration vers Sylius].

Vous vous demandez si votre plateforme e-commerce est encore adaptée à vos enjeux ?

Un audit permet d’identifier les limites de l’existant, les dépendances techniques et les évolutions possibles avant d’engager une refonte ou une migration.

Évaluez la maturité de votre e-commerce et identifiez les prochains leviers d’évolution.

Diagnostic e-commerce

Retrouvez également notre article : Choisir son intégrateur Sylius

Migration e-commerce sans perte SEO : la méthode pour sécuriser une migration (exemple vers Sylius)

Posted on by Dev Cyllene
migration sylius conservation SEO

Une migration e-commerce peut améliorer les performances, l’expérience client et l’agilité d’un site. Mais sans préparation SEO, elle peut aussi entraîner une perte de trafic organique, de positions et de chiffre d’affaires. Découvrez la méthode pour sécuriser chaque étape d’une migration, avec Sylius comme exemple de plateforme cible.

Changer de CMS, refondre son site ou faire évoluer son architecture e-commerce est un projet stratégique.

Le problème ? Une grande partie de la valeur d’un site ne se trouve pas uniquement dans sa technologie. Elle est aussi dans ses URL, ses contenus, ses backlinks, son historique d’indexation et son trafic organique.

Une migration réussie doit donc préserver cet actif tout en permettant au nouveau site de progresser.

Point essentiel

Le SEO d’une migration e-commerce ne doit pas être traité au moment de la recette. Il doit être intégré dès la conception du projet.

À retenir

  • Changer de CMS ne provoque pas automatiquement une perte de référencement.
  • Le principal risque vient des changements d’URL, des redirections incomplètes et des problèmes d’indexation.
  • L’ancien site doit être entièrement cartographié avant de construire le nouveau.
  • Le plan de redirection 301 doit être préparé et testé avant la mise en production.
  • Le staging doit faire l’objet d’une véritable recette SEO.
  • Après la mise en ligne, le suivi doit continuer pendant plusieurs semaines.

Pourquoi une migration e-commerce peut-elle faire perdre du SEO ?

Le changement de technologie n’est pas, en lui-même, un problème pour les moteurs de recherche.

Les difficultés apparaissent lorsque la migration modifie sans contrôle les signaux qui permettent de comprendre, explorer et positionner le site. Par exemple :

  • les performances se dégradent.nt une mauvaise migration SEO.
  • les URL changent ;
  • des pages disparaissent ;
  • l’arborescence est modifiée ;
  • les balises Title et Hn évoluent ;
  • le maillage interne est reconstruit ;
  • les balises canonical changent ;
  • certaines pages deviennent non indexables ;
  • les données structurées disparaissent ;

Prenons l’exemple d’une fiche produit :

Avant migration : /chaussures-homme/basket-mode-123.html

Après migration : /chaussures-homme/baskets/basket-mode/

Si l’ancienne URL disparaît sans redirection pertinente, le moteur de recherche doit retrouver et réévaluer la nouvelle page.

À l’échelle de quelques URL, le problème peut sembler limité.

À l’échelle de 50 000, 100 000 ou plusieurs centaines de milliers d’URL, l’enjeu devient stratégique.

La méthode en 5 phases pour réussir une migration e-commerce sans perte SEO

Phase 1 — Cartographier votre patrimoine SEO

La première erreur consiste à commencer par le nouveau site. Avant de développer, il faut comprendre ce que l’ancien site a accumulé.

Commencez par crawler l’ensemble des URL existantes :

  • produits ;
  • catégories ;
  • sous-catégories ;
  • pages éditoriales ;
  • articles ;
  • pages de marques ;
  • filtres et facettes ;
  • landing pages ;
  • anciennes pages commerciales.

Mais connaître les URL ne suffit pas. Il faut également identifier celles qui ont une véritable valeur.

Croisez notamment :

  • les données de Google Search Console ;
  • les données Analytics ;
  • les données commerciales ;
  • les backlinks ;
  • les données de crawl.

Une page peut avoir peu de trafic mais disposer de nombreux backlinks. À l’inverse, une page peut générer beaucoup de chiffre d’affaires sans être particulièrement visible dans les moteurs..

Notre recommandation : classer les URL en P1, P2 et P3

P1 — Protection absolueFort trafic, fort chiffre d’affaires, nombreux backlinks ou forte valeur stratégique.
P2 — Conservation recommandéeTrafic organique régulier ou valeur éditoriale.
P3 — À analyserFaible trafic, contenu obsolète ou URL sans valeur clairement identifiée.

Cette classification permet aussi de décider quelles pages doivent être conservées, fusionnées, supprimées ou redirigées.

Phase 2 — Construire un plan de redirection 301 exhaustif

Le plan de redirection est probablement le document le plus important d’une migration SEO.

REGLE A RETENIR

Une ancienne URL doit avoir une nouvelle destination pertinente lorsqu’elle conserve une valeur SEO ou commerciale. Il faut conserver autant que possible la pertinence sémantique et commerciale.

L’erreur classique : tout rediriger vers la homepage 

Google recommande de préparer un mappage entre les anciennes et les nouvelles URL, puis de mettre en place des redirections permanentes vers les destinations correspondantes.

Définition

Une redirection 301, c’est quoi ?

Une redirection 301 indique qu’une URL a été déplacée définitivement vers une autre URL.

ancienne-url-produit → nouvelle-url-produit

Elle permet d’accompagner les utilisateurs et les moteurs de recherche vers la nouvelle adresse.

Trois règles à respecter :

1. Éviter les chaînes

Mauvais : URL A → URL B → URL C

Préférable : URL A → URL C

2. Éviter les boucles

URL A → URL B → URL A

Une telle configuration doit être détectée avant la mise en production.

Traiter les pages supprimées au cas par cas

Un ancien produit peut avoir un équivalent, une nouvelle catégorie peut remplacer une ancienne catégorie, mais certaines pages peuvent aussi ne plus avoir de destination pertinente.

Le plan doit également prendre en compte les filtres, les anciennes campagnes, la pagination et les catégories fusionnées.

Phase 3 — Recetter le nouveau site en pré-production

Le staging ne sert pas uniquement à vérifier que le site fonctionne.

Il doit permettre de vérifier que le futur site conserve les fondamentaux SEO de l’ancien tout en apportant les améliorations attendues.

Indexation

Vérifiez :

  • protection du staging ;
  • noindex ;
  • robots.txt ;
  • absence d’URL staging indexées.

SEO on-page

Contrôlez :

  • Titles ;
  • meta descriptions ;
  • H1 et structure Hn ;
  • canonical ;
  • URLs ;
  • contenus stratégiques.

Architecture

Testez :

  • navigation ;
  • maillage interne ;
  • breadcrumbs ;
  • profondeur des pages ;
  • pages orphelines ;
  • liens cassés.

E-commerce

Le SEO ne doit jamais être testé séparément du business.

Il faut également valider :

  • catalogue ;
  • prix ;
  • stocks ;
  • recherche ;
  • filtres ;
  • panier ;
  • tunnel de commande ;
  • paiement.

Données structurées

Pour un site e-commerce, contrôlez notamment :

  • Product ;
  • Offer ;
  • Breadcrumb ;
  • Organization ;
  • Prix ;
  • Disponibilité.

Le staging doit reproduire le plus fidèlement possible le comportement du futur site afin que les problèmes soient détectés avant la mise en production. C’est l’environnement dans lequel la future plateforme doit être auditée avant sa mise en production.

Phase 4 — Organiser une bascule e-commerce sans rupture

Le jour J ne doit pas être improvisé. Il doit être préparé comme une opération critique.

Avant la bascule

À valider :

  • sauvegarde complète ;
  • dernière synchronisation des données ;
  • freeze des développements ;
  • validation du mapping URL ;
  • validation du plan 301 ;
  • validation des flux ;
  • validation du tracking ;
  • décision Go/No-Go.

Pendant la bascule

Contrôlez notamment :

  • déploiement de la nouvelle plateforme ;
  • activation des redirections ;
  • HTTPS ;
  • DNS ;
  • robots.txt ;
  • sitemap ;
  • accès aux principales pages ;
  • panier ;
  • paiement ;
  • confirmation de commande ;
  • tracking.

Dans les premières heures

Les premières vérifications doivent porter sur les pages les plus critiques. Commencez par :

  1. la homepage ;
  2. les principales catégories ;
  3. les pages SEO prioritaires ;
  4. les produits stratégiques ;
  5. le panier ;
  6. le tunnel de commande ;
  7. le paiement ;
  8. les principales anciennes URL ;
  9. le tracking ;
  10. les erreurs serveur.

Phase 5 — Monitorer le site pendant 30 jours

Une migration ne se termine pas lorsque le nouveau site est accessible. C’est à ce moment que commence la phase de surveillance.

De J+1 à J+7

Surveillez quotidiennement :

  • erreurs 404 ;
  • erreurs 500 ;
  • pages non indexées ;
  • couverture d’indexation ;
  • trafic organique ;
  • positions ;
  • logs Googlebot ;
  • performances ;
  • conversions ;
  • chiffre d’affaires.

De J+7 à J+30

Analysez les tendances :

  • évolution des positions ;
  • évolution du trafic ;
  • pages stratégiques ;
  • évolution des conversions ;
  • crawl des robots ;
  • nouveaux problèmes d’indexation ;
  • évolution des erreurs 404.

L’objectif n’est pas uniquement de constater une éventuelle baisse. Il faut être capable de relier une anomalie à une cause technique ou éditoriale précise.

Exemple : une migration vers Sylius

Prenons maintenant un cas concret. Une entreprise dispose d’un site e-commerce devenu difficile à faire évoluer. Elle décide de profiter de sa refonte pour adopter Sylius comme nouvelle plateforme.

Le principe reste exactement le même que pour toute autre migration. Il faut d’abord préserver le patrimoine SEO existant, puis reconstruire l’architecture cible.

L’intérêt d’une plateforme comme Sylius peut apparaître lorsque le projet nécessite davantage de flexibilité :

  • règles métier spécifiques ;
  • besoins B2B ;
  • catalogue complexe ;
  • nombreuses intégrations ;
  • architecture personnalisée ;
  • plusieurs canaux ;
  • évolutions importantes de la plateforme.

Mais le choix de Sylius ne remplace pas le travail SEO.

Les URL doivent toujours être définies.
Les redirections doivent toujours être préparées.
Le maillage doit toujours être testé.
Les données structurées doivent toujours être contrôlées.
Le nouveau site doit toujours être monitoré après son lancement.

Les 10 erreurs qui peuvent coûter cher lors d’une migration

ErreurRisque principal
Ne pas crawler l’ancien siteURL oubliées
Préparer les 301 trop tardMapping incomplet
Rediriger vers la homepagePerte de pertinence
Supprimer massivement des URLPerte de longue traîne
Indexer le stagingMauvaise indexation
Modifier le maillage sans analysePerte de popularité interne
Oublier les canonicalSignaux contradictoires
Négliger les performancesDégradation de l’expérience
Oublier le trackingPerte de visibilité business
Arrêter le monitoring trop tôtCorrections tardives

Une migration e-commerce est aussi l’occasion de repenser son architecture

Une migration ne consiste pas seulement à déplacer un site d’une plateforme à une autre. Elle permet aussi de prendre du recul sur son architecture e-commerce et de se poser une question essentielle : la plateforme actuelle est-elle encore adaptée aux ambitions de l’entreprise ?

Si votre CMS répond toujours efficacement à vos besoins, une migration n’est pas forcément nécessaire. En revanche, si les évolutions deviennent complexes, que les développements spécifiques se multiplient ou que la plateforme limite vos projets, la migration peut être l’occasion de repartir sur un socle plus évolutif.

Et dans certains projets, cette réflexion conduit également à envisager une architecture headless commerce, qui permet de découpler le front-end de la plateforme e-commerce pour gagner en liberté sur les expériences digitales et les différents canaux.

Avant de choisir une nouvelle solution, commencez donc par identifier les limites de l’existante.

Chez Cyllene, nous accompagnons les entreprises dans ces transformations e-commerce, de l’analyse de l’existant au choix d’architecture, jusqu’à la migration et à la mise en production. L’objectif : construire une plateforme qui réponde aux enjeux d’aujourd’hui, mais surtout à ceux de demain.

Qu’est-ce que le headless commerce ? Avantages, limites et cas d’usage

Posted on by Dev Cyllene

Headless commerce

Le headless commerce est une architecture e-commerce qui sépare le front-end, c’est-à-dire l’interface visible par les utilisateurs, du back-end, qui gère notamment les produits, les clients, les paniers et les commandes.

Les deux couches communiquent via des API, ce qui permet de faire évoluer l’expérience utilisateur indépendamment du moteur e-commerce.

Cette approche apporte davantage de liberté et de flexibilité, mais elle implique également une architecture plus complexe à concevoir et à maintenir.

Résumé exécutif

Bénéfices : Cette approche offre davantage de liberté pour concevoir les expériences digitales et faire évoluer les différents composants indépendamment. Elle est particulièrement pertinente pour les projets omnicanaux, B2B ou fortement personnalisés.

Attention : Le headless implique aussi davantage de complexité, de développement et de gouvernance. Il n’est donc pas nécessairement adapté à tous les e-commerces.

Quand l’envisager ? Lorsque votre architecture actuelle limite vos évolutions, que vous multipliez les canaux ou que vos besoins métier nécessitent davantage de flexibilité.

Sylius : Une plateforme comme Sylius, avec son approche modulaire et API-first, peut s’intégrer dans une architecture headless et répondre à des projets e-commerce fortement personnalisés.

Qu’est-ce que le headless commerce ?

Dans une architecture e-commerce traditionnelle, le front-end et le back-end sont généralement étroitement liés. La plateforme gère à la fois la logique commerciale et une partie importante de la présentation du site.

Avec le headless, cette relation est différente. Le back-end conserve les fonctions e-commerce : catalogue, prix, panier, commandes, comptes clients, règles métier, etc. Le front-end est développé séparément et peut utiliser les technologies les plus adaptées à l’expérience recherchée. Les deux communiquent grâce aux API.

En pratique : une même plateforme e-commerce peut ainsi alimenter plusieurs expériences :

  • un site e-commerce ;
  • une application mobile ;
  • un portail B2B ;
  • une borne ou une interface spécifique ;
  • d’autres points de contact numériques.

Le headless commerce n’est pas un CMS. C’est une approche architecturale qui découple l’expérience utilisateur du moteur e-commerce.

Comment fonctionne une architecture headless ?

fonctionnement d'une architecture headless

Pourquoi les API sont-elles essentielles ?

Dans une architecture headless, les API constituent le point de communication entre les différentes couches.

Elles permettent notamment au front-end de consommer les services du moteur e-commerce sans dépendre directement de son système de présentation.

API First

Une approche API-first consiste à concevoir les API comme un élément central de l’architecture, afin de permettre aux différents systèmes et interfaces de communiquer avec les services métier.

API-first et headless sont donc liés, mais ne désignent pas exactement la même chose. Le headless décrit le découplage entre front-end et back-end ; l’API-first décrit une manière de concevoir l’accès aux services et aux données.

Headless vs e-commerce monolithique : quelles différences ?

La principale différence concerne le niveau de découplage entre l’expérience utilisateur et le moteur e-commerce.

Définition

Une architecture e-commerce monolithique regroupe le front-end et le back-end au sein d’une même plateforme, avec des composants fortement interconnectés.

E-commerce monolithiqueHeadless commerce
Front-end / back-endFortement liésDécouplés
Front-endGénéralement fourni par la plateformeDéveloppé indépendamment
APISelon les capacités de la solutionÉlément central
Liberté technologiquePlus limitéePlus importante
Multiplication des expériencesVariableFacilitée
Complexité techniqueGénéralement plus faiblePlus élevée
GouvernancePlus simplePlus exigeante

Attention

Headless ne signifie pas automatiquement “meilleur”. Pour un e-commerce avec une seule boutique, des parcours standards et peu de besoins spécifiques, une architecture traditionnelle peut être plus simple et plus économique à maintenir.

Le choix doit donc être guidé par les besoins de l’entreprise, et non par la seule volonté d’adopter une architecture plus moderne.

Quels sont les avantages du headless commerce ?

Une plus grande liberté sur le front-end

Le front-end n’est plus directement contraint par le système de templates du moteur e-commerce. Les équipes peuvent donc construire une expérience particulièrement personnalisée et utiliser les technologies adaptées à leur projet.

Une architecture adaptée à plusieurs canaux

Un même socle e-commerce peut alimenter différentes interfaces. Cette approche peut être intéressante lorsqu’une entreprise développe une stratégie omnicanale ou souhaite multiplier les expériences digitales.

Des évolutions plus indépendantes

Le découplage permet de faire évoluer le front-end sans nécessairement modifier le back-end e-commerce. À l’inverse, certaines évolutions du moteur e-commerce peuvent être réalisées sans reconstruire l’expérience utilisateur.

Une meilleure capacité à personnaliser les parcours

Le headless peut être particulièrement pertinent lorsque les parcours clients s’éloignent fortement des scénarios standards proposés par une plateforme.

Le headless prend surtout de la valeur lorsque la liberté du front-end devient un enjeu business : expérience digitale différenciante, multiplication des canaux, parcours B2B spécifiques ou besoins omnicanaux.

Quelles sont les limites du headless commerce ?

Le découplage apporte de la flexibilité, mais il ajoute également de la complexité.

Une architecture plus complexe

Une architecture headless implique généralement davantage de composants : front-end, back-end, API, hébergement, outils tiers et systèmes d’intégration. Il faut donc maîtriser les interactions entre ces différentes briques.

Des coûts de conception et de développement plus importants

Un projet headless nécessite de concevoir et maintenir un front-end indépendant, ainsi que les échanges avec le back-end. Le coût initial peut donc être supérieur à celui d’un projet reposant sur un front-end intégré.

Une gouvernance plus exigeante

Plus les composants sont nombreux, plus les responsabilités doivent être clairement définies. Sans gouvernance adaptée, le découplage peut entraîner une multiplication des dépendances techniques.

Une forte dépendance aux API

Les API deviennent une brique critique de l’architecture. Leur conception, leur documentation, leur sécurité et leur capacité à évoluer doivent donc être soigneusement prises en compte.

Attention

Le headless ne fait pas disparaître la complexité : il la déplace. La liberté gagnée sur le front-end implique davantage de responsabilités en matière d’architecture, de développement et de maintenance.

Quand adopter une architecture headless ?

Le headless peut être pertinent lorsque l’entreprise rencontre plusieurs des situations suivantes :

  • besoin d’une expérience front-end fortement personnalisée ;
  • multiplication des canaux de vente ou des interfaces ;
  • stratégie omnicanale ;
  • parcours B2B spécifiques ;
  • nombreuses intégrations avec le système d’information ;
  • besoin de faire évoluer le front-end indépendamment du back-end ;
  • volonté de conserver une plus grande liberté technologique.

À l’inverse, une architecture headless peut être disproportionnée pour un projet e-commerce simple.

Avant de choisir le headless, posez-vous trois questions :

1. Quels problèmes notre architecture actuelle nous empêche-t-elle de résoudre ?

2. Le découplage apportera-t-il une réelle valeur métier ?

3. Avons-nous les compétences et la gouvernance nécessaires pour maintenir cette architecture ?

Si la réponse est non aux trois, une architecture plus simple peut être préférable.

Headless et SEO : quels impacts ?

Le headless commerce n’est pas automatiquement meilleur pour le SEO.

Le référencement dépend notamment de la manière dont le front-end est conçu et dont les pages sont rendues accessibles aux moteurs de recherche.

Google peut exécuter JavaScript, mais recommande notamment le rendu côté serveur ou le pré-rendu lorsque cela est pertinent. Tous les robots ne gèrent par ailleurs pas JavaScript de la même manière.

Dans un projet headless, il faut donc particulièrement surveiller :

  • le rendu du contenu ;
  • les URL ;
  • les balises title et meta description ;
  • les liens internes ;
  • les balises canoniques ;
  • les redirections ;
  • les sitemaps ;
  • les données structurées ;
  • les performances.

Headless ≠ meilleur SEO

Une architecture headless n’améliore pas automatiquement le référencement naturel. Google peut exécuter JavaScript, mais recommande notamment le rendu côté serveur ou le pré-rendu lorsque cela est pertinent. Le contenu doit rester accessible et correctement rendu pour les moteurs de recherche.

Headless et Core Web Vitals

Le découplage peut donner davantage de contrôle sur le front-end et donc sur les performances.
Mais cette liberté ne garantit aucun résultat.

Un front-end mal conçu, des appels API trop nombreux ou un rendu mal optimisé peuvent au contraire dégrader l’expérience utilisateur.

Le SEO doit donc être intégré à la conception de l’architecture headless, et non traité après coup.

Headless et B2B : quels bénéfices ?

Le B2B présente souvent des parcours plus complexes que le e-commerce B2C standard.

Une plateforme peut notamment devoir gérer :

  • plusieurs utilisateurs pour une même entreprise ;
  • des rôles et permissions ;
  • des tarifs personnalisés ;
  • des catalogues spécifiques ;
  • des workflows de validation ;
  • des demandes de devis ;
  • des commandes récurrentes ;
  • des intégrations avec l’ERP.

Le headless permet de construire des interfaces adaptées à ces parcours tout en conservant un socle e-commerce centralisé.

78% des entreprises B2B interrogées par Adobe utilisent, déploient ou évaluent une solution de commerce headless.

Source1

Quel rôle pour Sylius dans une architecture headless ?

Sylius s’inscrit naturellement dans cette réflexion grâce à son approche modulaire et API-first.

Dans une architecture headless, Sylius peut jouer le rôle de moteur e-commerce tandis qu’un front-end indépendant prend en charge l’expérience utilisateur.

Cette approche permet notamment de construire des expériences fortement personnalisées et de connecter le moteur e-commerce aux différentes briques du système d’information.

Elle peut être particulièrement pertinente pour des projets qui nécessitent :

  • une forte personnalisation métier ;
  • des parcours B2B complexes ;
  • plusieurs canaux ;
  • de nombreuses intégrations ;
  • une architecture découplée ;
  • une capacité à faire évoluer les différentes couches indépendamment.

Point de vigilance

Sylius et headless ne sont pas synonymes. Sylius est une plateforme e-commerce ; le headless est un choix d’architecture. Sylius peut s’inscrire dans une architecture headless, mais le choix de l’un ne signifie pas automatiquement l’adoption de l’autre.

Faut-il passer au headless ?

Non, pas nécessairement.

Le headless commerce répond à des problématiques précises. Il n’est pas une étape obligatoire dans l’évolution d’un site e-commerce.

Une architecture traditionnelle peut rester parfaitement adaptée lorsque :

  • les besoins sont standards ;
  • le nombre de canaux reste limité ;
  • les parcours clients sont simples ;
  • les intégrations sont maîtrisées ;
  • le front-end ne nécessite pas de personnalisation importante.

À l’inverse, le headless peut devenir pertinent lorsque l’architecture actuelle commence à limiter les évolutions de l’entreprise.

C’est notamment le cas lorsque les développements spécifiques se multiplient, que les nouveaux canaux sont difficiles à déployer ou que le CMS devient un frein à la roadmap business.

Ne choisissez pas le headless parce qu’il est plus moderne. Choisissez-le lorsque le découplage répond à un problème concret de votre entreprise.

Comment savoir si le headless est adapté à votre projet ?

Avant d’engager une transformation architecturale, il est utile d’analyser :

  • votre architecture actuelle ;
  • vos parcours clients ;
  • vos besoins B2B et omnicanaux ;
  • vos intégrations SI ;
  • vos contraintes SEO ;
  • vos performances ;
  • vos ressources techniques ;
  • vos ambitions à moyen et long terme.

L’objectif est de déterminer si le headless apporte une véritable valeur ou s’il introduit une complexité disproportionnée.

En résumé

Le headless commerce sépare le front-end du back-end e-commerce afin d’offrir davantage de liberté dans la conception des expériences digitales.

Cette architecture peut être particulièrement pertinente pour les entreprises ayant des besoins complexes, plusieurs canaux, des parcours B2B spécifiques ou un système d’information riche.

Mais headless ne signifie pas automatiquement plus performant, plus SEO ou plus rentable. Sa pertinence dépend du contexte, des objectifs business et de la maturité technique de l’entreprise.

Pour les entreprises dont le CMS commence à devenir un frein à l’évolution, l’étape suivante consiste d’abord à identifier ce qui limite réellement l’architecture existante.

👉 À ce titre, notre article [10 signes que votre CMS e-commerce freine votre croissance] permet d’identifier les principaux signaux à surveiller.

  1. Rapport 2024 sur les tendances et les données du commerce B2B ↩︎

Nous contacter

  • Paris

    82 bis/84 rue de la Procession
    75015 Paris

    01 41 19 40 40

  • Nanterre

    93-105 rue Veuve Lacroix
    92000 Nanterre

    01 41 19 40 40

  • Lyon

    45 quai Rambaud
    69002 – Lyon

    04 78 64 56 06

  • Lille

    393 rue du Général de Gaulle

    59700 Marcq-en-baroeul

    01 42 12 28 22

  • Bordeaux

    10 rue Thomas Edison, Parc Ampéris, Bâtiment Baya
    33600 Pessac

    05 17 12 98 97

  • Strasbourg

    7 Boulevard de Dresde
    67000 Strasbourg

    01 41 19 40 40 

  • Troyes

    2 rue de Berlin
    10300 Saint-Savine

    03 25 43 74 00

  • Arras

    Zone Artoipole
    245 Boulevard de l’Europe
    62 118 Monchy-le-Preux

    03 21 22 21 21

  • Nantes

    3 Rue Alessandro Volta
    44 470 Carquefou

    02 96 58 06 06

     

  • Papeete

    P.O Box 608
    98713 Papeete

    +689 87 23 44 061

  • Saint-Brieuc

    10 Rue de la prunelle

    ZA des longs Réages
    22190 Plérin

    02 96 58 06 00

  • Montigny

    8 Avenue des 3 Peuples
    78180 Montigny-le-Bretonneux

    01 41 19 40 40

  • Montbéliard

    P.A Valparc / Le Quasar 3
    25200 Montbéliard

    03 81 34 50 50

Racontez-nous une histoire


    Les réponses aux rubriques « civilité », « nom », « prénom », « email professionnel » et « numéro de téléphone » sont obligatoires et nécessaires pour traiter vos demandes de contact et d’information. Les réponses aux autres rubriques sont facultatives.
    Les informations collectées sont traitées conformément à la Politique de confidentialité
    .

    *Conformément à la loi n° 78-17 du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés telle que modifiée, et au Règlement (UE) 2016/679 du Parlement Européen et du Conseil du 27 avril 2016, vous pouvez exercer votre droit d’accès, de rectification, d’opposition, d’effacement et de portabilité en envoyant une demande écrite accompagnée d’un justificatif d’identité valide à dpo@groupe-cyllene.com ou DPO – CYLLENE – 93/99, rue Veuve Lacroix 92000 Nanterre.

    Votre message a été envoyé avec succès.

    Merci pour votre message. Nous allons en prendre connaissance et revenons vers vous dans les meilleurs délais. Préparez-vous à grimper en haut du sommet !

    C’est compris