Création marketplace

Sharetribe : combien coûtent les images de votre catalogue ?

Jérémy Chomel Dawap
  • Publié le : 24 octobre 2026
  • Temps de lecture : 19 minutes
  1. Dans quel cas examiner les images avant le nombre de ventes
  2. Séparer l’annonce d’octobre du tarif applicable à votre compte
  3. Comprendre les trois compteurs d’une image livrée
  4. Exemple concret : deux catalogues, le même volume de ventes
  5. Appliquer le million inclus une seule fois
  6. Exécuter la simulation et éprouver ses limites
  7. Rapprocher le modèle de Console sans inventer les données manquantes
  8. Réduire les demandes inutiles en préservant l’expérience acheteur
  9. Erreurs fréquentes dans le budget d’usage
  10. Plan d’action : mesurer, corriger, puis décider du budget
  11. Guides complémentaires pour élargir la décision
  12. Conclusion : donner un prix au parcours réellement utilisé
Portrait de Jérémy Chomel

Votre marketplace vend autant qu’avant, mais son budget technique augmente après une refonte du catalogue et réduit votre marge. Les équipes cherchent une hausse des commandes, des vendeurs ou des commissions. Le changement peut pourtant se trouver dans les images : davantage de photos demandées, plusieurs formats chargés inutilement et des pages qui parcourent une grande partie de l’inventaire sans produire une vente supplémentaire.

La nouvelle tarification Sharetribe annoncée en octobre 2026 rend cette question particulièrement concrète. En pratique, il faut distinguer trois quantités : les images sources demandées pendant le mois, les requêtes de livraison et les octets transférés. Le nombre de commandes ne permet de reconstituer aucune de ces trois mesures. Une galerie peu consultée peut peser dans l’usage si son contenu est chargé à l’avance.

Nous allons construire une simulation de catalogue, vérifier les unités et rapprocher le résultat du relevé fournisseur. Les chiffres sont fictifs ; ils ne constituent ni une facture Sharetribe, ni un résultat client Dawap. La méthode sert à choisir un essai mesurable avant de changer le chargement des photos, de souscrire un engagement ou de remettre en cause toute la plateforme.

Ce travail appartient au cadrage d’une marketplace opérateur conçue avec Dawap. Il prolonge l’analyse du business model et des coûts d’exploitation en reliant une décision d’interface à une consommation vérifiable, sans confondre économie technique et rentabilité commerciale.

Dans quel cas examiner les images avant le nombre de ventes

Un catalogue riche dont les coûts ne suivent pas les commandes

Cette analyse concerne surtout les opérateurs disposant de nombreuses annonces illustrées : location de matériel, objets d’occasion, services avec portfolios ou catalogue professionnel. Le signal utile est une divergence. Les ventes restent stables alors qu’une livraison d’interface, un changement de galerie ou une importation de visuels précède la hausse des crédits. Cette proximité temporelle justifie une investigation, sans suffire à établir une cause.

Commencez par comparer un périmètre constant. Un mois de campagne publicitaire ne se compare pas directement à un mois calme. Une nouvelle catégorie peut attirer beaucoup de visiteurs avant ses premières ventes. Le pilotage du GMV au-delà du volume complète cette lecture : la consommation technique doit être rapprochée de l’activité utile, sans faire du chiffre d’affaires son unique explication.

Un diagnostic ciblé, sans conclusion prématurée sur le fournisseur

Si le relevé attribue l’essentiel de la consommation à des écritures, à des recherches ou à un traitement de fond, réduire les photos sera secondaire. Inversement, un stockage volumineux ne démontre pas une forte consommation de livraison. Il faut observer ce qui est effectivement demandé au service, puis comprendre quel parcours le déclenche et quelle valeur ce parcours apporte aux acheteurs.

Ne décidez pas de migrer à partir d’une seule ligne de facture. Le coût d’une correction locale, les frais de migration et la qualité de service doivent rester comparables. L’analyse du coût total d’un marketplace maker traite cette décision plus large ; le présent calcul isole uniquement la composante images d’un modèle d’usage identifié.

Séparer l’annonce d’octobre du tarif applicable à votre compte

Une transition à dater avant de recalculer un budget

L’historique tarifaire officiel de Sharetribe annonce en octobre 2026 le passage d’un comptage lié aux transactions à une tarification fondée sur l’usage. La documentation technique de ce modèle, consultée le 24 octobre, indique une entrée en vigueur au 1er décembre 2026 pour les clients existants. Une annonce ne prouve donc pas que votre facture d’octobre utilise déjà ces règles.

Conservez, dans le dossier de décision, la date de consultation, la formule du compte, la date d’application communiquée et le mois simulé. Nos scénarios portent sur décembre 2026 avec le barème disponible le 24 octobre. Avant une décision réelle, vérifiez dans votre abonnement les conditions effectivement applicables. Un compte hérité, une offre particulière ou une période d’essai ne doit pas être assimilé silencieusement au scénario standard.

Un abonnement et une consommation à lire séparément

La page des tarifs affiche Live à 259 dollars par mois avec paiement mensuel, ou un équivalent de 199 dollars mensuels facturé annuellement. Les montants sont en dollars américains, hors TVA. Notre exemple utilise l’option mensuelle à 259 dollars, sans engagement de crédits. Il ne convertit pas cette dépense en euros.

L’abonnement n’épuise pas le budget du projet. Les services de paiement, les prestations de développement et les autres outils éventuels se suivent à part. Un total « abonnement plus usage » est une sous-partie explicite du coût complet. Le présenter comme le coût de fonctionnement intégral masquerait précisément les postes que l’opérateur doit encore financer.

Comprendre les trois compteurs d’une image livrée

Une image source peut produire plusieurs requêtes

La référence officielle des crédits API distingue la livraison CDN, facturée à 1,5 crédit par requête et à 10 000 crédits par GB livré, du premier appel d’une image sur un mois civil, qui ajoute 340 crédits. Les variantes de taille ou de format ne créent pas une nouvelle charge d’image unique pour cette même image pendant le mois.

Pour le suivi local, attribuez donc une identité à la photo source, puis rattachez ses formats à cette identité. Une miniature et une grande image ne sont pas deux photos différentes lorsqu’elles dérivent de la même source. À l’inverse, deux fichiers réimportés comme deux images distinctes ne doivent pas être fusionnés sur la seule ressemblance de leur nom. La correspondance doit être démontrée par les identifiants disponibles.

Le transfert ne se déduit pas du poids affiché dans le catalogue

La documentation de tarification définit ici un GB comme 2³⁰ octets. Pour éviter l’ambiguïté, nous écrivons GiB dans les calculs : 1 GiB vaut 1 073 741 824 octets. Les octets de plusieurs livraisons s’additionnent. Réutiliser une photo déjà demandée peut éviter une nouvelle charge d’unicité sans rendre ses nouvelles livraisons gratuites.

Notre simulation retient uniquement des livraisons réussies. Elle ne généralise pas leur facturation aux erreurs ou aux revalidations. Une requête d’image observée dans le navigateur ne doit pas non plus être assimilée automatiquement à une nouvelle livraison CDN : un cache peut intervenir. Les trois compteurs doivent provenir d’observations compatibles avec le périmètre de facturation, et non d’un simple décompte des balises présentes sur la page.

Exemple concret : deux catalogues, le même volume de ventes

Fixer les hypothèses avant de comparer les interfaces

Imaginons une marketplace disposant de 5 000 photos sources. Elle réalise 200 ventes et 10 000 dollars de GMV sur le mois étudié. Dans le scénario A, un parcours charge trop largement le catalogue : toutes les photos sont demandées. Dans le scénario B, seules 1 000 photos le sont. Chaque photo demandée reçoit six livraisons réussies, réparties sur trois variantes. Ces observations sont entièrement fabriquées pour rendre le calcul reproductible.

Nous fixons les transferts totaux à 15 GiB dans A et 3 GiB dans B. Les autres usages représentent 650 000 crédits dans chaque scénario, sans inclure les livraisons d’images déjà comptées. Ce poste agrégé est fourni comme hypothèse ; il n’est pas reconstruit à partir des 200 ventes. Les uploads, les autres appels et les actions d’administration ne sont donc pas déclarés gratuits.

Simulation mensuelle fictive : consommation d’images et autres usages.
MesureA : largeB : ciblé
Photos demandées5 0001 000
Livraisons CDN30 0006 000
Transfert15 GiB3 GiB
Crédits images1 895 000379 000
Autres crédits650 000650 000
Crédits totaux2 545 0001 029 000
Usage, en USD108,152,03

Lire la baisse sans lui attribuer un effet commercial inventé

Dans A, les images uniques représentent 1 700 000 crédits, les requêtes 45 000 et le transfert 150 000. Leur somme atteint 1 895 000. Dans B, les trois composantes valent respectivement 340 000, 9 000 et 30 000, soit 379 000. La différence ne vient ni d’un taux de commission modifié ni d’une réduction du nombre de commandes.

Le scénario B suppose que l’on peut éviter certaines demandes sans perdre de ventes. Cela reste une hypothèse à tester dans une vraie interface. Si les photos supplémentaires aident les visiteurs à qualifier les annonces, les retirer peut réduire les crédits et détériorer la conversion. La simulation prouve l’arithmétique du modèle, pas la pertinence commerciale d’une galerie allégée.

Appliquer le million inclus une seule fois

Calculer le supplément sur l’ensemble du périmètre

Le fonctionnement officiel des frais d’usage prévoit un million de crédits inclus, puis une tarification par tranches. Entre un et trois millions, le tarif est de 0,07 dollar pour mille crédits. Notre simulation reste entièrement dans cette tranche : il n’est donc pas nécessaire d’appliquer les suivantes.

Pour A, le dépassement est de 1 545 000 crédits : 1 545 × 0,07 = 108,15 dollars. Pour B, il est de 29 000 crédits : 29 × 0,07 = 2,03 dollars. L’écart vaut 106,12 dollars. L’abonnement mensuel retenu donne respectivement 367,15 et 261,03 dollars hors TVA pour « Live plus usage », avant les autres dépenses du projet.

Ne pas distribuer plusieurs fois les crédits inclus

Déduire un million des images, puis encore un million des autres opérations, produirait deux franchises inexistantes dans ce calcul. Préparez d’abord un périmètre de consommation complet, appliquez ensuite l’inclusion correspondante. Le centre d’aide précise que l’usage couvre aussi les environnements Test et Dev, ainsi que Live : observer seulement le trafic public peut laisser un écart inexpliqué.

Un seuil interne de revue à 900 000 crédits cumulés peut aider une petite équipe à préparer le dépassement ; ce n’est pas une limite fournisseur ni un mécanisme de coupure. Le franchissement de trois millions exige un autre calcul, avec les tranches suivantes. Le programme fourni refuse ce dépassement plutôt que de prolonger le premier tarif et de produire une estimation faussement précise.

Exécuter la simulation et éprouver ses limites

Un programme téléchargeable, sans connexion au compte

Le programme Python de calcul des crédits images utilise uniquement la bibliothèque standard. Il génère les livraisons fictives, calcule les trois composantes puis les frais du sous-périmètre. Téléchargez-le et exécutez la commande ci-dessous. Aucune clé, aucun appel API et aucun export client ne sont nécessaires.

python3 credits_images_sharetribe.py
# A : 2 545 000 crédits ; usage 108,15 USD
# B : 1 029 000 crédits ; usage   2,03 USD
# Différence : 106,12 USD
# 49 contrôles : PASS

Les entrées décrivent chaque observation par un identifiant de requête, un mois, une image source, une variante, un nombre d’octets et un statut de réussite. La sortie rend les totaux par mois. Le contrat refuse une identité vide, des octets négatifs ou non entiers, une période inconnue et un barème différent. Ces contrôles organisent la traçabilité locale ; ils ne prétendent pas reproduire le système de facturation de Sharetribe.

Trois raccourcis qui échouent sur les mêmes données

Compter les trois variantes comme trois images sources donne à tort 5 295 000 crédits images pour A. Oublier la composante d’unicité donne seulement 195 000. Enfin, diviser les octets par un milliard au lieu de 2³⁰ donne 161 061,2736 crédits de transfert au lieu de 150 000. Ces témoins volontairement incorrects montrent pourquoi un total plausible ne suffit pas à valider la formule.

Les 49 contrôles couvrent également six permutations d’un petit jeu, l’ordre inversé du grand scénario et le réimport exact des mêmes observations. Deux lignes contradictoires portant la même identité sont refusées. Une nouvelle requête réelle doit avoir sa propre identité et rester comptée : l’idempotence de l’import ne doit pas effacer les consultations répétées des acheteurs.

Rapprocher le modèle de Console sans inventer les données manquantes

Partir du relevé fournisseur avant de détailler les parcours

La documentation technique indique que Console permet de suivre la consommation et de télécharger un CSV mensuel agrégé par endpoint. Cet export constitue un point de rapprochement ; nous ne lui attribuons pas un détail par image ou par visiteur que la documentation ne garantit pas. Conservez le fichier original et la période, puis construisez une copie de travail avec des catégories explicites.

Un contrat de rapprochement utile prend en entrée cet export, le total Console et les observations disponibles sur les parcours. La finance vérifie la période et la formule ; l’équipe technique qualifie les compteurs ; le produit explique les changements d’interface. La sortie doit montrer les montants rapprochés, les postes absents et un écart résiduel attribué à un responsable. Un total forcé à correspondre détruit la valeur du contrôle.

Ne pas fabriquer une précision par vendeur

Si les données ne permettent pas d’associer les images uniques à leurs vendeurs, indiquez cette limite. Une répartition proportionnelle au GMV serait une convention de gestion, pas une mesure technique. Elle pourrait pénaliser un vendeur performant alors qu’un autre catalogue, peu vendu mais abondamment préchargé, déclenche davantage d’usage. Toute refacturation éventuelle nécessite une règle distincte, explicable et validée.

Autre scénario : le suivi local couvre 1,8 million de crédits et Console en affiche 2,1 millions. N’insérez pas automatiquement 300 000 crédits dans la catégorie images. Cherchez d’abord une différence de période, un environnement oublié, un traitement d’administration ou un périmètre incomplet. Tant que l’écart reste sans cause, l’estimation sert à orienter l’enquête ; elle ne permet pas d’annoncer une économie contractuelle.

Réduire les demandes inutiles en préservant l’expérience acheteur

Tester un parcours avant de modifier tout le catalogue

Repérez une page où des photos sont demandées alors que l’acheteur ne les voit pas encore et ne les consulte presque jamais. Préparez une variante qui diffère ces demandes. Gardez accessibles les photos nécessaires à la comparaison et à la décision d’achat. La modification doit supprimer un chargement sans utilité observée tout en conservant un catalogue complet et réactif.

La recette vérifie le premier écran, l’ouverture de la galerie, le retour à la liste et les formats mobiles. Comparez les requêtes réellement délivrées, le temps d’affichage utile et les abandons du parcours. Pour les arbitrages de cache et de traitement différé, le dossier sur les jobs, caches et recherches d’une marketplace scalable donne un cadre plus large, sans remplacer cette mesure ciblée.

Ne pas confondre réduction des octets et réduction des images uniques

Contrairement à ce que suggère le poids des fichiers, une forte compression peut laisser intact le principal poste de consommation : les photos sources demandées. Elle réduit le transfert, sans réduire leur nombre. Dans A, même un transfert ramené à zéro laisserait théoriquement 1 745 000 crédits liés aux images uniques et aux requêtes. Ce calcul limite l’économie maximale de la seule composante transfert ; il ne décrit évidemment pas une livraison réelle sans données. Choisir la bonne action demande de connaître le poste dominant.

Deux signaux faibles méritent une revue : un déploiement qui multiplie les formats chargés sans augmenter les photos sources, et une hausse mensuelle des photos uniques alors que le catalogue publié ne grandit pas. Le premier oriente vers les demandes de variantes ; le second vers l’exposition de nouvelles photos ou un changement d’identité. Documentez la cause avant de conclure à un problème de poids des fichiers.

Erreurs fréquentes dans le budget d’usage

Comparer des périodes et des identités incompatibles

Une photo déjà demandée en décembre peut déclencher à nouveau la composante d’unicité en janvier. Un cumul depuis le lancement ne convient donc pas à une mesure mensuelle. Le programme vérifie explicitement le passage entre ces deux mois. Il ne choisit pas lui-même le fuseau de facturation : les observations doivent être rattachées à la période retenue dans le relevé fournisseur avant leur import.

Le nom du fichier n’est pas non plus une identité fiable. Deux vendeurs peuvent utiliser « produit.jpg » pour deux photos différentes. À l’inverse, plusieurs URL de variantes peuvent désigner la même source. Si cette correspondance est incertaine, conservez un groupe « identité à vérifier » et différez le calcul fin. Une estimation incomplète signalée vaut mieux qu’un regroupement arbitraire présenté comme exact.

S’engager pour absorber un pic qui disparaîtra

La documentation des engagements de crédits Sharetribe décrit un minimum mensuel sur douze mois. Le montant reste dû lorsque la consommation est inférieure ; les crédits inutilisés ne sont ni reportés ni remboursés. Une remise unitaire ne suffit donc pas à justifier cet engagement après un seul mois de préchargement excessif.

Dans nos deux scénarios, les frais d’usage ordinaires restent inférieurs aux 249 dollars mensuels du premier engagement affiché, couvrant dix millions de crédits. Cet engagement n’est pas retenu dans la simulation. Pour un compte plus volumineux, construisez une trajectoire mensuelle incluant les périodes basses et les corrections prévues. Une optimisation imminente peut changer la décision ; un pic saisonnier ne prouve pas un besoin permanent.

Plan d’action : mesurer, corriger, puis décider du budget

Préparer un essai dont l’équipe peut expliquer le résultat

Commencez par figer une période de référence et collecter les pièces qui existent réellement : formule du compte, relevé de consommation et version déployée de l’interface. La responsabilité de chaque pièce doit être claire. Un développeur ne peut pas confirmer seul la date d’application commerciale ; la finance ne peut pas déduire seule quelles images une galerie demande en arrière-plan. Ce premier passage produit un périmètre commun, avec les informations encore absentes et leur prochaine date de collecte.

Choisissez ensuite une seule modification mesurable. Par exemple, différer les images d’une galerie secondaire tout en conservant le premier visuel visible immédiatement. Définissez avant l’essai le seuil qui suspendra la modification : une image manquante sur un parcours critique doit suffire à déclencher le repli, même si les crédits baissent. Pour les indicateurs de conversion, prévoyez une durée et un volume d’observations adaptés au trafic réel ; quelques commandes ne permettent pas de conclure que l’expérience reste équivalente.

Transformer les résultats en décision réversible

À la fin de l’essai, distinguez trois résultats : la baisse technique observée, son effet tarifaire calculé et son effet commercial encore mesuré ou inconnu. Une réduction de 20 % des octets ne devient pas automatiquement une baisse de 20 % de la facture. Les inclusions, les autres composantes et les tranches interviennent. Si les données restent partielles, poursuivez la mesure sur le même parcours plutôt que d’étendre immédiatement la modification à tous les vendeurs et à toutes les catégories.

Enfin, chiffrez le travail nécessaire pour conserver l’amélioration. Si une adaptation fictive coûte 900 dollars et économise durablement 106,12 dollars par mois, son retour simple approche 8,5 mois, hors maintenance et effets commerciaux. Si l’économie n’est observée que pendant trois mois de forte activité, elle atteint seulement 318,36 dollars sur cette période. Ces hypothèses changent l’arbitrage. Le dossier de décision doit permettre au prochain responsable de retrouver le calcul, les observations, le seuil de repli et la raison de conserver ou d’abandonner la modification.

  • Si la date d’application du tarif est inconnue, différer l’engagement et faire confirmer la période concernée.
  • Si les crédits sont dominés par les images uniques, tester d’abord les photos demandées inutilement plutôt que la seule compression.
  • Si le rapprochement conserve un écart inexpliqué, poursuivre la collecte avant d’annoncer une économie.
  • Si l’essai masque une information nécessaire à l’achat, rétablir le parcours puis revoir la solution avec le produit.

Guides complémentaires pour élargir la décision

Le diagnostic des crédits images ne couvre ni l’ensemble des dépenses du maker ni les opérations humaines nécessaires au catalogue. Deux lectures prolongent le travail lorsque la consommation a été expliquée et que l’opérateur doit décider où investir.

Remettre l’optimisation dans le coût complet du socle

Le dossier sur le TCO d’un marketplace maker aide à comparer licence, adaptations, support et éventuelle sortie. Il permet de conserver une amélioration utile sans transformer une anomalie ponctuelle d’interface en argument automatique pour une refonte générale.

Préparez pour cette discussion le coût constaté, le coût de correction et les contraintes restantes. Le débat porte alors sur des options comparables : garder le standard, adapter un parcours ou changer un périmètre plus large. Le relevé d’usage fournit une pièce de cette décision, pas sa conclusion à lui seul.

Éviter de déplacer le coût vers les équipes support

Une galerie qui charge moins peut susciter plus de demandes d’aide si les acheteurs ne trouvent plus les détails nécessaires. Le diagnostic des tickets Zendesk fusionnés et du coût support marketplace aide à garder une mesure lisible de ce travail, même lorsque plusieurs demandes sont regroupées.

Rapprochez les motifs d’aide du parcours modifié. Une économie technique accompagnée de davantage d’interventions manuelles peut rester intéressante, mais elle doit être chiffrée comme telle. Ce suivi protège une décision simple : conserver les photos et les informations qui évitent un effort répétitif aux acheteurs comme aux équipes opérateur.

Conclusion : donner un prix au parcours réellement utilisé

Le budget d’images se comprend en distinguant les photos sources demandées, les livraisons et les octets. Le cas étudié garde les mêmes ventes mais produit deux consommations différentes. Il montre où chercher une dérive et comment éprouver un calcul, sans prétendre que toute réduction de photos améliorerait la rentabilité.

La prochaine étape utile est de rapprocher un mois d’usage, une version d’interface et un essai limité. La date d’application du tarif, les données manquantes et les conséquences sur l’achat restent visibles. C’est à cette condition que les économies envisagées peuvent devenir une décision défendable plutôt qu’un montant séduisant dans un tableau.

Le cadrage du budget et de la rentabilité de votre plateforme permet d’intégrer ce poste aux autres dépenses, avec des scénarios saisonniers et des hypothèses que les équipes pourront réviser.

Dawap vous accompagne dans la création et l’évolution de votre marketplace pour relier les choix de catalogue, les interfaces et les intégrations aux conditions concrètes d’exploitation. Cet accompagnement vise un parcours utile aux acheteurs, dont les coûts et les responsabilités restent compréhensibles après la mise en service.

Portrait de Jérémy Chomel

Relier expérience catalogue et coûts d’exploitation

Dawap accompagne les opérateurs pour relier le catalogue, les parcours d’achat et les intégrations à un budget mesurable, avec des essais avant chaque décision.

Articles recommandés

Marketplace maker : calculer le coût total de possession au-delà du setup initial Création marketplace opérateur Marketplace maker : prévoir le coût complet Lire l'article
  • 26 février 2025
  • Lecture ~15 minutes

Un maker paraît abordable tant que le comité ne chiffre que la licence. Le vrai coût apparaît ensuite dans les connecteurs, le support, les reprises, la dette de workflow et la sortie. Cet article montre comment lire le TCO sur 24 mois, fixer les seuils de dérive et comparer un maker, un hybride ou un socle plus maîtrisé.

Illustration des filtres de recherche conservant le prix et le stock de la même offre marketplace Création marketplace Filtres : le prix et le stock de la même offre Lire l'article
  • 24 octobre 2026
  • Lecture ~18 minutes

Un produit apparaît à 80 euros alors que seule l’offre à 120 euros est disponible. Quatre produits fictifs montrent comment des filtres indépendants inventent une promesse. Le dossier relie sélection Elasticsearch, prix trié, offre affichée et compteurs, avec une recette locale et les contrôles à rejouer sur le moteur réel.

GMV marketplace volume rentabilité dashboard opérateur Création marketplace opérateur GMV marketplace : piloter au-delà du volume Lire l'article
  • 27 juin 2026
  • Lecture ~16 min

Pilotez le GMV marketplace sans confondre volume et santé réelle : marge nette, take rate, vendeurs, catégories, stock, disponibilité, coûts support, cohortes et dashboard opérateur. Le bon reporting doit dire quoi accélérer, corriger ou ralentir pour protéger la rentabilité, le stock et la confiance.

Durées des tickets source et destination rapprochées avant classement des coûts par catégorie Création de marketplace Tickets fusionnés : où passent les minutes du support ? Lire l'article
  • 9 octobre 2026
  • Lecture ~15 min

Deux tickets sont regroupés, mais le rapport ne reprend plus toutes les minutes observées. Douze témoins locaux séparent durées additionnelles, cumuls, doublons et affectations inconnues. Le diagnostic explique le classement des catégories avant de choisir une correction produit, sans transformer une amélioration de mesure en économie déjà réalisée.

Construire une marketplace dont les coûts restent explicables

Dawap accompagne les opérateurs pour relier le catalogue, les parcours d’achat et les intégrations à un budget mesurable, avec des essais avant chaque décision.