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

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.

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

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.

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.

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.

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

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

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

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.

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 ?

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.

Sylius vs PrestaShop : quelle plateforme pour un e-commerce complexe ?

prestashop vs Sylius

Choisir une plateforme e-commerce ne consiste pas à déterminer laquelle est « la meilleure ». PrestaShop et Sylius répondent à des logiques différentes, et le bon choix dépend surtout du niveau de complexité du projet, de ses ambitions et de son système d’information.

Pour un e-commerce standard, avec un lancement rapide et des besoins couverts par des fonctionnalités existantes, PrestaShop peut être un choix parfaitement pertinent. Pour un projet nécessitant une forte personnalisation, des règles métier spécifiques ou une architecture e-commerce profondément intégrée au SI, Sylius peut offrir davantage de liberté.

Alors, Sylius ou PrestaShop pour un e-commerce complexe ? Voici les critères à regarder avant de choisir.

A RETENIR

  • PrestaShop est particulièrement adapté aux projets e-commerce standards nécessitant un time-to-market rapide et bénéficiant d’un vaste écosystème de modules.
  • Sylius est davantage adapté aux projets nécessitant une personnalisation poussée et une architecture construite autour des besoins métier.
  • Le nombre de modules n’est pas le seul critère : leur interdépendance et leur impact sur la maintenance comptent également.
  • Les projets B2B, les règles métier complexes et les intégrations importantes avec un ERP, un PIM ou un CRM peuvent favoriser une approche comme Sylius.
  • Sylius n’est pas « meilleur » que PrestaShop. Il répond à une autre catégorie de projets.

PrestaShop : un choix pertinent pour les projets e-commerce standards

PrestaShop est une solution open source mature, largement utilisée pour les projets e-commerce qui recherchent avant tout rapidité de déploiement, couverture fonctionnelle et écosystème.

Son principal avantage est son catalogue de modules et de thèmes. Paiement, livraison, SEO, marketing, internationalisation ou fonctionnalités commerciales : de nombreux besoins standards peuvent être couverts sans développement spécifique.

C’est un avantage important lorsqu’une entreprise souhaite lancer rapidement son activité ou faire évoluer un catalogue sans construire chaque fonctionnalité elle-même.

Le choix de PrestaShop peut donc être particulièrement pertinent lorsque :

  • les besoins fonctionnels sont relativement standards ;
  • le time-to-market est prioritaire ;
  • les fonctionnalités recherchées existent déjà sous forme de modules ;
  • les règles métier restent limitées ;
  • l’architecture du SI n’impose pas de nombreux développements spécifiques.

Le vaste écosystème PrestaShop constitue d’ailleurs l’un de ses principaux atouts. Le document comparatif fourni recense plus de 7 000 modules et thèmes dans son marketplace.

PrestaShop n’est donc pas une solution à écarter lorsqu’un projet devient important. La vraie question est plutôt de savoir si son modèle d’extension reste cohérent avec la complexité du projet.

Sylius : quand le projet devient un problème d’architecture

Sylius suit une logique différente. Il s’agit d’une solution e-commerce open source construite sur Symfony, davantage pensée comme un framework e-commerce permettant de construire une plateforme adaptée au métier que comme un CMS que l’on enrichit principalement avec des modules.

Le document comparatif résume bien cette différence : PrestaShop est présenté comme une application e-commerce prête à l’emploi, tandis que Sylius fournit un socle à construire et à étendre autour de la logique métier.

Cette approche devient particulièrement intéressante lorsque le projet doit gérer :

  • des règles commerciales complexes ;
  • des catalogues ou tarifs spécifiques ;
  • des parcours B2B particuliers ;
  • plusieurs types d’utilisateurs ou de comptes ;
  • plusieurs canaux de vente ;
  • des intégrations nombreuses avec le SI ;
  • des fonctionnalités différenciantes ;
  • une architecture API-first ou headless.

C’est notamment le cas de projets B2B complexes, pour lesquels les besoins dépassent largement le simple catalogue + panier + paiement. Pour approfondir ce sujet, voir notre article Sylius pour le e-commerce B2B : dans quels cas est-il pertinent ?.

Sylius vs PrestaShop : le vrai comparatif

Il est tentant de comparer les deux plateformes fonctionnalité par fonctionnalité. Mais pour un projet complexe, les critères les plus intéressants sont souvent l’architecture, la personnalisation et la capacité d’évolution.

BesoinPrestaShopSylius
E-commerce standard✅
Time-to-market✅
Personnalisation poussée✅
Règles métier complexes✅
Architecture sur mesure✅
SI complexe✅
B2B spécifique✅
Écosystème de modules✅
Maîtrise du code✅

Cette grille synthétise les critères du comparatif fourni, notamment les différences d’approche entre écosystème de modules, personnalisation, architecture et coût d’évolution.

Attention

Toutefois : ce tableau ne signifie pas que PrestaShop serait incapable de gérer un projet complexe. Il indique simplement quelle philosophie de plateforme devient la plus naturelle selon le contexte.

Le critère souvent oublié : le coût d’évolution

Le prix initial d’une plateforme ne suffit pas pour comparer deux solutions.

Il faut également regarder le TCO — Total Cost of Ownership, c’est-à-dire le coût total de possession sur plusieurs années.

Dans une approche fortement basée sur les modules, il faut prendre en compte :

  • les licences ou abonnements ;
  • les renouvellements ;
  • la compatibilité entre extensions ;
  • les mises à jour ;
  • la maintenance ;
  • les développements spécifiques ;
  • les tests de non-régression ;
  • les éventuels conflits entre modules.

Cela ne signifie pas qu’un développement sur mesure est automatiquement moins cher.

Un module peut être beaucoup plus économique lorsqu’il répond précisément à un besoin standard. À l’inverse, développer une fonctionnalité métier spécifique peut être plus cohérent lorsqu’elle constitue un élément important du fonctionnement de l’entreprise.

Le document comparatif rappelle d’ailleurs qu’aucune des deux approches n’est universellement moins chère : tout dépend de l’adéquation entre les besoins et les fonctionnalités disponibles.

Notre article sur le coût caché des plateformes e-commerce : modules vs développement sur mesure détaille cette logique de TCO.

Et si le véritable sujet était votre système d’information ?

Pour un e-commerce complexe, la plateforme ne fonctionne jamais seule.

Elle doit échanger avec :

ERP → e-commerce → PIM → CRM → paiement → logistique → outils métiers

La question devient alors : quelle plateforme permet de construire une architecture cohérente autour de votre SI ?

C’est notamment là que l’approche API-first peut devenir intéressante. Elle permet de considérer le moteur e-commerce comme une brique d’un écosystème plus large plutôt que comme le centre unique de toute l’expérience digitale.

Pour comprendre cette logique, voir notre article API-first e-commerce : définition, avantages et cas d’usage.

Et lorsque l’entreprise souhaite dissocier davantage le front-end du moteur e-commerce, l’approche headless commerce peut également entrer en considération. Elle apporte de la liberté, mais aussi davantage de complexité : elle ne doit donc pas être choisie uniquement parce qu’elle est technologiquement attractive.

B2B : quand la complexité métier devient déterminante

Le B2B est un bon exemple de situation où le choix de plateforme mérite d’être étudié au-delà des fonctionnalités standards.

Tarifs négociés, catalogues par client, comptes multi-utilisateurs, rôles et droits, commandes spécifiques, workflows de validation ou intégration ERP peuvent rapidement modifier la nature du projet.

Dans ce contexte, l’enjeu n’est plus simplement de disposer d’une boutique en ligne. Il faut construire une plateforme capable de traduire les règles commerciales de l’entreprise.

C’est ce type de contexte qui peut rendre Sylius particulièrement pertinent.

Chez Cyllene, cette approche se retrouve notamment dans le projet B2B réalisé pour Bollinger, avec une plateforme sur mesure, synchronisation avec le SI, gestion des commandes et processus métier spécifiques.

Faut-il migrer de PrestaShop vers Sylius ?

Pas nécessairement. Avant de changer de plateforme, il faut d’abord comprendre ce qui pose réellement problème.

Votre PrestaShop peut très bien continuer à répondre à vos besoins si :

  • les performances sont satisfaisantes ;
  • les modules restent maîtrisables ;
  • les mises à jour sont correctement gérées ;
  • les évolutions restent raisonnables ;
  • les intégrations fonctionnent correctement ;
  • votre roadmap ne nécessite pas une architecture plus spécifique.

À l’inverse, certains signaux peuvent justifier une réflexion :

  • chaque évolution devient longue ou coûteuse ;
  • les modules s’empilent ;
  • les mises à jour deviennent risquées ;
  • les développements spécifiques se multiplient ;
  • les intégrations ERP/PIM/CRM deviennent difficiles ;
  • les performances deviennent problématiques ;
  • la plateforme limite les ambitions B2B ou omnicanales.

Notre article PrestaShop → Sylius : faut-il migrer ou moderniser ? approfondit justement cette question et présente trois trajectoires possibles : optimiser l’existant, le moderniser progressivement ou envisager une migration.

Alors, Sylius ou PrestaShop ?

La réponse dépend finalement moins de la plateforme que du projet que vous devez construire.

Si votre priorité est…La plateforme à étudier en priorité
Lancer rapidement un e-commerce standardPrestaShop
Utiliser un vaste écosystème de modulesPrestaShop
Réduire le développement spécifiquePrestaShop
Construire des règles métier spécifiquesSylius
Maîtriser l’architecture et le codeSylius
Intégrer un SI complexeSylius
Construire une plateforme B2B spécifiqueSylius
Faire évoluer fortement l’architectureSylius

Sylius n’est pas « meilleur » que PrestaShop. Il répond à une autre catégorie de projets.

C’est cette distinction qui doit guider la décision.

Le bon choix n’est donc pas celui de la technologie la plus puissante sur le papier. C’est celui qui offre le meilleur équilibre entre besoins métier, coût d’évolution, architecture, compétences disponibles et ambitions de l’entreprise.

Et avant d’envisager une migration, un audit de l’existant permet souvent de déterminer si le problème vient réellement de la plateforme — ou de son architecture, de ses modules et de ses intégrations.

Chez Cyllene, cette réflexion fait partie de notre approche e-commerce : choix de plateforme, architecture, intégration au SI, performance et évolutivité. Notre expertise e-commerce et Sylius s’adresse notamment aux projets B2B complexes, B2C à fort volume et environnements nécessitant une forte intégration ERP, PIM ou CRM.

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

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 ?

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.

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

Qu’est-ce qu’un CMS headless ?

cms headless

Le CMS headless est une architecture qui sépare la gestion des contenus de leur présentation. Le contenu est administré dans un back-office puis diffusé via des API vers un ou plusieurs front-ends.

Cette approche offre davantage de liberté pour construire des expériences digitales sur mesure et réutiliser les mêmes contenus sur plusieurs canaux.

Mais une confusion persiste : un CMS headless n’est pas une plateforme e-commerce. Le premier gère principalement les contenus ; la seconde porte la logique commerciale : catalogue, prix, panier, commandes, paiement, etc.

Alors, comment fonctionne un CMS headless ? Quels sont ses avantages et ses limites ? Et surtout, dans quels projets cette architecture est-elle réellement pertinente ?

L'essentiel à retenir

Un CMS headless sépare le contenu de son affichage. Les contenus sont gérés dans un back-office et exposés via des API à des applications ou front-ends indépendants.

Son principal intérêt : pouvoir faire évoluer l’expérience utilisateur, réutiliser les contenus et multiplier les canaux sans nécessairement remettre en cause le système de gestion de contenu.

Son principal inconvénient : cette liberté implique davantage de conception, de développement et de gouvernance.

À ne pas confondre : un CMS headless gère les contenus. Une plateforme e-commerce gère l’activité commerciale. Les deux peuvent fonctionner ensemble.

Qu’est-ce qu’un CMS ?

Un CMS (Content Management System) est un système permettant de créer, organiser et publier des contenus numériques.

Dans un CMS traditionnel, la gestion du contenu et sa présentation sont généralement fortement liées. Le CMS fournit le back-office, mais également une partie des mécanismes permettant d’afficher les pages.

Un CMS headless adopte une logique différente : le système conserve la gestion des contenus, mais dissocie leur présentation.

Le contenu est exposé via des API. Un front-end indépendant vient ensuite récupérer ces données pour construire l’expérience visible par l’utilisateur.

Le terme headless, « sans tête », fait donc référence à l’absence de couche de présentation directement attachée au CMS.

 Un CMS headless = un back-office de contenu + des API + un ou plusieurs front-ends indépendants.

Comment fonctionne un CMS headless ?

Le fonctionnement peut être résumé en trois grandes briques :

1. Le CMS
Les équipes éditoriales créent et organisent les contenus dans le back-office.

2. Les API
Elles permettent aux applications et front-ends de récupérer ces contenus.

3. Le ou les front-ends
Ils utilisent les données du CMS pour construire l’expérience visible par l’utilisateur.

Exemple concret

Une marque publie un guide d’achat dans son CMS.

Avec une architecture headless, ce contenu peut être utilisé sur son site web, mais également dans une application mobile ou un portail client, sans devoir recréer le contenu dans chaque interface.

Le CMS devient ainsi une source de contenu, tandis que chaque front-end décide de la manière dont ce contenu est présenté.

Quels sont les avantages d’un CMS headless ?

Une plus grande liberté sur le front-end

Le principal avantage du headless est de ne plus dépendre du système de templates du CMS pour construire l’expérience utilisateur.

Les développeurs peuvent choisir les technologies front-end adaptées au projet et concevoir des interfaces spécifiques aux besoins de l’entreprise.

Cette liberté peut être particulièrement intéressante lorsque l’expérience digitale constitue un véritable élément de différenciation.

Une meilleure réutilisation des contenus

Un contenu créé dans le CMS peut être exposé à plusieurs applications.

L’entreprise évite ainsi de recréer ou de maintenir manuellement le même contenu dans plusieurs systèmes.

Cela devient particulièrement pertinent lorsqu’une marque dispose de plusieurs sites, pays, applications ou points de contact.

Une architecture adaptée à l’omnicanal

Le CMS n’est plus pensé uniquement pour « alimenter un site ».

Il devient une source de contenu pouvant être consommée par différentes interfaces.

Le headless peut donc accompagner des stratégies dans lesquelles les contenus doivent circuler entre plusieurs canaux numériques.

Une évolution plus indépendante des différentes couches

Le front-end et le CMS pouvant évoluer séparément, une refonte de l’expérience utilisateur ne nécessite pas nécessairement de remplacer le système de gestion de contenu.

Inversement, le CMS peut évoluer sans imposer une refonte complète du front-end.

Cette indépendance constitue l’un des intérêts majeurs du découplage.

Quelles sont les limites d’un CMS headless ?

Le headless apporte de la flexibilité, mais cette flexibilité n’est pas gratuite.

Une architecture plus technique

Un projet headless peut nécessiter plusieurs briques : CMS, API, front-end, hébergement, moteur de recherche, gestion des médias, analytics, authentification et autres services.

Il faut donc concevoir les interactions entre ces composants et définir clairement les responsabilités de chacun.

Davantage de développement

Un CMS headless ne fournit généralement pas une expérience front-end complète prête à l’emploi.

Le front-end doit être développé et maintenu indépendamment. Cela demande des compétences techniques et peut augmenter le coût initial du projet.

Une gouvernance indispensable

Lorsque plusieurs systèmes communiquent, les questions de gouvernance deviennent importantes :

  • quelle donnée est la source de référence ?
  • qui peut modifier les contenus ?
  • comment les API évoluent-elles ?
  • comment gérer les droits et la sécurité ?
  • comment maintenir la cohérence entre les canaux ?

Le headless ne supprime donc pas la complexité : il déplace une partie de cette complexité vers l’architecture et le développement.

CMS headless et SEO : attention aux raccourcis

Le headless n’est ni un avantage SEO automatique, ni un inconvénient SEO automatique.

Le référencement dépend notamment de la manière dont le front-end est construit : rendu des pages, HTML accessible aux moteurs, URLs, balises, liens internes, données structurées et performances.

Google peut explorer et rendre du JavaScript, mais précise que certaines contraintes existent et recommande notamment de prendre en compte le rendu côté serveur ou statique lorsque cela est pertinent.

Le SEO doit donc être intégré dès la conception de l’architecture, plutôt qu’ajouté une fois le front-end terminé.

CMS headless vs plateforme e-commerce : quelles différences ?

Un CMS headless et une plateforme e-commerce ne répondent pas au même besoin.

CMS headlessPlateforme e-commerce
Fonction principaleGérer et diffuser des contenusGérer l’activité commerciale
ContenusArticles, pages, médias, contenus éditoriauxProduits, catégories, contenus commerciaux
PrixNonOui
PanierNonOui
CommandesNonOui
PaiementNonOui
Comptes clientsSelon le CMS, mais pas comme cœur commercialOui
Front-endPeut être indépendantPeut être intégré ou découplé
APIGénéralement centrale dans une approche headlessPeut permettre un fonctionnement headless/API-first

Une architecture digitale peut donc utiliser les deux. Par exemple :

CMS headless → contenus éditoriaux
PIM → données produit
Plateforme e-commerce → catalogue commercial, panier, commandes
CRM → relation client
Front-end → expérience utilisateur

Le front-end peut alors agréger ces différentes sources pour construire une expérience cohérente.

CMS headless, headless commerce et API-first : quelle différence ?

Ces notions sont proches mais désignent des choses différentes.

CMS headless

Il concerne le découplage entre la gestion des contenus et leur présentation.

Headless commerce

Il concerne le découplage entre le moteur e-commerce et le front-end.

API-first

Il s’agit d’une approche dans laquelle les API occupent une place centrale dans la conception des services et de leurs échanges.

On peut donc retrouver les trois approches dans une même architecture.

Pour approfondir cette logique, découvrez notre article API-first e-commerce : définition, avantages et cas d’usage.

Dans quels cas utiliser un CMS headless ?

Le headless peut être pertinent dans plusieurs situations.

Plusieurs canaux de diffusion

Une entreprise souhaite gérer ses contenus depuis un point central tout en les diffusant sur son site, son application ou différents portails.

Plusieurs sites ou marques

Un groupe dispose de plusieurs expériences digitales qui partagent certains contenus mais nécessitent des interfaces différentes.

Une expérience très personnalisée

Le front-end doit s’affranchir des contraintes d’un système de templates traditionnel.

Un écosystème applicatif complexe

Le CMS doit communiquer avec plusieurs briques du système d’information et alimenter différentes expériences.

En revanche, pour un site simple, avec un seul canal et des besoins éditoriaux standards, une architecture traditionnelle peut rester parfaitement adaptée.

Comment construire une architecture headless ?

Avant de choisir une solution, mieux vaut partir du besoin plutôt que de la technologie.

architecture headless : comment la construire ?

Cette démarche permet d’éviter un écueil fréquent : adopter une architecture headless uniquement parce qu’elle est présentée comme plus moderne.

Faut-il passer au headless ?

Pas forcément.

Le headless est pertinent lorsqu’il répond à un besoin concret : multiplication des canaux, forte personnalisation du front-end, réutilisation des contenus ou nécessité de faire évoluer indépendamment certaines briques du système.

À l’inverse, si les besoins sont simples, une architecture traditionnelle peut être plus facile à exploiter et à maintenir.

Le bon choix dépend donc moins de la tendance technologique que de l’équilibre entre besoins métier, expérience utilisateur, contraintes techniques et capacité de maintenance.

Dans un contexte e-commerce, cette réflexion doit également porter sur l’ensemble de l’architecture et pas uniquement sur le CMS. Si votre solution actuelle commence à limiter vos évolutions, découvrez notre article 10 signes que votre CMS e-commerce freine votre croissance.

Comment choisir son agence / intégrateur Sylius en France ?

choix integrateur sylius

Choisir une agence ou un intégrateur Sylius ne consiste pas simplement à trouver un partenaire qui maîtrise la technologie. Pour une création ou une refonte e-commerce complexe, le choix doit surtout porter sur sa capacité à comprendre vos enjeux métier, concevoir une architecture adaptée, connecter votre système d’information et accompagner la plateforme dans la durée.

B2B, B2C ou modèle hybride, migration depuis Magento ou PrestaShop, catalogue complexe, règles tarifaires spécifiques, ERP, PIM ou CRM : les critères à examiner ne sont pas les mêmes que pour un projet e-commerce standard.

Alors, comment comparer les agences Sylius en France et identifier le partenaire adapté à son projet ?

A RETENIR

  • Vérifiez l’expérience réelle de l’agence sur des projets Sylius comparables au vôtre.
  • Analysez ses références B2B, B2C, migrations et projets à forte complexité métier.
  • Évaluez sa capacité à intégrer ERP, PIM, CRM et autres briques du SI.
  • Ne vous limitez pas à l’équipe commerciale : identifiez les profils qui interviendront réellement sur le projet.
  • Anticipez dès le départ la performance, la maintenance et les évolutions futures.

Définition

Intégrateur Sylius

Un intégrateur Sylius accompagne une entreprise dans la conception, le développement, l’intégration, la mise en production et l’évolution d’une plateforme e-commerce basée sur Sylius. Son rôle peut couvrir le cadrage, l’architecture, les développements spécifiques, les connexions au SI, la migration et la TMA.

1. Vérifier l’expertise réelle de l’agence sur Sylius

Toutes les agences qui proposent Sylius n’ont pas nécessairement le même niveau d’expérience.

Le premier réflexe consiste donc à regarder l’ancienneté dans l’écosystème Sylius, le niveau de partenariat, les contributions éventuelles à l’écosystème et surtout les projets réellement livrés.

L’annuaire officiel permet notamment d’identifier les partenaires Sylius présents en France et leurs différents niveaux d’implication dans l’écosystème. Consulter l’annuaire officiel des partenaires Sylius en France

Mais un badge ou un niveau de partenariat ne suffit pas à lui seul. Demandez surtout :

  • Combien de projets Sylius avez-vous réalisés ?
  • Sur quelles versions ?
  • Quels types de clients accompagnez-vous ?
  • Pouvez-vous présenter des projets comparables au mien ?
  • Quelle part de l’équipe travaille régulièrement sur Sylius ?

Privilégiez les références concrètes plutôt qu’une simple liste de compétences techniques.

2. Regarder les références sur des projets comparables

Une agence peut parfaitement maîtriser Sylius sans avoir l’expérience d’un projet présentant vos contraintes.

Un site B2C avec un catalogue relativement simple n’implique pas les mêmes problématiques qu’une plateforme B2B avec plusieurs grilles tarifaires, des droits utilisateurs, des workflows de commande ou des règles commerciales spécifiques.

Avant de choisir, cherchez donc des références présentant des caractéristiques proches :

Votre projetRéférences à rechercher
E-commerce B2BTarification, comptes clients, droits, workflows
B2C à fort volumePerformance, trafic, catalogue, conversion
B2B/B2C hybridePlusieurs modèles commerciaux sur une même plateforme
RefonteMigration de données, SEO, redirections, continuité de service
SI complexeERP, PIM, CRM, DAM, SSO, middleware
InternationalMulti-pays, multi-langues, multi-devises

Une bonne référence n’est donc pas nécessairement la plus prestigieuse : c’est celle qui permet de démontrer que l’agence sait résoudre des problématiques similaires aux vôtres.

3. Évaluer la capacité à gérer la complexité métier

Sylius prend particulièrement son sens lorsque le fonctionnement de l’entreprise nécessite des règles spécifiques qui dépassent les fonctionnalités standard d’une plateforme e-commerce.

Cela peut concerner :

  • les règles de prix et de remises ;
  • les catalogues par client ou groupe de clients ;
  • les règles de disponibilité ;
  • les workflows de commande ;
  • les conditions de livraison ;
  • les comptes et droits utilisateurs ;
  • les marketplaces ou espaces revendeurs ;
  • les spécificités de facturation.

L’enjeu n’est pas de développer du spécifique pour le principe. Il est de déterminer ce qui doit être standardisé, ce qui doit être configuré et ce qui justifie réellement un développement métier spécifique.

Lors des échanges avec une agence, présentez vos règles métier avant de parler de fonctionnalités. La qualité des questions et des réponses obtenues est souvent un meilleur indicateur que la démonstration d’une solution déjà préparée.

4. Vérifier les intégrations avec votre système d’information

Pour un projet e-commerce complexe, le site n’est qu’une brique du système d’information.

L’agence doit être capable de comprendre les flux entre le e-commerce et les autres applications :

ERP → e-commerce
Stocks, prix, commandes, clients, facturation.

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

CRM → e-commerce
Clients, comptes, données commerciales et parcours.

Selon les projets, d’autres briques peuvent également intervenir : DAM, SSO, middleware, solutions de paiement, transporteurs ou outils métiers.

Il faut donc vérifier non seulement si l’agence « sait connecter un ERP », mais si elle possède une expérience concrète des architectures et flux correspondant à votre SI.

5. Ne pas négliger l’expérience de migration

Une refonte Sylius implique souvent une migration depuis une autre solution : Magento, PrestaShop ou une plateforme développée sur mesure.

Le sujet dépasse largement l’import des produits. Une migration doit notamment prendre en compte :

  • les données produits et clients ;
  • l’historique des commandes ;
  • les URLs et redirections 301 ;
  • les règles tarifaires ;
  • les comptes utilisateurs ;
  • les intégrations existantes ;
  • les performances ;
  • le référencement naturel ;
  • les flux et interfaces avec le SI.

Demandez à l’agence comment elle prépare et sécurise une migration, mais aussi comment elle prévoit les phases de recette, de bascule et de suivi post-production.

6. Évaluer architecture, performance et évolutivité

Un projet Sylius ne doit pas être évalué uniquement sur ce qui fonctionne au lancement.

L’architecture doit pouvoir accompagner les évolutions du catalogue, du trafic, des fonctionnalités et du système d’information.

Interrogez l’agence sur :

  • les choix d’architecture ;
  • la stratégie de cache ;
  • la gestion des pics de trafic ;
  • les performances front et back ;
  • la supervision ;
  • la sécurité ;
  • les possibilités d’évolution.

Point de vigilance

Attention également aux effets de mode : headless, API-first ou composable ne sont pas automatiquement synonymes de meilleure architecture.

Le bon choix dépend des objectifs, du SI existant, des équipes disponibles et du niveau de complexité du projet.

7. Comprendre qui va réellement vous accompagner

La taille de l’agence ne dit pas nécessairement grand-chose sur la qualité de l’accompagnement.

Une structure importante peut proposer de nombreuses expertises, tandis qu’une équipe plus réduite peut apporter davantage de proximité. L’essentiel est de comprendre comment l’équipe projet est réellement organisée.

Avant de signer, demandez :

  • Qui sera mon interlocuteur au quotidien ?
  • Quels profils participeront au projet ?
  • Les développeurs présentés lors de l’avant-vente seront-ils ceux du projet ?
  • Où sont basées les équipes ?
  • Comment travaillent-elles avec les équipes métier ?
  • Quelle est la disponibilité du partenaire pendant les phases critiques ?

à vérifier

Ne choisissez pas uniquement une agence : choisissez également l’équipe qui va réellement construire et faire évoluer votre plateforme.

8. Anticiper la maintenance et l’après-mise en production

La mise en ligne n’est pas la fin d’un projet e-commerce.

Une plateforme Sylius évolue avec l’entreprise : nouvelles règles métier, nouveaux connecteurs, évolutions réglementaires, optimisation des performances, mises à jour techniques ou nouveaux parcours clients.

Il est donc utile d’évaluer dès l’avant-vente :

  • les modalités de TMA ;
  • les délais d’intervention ;
  • la supervision ;
  • la gestion des incidents ;
  • les mises à jour de sécurité ;
  • les évolutions fonctionnelles ;
  • la capacité à accompagner les montées en charge.

Une agence capable de construire le projet mais pas de l’accompagner dans la durée n’est pas nécessairement le meilleur choix pour une plateforme stratégique.

La grille pour comparer plusieurs agences Sylius

Pour objectiver les échanges, vous pouvez attribuer une note à chaque agence sur les critères suivants :

CritèreQuestion à poser
Expertise SyliusCombien de projets Sylius réellement livrés ?
RéférencesDes projets comparables au mien ?
B2B / B2CExpérience de mon modèle commercial ?
Complexité métierCapacité à gérer des règles spécifiques ?
IntégrationsERP, PIM, CRM et autres briques déjà intégrés ?
MigrationExpérience Magento, PrestaShop ou autre solution ?
ArchitectureMéthodologie pour garantir performance et évolutivité ?
ÉquipeQui travaillera concrètement sur le projet ?
AccompagnementQuel dispositif de pilotage et de collaboration ?
TMAQuelle organisation après la mise en production ?

Cette grille permet surtout de comparer des agences sur des éléments objectifs plutôt que sur leur discours commercial.

Des critères vérifiés sur des projets réels Cyllene

Innelec : une refonte B2B où la compréhension métier fait la différence

7000 références produits à gérer
6 agences Sylius consultées

Le projet B2B sous Sylius, Innelec, constitue notamment un exemple de refonte B2B complexe : migration depuis Magento 2.3, règles de prix, de fiscalité et de livraison spécifiques, intégrations PIM, CRM et Sage, ainsi qu’une architecture API-first.

Innelec a retenu Cyllene, notamment pour sa compréhension des enjeux métier, ses réponses concrètes et son accompagnement à taille humaine. Découvrir Cyllene, intégrateur Sylius expérimenté

Bollinger : quand Sylius s’adapte à des processus B2B spécifiques

Autre exemple, le projet réalisé pour le Groupe Bollinger porte sur un portail B2B intégrant notamment ERP, PIM/DAM et SSO. Environ 80 à 90 % des commandes de ses quelque 200 clients sont désormais réalisées via le portail.

Ces références permettent d’illustrer concrètement plusieurs critères à examiner lors du choix d’un intégrateur : complexité métier, intégration au SI, B2B, migration, performance et accompagnement dans la durée.

Cyllene est partenaire officiel Sylius depuis 2022 et dispose du niveau Professional Solution Partner.

Voir le profil Cyllene sur l’annuaire officiel Sylius

les 10 questions à poser avant de choisir son agence Sylius

  1. Combien de projets Sylius l’agence a-t-elle réellement livrés ?
  2. A-t-elle déjà accompagné des entreprises avec un niveau de complexité comparable ?
  3. Dispose-t-elle de références B2B, B2C ou hybrides similaires ?
  4. A-t-elle déjà intégré votre type d’ERP, PIM ou CRM ?
  5. Maîtrise-t-elle les migrations depuis votre plateforme actuelle ?
  6. Comment aborde-t-elle l’architecture et la performance ?
  7. Qui composera réellement l’équipe projet ?
  8. Comment seront organisés le pilotage et les échanges avec vos équipes ?
  9. Quel dispositif est prévu après la mise en production ?
  10. Pouvez-vous échanger avec un client ayant réalisé un projet comparable ?

En conclusion

Choisir son agence Sylius revient moins à trouver le partenaire le plus visible qu’à identifier celui qui comprend réellement votre projet.

Pour une création ou une refonte e-commerce complexe, comparez les agences sur des critères concrets : expertise Sylius, références comparables, complexité métier, intégrations SI, migration, architecture, équipe et accompagnement dans la durée.

Cette méthode permet de construire une short-list de partenaires réellement adaptés à votre contexte, plutôt que de choisir uniquement sur la base d’un niveau de partenariat ou d’un discours commercial.

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.