Pourquoi les API ne devraient facturer qu'en cas de succès — le plaidoyer pour la facturation au HTTP 200
La plupart des API facturent chaque appel facturable. Les agents IA réessaient sans cesse sur des services amont instables — ce qui revient, avec le modèle hérité « toujours facturer », à taxer la résilience. Voici le plaidoyer pour ne facturer qu'au HTTP 200, et ce que ça change dans la conception des agents.
L'essentiel
- •Les agents IA réessaient raisonnablement sur les échecs transitoires (5xx, timeouts, rate limits). Sous la facturation « toujours facturer », chaque retry est un vrai coût — transformant un amont à 99,5 % de disponibilité en pénalité de coût ×5 pendant les mauvais 0,5 %.
- •« Facturer uniquement sur HTTP 200 » aligne l'intérêt du fournisseur sur celui du client : les fournisseurs corrigent l'instabilité, les clients ne la paient pas.
- •Cela débloque aussi des patterns de conception — budgets de retry agressifs, prefetching optimiste, appels redondants — que le « toujours facturer » rend prohibitivement coûteux.
- •La plupart des fournisseurs ne le font pas parce que leur infra héritée lie le comptage à l'appel amont, pas à la réponse. C'est une limite du système de facturation déguisée en politique.
Le comportement que l'on cherche à encourager
Les agents IA sont un nouveau type de client d'API. Ce ne sont pas les intégrations d'entreprise prudentes de 2015 qui attrapaient une erreur et envoyaient un mail à un ingénieur d'astreinte. Ce sont des boucles qui, quand quelque chose échoue, dorment un instant et réessaient — parfois cinq ou dix fois — sans jamais remonter le résultat à un humain. Tout l'intérêt de la boucle est que les échecs transitoires soient invisibles pour l'utilisateur final.
C'est un excellent pattern. Il produit des produits résilients. Il cache aux utilisateurs la réalité chaotique de l'internet public. Le problème, c'est que le modèle de facturation des API a été établi à une époque où réessayer était assez rare et coûteux pour être découragé par défaut. Il fonctionne encore ainsi. Chaque retry est un appel facturable, qu'il ait renvoyé quelque chose ou non.
Concrètement : un agent qui frappe une API à 99,5 % de disponibilité et réessaie jusqu'à cinq fois sur les échecs transitoires va, pendant les mauvais 0,5 %, générer jusqu'à 5× les appels — et 5× la facture. L'agent a fait ce qu'il fallait. Le client paie l'instabilité de l'amont.
L'alternative plus simple
Ne facturer que sur HTTP 200. Précisément, uniquement sur une réponse réussie avec la forme de réponse documentée. Tout le reste — 4xx pour les erreurs de l'appelant, 5xx pour nos erreurs, timeouts, rate limits, réponses partielles-mais-mal-formées — est gratuit.
Cela ressemble à un petit changement. Ça ne l'est pas. Ça change ce qui est économiquement rationnel des deux côtés :
- Le fournisseur a désormais une incitation financière directe à corriger l'instabilité. Chaque 503 capricieux est une vente manquée, pas un repas gratuit. Nous avons constaté que l'adoption de la facturation uniquement en cas de succès a été la seule force la plus puissante qui a remonté notre travail de fiabilité en tête de roadmap — aucun tour de passe-passe de tableur ne fait paraître l'indisponibilité acceptable quand on renonce au revenu de ces appels.
- Le client peut dimensionner ses budgets de retry agressivement. Une boucle de 5 retries en exponential backoff devient une évidence quand le pire cas d'un échec transitoire est un seul appel payé (le succès final) au lieu de six (un payé par tentative).
- Le marché peut comparer les API en dollars par appel réussi plutôt qu'en dollars par tentative. C'est la bonne unité. Si deux API affichent toutes deux « $0.001 par appel » mais que l'une est à 99,9 % de disponibilité et l'autre à 95 %, les coûts visibles par l'utilisateur diffèrent de 5× sous le « toujours facturer », et de 0 % exactement sous le « uniquement en cas de succès ». Laquelle un acheteur devrait préférer est évident — et le « uniquement en cas de succès » le rend visible.
Ce que ça change dans la construction des agents
1. Les budgets de retry deviennent gratuits
Sous la facturation « toujours facturer », le bon budget de retry pour un gestionnaire d'échec transitoire est d'environ 1 à 2 tentatives — au-delà, le coût des échecs répétés commence à compter. Sous le « uniquement en cas de succès », le budget est « aussi longtemps que l'utilisateur peut attendre ». Nous voyons couramment des boucles d'agent avec des patterns de 5 retries, exponential backoff et jitter qui seraient imprudents sous la facturation héritée.
2. Le prefetching optimiste devient bon marché
Un pattern prohibitivement coûteux sous le « toujours facturer » : lancer un appel de recherche de manière spéculative pendant que l'utilisateur tape encore, au cas où la requête prédite serait la bonne. Si la prédiction est fausse, on jette le résultat. Sous le « uniquement en cas de succès », c'est bon marché parce que les appels annulés / inutilisés renvoient un succès mais on jette la réponse — on paie donc une petite prime pour la prévisibilité et la latence. Sous le « toujours facturer », chaque prédiction erronée est un appel payé, ce qui rend l'heuristique trop chère à livrer.
3. Les appels redondants deviennent un outil de fiabilité
Parfois, la stratégie de fiabilité la moins chère consiste à lancer deux requêtes vers deux API différentes, à prendre celle qui répond la première et à jeter la plus lente. Sous le « toujours facturer », ça double votre facture. Sous le « uniquement en cas de succès », c'est gratuit pour l'appel jeté (vous n'avez pas utilisé la réponse, vous ne l'avez pas payée). Soudain, des stratégies de hedging qui étaient des abstractions coûteuses deviennent praticables.
Ce que « succès » doit signifier
Le modèle ne fonctionne que si « succès » est sans ambiguïté. Nous le définissons strictement :
- HTTP 200 avec le schéma de réponse documenté — facturable.
- HTTP 200 avec une erreur enveloppée dans le corps de la réponse — non facturable (ce serait la faille qui casse tout le modèle).
- HTTP 4xx — non facturable. Cela inclut 401 (auth), 402 (crédits insuffisants), 422 (validation), 404 (introuvable dans certains contextes).
- HTTP 5xx — non facturable.
- HTTP 429 (rate limit) — non facturable.
- Erreurs réseau / timeouts avant notre edge — non facturables.
Pour les endpoints batch (par ex. URL Extract avec 25 URL en un appel), l'appel dans son ensemble est un seul HTTP 200 si au moins une URL a réussi, facturé au tarif par URL. Le champ status par URL indique à l'appelant quelles URL ont échoué. Le travail a été fait ; c'est facturable.
Pourquoi la plupart des fournisseurs ne le font pas
Trois raisons, par ordre d'importance :
- L'infrastructure de facturation. Le pattern standard consiste à compter au niveau de l'API gateway, avant de connaître la réponse. La gateway émet un événement facturable dans Kafka, le système de facturation l'agrège, la facture est envoyée. Recâbler le comptage pour qu'il se déclenche après que le service amont a répondu avec un code de statut exige soit (a) de coupler la gateway à la santé du backend (créant de nouveaux modes de défaillance), soit (b) d'écrire un pipeline de réconciliation qui crédite rétroactivement les appels en échec. Les deux représentent un vrai travail d'ingénierie.
- L'habitude. Le pattern a été établi par des backends fiables — Twilio, AWS, Stripe. Il fonctionne bien quand votre amont est à 99,99 % de disponibilité. Les API qui enveloppent des LLM, scrapent le web ou appellent des partenaires de données lents sont bien moins fiables, mais le pattern de facturation a été hérité de l'ère fiable et jamais mis à jour.
- Le revenu. Le « toujours facturer », c'est simplement plus d'argent. La plupart des fournisseurs n'ont pas eu à se concurrencer sur cette dimension parce que la plupart des clients n'étaient pas du trafic d'agent, et les utilisateurs humains synchrones tolèrent mieux des échecs occasionnels qu'ils ne tolèrent de lire un modèle de facturation.
La première est du vrai travail d'ingénierie. Les deuxième et troisième sont de l'inertie. Les deux céderont à mesure que le trafic d'agent devient la majorité de la consommation d'API — ce que, selon les tendances, devrait advenir d'ici 18 mois pour la plupart des API publiques.
Ce qu'il faut chercher en tant qu'acheteur
Si vous évaluez des API de données pour une charge d'agent, trois questions explicites :
- « Facturez-vous uniquement sur HTTP 200, ou sur chaque tentative facturable ? » — réponse franche exigée. N'acceptez pas « en général » ou « selon le plan ».
- « Comment le HTTP 207 / succès partiel est-il facturé ? » — fait ressortir la réponse à failles.
- « Quelle est votre disponibilité publiée, et quel est le mécanisme de remboursement SLA si vous la manquez ? » — le « uniquement en cas de succès » est un signal fort mais ne remplace pas un vrai SLA. Les deux devraient être présents.
Le glissement que cela annonce
Les agents IA changent l'économie unitaire de chaque API qu'ils touchent. Les API conçues pour l'ère des agents sont différentes — formes plus simples, schémas prévisibles, auth machine-friendly, tarification transparente — et leurs modèles de facturation aussi. Le « uniquement en cas de succès » est l'un des glissements les plus simples. Le plus difficile, encore devant nous, est de comprendre comment les workflows d'agent multi-étapes se tarifent entre fournisseurs quand aucune partie unique ne possède le chemin complet.
Pour l'instant, exigez le « uniquement en cas de succès » des fournisseurs qui le peuvent. Construisez des agents qui en tirent parti. Et quand vous cherchez une API, faites le calcul en dollars par appel réussi, pas en dollars par tentative.
Questions fréquentes
Le « uniquement en cas de succès » n'incite-t-il pas les fournisseurs à classer des succès en échecs ?
En théorie, mais la pression inverse est plus forte : les développeurs comparent les API sur le coût réel en dollars par appel utile, et c'est exactement ce que mesure le « uniquement en cas de succès ». Un fournisseur qui requalifierait discrètement des succès en échecs ferait face à une file de support en colère et à une traînée d'avis publics en quelques jours. Le marché est assez petit pour que ça s'auto-corrige.
Et si mon appel réussit partiellement — par exemple, un extract batch où 2 URL sur 25 échouent ?
Deux modèles raisonnables. (a) L'appel entier est un HTTP 200 si au moins une URL a réussi ; les échecs par URL sont signalés dans le statut par URL. Le travail a eu lieu, donc c'est facturable. (b) HTTP 207 (multi-status) pour le partiel — chaque URL est facturée individuellement. Nous avons choisi (a) parce que ça rend la tarification prévisible : les agents savent qu'un HTTP 200 réussi signifie que le pire cas est le coût en crédits annoncé. Le (b) est plus « équitable » mais plus difficile à budgéter.
Qu'est-ce qui compte comme un échec ?
Notre règle : un HTTP 4xx clairement imputable à l'appelant (corps mal formé, auth manquante, crédits insuffisants) n'est pas facturé. Un HTTP 5xx n'est jamais facturé — c'est notre problème. Les erreurs réseau et timeouts de notre côté ne sont jamais facturés. Les rate limits (429) ne sont jamais facturés. La seule chose facturée est un HTTP 200 avec la forme de réponse annoncée.
Pourquoi la plupart des fournisseurs facturent-ils chaque appel ?
Trois raisons, surtout historiques. (1) Les systèmes de facturation hérités comptent au niveau de l'API gateway, avant de connaître la réponse. Câbler la facturation pour qu'elle se déclenche rétroactivement sur le statut de réponse n'est pas trivial. (2) Le pattern a été établi par Twilio et AWS à une époque de backends fiables ; les API qui enveloppent des LLM ou scrapent le web sont bien moins fiables, l'hypothèse cesse donc de tenir. (3) C'est plus de revenu. Les deux premières sont des excuses ; la troisième est la vérité.
Y a-t-il des cas où le « toujours facturer » a du sens ?
Quand l'appel consomme réellement un coût fixe à chaque invocation, quel que soit le résultat — par exemple un appel matériel (SMS envoyé), une mutation atomique à la frontière (mise à jour DNS), ou un service dont le backend ne sait pas distinguer « on a essayé et échoué » de « on l'a fait et vous ne l'avez pas remarqué ». Pour les API de données en lecture et les API de recherche, le modèle ne convient pas.
APIs utilisées dans cet article
Sarah Choy est CEO d'API Pick. Elle écrit sur la création d'APIs prêtes pour la production destinées aux agents IA et aux workflows LLM.