La monétisation ne paiera pas votre plateforme

Dans un business case de plateforme APIM sur trois, la monétisation apparaît en ligne de recettes : « à terme, la plateforme s'autofinancera par la vente d'API ». C'est un des arguments les plus efficaces en comité d'investissement, et une des promesses les moins tenues du marché.

Le module de monétisation, lui, fonctionne. Ce qui manque, c'est tout le reste.

Pourquoi ça ne se produit presque jamais

Il faut un produit, pas une API. Une API qui se vend est une API dont quelqu'un d'extérieur tire une valeur mesurable, avec une documentation irréprochable, des garanties de service, un support. C'est un produit au sens plein, avec un responsable produit, un marketing, une policy tarifaire. La plupart des API candidates à la monétisation sont des API internes qu'on espère vendre telles quelles. Elles ne valent rien telles quelles.

Le marché est plus petit que prévu. Qui, précisément, paiera ? La réponse honnête est souvent : les partenaires existants, qui payaient déjà la prestation d'une autre manière, et dont la facturation à l'appel dégrade parfois la relation plus qu'elle ne rapporte.

La facturation est un métier. Dès qu'un appel coûte de l'argent, chaque erreur de comptage devient un litige. Il faut des relevés opposables, une gestion des avoirs, des seuils d'alerte côté client, un support facturation. Le module de la plateforme compte les appels, il ne fait rien de tout cela.

Le compteur de la gateway n'est pas une source de vérité

C'est le point qui fait échouer les projets déjà lancés, et il est technique. Un module de monétisation compte ce que la gateway a vu. Le client, lui, conteste sur ce qu'il a envoyé, et les deux nombres diffèrent toujours.

Ils diffèrent pour des raisons parfaitement normales. Les métriques d'une gateway sont souvent agrégées et parfois échantillonnées, ce qui est un choix de performance raisonnable et une catastrophe comptable. Un redémarrage d'instance perd les compteurs en mémoire non encore exportés. Les appels rejetés en amont, quota dépassé ou jeton invalide, sont comptés ici et pas là. Et une réponse servie depuis un cache de bordure n'atteint jamais le compteur.

Un système de facturation demande l'inverse d'une métrique. Il lui faut un enregistrement par événement facturable, immuable et horodaté. Un identifiant unique par événement, qui rend le rejeu idempotent. Une conservation au moins aussi longue que le délai de contestation prévu au contrat. Et un rapprochement mensuel avec le total facturé.

Ces quatre propriétés se retrouvent dans tous les systèmes de facturation à l'usage, chez un opérateur télécom comme chez un fournisseur de cloud. Aucune gateway ne les rend par défaut. D'où la première question à poser à l'éditeur qui vend le module : votre compteur produit-il des événements unitaires réconciliables, ou des séries agrégées ? La seconde réponse signifie que la facturation reste à construire.

Ce que le comptage fait vraiment gagner

La bonne nouvelle, c'est que l'infrastructure de monétisation a un usage qui rapporte presque à tous les coups : la refacturation interne, ou même sa version sans facture, la simple visibilité des consommations.

Publier chaque mois qui consomme quoi, en volume et en coût d'infrastructure imputé, change les comportements plus sûrement que n'importe quelle norme : les batchs aberrants se corrigent, les caches apparaissent côté consommateur, les capacités se dimensionnent sur des chiffres. C'est de la gouvernance par la transparence, et ça ne demande ni contrat ni support facturation.

Si vous voulez vraiment vendre

Il existe des cas légitimes : une donnée rare, un service difficile à répliquer, une position de place de marché. Si vous y êtes, traitez le sujet comme un lancement de produit, pas comme une option de la plateforme :

1. un responsable produit nommé, dont c'est l'objectif principal.
2. une étude de disposition à payer faite avec de vrais prospects, avant tout développement.
3. une tarification simple au départ : paliers mensuels plutôt que paiement à l'appel, pour limiter la mécanique de litige.
4. des conditions de service écrites et tenables, adossées à votre observabilité réelle.
5. le circuit de facturation branché sur l'outillage de facturation de l'entreprise, pas sur le module de la gateway.

Deux sujets se découvrent toujours trop tard, et aucun n'est technique. La fiscalité d'abord. Vendre des appels d'API à des clients de plusieurs pays est une vente de service électronique, avec des règles de TVA qui dépendent du pays du client et de sa qualité d'assujetti. Aucun module d'APIM ne les connaît.

Le recouvrement ensuite : relances, suspension de service pour impayé, avoirs. Ce sont des processus d'entreprise, et ils décident si le revenu est encaissé ou seulement facturé.

Et surtout : un seuil d'abandon décidé à l'avance. Si le revenu à douze mois est sous le coût du dispositif, on arrête. La monétisation zombie, maintenue parce qu'elle figurait au business case, est un poste de coût déguisé en poste de recette.

La ligne à écrire dans le business case

À la place de « la plateforme s'autofinancera », écrivez : « la plateforme rendra les consommations visibles et imputables ». C'est finançable, c'est tenable dès la première année, et cela ne vous oblige pas à inventer un marché.

Le business case complet, poste par poste, est le sujet de Combien coûte vraiment une plateforme d'API management. La monétisation y figure, à sa place : en option incertaine, jamais en pilier du financement.