# Construire une marketplace WooCommerce à 500 fournisseurs, tunnel préservé

> Passer de quelques dizaines à plusieurs centaines de vendeurs tiers sur une même marketplace WooCommerce sans que le tunnel de commande ne s'effondre : l'enjeu se joue sur la répartition et le cache ciblé, pas sur le serveur.

- Auteur : Clément Hadrot
- Publié le : 2025-11-24
- Mis à jour le : 2025-11-24
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/marketplace-woocommerce-500-fournisseurs-tunnel/

## L’essentiel

- La commande unique doit se scinder en sous-commandes sans bloquer le paiement
- Le cache par vendeur limite l'impact d'un catalogue qui grossit sans cesse
- La commission se calcule après confirmation du paiement, jamais avant

500 vendeurs tiers, chacun avec son propre catalogue, ses propres règles d'expédition et sa propre commission : au-delà d'une certaine échelle, une marketplace WooCommerce construite avec les réglages par défaut d'une extension multi-vendeurs commence à ralentir précisément là où ça compte le plus — au moment du paiement, quand une commande unique du client doit être éclatée entre plusieurs vendeurs sans jamais bloquer la transaction.

Les extensions multi-vendeurs (Dokan, WCFM, WC Vendors) gèrent nativement la logique de séparation des commandes, mais leur configuration par défaut n'est pas pensée pour plusieurs centaines de vendeurs actifs simultanément. L'architecture qui tient à cette échelle repose sur trois principes : séparer strictement le calcul de commande du calcul de commission, mettre en cache le catalogue par vendeur plutôt que globalement, et ne jamais faire dépendre la confirmation de paiement d'un traitement synchrone lourd.

## Arborescence générale de la répartition des commandes

```
Commande client (panier multi-vendeurs)
├── Validation du paiement global (une seule transaction PSP)
├── Éclatement en sous-commandes (une par vendeur)
│   ├── Sous-commande vendeur A (statut : en attente de traitement)
│   ├── Sous-commande vendeur B (statut : en attente de traitement)
│   └── Sous-commande vendeur C (statut : en attente de traitement)
└── File asynchrone : calcul des commissions par sous-commande
    └── Notification vendeur (email + tableau de bord) une fois calculée
```

Le point clé de ce schéma : le paiement est validé une seule fois, globalement, avant tout éclatement. L'éclatement en sous-commandes et le calcul des commissions se font ensuite, de façon asynchrone, sans jamais faire attendre le client sur ce traitement.

## Pourquoi le calcul de commission ne doit jamais être synchrone

Sur une marketplace à quelques dizaines de vendeurs, calculer la commission de chacun en temps réel, au moment de la commande, reste transparent pour l'utilisateur. À 500 vendeurs, avec des grilles de commission parfois différentes par catégorie de produit ou par palier de volume mensuel, ce calcul devient une opération non triviale qui n'a aucune raison de bloquer la confirmation de commande côté client.

> L'essentiel à retenir : La commande unique doit se scinder en sous-commandes sans bloquer le paiement ; Le cache par vendeur limite l'impact d'un catalogue qui grossit sans cesse ; La commission se calcule après confirmation du paiement, jamais avant

Le traitement différé via Action Scheduler, déclenché juste après la confirmation de paiement, permet de calculer chaque commission dans une tâche isolée, avec sa propre reprise en cas d'échec, sans impact sur le temps de réponse perçu par le client final.

## Cache ciblé par vendeur plutôt que cache global du catalogue

Avec 500 vendeurs, le catalogue global change en permanence : un vendeur ajoute un produit, un autre modifie son stock, toutes les quelques secondes. Un cache de catalogue global, invalidé à chaque modification de n'importe quel vendeur, perd rapidement toute son efficacité. La solution consiste à segmenter le cache par vendeur, avec des groupes de cache d'objets distincts :

```
wp_cache_set( 'catalogue_vendeur_' . $vendeur_id, $produits, 'marketplace_vendeurs', 300 );
wp_cache_delete( 'catalogue_vendeur_' . $vendeur_id, 'marketplace_vendeurs' );
```

Ainsi, la modification d'un produit par un vendeur n'invalide que son propre segment de cache, laissant intacts les 499 autres.

## Ce que l'architecture ne doit pas essayer de résoudre

La gestion des litiges entre vendeurs et clients, les demandes de retour multi-vendeurs, ou l'arbitrage en cas de désaccord sur une commission relèvent d'un processus opérationnel, pas d'une architecture technique. Confondre les deux mène à des systèmes trop complexes qui tentent d'automatiser des décisions qui restent, en pratique, humaines.

> Sur ce type de projet, la règle appliquée est de séparer strictement ce qui doit être instantané pour le client (paiement, confirmation) de ce qui peut être différé de quelques secondes à quelques minutes (répartition, commission, notification vendeur), sans jamais faire percevoir ce délai côté client.

## Notre verdict

Une marketplace WooCommerce tient à 500 vendeurs à condition de traiter le paiement et la répartition comme deux étapes strictement séparées dans le temps, et de segmenter le cache par vendeur plutôt que de le penser globalement. Les extensions multi-vendeurs fournissent la brique fonctionnelle ; l'architecture de répartition et de cache reste, elle, à construire sur mesure au-delà d'un certain seuil.