Créer une API, ça coûte cher. Développement, hébergement, maintenance, support.
Mais une API peut aussi rapporter de l'argent.
Stripe, Twilio, OpenAI vendent l'accès à leurs API comme produit principal,
et même un géant comme Google facture au compteur l'usage de ses cartes.
L'API n'est plus un simple outil technique interne.
C'est devenu un produit à part entière,
avec ses clients, son pricing et sa stratégie commerciale.
Et comme tout produit, elle a une roadmap, un support, un contrat de service
et parfois une équipe commerciale dédiée.
Le modèle SaaS et l'API-first
Historiquement, les logiciels se vendaient sous forme de licence.
Tu payais une fois, tu installais le logiciel sur ta machine, et c'était à toi.
Le SaaS (Software as a Service) a changé la donne.
Le logiciel tourne chez le fournisseur, tu y accèdes via Internet,
et tu paies un abonnement mensuel ou annuel. Pas d'installation,
pas de maintenance de ton côté.
Beaucoup de SaaS exposent une API en plus de leur interface web.
Certains vont encore plus loin avec l'approche API-first, où l'API est le produit
et l'interface web n'est qu'un client parmi d'autres.
C'est le cas de Stripe (paiement), Twilio (SMS et téléphonie), Algolia (recherche)
ou SendGrid (email).
L'intérêt commercial est massif. Une fois qu'une entreprise a intégré ton API
dans son parcours de paiement ou dans son moteur de recherche, en changer coûte
des semaines de développement. C'est un produit qu'on n'annule pas sur un coup de tête,
et ça se voit dans les taux de rétention.
Les modèles de tarification
Le freemium
Une offre gratuite avec des limites (nombre de requêtes, fonctionnalités),
et des plans payants pour aller plus loin.
C'est le modèle le plus courant. Il permet de tester l'API sans engagement
et de convertir les utilisateurs satisfaits en clients payants.
Google Maps en est un bon exemple. Un quota mensuel gratuit de chargements de carte
et d'appels, puis une facturation au millier d'appels au-delà, avec un tarif
qui dépend du service utilisé. Les grilles évoluent régulièrement, donc l'ordre
de grandeur à retenir tient en une phrase, quelques dollars pour mille appels,
ce qui reste anecdotique pour un site vitrine et devient une ligne budgétaire
sérieuse pour une application grand public.
Le piège du freemium, c'est le client qui reste gratuit à vie parce que le seuil
est trop généreux. Le seuil doit être assez haut pour convaincre pendant les tests
et assez bas pour qu'un vrai usage professionnel bascule dans le payant.
Le pay-per-use
Tu paies exactement ce que tu consommes. Pas de forfait, pas de minimum.
C'est le modèle de Stripe (une commission par transaction),
d'AWS (à la requête ou au gigaoctet) et des fournisseurs d'IA générative,
qui facturent au token, l'unité de découpage du texte que nous avons vue dans le chapitre sur
l'IA générative.
C'est idéal pour les usages variables. Un site qui fait 100 ventes en janvier
et 10 000 en décembre ne paie que pour ce qu'il utilise.
Le revers, c'est l'imprévisibilité. Une facture qui suit la consommation peut exploser
à cause d'une boucle infinie dans le code d'un développeur ou d'un pic de trafic imprévu.
D'où l'importance de poser des alertes de budget et des plafonds dès le premier jour,
plutôt que de découvrir la note à la fin du mois.
L'abonnement par paliers
Des plans fixes avec des quotas croissants.
Le plan "Starter" à 29 euros par mois pour 10 000 requêtes,
le plan "Pro" à 99 euros par mois pour 100 000 requêtes,
le plan "Enterprise" sur devis.
C'est prévisible pour le client comme pour le fournisseur, ce qui plaît beaucoup
aux directions financières des deux côtés. En contrepartie, le client paie
même les mois où il consomme peu, et se retrouve parfois à sauter d'un palier
à l'autre pour quelques centaines de requêtes de dépassement.
En pratique, la plupart des acteurs mélangent les modèles. Un abonnement de base
qui couvre un quota, puis une facturation à l'usage au-delà.
Le "Enterprise sur devis" cache d'ailleurs souvent autre chose que le volume,
un contrat de service avec engagement de disponibilité, un support prioritaire,
des garanties de conformité RGPD
ou un hébergement dans un pays précis.
Les clés API et le contrôle d'accès
Pour facturer, il faut savoir qui consomme et combien.
C'est le rôle de la clé API, un identifiant unique
que le client envoie à chaque requête.
La clé API permet au fournisseur de :
- Identifier le client et le rattacher à son compte.
- Compter les requêtes pour la facturation.
- Limiter le débit (rate limiting) pour protéger l'infrastructure et respecter les quotas du plan choisi.
- Bloquer l'accès si le paiement n'est pas à jour ou si la clé a été compromise.
- Analyser les usages pour savoir quelles fonctionnalités méritent d'être développées et lesquelles ne servent à personne.
Ce dernier point est sous-estimé. Une API bien instrumentée est une mine d'informations produit. Tu vois exactement quel appel est populaire, quel client augmente sa consommation (donc probablement prêt à passer au palier supérieur) et lequel s'effondre depuis trois semaines, signe qu'il est peut-être en train de partir chez un concurrent. Nous y reviendrons dans le chapitre sur les analytics.
La marketplace d'API
Certaines plateformes regroupent des centaines d'API dans un catalogue unique.
Les développeurs peuvent y chercher, tester et s'abonner à une API
directement depuis la marketplace, avec une facturation centralisée.
RapidAPI a longtemps été la référence du genre, et les grands fournisseurs
cloud proposent aujourd'hui la leur.
C'est l'équivalent d'un App Store, mais pour les API. Avec les mêmes avantages,
la visibilité et un paiement déjà en place, et les mêmes inconvénients,
une commission prélevée et une relation client qui appartient en partie à la plateforme.
Quand l'API n'est pas le produit
Toutes les API ouvertes ne cherchent pas à générer du chiffre d'affaires directement. Beaucoup sont gratuites parce qu'elles servent une autre stratégie.
- La distribution : plus de sites intègrent ton service, plus ta marque circule. Les boutons de partage et les widgets des réseaux sociaux ont été construits comme ça.
- L'écosystème : en ouvrant une API, tu laisses des tiers construire des intégrations que tu n'aurais jamais eu le temps de développer, ce qui rend ton produit principal plus difficile à quitter.
- Le partenariat : une API réservée à quelques partenaires contractuels, avec une facturation qui se négocie au contrat et pas sur une page de tarifs.
- L'usage interne : dans les grandes entreprises, les équipes se refacturent parfois leur consommation d'API entre elles, ce qui responsabilise sur les coûts d'infrastructure.
Une API gratuite n'est jamais une garantie. Plusieurs plateformes ont fermé ou rendu payante du jour au lendemain une API que des milliers d'applications utilisaient gratuitement, Twitter et Reddit en 2023 étant les cas les plus commentés. Des applications entières ont disparu en quelques semaines. Avant de construire ton produit sur une API tierce, demande-toi ce qui se passe si son prix est multiplié par dix, ou si elle ferme.
Le coût caché d'une API
Côté fournisseur, le prix affiché doit couvrir bien plus que les serveurs.
Le support technique représente souvent le poste le plus lourd, puisqu'un client qui
n'arrive pas à intégrer ton API écrit, et il faut lui répondre.
S'ajoutent la documentation à maintenir,
les bibliothèques clientes à mettre à jour dans cinq langages, et surtout la compatibilité.
C'est le point le plus douloureux. Une API vendue est une API qu'on ne peut plus casser.
La moindre modification du contrat
peut mettre en panne des centaines de clients, donc on maintient les anciennes versions
pendant des années. Ce coût-là n'apparaît sur aucune facture d'hébergement,
mais il pèse lourd dans la durée.
L'économie des API est devenue un pilier du numérique. Chaque fois qu'une application affiche une carte, envoie un SMS, traite un paiement ou traduit un texte, il y a probablement une API payante derrière. C'est un modèle qui aligne plutôt bien les intérêts, le fournisseur est motivé à maintenir un service fiable, et le client ne paie que pour la valeur qu'il reçoit.