Summary

  • AWS Marketplace déduplique les relevés SaaS selon le produit, le client, l’heure et la dimension tarifaire dans l’ancien modèle ; avec les accords simultanés, la licence remplace le produit dans cette clé.
  • AWS dit qu’envoyer l’usage d’un même client et d’une même heure une fois avec ProductCode, puis avec LicenseArn, entraîne une double facturation. L’essai de migration doit porter sur les relevés réels envoyés, pas seulement sur l’activation du nouveau connecteur.

Le logiciel tourne une heure. Combien d’heures le vendeur envoie-t-il à la caisse ?

Dans AWS Marketplace, le fournisseur de SaaS mesure l’usage et transmet des relevés. AWS calcule ensuite la facture du client à partir de ces quantités et des prix du produit. Pour un produit sans accords simultanés, le dédoublonnage s’appuie sur le produit, le client, l’heure et la dimension facturée. Avec les accords simultanés, un même client peut acheter plusieurs accords pour le même produit. Chaque accord possède alors son LicenseArn, et le dédoublonnage se fait par licence.

Le changement paraît administratif jusqu’à ce que deux expéditeurs travaillent en même temps. Le guide d’AWS précise qu’une répétition sous le même LicenseArn suit les règles ordinaires de dédoublonnage. En revanche, l’envoi sous ProductCode puis sous LicenseArn pour la même période d’usage provoque une double facturation. La plateforme reconnaît deux identités distinctes ; l’entreprise, elle, n’a consommé qu’une fois.

Depuis le 1er juin 2026, les nouveaux produits SaaS doivent prendre en charge la nouvelle intégration des accords simultanés. Les intégrations existantes peuvent continuer à fonctionner. La date ne transforme donc pas automatiquement toutes les anciennes installations. Elle rend en revanche très concrète la question pour celles qui migrent : qui ferme le compteur du produit, à quelle heure, et qui autorise le compteur de la licence à prendre le relais ?

AWS demande aux nouvelles intégrations d’identifier le client par CustomerAWSAccountId et l’accord par LicenseArn. Ce dernier provient de l’appel ResolveCustomer lors de l’inscription. Dans les relevés fondés sur la licence, AWS demande de ne pas mettre ProductCode au niveau de la requête. L’accord concerné doit figurer dans chaque UsageRecord. C’est essentiel lorsqu’un client possède deux accords actifs : le nom du produit ne suffit plus à attribuer l’usage.

Une quantité déjà déclarée, même nulle, ne peut pas être modifiée selon le guide. Si une nouvelle tentative indique une quantité différente pour la même clé de relevé, la quantité initiale reste facturée. Le vendeur doit donc conserver un registre des heures, des dimensions et des accords, puis vérifier quel processus a émis chaque ligne. Une simple capture d’écran du nouveau paramétrage ne dit rien de l’ancien processus qui envoie encore.

Le client voit les dimensions et les totaux dans la console de facturation AWS ; le rapport de coûts et d’usage peut donner davantage de détail lorsqu’il est activé. Ces vues n’arrivent pas en temps réel. Du côté du vendeur, AWS cite CloudTrail pour vérifier les appels d’API. Pour établir le montant d’un cas concret, il faudrait les relevés soumis pour l’heure et l’accord en cause, puis les lignes de facture définitives.

Le pouvoir économique se cache ici dans une clé technique. AWS fixe les règles de dédoublonnage. Le vendeur décide quelle identité envoie l’usage. Le client paie le résultat. Une migration maîtrisée donne à chaque heure une seule route vers la facture.

Sources officielles