Hébergement marketplace : ce qu’il faut regarder avant de choisir
- Arnaud
- 7 minutes de lecture
Si vous cherchez où héberger une marketplace, la réponse courte tient en une phrase : une plateforme multi-vendeurs ne se dimensionne pas comme un site e-commerce, parce que la quasi-totalité de son trafic est authentifié et doit donc être calculée à chaque requête. Tout le reste en découle, y compris le budget.
Cet article détaille ce que cela implique en pratique, les trois modèles d’hébergement disponibles avec leurs limites respectives et la façon dont nous traitons la question chez Origami Marketplace.
Sommaire :
- Une marketplace ne charge pas comme une boutique en ligne
- Les erreurs de dimensionnement qu’on voit le plus souvent
- Hébergeur, infrastructure dédiée ou plateforme managée : trois compromis
- Pourquoi l’hébergement en France revient systématiquement dans les projets B2B
- Ce que le modèle d’architecture change sur la facture
- Comment nous hébergeons les marketplaces de nos clients
- Questions fréquentes
Une marketplace ne charge pas comme une boutique en ligne
- Un site e-commerce classique, la majorité des visiteurs sont anonymes. Les fiches produit sont identiques pour tout le monde, elles se mettent en cache, un CDN les sert et le serveur applicatif ne voit passer qu’une fraction du trafic réel. C’est le modèle pour lequel la plupart des offres d’hébergement e-commerce sont pensées.
- Une marketplace peut fonctionner dans l’autre sens, surtout en B2B. L’acheteur peut se connecter et avoir des tarifs négociés, un catalogue autorisé, des circuits de validation différents d’un autre. Chaque page doit être calculée pour lui, ce qui rend le cache largement inopérant. Pendant ce temps, les vendeurs travaillent dans leurs propres back-offices : mise à jour des stocks, ajout de références, traitement des commandes. Là où une boutique gère une interface d’administration, une marketplace en gère autant qu’elle compte de vendeurs actifs, et toutes écrivent en base de données simultanément.
« Il faut y ajouter les traitements de fond, invisibles dans les statistiques de fréquentation, mais très présents dans la consommation de ressources. Un fournisseur qui pousse 60 000 références en fin de journée déclenche une normalisation de données, une réindexation du moteur de recherche, parfois un recalcul de prix sur tout son périmètre. Cela n’apparaît nulle part dans le nombre de visites du mois, mais cela occupe la base de données pendant que les acheteurs, eux, passent commande.. »
Vincent Pichon, cofondateur et CTO d’Origami Marketplace
Les erreurs de dimensionnement qu'on voit le plus souvent
Raisonner en visiteurs mensuels
Le chiffre qui dimensionne réellement une marketplace, c’est le nombre de sessions authentifiées simultanées en heure de pointe, croisé avec le volume du catalogue. Deux plateformes affichant le même trafic mensuel peuvent avoir des besoins d’infrastructure très différents selon que leurs utilisateurs consultent ou travaillent.
Traiter la base de données comme un composant secondaire
Une marketplace dont la base est indisponible n’est pas dégradée, elle est arrêtée. Plus de catalogue, plus de panier, plus de commande. La bonne question à poser à un hébergeur ou à un prestataire ne porte donc pas sur la puissance du serveur, mais sur le comportement en cas de panne : y a-t-il une réplique ? La bascule est-elle automatique ? En combien de temps, et avec quelle perte de données acceptée ? Les sauvegardes appellent la même précision. Une sauvegarde dont la restauration n’a jamais été testée est une intention, pas une garantie.
Découvrir la question de l’isolation pendant l’audit
L’isolation se joue à deux niveaux, et les deux finissent par être examinés. Entre vendeurs d’abord, puisque chacun ne doit voir que ses produits, ses commandes et ses marges. Entre organisations clientes ensuite, dès que l’infrastructure est partagée. C’est presque toujours le sujet sur lequel bute un projet au moment de la revue de sécurité, et il se prépare en amont, avec une architecture documentée, pas avec une réponse improvisée à un questionnaire de 200 lignes.
Faire l’économie d’un environnement de recette
Une marketplace évolue en continu : nouveau connecteur, nouvelle règle de commission, nouveau workflow de validation. Sans environnement de préproduction comparable à la production, chaque mise en ligne devient un pari sur un système qui porte des transactions.
Superviser la technique en oubliant le métier
Un serveur peut afficher tous ses indicateurs au vert pendant que les paiements échouent chez un vendeur, ou qu’un import de catalogue tourne depuis six heures sans finir. La supervision utile suit aussi les signaux fonctionnels : taux d’erreur au tunnel de commande, durée des traitements asynchrones, âge du dernier import réussi par fournisseur.
Besoin d'un modèle de cahier des charges ?
Découvrez notre modèle prêt à l’emploi pour cadrer rapidement votre projet de plateforme multi-vendeurs, comparer les solutions du marché et sécuriser votre projet.
Modèle complet • Utilisé sur des projets achats B2B, B2C et C2C • Prêt à adapter
Hébergeur, infrastructure dédiée ou plateforme managée : 3 compromis
La marketplace « plugin » sur hébergement managé
C’est l’approche des extensions multi-vendeurs sur WordPress et WooCommerce. On part d’un site e-commerce, on ajoute une couche vendeurs, on héberge chez un spécialiste WordPress.
L’intérêt est réel : coût d’entrée faible, mise en route rapide, écosystème d’extensions très riche, et une communauté qui documente à peu près tous les cas d’usage. Pour valider une idée, ou pour opérer une marketplace grand public de taille modeste, c’est un choix défendable.
Les limites apparaissent avec le volume. L’architecture reste celle d’un site unique auquel on a greffé du multi-vendeurs, ce qui pèse sur les requêtes à mesure que les références et les vendeurs s’accumulent. Chaque mise à jour engage la compatibilité d’une pile d’extensions que personne ne maintient ensemble. Et le seul levier de croissance proposé reste le passage au palier tarifaire supérieur. Les exigences classiques d’un projet B2B, authentification unique, workflows de validation d’achat, connexion à un ERP, engagements de disponibilité contractualisés, sortent assez vite du cadre.
Une infrastructure dédiée par client
Chaque marketplace tourne sur son propre environnement. L’isolation est nette, le dimensionnement se fait sur mesure, la réversibilité est simple à expliquer à une DSI.
C’est le modèle sur lequel Origami Marketplace a démarré, en cloud public chez OVHcloud, avec un environnement par client. Il fonctionne bien tant que le nombre de plateformes reste faible, et il devient un problème d’échelle assez mécaniquement : chaque nouveau contrat ajoute une infrastructure complète à déployer, puis à maintenir. Certificats, mises à jour, incidents, supervision, sauvegardes. Le coût suit le nombre d’environnements, et le temps des équipes aussi.
« Chaque nouveau client signifiait un environnement de plus à maintenir. Pour une entreprise en croissance comme la nôtre, avec des clients dont les usages devenaient de plus en plus critiques pour leur business, on sentait bien que le modèle devait être optimisé. Nos équipes passaient un temps croissant sur des sujets d’exploitation au lieu de se concentrer sur le produit. »
Vincent Pichon, cofondateur et CTO d’Origami Marketplace
Une plateforme mutualisée et isolée
Le troisième modèle refuse l’arbitrage entre mutualisé et dédié. C’est celui qu’Origami Marketplace a adopté pour ses clients. Une seule infrastructure, industrialisée, sur laquelle chaque environnement client est cloisonné logiquement : espaces de noms séparés, politiques réseau, quotas de ressources, accès distincts. La mutualisation permet de densifier les charges de travail et d’absorber un pic chez un client avec la capacité disponible sur l’ensemble. Le cloisonnement préserve la gouvernance des données de chacun.
Il faut être honnête sur ce que ce modèle demande. Mal paramétré, il expose au voisinage bruyant, c’est-à-dire à un environnement qui consomme au détriment des autres, ce qui se corrige avec des quotas et des limites posés sérieusement dès le départ.
Il suppose une vraie compétence Kubernetes, en interne ou chez un partenaire, et ce n’est pas une compétence qu’on improvise sur un incident de production. Enfin, il n’a d’intérêt qu’à partir de plusieurs environnements à opérer : pour une plateforme unique, la complexité ajoutée ne se rembourse pas.
| Critère | Plugin sur hébergement managé | Infrastructure dédiée par client | Plateforme mutualisée et isolée |
|---|---|---|---|
| Modèle | Site e-commerce plus surcouche vendeurs | Un client, une plateforme | Une plateforme, N environnements cloisonnés |
| Coût quand l'activité croît | Par paliers tarifaires | Croissance linéaire | Découplé du nombre d'environnements |
| Absorption des pics | Faible | Prévue environnement par environnement | Capacité mutualisée |
| Isolation | Applicative | Physique | Logique stricte, documentée |
| Ouverture d'un environnement | Nouveau site à monter | Projet d'infrastructure | Déploiement automatisé |
| Compétence requise | WordPress | Système et cloud | Kubernetes, en interne ou déléguée |
| Pertinent pour | Petites marketplaces grand public | Projet unique très contraint | Marketplaces B2B, sectorielles, e-procurement |
Pourquoi l'hébergement en France revient systématiquement dans les projets B2B
Sur un projet grand compte, l’hébergement finit toujours par sortir du périmètre technique pour arriver devant la DSI, la sécurité, parfois les achats. La demande est presque toujours formulée de la même manière : nous voulons que les données restent en France, ou au moins en Europe.
Cette attente est légitime, en particulier quand la plateforme manipule des conditions commerciales négociées, des données de fournisseurs ou des informations concernant des adhérents. Elle mérite pourtant d’être précisée, parce que le vocabulaire est devenu très élastique. Le RGPD n’impose pas un hébergement en France, il encadre les traitements et les transferts hors Union européenne.
Une exigence de localisation nationale relève donc le plus souvent d’une politique interne, d’une exigence contractuelle ou d’un choix stratégique, ce qui est parfaitement recevable, mais n’est pas la même chose qu’une obligation réglementaire. Savoir de quoi on parle évite de payer pour un argument commercial plutôt que pour une garantie. Trois questions suffisent en général à faire le tri entre les offres qui s’appuient sur des faits et celles qui s’appuient sur un champ lexical :
- Dans quel pays se trouvent physiquement les serveurs et l’engagement figure-t-il au contrat ?
- L’architecture d’isolation est-elle documentée dans un support opposable en audit ?
- Qui dispose d’un accès d’administration à l’infrastructure et de quelle entité juridique ces personnes relèvent-elles ?
Ce que le modèle d'architecture change sur la facture
Comparer des offres d’hébergement sur leur seul montant mensuel donne une image fausse, pour deux raisons.
- La première est le temps d’exploitation : Il ne figure sur aucune facture d’hébergeur, mais se paie en salaires : mises à jour, renouvellement de certificats, gestion des sauvegardes, astreinte, traitement des incidents. Sur une plateforme transactionnelle, ce poste n’est pas marginal.
- La seconde est le surdimensionnement : une infrastructure se dimensionne sur son pic, et l’on paie donc toute l’année une réserve de capacité utilisée quelques heures par mois. Dans un modèle dédié par client, chaque environnement porte sa propre réserve, et la somme de ces réserves dépasse largement le besoin réel de l’ensemble. Une plateforme mutualisée partage cette réserve, ce qui améliore nettement l’allocation des ressources et découple la courbe de coût du nombre d’environnements.
Cela ne rend pas l’hébergement gratuit, et il existe des situations où un environnement dédié reste plus adapté, par exemple lorsqu’une plateforme atteint une taille telle qu’elle consomme l’équivalent d’une infrastructure complète, ou lorsqu’une contrainte contractuelle l’impose explicitement. L’arbitrage se fait au cadrage, pas par principe.
Comment nous hébergeons les marketplaces de nos clients
Origami Marketplace est une solution française qui permet aux entreprises de créer et d’opérer leurs propres marketplaces : B2B, e-procurement, plateformes de services, digitalisation de réseaux de revendeurs. Parmi nos clients figurent des fédérations sportives nationales, des mutuelles et des groupes industriels, pour lesquels la plateforme est un outil de production.
Nous avons donc traversé nous-mêmes la transition décrite plus haut. À l’été 2022, accompagnés par les équipes d’Enix, nous avons fait évoluer notre modèle dédié par client vers une plateforme Kubernetes mutualisée.
L’infrastructure repose aujourd’hui sur des machines bare metal OVHcloud, virtualisées avec Proxmox, sur lesquelles tournent deux clusters Kubernetes, l’un pour le développement, l’autre pour la production. Tous les environnements clients sont hébergés dans le cluster de production, avec des ressources partagées et une isolation stricte des données. Le déploiement d’un nouvel environnement est automatisé par des opérateurs Kubernetes, et les bases de données sont opérées en haute disponibilité directement au sein du cluster.
« Le passage à une plateforme à la fois mutualisée et isolée a été un vrai tournant. Mutualisée pour découpler notre croissance du nombre d’environnements à gérer, isolée pour conserver une gouvernance stricte de la donnée de chaque client. On a gagné sur les deux tableaux : le scale et la sécurité. Onboarder un nouveau client, c’est devenu un processus fluide, plus un projet d’infrastructure. »
Vincent Pichon, cofondateur et CTO d’Origami Marketplace
La migration s’est faite client par client, sans rupture de service, ce qui reste la méthode que nous appliquons pour reprendre une plateforme existante. Depuis, l’infrastructure a continué d’évoluer : extension et modernisation du cluster de virtualisation trois ans plus tard, avec des opérations menées à chaud, adoption d’un système d’exploitation immuable sur les nœuds Kubernetes pour réduire la surface d’attaque, et renforcement continu du monitoring et de l’observabilité.
Pour un client, cela se traduit par une chose simple : l’hébergement ne fait pas partie de son projet. Il n’a pas de serveur à dimensionner, pas de base à répliquer, pas d’astreinte à organiser, et il dispose d’une architecture documentée à présenter à ses propres équipes sécurité. Ses développeurs, quand il en a, travaillent sur les intégrations et l’expérience d’achat.
« Aujourd’hui on a une plateforme solide, qui évolue avec nous et avec nos clients. L’accompagnement d’Enix nous permet de rester focalisés sur ce qui compte vraiment, l’innovation produit, tout en ayant la certitude que l’infra suit le rythme. C’est exactement le partenariat qu’on cherchait. »
Vincent Pichon, cofondateur et CTO d’Origami Marketplace
Le détail de cette transformation est documenté dans le use case publié par Enix.
Si vous êtes en train de faire des recherches sur l’hébergement de votre future marketplace, la discussion la plus utile porte rarement sur les serveurs. Elle porte sur votre volume de catalogue, vos intégrations, vos contraintes de sécurité et votre trajectoire à deux ans. Parlons-en.
Vous avez des questions?
