Développeur WooCommerce : comment bien le choisir (et éviter les mauvaises surprises)

WooCommerce équipe environ un tiers des boutiques en ligne recensées dans le monde — en nombre de boutiques, car sa part tombe sous les 20 % si l'on ne regarde que le premier million de sites marchands. Cette popularité a un revers : à peu près n'importe quel développeur WordPress se présente aujourd'hui comme « développeur WooCommerce », alors que gérer un catalogue, une TVA multi-pays et un tunnel de paiement n'a pas grand-chose à voir avec l'assemblage d'un site vitrine.

L'écart de résultat est considérable. Une boutique mal construite ne plante pas le jour de la livraison : elle s'effondre six mois plus tard, quand le catalogue passe à 2 000 références ou quand arrive le premier pic de trafic. Voici comment reconnaître, avant de signer, quelqu'un capable de tenir la distance.

Pourquoi un spécialiste plutôt qu'un généraliste WordPress

Un site vitrine sert un contenu quasi statique. Une boutique WooCommerce, elle, exécute des requêtes en base à chaque page, gère des sessions de panier, synchronise des stocks, applique des règles fiscales et dialogue avec un prestataire de paiement. Ce sont deux métiers différents.

La différence se voit rarement à la livraison. Elle apparaît quand le catalogue grossit : une boutique de 200 produits pardonne beaucoup d'approximations, une boutique de 5 000 références n'en pardonne aucune. Les requêtes non indexées, les variations mal modélisées et les plugins qui se chargent sur toutes les pages deviennent alors des minutes de chargement.

Ce que WooCommerce ajoute vraiment à WordPress

WooCommerce est une extension, mais elle installe une application complète dans WordPress : deux types de contenu (le produit et la commande), trois taxonomies produit, un panier avec session, un moteur de calcul de taxes et un tunnel en plusieurs étapes. Rien de tout cela n'existe sur un site vitrine.

La conséquence est concrète : on ne personnalise pas une boutique en modifiant des gabarits, mais en se branchant sur les actions et les filtres que WooCommerce expose, depuis une extension maison ou un thème enfant. Un développeur qui ignore ce mécanisme éditera des fichiers que la prochaine mise à jour écrasera ; la boutique restera alors bloquée sur une version obsolète.

Cinq objets reviennent dans presque tous les projets. Votre prestataire doit savoir les nommer sans hésiter.

• Le produit variable — une fiche, plusieurs déclinaisons avec leur propre prix, leur propre stock et leur propre référence. Mal modélisé, il rend le catalogue impossible à filtrer.
• Les attributs globaux — réutilisables d'un produit à l'autre, ils alimentent les filtres. Les attributs locaux, eux, ne filtrent rien.
• La gestion du stock — décrément à la commande ou au paiement, réservation pendant le tunnel, rupture partielle sur une commande multi-articles.
• Les statuts de commande — chacun déclenche des e-mails et des écritures. Les personnaliser est courant, en inventer hors de l'API est une source de pannes.
• Le stockage des commandes (HPOS) — les commandes vivent désormais dans des tables dédiées, plus dans wp_posts. Les extensions anciennes ne suivent pas toutes.

Ce sont exactement les endroits où une boutique mal construite commence à coûter cher. Une question suffit à tester le terrain : « comment gérez-vous une rupture de stock sur une seule déclinaison d'un produit variable ? »

Les 6 compétences à vérifier avant de signer

Au-delà de « connaître WordPress », voici ce qui distingue concrètement quelqu'un capable de livrer une boutique qui tiendra dans le temps.

• Les hooks WooCommerce — savoir modifier un comportement via add_filter plutôt qu'en éditant le cœur ou le thème parent. C'est ce qui rend les mises à jour possibles sans tout casser.
• La modélisation du catalogue — distinguer produit variable, produit groupé et attribut global. Une erreur à ce niveau se paie pendant des années.
• La performance en base — comprendre pourquoi wp_postmeta devient le goulot d'étranglement, et savoir quand basculer sur des tables dédiées ou du HPOS.
• Les paiements et la TVA — SCA, 3D Secure, TVA intracommunautaire, guichet unique OSS. Ce sont des sujets réglementaires, pas des options.
• Le tunnel de commande — savoir mesurer et corriger l'abandon panier, pas seulement l'afficher.
• Le RGPD appliqué au e-commerce — durée de conservation des commandes, consentement, sous-traitants.

Personne n'est excellent sur les six. Ce qui compte est que votre interlocuteur sache dire où il est faible et comment il compense : un expert-comptable pour la TVA, un hébergeur spécialisé pour la performance. La réponse inquiétante est celle qui prétend tout couvrir.

Les questions à poser en entretien

Ces questions ne demandent aucune compétence technique pour être posées, mais les réponses sont très discriminantes.

• « Combien de boutiques avez-vous en production aujourd'hui, et quelle est la plus grosse en nombre de références ? »
• « Comment gérez-vous les mises à jour de WooCommerce sur un site que vous avez personnalisé ? »
• « Que se passe-t-il si je veux changer de prestataire dans deux ans ? »
• « Le site m'appartient-il entièrement, code et accès compris ? »
• « Quel est votre plan si la boutique tombe un samedi de forte affluence ? »
• « Sur quels indicateurs jugerez-vous que le projet est réussi ? »

Lire un portfolio e-commerce sans être technique

Un portfolio de boutiques est facile à embellir : des captures d'écran ne prouvent rien, une maquette encore moins. Cinq vérifications suffisent à écarter les profils qui n'ont jamais dépassé le site vitrine doté d'une page « boutique ».

• Demandez des adresses de boutiques en production, pas des visuels. Vérifiez qu'on peut ajouter au panier et atteindre la page de paiement.
• Ouvrez une page catégorie avec un filtre actif, pas la page d'accueil. C'est là que les requêtes se multiplient, et c'est cette page que Google évalue.
• Cherchez un produit à variations — taille, couleur, contenance. Un développeur qui n'a livré que des produits simples n'a pas rencontré la moitié des problèmes réels.
• Testez la recherche interne et le tri par prix sur un catalogue fourni. Beaucoup de boutiques s'effondrent exactement là.
• Demandez depuis combien de temps la boutique tourne et qui l'a mise à jour depuis. Une boutique de deux ans encore à jour vaut mieux qu'une refonte récente.

Ces vérifications ne remplacent pas un audit de code, mais elles changent la nature du dialogue. Un développeur qui a livré de vraies boutiques répond avec des chiffres : nombre de références, volume de commandes, temps de réponse serveur. Celui qui n'en a pas livré répond avec du vocabulaire de design.

Les intégrations qu'il faut chiffrer à part

La première source de dérapage budgétaire n'est pas le design, c'est le raccordement de la boutique au reste de l'entreprise. Un devis qui annonce un prix global sans détailler ces postes vous fera découvrir la facture en cours de route.

Deux détails font varier ces montants du simple au triple. Le sens de la synchronisation d'abord : l'ERP écrase-t-il le catalogue, ou l'inverse ? Le bidirectionnel coûte nettement plus cher. La fréquence ensuite : un stock rafraîchi chaque nuit suffit à beaucoup d'activités, quand le temps réel devient un projet à lui seul.

Le cas où il ne faut pas intégrer mérite d'être dit : en dessous de vingt commandes par mois, la ressaisie manuelle coûte quelques minutes par commande, quand une synchronisation ERP représente plusieurs milliers d'euros à maintenir des deux côtés.

Pourquoi 3 000 références ne se comportent pas comme 20 pages

Sur un site vitrine, une page se met en cache et se sert telle quelle. Sur une boutique, le panier, les prix par client, la disponibilité et les filtres changent d'un visiteur à l'autre : le cache classique ne peut pas tout absorber, d'où une architecture différente.

Le point de bascule se situe rarement en dessous de mille références. Au-delà, une page catégorie filtrée peut déclencher des centaines de requêtes sur les métadonnées produit, et le temps de réponse serveur passe de 200 millisecondes à plusieurs secondes.

Voici ce qu'un développeur expérimenté met en place, et que le devis peut exiger.

• Un cache de page qui exclut le panier, le compte client et le tunnel, plutôt qu'un cache global qui finit par afficher le panier d'un autre visiteur.
• Le stockage HPOS activé, et des index en base sur les colonnes réellement interrogées.
• Des images produit en WebP ou AVIF, dimensionnées pour la vignette de catégorie et non pour la fiche.
• Un filtrage qui interroge des tables de correspondance au lieu de balayer les métadonnées à chaque clic.
• Une mesure avant et après, sur une page catégorie réelle.

Le budget réel en 2026

Les fourchettes ci-dessous correspondent au marché français, pour un travail sur mesure et non un assemblage de thème.

Un devis nettement sous ces fourchettes finance rarement le travail invisible : la modélisation du catalogue, les tests de commande, la conformité fiscale. Ce travail sera fait quand même — mais par vous, ou par le prestataire suivant.

Ramené à la journée, un spécialiste WooCommerce facture entre 400 et 700 € en France. En dessous de 350 €, vous payez un intégrateur de thème : cela peut suffire pour une boutique simple, mais pas pour une intégration transporteur ni un correctif sur le tunnel.

Maintenance, sécurité et propriété du code

WooCommerce publie des versions correctives régulièrement, et chaque extension suit son propre rythme. Sur une boutique, une mise à jour ratée ne casse pas une mise en page : elle empêche de payer. La question n'est donc pas de savoir si vous prenez un contrat de maintenance, mais lequel.

Le point à écrire noir sur blanc est le délai d'intervention quand le tunnel de commande est cassé : une boutique arrêtée un samedi coûte une journée de chiffre d'affaires, et une réponse promise « sous 48 heures ouvrées » ne vous protège de rien. Demandez aussi comment se déroule une restauration : une sauvegarde jamais restaurée est une sauvegarde inconnue.

Ce que le devis doit dire sur la propriété

Beaucoup de litiges viennent de là. Un site peut vous être livré sans que vous en soyez propriétaire au sens pratique : hébergement au nom du prestataire, extensions payantes sous sa licence, code jamais versionné. Quatre lignes suffisent à fermer le sujet.

• Le code sur mesure vous est cédé, avec les droits d'exploitation et de modification.
• L'hébergement, le domaine et le compte de paiement sont ouverts à votre nom.
• Les licences des extensions payantes sont à votre nom, renouvelables sans le prestataire.
• Vous avez un accès au dépôt Git et une sauvegarde complète exportable.

Sans ces garanties, la reprise par un autre prestataire se paie en jours d'archéologie, parfois plusieurs milliers d'euros.

Les signaux qui doivent vous faire renoncer

Ces signaux ne sont pas des détails de forme. Chacun correspond à un litige déjà vu, et aucun ne se corrige facilement une fois le contrat signé.

• Aucune boutique en production à montrer, seulement des maquettes.
• Le devis ne mentionne ni la recette, ni la reprise du catalogue existant.
• L'hébergement et le nom de domaine sont ouverts au nom du prestataire.
• Aucune mention de sauvegarde ni d'environnement de test.
• La question de la TVA et des mentions légales est renvoyée à « votre comptable ».

FAQ — Recruter un développeur WooCommerce

WooCommerce convient-il à une grosse boutique ?

Oui, jusqu'à plusieurs dizaines de milliers de références, à condition que la base soit correctement modélisée et que le stockage des commandes en tables dédiées (HPOS) soit activé. La limite pratique vient presque toujours de la qualité de l'intégration, pas de WooCommerce lui-même.

Faut-il un freelance ou une agence ?

Un freelance expérimenté suffit pour une boutique standard et coûte moins cher. Une agence se justifie quand il faut garantir une continuité de service, gérer des synchronisations avec un ERP, ou tenir des engagements de disponibilité contractuels.

Combien coûte un développeur WooCommerce à la journée ?

Entre 400 et 700 € par jour en France pour un profil réellement spécialisé e-commerce. En dessous de 350 €, il s'agit généralement d'un intégrateur de thème plutôt que d'un développeur capable d'intervenir sur le comportement de la boutique.

Peut-on migrer de Shopify vers WooCommerce ?

Oui. La migration du catalogue, des clients et de l'historique de commandes est un travail standard. Le point de vigilance est la conservation des URLs produits avec des redirections 301, faute de quoi la boutique perd son référencement acquis.

Combien de temps faut-il pour créer une boutique WooCommerce ?

Comptez 4 à 6 semaines pour une boutique simple dont le catalogue est déjà propre, et 2 à 5 mois dès qu'il faut synchroniser un ERP ou alimenter des marketplaces. Le délai dépend surtout de vous : les fiches produits, les photos et les conditions de vente bloquent le planning plus souvent que le développement.

Comment vérifier le niveau technique sans savoir coder ?

Ouvrez une page catégorie filtrée d'une de ses boutiques en production et mesurez-la avec PageSpeed Insights en mobile. Demandez ensuite comment les personnalisations ont été faites : une extension dédiée ou un thème enfant avec des hooks valent mieux qu'un constructeur de pages.

Sources

• WooCommerce — Stockage des commandes HPOS — pourquoi les commandes ne vivent plus dans wp_posts
• WooCommerce — Référence des hooks et filtres — ce que l'on surcharge sans toucher au cœur
• WooCommerce — Produits variables — modélisation des variations et des attributs
• WooCommerce — Configurer la TVA — règles de taxe et taux par pays
• WordPress — Sauvegardes et restauration — ce que doit couvrir un plan de sauvegarde
• web.dev — Core Web Vitals — seuils LCP, INP, CLS
• Service-Public — Numéro de TVA intracommunautaire — obligations de facturation dans l'Union européenne