Un acheteur commande une licence logicielle auprès d’un vendeur. Le paiement est confirmé, le service de livraison appelle deux fois l’API du fournisseur et deux codes sont consommés. L’email n’en contient qu’un. Trois jours plus tard, le client demande un remboursement ; le support annule la commande, mais aucun système ne sait si la licence a été activée ni comment retirer l’accès.
La douleur vient d’une confusion entre fichier, code, téléchargement et droit d’usage. Une réponse HTTP réussie ne prouve pas que le bon bénéficiaire dispose du bon périmètre. À l’inverse, un email perdu ne signifie pas que la livraison a échoué. Cette ambiguïté crée doubles attributions, litiges et fraude.
Le vrai enjeu d’une marketplace de biens numériques dans une marketplace opérateur est de créer un droit traçable, puis de piloter son accès jusqu’à expiration ou révocation. Contre-intuitivement, protéger davantage le fichier ne résout pas un contrat de licence mal modélisé.
Vous allez comprendre comment structurer les droits, figer la promesse, délivrer de façon idempotente, collecter les preuves et corriger remboursements ou transferts. Le dispositif relie entrées, sorties, owner, instrumentation, monitoring, dépendances, seuils, file, retry et rollback avant d’étendre cette verticale.
Définir ce qui est réellement vendu
Nommer la nature du droit
L’offre peut vendre propriété d’un fichier, licence personnelle, accès pendant une durée, nombre d’utilisations, crédit consommable ou abonnement. Ces modèles ne partagent ni la même livraison ni la même règle de remboursement. Le type devient un objet métier obligatoire.
Le contrat précise bénéficiaire, territoire, durée, appareils, transfert, mises à jour, usage commercial et conditions de révocation. Un libellé « téléchargement illimité » ne suffit pas s’il cache une licence limitée à un utilisateur.
Définir les sorties du parcours
La commande peut produire un entitlement actif, une attribution en attente, une activation requise, un échec récupérable ou un refus définitif. Chaque sortie possède prochaine action, délai, preuve et message acheteur.
Le vendeur ne voit jamais « livré » si seul le paiement est confirmé. L’acheteur ne voit pas « en préparation » pour une validation déjà disponible. Les statuts commerciaux se déduisent d’événements précis sans écraser les états techniques.
Le coût de l’erreur oriente la policy. Une double licence peut être irréversible chez un fournisseur ; un lien signé peut simplement expirer. Le système choisit donc retry automatique, revue ou remboursement selon le type de délivrance.
Séparer produit, licence et accès
Construire les objets canoniques
Le produit décrit l’œuvre ou le service. L’offre porte prix et conditions vendeur. La licence définit les droits vendus. L’entitlement relie bénéficiaire, licence et commande. L’accès matérialise un téléchargement, une clé, un compte externe ou une session.
Cette séparation permet plusieurs offres pour la même licence, plusieurs accès pour un même droit et une révocation sans supprimer l’historique de commande. Le support peut expliquer ce qui a été acheté, attribué et utilisé.
Conserver une machine à états
L’entitlement passe par PENDING, PROVISIONING, ACTIVE, SUSPENDED, EXPIRED ou REVOKED. Les transitions autorisées citent événement et acteur. Une réponse tardive du fournisseur ne réactive pas un droit déjà remboursé.
Chaque version conserve occurred_at, source_event_id, reason et policy_version. La vue courante est reconstruite depuis les événements. Une correction produit un événement compensatoire au lieu de réécrire le passé.
Structurer les droits dans le catalogue
Rendre les restrictions comparables
Durée, territoire, nombre d’utilisateurs, appareils, formats, résolution, usage commercial et mises à jour utilisent des attributs gouvernés. L’acheteur compare deux licences sur des faits, pas seulement sur leurs titres marketing.
Les unités sont normalisées : douze mois, trois appareils, dix téléchargements. « À vie » exige une définition de la durée du service ou de la version. Les valeurs inconnues bloquent publication lorsqu’elles déterminent la décision d’achat.
Vérifier le droit du vendeur
Le vendeur fournit preuve de distribution, territoires, produits couverts et date de validité. La marketplace conserve document, source et version. Une autorisation expirée déclenche une revue ciblée avant de nouvelles ventes.
Le catalogue distingue créateur, ayant droit, distributeur et revendeur. Une preuve valide pour un titre ne s’étend pas à toute une marque. Les retraits sont rattachés aux offres concernées et aux commandes ouvertes.
Les fichiers et métadonnées passent en quarantaine jusqu’aux contrôles techniques et éditoriaux. Une nouvelle version ne remplace pas immédiatement celle déjà vendue. Les entitlements historiques pointent vers le manifeste correspondant à leur commande.
Une campagne de retrait commence par le périmètre exact des licences encore vendables, des droits déjà attribués et des accès actifs. Le propriétaire décide si les acheteurs conservent l’usage, reçoivent un remplacement ou doivent être informés. Le catalogue ne supprime jamais la relation qui permettra ensuite au support de retrouver la population concernée.
Figer le contrat à la commande
Créer un snapshot opposable
La ligne de commande capture licence_version, prix, taxes, territoire, bénéficiaire, durée et règle de remboursement. Une modification d’offre postérieure n’altère pas le droit acquis. Le snapshot reste lisible par support et finance.
Le checkout valide compatibilité entre pays, compte, appareil éventuel et restrictions. Il ne provisionne pas avant le paiement ou l’événement contractuel défini. Une préautorisation peut réserver un code sans l’activer.
Distinguer acheteur et bénéficiaire
Une entreprise peut acheter pour un salarié, un parent offrir un jeu ou un revendeur distribuer des sièges. Le bénéficiaire possède une identité et un statut d’acceptation. Son email n’est pas la seule clé de l’entitlement.
Le changement de bénéficiaire avant activation suit une règle explicite. Après consommation, il peut être interdit ou nécessiter transfert. Le journal conserve l’auteur, la raison et les accès révoqués.
Les achats en volume ajoutent un délai entre paiement et attribution des sièges. La commande conserve alors une enveloppe non affectée et son administrateur. Chaque invitation consomme une unité de manière atomique ; une annulation ne rembourse que les unités encore disponibles selon les conditions figées au checkout.
Délivrer sans double attribution
Rendre le provisioning idempotent
Le service reçoit order_line_id, entitlement_id, beneficiary et idempotency_key. Il renvoie provider_reference, état et prochaine vérification. Un retry retourne la même attribution ou reprend l’étape incomplète sans consommer un second code.
La transaction locale écrit l’intention avant l’appel externe. Un outbox publie le travail, puis le callback est rapproché par référence. Si la réponse réseau est perdue, le worker interroge le fournisseur avant de retenter.
Les codes préalloués utilisent une réservation atomique. Leur stock distingue disponible, réservé, attribué, révoqué et expiré. Un code ne revient jamais en disponible après exposition à un utilisateur, même si la commande échoue.
Gérer fichiers et liens signés
Le fichier est stocké avec version, hash et contrôle antivirus. Le lien signé expire, limite éventuellement les usages et ne révèle pas le chemin interne. Régénérer un lien ne crée pas un nouveau droit.
Le CDN vérifie l’entitlement au moment de l’accès ou utilise un jeton court. La désactivation se propage avec un délai connu. Le monitoring détecte téléchargements anormaux, erreurs et contenus manquants.
Le plan de reprise tient compte des caches déjà distribués. Retirer l’asset d’origine ne suffit pas si un edge conserve la réponse ou si un lien signé reste valide. Le manifeste de révocation demande purge, vérifie les régions et conserve les échecs dans une file avant de déclarer le contenu inaccessible.
Prouver accès et consommation
Séparer délivrance et usage
Délivré signifie que l’accès est disponible au bénéficiaire. Consulté, téléchargé, activé et consommé sont des événements différents. Une notification email envoyée ne prouve ni la délivrance ni l’usage.
La preuve conserve moment, entitlement_id, accès, résultat et source. Les données techniques sont minimisées. Une adresse IP seule ne suffit pas à attribuer une action à une personne, surtout dans un réseau d’entreprise.
Construire un dossier de contestation
Le dossier réunit commande, licence, paiement, provisioning, notifications, accès et échanges. Il distingue faits confirmés et hypothèses. Support peut produire une chronologie sans collecter des captures depuis cinq outils.
Par exemple, un lien créé à 10 h, ouvert à 10 h 05 et un fichier entièrement servi montrent un accès, mais pas nécessairement l’exploitation du contenu. La décision applique le contrat et les règles pertinentes sans surinterpréter la télémétrie.
Protéger fichiers, codes et comptes
Contrôler la chaîne de fourniture
Les imports passent par quarantaine, scan, décompression bornée et validation de type. Les archives imbriquées, exécutables inattendus et macros sont refusés ou escaladés. Le hash relie asset vendeur, version publiée et téléchargement.
Les accès internes suivent le privilège minimal. Un modérateur peut consulter métadonnées sans télécharger le fichier complet. Les opérations sensibles sont auditées, et les secrets fournisseur restent dans un coffre avec rotation.
Limiter partage et extraction
Les contrôles peuvent combiner liens courts, appareil, watermark ou limitation d’usage selon le produit. Ils ne rendent jamais la copie impossible et ne doivent pas casser l’accès légitime. La policy mesure réduction du risque et friction.
Une hausse de téléchargements, plusieurs pays en quelques minutes ou un code activé sur trop d’appareils déclenche une revue. Le système suspend le mode d’accès concerné plutôt que le compte entier lorsque la portée le permet.
Rembourser et révoquer proprement
Décider avec l’état du droit
La règle considère provisioning, activation, consommation, délai et motif. Un fichier jamais accessible, une clé invalide et un contenu déjà consommé ne suivent pas le même parcours. Le résultat peut être remboursement, remplacement, avoir, refus ou revue.
Le moteur ne prend pas de décision juridique autonome. Il applique la policy validée au pays et au contrat, puis escalade les situations non couvertes. Le motif visible reste précis et proportionné.
Orchestrer compensation et révocation
Le remboursement crée une intention de révocation avec la même référence de dossier. Le fournisseur accuse retrait ou indique impossibilité. Finance ne considère pas le parcours fini tant que paiement, entitlement et commission ne sont pas réconciliés.
Si la révocation externe échoue, alors le droit passe SUSPENDED localement et rejoint une file prioritaire. Le retry est idempotent. Une compensation financière ne réactive pas le droit en cas de callback tardif.
Le rollback d’une décision erronée recrée un entitlement depuis le snapshot initial, mais pas forcément la même clé déjà invalidée. L’acheteur reçoit un nouvel accès et la chronologie relie les deux attributions.
Gérer partage, transfert et appareils
Modéliser les sièges et délégations
Une licence multi-utilisateur possède un pool de sièges et des attributions. L’administrateur peut inviter, retirer et réaffecter selon contrat. L’usage d’un siège ne consomme pas automatiquement le droit de transfert.
Les invitations expirent et ne livrent aucun contenu avant acceptation. Le nombre attribué est contrôlé atomiquement. Une suppression d’utilisateur libère ou non le siège selon la licence, avec trace et délai.
Révoquer un appareil sans annuler le droit
Appareil, session et entitlement sont distincts. Perdre un téléphone retire son token et libère éventuellement un emplacement, sans rembourser la commande. Un nouvel appareil suit authentification et limite de fréquence.
Les transferts inhabituels déclenchent une revue. En revanche, un renouvellement matériel légitime ne doit pas devenir un ticket manuel. Le portail explique appareils actifs, dernière utilisation et action possible.
Versionner mises à jour et abonnements
Distinguer version acquise et version courante
Le manifeste relie chaque entitlement aux versions incluses. Une mise à jour corrective peut remplacer un asset, tandis qu’une version majeure exige un nouveau droit. Le catalogue annonce la politique avant achat.
Le retrait d’un fichier compromis conserve une page d’information et propose une version saine. Les anciens liens cessent de servir l’asset vulnérable. Le hash et les accès concernés permettent une notification ciblée.
Gérer renouvellement et grâce
Un abonnement porte période, renouvellement, échec de paiement, grâce et fin de service. La grâce maintient ou réduit les capacités selon promesse. Elle ne change pas la date contractuelle sans événement explicite.
Un paiement tardif réactive le même entitlement avec une nouvelle période. Les événements hors ordre sont comparés à billing_cycle_version. Une résiliation future n’est pas annulée par un callback ancien.
Piloter qualité et support
Mesurer tout le funnel de délivrance
Le tableau suit paiement à entitlement, provisioning, délai d’accès, activation, erreurs, retry, remboursement, révocation et support. Il segmente vendeur, type de droit, fournisseur et version pour isoler la cause.
Le taux « livré » ne suffit pas. Un p95 de dix minutes, 3 % de doubles tentatives ou beaucoup de liens régénérés révèlent une expérience fragile. Le coût inclut codes perdus, support et commissions corrigées.
Outiller la reprise
Le back-office montre commande, entitlement, accès, fournisseur, preuves et actions sûres. Support peut renvoyer une notification ou régénérer un lien, mais pas inventer une licence ni modifier l’historique.
Le monitoring alerte sur files, callbacks, stock de codes, signatures, assets et révocations. Chaque seuil possède owner et runbook. Un mode dégradé conserve les commandes en attente plutôt que de promettre une livraison non vérifiable.
La revue hebdomadaire prélève les dossiers les plus anciens, les doubles tentatives et les droits remboursés encore actifs. Elle compare la cause, le temps de reprise et le fournisseur concerné. Une anomalie répétée ouvre une correction produit ou contractuelle ; elle ne devient pas une consigne permanente donnée au support.
Adapter la méthode et éviter les erreurs
Pour qui cette architecture de droits convient
Elle concerne logiciels, médias, jeux, documents, crédits et abonnements dès qu’un remboursement ou un transfert doit agir au-delà de l’email. Une petite marketplace commence avec un type de droit et une seule méthode d’accès.
Catalogue possède la licence, Orders le snapshot, Fulfillment l’attribution, Security les accès, Finance la compensation et Support la reprise. Chaque fournisseur conserve un owner et un contrat de réversibilité.
Erreurs fréquentes des biens numériques
Confondre email et livraison, réutiliser un code après exposition, retry sans idempotence, supprimer l’entitlement au remboursement et laisser l’offre définir seule les droits sont les erreurs majeures.
Une autre erreur consiste à mesurer uniquement les téléchargements. Enfin, croire qu’un DRM remplace la gouvernance des licences rend remboursements et support impossibles. Le droit demeure l’objet central.
Plan d’action pour lancer les biens numériques
Semaines 1 à 4 : contrat et objets
La première semaine choisit un type de licence et ferme ses attributs. La deuxième modélise entitlement, accès et états. La troisième branche paiement et snapshot. La quatrième construit provisioning idempotent et preuves.
Les tests couvrent double callback, réponse perdue, code épuisé, fichier absent, bénéficiaire différent, lien expiré, activation, remboursement et révocation. Chaque scénario attend état, message, trace et compensation.
Semaines 5 à 8 : exploitation et pilote
La cinquième semaine outille support et files. La sixième ajoute sécurité et monitoring. La septième exécute canary avec quelques vendeurs ; la huitième provoque retry, fournisseur indisponible, réconciliation et rollback.
Les entrées sont offres, licences, commandes et bénéficiaires ; les sorties sont droits, accès, preuves et anomalies. L’instrumentation suit latence, erreurs, consommations et révocations. Le runbook nomme owners et dépendances.
Le go exige zéro double attribution, livraison reconstituable, remboursement réconcilié et révocation testée. Une personne extérieure au projet doit reprendre une réponse perdue, régénérer un accès et fermer un code compromis.
Si le p95 de délivrance dépasse cinq minutes ou si plus de 2 % des commandes demandent une action support, alors l’extension attend. L’équipe corrige fournisseur, statut ou message avant d’ajouter un nouveau type de licence.
- À faire d’abord : fermer licence, entitlement, snapshot et preuve de délivrance.
- À tester ensuite : idempotence, consommation, remboursement, révocation et reprise.
- À différer : partage complexe tant que le droit individuel reste fragile.
- À refuser : toute livraison sans référence, état final et chemin de compensation.
Ressources complémentaires opérateur
Borner le premier périmètre
Le MVP marketplace avant ouverture aide à retenir un premier type de droit exploitable.
La méthode pour ouvrir une première catégorie relie densité d’offre et capacité support.
Structurer catalogue et reprise
Le catalogue PIM marketplace gouverne licences, versions et preuves vendeur.
Les écrans du back-office opérateur réunissent commande, droit, accès et correction.
Conclusion : gouverner le droit au-delà du fichier
Une marketplace numérique fiable distingue licence, entitlement et accès avant d’automatiser sa livraison.
Snapshot, idempotence et preuves empêchent qu’un retry, un email ou un code devienne une vérité commerciale fragile.
Révocation, compensation, monitoring et reprise rendent le droit gouvernable pendant toute sa durée de vie. Cette continuité permet aussi d’expliquer chaque décision à l’acheteur, au vendeur et aux opérations sans reconstituer le dossier depuis plusieurs outils.
Dawap peut vous accompagner pour bâtir une verticale de biens numériques avec droits, délivrance et révocation traçables dans votre marketplace opérateur.
