Un plugin au lieu de vingt : combien coûte un zoo d'extensions WooCommerce ?

Récemment, le propriétaire d'une boutique en ligne de lubrifiants industriels m'a contacté. Site Internet sur WooCommerce, catalogue - environ quatre mille produits, le trafic est assez correct, les commandes arrivent. Mais sa question ne concernait pas les ventes ou le référencement. Il a littéralement dit ce qui suit : "Oleg, j'ai trente-deux plugins sur mon site et j'ai peur de cliquer sur le bouton "Mettre à jour" sur au moins l'un d'entre eux. La dernière fois que j'ai mis à jour le filtre de produits, le panier et la comparaison ont été ajoutés. Le magasin est resté là pendant deux jours. Que faire ?" Et vous savez, à ce moment-là, je me suis surpris à penser que j'entendais cette histoire environ une fois par mois. Différentes niches, différentes échelles d'activité, mais le problème est le même : un zoo de plugins qui était autrefois assemblé pièce par pièce pour la croissance, mais qui s'est maintenant transformé en un champ de mines. Chaque mise à jour est une roulette russe. Chaque nouveau plugin est un conflit potentiel avec les trois déjà installés. Et le plus triste, c'est que le propriétaire du magasin prend cela pour acquis. Comme un mal nécessaire de WooCommerce. Ils disent, eh bien, que pouvez-vous faire, une telle plateforme est modulaire, sur des plugins, c'est comme ça que tout le monde vit.

Enfin, pas tous. Et je veux expliquer pourquoi le « zoo » n’est pas une fatalité, mais un choix. Un choix coûteux, un choix risqué et, dans la plupart des cas, un choix inconscient. Parce que lorsque vous installez le premier plugin de liste de souhaits pour 99 $ par an, vous ne pensez pas que dans six mois vous aurez vingt abonnements de ce type, et le montant total des extensions dépassera trois fois le coût de l'hébergement lui-même. Vous résolvez simplement un problème spécifique : « J’ai besoin d’une liste de souhaits. » Ensuite, "J'ai besoin d'une comparaison de produits". Ensuite "J'ai besoin d'un module B2B". Et c'est parti. J'ai vécu cela moi-même - à la fois en tant que propriétaire de magasin et en tant que personne qui construit ces magasins pour les clients. Et à un moment donné, j’ai réalisé que je ne pouvais plus vivre ainsi. Qu’une approche fondamentalement différente est nécessaire. Mais parlons de tout dans l'ordre.

Anatomie d'une boutique WooCommerce typique : ce qu'il y a sous le capot

Prenons une boutique en ligne conditionnelle « moyenne » sur WooCommerce. Pas une page de destination avec dix produits, mais une boutique fonctionnelle normale : un catalogue de milliers d'articles, plusieurs catégories, filtres, recherche, panier, paiement, compte personnel. Rien d'exotique - un ensemble de base pour le e-commerce. Voyons maintenant quels plugins sont disponibles sur un tel site, et je ne parle pas de scénarios fictifs, mais de projets réels que j'ai vus et sur lesquels j'ai travaillé.

WooCommerce vous offre un catalogue, un panier et un paiement prêt à l'emploi. Tout le reste est des plugins. Filtrage des produits - plugin. Recherche de catalogue qui fonctionne normalement, et pas comme une recherche WordPress standard qui renvoie des pages au lieu de produits - un plugin. Comparaison de produits - plugin. La liste de souhaits est un plugin. Méga menu pour que le catalogue soit joliment organisé dans l'en-tête - plugin. Fonctionnalité B2B : prix de gros, groupes de clients, demandes de devis, c'est déjà tout un ensemble de plugins. Sécurité - pare-feu, protection contre la force brute, surveillance - plugin. Analyse et audit SEO - plugin. Champs personnalisés pour les produits - plugin. Formulaires de commentaires et de candidature - plugin. Livraison via SDEK, Boxberry, KIT - un plugin pour chaque transporteur. L'intégration avec 1C est un plugin distinct. Le téléchargement sur Yandex.Market en est un autre. Redirections - plus. Le plan du site XML est normal – toujours. Et je n'ai pas encore évoqué la mise en cache, l'optimisation des images, une médiathèque avec des dossiers et une douzaine de petits utilitaires.

Je n'exagère pas. Je vais maintenant ouvrir l'un des vrais projets et faire le calcul. L'un des magasins que j'ai pris en charge l'année dernière avait vingt-sept plugins actifs, dont dix-neuf étaient des extensions de la fonctionnalité WooCommerce. Pas de « jolis boutons » décoratifs, mais des modules fonctionnels, sans lesquels le magasin ne peut pas fonctionner. Enlevez-en un et quelque chose se brisera. Le filtre cessera de filtrer, la recherche cessera de chercher, les clients B2B ne verront pas leurs prix, 1C cessera de télécharger les soldes. Chaque plugin est une dépendance. Et c’est ici que le plaisir commence : calculons combien cela coûte.

Liste de souhaits YITH WooCommerce Premium – 99 $/an. YITH WooCommerce Comparer Premium – 79 $/an. Filtre de produit YITH Ajax – 99 $ par an. Wordfence Premium - 119 $ par an. ACF Pro – 99 $ par an (ou 49 $ pour une licence personnelle, mais une entreprise est requise pour un site commercial). SearchWP – 99 $ par an. WPForms Pro – 199 $ par an (ou Contact Form 7 est gratuit, mais avec de nombreux modules complémentaires pour de l'argent). MaxMegaMenu Pro – 49 $ par an. Plugin de livraison SDEK - 3900 roubles par an. Plugin Boxberry - 2500 roubles. Plugin pour l'intégration 1C - de 5 000 à 15 000 roubles par an, selon la fonctionnalité. Yoast SEO Premium – 99 $ par an. Plugin pour le flux Yandex.Market - de 2000 à 5000 roubles. Véritable médiathèque pour l'organisation des médias - 49 $. Et cela ne prend même pas en compte le thème, qui lui-même peut coûter entre 59 et 79 dollars par an pour les mises à jour.

Si vous additionnez tout cela, cela représente entre 900 $ et 1 500 $ par an rien que pour les plugins. Au taux de change de 90 roubles pour un dollar, cela représente entre 81 000 et 135 000 roubles par an. Pour les abonnements aux plugins. Pas pour l'hébergement, pas pour le domaine, pas pour le travail du programmeur - seulement pour le droit d'utiliser le code de quelqu'un d'autre. Et chaque année, vous devez payer à nouveau ce montant, car si vous arrêtez de payer, les mises à jour cesseront d'arriver, et sans mises à jour, le plugin tombera tôt ou tard en panne sur une nouvelle version de WordPress ou WooCommerce. J'ai vu des magasins qui fonctionnaient avec des plugins vieux de trois ans et ne fonctionnaient que parce que le propriétaire avait peur de mettre à jour WordPress au-delà d'une certaine version. Ce n’est pas une stratégie, c’est une bombe à retardement.

Mais l'argent, ce n'est pas si mal. L'argent peut être compté, planifié, budgétisé. Ce qui est bien pire est ce qui ne peut être calculé : les pertes dues aux conflits, aux temps d'arrêt et à la dégradation de la productivité.

Vingt plugins - vingt points de défaillance

Voici ce que j'ai appris au fil des années de travail avec les boutiques WooCommerce : chaque plugin est une unité de code indépendante, écrite par son propre auteur, selon ses propres standards, avec sa propre architecture. Lorsque vous avez vingt plugins sur votre site, vous disposez de vingt approches différentes pour travailler avec la base de données, vingt façons différentes de connecter JavaScript et CSS, vingt systèmes différents de hooks et de filtres qui s'accrochent aux mêmes événements WooCommerce. Et tôt ou tard, deux de ces vingt plugins commencent à entrer en conflit. Non pas parce qu’ils sont mal écrits – souvent les deux plugins sont d’excellente qualité. C’est juste que leurs auteurs ne se connaissaient pas et ne pouvaient pas prévoir que leur code fonctionnerait sur le même site en même temps.

Je me souviens d'un cas où le magasin d'un client avait YITH Compare et un plugin de tarification B2B d'un autre développeur installés en même temps. Séparément, les deux ont parfaitement fonctionné. Mais ce qui s’est passé, c’est que lorsqu’un client B2B ouvrait une page de comparaison de produits, il voyait les prix de détail au lieu des prix de gros. Pourquoi? Parce que YITH Compare a généré son tableau de comparaison via une requête AJAX et que le plugin B2B a intercepté les prix via le hook woocommerce_product_get_price, qui dans le contexte de la requête Compare AJAX fonctionnait différemment que sur une page de produit classique. Le bug était reproduit uniquement pour les clients B2B, uniquement sur la page de comparaison, uniquement avec certains produits. Nous l'avons recherché pendant trois jours. Pendant trois jours, le programmeur s'est assis et a compris le code de deux plugins, dont nous avions un accès limité au code source, car tous deux étaient premium, avec du code obscurci.

Imaginez maintenant qu'il n'y ait pas un ou deux conflits potentiels de ce type sur le site, mais des dizaines. Chaque paire de plugins est un point d’intersection potentiel. Si vous disposez de vingt plugins, alors le nombre de paires possibles est de cent quatre-vingt-dix. Cent quatre vingt dix conflits potentiels. Bien sûr, tous ne sont pas mis en œuvre, mais même si un sur vingt « tire », cela représente près de dix problèmes réels, dont chacun nécessite du temps et de l'argent pour être diagnostiqué et corrigé.

Et les conflits ne sont pas que des bugs fonctionnels. C'est aussi une question de productivité. Chaque plugin ajoute ses propres tables à la base de données. ACF a ses propres tableaux, la liste de souhaits a la sienne, le module B2B a la sienne, la recherche a la sienne, l'intégration 1C a la sienne. Sur l'un des projets, j'ai calculé : vingt plugins ont créé un total de quarante-sept tables supplémentaires dans la base de données. Quarante-sept tableaux en plus des tableaux standards WordPress et WooCommerce. Et chaque plugin effectue ses propres requêtes SQL sur ses tables lorsque la page est chargée. Un plugin – deux à cinq requêtes. Vingt plugins - quarante à cent requêtes SQL supplémentaires pour chaque chargement de page. Et chacun inclut également son propre fichier CSS et son propre JavaScript. Vingt fichiers CSS, vingt fichiers JS - cela représente 500 à 800 kilo-octets supplémentaires que le navigateur doit télécharger, analyser et exécuter. Sur un Internet rapide, vous ne le remarquerez peut-être pas, mais PageSpeed ​​​​le remarquera et Yandex le remarquera également lors du classement.

J'ai mesuré cela sur un projet spécifique. Magasin d'huiles et lubrifiants, vingt-trois plugins. Le temps de réponse du serveur (TTFB) est de 1,8 seconde. Le chargement complet de la page du catalogue est de 4,2 secondes. Nous avons commencé à désactiver les plugins un par un et à mesurer à nouveau. Chaque plugin désactivé prenait en moyenne 80 à 120 millisecondes depuis TTFB. Lorsque nous avons remplacé dix-sept plugins par une solution complète, le TTFB est tombé à 0,7 seconde. La page a commencé à se charger en 1,9 seconde. Deux fois plus vite - sans changer d'hébergement, sans CDN, sans aucune autre optimisation. Simplement parce qu'au lieu de dix-sept morceaux de code indépendants, chacun étant initialisé à sa manière, chargeant ses ressources et faisant ses propres requêtes à la base de données, un plugin avec une architecture unique a commencé à fonctionner.

Mais parlons d'un autre aspect généralement oublié : les mises à jour. Vingt plugins, cela signifie vingt auteurs différents, vingt calendriers de mise à jour différents. Un auteur publie une mise à jour une fois par semaine, un autre une fois tous les six mois. L’un teste la compatibilité avec la dernière version de WooCommerce, l’autre non. L'un rédige un journal des modifications détaillé, l'autre se limite à des « corrections de bugs » laconiques. Et chaque mise à jour de chaque plugin représente un risque potentiel. Je connais des propriétaires de magasins qui passent deux à trois heures par semaine à vérifier les mises à jour disponibles, à lire les journaux des modifications, à décider quoi mettre à jour maintenant et ce qui peut attendre, à effectuer une sauvegarde, à mettre à jour, à vérifier si quelque chose est cassé. Deux à trois heures par semaine représentent cent à cent cinquante heures par an. Pour les mises à jour des plugins. Si vous traduisez en argent au taux d'au moins un administrateur système, cela représente 150 à 300 000 roubles supplémentaires par an en dépenses implicites.

Quand j'ai décidé que ça suffisait

Le tournant pour moi s'est produit il y a environ trois ans. J'ai travaillé sur un grand projet B2B - un magasin de produits chimiques industriels, un millier et demi de produits, un système de tarification complexe avec des groupes de clients et des remises individuelles, l'intégration avec 1C, SDEK multi-livraison plus KIT plus Business lignes, filtres par caractéristiques techniques, listes de souhaits, comparaison, formulaires de demande de devis. Ensemble standard pour un magasin B2B sérieux. Il y avait vingt-cinq plugins sur le site. Et puis WooCommerce a déployé une grosse mise à jour – je ne me souviens plus exactement de quelle version, mais la mise à jour était majeure, avec des modifications de l’API. Et c’est l’enfer qui s’est déchaîné. Trois plugins sur vingt-cinq se sont révélés incompatibles avec la nouvelle version. L'un d'eux, le plugin d'intégration 1C, a tout simplement cessé de fonctionner. L'auteur a publié une mise à jour deux semaines plus tard. Pendant deux semaines, le magasin a fonctionné sans synchronisation avec 1C - les soldes n'ont pas été mis à jour, les prix n'ont pas été mis à jour, les nouveaux produits n'ont pas été déchargés. Le deuxième plugin, le filtre de produits, a commencé à générer des erreurs lors du filtrage par prix. L'auteur a répondu au support quatre jours plus tard et a publié le correctif une semaine plus tard. Le troisième plugin, le module de tarification B2B, ne calcule plus correctement les remises de gros pour l'un des groupes de clients. Nous n’avons pas remarqué ce bug tout de suite, mais seulement lorsque le client s’est plaint qu’on lui facturait un prix de détail au lieu d’un prix de gros. Combien de commandes ont été traitées avec des prix incorrects avant que nous découvrions cela - je ne le sais toujours pas.

Et puis je me suis posé la question : pourquoi, en fait, tout devrait être comme ça ? Pourquoi un magasin a-t-il besoin de vingt-cinq produits logiciels indépendants provenant de vingt-cinq auteurs différents qui ne se connaissent pas ? Pourquoi ne pouvez-vous pas avoir un seul produit qui couvre tous les besoins du magasin ? Pas « un plugin qui fait tout mal », mais un produit avec une architecture bien pensée, où tous les modules fonctionnent dans une seule base de code, utilisent des bibliothèques communes, un système commun de hooks, des tables communes dans la base de données ?

J'ai commencé à chercher une telle solution. Et je ne l'ai pas trouvé. Plus précisément, j'ai trouvé plusieurs tentatives - des plugins « tout-en-un » pour WooCommerce, qui promettaient de tout remplacer dans le monde. Mais après une inspection plus approfondie, il s'est avéré qu'il s'agissait soit d'un ensemble de modules faiblement couplés, collés ensemble dans un seul fichier zip, soit de produits dont les fonctionnalités de chaque module étaient si réduites que des plugins spécialisés devaient encore être livrés pour fonctionner réellement. Le « filtre de produits » dans une telle combinaison se compose de trois cases à cocher et d'un curseur de prix. « B2B » est un champ permettant de saisir une remise de groupe. « Recherche » est une recherche WordPress standard avec un modèle différent. Vous ne pouvez pas bâtir une entreprise sérieuse avec cela.

Et puis j'ai décidé de le construire moi-même. Non pas parce que je suis le développeur le plus intelligent ou le plus expérimenté au monde, mais parce que je connaissais les besoins spécifiques des magasins avec lesquels j'ai travaillé. Je savais quelles fonctionnalités étaient réellement utilisées et lesquelles étaient du marketing. Je savais où les plugins étaient en conflit et pourquoi. Je savais quelles requêtes de base de données nuisaient aux performances et comment les optimiser. C'est ainsi qu'est né COS WP Woo - un plugin qui a commencé comme un outil interne pour mes projets et est devenu un produit à part entière.

Que signifie en pratique « un plugin au lieu de vingt » ?

Je ne vais pas décrire chaque bouton et chaque case à cocher ici - il existe une documentation et des pages avec des descriptions de modules individuels pour cela. Je veux parler d'un principe. À propos de ce qui change lorsque l’on passe d’un zoo de plugins à une solution unique. Et pourquoi ce n’est pas seulement « plus pratique », mais cela change fondamentalement la rentabilité et la fiabilité de votre magasin.

Commençons par l'architecture. Lorsque vingt plugins sont remplacés par un seul, cela ne signifie pas que vingt bases de code sont mécaniquement collées en une seule. Cela signifie qu'une architecture unique est créée dans laquelle tous les modules partagent une infrastructure commune. Chargeur automatique de classe générale - un au lieu de vingt. Système d'enregistrement de hook commun : tous les modules sont connectés via un seul point d'entrée, dans un ordre prévisible, sans conflits de priorité. API REST commune : espace de noms commun, système d'autorisation commun, normes de réponse communes. Tables partagées dans la base de données là où cela a du sens - au lieu que chaque module crée sa propre table pour la journalisation, une table Activity_log commune dessert tous les modules. Un bundle JavaScript courant est constitué d'un fichier au lieu de vingt, compilé par webpack, minifié, avec tremblement d'arborescence pour supprimer le code inutilisé. CSS commun - un système de style au lieu de vingt fichiers, chacun comportant sa propre version de Bootstrap ou son propre framework personnalisé.

En pratique, cela signifie que lorsque le module de tarification B2B calcule le prix de gros pour un groupe de clients, ce prix est instantanément visible par le module de comparaison de produits, le module de liste de souhaits, le module de panier, le module de filtrage des prix. Pas via des hooks intermédiaires qu’un plugin peut intercepter mais qu’un autre ne peut pas. Directement, via des services partagés. Parce que tous ces modules font partie d’un tout et se connaissent.

Lorsque le module de recherche indexe un produit, il l'indexe avec tous les champs personnalisés définis dans le module Champs personnalisés. Non pas parce que « nous avons écrit l'intégration avec ACF », mais parce que Custom Fields et Search sont deux modules du même plugin qui utilisent les mêmes services pour accéder aux données. Lorsque le module 1C met à jour les soldes des produits, ces données mises à jour sont instantanément disponibles pour le module de filtrage, le module de flux Yandex.Market et le module de notification de liste de souhaits (pour envoyer une lettre « le produit est de nouveau en stock »). Tout cela se produit en une seule requête, sans appels AJAX supplémentaires, sans mise en cache intermédiaire, sans synchronisation via cron.

Permettez-moi de montrer cela en utilisant des chiffres spécifiques d'un projet réel. Le magasin d’huiles et de lubrifiants est le même que celui que j’ai mentionné ci-dessus. Avant de passer à COS WP Woo : 23 plugins, 47 tables supplémentaires dans la base de données, environ 90 requêtes SQL pour charger la page catalogue, 18 fichiers CSS et 15 fichiers JS connectés en front end, TTFB 1,8 secondes, chargement complet 4,2 secondes. Après la transition : 1 plugin (plus WooCommerce, bien sûr, et le thème), 30 tables dans la base de données (oui, COS WP Woo crée aussi ses propres tables, mais il y en a moins, car les fonctions communes utilisent des tables communes), environ 35 requêtes SQL sur la même page, 3 fichiers CSS et 2 fichiers JS sur le frontend, TTFB 0,7 seconde, pleine charge 1,9 seconde. PageSpeed ​​​​Insights a montré une augmentation de 23 points sur ordinateur et de 18 points sur mobile. Sans aucune autre optimisation - uniquement en remplaçant le zoo de plugins par une solution unique.

Et maintenant à propos d'argent. Les mêmes 23 plugins coûtent au client environ 1 100 $ par an en abonnements. Plus environ 200 heures par an pour la maintenance - mises à jour, vérifications de compatibilité, résolution de conflits, contact avec l'assistance de différents fournisseurs. Au tarif minimum d'un administrateur système de 1 500 roubles par heure, cela représente 300 000 roubles supplémentaires. Total : environ 400 000 roubles par an pour entretenir le zoo de plugins. Le prix d'une licence COS WP Woo - je ne donnerai pas de chiffres précis ici, car nous avons un système tarifaire flexible en fonction du nombre de modules - mais je dirai ceci : les économies annuelles sont au moins triples. Et cela ne prend pas en compte les pertes implicites dues aux temps d’arrêt, aux conflits et à la faible vitesse du site.

Mais je veux être honnête : passer d'un zoo de plugins à une solution unique n'est pas gratuit. Ceci est un projet. Vous devez migrer les données : listes de souhaits des utilisateurs, paramètres de groupe B2B, champs de produits personnalisés, historique de recherche, règles de redirection. Nous devons configurer de nouveaux modules et vérifier que tout fonctionne comme prévu. Vous devez passer du temps. En règle générale, la migration d'un magasin moyen prend entre un et trois jours de travail. Mais ces journées portent leurs fruits dès le premier mois - grâce aux économies sur les abonnements, à l'augmentation de la vitesse, à la disparition des conflits.

Le côté obscur du tout-en-un - et pourquoi COS WP Woo n'est pas comme ça

Je comprends tout à fait le scepticisme que suscite l'idée d'« un plugin au lieu de vingt ». Parce que cette idée a un côté obscur connu, et il faut en parler ouvertement. Les solutions monolithiques « tout-en-un » sont souvent critiquées pour trois raisons : la dépendance vis-à-vis du fournisseur, la taille et la complexité excessives, et le risque que « si un plugin tombe en panne, tout se brise ». Examinons chacun de ces arguments honnêtement, sans glose marketing.

Verrouillage du fournisseur. Oui, lorsque vous passez de vingt plugins indépendants à un seul complexe, vous devenez dépendant d'un seul développeur. Si ce développeur abandonne le projet ou fait faillite, vous avez un problème. C’est un risque réel, et je ne prétendrai pas qu’il n’existe pas. Mais regardons les choses de l'autre côté. Quand on a vingt plugins, on dépend de vingt développeurs. Et si au moins l’un d’entre eux abandonne son plugin, vous avez aussi un problème, juste local. J'ai vu des situations où l'auteur d'un plugin WooCommerce populaire a tout simplement cessé de le prendre en charge, laissant des milliers de magasins avec un code mort qui devenait de moins en moins compatible avec chaque mise à jour de WordPress. Dans le cas d'un zoo, cela semble moins critique : vous pouvez remplacer un plugin mort par un plugin analogique. Mais migrer des données d’un plugin de liste de souhaits à un autre est aussi un projet, aussi du temps, aussi de l’argent. Il existe donc un risque de dépendance vis-à-vis du fournisseur dans les deux cas, mais il prend simplement une forme différente.

Concernant COS WP Woo spécifiquement, nous distribuons un plugin open source. Vous bénéficiez d'un PHP et d'un JavaScript complets et non obscurcis. Si nous disparaissons de la surface de la terre demain (ce qui, j'espère, n'arrivera pas), votre plugin fonctionnera toujours et tout développeur WordPress qualifié pourra le maintenir et le modifier. Cela nous distingue fondamentalement des plugins avec code crypté, qui se transforment en citrouille sans licence active.

Taille gonflée. Le deuxième argument classique est que si un plugin fait tout, il est forcément lourd et lent. J'ai seulement besoin d'une liste de souhaits - pourquoi dois-je télécharger l'intégration B2B et 1C ? L’argument est logique, mais il ignore une nuance importante : seul ce qui est activé est chargé. COS WP Woo est construit sur une architecture modulaire à chargement paresseux. Si vous n'avez pas activé le module 1C, son code n'est pas du tout chargé. Ce n’est pas « chargé mais pas exécuté », mais pas physiquement connecté. L'autochargeur ne charge pas les classes de modules inactifs, JavaScript utilise le fractionnement de code et le chargement paresseux - le paquet de pages actif ne contient pas le code des modules inactifs. En pratique, si vous utilisez dix des modules disponibles, la taille du code chargé est approximativement égale à dix plugins individuels, mais avec une différence importante : dix plugins individuels ont dix copies de wrappers jQuery, dix copies d'utilitaires AJAX, dix frameworks CSS différents. Un plugin avec une architecture modulaire possède une infrastructure commune pour tous les modules. Ainsi, en réalité, dix modules COS WP Woo pèsent moins que dix plugins indépendants similaires.

Le troisième argument est « si on casse, tout casse ». Ici, je serai le plus direct possible : oui, c'est un risque, et nous y avons pensé dès le début. Par conséquent, chaque module COS WP Woo est isolé dans son propre espace de noms, avec ses propres services, son propre contrôleur API REST et ses propres classes frontales. Si une erreur survient soudainement dans le module Mega Menu, cela n'affectera ni le module B2B ni le module de recherche. Chaque module est connecté via un wrapper try-catch au point d'initialisation, et une erreur fatale dans un module ne fait pas planter l'ensemble du plugin. Ce n'est pas une théorie - nous testons spécifiquement ce scénario : nous cassons artificiellement un module et vérifions que les autres continuent de fonctionner. De plus, une base de code unique signifie des tests unifiés : nous testons la compatibilité de tous les modules entre eux à chaque version, ce qui est impossible avec un zoo de vingt plugins indépendants.

Il y a un autre argument qui m'est parfois avancé : "Un plugin spécialisé sera toujours mieux qu'un module dans une moissonneuse-batteuse." Et ce n’est pas tout à fait vrai non plus. Wordfence est sans aucun doute un excellent produit de sécurité. Mais avez-vous besoin de tout Wordfence si votre magasin n'a besoin que de WAF, d'une protection contre la force brute, d'une surveillance de l'intégrité des fichiers et d'une authentification à deux facteurs ? Le module Sécurité de COS WP Woo couvre exactement ces besoins – ni plus, ni moins. SearchWP est un excellent plugin de recherche. Mais si votre magasin utilise déjà Typesense pour la recherche (et que notre module de recherche fonctionne spécifiquement avec Typesense - le moteur de recherche open source le plus rapide) - vous n'avez pas besoin de SearchWP avec sa recherche basée sur MySQL, qui commence à ralentir sensiblement avec un catalogue de dix mille produits. Parfois, un « module dans une combinaison » s'avère technologiquement plus moderne qu'un plugin spécialisé, simplement parce qu'il a été écrit plus tard et prend en compte l'expérience de ses prédécesseurs.

Je ne dis pas que COS WP Woo est meilleur que n'importe quel plugin dans tous les cas. Wordfence en sait plus que nous sur la sécurité de WordPress. Yoast en sait plus que nous sur le référencement. Mais pour une boutique WooCommerce typique qui n’a pas besoin d’un module, mais de dix à quinze, la valeur totale d’une seule solution dépasse largement les avantages des plugins individuels « les meilleurs de leur catégorie ». Parce que le meilleur de sa race isolément et le meilleur de sa race en association avec dix-neuf autres meilleurs de sa race sont deux expériences complètement différentes.

Laissez-moi passer en revue les principaux modules et vous dire ce qu'ils remplacent exactement. Non pas sous la forme d'une liste sèche - j'avais promis qu'il n'y aurait pas de listes - mais à travers le prisme des problèmes réels que chacun résout.

Le module AI Content est probablement la partie la plus unique de COS WP Woo, car il n'existe pratiquement pas d'analogue direct sous la forme d'un plugin séparé. Oui, il existe des plugins pour la génération de contenu IA, mais la plupart d'entre eux sont de simples wrappers sur l'API ChatGPT qui génèrent un texte à la fois. Notre module fonctionne en mode batch : vous définissez les paramètres, sélectionnez les produits - et BatchProcessor traite au moins un millier de positions en arrière-plan via l'Action Scheduler. Dans ce cas, vous pouvez choisir un fournisseur - Anthropic Claude ou OpenAI - et créer des invites spécialisées pour votre niche. Les tests A/B des descriptions permettent de comparer la conversion de différentes options de texte sur du trafic réel. Il s'agit d'un outil qui remplace non pas un plugin, mais tout un département de rédacteurs. L'un de nos clients, un magasin d'huiles automobiles, a généré des descriptions pour douze mille produits en une nuit. À la main, cela représente un travail de trois à quatre mois pour une équipe de trois rédacteurs.

Le module SEO et Audit est notre réponse à la combinaison Yoast Premium plus Rank Math. Audit complet des fiches produits basé sur quinze critères ou plus : longueur de la description, balises méta, textes alternatifs des images, liens internes, données structurées. Génération automatique de FAQ pour chaque produit avec sortie au format JSON-LD - ce sont les mêmes « questions et réponses » qui apparaissent directement dans les résultats de recherche et augmentent considérablement le CTR. Le module de redirection remplace Redirection ou Safe Redirect Manager. Le module Sitemap génère un plan de site XML optimisé pour WooCommerce - avec des produits, des catégories, des images. Et tout cela constitue un écosystème unique : l'auditeur connaît les champs personnalisés, les redirections sont intégrées à la recherche, le plan du site prend en compte la visibilité B2B des produits.

Le module B2B est généralement couvert par un groupe de trois à cinq plugins : YITH B2B, WooCommerce B2B, plugin de tarification de gros, plugin de demande de devis, plugin de sous-compte. Notre module B2B comprend dix sous-modules : groupes de clients avec tarification multi-niveaux, prix individuels, règles de visibilité des produits, quantités minimales de commande, portefeuille électronique, sous-comptes pour les employés du service achats, workflow pour les demandes de devis avec correspondance et contre-propositions, enregistrement personnalisé des clients B2B, documents PDF pour les propositions commerciales, passerelles de paiement pour le B2B - paiement des factures et des bons de commande. Je ne connais aucun plugin qui couvrirait tout cela en même temps. En règle générale, un B2B à part entière sur WooCommerce nécessite trois à cinq plugins, et ils entrent inévitablement en conflit les uns avec les autres car chacun modifie la logique de tarification de WooCommerce à sa manière.

Le module de recherche fonctionne avec Typesense, un moteur de recherche open source plus rapide et plus pertinent que n'importe quelle recherche basée sur MySQL, y compris SearchWP et Relevanssi. Recherche instantanée avec saisie semi-automatique, filtrage à facettes, synonymes, analyse des requêtes, curation de recherche - tout est prêt à l'emploi. Plus intégration avec des cartes de lubrifiants et des tableaux d’application. Remplace SearchWP (99 $ par an) ou Relevanssi Premium (99 euros par an), et est fondamentalement plus rapide.

Module de sécurité - WAF (Web Application Firewall), protection contre la force brute, surveillance de l'intégrité des fichiers, authentification à deux facteurs, géoblocage, URL de connexion personnalisée, journal d'activité, protection XML-RPC, intégration CAPTCHA. Remplace Wordfence Premium (119 $/an) ou Sucuri (199 $/an) pour les besoins typiques du magasin WooCommerce. Je ne prétends pas que notre module soit un analogue complet de Wordfence avec sa base de données de signatures et ses renseignements sur les menaces. Mais pour un magasin qui a besoin d'une protection de base contre les menaces standards, c'est plus que suffisant et, surtout, cela n'entre pas en conflit avec d'autres modules.

Le module Forms est un générateur de formulaires par glisser-déposer qui remplace Contact Form 7 (gratuit, mais avec des modules complémentaires payants) ou WPForms Pro (199 $/an). Formulaires de commentaires, formulaires de candidature, formulaires de demande de devis - tout est collecté dans un générateur visuel, les enregistrements sont stockés dans une base de données avec une journalisation complète. L'intégration avec le module Email vous permet d'envoyer des notifications via SMTP sans plugin supplémentaire.

Le module Custom Fields remplace complètement ACF Pro (Advanced Custom Fields). Groupes de champs, répéteurs, contenu flexible, galeries, règles de mise en page, logique d'affichage conditionnelle. Pour ceux qui ont utilisé ACF, la transition est presque transparente car nous avons implémenté une couche de compatibilité qui comprend les fonctions ACF get_field() et the_field(). Pourquoi changer ACF si ça marche ? Car ACF est un autre plugin indépendant avec ses propres tables, sa propre mise à jour, ses propres conflits potentiels. Et le module intégré de champs personnalisés fonctionne nativement avec le module de recherche (les champs sont automatiquement indexés dans Typesense), avec le module d'audit (l'auditeur vérifie l'exhaustivité des champs personnalisés), avec le module 1C (les champs sont mappés aux attributs 1C).

Le module Mega Menu remplace MaxMegaMenu Pro (49 $/an). Nous avons littéralement migré de MaxMegaMenu vers notre module sur le magasin de travail - nous avons désactivé MaxMegaMenu, activé notre module et tout a fonctionné. Sous-menus imbriqués, onglets du catalogue, icônes, adaptation mobile, tout est en place. Seulement maintenant, le menu ne nécessite pas de framework CSS distinct ni de bundle JavaScript distinct.

Module de filtre - similaire au filtre de produit YITH Ajax (99 $ par an). Filtrage par attributs, prix, disponibilité, note. Chargement AJAX des résultats sans recharger la page. Superposition mobile pour filtres sur petits écrans. L'index de filtrage natif n'est pas constitué de requêtes SQL directes sur les tables WooCommerce, mais d'un index pré-calculé mis à jour en arrière-plan. Cela permet de filtrer en quelques millisecondes même sur des catalogues de vingt mille produits.

Module d'expédition - multi-livraison : SDEK, KIT, Business Lines, Russian Post, Boxberry. Un module au lieu de cinq plugins distincts, un pour chaque opérateur. Une interface de configuration unique, une matrice unique pour sélectionner un mode de livraison à la caisse et un système de suivi unique. Économies - de 10 000 à 25 000 roubles par an sur les abonnements aux plugins d'opérateurs individuels.

Module 1C - Intégration OData avec 1C : Trade Management. Synchronisation des produits, prix, soldes, catégories, attributs. Cartographie des caractéristiques 1C sur la taxonomie WooCommerce. Exportez les commandes vers 1C. Remplace WC1C (de 5 000 à 15 000 roubles par an) ou divers plugins CommerceML. La principale différence réside dans l'intégration d'OData au lieu de CommerceML. OData est une API REST fonctionnant sur HTTP, tandis que CommerceML est un partage de fichiers sur FTP/HTTP qui est obsolète et peu fiable. OData permet la synchronisation en temps réel, CommerceML autorise uniquement le téléchargement périodique.

Module YandexFeed - génération d'un flux de produits pour Yandex.Market. Remplace un plugin séparé coûtant de 2 000 à 5 000 roubles par an. Intégration avec le module B2B - vous pouvez exclure du flux les produits visibles uniquement par les grossistes. Intégration avec le module Champs personnalisés - les champs de produits personnalisés apparaissent dans le flux en tant que paramètres.

Et je n'ai pas encore mentionné les modules Compare (comparaison des produits), Wishlist (liste de souhaits avec notifications sur les réductions de prix et les retours en stock), Cart Popup (panier contextuel), Bottom Menu (menu inférieur mobile), CSS Editor (éditeur CSS visuel), Media Folders (organisation d'une médiathèque en dossiers), Login Page (page de connexion personnalisée), Insert Code (insérer un code personnalisé - un analogue des extraits de code), Email (SMTP et journalisation des e-mails), Load More (sans fin défilement du catalogue), Store Customizer (personnalisation des pages WooCommerce), Swatches (nuanciers de couleurs pour les attributs), Activity Log (journal d'activité), Document Gallery (galerie de documents et certificats sur la page produit).

Je ne le cacherai pas : chacun de ces modules possède des fonctions que les concurrents spécialisés n'ont pas, et des fonctions que les concurrents implémentent plus en profondeur. C'est bien. Mais il ne s’agit pas de battre chaque concurrent individuellement : il s’agit de donner au magasin un tout fonctionnel plutôt qu’un ensemble de parties disparates. Et dans ce « tout », chaque module renforce les autres.

Lorsqu'un acheteur ajoute un produit à une liste de souhaits, le module Wishlist l'enregistre dans la base de données, le module Analytics en tient compte dans les statistiques, le module Email prépare l'envoi d'une notification lorsque le prix baisse, le module Recherche prend en compte la popularité du produit lors du classement des résultats. Quatre modules fonctionnent de manière synchrone, sans délais, sans duplication de données, sans conflits. Essayez d'obtenir la même chose à partir de quatre plugins indépendants - je vous souhaite sincèrement bonne chance.

Savez-vous ce qui m'a le plus convaincu sur la justesse de l'approche « un plugin au lieu de vingt » ? Il ne s’agit pas d’économiser de l’argent, ni d’augmenter la productivité, mais de simplifier les mises à niveau. Autrefois, lorsqu’une nouvelle version de WooCommerce sortait, je commençais par ouvrir une liste de vingt-cinq plugins et vérifier la compatibilité de chacun. Ensuite, j'ai attendu que tous les auteurs publient des mises à jour. Ensuite, j'ai mis à jour un par un, en vérifiant après chacun. L'ensemble du processus pourrait prendre une semaine. Maintenant, je mets à jour un plugin. Un. Nous testons la compatibilité avec la nouvelle version de WooCommerce avant la sortie, publions la mise à jour et le client clique sur un bouton. Si quelque chose ne va pas - un point de contact pour l'assistance, un journal des modifications pour vérification, un retour à la version précédente. Pas vingt-cinq lettres adressées à vingt-cinq services d'assistance différents : une demande, une réponse, une solution.

J'ai longuement réfléchi à la façon de terminer cet article, et j'ai décidé de ne pas le terminer par un joli « total », mais de dire ceci. Le zoo de plugins sur WooCommerce n’est pas un bug de la plateforme et n’est pas une fatalité. Cela est le résultat de l’évolution historique de l’écosystème WordPress : chaque développeur a résolu un problème, a intégré la solution dans un plugin et l’a vendue. Cela fonctionnait lorsque les magasins avaient besoin de deux ou trois extensions. Mais aujourd’hui, alors qu’une boutique WooCommerce moyenne a besoin de quinze à vingt extensions, le modèle « plugin par tâche » commence à éclater. Conflits, performances, coûts de maintenance - tout cela augmente de manière non linéaire avec chaque plugin ajouté. Deux plugins - presque aucun problème. Dix est tolérable. Vingt - vous passez plus de temps à entretenir le zoo qu'à développer votre entreprise.

Je ne dis pas que chaque boutique WooCommerce devrait immédiatement supprimer tous les plugins et installer COS WP Woo. Si vous avez une petite boutique avec cinq plugins et que tout fonctionne, pour l’amour de Dieu, n’y touchez pas. Mais si vous vous reconnaissez dans cet article - si vous possédez plus d'une quinzaine de plugins, si vous avez peur des mises à jour, si quelque chose tombe en panne tous les mois, si la vitesse de chargement des pages laisse beaucoup à désirer, si vous payez plus pour les abonnements que pour l'hébergement - demandez-vous s'il n'est pas temps de mettre les choses en ordre.

Essayez COS WP Woo gratuitement pendant 14 jours. Installez, activez les modules nécessaires, voyez comment ils fonctionnent dans votre combinaison. Migrez les données des plugins actuels - pour la plupart d'entre eux, nous disposons d'outils de migration directement dans l'interface. Et si au bout de deux semaines vous réalisez qu’un plugin peut réellement en remplacer vingt, vous serez surpris de ne pas l’avoir fait plus tôt. Et si cela ne fonctionne pas, vous ne perdrez rien à part quelques heures de tests. Mais je suis prêt à parier que cela suffira.