WooCommerce ou Laravel : quelle plateforme e-commerce choisir, et quand

La liste des fonctionnalités du premier jour ne départage pas les plateformes — le stock, les prix B2B et le multilingue, nous les construisons sur les deux. Ce qui départage, c’est qui décide de votre prochaine évolution, et ce qu’elle coûte.

Une question de technologie dont la réponse n’est pas une liste de fonctionnalités

La conversation commence presque toujours de la même façon : le client a environ sept cents références, trois niveaux de prix pour ses revendeurs — chacun ne voyant dans son espace que le sien — et une comptabilité Visma Horizon où le stock fait foi, le site ne faisant que le refléter. La question qu’il pose tient en trois mots : WooCommerce ou Laravel ? La réponse qu’il attend est un tableau à deux colonnes, avec d’un côté ce qui existe et de l’autre ce qui manque — un tableau que nous n’avons pas, et que personne parmi ceux qui construisent vraiment les deux ne possède non plus.

Le module de gestion d’entrepôt avec synchronisation des quantités en temps réel, les niveaux de prix B2B, le système de remises, la prise en charge multilingue et la migration des contenus, nous les construisons sur les deux plateformes, et notre grille tarifaire ne bouge pas de l’une à l’autre : la création d’un site e-commerce coûte 4 500 € en version Basic et 9 500 € en version Pro, aussi bien sous WooCommerce que sous Laravel. Ce sont exactement ces cinq lignes qui séparent Basic de Pro, et non ce qu’il y a en dessous ; l’interface d’administration figure déjà dans la version Basic, tandis que le fonctionnement multidevise n’est dans aucune des deux et se négocie à part — de nouveau, sur l’une comme sur l’autre plateforme.

Il en découle une chose très concrète : une plateforme qu’on vous vend sur la liste de ses fonctionnalités du premier jour vous est vendue pour quelque chose que l’on obtient des deux côtés, et un comparatif qui commence par cette liste est terminé avant d’avoir commencé. La question intéressante se pose un cran plus loin — qui décide de ce que votre site saura faire l’année prochaine, et combien de temps cette décision attend son tour dans la file de quelqu’un d’autre.

La première année, les deux plateformes font ce pour quoi vous avez payé, puisque dans les deux cas quelqu’un vient de le construire ; la deuxième année, le processus bouge — la vente en gros arrive, un deuxième entrepôt, l’obligation d’émettre des factures lisibles par une machine, ou simplement un autre ordre de calcul des remises —, et à partir de cet instant les deux chemins ne coûtent plus la même chose. Sur l’extension d’un éditeur tiers, chaque évolution ultérieure ressemble à des travaux dans un local loué : les règles de votre processus habitent l’écran de réglages d’un autre et se déplacent au rythme de ses versions à lui. Sur votre propre code, la même chose est un travail dont le tarif figure dans notre grille, et la seule chose à arbitrer est sa priorité face au reste de la liste.

Ce que WooCommerce fait bien

Nous installons nous-mêmes WooCommerce chez nos clients chaque fois que le processus s’y prête, et c’est le système e-commerce le plus répandu dans les relevés de W3Techs : au 6 août 2026, il faisait tourner 8,2 % de tous les sites web et représentait 48,5 % de tous les systèmes e-commerce recensés. Plus important que le chiffre : ce sur quoi il est calculé — une part des systèmes recensés, pas des sites e-commerce du monde entier, et certainement pas du chiffre d’affaires de l’e-commerce —, et derrière lui se tient WordPress, qui fait tourner 41,2 % de tous les sites web.

Le répertoire de WordPress.org affichait le même jour WooCommerce 11.0.0, mis à jour le 4 août, avec l’estimation « 7+ million active installations » — plus de sept millions d’installations actives —, et l’éditeur lui-même invite à la lire avec prudence : la remontée des statistiques d’usage est désactivée par défaut dans le cœur téléchargé depuis WordPress.org, si bien que personne, Automattic compris, ne sait combien de sites vendent réellement. Ce nombre est un plafond d’installations, pas un décompte de marchands.

La page tarifaire de l’éditeur présente WooCommerce comme une plateforme open source, sans frais de plateforme et avec 0 % de part sur les revenus : vous ne payez pas parce que vous vendez, et vous ne payez pas davantage parce que vos ventes augmentent. Le catalogue, la liste des commandes et les réglages de remises ressemblent par ailleurs au reste de l’administration WordPress, que votre équipe sait très probablement déjà utiliser sans formation.

L’argument le plus fort en faveur de WooCommerce disparaît presque toujours des comparatifs, et c’est le correctif automatique : le 2 mars 2026, une vulnérabilité de la Store API a été rendue publique ; elle touchait les versions 5.4 à 10.5.2 et permettait, avec une requête forgée, de se créer un compte administrateur. La faille a été trouvée par quelqu’un d’autre que les commerçants concernés, le correctif a été rétroporté sur les 52 versions affectées, et le jour même, à partir de 14 h 00 UTC, il a commencé à se diffuser tout seul vers les sites dont les mises à jour automatiques étaient activées, sans facture. Ce réglage n’a pourtant rien d’évident, et c’est précisément ce qu’une personne configure et surveille dans un contrat de maintenance ; la façon dont un site WordPress se fait pirater, et ce qu’il faut faire quand c’est déjà arrivé, nous l’avons décrite dans notre article sur un site WordPress piraté.

La recommandation n’a donc pas changé, et elle est écrite noir sur blanc sur notre page de service : pour un très petit site e-commerce aux processus standards, WooCommerce. Pour cent références avec un seul prix, un seul entrepôt et un seul moyen de paiement, une plateforme sur mesure n’apporte rien qui vaille l’écart de prix, et vendre la version chère quand la version bon marché fait la même chose, c’est un client mécontent de plus et pas une seule recommandation.

WooCommerce tient-il les paiements et la livraison en Lettonie ?

Oui. En Lettonie, la livraison et les paiements ne sont pas l’endroit où un site e-commerce tout fait s’arrête, et les mises en garde inverses sont en général sans fondement : Omniva publie des modules prêts à l’emploi pour six plateformes — WooCommerce, Shopify, PrestaShop, OpenCart, Magento et Mozello — et, à côté, une interface OMX documentée par laquelle transitent données d’expédition, étiquettes, événements de suivi et listes de consignes automatiques dans les trois pays baltes : le préalable est un contrat d’entreprise, pas un développeur. DPD Baltics maintient elle-même son extension WooCommerce dans le répertoire de WordPress.org — version 1.2.91, plus de 2 000 installations actives — et celle-ci couvre consignes automatiques, coursier, étiquettes, manifestes et paiement à la livraison ; on y lit aussi sa note publique de 2,7 sur 5 et des avis qui se plaignent de conflits avec d’autres extensions de livraison.

MakeCommerce, derrière lequel se tient Maksekeskus AS, donne avec un seul contrat les liens bancaires Swedbank, SEB, Citadele et Luminor, les cartes, Apple Pay et Google Pay, et juste à côté les livraisons Omniva, DPD, Venipak et Unisend ; son extension WooCommerce dépasse les 3 000 installations actives et sa dernière mise à jour date de juin 2026. Klix by Citadele, maintenu par la banque elle-même, publie des extensions officielles pour six plateformes, dont WooCommerce à partir de la version 3.5 — soutenir qu’un site e-commerce tout fait ne peut pas encaisser en Lettonie serait donc tout simplement faux.

Le revers de la même médaille, c’est que ces prestataires n’appartiennent pas aux extensions : MakeCommerce, Omniva et DPD publient des interfaces, pas seulement des modules, et dans notre grille le raccordement des paiements — MakeCommerce et Stripe — figure déjà dans la version Basic à 4 500 €, quelle que soit la plateforme en dessous. Les intégrations avec Horizon, Jumis, la poste lettone, Omniva et DPD sont une ligne du service e-commerce, pas un supplément pour Laravel, et nous travaillons régulièrement avec les API de livraison d’Omniva, de la poste, de DPD et de Venipak : le socle local des paiements et de la livraison n’est un argument ni pour ni contre aucun des trois chemins.

Là où il y a vraiment du travail en Lettonie

L’arrière-boutique se complique parce que Visma Horizon, Jumis et Directo publient chacun sa propre interface REST — la documentation de Directo décrit une authentification par en-tête X-Directo-Key et l’accès aux articles, commandes, clients, factures, stocks et formules de prix —, mais une interface publiée n’est pas encore une intégration : il faut que quelqu’un fasse coïncider ce que le site appelle un produit avec ce que la comptabilité appelle un article de nomenclature, et décide laquelle des deux détient la vérité sur le stock à la seconde où l’acheteur appuie sur le bouton. Deux endroits où vit la quantité disponible, ce sont deux horloges à bord d’un navire : tant qu’on ne les règle pas l’une sur l’autre, personne ne sait l’heure, et ce travail est du sur-mesure sur n’importe quelle plateforme — avec Horizon et Jumis, nous le faisons régulièrement.

Au-dessus, il y a un fait juridique daté avec un piège dedans : en Lettonie, la facture électronique structurée est obligatoire pour les organismes publics depuis le 1er janvier 2025, et elle le deviendra pour les échanges entre entreprises le 1er janvier 2028 — dans le cadre de la loi comptable lettone (Grāmatvedības likums) et au format LVS EN 16931-1:2017. Le piège, c’est la date : l’échéance visée au départ était 2026, si bien que des articles de presse de 2024 citent encore la mauvaise date, et cela se vérifie sur la page du ministère des Finances, pas dans l’actualité — car pour un site qui vend à des entreprises, quelqu’un devra construire le chemin de la facture lisible par une machine sur n’importe quelle plateforme, quelle que soit l’année qui l’emportera.

WooCommerce ou Laravel : lequel des trois chemins est le vôtre ?

Les comparatifs qui présentent ce choix comme deux boutons laissent de côté le chemin que nous vendons le plus souvent, car il y en a trois ; ils se distinguent par la part de votre processus qui vit dans du code que vous pouvez modifier vous-même, et choisir entre eux revient à choisir où résideront désormais vos règles de prix et de commande — dans un écran de réglages, dans votre propre dépôt, ou à mi-chemin entre les deux.

Le premier chemin est l’outil du marché avec ses extensions toutes faites — WooCommerce ou OpenCart, que nous proposons aussi aux sites existants. Le cœur de WooCommerce contient deux champs de prix, le prix normal et le prix promotionnel, une seule quantité en stock par produit ou par variation, et trois moyens de paiement dont aucun n’encaisse en ligne ; le prix réservé à un groupe de clients donné, les remises sur quantité, la transformation d’un devis en commande, l’exonération de TVA et les stocks répartis sur plusieurs entrepôts sont donc autant d’achats séparés, auprès d’éditeurs séparés, avec des abonnements annuels séparés. C’est le chemin le plus rapide et, très souvent, le bon ; son prix n’est pas de l’argent, mais le fait que les règles de votre processus habitent désormais l’écran de réglages d’un autre.

Le deuxième chemin n’apparaît presque jamais dans les comparatifs, alors que c’est celui que nous vendons le plus souvent : l’outil du marché avec notre propre code par-dessus. WooCommerce est du PHP open source, si bien qu’une table de prix revendeurs, un contrôle d’encours ou une réservation de stock s’écrivent à côté du cœur au lieu de s’acheter sous forme d’extension, et il n’y a pour cela aucune licence — il y a des heures —, avec pour contrepartie que ce code reste lié au rythme des mises à jour de WooCommerce et à la façon dont cette plateforme range ses commandes. Une part notable de ce que notre grille appelle la version Pro à 9 500 € est exactement ce travail-là, et c’est là que se trouve la majorité des sites que nous avons construits.

Le troisième chemin est notre propre plateforme, où le catalogue, le panier, le tunnel de commande et la logique de prix sont écrits à partir d’une page blanche autour de votre processus ; c’est le démarrage le plus cher, et le seul qui ne repose sur aucune hypothèse d’éditeur tiers quant à ce qu’est un produit et au moment où une commande devient une commande. À l’intérieur de ce troisième chemin, il existe un embranchement : Bagisto et Lunar sont des paquets e-commerce Laravel sous licence MIT — au 6 août 2026, respectivement 27 943 et 3 588 étoiles sur GitHub — qui livrent le catalogue et le panier déjà écrits, en échange d’une dépendance externe de plus, dont le rythme ne vous appartient pas. Nous ne l’empruntons pas.

Combien coûtent les licences annuelles des extensions WooCommerce ?

Pour un site de sept cents références et trois niveaux revendeurs, le premier chemin coûtait, au 6 août 2026, 270 € par an pour deux prix publics, plus un troisième inconnu. Dynamic Pricing, à 113 € par an, donne les remises par quantité et par rôle ; B2B for WooCommerce, développé par Addify, donne pour 157 € par an les prix par rôle, les prix par paliers, la transformation d’un devis en commande, l’exonération de TVA et des moyens de paiement et de livraison restreints selon le rôle ; mais pour les stocks répartis sur plusieurs entrepôts le cœur ne prévoit rien, d’où une troisième extension payante — Addify Multi Inventory Management, par exemple — dont l’éditeur n’affiche aucun tarif annuel public.

Ces 270 € par an représentent un peu plus de cinq heures de développement, puisque l’heure vaut 50 € dans notre grille, et pour des fonctions qui ont un éditeur, une documentation et des mises à jour, c’est bon marché. Un prix qu’on ignore avant d’avoir eu la conversation ne se met pourtant pas dans un chiffrage : l’extension d’entrepôts fait monter ce total, et de combien dépendra du devis qui arrivera une fois annoncés le nombre d’entrepôts et le volume de commandes.

Un autre site aura d’autres lignes : pour celui qui vend des abonnements, des réservations et des niveaux d’adhésion, aux mêmes tarifs de la place de marché, WooCommerce Subscriptions coûte 245 € par an, Bookings 218 €, Memberships 175 €, AutomateWoo 140 € et Product Add-Ons 70 € — soit 848 € par an. Sur cinq ans, à tarifs constants, cela fait 4 240 € : presque le prix entier d’un site en version Basic, qui vaut 4 500 € dans notre grille, et presque la moitié de la version Pro à 9 500 €. Cette ligne ne s’amortit pas, puisqu’elle porte sur un seul site, sur une seule année, et qu’elle se règle chaque année à nouveau.

Le même montant lu à l’envers, ce sont près de 85 heures de développement à 50 €, des heures qui restent dans votre code et dans votre patrimoine au lieu de se renouveler sur la facture de l’année suivante. Ces 848 € sont d’ailleurs la facture d’un site d’abonnements, de réservations et d’adhésions, et non une norme — il n’y en a pas ici, et chaque commerçant doit additionner cette ligne à partir de son propre processus. La ligne des licences s’ajoute par ailleurs à la construction, elle ne s’y substitue pas : dans les deux cas quelqu’un a d’abord construit le site, et dans un seul des deux une facture retombe en janvier pour ce qui est déjà construit.

Ce que devient la facture quand on ne la paie plus

Si l’abonnement n’est pas renouvelé, la documentation de WooCommerce.com le dit sans détour : « the extension or theme remains installed on your site but will no longer receive updates » — l’extension reste installée, le site continue de fonctionner, et seules les mises à jour disparaissent. La conséquence d’une licence non renouvelée n’est donc pas une interruption que l’on remarque le jour même, mais un morceau de code non corrigé qui traite toujours des paiements ; un abonnement couvre par ailleurs un site de production et un site de préproduction, et les sous-domaines comptent séparément.

Une ligne se comporte autrement, et de la même façon des deux côtés : le connecteur comptable n’est en général pas une licence mais un abonnement qui monte avec le nombre de commandes — MyWorks Xero Sync démarre sur la place de marché avec un palier gratuit, et au-delà c’est le volume qui fixe le prix, si bien que cette ligne grossit quand le site e-commerce grossit. Une plateforme sur mesure ne la supprime pas ; elle change qui maintient le connecteur, et chez nous ce sont des heures. Il ne faut pas non plus gonfler ces lignes : le multilingue ne coûte pas automatiquement 99 € par an pour WPML Multilingual CMS, puisque Polylang existe à côté de WPML, mais la licence WPML la moins chère, Multilingual Blog à 39 €, ne prend pas en charge l’e-commerce — pour un site e-commerce, le choix entre 39 € et 99 € n’existe pas.

Pourquoi l’écart apparaît la deuxième année

Que le coût du changement soit une dépense réelle et non théorique, c’est la plateforme elle-même qui le montre : depuis 2023, WooCommerce a retiré deux pièces porteuses, abandonné une fonction en bêta et changé un réglage par défaut. L’ancienne API REST a quitté le cœur le 11 juin 2024 avec la version 9.0, après avoir été déclarée obsolète dès la version 2.6 en 2016 ; la passerelle PayPal Standard intégrée a été retirée dans la version 8.9 en mai 2024 ; la version bêta de l’éditeur de produits a disparu dans la 11.0, apparue au catalogue le 4 août ; quant au stockage des commandes HPOS, il est devenu le réglage par défaut des nouvelles installations dans la version 8.2 en octobre 2023 et ne touche pas les sites existants tant que personne ne les migre.

Sur ce fond, la catégorie Advisories du blog développeurs de WooCommerce compte 37 billets sur les douze mois qui s’achèvent le 5 août 2026 — environ trois par mois —, et chacun doit être confronté à chaque extension installée, ce qu’un site à quatre extensions encaisse sans effort et un site à vingt, plus du tout. La pile ne s’accumule d’ailleurs pas en un jour : les extensions arrivent une par une, chacune étant, prise isolément, une décision parfaitement raisonnable, et la multiplication des combinaisons à vérifier se fait en silence.

Dix extensions, ce ne sont pas dix pièces mais dix contrats, dont chacun peut s’achever de son côté, et le propriétaire change parfois alors que le code se porte très bien. Le 31 octobre 2025, le service d’avis Judge.me a coupé son intégration WooCommerce en même temps que Square, Squarespace, BigCommerce, Duda et PrestaShop : les données restaient accessibles jusqu’au 19 novembre, l’accès a ensuite été retiré définitivement, et les vidéos d’avis n’entraient pas dans l’export — un actif marketing accumulé pendant des années est donc resté pour partie de l’autre côté de la porte. Les cas paisibles sont plus convaincants encore : en 2019, Automattic a racheté Prospress, l’auteur de WooCommerce Subscriptions et d’AutomateWoo ; en 2020, GoDaddy a racheté SkyVerge, dont plus de soixante extensions étaient utilisées par plus de 100 000 marchands ; et les deux opérations, autant qu’on puisse en juger publiquement, se sont bien terminées pour les commerçants. La question n’est pas celle du dommage, mais celle-ci : le propriétaire d’un composant de votre site peut changer sans votre participation.

Quelle est vraiment la taille de ce risque

L’échelle relativise tout cela, et les chiffres sont ici les nôtres : dans le relevé du 6 août 2026, l’API de WordPress.org a renvoyé 7 764 extensions portant l’étiquette « woocommerce », dont 23,1 % n’ont pas été mises à jour depuis deux ans ou plus ; mais, dans ce même relevé, 10 809 800 installations actives reposent sur des extensions mises à jour au cours des six derniers mois, et 208 790 seulement sur des extensions laissées de côté depuis plus de trois ans. Les extensions comptant 10 000 installations ou plus et restées deux ans sans mise à jour sont, dans ce même relevé, exactement six.

L’extension abandonnée n’est presque jamais celle que tout le monde connaît : le risque se loge dans ce module étroit qu’exige précisément votre processus — les niveaux de prix B2B, le connecteur d’entrepôt, le générateur d’étiquettes d’un transporteur particulier —, et plus votre processus s’écarte de la moyenne, plus vous êtes proche de la région du répertoire où la dernière mise à jour remonte à deux ans. Cette ligne se réduit sans rien reconstruire : dans un contrat de maintenance, c’est nous qui le faisons — nous réduisons le nombre d’extensions, configurons les mises à jour et assurons la supervision —, et la reconstruction n’est la réponse que le jour où le problème n’est plus l’entretien, mais le fait que le processus n’est écrit nulle part.

Où la forme des données de WooCommerce commence à serrer

La deuxième zone où la deuxième année coûte, c’est la forme des données — et d’abord le côté par lequel cet argument n’est plus vrai : depuis la version 8.2, les commandes des installations neuves reposent dans quatre tables qui leur sont propres, et la mesure publiée par l’éditeur en mars 2023 montre que ce nouveau stockage accélère les opérations sur les commandes au lieu de les freiner. C’est du côté des produits que cela serre, et personne ne l’a mieux écrit que les développeurs de WooCommerce eux-mêmes, le 1er avril 2019, en expliquant les gains de performance de la version 3.6 : les produits et leurs variations passent par le système de publications de WordPress, où le post meta est extraordinairement souple mais « not that efficient when we need to sort or filter by many meta values at once » — pas si efficace lorsqu’il faut trier ou filtrer selon de nombreuses valeurs de méta à la fois. La réponse, dans la même version, fut wc_product_meta_lookup, table auxiliaire dénormalisée portant référence, prix et état du stock à côté du post meta et non à sa place : la structure de fond, elle, est restée la même.

Le travail équivalent du côté des produits, woocommerce/woocommerce-product-tables-feature-plugin, vit depuis le 16 octobre 2017 sur GitHub et nulle part ailleurs, et il n’est pas abandonné — dernières modifications le 31 juillet 2026 —, il n’est simplement toujours pas jugé assez stable pour le répertoire de WordPress.org. À côté se tient wp_options, dont le champ autoload n’a pas d’index par défaut, dont les données chargées automatiquement sont lues à chaque affichage de page, que WooCommerce recommande elle-même de maintenir idéalement sous les 500 lignes environ, et dont la croissance vient précisément des extensions, achetées ou gratuites, et des thèmes — la même pile que plus haut, vue depuis la base de données.

Ce que Laravel apporte à un site e-commerce et qu’un outil du marché n’apporte pas

Laravel n’est pas un site e-commerce et ne prétend pas l’être : il fournit des pièces nommées, documentées et sous licence MIT à partir desquelles quelqu’un assemble un site e-commerce, si bien que la question qui vaut de l’argent ici n’est pas « le framework est-il bon », mais « quelles parties de votre processus deviennent enfin vos propres tables et vos propres tâches ». Chez un commerçant, la réponse tient d’ordinaire en quatre lignes — la table de prix revendeurs, l’encours autorisé, la réservation de stock et la synchronisation comptable —, et ce sont exactement celles que, dans un outil du marché, vous achetez à quatre éditeurs différents avant de devoir les accorder entre elles.

Avant d’aller plus loin, il est honnête de dire ce que ce chemin ne donne pas, car aucune des quatre lignes n’est fournie par Laravel lui-même : les kits de démarrage officiels du framework donnent l’authentification et rien d’autre — ni catalogue, ni panier, ni tunnel de commande, ni entrepôt —, et le seul paquet commercial livré d’origine est Cashier, qui prend en charge la facturation d’abonnements du côté de Stripe ou de Paddle et suppose que les produits et leurs prix sont déjà décrits dans le tableau de bord du prestataire de paiement. Ce que Laravel donne, c’est une forme dans laquelle ces quatre lignes sont peu coûteuses à écrire et moins coûteuses encore à modifier ensuite.

Files d’attente, transactions et la forme de votre propre base de données

La première pièce, ce sont les files d’attente : une seule interface au-dessus de plusieurs moteurs — Redis, la base de données, Amazon SQS, Beanstalkd — qui permet au traitement d’une commande, à la synchronisation avec l’ERP et à l’envoi des courriels de sortir de la requête, si bien que l’acheteur n’attend plus la réponse du système comptable. La documentation nomme aussi ce qui départage une vraie mise en œuvre : les chaînes et les lots de tâches (jobs), les tâches uniques qu’une file n’exécute pas deux fois, les tentatives de reprise et la table des tâches échouées, d’où l’on peut les relancer. Une commande exécutée deux fois, c’est une facture que quelqu’un devra ensuite annuler, et un client qui s’en aperçoit avant vous.

Horizon montre le débit des files, les temps d’exécution et les erreurs, décrit la configuration des workers dans le code et alerte quand une file attend trop longtemps ; il exige en revanche Redis et ne fonctionne pas, à ce jour, avec Redis Cluster — une ligne distincte sur la facture d’hébergement, pas un supplément gratuit. Les transactions sont ce que signifie concrètement la phrase « la commande et le mouvement de stock se font tous les deux ou aucun des deux » : en cas d’erreur, DB::transaction annule les changements et permet de rejouer l’opération si la base se retrouve en interblocage.

Les migrations, que la documentation de Laravel appelle la gestion de versions de la base, signifient en pratique que vous dessinez tables, index et clés étrangères autour de votre logique de prix et de stock, et non autour de ce qu’un autre a décidé un jour de la notion de produit. La recherche et la facturation des abonnements restent d’ailleurs un choix, pas une ligne mensuelle obligatoire : Scout indexe sur place avec les index plein texte de MySQL ou de PostgreSQL, sans service externe, et Cashier tient le côté Stripe si le site e-commerce a des abonnements.

La table de prix, l’encours et la réservation, écrits en clair

À quoi cela ressemble concrètement, la première des quatre lignes le montre le mieux : sur votre propre code, la table de prix revendeurs est une migration à quatre colonnes — groupe de clients, article, seuil de quantité, prix — avec un index unique sur les trois premières : le prix applicable à un acheteur donné se trouve avec une requête et une jointure, et non par une fouille dans des valeurs de méta, et un nouveau niveau de prix est une ligne de plus dans une table, pas un réglage de plus dans la fenêtre d’un autre éditeur. Quand un quatrième niveau arrive un an plus tard avec un autre mode d’arrondi, c’est un endroit et un test qui changent, et les deux sont dans votre dépôt.

L’encours autorisé et la réservation de stock sont la même idée un cran plus loin, car là aussi tout tient à une table et à une transaction : le total des factures impayées est une colonne chez le client, et le contrôle a lieu dans la transaction même qui crée la commande, si bien que deux commandes envoyées en même temps ne peuvent pas passer toutes les deux sous le plafond, tandis qu’en cas d’interblocage la transaction se rejoue toute seule. La réservation, elle, est une ligne assortie d’une date d’expiration, qui naît avec la commande et disparaît avec une tâche de fond planifiée si la commande n’est pas payée — la quantité en stock cesse ainsi d’être un nombre que deux acheteurs peuvent vider en même temps.

La synchronisation comptable est une tâche de file marquée comme unique, de sorte qu’une reprise n’émet jamais deux fois la même facture ; et quand Horizon montre au matin que la comptabilité a connu une coupure pendant la nuit, la table des tâches échouées permet de les relancer dans l’ordre au lieu de les ressaisir à la main. Chacune de ces quatre lignes existe aussi dans un outil du marché, mais sous la forme d’une fenêtre de réglages d’éditeur dont vous ne voyez pas les règles, qu’il faut recontrôler après chaque mise à jour et qui ne se transporte pas sur une autre plateforme.

Deux réalisations déjà en service

À quoi cela ressemble dans un projet plutôt que dans une documentation, nos propres réalisations Laravel le montrent. Dans la plateforme de commande de repas LIDO, ce n’est pas le produit qui fixe le prix mais l’adresse : la géolocalisation détermine la zone de livraison, la distance et le montant, chacun des treize restaurants a sa propre carte, et à côté du site tourne un système distinct d’automatisation des processus, où arrivent toutes les commandes et depuis lequel elles sont réparties entre les restaurants et les cuisiniers — avec des intégrations vers plus de dix autres systèmes, dont Wolt, QWQER et RKeeper. Dans le site Riga Lashes, bâti sur Laravel, il y a les prix par variante, les comptes clients, la liste d’envies et la grille des prestations du studio, et derrière eux l’entrepôt, les intégrations avec les transporteurs et les paiements, où le processus est automatisé jusqu’au stade de l’emballage. Dans les deux cas, l’essentiel aurait dû être écrit sur un outil du marché aussi, mais à l’intérieur des formes de prix et de commande d’un autre éditeur — et c’est là la différence qui subsiste : sur votre propre code, ce travail tient dans un dépôt, sans abonnement séparé par capacité, et sans recontrôle après chaque mise à jour de la plateforme. Nous écrivons du Laravel depuis 2013, et la plupart de nos systèmes sur mesure, de nos portails du secteur public et de nos plateformes B2B tournent dessus.

Où part l’argent qui n’est pas dans les licences est une question concrète, et la réponse l’est tout autant : les quelque 85 heures que coûte, sur cinq ans, la ligne de licences de 848 € par an sont, sur votre propre code, exactement cette table de prix, cet encours, cette réservation et cette synchronisation, écrites autour de votre processus. Elles restent dans votre dépôt même si nous cessons un jour d’être votre partenaire : dans une prestation sur commande, le code est le vôtre dès le premier jour, et c’est écrit aussi sur notre page de service Laravel.

Filament : l’interface d’administration que personne n’écrit à partir de zéro

La part « interface d’administration » de l’objection selon laquelle tout serait à écrire de zéro dans un système sur mesure, c’est Filament qui l’enlève — un framework d’interface open source pour applications Laravel. Ses ressources génèrent les écrans de création, de consultation, de modification et de suppression des modèles Eloquent, le constructeur de tables apporte filtrage, tri et pagination, les composants de formulaire arrivent avec leur validation, et les droits d’accès, Filament les lit dans les politiques de modèles de Laravel : les contrôles de rôle ne s’écrivent pas deux fois. Gestionnaires de relations, widgets de tableau de bord et notifications sont fournis avec ; l’architecture multi-locataire aussi, avec cet avertissement de Filament lui-même qu’il s’agit d’un jeu d’outils et non d’une garantie, et que la séparation des données entre locataires incombe à celui qui met en œuvre. Toute cette couche est sous licence MIT, comme Laravel : aucun frais de licence.

Le plus important n’est pourtant pas ce que le framework dessine, mais l’endroit où va l’argent ainsi libéré : les écrans d’édition des produits, les tableaux de commandes, les filtres et les contrôles de droits sont la part du développement que l’acheteur ne voit jamais et que le client paie pourtant au tarif plein ; quand le framework les fournit, le budget part vers la logique de prix, de commandes et de stock pour laquelle le sur-mesure avait été choisi. L’exemple se trouve là où vous lisez ces lignes : ce site tourne sous Laravel 13 et Filament 5, et tout le travail éditorial en douze langues se fait dans un panneau que nous avons configuré et non écrit à partir de zéro.

Où s’arrête le framework et où commence le site e-commerce

Filament n’est pas un site e-commerce, et la frontière mérite d’être tracée nettement : le framework donne une interface d’administration — écrans, tableaux, formulaires, contrôles de droits — mais ne sait rien de ce qui se trouve dans ces tableaux ni des règles selon lesquelles cela y arrive. Un catalogue de produits avec ses variations et ses attributs, un panier, un tunnel de commande, des règles de prix avec des niveaux de clients et des remises sur quantité, un cycle de vie de commande de la création au retour, la réservation des quantités en entrepôt : rien de tout cela n’est livré avec Laravel et Filament. Filament, c’est un atelier aménagé, avec ses étagères, ses établis et sa lumière ; ce qu’on y fabrique n’est pas dans le carton.

À quel point c’est à prendre au pied de la lettre, la documentation le montre elle-même : les modèles Order et Payment n’y figurent qu’à titre d’exemples, écrits par le développeur, car de telles classes n’existent tout bonnement pas dans le framework. Ce n’est pas un défaut mais un partage du travail : Filament promet une interface d’administration et rien d’autre, exactement comme Laravel promet un framework et non une application finie. En pratique, cela signifie que Filament raccourcit le travail d’administration, mais ne raccourcit rien dans la partie pour laquelle le développement sur mesure avait été choisi.

C’est pourquoi, dans notre grille, le site e-commerce en version Basic à 4 500 € arrive sans module de gestion d’entrepôt, sans prise en charge multilingue, sans niveaux de prix B2B, sans système de remises et sans migration des contenus, tandis que la version Pro à 9 500 € les comprend tous. L’écart n’est pas une majoration pour technologie plus moderne, mais le prix de ce que quelqu’un doit écrire, et c’est précisément pour cela qu’il est identique sur les deux plateformes. Un système Laravel à périmètre fixe, à partir de 8 000 €, est déjà une autre ligne et un autre produit dans la grille : ce n’est pas un site e-commerce, mais un système dans lequel tout le processus naît d’une page blanche.

Ce que nous ne promettons pas : là où le sur-mesure coûte plus cher

Un site construit sur mesure est affranchi des licences annuelles d’extensions, pas de la maintenance, et ce sont deux choses entièrement différentes. Laravel accorde à chaque version 18 mois de correctifs de bugs et deux ans de correctifs de sécurité, publie une version majeure par an, et il n’existe chez lui aucun palier de support à long terme : les dates sont donc précises. Laravel 13 est sorti le 17 mars 2026, avec des correctifs de sécurité jusqu’au 17 mars 2028 ; la fenêtre de sécurité de Laravel 11 s’est refermée le 12 mars 2026 ; les correctifs de bugs de Laravel 12 s’arrêtent le 13 août 2026. Tous les ans ou tous les deux ans, le système doit donc passer sur une nouvelle version majeure, et la documentation de Laravel dit s’efforcer de rendre cette opération faisable en une journée ou moins — un effort, et non une promesse sur le temps que cela prendra dans votre système.

Le tapis roulant de PHP est par ailleurs le même des deux côtés : chaque branche reçoit deux ans de support actif et deux ans de correctifs de sécurité seulement, si bien qu’une fenêtre de cinq ans contient au moins une migration PHP forcée et, selon le moment du cycle où vous démarrez, jusqu’à deux, quelle que soit la plateforme en dessous. Ni un site sous WooCommerce ni un site sous Laravel n’échappe à cette ligne, et dans les deux cas c’est la même personne qui la planifie avec le reste de la maintenance — la seule différence étant que, sur votre propre code, la migration se fait quand cela vous arrange, et non quand une extension cesse de prendre en charge l’ancienne version.

Trois lignes où l’outil du marché l’emporte

Plus chères que la maintenance, il y a trois autres lignes, et la première est l’écosystème : là, l’outil du marché gagne sans discussion. Une automatisation marketing de plus dans un site WooCommerce, c’est une fiche sur la place de marché — AutomateWoo, par exemple, coûte 140 € par an — et, d’après notre expérience, une journée de travail ; dans un système sur mesure, c’est une spécification, des heures et un test, et à 50 € de l’heure c’est la première fonction dont vous vous demanderez si elle est vraiment nécessaire. Un champ produit ou un nouveau filtre dans l’administration ne figurent pas sur cette liste, puisque le framework les donne. L’absence d’écosystème n’est pas un coût unique mais un seuil durablement plus haut pour tout ce qu’on voudra essayer ensuite ; pour un site e-commerce qui expérimente beaucoup, cela peut peser plus lourd que la facture de licences — d’où le fait que nous n’en faisons pas notre argument principal.

La deuxième est la dépendance à une seule équipe, et c’est la structure qui y répond, pas une déclaration : dans une prestation sur commande, le code est le vôtre dès le premier jour, nous l’écrivons dans la structure standard de Laravel sans montages exotiques, la logique critique est couverte par des tests, et un README documenté ainsi qu’une chaîne d’intégration continue sont livrés avec, pour qu’un autre puisse reprendre le système. Des développeurs Laravel, on en trouve sans peine en Lettonie, et c’est pourquoi notre propre réponse à la question « pourquoi Laravel » se termine par cette phrase : vous ne restez dépendant d’aucune équipe unique, la nôtre comprise. Cela n’annule pas le risque, mais cela le rend transférable.

La troisième, c’est la norme PCI DSS, et elle joue contre nous. La révision du questionnaire SAQ A publiée en janvier 2025 et entrée en vigueur le 31 mars 2025 a supprimé, pour les marchands dont la page de paiement est fournie entièrement et directement par un prestataire conforme à PCI DSS et qui ont eux-mêmes attesté que leur site n’est pas exposé aux attaques par script, les exigences 6.4.3 et 11.6.1 — l’inventaire des scripts, leur justification et la surveillance de leurs modifications — ainsi que l’exigence 12.3.1 sur l’analyse de risque ciblée, tout en précisant que les exigences PCI DSS sous-jacentes, elles, ne disparaissent pas. Cet allègement décrit un petit site WooCommerce à page de paiement bancaire bien plus fidèlement qu’un tunnel de commande que nous affichons dans notre propre code, et à côté se tient un second fait tout aussi inconfortable : la vulnérabilité de mars a été trouvée et corrigée par quelqu’un d’autre, alors que dans un système écrit par nous, c’est notre équipe qui s’en charge — la maintenance y est une ligne de contrat, pas une hypothèse.

Nos dépendances ne sont pas d’une autre espèce

Filament est exactement la même dépendance tierce que les extensions dont il vient d’être question, et l’écart entre les deux est un écart de degré et de place, pas de principe. C’est une dépendance sous licence MIT dans la couche de développement, son code se trouve dans notre dépôt et peut être forké, et elle ne se tient pas sur le chemin de paiement de l’acheteur, puisqu’elle dessine une interface d’administration au lieu d’encaisser.

Si le projet s’arrêtait demain, le site continuerait à prendre des commandes, et ce qui vieillirait serait la partie que voient vos collaborateurs, pas celle qui prend l’argent de l’acheteur. Filament publie d’ailleurs un tableau de support par version, avec des dates précises : la version trois est sortie en août 2023 et reçoit des correctifs de sécurité jusqu’au 1er janvier 2028, soit une fenêtre plus longue que celle que Laravel accorde à ses propres versions.

Filament n’est pourtant pas un paquet officiel de Laravel, puisque Laravel ne le cite pas dans sa liste de paquets, et derrière le projet il n’y a pas une société avec un bilan mais une équipe rassemblée autour d’un seul mainteneur : quelque 17 000 modifications du dépôt portent son nom, contre environ 2 400 pour le contributeur suivant, et le financement vient de sponsors GitHub et de missions de conseil payantes. Le rythme des versions n’a rien de doux non plus : la quatrième est sortie en août 2025, la cinquième dès janvier 2026, deux jours après Livewire 4, laquelle est une dépendance tierce de plus, en dessous. Et la phrase « au besoin, nous la forkerons » est peu coûteuse à écrire et très coûteuse à tenir.

Nous ne proposons pas un site e-commerce sans dépendances tierces, parce qu’il n’en existe ni chez nous ni ailleurs ; nous en proposons un nombre plus petit, une licence qui permet de garder le code et de l’entretenir nous-mêmes, et une frontière nette entre ce qui, en cas de panne, arrête les encaissements et ce qui gâche la journée de travail d’un salarié. Si cet écart ne vous paraît pas assez grand, l’objection est parfaitement fondée — et nous vous construisons alors l’outil du marché, puisque c’est la même version Basic ou Pro au même prix. Aucune de ces deux réponses ne fait de nous le mauvais partenaire.

Comment nous tranchons ce choix en pratique

Avec la plateforme, vous achetez la réponse à une seule question — qui a le droit de modifier vos règles de prix et de commande, et selon quel calendrier —, et sur votre propre code cette réponse est « vous, au prochain sprint », tandis que sur l’extension d’un éditeur tiers elle devient « quand l’éditeur l’intégrera à l’une de ses versions, s’il l’intègre ». C’est pourquoi, en cadrage, nous ne demandons pas votre chiffre d’affaires : nous demandons combien de niveaux de prix vous avez réellement et si un client voit parfois un prix différent d’un autre — c’est là que passe la frontière entre les deux champs de prix que WooCommerce fournit lui-même et une table de prix que quelqu’un devra tenir.

Nous demandons ensuite si le stock vit à plus d’un endroit, car un entrepôt plus un rayon en magasin font déjà deux endroits, et deux endroits signifient que quelqu’un doit décider lequel fait foi. Les deux questions suivantes tranchent en général tout le reste : une commande devient-elle une commande immédiatement, ou lui faut-il d’abord une validation — du service achats du client, de votre responsable commercial ou d’un encours autorisé —, et le processus tiendrait-il encore si le catalogue doublait ?

Si la réponse sur la validation est oui, vous êtes exactement là où le marché des extensions toutes faites est le plus faible : la surveillance d’un encours autorisé et le blocage des commandes qui le dépassent ne sont ni dans le cœur ni dans les suites B2B les plus répandues, et seules quelques fiches spécialisées le promettent, comme QuarkCode B2B Commerce Suite. Quelle part de votre processus vous acceptez de refaire pour l’outil, voilà la question qui reste — et des exigences floues sont l’erreur la plus chère de toute la commande, ce dont nous avons parlé à part.

Si les réponses entrent dans l’outil du marché, prenez l’outil du marché, il coûtera moins cher — et c’est nous qui vous le construirons. Si une ou deux n’y entrent pas, vous êtes très probablement sur le chemin du milieu, et cela correspond dans la grille à cette même version Pro à 9 500 € sous WooCommerce — le même prix que sous Laravel, puisque ce qui coûte, c’est le travail et non la plateforme. Si trois réponses ou plus n’y entrent pas, et surtout si l’étape de validation ou l’encours autorisé en font partie, la conversation ne porte plus sur la plateforme mais sur la part du processus qui vit dans du code que nous pouvons modifier sans l’accord d’un autre éditeur.

Trois façons de commencer, et ce que chacune coûte

En pratique, nous vendons trois façons de commencer, chacune avec un prix calculable. La première : démarrer avec le catalogue, les paiements et la livraison, mettre en ligne, puis ajouter les prix B2B, la logique de remises et les intégrations de stock une fois les premières vraies commandes arrivées — dans nos réponses, nous appelons cela le choix le plus souvent juste. La deuxième : déplacer un site existant, et c’est un projet, pas un interrupteur. Nous conservons la structure des URL, mais les modèles de données ne se recouvrent pas un pour un, et chaque extension qui a rangé ses propres champs doit être examinée séparément. Dans la version Pro et dans la location, la migration est comprise ; dans la version Basic, non, et nous la chiffrons à part selon le volume, car ce sont la quantité de données et le nombre de champs qui en décident.

La troisième est la location : un site e-commerce Laravel avec notre hébergement, à partir de 130 € par mois, plus 600 € de frais d’installation, une seule fois ; dans la grille, son contenu est celui de la version Pro — module de gestion d’entrepôt, prise en charge multilingue, niveaux de prix B2B, système de remises et migration des contenus —, avec en plus l’hébergement, les mises à jour et la maintenance. Elle n’existe qu’avec Laravel, car on ne loue pas de site WooCommerce chez nous. Le choix de la plateforme tranche en lui-même quelques points précis que le travail ne rattrape pas : cette ligne de location, les correctifs automatiques et gratuits du cœur, le seuil de l’écosystème, et qui doit donner son accord avant que votre prochaine évolution n’arrive en production. Tout le reste est du travail.

La location démarre à 130 € par mois, soit à partir de 7 800 € sur cinq ans, plus 600 € d’installation — à partir de 8 400 € —, et elle comprend l’hébergement, les mises à jour et la maintenance. La version Pro coûte 9 500 € en une fois, et l’hébergement vient à côté : notre location d’infrastructure démarre à 45 € par mois, soit à partir de 2 700 € sur cinq ans, donc à partir de 12 200 € au total, et les mises à jour applicatives n’y sont pas encore comprises. Les deux montants sont des planchers, pas des totaux, et ils sont comparables parce que la composition fonctionnelle des deux formules est identique dans la grille. Dans la location, vous payez l’usage avec l’hébergement ; dans une construction, vous payez le système d’un coup — et, planchers contre planchers, la location démarre plus bas sur cinq ans. Là où chacune s’arrête, c’est le volume qui le décide : nous les chiffrons donc toutes les deux par projet plutôt que de les lire dans la grille.

Le travail avance ensuite par sprints de deux semaines, avec une démonstration à la fin de chacun ; les paiements, les transporteurs et la comptabilité sont raccordés et testés avant la mise en ligne ; les produits, les clients et l’historique des commandes sont transférés en conservant la structure des URL. Pour les travaux plus vastes et non standards, nous travaillons en régie avec un plafond hebdomadaire, parce qu’un prix fixe y signifie le plus souvent soit une majoration pour le risque, soit une dispute sur le périmètre ; le taux horaire de la grille est de 50 €. Le parcours complet prend 8 à 32 semaines. Demandez une évaluation de votre projet et une recommandation technologique — répondez-nous à ces mêmes questions, et nous vous dirons lequel des trois chemins vous coûtera le moins.