Commercetools vs CommerceLayer vs Saleor — Quelle Plateforme API-First Choisir ?

#Commercetools vs CommerceLayer vs Saleor 2026 -- Quel moteur API-first pour votre commerce composable

Le commerce composable repose sur un principe simple : assembler des briques spécialisées plutôt que de subir les limites d'un monolithe. Commercetools, CommerceLayer et Saleor incarnent trois visions différentes de ce paradigme. Les trois sont API-first. Les trois sont headless. Mais leur périmètre fonctionnel, leur modèle économique et leur philosophie architecturale divergent radicalement.

Ce comparatif s'appuie sur notre experience de déploiement en production chez des clients B2B et B2C. Pas de théorie : des retours terrain sur des projets reels, des chiffres de performances mesures et des budgets constates.

Commercetools est la référence enterprise pour les grands comptes avec des budgets conséquents et des exigences d'intégration complexes. CommerceLayer excelle pour les multi-boutiques et le B2B international grâce à son modèle d'Order Management. Saleor est le choix open source moderne pour les equipes Python/GraphQL voulant une solution composable sans les coûts de licence Commercetools.

#Architecture API-first : trois approches du commerce decouple

La distinction entre ces trois plateformes ne se limite pas a une question de langage ou de stack technique. C'est une divergence architecturale profonde qui conditionne votre périmètre fonctionnel, vos intégrations et votre coût de possession.

#Commercetools : le moteur commerce complet, multi-API

Commercetools couvre l'intégralité du cycle commerce : catalogue produits, pricing, promotions, panier, checkout, order management, customer profiles, inventaire. Chaque domaine est expose via des APIs REST et GraphQL séparées. Le modèle de données est le plus riche du marche : Product Types, Product Variants, Custom Fields, Product Selections, Stores -- chaque concept métier a son endpoint dedie.

L'architecture est multi-tenant SaaS, déployée sur AWS et GCP en multi-region (EU, US, Asie). Commercetools gere l'infrastructure, les mises à jour, la scalabilite. Le marchand ne touche jamais au backend : il consomme les APIs depuis un frontend decouple (Next.js, Nuxt, Remix) ou depuis des systèmes internes (ERP, PIM, CRM).

La puissance de Commercetools reside dans sa granularite. Chaque appel API est atomique. Vous pouvez mettre à jour un prix sans toucher au produit, ajouter un item au panier sans recalculer les taxes, modifier une promotion sans invalider le cache du catalogue. Cette granularite est un avantage pour les architectures microservices complexes -- et un surengineering pour les projets simples.

Commercetools est membre fondateur de la MACH Alliance (Microservices, API-first, Cloud-native, Headless), le consortium qui certifie les plateformes composable. C'est le standard de référence du marche enterprise, avec des clients comme REWE, BMW, Levi's et de nombreuses ETI françaises en transformation digitale.

#CommerceLayer : l'OMS API-first, sans catalogue

CommerceLayer adopte une philosophie radicalement différente. Il ne gere pas le catalogue produits. Il se concentre sur la couche transactionnelle : checkout, paiement, order management, fulfillment, retours. Le catalogue reste dans votre PIM (Akeneo, Pimcore, Contentful) ou dans votre CMS (Payload, Strapi, Contentful).

Cette approche OMS-first simplifie l'architecture pour les projets ou le catalogue est déjà géré ailleurs. Au lieu de dupliquer les données produit dans un moteur commerce, CommerceLayer se contente d'un identifiant produit (SKU) et gere tout le reste : prix par marche, stocks par entrepot, règles fiscales par pays, modes de paiement par région.

L'API est RESTful (JSON:API), bien documentée, et déployée sur une infrastructure edge Cloudflare. Les performances de checkout sont parmi les meilleures du marche : temps de réponse API inférieur a 80 ms en P95 sur les endpoints de commande. CommerceLayer est multi-tenant SaaS, certifie ISO 27001, avec hébergement EU disponible.

Le modèle multi-boutiques natif est le vrai differenciateur de CommerceLayer. Une seule instance gere des dizaines de marches avec des prix, des devises, des modes de paiement et des règles fiscales différents. Pour les marques internationales avec 10 ou 15 boutiques dans autant de pays, cette architecture evite de multiplier les instances de plateforme.

#Saleor : le moteur commerce open source, GraphQL-first

Saleor est une plateforme e-commerce API-first open source (licence Apache 2.0) développée en Python/Django avec une API GraphQL complete. Lance en 2012 et refonde en 2019 sur une architecture headless, Saleor combine les avantages du composable commerce et de l'open source.

L'API GraphQL de Saleor est considérée comme l'une des meilleures du secteur en termes de coherence et de completude. Chaque mutation retourne les données mises à jour, les erreurs sont typées et documentées, et les subscriptions WebSocket permettent de réagir aux evenements en temps réel. Un frontend Next.js connecte a Saleor peut afficher un panier mis à jour en temps réel sans polling.

Saleor couvre catalogue, checkout, paiements (Stripe, Adyen intégrés), order management, promotions, utilisateurs et permissions. Le périmètre fonctionnel est comparable a Commercetools pour les cas d'usage B2C et B2B standards. Les fonctionnalités B2B avancées (Company accounts, B2B pricing, canaux de vente multiples) ont été ajoutées en 2025-2026.

Le modèle économique est dual : la version auto-hébergée est gratuite et entièrement customisable. La version Cloud (SaaS gere par Saleor) demarre à partir de 890 $/mois. L'auto-hébergement sur OVH ou Hetzner garantit une souveraineté des données totale -- un argument de poids pour les ETI européennes soumises aux contraintes RGPD.

Pour approfondir les différences entre architecture headless et monolithique, consultez notre Headless vs monolithe commerce -- comparatif.

#Tableau comparatif sur 10 critères

Critère	Commercetools	CommerceLayer	Saleor
API-first architecture	5/5 -- REST + GraphQL, granularite maximale	5/5 -- REST JSON:API, edge Cloudflare	5/5 -- GraphQL-first, subscriptions WebSocket
Modèle données	5/5 -- Product Types, Custom Fields, Stores	4/5 -- SKU-centric, pas de catalogue natif	4/5 -- Products, Variants, Attributes, Channels
Prix composable	2/5 -- à partir de 846 EUR/an, monte vite	3/5 -- à partir de 992 EUR/mois, base commandes	5/5 -- open source gratuit, Cloud à partir de 890 $/mois
Performances API	5/5 -- SLA 99,99 %, latence P99 < 50 ms	5/5 -- edge Cloudflare, P95 < 80 ms checkout	4/5 -- depend de l'infra, PostgreSQL bien dimensionné
B2B multi-boutiques	5/5 -- Business Units, quotes, approval workflows	5/5 -- multi-marches natif, prix/devises par boutique	4/5 -- Channels, B2B pricing, maturité croissante
Integrations marketplace	5/5 -- connecteurs certifies SAP, Oracle, Salesforce	4/5 -- integrations custom, moins d'off-the-shelf	3/5 -- plugins communautaires, dev custom requis
Certification EU	5/5 -- SOC 2 Type II, ISO 27001, RGPD, hébergement EU	5/5 -- ISO 27001, hébergement EU, RGPD	4/5 -- auto-hébergement EU possible, Cloud US par défaut
Complexité déploiement	3/5 -- onboarding 3 a 6 mois, equipe MACH requise	4/5 -- déploiement en semaines si PIM déjà en place	4/5 -- déploiement 2 a 4 mois, stack Python/PostgreSQL
Documentation	5/5 -- reference du marche, exemples exhaustifs	4/5 -- claire et complete, moins d'exemples avances	4/5 -- bonne couverture GraphQL, communauté active
Communauté développeurs	5/5 -- écosystème certifie le plus large	3/5 -- communauté plus petite, croissance rapide	4/5 -- Discord 15 000+ membres, contributions open source

Les scores traduisent la capacité de chaque plateforme a répondre au critère pour une ETI ou grande entreprise en 2026. Un 5/5 signifie que la plateforme excelle nativement sans contournement technique.

#GraphQL vs REST : quel modèle d'API pour quel projet

Le choix entre GraphQL et REST n'est pas anodin. Il conditionne l'expérience développeur, les performances frontend et la complexité de maintenance.

#Commercetools : le double jeu REST + GraphQL

Commercetools expose ses deux APIs en parallèle. L'API REST est la plus ancienne et la plus complete : chaque ressource (Product, Cart, Order, Customer, Payment, Discount) dispose de son endpoint CRUD. L'API GraphQL couvre une surface fonctionnelle large mais pas identique -- certaines operations avancées (Import API, Subscriptions management) restent uniquement en REST.

En pratique, les projets Commercetools utilisent GraphQL pour le frontend (requêtes de catalogue, panier, checkout) et REST pour les intégrations backend (import de produits, webhooks, operations administratives). Cette dualité offre de la flexibilité mais impose de maîtriser les deux modèles.

#CommerceLayer : REST pur, JSON:API

CommerceLayer a fait le choix du REST pur avec la specification JSON:API. Les endpoints sont prévisibles, la pagination standardisée, les relations explicites. Pour les equipes habituées aux APIs REST classiques, la courbe d'apprentissage est minimale.

La contrepartie du REST pur est le problème classique d'over-fetching et under-fetching. Pour afficher une page produit avec prix, stock et promotions, le frontend doit enchaîner plusieurs appels API la ou GraphQL pourrait tout récupérer en une seule requête. CommerceLayer compense partiellement via les includes JSON:API (eager loading de relations), mais l'expérience développeur reste inférieure a GraphQL pour les interfaces complexes.

#Saleor : GraphQL-first, sans compromis

Saleor a construit son API exclusivement en GraphQL. Pas de REST en fallback. Chaque query et mutation est documentée, typée et testable via le playground GraphQL integre. Les subscriptions WebSocket permettent de recevoir des evenements en temps réel (commande créée, stock mis à jour, paiement confirme).

Pour les equipes frontend modernes (React, Next.js, Vue), GraphQL est un avantage net. Le typage fort (genere via GraphQL Code Generator) elimine une catégorie entière de bugs runtime. Les requêtes sont optimisées : le frontend ne demande que les champs nécessaires, ce qui réduit la taille des payloads et ameliore les performances réseau.

Le choix GraphQL-only de Saleor est un frein pour les intégrations backend classiques. Les ERP, les connecteurs ETL et les outils d'import de données sont souvent conçus pour consommer du REST. Intégrer SAP ou Oracle avec une API GraphQL necessite une couche d'adaptation supplémentaire.

#Moteur de pricing et gestion multi-devises

Le pricing est le nerf de la guerre en commerce composable. La capacité a gérer des grilles tarifaires complexes, des promotions conditionnelles et des devises multiples differencie les plateformes enterprise des solutions mid-market.

#Commercetools : le pricing le plus granulaire du marche

Commercetools gere les prix via un modèle multi-dimensionnel : chaque prix est défini par canal de vente, groupe client, pays, devise et période de validité. Un meme produit peut avoir des centaines de prix différents selon la combinaison de ces dimensions. Le moteur de promotions supporte les remises par produit, par catégorie, par panier, par code promo, par volume et par combinaison de conditions booléennes.

La gestion multi-devises est native : chaque Store peut opérer dans sa propre devise avec des taux de change configurables. Les taxes sont calculées par pays et par catégorie de produit, avec support de la TVA européenne (OSS inclus).

#CommerceLayer : le pricing par marche

CommerceLayer gere les prix via ses Price Lists, associées a des marches (Markets). Chaque marche a sa devise, ses règles fiscales, ses modes de paiement et ses prix. Le modèle est moins granulaire que Commercetools (pas de prix par groupe client natif), mais plus simple a configurer pour les cas multi-boutiques standards.

Le moteur de promotions est fonctionnel mais moins avance que Commercetools : remises par pourcentage, par montant fixe, free shipping, codes promo. Les promotions conditionnelles complexes (buy X get Y, tiered pricing, bundles dynamiques) nécessitent du développement custom via les webhooks.

#Saleor : le pricing par canal

Saleor gere les prix via ses Channels. Chaque canal a sa devise et ses prix. Les promotions couvrent les cas standards : codes promo, remises par pourcentage ou montant fixe, ventes flash avec dates de debut et fin. Le système de vouchers gere les coupons a usage unique ou limite.

La gestion multi-devises est native depuis la v2 : chaque Channel peut opérer dans sa propre devise. La conversion de devises n'est pas automatique -- les prix doivent être définis explicitement par Channel. Pour les catalogues avec des milliers de produits et des dizaines de devises, cette approche implique une gestion de prix plus lourde qu'avec Commercetools.

#Integration PIM et écosystème composable

Dans une architecture composable, le moteur commerce n'est qu'une brique parmi d'autres. L'integration avec un PIM (Product Information Management), un CMS headless, un OMS et un moteur de recherche est déterminante.

#Commercetools + PIM : l'intégration de référence

Commercetools s'integre nativement avec les PIM majeurs du marche. Les connecteurs Akeneo et Pimcore sont certifies et maintenus. Le flux standard est : le PIM gere les données produit (descriptions, images, attributs, categories) et les synchronise avec Commercetools via des APIs. Commercetools gere le pricing, le stock et les transactions.

L'integration avec les ERP (SAP, Oracle, Microsoft Dynamics) est le point fort historique de Commercetools. Les connecteurs certifies couvrent la synchronisation bidirectionnelle des commandes, des stocks et des prix. Pour les grandes entreprises avec un SI existant, cette maturité d'intégration réduit le risque et le temps de déploiement.

Pour un comparatif detaille des solutions PIM, consultez notre Akeneo vs Pimcore vs Plytix -- PIM integre.

#CommerceLayer + PIM : le tandem naturel

CommerceLayer est conçu pour fonctionner avec un PIM ou un CMS en complement. Il ne gere pas le catalogue : les SKU sont references par identifiant, et les données produit (titre, description, images) sont servies par le PIM ou le CMS au frontend. Cette separation est un avantage architectural : chaque système fait ce qu'il fait de mieux, sans duplication de données.

L'integration CommerceLayer + Contentful est particulièrement bien documentée. Le CMS gere le contenu et la structure des pages, CommerceLayer gere les prix et le checkout. Le frontend Next.js assemble les deux en temps réel. Nehos a déployé cette architecture sur des projets multi-boutiques avec 8 marches en production.

#Saleor + PIM : integration via API et webhooks

Saleor gere son propre catalogue (Products, Variants, Attributes, Categories) mais s'integre avec des PIM via son système de webhooks et ses APIs GraphQL. L'integration avec Akeneo ou Pimcore necessite un middleware de synchronisation (script Node.js ou Python) qui mappe les entités PIM vers les entités Saleor.

Cette approche est plus flexible mais plus coûteuse en développement qu'un connecteur certifie Commercetools. Pour les projets ou le PIM est déjà en place, comptez 2 a 4 semaines de développement supplémentaire pour la couche de synchronisation.

#Checkout, B2B et personnalisation du parcours d'achat

Le checkout est le moment critique du parcours e-commerce. La capacité a personnaliser ce parcours, a gérer des workflows B2B complexes et a intégrer des modes de paiement multiples differencie les plateformes.

#Commercetools : le checkout le plus flexible du marche

Commercetools ne fournit pas de checkout pre-construit. Chaque étape du parcours (panier, adresse, livraison, paiement, confirmation) est construite via les APIs. Cette approche donne un controle total sur l'expérience utilisateur, mais impose un développement frontend significatif.

Les fonctionnalités B2B de Commercetools sont les plus avancées du segment. Le modèle Business Units permet de modéliser des hierarchies d'entreprise (siege, filiales, départements). Les approval workflows gerent les circuits de validation de commandes avec des roles (acheteur, valideur, administrateur). Le système de quotes gere les demandes de devis avec négociation et contre-offre. Les Associate Roles définissent des permissions granulaires par utilisateur.

#CommerceLayer : le checkout optimise, multi-marches

CommerceLayer propose un checkout API-first avec des composants frontend pre-construits (Drop-in.js). Le parcours est personnalisable tout en restant rapide a implementer. Les integrations de paiement natives couvrent Stripe, Adyen, Braintree, PayPal et les modes de paiement locaux européens.

Le B2B chez CommerceLayer passe par son modèle multi-marches. Chaque marche peut avoir ses propres conditions de paiement (paiement a 30 jours, virement bancaire), ses propres règles de livraison et ses propres prix. Les comptes entreprise avec hiérarchie de roles sont geres via l'API Customers et les tags de segmentation.

#Saleor : le checkout GraphQL, personnalisable en profondeur

Saleor expose son checkout via des mutations GraphQL dédiées (checkoutCreate, checkoutLinesAdd, checkoutPaymentCreate, checkoutComplete). Chaque étape est une mutation atomique, ce qui permet de construire des parcours d'achat non linéaires (save for later, edit in place, one-page checkout).

Les fonctionnalités B2B de Saleor sont en maturité croissante. Les Company accounts permettent de gérer des comptes entreprise avec plusieurs utilisateurs. Le B2B pricing gere des grilles tarifaires par canal. Les fonctionnalités d'approval workflows et de gestion de devis restent moins matures que Commercetools -- pour les cas B2B complexes, un développement custom est nécessaire.

#Coût total de possession et modèles tarifaires

Le budget est souvent le facteur décisif. Les trois plateformes ont des modèles économiques radicalement différents.

#Commercetools : tarification enterprise basée sur le GMV

La tarification Commercetools est basée sur le GMV (Gross Merchandise Value) et les appels API. Les plans démarrent à partir de 846 EUR/an pour les petits volumes (plan Essentials). Pour une ETI avec 2 500 000 EUR de GMV annuel, le coût de licence atteint 50 000 EUR/an et plus. Les grands comptes (49 600 000 EUR+ de GMV) paient 194 000 EUR/an et au-delà.

A la licence s'ajoutent les coûts de développement frontend (le frontend est entièrement a construire), les intégrations (PIM, ERP, paiement) et la maintenance. Un projet Commercetools réaliste pour une ETI revient à partir de 109 472 EUR la première année (licence + développement + integrations).

Estimation TCO 3 ans pour une ETI avec 2 500 000 EUR de GMV : à partir de 248 000 EUR.

#CommerceLayer : tarification basée sur les commandes

CommerceLayer facture selon le nombre de commandes traitées. Le plan Developer demarre à partir de 992 EUR/mois. Les plans Growth et Enterprise montent selon le volume de commandes et les fonctionnalités (multi-marches, SLA dédiés, support premium).

L'avantage de ce modèle : la prévisibilité. Le coût n'est pas correle au GMV mais au volume de transactions. Pour les marques avec un panier moyen eleve et un volume de commandes modere, CommerceLayer est plus économique que Commercetools.

A la licence s'ajoutent les coûts du PIM ou CMS (puisque CommerceLayer ne gere pas le catalogue), le frontend et les intégrations. Un projet CommerceLayer + Contentful + Next.js revient à partir de 78 000 EUR la première année.

Estimation TCO 3 ans pour une ETI avec 5 000 commandes/mois : à partir de 185 000 EUR.

#Saleor : open source ou Cloud gere

Saleor auto-heberge est gratuit (licence Apache 2.0). Les coûts se limitent a l'hébergement (OVH ou Hetzner, à partir de 80 EUR/mois pour une configuration production), au développement frontend et aux integrations. Un projet Saleor auto-heberge avec Next.js revient à partir de 42 000 EUR la première année.

Saleor Cloud (SaaS gere) demarre à partir de 890 $/mois. L'infrastructure, les mises à jour et le monitoring sont geres par Saleor. Le Cloud est adapte aux equipes qui veulent se concentrer sur le frontend sans gérer le DevOps backend.

Estimation TCO 3 ans pour Saleor auto-heberge : à partir de 68 000 EUR (développement + hébergement + maintenance). Estimation TCO 3 ans pour Saleor Cloud : à partir de 95 000 EUR (licence Cloud + développement + maintenance).

Pour estimer le budget de votre projet spécifique, utilisez notre Estimateur budget refonte e-commerce B2B.

#Scalabilite, performances et migration depuis Magento ou Shopify Plus

#Scalabilite : du mid-market au grand compte

Commercetools est conçu pour les grands volumes. Son SLA garantit 99,99 % de disponibilité et une latence API inférieure a 50 ms en P99. Des marques traitant des millions de commandes par an tournent en production sur Commercetools. La scalabilite est gérée par la plateforme : le marchand ne provisionne pas d'infrastructure.

CommerceLayer s'appuie sur une infrastructure edge Cloudflare qui distribue les requêtes à l'échelle mondiale. Les performances de checkout sont constantes quel que soit le volume. La scalabilite est transparente pour le marchand sur les plans Growth et Enterprise.

Saleor auto-heberge requiert un dimensionnement d'infrastructure adéquat. PostgreSQL bien configure avec Redis pour le cache et des workers async pour les taches lourdes tient 100 000+ references produits et plusieurs milliers de commandes par jour. Au-delà de 50 000 000 EUR de GMV annuel, la scalabilite de Saleor est moins éprouvée que celle de Commercetools. Saleor Cloud gere la scalabilite pour vous, mais les SLA sont moins détaillés que ceux de Commercetools.

#Migration depuis Magento 2

La migration depuis Magento 2 vers une plateforme composable est un projet de transformation, pas une simple migration de données. Le modèle de données Magento (EAV pour les produits, multi-store natif, système de prix par groupe client) ne se mappe pas directement sur les modèles de données de Commercetools, CommerceLayer ou Saleor.

Vers Commercetools : la migration la plus fluide pour les grands comptes. Les connecteurs d'import existent, la surface fonctionnelle B2B est équivalente ou supérieure. Durée typique : 6 a 18 mois selon la complexité des intégrations ERP. Budget à partir de 180 000 EUR.

Vers CommerceLayer : pertinent si le catalogue est déjà dans un PIM (Akeneo, Pimcore). La migration porte alors uniquement sur le checkout, l'OMS et les intégrations de paiement. Durée typique : 3 a 8 mois. Budget à partir de 90 000 EUR.

Vers Saleor : la migration la plus économique. Les scripts d'import Python permettent de migrer les produits, categories, clients et commandes historiques via l'API GraphQL. Le frontend est reconstruit en Next.js. Durée typique : 4 a 10 mois. Budget à partir de 65 000 EUR.

#Migration depuis Shopify Plus

La migration depuis Shopify Plus est généralement motivée par le vendor lock-in, le coût des commissions sur transactions ou les limites fonctionnelles B2B.

Vers Commercetools : justifie pour les marques dépassant 10 000 000 EUR de GMV annuel avec des besoins B2B avances que Shopify ne couvre pas. La migration des données (produits, clients, commandes) se fait via les APIs. Le développement du frontend est le poste le plus lourd. Durée typique : 6 a 12 mois.

Vers Saleor : justifie pour les equipes techniques voulant éliminer le vendor lock-in et les commissions sur transactions. L'export Shopify (CSV ou API) alimente les scripts d'import Saleor. Durée typique : 3 a 6 mois.

Notre Baromètre headless commerce France 2026 detaille les tendances de migration par plateforme sur un échantillon de 120 sites e-commerce français.

#Quel choix selon votre cas

Chaque profil d'entreprise a une plateforme naturelle. Voici nos recommandations basées sur les projets que nous avons accompagnes.

Grande entreprise avec 49 600 000 EUR+ de GMV, multi-marches EU et integration SAP : Commercetools est le standard du marche pour ce profil. Ses certifications enterprise, ses SLAs et la maturité de ses intégrations ERP justifient le coût (200 000+ EUR/an). Prévoir 12 a 24 mois pour un déploiement complet avec intégration SAP.

Marque internationale avec 15 boutiques dans 10 pays et checkout unifie : CommerceLayer est la solution la plus élégante pour ce cas d'usage. Son modèle multi-boutiques natif avec gestion des devises, taxes et paiements par marche est conçu exactement pour ce scenario.

Scale-up tech avec equipe Python, budget SaaS maitrise : Saleor Cloud est le meilleur compromis entre fonctionnalités, coûts et maturité technique. L'API GraphQL est excellente, le dashboard admin prêt a l'emploi, et l'auto-hébergement reste possible en cas de croissance.

ETI voulant un commerce composable avec souveraineté des données EU : Saleor auto-heberge sur OVH ou Hetzner est l'option la plus souveraine. Pimcore peut gérer le PIM en complement. L'ensemble constitue une stack composable 100 % EU et open source.

Projet avec CMS headless existant (Contentful, Payload) a completer avec un moteur commerce : CommerceLayer est ideal pour ce cas. Il se greffe sur n'importe quel CMS existant comme couche de transaction sans remplacer la gestion du contenu. Integration en quelques semaines contre plusieurs mois pour Commercetools.

#Retour d'expérience Nehos

Nehos a evalue les trois plateformes dans le cadre de projets clients en 2024-2025. Notre conclusion : Commercetools est surdimensionne pour les ETI sous 2 500 000 EUR de GMV et son coût le rend inabordable hors grands comptes. CommerceLayer est sous-estime en France -- son modèle OMS-first est très adapte aux projets multi-boutiques que nous rencontrons dans la distribution B2B. Saleor est notre recommandation pour les projets greenfield avec des equipes techniques solides et un besoin de controle total : l'API GraphQL est exceptionnelle et l'écosystème Python mature.

Sur tous nos projets composable, nous combinons ces plateformes avec Next.js en frontend et Akeneo ou Pimcore en PIM. Le choix du moteur commerce n'est qu'un élément de l'architecture globale. Un Saleor bien integre avec un PIM et un CMS headless est plus performant qu'un Commercetools mal configure sans stratégie d'intégration.

Le commerce composable n'est pas une question de plateforme, c'est une question d'architecture. La plateforme qui vous convient est celle qui s'integre le mieux dans votre SI existant, que votre equipe maitrise, et dont le coût de possession est soutenable sur trois ans. Commercetools pour les grands comptes. CommerceLayer pour les multi-boutiques. Saleor pour la souveraineté et le controle technique. Les trois sont d'excellents moteurs -- le bon choix depend de votre contexte.

Agence commerce composable Nehos -- Contactez-nous pour un audit de votre projet commerce composable.

#Questions frequentes

Qu'est-ce que l'architecture MACH et pourquoi est-elle importante ?

MACH signifie Microservices, API-first, Cloud-native, Headless. C'est un paradigme d'architecture e-commerce qui consiste a assembler des services spécialisés (PIM, OMS, CMS, moteur de recherche, paiement) via des APIs plutôt que d'utiliser une plateforme monolithique. Les avantages : flexibilité, scalabilite indépendante de chaque composant, liberté de changer un composant sans reconstruire le tout. L'inconvenient : complexité d'intégration et d'orchestration.

Commercetools est-il vraiment accessible aux ETI françaises ?

Oui, depuis 2024, Commercetools propose des plans Essentials à partir de 992 EUR/mois pour les petits volumes. Mais une implémentation réaliste (développement frontend, integrations, déploiement) porte le budget total à partir de 109 472 EUR la première année. C'est accessible pour des ETI au-dessus de 1 200 000 EUR de GMV avec un business case clair.

Saleor peut-il gérer un catalogue de 100 000 references produits ?

Oui, Saleor est conçu pour les grands catalogues. Son architecture PostgreSQL avec indexation ElasticSearch (ou Algolia) tient 100 000+ references. Plusieurs clients en production dépassent ce seuil. La clé est l'infrastructure d'hébergement (PostgreSQL bien dimensionné, Redis pour le cache, worker async pour les taches lourdes).

CommerceLayer gere-t-il la TVA et les taxes européennes ?

Oui, CommerceLayer dispose d'un moteur de taxe natif configurable par marche. Il s'integre également avec des solutions spécialisées comme Avalara et TaxJar pour les calculs de TVA automatises. La conformité OSS (One Stop Shop) pour la TVA e-commerce EU est supportée.

Quelle est la différence entre un moteur e-commerce API-first et un OMS ?

Un moteur e-commerce API-first (Commercetools, Saleor) couvre l'ensemble du cycle : catalogue, pricing, checkout, OMS, promotions. Un OMS (Order Management System) comme CommerceLayer se concentre sur la couche de transaction et d'exécution des commandes, laissant le catalogue au PIM ou au CMS. Les deux approches sont valides selon votre contexte : si vous avez déjà un PIM, un OMS est plus leger a déployer.

#Pour aller plus loin

• Baromètre headless commerce France 2026
• Headless vs monolithe commerce -- comparatif
• Estimateur budget refonte e-commerce B2B
• Akeneo vs Pimcore vs Plytix -- PIM integre
• Agence commerce composable Nehos