Ce guide aide les propriétaires de boutiques et leurs responsables techniques à choisir entre WooCommerce et Magento, qu’ils planifient une nouvelle boutique ou qu’ils se demandent si la leur a dépassé sa plateforme. WooCommerce est une extension gratuite qui transforme un site WordPress en boutique. Magento est une application conçue uniquement pour le commerce en ligne, gratuite sous le nom de Magento Open Source ou offerte sous licence par Adobe sous le nom d’Adobe Commerce. Les deux font rouler de grosses boutiques rentables, alors la question utile est de savoir laquelle correspond à votre catalogue, à votre équipe et aux serveurs que vous êtes prêt à exploiter. En bref, WooCommerce convient à la plupart des catalogues petits et moyens, et aux équipes qui connaissent déjà WordPress. Magento convient aux catalogues complexes, à plusieurs vitrines gérées depuis une seule administration et à la vente B2B, à condition d’avoir des développeurs qui maîtrisent son système de modules. À la fin, vous aurez mesuré votre boutique, répété le travail courant de chaque plateforme et rédigé une décision que vous pouvez défendre.
Ce que vous allez accomplir
- Comprendre ce dont chaque plateforme a besoin en dessous, du serveur web au moteur de recherche.
- Mesurer une vraie boutique WooCommerce ou Magento avec quelques commandes en lecture seule, pour que la comparaison repose sur vos chiffres.
- Vérifier si votre équipe peut assumer la routine de déploiement de Magento, ou la routine de mises à jour de WordPress, semaine après semaine.
- Dresser la liste des facteurs de coût de chaque plateforme en termes simples, sans deviner de prix.
- Terminer avec une courte décision écrite et une liste de vérification qui prouve qu’elle est complète.
Prérequis
- Une liste de ce que la boutique vend, du nombre de produits et de variantes, du nombre de vitrines ou de langues nécessaires, et de la vente aux entreprises, s’il y a lieu.
- Pour une boutique WooCommerce, un accès shell à une copie de préproduction et WP-CLI (l’outil de ligne de commande de WordPress), lancé avec l’utilisateur du site depuis le dossier WordPress. Les commandes ci-dessous visent WooCommerce 8.x ou plus récent.
- Pour une boutique Magento, un accès shell à une copie de préproduction de Magento 2.4.x, lancé avec le propriétaire des fichiers depuis le dossier racine de Magento, ainsi qu’un accès en lecture à sa base MySQL.
- Si vous n’avez encore ni l’une ni l’autre, sautez les étapes de mesure et prenez les chiffres de votre chiffrier de produits.
- Environ deux semaines d’attention à temps partiel, et une personne qui peut parler au nom de l’entreprise.
Comment ça fonctionne
Les deux plateformes partent de points différents. WooCommerce ajoute une boutique à WordPress, le système de gestion de contenu qui fait déjà rouler une bonne part du Web. Les produits, les commandes et les clients vivent dans la même base MySQL que vos pages et vos articles. Les versions récentes rangent les commandes dans HPOS, pour High-Performance Order Storage, un ensemble de tables dédiées aux commandes qui a remplacé l’ancienne méthode, où chaque commande était enregistrée comme une publication WordPress. HPOS est activé par défaut pour les nouvelles boutiques depuis WooCommerce 8.2.
Magento a été conçu uniquement pour le commerce. Il inclut d’office plusieurs types de produits (simple, configurable, groupé, lot, virtuel et téléchargeable). Il prend aussi en charge une hiérarchie de sites web, de magasins et de vues de magasin. Elle permet à une seule administration de gérer plusieurs marques, pays ou langues, chacun avec ses prix et son catalogue. Adobe Commerce, l’édition payante, ajoute des fonctions B2B comme les comptes d’entreprise, les catalogues partagés et les demandes de soumission, en plus d’autres fonctions absentes de Magento Open Source.
La plus grande différence pratique tient à ce que chacune demande au serveur.
WooCommerce tourne sur la pile LAMP habituelle (Linux, Apache ou un serveur web semblable, MySQL et PHP). Un compte d’hébergement cPanel ordinaire suffit pour une petite boutique, et une plus grosse ajoute des processus PHP, un cache de pages et souvent Redis comme cache d’objets. Magento 2.4 demande plus de morceaux, à commencer par PHP-FPM (le FastCGI Process Manager, qui garde une réserve de processus PHP prêts à répondre). Depuis la version 2.4, la recherche dans le catalogue exige un moteur de recherche distinct, Elasticsearch ou OpenSearch, et c’est OpenSearch que visent les versions récentes. La plupart des boutiques Magento en production exploitent aussi Redis pour le cache et les sessions, et Varnish, un mandataire de cache qui sert des pages complètes depuis la mémoire. La page des exigences système d’Adobe donne les versions prises en charge pour chaque version de Magento.
Les compétences de l’équipe suivent le même partage. Un développeur WooCommerce écrit du PHP dans le style WordPress, avec des crochets (hooks) et des extensions. Les changements passent en ligne le plus souvent par la mise à jour d’une extension ou d’un thème. Magento utilise Composer (le gestionnaire de paquets de PHP) pour chaque module, un système d’injection de dépendances qui relie les classes entre elles à partir de fichiers XML, et une étape de compilation à chaque déploiement.
Il vaut mieux comparer les coûts par facteurs que par prix affichés :
- Facteurs pour WooCommerce. Un hébergement dimensionné pour votre trafic, des extensions payantes et leurs licences annuelles, les frais de paiement, et le temps d’exploitation pour les mises à jour, les sauvegardes et la sécurité.
- Facteurs pour Magento. Une empreinte serveur plus lourde avec plus de services à exploiter, et des développeurs qui connaissent Magento. Ajoutez les extensions payantes de l’Adobe Commerce Marketplace ou d’autres éditeurs, les frais de paiement et une licence Adobe si vous choisissez Adobe Commerce.
Étapes
1. Notez les exigences qui décident habituellement ce choix. Utilisez ce format, avec un poids de 3 pour critique, 2 pour important et 1 pour utile.
requirement,weight,type
Configurable products with 3+ options each,3,must
Two brands on one back office with separate prices,3,must
Company accounts and quote requests for B2B buyers,2,nice
Weekly blog and buying guides edited by marketing,2,nice
Team of two PHP developers who know WordPress,3,mustUne exigence « must » est une chose sans laquelle l’entreprise ne peut ni lancer ni exploiter la boutique, et « nice » désigne un simple souhait. Gardez la liste autour de cinq lignes, parce qu’une liste gonflée cache les vrais critères de décision.
2. Mesurez une boutique WooCommerce. Sur la copie de préproduction, lancez ces commandes depuis le dossier WordPress.
wp plugin get woocommerce --field=version
wp post list --post_type=product --post_status=publish --format=count
wp post list --post_type=product_variation --post_status=any --format=count
wp option get woocommerce_custom_orders_table_enabled
wp plugin list --status=active --format=count9.3.3
2140
15820
yes
31Vous devriez voir cinq lignes. Elles donnent la version de WooCommerce, les produits publiés, les variations, l’état de HPOS (yes s’il est actif) et le nombre d’extensions actives. Un résultat no pour HPOS veut dire que les commandes vivent encore dans les tables de publications. C’est pris en charge, mais planifiez le passage avant que la boutique grossisse. Si wp plugin get woocommerce indique que l’extension est introuvable, vous n’êtes pas dans le bon dossier.
3. Mesurez une boutique Magento. Depuis la racine de Magento en préproduction, vérifiez d’abord la version et le moteur de recherche.
bin/magento --version
bin/magento config:show catalog/search/engineMagento CLI 2.4.7-p3
opensearchLa première ligne confirme la version. La deuxième montre le moteur de recherche configuré, et elasticsearch7 correspond à l’ancienne option. Listez ensuite la structure des magasins.
bin/magento store:website:list
bin/magento store:list+----+------------------+-------------+------------+------------+------------+
| ID | Default Group Id | Name | Code | Sort Order | Is Default |
+----+------------------+-------------+------------+------------+------------+
| 1 | 1 | Main Brand | base | 0 | 1 |
+----+------------------+-------------+------------+------------+------------+Chaque commande affiche un tableau, et le nom des colonnes peut varier légèrement d’une version à l’autre. Le premier compte une ligne par site web, et le second une ligne par vue de magasin (une version linguistique ou régionale d’un magasin). La ligne d’administration, avec l’ID 0 dans le second tableau, est intégrée, alors ne la comptez pas. Un seul site web avec une seule vue de magasin veut dire que vous n’utilisez pas encore la structure multimagasin de Magento. Comptez ensuite les produits par type dans MySQL.
mysql -u magento_user -p magento_db -e "SELECT type_id, COUNT(*) AS products FROM catalog_product_entity GROUP BY type_id;"+--------------+----------+
| type_id | products |
+--------------+----------+
| configurable | 610 |
| simple | 18244 |
| bundle | 35 |
+--------------+----------+Remplacez le nom d’utilisateur et le nom de la base par les valeurs de app/etc/env.php. Si MySQL répond que la table n’existe pas, votre installation utilise un préfixe de tables; ajoutez-le devant le nom de la table. Bien des produits simples sont les enfants de produits configurables, alors les deux chiffres comptent.
4. Vérifiez l’état des index de Magento. Les indexeurs sont des tâches de fond qui copient les données de produits, de prix et de stock dans des tables de consultation rapides et dans le moteur de recherche.
bin/magento indexer:status+------------------------+----------------+--------+--------------------+---------------------+
| ID | Title | Status | Update On | Schedule Status |
+------------------------+----------------+--------+--------------------+---------------------+
| catalogsearch_fulltext | Catalog Search | Ready | Update by Schedule | idle (0 in backlog) |
| cataloginventory_stock | Stock | Ready | Update by Schedule | idle (0 in backlog) |
+------------------------+----------------+--------+--------------------+---------------------+Le vrai tableau compte plus de lignes et une dernière colonne pour la plus récente mise à jour planifiée; l’exemple est abrégé. Chaque ligne devrait afficher Ready. Des lignes marquées Reindex required, ou un gros arriéré, veulent dire que les tâches cron ou le moteur de recherche demandent de l’attention. C’est du travail d’exploitation courant pour Magento, alors notez qui s’en charge aujourd’hui. Le guide sur la recherche de catalogue avec OpenSearch explique comment corriger la situation.
5. Répétez la routine de déploiement que votre équipe devra assumer. Chaque plateforme a une routine par laquelle passe chaque changement. Sur Magento, un changement de code ou de module sur une boutique en mode production passe par ces étapes.
bin/magento maintenance:enable
composer install --no-dev
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy en_US fr_CA -f
bin/magento cache:flush
bin/magento maintenance:disableChaque étape devrait se terminer sans erreur. setup:upgrade applique les changements à la base de données, setup:di:compile génère le code de liaison entre les classes, et setup:static-content:deploy construit le CSS et le JavaScript de chaque langue. Demandez à votre développeur de lancer la routine une fois en préproduction et de la chronométrer, puisque la boutique reste en maintenance pendant toute la durée. Sur WooCommerce, la répétition équivalente est une mise à jour d’extensions en préproduction.
wp plugin update --all --dry-runAvailable plugin updates:
+-------------+----------+---------+----------------+
| name | status | version | update_version |
+-------------+----------+---------+----------------+
| woocommerce | active | 9.3.3 | 9.4.0 |
+-------------+----------+---------+----------------+Le tableau liste chaque extension qui a une mise à jour en attente, et --dry-run veut dire que rien n’est modifié. Retirez --dry-run en préproduction pour appliquer les mises à jour, puis parcourez la boutique et le paiement. La règle de cette étape est simple. Si personne dans l’équipe ne peut mener la routine Magento avec assurance, notez au mieux 1 chaque exigence « must » qui demande du code sur mesure dans Magento. Gardez cette note tant que vous n’avez pas embauché ou engagé cette compétence.
6. Notez la grille d’adéquation. Donnez à chaque plateforme 0 si elle ne peut pas répondre à une exigence, 1 si elle demande une extension ou du travail sur mesure, et 2 si elle y répond d’office. Multipliez par le poids. L’exemple ci-dessous vaut pour une boutique précise, pas comme verdict sur l’une ou l’autre plateforme.
requirement,weight,type,woo,magento
Configurable products with 3+ options each,3,must,2,2
Two brands on one back office with separate prices,3,must,1,2
Company accounts and quote requests for B2B buyers,2,nice,1,1
Weekly blog and buying guides edited by marketing,2,nice,2,1
Team of two PHP developers who know WordPress,3,must,2,1Une exigence « must » notée 0 élimine cette plateforme, peu importe son total. Pour le B2B, notez Magento Open Source et Adobe Commerce dans des colonnes séparées si les fonctions B2B décident du résultat, parce que c’est justement là qu’elles diffèrent.
7. Décidez et mettez-le par écrit. Parcourez l’arbre de décision ci-dessous avec votre grille et les durées mesurées à l’étape 5.
Rédigez une page qui nomme la plateforme, les raisons, les facteurs de coût que vous acceptez et le responsable de chaque tâche récurrente. Si la réponse est de quitter Magento, le guide de migration de Magento vers WooCommerce couvre le déménagement. Si Shopify fait aussi partie de vos options, comparez-le avec le guide WooCommerce ou Shopify.
Valider le résultat
Votre décision est prête quand chaque ligne de cette liste est vraie :
- Chaque exigence « must » obtient 1 ou 2 sur la plateforme choisie, et chaque note de 1 nomme l’extension ou le travail sur mesure qui la justifie.
- Les nombres de produits, de variantes et de vues de magasin viennent de vraies commandes, pas d’estimations.
- Pour Magento,
bin/magento indexer:statusaffiche chaque index àReadyen préproduction, et la routine de déploiement a été chronométrée. - Pour WooCommerce, HPOS est actif, ou une date est fixée pour l’activer.
- Chaque tâche récurrente, des mises à jour à l’entretien du moteur de recherche, a un responsable nommé.
- Le plan d’hébergement liste chaque service dont la plateforme a besoin, y compris OpenSearch pour Magento.
Dépannage
bin/magento échoue avec une erreur de permissions ou de mémoire. Lancez-le avec le propriétaire des fichiers, pas avec root. Si PHP manque de mémoire, lancez php -d memory_limit=2G bin/magento indexer:status en remplaçant la commande par celle qui a échoué.
config:show indique que le chemin du moteur de recherche n’existe pas. La valeur est peut-être verrouillée dans app/etc/env.php ou app/etc/config.php, ou laissée à la valeur par défaut de la version. Cherchez catalog/search/engine dans ces fichiers. Dans l’administration, la section Catalog Search sous Stores, Configuration, Catalog affiche le moteur utilisé.
wp option get woocommerce_custom_orders_table_enabled indique que l’option n’existe pas. Aucun réglage HPOS n’a jamais été enregistré dans la boutique, ce qui signale habituellement une version plus ancienne de WooCommerce. Mettez WooCommerce à jour en préproduction, puis vérifiez de nouveau.
Les deux plateformes obtiennent presque le même total. Vos exigences sont probablement trop larges. Découpez des lignes comme « recherche rapide » en critères vérifiables, comme « la recherche trouve les numéros de pièce qui contiennent des tirets », puis notez de nouveau.
L’équipe est divisée. Le désaccord vient le plus souvent de poids différents sur une même ligne. Réglez d’abord les poids; la décision suit généralement.
Quand cette approche ne convient pas
Si votre catalogue est petit et que vous n’avez aucun développeur, une plateforme hébergée vous conviendra peut-être mieux que l’une ou l’autre option; la comparaison avec Shopify mentionnée plus haut couvre ce cas. Si vous exploitez déjà bien Magento, avec une équipe qui maîtrise la routine de déploiement et des index en bonne santé, une boutique qui fonctionne vaut rarement une reconstruction pour elle-même. Mage-OS, une distribution de Magento Open Source maintenue par la communauté, mérite aussi un coup d’œil si vous voulez rester sur Magento sans licence Adobe. Pour les détails de WooCommerce, y compris HPOS, partez de la documentation WooCommerce sur High-Performance Order Storage.
Un WordPress qui rapporte vraiment mérite un opérateur — Stack Harbor opère cette pile sous WordPress Entreprise ; réservez une consultation d’infrastructure.