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 specialisees plutot que de subir les limites d'un monolithe. Commercetools, CommerceLayer et Saleor incarnent trois visions differentes de ce paradigme. Les trois sont API-first. Les trois sont headless. Mais leur perimetre fonctionnel, leur modele economique et leur philosophie architecturale divergent radicalement.

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

Commercetools est la reference enterprise pour les grands comptes avec des budgets consequents et des exigences d'integration complexes. CommerceLayer excelle pour les multi-boutiques et le B2B international grace a son modele d'Order Management. Saleor est le choix open source moderne pour les equipes Python/GraphQL voulant une solution composable sans les couts 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 perimetre fonctionnel, vos integrations et votre cout de possession.

#Commercetools : le moteur commerce complet, multi-API

Commercetools couvre l'integralite du cycle commerce : catalogue produits, pricing, promotions, panier, checkout, order management, customer profiles, inventaire. Chaque domaine est expose via des APIs REST et GraphQL separees. Le modele de donnees est le plus riche du marche : Product Types, Product Variants, Custom Fields, Product Selections, Stores -- chaque concept metier a son endpoint dedie.

L'architecture est multi-tenant SaaS, deployee sur AWS et GCP en multi-region (EU, US, Asie). Commercetools gere l'infrastructure, les mises a 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 systemes internes (ERP, PIM, CRM).

La puissance de Commercetools reside dans sa granularite. Chaque appel API est atomique. Vous pouvez mettre a 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 reference du marche enterprise, avec des clients comme REWE, BMW, Levi's et de nombreuses ETI francaises en transformation digitale.

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

CommerceLayer adopte une philosophie radicalement differente. 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 deja gere ailleurs. Au lieu de dupliquer les donnees produit dans un moteur commerce, CommerceLayer se contente d'un identifiant produit (SKU) et gere tout le reste : prix par marche, stocks par entrepot, regles fiscales par pays, modes de paiement par region.

L'API est RESTful (JSON:API), bien documentee, et deployee sur une infrastructure edge Cloudflare. Les performances de checkout sont parmi les meilleures du marche : temps de reponse API inferieur a 80 ms en P95 sur les endpoints de commande. CommerceLayer est multi-tenant SaaS, certifie ISO 27001, avec hebergement EU disponible.

Le modele 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 regles fiscales differents. 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) developpee 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 consideree comme l'une des meilleures du secteur en termes de coherence et de completude. Chaque mutation retourne les donnees mises a jour, les erreurs sont typees et documentees, et les subscriptions WebSocket permettent de reagir aux evenements en temps reel. Un frontend Next.js connecte a Saleor peut afficher un panier mis a jour en temps reel sans polling.

Saleor couvre catalogue, checkout, paiements (Stripe, Adyen integres), order management, promotions, utilisateurs et permissions. Le perimetre fonctionnel est comparable a Commercetools pour les cas d'usage B2C et B2B standards. Les fonctionnalites B2B avancees (Company accounts, B2B pricing, canaux de vente multiples) ont ete ajoutees en 2025-2026.

Le modele economique est dual : la version auto-hebergee est gratuite et entierement customisable. La version Cloud (SaaS gere par Saleor) demarre a partir de 890 $/mois. L'auto-hebergement sur OVH ou Hetzner garantit une souverainete des donnees totale -- un argument de poids pour les ETI europeennes soumises aux contraintes RGPD.

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

#Tableau comparatif sur 10 criteres

Les scores traduisent la capacite de chaque plateforme a repondre au critere pour une ETI ou grande entreprise en 2026. Un 5/5 signifie que la plateforme excelle nativement sans contournement technique.

#GraphQL vs REST : quel modele d'API pour quel projet

Le choix entre GraphQL et REST n'est pas anodin. Il conditionne l'experience developpeur, les performances frontend et la complexite de maintenance.

#Commercetools : le double jeu REST + GraphQL

Commercetools expose ses deux APIs en parallele. 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 avancees (Import API, Subscriptions management) restent uniquement en REST.

En pratique, les projets Commercetools utilisent GraphQL pour le frontend (requetes de catalogue, panier, checkout) et REST pour les integrations backend (import de produits, webhooks, operations administratives). Cette dualite offre de la flexibilite mais impose de maitriser les deux modeles.

#CommerceLayer : REST pur, JSON:API

CommerceLayer a fait le choix du REST pur avec la specification JSON:API. Les endpoints sont previsibles, la pagination standardisee, les relations explicites. Pour les equipes habituees aux APIs REST classiques, la courbe d'apprentissage est minimale.

La contrepartie du REST pur est le probleme classique d'over-fetching et under-fetching. Pour afficher une page produit avec prix, stock et promotions, le frontend doit enchainer plusieurs appels API la ou GraphQL pourrait tout recuperer en une seule requete. CommerceLayer compense partiellement via les includes JSON:API (eager loading de relations), mais l'experience developpeur reste inferieure 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 documentee, typee et testable via le playground GraphQL integre. Les subscriptions WebSocket permettent de recevoir des evenements en temps reel (commande creee, stock mis a 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 categorie entiere de bugs runtime. Les requetes sont optimisees : le frontend ne demande que les champs necessaires, ce qui reduit la taille des payloads et ameliore les performances reseau.

Le choix GraphQL-only de Saleor est un frein pour les integrations backend classiques. Les ERP, les connecteurs ETL et les outils d'import de donnees sont souvent concus pour consommer du REST. Integrer SAP ou Oracle avec une API GraphQL necessite une couche d'adaptation supplementaire.

#Moteur de pricing et gestion multi-devises

Le pricing est le nerf de la guerre en commerce composable. La capacite a gerer 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 modele multi-dimensionnel : chaque prix est defini par canal de vente, groupe client, pays, devise et periode de validite. Un meme produit peut avoir des centaines de prix differents selon la combinaison de ces dimensions. Le moteur de promotions supporte les remises par produit, par categorie, par panier, par code promo, par volume et par combinaison de conditions booleennes.

La gestion multi-devises est native : chaque Store peut operer dans sa propre devise avec des taux de change configurables. Les taxes sont calculees par pays et par categorie de produit, avec support de la TVA europeenne (OSS inclus).

#CommerceLayer : le pricing par marche

CommerceLayer gere les prix via ses Price Lists, associees a des marches (Markets). Chaque marche a sa devise, ses regles fiscales, ses modes de paiement et ses prix. Le modele 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) necessitent du developpement 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 systeme de vouchers gere les coupons a usage unique ou limite.

La gestion multi-devises est native depuis la v2 : chaque Channel peut operer dans sa propre devise. La conversion de devises n'est pas automatique -- les prix doivent etre definis 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 ecosysteme 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 determinante.

#Commercetools + PIM : l'integration de reference

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 donnees 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 maturite d'integration reduit le risque et le temps de deploiement.

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

#CommerceLayer + PIM : le tandem naturel

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

L'integration CommerceLayer + Contentful est particulierement bien documentee. 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 reel. Nehos a deploye 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 systeme 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 entites PIM vers les entites Saleor.

Cette approche est plus flexible mais plus couteuse en developpement qu'un connecteur certifie Commercetools. Pour les projets ou le PIM est deja en place, comptez 2 a 4 semaines de developpement supplementaire pour la couche de synchronisation.

#Checkout, B2B et personnalisation du parcours d'achat

Le checkout est le moment critique du parcours e-commerce. La capacite a personnaliser ce parcours, a gerer des workflows B2B complexes et a integrer 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 etape du parcours (panier, adresse, livraison, paiement, confirmation) est construite via les APIs. Cette approche donne un controle total sur l'experience utilisateur, mais impose un developpement frontend significatif.

Les fonctionnalites B2B de Commercetools sont les plus avancees du segment. Le modele Business Units permet de modeliser des hierarchies d'entreprise (siege, filiales, departements). Les approval workflows gerent les circuits de validation de commandes avec des roles (acheteur, valideur, administrateur). Le systeme de quotes gere les demandes de devis avec negociation et contre-offre. Les Associate Roles definissent 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 europeens.

Le B2B chez CommerceLayer passe par son modele multi-marches. Chaque marche peut avoir ses propres conditions de paiement (paiement a 30 jours, virement bancaire), ses propres regles de livraison et ses propres prix. Les comptes entreprise avec hierarchie 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 dediees (checkoutCreate, checkoutLinesAdd, checkoutPaymentCreate, checkoutComplete). Chaque etape est une mutation atomique, ce qui permet de construire des parcours d'achat non lineaires (save for later, edit in place, one-page checkout).

Les fonctionnalites B2B de Saleor sont en maturite croissante. Les Company accounts permettent de gerer des comptes entreprise avec plusieurs utilisateurs. Le B2B pricing gere des grilles tarifaires par canal. Les fonctionnalites d'approval workflows et de gestion de devis restent moins matures que Commercetools -- pour les cas B2B complexes, un developpement custom est necessaire.

#Cout total de possession et modeles tarifaires

Le budget est souvent le facteur decisif. Les trois plateformes ont des modeles economiques radicalement differents.

#Commercetools : tarification enterprise basee sur le GMV

La tarification Commercetools est basee sur le GMV (Gross Merchandise Value) et les appels API. Les plans demarrent a partir de 846 EUR/an pour les petits volumes (plan Essentials). Pour une ETI avec 2 500 000 EUR de GMV annuel, le cout 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-dela.

A la licence s'ajoutent les couts de developpement frontend (le frontend est entierement a construire), les integrations (PIM, ERP, paiement) et la maintenance. Un projet Commercetools realiste pour une ETI revient a partir de 109 472 EUR la premiere annee (licence + developpement + integrations).

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

#CommerceLayer : tarification basee sur les commandes

CommerceLayer facture selon le nombre de commandes traitees. Le plan Developer demarre a partir de 992 EUR/mois. Les plans Growth et Enterprise montent selon le volume de commandes et les fonctionnalites (multi-marches, SLA dedies, support premium).

L'avantage de ce modele : la previsibilite. Le cout 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 economique que Commercetools.

A la licence s'ajoutent les couts du PIM ou CMS (puisque CommerceLayer ne gere pas le catalogue), le frontend et les integrations. Un projet CommerceLayer + Contentful + Next.js revient a partir de 78 000 EUR la premiere annee.

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

#Saleor : open source ou Cloud gere

Saleor auto-heberge est gratuit (licence Apache 2.0). Les couts se limitent a l'hebergement (OVH ou Hetzner, a partir de 80 EUR/mois pour une configuration production), au developpement frontend et aux integrations. Un projet Saleor auto-heberge avec Next.js revient a partir de 42 000 EUR la premiere annee.

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

Estimation TCO 3 ans pour Saleor auto-heberge : a partir de 68 000 EUR (developpement + hebergement + maintenance). Estimation TCO 3 ans pour Saleor Cloud : a partir de 95 000 EUR (licence Cloud + developpement + maintenance).

Pour estimer le budget de votre projet specifique, 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 concu pour les grands volumes. Son SLA garantit 99,99 % de disponibilite et une latence API inferieure a 50 ms en P99. Des marques traitant des millions de commandes par an tournent en production sur Commercetools. La scalabilite est geree par la plateforme : le marchand ne provisionne pas d'infrastructure.

CommerceLayer s'appuie sur une infrastructure edge Cloudflare qui distribue les requetes a l'echelle 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 adequat. 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-dela de 50 000 000 EUR de GMV annuel, la scalabilite de Saleor est moins eprouvee que celle de Commercetools. Saleor Cloud gere la scalabilite pour vous, mais les SLA sont moins detailles 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 donnees. Le modele de donnees Magento (EAV pour les produits, multi-store natif, systeme de prix par groupe client) ne se mappe pas directement sur les modeles de donnees 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 equivalente ou superieure. Duree typique : 6 a 18 mois selon la complexite des integrations ERP. Budget a partir de 180 000 EUR.

Vers CommerceLayer : pertinent si le catalogue est deja dans un PIM (Akeneo, Pimcore). La migration porte alors uniquement sur le checkout, l'OMS et les integrations de paiement. Duree typique : 3 a 8 mois. Budget a partir de 90 000 EUR.

Vers Saleor : la migration la plus economique. 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. Duree typique : 4 a 10 mois. Budget a partir de 65 000 EUR.

#Migration depuis Shopify Plus

La migration depuis Shopify Plus est generalement motivee par le vendor lock-in, le cout des commissions sur transactions ou les limites fonctionnelles B2B.

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

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

Notre Barometre headless commerce France 2026 detaille les tendances de migration par plateforme sur un echantillon de 120 sites e-commerce francais.

#Quel choix selon votre cas

Chaque profil d'entreprise a une plateforme naturelle. Voici nos recommandations basees 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 maturite de ses integrations ERP justifient le cout (200 000+ EUR/an). Prevoir 12 a 24 mois pour un deploiement complet avec integration SAP.

Marque internationale avec 15 boutiques dans 10 pays et checkout unifie : CommerceLayer est la solution la plus elegante pour ce cas d'usage. Son modele multi-boutiques natif avec gestion des devises, taxes et paiements par marche est concu exactement pour ce scenario.

Scale-up tech avec equipe Python, budget SaaS maitrise : Saleor Cloud est le meilleur compromis entre fonctionnalites, couts et maturite technique. L'API GraphQL est excellente, le dashboard admin pret a l'emploi, et l'auto-hebergement reste possible en cas de croissance.

ETI voulant un commerce composable avec souverainete des donnees EU : Saleor auto-heberge sur OVH ou Hetzner est l'option la plus souveraine. Pimcore peut gerer 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'experience 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 cout le rend inabordable hors grands comptes. CommerceLayer est sous-estime en France -- son modele OMS-first est tres 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'ecosysteme 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 element de l'architecture globale. Un Saleor bien integre avec un PIM et un CMS headless est plus performant qu'un Commercetools mal configure sans strategie d'integration.

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 cout de possession est soutenable sur trois ans. Commercetools pour les grands comptes. CommerceLayer pour les multi-boutiques. Saleor pour la souverainete 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 specialises (PIM, OMS, CMS, moteur de recherche, paiement) via des APIs plutot que d'utiliser une plateforme monolithique. Les avantages : flexibilite, scalabilite independante de chaque composant, liberte de changer un composant sans reconstruire le tout. L'inconvenient : complexite d'integration et d'orchestration.

Commercetools est-il vraiment accessible aux ETI francaises ?

Oui, depuis 2024, Commercetools propose des plans Essentials a partir de 992 EUR/mois pour les petits volumes. Mais une implementation realiste (developpement frontend, integrations, deploiement) porte le budget total a partir de 109 472 EUR la premiere annee. C'est accessible pour des ETI au-dessus de 1 200 000 EUR de GMV avec un business case clair.

Saleor peut-il gerer un catalogue de 100 000 references produits ?

Oui, Saleor est concu pour les grands catalogues. Son architecture PostgreSQL avec indexation ElasticSearch (ou Algolia) tient 100 000+ references. Plusieurs clients en production depassent ce seuil. La cle est l'infrastructure d'hebergement (PostgreSQL bien dimensionne, Redis pour le cache, worker async pour les taches lourdes).

CommerceLayer gere-t-il la TVA et les taxes europeennes ?

Oui, CommerceLayer dispose d'un moteur de taxe natif configurable par marche. Il s'integre egalement avec des solutions specialisees comme Avalara et TaxJar pour les calculs de TVA automatises. La conformite OSS (One Stop Shop) pour la TVA e-commerce EU est supportee.

Quelle est la difference 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'execution des commandes, laissant le catalogue au PIM ou au CMS. Les deux approches sont valides selon votre contexte : si vous avez deja un PIM, un OMS est plus leger a deployer.

#Pour aller plus loin

• Barometre 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