Drupal Commerce - Quand Il Surpasse Shopify

Drupal Commerce est la mauvaise réponse pour la plupart des boutiques en ligne. Ce n’est pas une critique du projet, bien conçu depuis quinze ans. C’est un constat sur ce que sont la plupart des boutiques: quelques centaines de références, une devise, des clients particuliers, un paiement par carte à la fin. Pour cette forme d’activité, une plateforme hébergée gagne sur tous les axes qui comptent et le débat est clos avant de commencer.

Il existe une minorité pour laquelle le calcul s’inverse complètement, et elle est lucrative. Des produits configurables qui ne tiennent pas dans une grille de variantes. Des comptes professionnels aux tarifs négociés. Un catalogue qui est aussi le contenu éditorial. Un ERP qui possède le stock et les prix et traite le site comme une surface d’affichage. Là, la plateforme hébergée n’est pas moins chère: c’est un impôt permanent payé en applications, en contournements et en choses que vous n’avez pas le droit de changer.

Cet article situe cette frontière, chiffres à l’appui des deux côtés. Si vous lisez la partie Shopify et reconnaissez votre activité, arrêtez-vous là. Vous économiserez beaucoup et cet article aura fait son travail.

Quand Drupal Commerce surpasse-t-il Shopify? Quand vos produits ne tiennent pas dans une simple grille de variantes, quand deux clients voient des prix différents pour la même référence, quand catalogue et contenu éditorial ne font qu’un, ou quand un ERP fait autorité et que la boutique n’en est qu’une vue. Pour un catalogue grand public classique en une ou deux devises, Shopify coûte moins cher sur trois ans et convertit mieux. La ligne de partage est la complexité produit et tarifaire, pas le trafic ni le chiffre d’affaires.

Ce qu’est réellement Drupal Commerce

Drupal Commerce n’est pas un produit de boutique. C’est un ensemble de types d’entités posé sur le système d’entités et de champs de Drupal, et tout ce qui suit dans cet article découle de cette phrase.

Un produit dans Drupal Commerce est une entité avec un bundle, exactement comme un noeud. Il en va de même d’une variation de produit, d’une commande, d’une ligne de commande, d’un paiement, d’une promotion et d’une boutique. Chacune accepte des champs arbitraires: une variation peut donc porter un numéro de lot, une référence de certificat, un délai en jours ouvrés et une dimension servant à calculer son prix. Rien de tout cela n’est un champ personnalisé greffé sur un schéma figé. C’est le schéma.

L’élément achetable est la variation, pas le produit. Le produit est l’enveloppe de présentation et la variation est l’article doté d’une référence et d’un prix, les attributs engendrant les combinaisons sélectionnables. Un type de produit décide des champs d’un produit, un type de variation décide des attributs que portent ses variations. Rien dans cet agencement ne présuppose du textile, des biens physiques ou un nombre fixe de choix.

La conséquence est que Drupal Commerce n’a presque aucune opinion sur ce que vous vendez. Le prix de cette liberté, c’est qu’il ne fournit presque aucune décision non plus, et quelqu’un doit toutes les prendre.

Où en est Drupal Commerce aujourd’hui

La version recommandée est Drupal Commerce 3.3.8, publiée le 17 juillet 2026, et elle fonctionne avec Drupal 10.3 ou ultérieur et avec Drupal 11. Les versions stables relèvent de la politique de sécurité de Drupal, ce qui compte plus qu’il n’y paraît: une vulnérabilité divulguée donne lieu à une publication coordonnée plutôt qu’à un ticket GitHub.

La page du projet Drupal Commerce recense 35 870 sites utilisant le module. Commerce 3.0.0 a été la première version stable de la branche 3.x, en janvier 2025, et elle a abandonné la prise en charge de Drupal 9. Autour gravite un petit écosystème contribué: Commerce Shipping en est à 3.0.3 avec environ 15 200 installations, et les modules spécialisés évoqués plus bas se comptent en milliers.

Comparez avec WooCommerce, qui déclare plus de 7 millions d’installations actives et exige WordPress 6.9 et PHP 7.4 ou supérieur. Rapporté à la base installée, Drupal Commerce est environ 200 fois plus petit.

Ce rapport est le chiffre le plus important de cet article, et c’est un avertissement, pas une vitrine. Il signifie que la réponse à la question de savoir s’il existe déjà un module est souvent non.

Le vrai plaidoyer pour Shopify

Shopify résout les quatre problèmes qui coulent la plupart des boutiques auto-hébergées, et il les résout avant que vous ayez écrit une ligne de code.

Il est hébergé: disponibilité, montée en charge et correctifs cessent d’être votre poste budgétaire. Il traite les données de carte, si bien que la surface de conformité dont vous héritez est une fraction de ce qu’elle serait autrement. Son tunnel de paiement est éprouvé sur un volume de transactions réelles qu’aucune agence ne peut reproduire, et à cette échelle de petits écarts de conversion valent plus que n’importe quelle préférence d’architecture. Enfin, son écosystème d’applications fait que la plupart des besoins arrivent sous forme d’abonnement plutôt que de projet.

Pour un catalogue grand public de quelques milliers de références, une ou deux devises et sans tarif négocié, aucun des avantages décrits plus loin ne s’applique. Vous paieriez une agence pour reconstruire, en moins bien, ce que vous obtenez aujourd’hui pour £65 par mois.

Disons-le franchement, puisque la suite plaide l’inverse: la plupart des boutiques devraient s’arrêter à Shopify. Si la vôtre en fait partie, notre comparaison entre Shopify et un développement e-commerce sur mesure traite la décision plus en détail que cette page.

Ce que coûte Shopify au Royaume-Uni

Shopify publie ses prix britanniques en livres, aucune conversion n’est donc nécessaire. Relevé sur la page tarifaire de Shopify en septembre 2026: Basic est à £25 par mois en facturation mensuelle ou £19 en annuel, Grow à £65 ou £49, Advanced à £344 ou £259, et Plus démarre à £1 800 par mois. POS Pro ajoute £69 par mois et par point de vente.

Les commissions carte pèsent plus lourd que l’abonnement. Les taux carte en ligne via Shopify Payments sont de 2 % plus 25 p sur Basic, 1,7 % plus 25 p sur Grow et 1,5 % plus 25 p sur Advanced. Le chiffre que l’on oublie le plus souvent est la commission sur prestataire de paiement tiers, prélevée quand vous utilisez une passerelle autre que Shopify Payments: 2 % sur Basic, 1 % sur Grow, 0,6 % sur Advanced et 0,2 % sur Plus.

Cette commission s’ajoute à ce que facture votre passerelle. Pour une boutique réalisant 1 million de livres par an et utilisant un acquéreur externe sur Advanced, la seule commission tierce représente £6 000 par an, soit £18 000 sur trois ans, pour le privilège de ne pas utiliser Shopify Payments.

Là où Shopify manque de place

Les limites sont publiées et elles sont précises. La documentation Shopify sur l’ajout de variantes indique que chaque produit peut avoir jusqu’à trois options et jusqu’à 2 048 variantes, et que dépasser l’une ou l’autre impose une application tierce ou du code de thème qui capture des propriétés de ligne.

Trois options: voilà le plafond qui gêne en premier. Une fenêtre, un panneau imprimé, un store sur mesure ou une machine configurée ont couramment six ou huit choix indépendants, et dès que vous dépassez trois, la plateforme cesse de modéliser votre produit pour l’approximer.

Le tunnel de paiement est le deuxième mur. Les extensions d’interface de tunnel de Shopify pour les étapes information, livraison et paiement ne sont offertes que sur le forfait Plus. En dessous de Plus, vous pouvez habiller le tunnel mais pas y insérer de logique, ce qui exclut le choix de créneau de livraison, la vérification d’encours client et les contrôles de conformité au moment où ils doivent avoir lieu.

La troisième limite est l’accumulation. Chaque manque est comblé par une application, chaque application est un abonnement mensuel et une dépendance de mise à jour, et une boutique dotée de vingt applications a un problème de maintenance qui ressemble beaucoup à celui qu’elle avait fui.

Le plaidoyer pour WooCommerce, et où il fatigue

WooCommerce mérite mieux que le procès qu’on lui fait d’ordinaire. Il est gratuit, il tourne sur un hébergement à quelques dizaines de livres par mois, les données vous appartiennent, et son catalogue d’extensions est de loin le plus vaste de l’e-commerce. Pour une boutique grand public de petite ou moyenne taille dont l’équipe connaît déjà WordPress, c’est souvent la bonne réponse et la moins chère.

Il fatigue à trois endroits prévisibles. Le premier est le modèle de données: les produits sont un type de publication WordPress dont les attributs sont stockés en métadonnées sérialisées, si bien que filtrer un gros catalogue riche en attributs revient à interroger une table clé-valeur plutôt que de vraies colonnes. C’est tenable à 1 000 produits et douloureux à 50 000.

Le deuxième est la performance face au nombre de variantes, la raison la plus fréquente pour laquelle une boutique WooCommerce paraît lente. Nous en avons détaillé la mécanique dans notre article sur les raisons de la lenteur d’une boutique WooCommerce, et en résumé les produits variables multiplient les requêtes, pas les lignes.

Le troisième est la prolifération d’extensions. WooCommerce résout les problèmes en installant des choses, et après quatre ans la boutique est définie par le calendrier de trente éditeurs plutôt que par le vôtre.

Modélisation produit complexe: la première vraie ligne de partage

Le cas le plus net en faveur de Drupal Commerce est un produit que l’on configure au lieu de le choisir. Du tissu vendu au mètre avec frais de coupe. Du vitrage tarifé largeur multipliée par hauteur avec un minimum de facturation. Une machine à huit groupes d’options dont certains en invalident d’autres. De l’impression avec une courbe de dégressivité et des frais de calage par commande.

Rien de tout cela n’est une grille de variantes. Sur une plateforme hébergée, on les approxime avec une application et un jeu de propriétés de ligne, ce qui veut dire que le prix montré au client est calculé hors de la logique tarifaire de la plateforme et devra être rapproché plus tard.

Dans Drupal Commerce, le prix est résolu par du code que vous écrivez. Un résolveur de prix reçoit la variation, la quantité et le contexte courant, et renvoie un prix. Rien d’exotique là-dedans, et cela veut dire que le prix configuré est le vrai prix partout: au panier, dans la commande, dans le calcul de taxe et dans l’export vers l’ERP.

Le test à appliquer est simple. Si vous pouvez écrire votre catalogue sous forme de tableur avec une ligne par article achetable, vous n’avez pas besoin de tout ceci. Sinon, tout le reste de cet article devient pertinent.

Tarifs B2B, listes de prix et conditions négociées

La deuxième ligne de partage est de savoir si deux clients voient un jour des prix différents pour la même référence. Les boutiques grand public répondent non. Les entreprises de négoce répondent oui, et cette réponse est généralement tout leur métier.

Shopify propose bien du B2B, et sa documentation sur les fonctions B2B par forfait confirme qu’il est disponible sur Basic, Grow, Advanced et Plus. Le détail est dans les limites: en dessous de Plus, vous disposez de trois catalogues actifs au maximum sur l’ensemble des marchés B2B, les catalogues d’entreprise directs sont réservés à Plus, tout comme les acomptes, les paiements partiels et les demandes de paiement par expédition. Trois catalogues suffisent pour trois niveaux de prix et ne servent à rien pour quarante comptes négociés.

Côté Drupal, l’équivalent est le module Commerce Price List, actuellement en 8.x-2.16 avec environ 1 662 installations déclarées et un suivi par l’équipe de sécurité. Il fixe des prix par utilisateur ou par rôle, gère des paliers de quantité et des plages de dates, et importe depuis un CSV.

Ce dernier point est le point pratique. Un grossiste avec quarante comptes, chacun sur sa liste convenue, rafraîchie chaque trimestre depuis l’ERP, relève d’un import CSV et non d’une migration de plateforme.

Multi-boutique, multi-devise et multilingue depuis une seule base de code

Une boutique est une entité de premier rang dans Drupal Commerce, et les produits sont affectés aux boutiques autorisées à les vendre. Petite décision de conception, grande conséquence: plusieurs vitrines peuvent partager un catalogue, un pipeline de commandes et une administration, tout en portant des devises, une configuration fiscale, des passerelles de paiement et des règles d’expédition différentes.

La forme habituelle est un site britannique, un site UE et un portail professionnel, tous issus d’un seul déploiement. Les données produit sont saisies une fois. Une liste de prix ne s’applique qu’à la boutique professionnelle. La taxe se résout par boutique, parce que la boutique porte son propre pays de facturation et ses propres immatriculations.

Le coeur de Drupal apporte en outre une couche multilingue vraiment solide, avec des alias d’URL par langue, des entités traduites et des liens de langue alternatifs, ce qui explique la forte présence de Drupal dans l’enseignement supérieur et le secteur public.

Shopify Markets en couvre désormais une bonne partie, mais le tunnel contextuel et la personnalisation de vitrine via Markets sont limités aux forfaits Advanced et Plus: la comparaison se fait donc au minimum face à £259 par mois plutôt que face à £25.

Quand le catalogue est éditorial

Certains catalogues sont du contenu. Un détaillant spécialisé dont les fiches produit portent des guides d’achat, des tableaux comparatifs, des explications techniques et les notes d’un testeur publie une revue qui accepte accessoirement des paiements.

Sur une plateforme hébergée, cela fait deux systèmes. Le CMS détient l’article, la boutique détient la référence, et un lien plus un export nocturne les réunissent. Les rédacteurs travaillent à deux endroits, la recherche indexe deux fois, et la structure d’URL se fend en son milieu.

Dans Drupal Commerce, un produit est une entité du même système que n’importe quel article: il partage le flux de travail éditorial, l’historique des révisions, les vocabulaires de taxonomie, la médiathèque, l’index de recherche et le modèle de droits. Une fiche produit peut référencer trois articles et un article neuf produits, dans les deux cas comme de vraies références d’entités et non comme des liens collés.

C’est l’argument qui justifie le plus souvent Drupal pour une entreprise qui tiendrait sinon très bien sur Shopify, et c’est celui que l’on écarte le plus souvent comme un confort, jusqu’à ce qu’une équipe éditoriale ait passé un an dans deux interfaces d’administration.

Produits réglementés et fortement attribués

Les produits porteurs de données de conformité sont le quatrième cas. Des produits chimiques avec fiches de données de sécurité. Des dispositifs médicaux avec numéros de certificat et dates de péremption. Des aliments avec matrices d’allergènes. Des appareils électriques avec déclarations de conformité. Tout ce qui exige une traçabilité de lot ou un indicateur de vente restreinte.

L’exigence n’est pas seulement de stocker ces valeurs. Elle est de les valider, de les versionner, d’afficher la bonne pour le lot que le client a réellement reçu, et de prouver après coup ce qui était publié à une date donnée. L’API de champs de Drupal et son système de révisions font cela parce qu’ils ont été bâtis pour la gouvernance de contenu et non pour le merchandising.

Le volet application des règles compte tout autant. Un processeur de commande peut refuser un paiement qui expédierait un article soumis à limite d’âge vers un pays qui l’interdit, ou qui associerait deux articles interdits de transport commun, et il peut le faire dans le pipeline de commande plutôt que dans un gabarit de thème.

Sur une plateforme hébergée, chacun de ces contrôles est une application, et les applications ne se composent pas. Deux applications qui modifient toutes deux le panier sont deux applications qui finiront par se contredire.

Quand l’ERP fait autorité

Le cinquième cas est structurel. Dans une entreprise de distribution ou de fabrication, l’ERP possède le stock, les prix, l’encours client et le statut des commandes, et le site est une surface d’affichage munie d’un panier. La question n’est pas ce que sait faire la boutique, mais à quel coût la maintenir en accord avec le système qui commande réellement.

Drupal Commerce est à l’aise ici parce que l’intégration tourne dans votre propre processus. L’API de files gère le travail asynchrone, l’API de migration gère des imports répétables et idempotents, et aucun intermédiaire ne facture à l’enregistrement ni ne bride votre fenêtre de synchronisation. Un import nocturne de prix et de stock de 200 000 lignes est une tâche planifiée.

Sur une plateforme hébergée, la même intégration est soit un abonnement applicatif, soit un abonnement à un intergiciel, et les limites d’appels de la plateforme deviennent une contrainte d’architecture que l’on contourne par conception plutôt qu’un détail. C’est jouable, et pour bien des entreprises c’est le bon arbitrage. Cela cesse de l’être quand la synchronisation est à la fois volumineuse, fréquente et critique.

Si le travail d’intégration pèse plus lourd que la boutique elle-même, il s’agit d’une mission de développement logiciel avec une vitrine greffée dessus, et elle doit être cadrée ainsi dès le départ.

La fiscalité, là où les plateformes hébergées cessent d’être bon marché

La fiscalité est le centre de coût discret de l’e-commerce transfrontalier, et c’est là que la comparaison des abonnements mensuels commence à tromper. Deux seuils décident de l’essentiel.

Le seuil d’immatriculation à la TVA britannique

Le guide GOV.UK sur le moment où s’immatriculer à la TVA fixe le seuil à £90 000 de chiffre d’affaires taxable total. Deux tests distincts déclenchent l’immatriculation: un test glissant sur douze mois, où vous devez vous immatriculer dans les 30 jours suivant la fin du mois où le chiffre d’affaires a dépassé £90 000, et un test prospectif, où vous devez vous immatriculer dès que vous constatez que le chiffre d’affaires dépassera £90 000 dans les 30 jours qui viennent.

Le test prospectif est celui qui piège les boutiques en croissance, parce que la date d’immatriculation est le jour où vous l’avez constaté, pas le jour où l’argent est arrivé.

TVA de l’UE et guichet unique

Le guide de la Commission européenne sur le lieu d’imposition fixe un seuil annuel combiné de EUR 10 000 couvrant ensemble les ventes à distance intracommunautaires de biens et les services de télécommunication, de radiodiffusion et électroniques. En dessous, le lieu d’imposition est celui où commence l’expédition ou le transport. Au-dessus, l’imposition se déplace là où le transport s’achève, donc au taux du client dans son pays.

Le guichet unique permet de déclarer tout cela dans une seule déclaration, dans un seul État membre, déposée chaque trimestre avec des échéances fin avril, juillet, octobre et janvier. Le guichet unique à l’importation couvre les biens importés hors UE dans des envois n’excédant pas EUR 150.

Ce que Drupal Commerce fait nativement

Commerce livre un plugin de taxe pour la TVA de l’Union européenne dans son coeur plutôt qu’en supplément. Il porte les taux des 27 États membres plus Monaco, distingue les taux normal, réduit, intermédiaire, super-réduit et nul, et traite les territoires spéciaux qui font trébucher les tables de taux uniformes, dont la Corse, les Açores, Madère, les îles grecques et l’enclave autrichienne de Jungholz.

Il applique aussi les règles et pas seulement les taux: imposition à destination pour les biens numériques, et livraisons intracommunautaires entre entreprises exonérées lorsqu’un numéro de TVA valide est fourni. Sur une plateforme hébergée, ce comportement est généralement une application facturée à la transaction.

Paiements, PCI DSS et la façon dont vous encaissez la carte

La manière dont vous collectez le numéro de carte décide de votre charge de conformité, et les règles ont récemment changé d’une façon largement mal comprise.

La clarification du PCI Security Standards Council sur les critères d’éligibilité au SAQ A explique un critère entré en vigueur le 1er avril 2025. Le commerçant doit confirmer que son site n’est pas vulnérable aux attaques par scripts susceptibles d’affecter ses systèmes d’e-commerce, ce qui s’obtient soit en mettant en oeuvre les techniques des exigences PCI DSS 6.4.3 et 11.6.1, soit en obtenant du prestataire de paiement la confirmation que sa solution intégrée comporte ces protections.

Le périmètre exact est la partie que l’on comprend de travers. Ce critère ne s’applique qu’aux commerçants dont la page intègre le formulaire de paiement du prestataire, typiquement dans une iframe. Le Council précise qu’il ne s’applique pas aux commerçants qui redirigent le client vers le prestataire, que ce soit par redirection HTTP, par meta refresh ou par JavaScript, ni à ceux qui externalisent entièrement les fonctions de paiement.

Une redirection hébergée garde donc une surface réduite. Les champs intégrés, qui convertissent mieux et que presque tout le monde veut en réalité, font entrer l’intégrité de chaque script de votre page de paiement dans votre conversation de conformité.

C’est là que se situe le véritable avantage de Shopify, car le tunnel est le sien et les scripts qui s’y exécutent aussi. Sur Drupal Commerce, le tunnel est le vôtre: la réponse doit donc être construite, avec une politique de sécurité de contenu stricte, l’intégrité des sous-ressources, un inventaire de chaque script exécuté sur la page de paiement et une détection de changement quand l’un d’eux bouge. Ce travail n’est ni difficile ni facultatif, et il doit figurer au budget plutôt qu’être découvert lors d’un audit.

L’accessibilité est un risque juridique et commercial

Les défauts d’accessibilité en e-commerce se concentrent dans le tunnel de paiement, c’est-à-dire là où chaque défaut coûte directement de l’argent.

La référence utile est WCAG 2.2, recommandation du W3C publiée le 12 décembre 2024. Les critères qui mordent dans une boutique sont précis. 1.3.5 Identify Input Purpose, niveau AA, couvre le remplissage automatique des champs d’adresse et de carte. 3.3.7 Redundant Entry, niveau A, est violé chaque fois qu’un tunnel oblige le client à ressaisir l’adresse de livraison à l’étape de paiement. 3.3.8 Accessible Authentication, niveau AA, régit la création de compte et la connexion. 2.5.8 Target Size, niveau AA, attrape les sélecteurs de quantité et les boutons de retrait du panier, et 1.4.3 Contrast, niveau AA, attrape le bouton grisé qui est en fait actif.

Deux autres entourent la commande elle-même: 3.3.1 Error Identification, niveau A, et 3.3.4 Error Prevention pour les transactions juridiques, financières et de données, niveau AA, qui vise précisément le fait de passer commande.

La situation juridique britannique est souvent exagérée. Un détaillant privé n’est pas tenu par une loi nommant un niveau de conformité WCAG. Ce qui s’applique est l’obligation de l’article 20 de l’Equality Act 2010 de prendre des mesures raisonnables pour éviter un désavantage substantiel aux personnes handicapées, y compris la fourniture d’aides. Les règlements qui nomment un niveau, les Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, visent les organismes publics et non les boutiques.

Le point commercial est plus tranchant que le point juridique. Sur un thème hébergé, vous ne pouvez pas toujours corriger ce qu’une application injecte dans votre tunnel. Sur une plateforme que vous maîtrisez, vous le pouvez.

Ce que coûtent réellement trois ans

La comparaison que l’on fait d’habitude oppose l’abonnement mensuel à l’hébergement mensuel, la ligne la moins significative du tableau. Le coût de construction et la maintenance dominent, et les pourcentages de transaction dominent au volume.

Les fourchettes ci-dessous sont des estimations maison de Mecanik pour une boutique britannique de milieu de marché, sauf les chiffres d’abonnement et de commission Shopify, cités en livres exactement tels que Shopify les publie. Le reste est ce que nous nous attendrions à chiffrer, et l’écart au sein de chaque ligne est plus large que l’écart entre plateformes en bas de fourchette.

Ce que chaque ligne du tableau achète vraiment

En prose: Shopify Advanced coûte entre £9 324 et £12 384 d’abonnement sur trois ans selon que vous vous engagez à l’année, hébergement compris, mais ajoute des abonnements applicatifs qui vont réalistement de £5 400 à £14 400 sur la même période. WooCommerce ne paie rien pour la plateforme et entre £3 600 et £14 400 pour l’hébergement, avec des extensions de £3 000 à £9 000 sur les trois ans. Drupal Commerce ne paie rien de licence, dépense le plus en hébergement, de £5 400 à £21 600, parce que c’est la plus lourde des trois applications, et le moins en modules payants, entre rien et environ £3 000, parce que les équivalents sont des modules contribués et non commerciaux.

Le coût de construction sépare les plateformes. Une réalisation Shopify de £8 000 à £25 000 achète une boutique thémée avec les intégrations standard, contre £10 000 à £35 000 sur WooCommerce. Le même cahier des charges sur Drupal Commerce vaut £35 000 à £120 000, parce que le tunnel, la logique tarifaire et les intégrations sont écrits et non configurés. La maintenance suit la même forme, à £3 000 à £9 000 par an pour Shopify, £4 000 à £12 000 pour WooCommerce et £12 000 à £30 000 pour Drupal Commerce, reflet de taux journaliers d’agence britannique d’environ £600 à £900 traités dans notre guide des tarifs des développeurs Drupal.

Où atterrissent les totaux sur trois ans

Les totaux sur trois ans atterrissent autour de £32 000 à £79 000 pour Shopify, £29 000 à £94 000 pour WooCommerce et £76 000 à £235 000 pour Drupal Commerce. Les commissions carte et passerelle s’ajoutent aux trois et croissent avec le chiffre d’affaires, ce qui explique que la commission tierce de Shopify de 0,6 % sur Advanced vaille £18 000 sur trois ans pour une boutique à 1 million de livres.

Lisez le tableau honnêtement et Drupal Commerce coûte deux à trois fois plus cher. Cela ne se justifie que lorsque l’alternative n’est pas réellement disponible, ce qui est tout le propos des cinq sections précédentes.

Drupal Commerce headless et découplé

Découpler Drupal Commerce est un vrai besoin dans un ensemble étroit de cas et une mode dans presque tout le reste. Le test honnête est de savoir si autre chose qu’un site web a besoin du même catalogue.

C’est un vrai besoin quand une application mobile native et un site doivent partager un même modèle produit et tarifaire, quand un frontal existant bâti par une autre équipe n’est pas remplacé, quand des terminaux de caisse ou des bornes consomment le même panier, ou quand un design system appartient à l’extérieur du projet et ne peut pas s’exprimer en Twig. Là, l’API est le produit et le CMS est délibérément invisible.

C’est une mode quand la raison avancée est la performance. Un frontal Drupal classique bien mis en cache sert les pages produit anonymes depuis la périphérie, et la méthode de rendu est rarement ce qui rend une boutique lente.

Le coût se concentre en un seul endroit. Le coeur de Drupal expose les contenus via JSON:API sans configuration, et le module Commerce Cart API place les paniers derrière une interface REST: lire un catalogue et constituer un panier sont donc presque gratuits. Le tunnel de paiement, non. Gestion des adresses, affichage des taxes, choix de livraison, promotions, intégration de l’élément de paiement et confirmation de commande doivent tous être reconstruits dans le frontal, ce qui représente d’ordinaire 40 % ou plus du chantier total.

La règle de décision en cinq minutes

Répondez à six questions sur votre propre catalogue. Chaque oui vaut un point.

Certains de vos produits ont-ils besoin de plus de trois options, ou de plus de 2 048 combinaisons achetables? Deux clients différents paient-ils parfois des prix différents pour la même référence? Vendez-vous dans plus d’un pays avec des traitements de TVA différents, ou prévoyez-vous une déclaration au guichet unique? Le catalogue est-il aussi un contenu éditorial que la même équipe rédige et entretient? Un ERP ou un PIM fait-il autorité sur le prix et le stock, la boutique étant en aval? Devez-vous insérer votre propre logique dans le tunnel de paiement, et pas seulement l’habiller?

Un score de zéro ou un: choisissez Shopify. Les avantages décrits dans cet article ne vous concernent pas et vous paieriez pour reconstruire ce que vous louez déjà.

Un score de deux: la décision est vraiment ouverte, WooCommerce étant souvent la meilleure voie médiane, surtout si l’équipe fait déjà tourner WordPress.

Un score de trois ou plus: Drupal Commerce mérite d’être chiffré sérieusement, parce que les contournements exigés ailleurs coûteront plus cher que la plateforme sur trois ans. Un score de cinq ou six: la plateforme hébergée n’est pas une option moins chère, c’est un autre produit qui ne fait pas le travail.

Là où les projets Drupal Commerce dérapent

L’échec le plus courant est de le choisir pour la mauvaise raison. Nous avons déjà Drupal n’est pas un besoin commerce. Un site de contenu et un site transactionnel n’ont pas les mêmes exigences de disponibilité, les mêmes tests ni les mêmes conséquences quand un déploiement se passe mal, et traiter la boutique comme une rubrique de plus du site existant est la façon dont un petit projet e-commerce hérite d’une équipe plateforme non prévue.

Le deuxième est de sous-doter la maintenance. Avec 35 870 installations, l’écosystème est assez petit pour que vous utilisiez des modules maintenus par une poignée de personnes, et quelqu’un chez vous doit suivre les avis de sécurité et planifier les mises à jour. Un site Drupal Commerce dont personne n’a la charge est un incident de sécurité à retardement, sujet que nous traitons plus en détail avec les exigences d’hébergement réelles de Drupal.

Le troisième est de supposer qu’un module existe. Vérifiez avant de chiffrer. S’il n’existe pas, le travail relève d’un développement de site web sur mesure et exige une vraie estimation plutôt qu’une ligne de devis.

Le quatrième est la discipline des versions majeures. Commerce 3 exige Drupal 10.3 ou ultérieur, et un site qui décroche du coeur finit par découvrir que ses modules commerce sont partis sans lui. Notre guide du développement Drupal en 2026 et l’article sur les coûts et échéances de migration traitent tous deux de ce cycle.

Prendre la bonne décision

Le choix se décide sur la complexité produit et tarifaire, pas sur le trafic, le chiffre d’affaires ou la préférence. Modélisez d’abord votre catalogue, sur papier, avec chaque option, chaque prix négocié et chaque intégration qui doit rester en accord avec autre chose. Si ce modèle tient dans une grille de variantes, achetez la plateforme hébergée et dépensez le budget épargné en merchandising.

Mecanik construit et entretient les deux types de boutique, et nous vous dirons de quel côté de la ligne vous êtes avant de chiffrer quoi que ce soit. Si la réponse est Drupal Commerce, le travail est une mission de développement de site web à forte composante d’intégration; si la charge ERP l’emporte sur la vitrine, elle relève plutôt du développement logiciel. Si la réponse est Shopify, nous le dirons, et nous préférons le dire maintenant plutôt que dix-huit mois après le début d’une refonte.

Questions fréquentes

Drupal Commerce est-il meilleur que Shopify? Pas pour la plupart des boutiques. Shopify coûte moins cher sur trois ans, prend en charge la conformité PCI et l’hébergement, et son tunnel de paiement est éprouvé à une échelle qu’aucune agence n’égale. Drupal Commerce gagne dans un ensemble étroit de cas: produits à plus de trois options ou 2 048 variantes, prix négociés par client, catalogues qui sont aussi du contenu éditorial, et boutiques où un ERP possède le prix et le stock.

Combien coûte une réalisation Drupal Commerce au Royaume-Uni? Comptez £35 000 à £120 000 pour la construction initiale et £12 000 à £30 000 par an de maintenance, à des taux journaliers d’agence britannique d’environ £600 à £900. Sur trois ans, une boutique Drupal Commerce atterrit typiquement entre £76 000 et £235 000 hébergement compris, contre environ £32 000 à £79 000 pour Shopify Advanced. Ce sont des estimations maison, pas des devis.

Quelle version de Drupal Commerce faut-il utiliser? Drupal Commerce 3, actuellement en 3.3.8, publiée le 17 juillet 2026. Elle fonctionne avec Drupal 10.3 ou ultérieur et avec Drupal 11, et ses versions stables relèvent de la politique de sécurité de Drupal. Commerce 2 prenait en charge Drupal 9 et 10 et constitue le cycle précédent: les nouveaux projets doivent donc démarrer sur la branche 3.x.

Drupal Commerce gère-t-il la TVA de l’UE et le guichet unique? Les règles fiscales sont intégrées au coeur de Commerce plutôt que vendues en supplément. Le plugin de TVA de l’Union européenne porte les taux des 27 États membres plus Monaco, distingue les taux normal, réduit, intermédiaire, super-réduit et nul, traite les territoires spéciaux, applique l’imposition à destination aux biens numériques et exonère les livraisons B2B intracommunautaires contre un numéro de TVA valide. Déposer la déclaration au guichet unique reste une tâche comptable.

Quand le Drupal Commerce headless en vaut-il la peine? Quand autre chose qu’un site web consomme le même catalogue, par exemple une application native, un terminal de caisse ou un frontal appartenant à une autre équipe. Cela n’en vaut pas la peine pour la seule vitesse, puisqu’un frontal classique mis en cache est déjà rapide. Prévoyez au budget la reconstruction du tunnel de paiement, qui représente d’ordinaire 40 % ou plus d’un projet découplé.