Comment j’ai transformé un catalogue industriel en expérience d’achat configurée

Quand WooCommerce ne suffit plus : comment j’ai conçu un configurateur produit sur-mesure

Il y a des projets où l’on sait dès le brief que les plugins du marché ne feront pas l’affaire. Celui-ci en faisait partie.

Un client e-commerce B2B avait un problème simple à énoncer, compliqué à résoudre : ses produits ne sont pas des articles. Ce sont des systèmes. Une installation, c’est un ensemble de composants interdépendants (quantités, dimensions, accessoires conditionnels) et un prix qui découle de tout ça. Impossible à mettre dans une fiche produit standard, impossible à configurer avec un plugin générique.

La commande : six configurateurs distincts, avec calcul instantané, aperçu visuel en temps réel, et ajout au panier WooCommerce par composant.

La contrainte qui change tout : le prix côté serveur

Avant de parler architecture, il y a une décision technique qui a structuré tout le reste : les prix ne sont jamais calculés côté client.

C’est le piège classique des configurateurs JavaScript. On calcule le total dans le navigateur, on envoie le résultat au panier. Et n’importe qui avec les outils de développement peut modifier ce total avant envoi.

Ici, le JS fait le travail d’affichage et d’UX (calcul instantané, aperçu visuel, récapitulatif). Mais quand l’utilisateur clique sur « Valider et commander », c’est le serveur PHP qui recalcule intégralement chaque prix à partir des tables stockées en base WordPress, en ignorant les montants envoyés par le client. Le hook woocommerce_before_calculate_totals surcharge ensuite les prix du panier côté serveur, inaccessible au navigateur.

Ce n’est pas la solution la plus simple. C’est la seule acceptable sur un site e-commerce.

Six configurateurs, une architecture commune

Chaque configurateur est un module indépendant qui charge son propre template PHP et son propre fichier JavaScript. Mais ils partagent tous la même colonne vertébrale :

• Un registre centralisé qui déclare pour chaque configurateur son template et son fichier JS
• Une table de prix stockée en base, éditable via une interface d’administration dédiée
• Un mapping produits qui fait correspondre chaque référence interne à un ID de variation WooCommerce
• Un script commun qui gère l’ajout au panier multi-composants via AJAX

Quand un utilisateur valide sa configuration, le JS envoie une liste d’items avec leurs références et quantités. Le PHP retrouve les IDs WooCommerce via le mapping, recalcule les prix via les tables serveur, et ajoute chaque composant comme une ligne de panier distincte.

Le défi du panier : rendre lisible l’invisible

Une configuration de taille moyenne, c’est facilement 15 à 25 lignes dans le panier WooCommerce. Affiché tel quel, le panier est illisible pour le client.

La solution : masquer toutes les lignes techniques et les remplacer par un récapitulatif visuel généré à partir des données de configuration stockées en session WooCommerce.

Le client voit dans son panier un bloc clair avec ses dimensions, ses quantités et son total HT, plus un lien « Reconfigurer » qui restaure l’état exact du configurateur. Toute la complexité technique reste invisible.

Ce mécanisme de restauration d’état a demandé un travail particulier : sérialiser l’état complet du configurateur (mode, dimensions, accessoires sélectionnés) dans les métadonnées de session WooCommerce, puis le désérialiser côté JS au chargement de la page produit.

La logique métier embarquée dans le JS

Chaque configurateur a sa propre logique de calcul.

L’utilisateur saisit une longueur utile souhaitée et choisit ses dimensions. Le JS calcule automatiquement les quantités de composants nécessaires, puis la longueur hors tout réelle en tenant compte des épaisseurs de montage.

Si la longueur demandée ne tombe pas juste, le configurateur affiche l’écart et la longueur réellement couverte, sans arrondir silencieusement.

Un garde-fou automatique bascule le bouton « Valider et commander » en « Demander un devis » au-delà de certains seuils, à partir desquels une commande en ligne n’est plus adaptée.

Ce qui n’était pas prévu : les contraintes d’intégration WooCommerce

Intégrer un système aussi custom dans WooCommerce sans modifier le plugin lui-même impose quelques contorsions.

La plus délicate, c’est la gestion des prix personnalisés dans le panier. WooCommerce calcule les totaux depuis les prix des produits en base. Pour imposer les prix du configurateur, il faut stocker le prix calculé dans les métadonnées du panier et le réinjecter à chaque recalcul de totaux via un hook dédié, tout en s’assurant que ce hook ne tourne qu’une seule fois par cycle pour éviter les boucles infinies.

L’autre contrainte, c’est la persistance des données de configuration entre sessions. WooCommerce stocke les données du panier en session PHP, qui expire. Pour les paniers persistants (utilisateurs connectés), les métadonnées de configuration sont également stockées sur les lignes de commande, ce qui permet au récapitulatif de rester correct même après reconnexion.

Ce que ce projet m’a appris

Ce type de développement est à l’opposé de l’intégration WordPress classique. Il n’y a pas de plugin à configurer, pas de widget à paramétrer : chaque décision technique est un choix d’architecture avec des conséquences sur la sécurité, la maintenabilité et l’expérience utilisateur.

Trois choses que je retiens de ce projet :

La sécurité par défaut, pas en option. Recalculer les prix côté serveur systématiquement, même quand le client ne le demande pas explicitement, c’est une exigence non négociable sur un site marchand.

La complexité doit être invisible pour l’utilisateur. Des dizaines de lignes de panier masquées derrière un récapitulatif lisible, une restauration d’état transparente, un basculement automatique vers le devis : l’UX finale ne doit rien laisser paraître de la complexité sous-jacente.

La logique métier appartient au code, pas à la configuration. Les règles de calcul (dimensions variables, garde-fous, accessoires conditionnels et exclusifs) sont dans le code, documentées, testables. Pas dans une feuille de calcul qu’un collaborateur met à jour manuellement.

Vous avez un projet e-commerce qui dépasse les capacités des solutions standard ? Parlons-en.