Les coûts d'API LLM sont des coûts directs, pas des frais généraux : guide de la marge brute pour les wrappers IA

Un fondateur qui dirige un assistant de rédaction basé sur l'IA m'a dit que ses « coûts logiciels » s'élevaient à $40,000 par mois. Quand nous avons décomposé ce chiffre, $34,000 provenaient des factures d'API d'OpenAI et d'Anthropic — et rien de tout cela ne figurait dans son coût des marchandises vendues. Cette somme se trouvait dans une ligne générale « Logiciels et abonnements », juste à côté de son outil de gestion de projet à $19 par mois. Sa marge brute déclarée était de 91%. Sa marge brute réelle, une fois l'inférence replacée là où elle appartenait, était de 58%.

Ce n'est pas un détail comptable technique. C'est la différence entre une entreprise qui ressemble à un éditeur de logiciels et une entreprise qui se comporte comme une usine — où chaque unité vendue consomme un intrant réel et variable. Si vous construisez votre produit sur GPT-5, Claude, Gemini ou tout autre modèle hébergé, votre facture LLM n'est pas des frais généraux. C'est un coût des marchandises vendues, et le traiter autrement signifie que vous ne savez pas réellement combien d'argent vous gagnez.

Pourquoi cette erreur est si facile à commettre​

Le SaaS traditionnel a habitué toute une génération de fondateurs à considérer les coûts logiciels comme fixes. Vous payez pour l'hébergement, vous payez pour votre CRM, vous payez pour Slack — et aucune de ces factures ne varie en fonction de l'usage que fait un client donné de votre produit. Alors, quand la première facture d'API d'OpenAI arrive, il est naturel de la classer dans le même tiroir mental : « les outils que nous payons pour faire tourner l'entreprise ».

Le problème, c'est qu'une facture d'API LLM ne se comporte pas comme un abonnement SaaS. Elle se comporte comme une matière première. Chaque fois qu'un client envoie un prompt, vous consommez des tokens, et chaque token a un prix. Un client qui effectue 50 requêtes par jour vous coûte nettement plus cher à servir qu'un client qui en effectue 2. C'est la définition même du coût des marchandises vendues : un coût qui augmente directement avec la livraison de votre produit à un client donné, par opposition à un coût que vous paieriez simplement pour faire tourner l'entreprise, indépendamment de l'usage.

Les données du secteur confirment à quel point cet enjeu est devenu significatif. Le rapport State of AI de janvier 2026 d'ICONIQ montre que l'inférence représente désormais en moyenne 23% du chiffre d'affaires total des entreprises IA B2B en phase de croissance, et 84% de ces entreprises ont signalé une érosion de la marge brute de six points de pourcentage ou plus, directement attribuable aux coûts d'infrastructure IA. Ce n'est pas une erreur d'arrondi que l'on peut absorber dans des « frais généraux divers ». C'est souvent le principal poste de coût de l'entreprise, et il mérite d'être traité comme tel.

La frontière entre COGS et OpEx, bien tracée​

La règle qui sépare le COGS des charges d'exploitation n'a pas changé du simple fait que l'intrant est désormais une API de modèle plutôt qu'un entrepôt rempli de pièces détachées : les coûts liés à la livraison de votre produit à un client payant relèvent du COGS ; les coûts liés à la construction de votre produit relèvent de la R&D, au sein de l'OpEx. Appliquée à un wrapper IA, cette répartition se présente ainsi :

Relève du COGS :

• Coûts d'inférence en production — chaque appel API que votre produit en exploitation effectue pour le compte d'un client payant, qu'il s'agisse d'une complétion de chat, d'un appel d'embedding, d'une passe de classification ou d'une boucle d'appels d'outils par un agent
• Hébergement du modèle / calcul GPU — si vous exécutez un modèle à poids ouverts sur votre propre infrastructure ou sur une infrastructure louée plutôt que d'appeler une API hébergée, le temps de calcul attribuable au traitement des requêtes clients
• Infrastructure d'inférence de soutien — requêtes de base de données vectorielle, exécutions du pipeline d'embedding et frais d'orchestration qui existent spécifiquement pour servir les requêtes de production
• Coûts de support spécifiques à l'IA — un ingénieur support dont le travail consiste à trier les problèmes de sortie du modèle pour les clients constitue un coût de livraison du produit, et non une charge générale de SG&A

Relève de l'OpEx (généralement la R&D) :

• Inférence de développement et de test — chaque prompt qu'un ingénieur envoie en itérant sur une fonctionnalité, en déboguant une régression ou en évaluant une nouvelle version de modèle
• Exécutions de fine-tuning et d'évaluation — construire ou améliorer le modèle relève de la R&D, pas de la livraison
• Outils IA internes — les licences ChatGPT Enterprise ou GitHub Copilot de votre équipe sont une dépense de productivité, pas un coût lié au service des clients

L'étape pratique qui rend cette répartition possible est ennuyeuse mais essentielle : utilisez des clés API ou des projets de facturation distincts pour le trafic de production et de développement, dès le premier jour. Si vos ingénieurs testent des prompts avec la même clé que celle utilisée par votre produit en production, vous n'avez aucun moyen de répartir correctement la facture après coup, et vous finirez chaque mois par surestimer ou sous-estimer votre marge réelle.

À quoi ressemble la « vraie » marge brute pour les produits IA​

Une fois cette répartition effectuée, attendez-vous à ce que le chiffre obtenu diffère de ce à quoi vous êtes habitué. Les entreprises SaaS traditionnelles visent des marges brutes de 70–80%, presque par défaut. Les produits nativement IA n'y parviennent pas de la même façon. Le guide de tarification de février 2026 de Bessemer Venture Partners situe les marges brutes typiques des produits IA à 50–60%, bien en dessous de la fourchette de 80–90% du SaaS traditionnel, et les données d'ICONIQ montrent que la marge brute moyenne des produits IA dans le secteur progresse — mais seulement jusqu'à 52%, contre 41% en 2024 et 45% en 2025.

Une règle empirique utile, issue des opérateurs qui suivent cela de près : maintenez les coûts LLM en dessous d'environ 20% du COGS total si vous voulez un modèle économique durable et évolutif. Au-delà de ce seuil, la compression des marges a tendance à s'accélérer à mesure que vous grandissez, plutôt que de s'atténuer, car les gros clients utilisent le produit davantage, pas moins. Certaines catégories fortement dépendantes de l'IA — assistants de codage, agents de traitement de documents — affichent des ratios de coûts LLM de 30–40% du COGS et restent malgré tout viables, mais uniquement parce qu'elles ont délibérément tarifé leur offre en fonction de cette réalité, plutôt que de la subir après coup.

Le chiffre qui compte vraiment n'est pas votre marge brute globale et mélangée à l'échelle de l'entreprise — c'est le coût par client. Les utilisateurs intensifs d'une fonctionnalité IA peuvent coûter 50 à 100 fois plus cher à servir en inférence brute que les utilisateurs légers, sur le même palier d'abonnement. Si vous ne suivez pas cela, vous ne savez pas quels clients sont rentables et lesquels vous subventionnez discrètement chaque mois. Un forfait à taux fixe qui semblait convenable pour vos dix premiers clients peut commencer à perdre de l'argent dès que l'un d'eux met un workflow en production et multiplie son volume de requêtes par 20x.

Construire le modèle de coût par requête​

Pas besoin d'outillage sophistiqué pour commencer — il faut de la discipline pour consigner les bons chiffres à chaque requête. La formule de base est simple :

request_cost = (input_tokens / 1,000,000) × input_price_per_million
             + (output_tokens / 1,000,000) × output_price_per_million

Les tokens de sortie coûtent généralement 2–5x plus cher que les tokens d'entrée à l'unité, car la génération est plus intensive en calcul que la lecture d'un prompt — un modèle de coût par requête qui ne suit que le total des tokens, sans distinguer l'entrée de la sortie, évaluera donc systématiquement de façon erronée le coût de tout ce qui comporte de longues complétions. À titre d'exemple concret, aux prix mi-2026 : une requête avec 2,000 tokens d'entrée et une réponse de 500 tokens, sur un modèle grand public de milieu de gamme (environ $3 en entrée / $15 en sortie par million de tokens), coûte environ $0.0135. Répétez cette même requête 50,000 fois par mois et vous obtenez environ $675 de coût d'inférence pour cette seule fonctionnalité — un chiffre invisible s'il est noyé dans une ligne « coûts cloud » à cinq chiffres, mais très visible une fois qu'il est rattaché à la fonctionnalité et au segment de clientèle qui l'a généré.

Pour rendre cela concret :

1. Consignez le nombre de tokens à chaque requête, pas seulement le coût — la plupart des fournisseurs de modèles renvoient le nombre de tokens d'entrée/sortie directement dans la réponse de l'API, il s'agit donc d'un changement de journalisation, pas d'une nouvelle source de données.
2. Étiquetez chaque requête avec un identifiant client et un identifiant de fonctionnalité afin de pouvoir agréger les coûts par compte et par surface produit, et pas seulement par mois.
3. Calculez le coût par client et par période de facturation, puis comparez-le à ce que ce client vous paie. C'est ce chiffre qui vous indique si vos paliers tarifaires correspondent réellement à votre coût de livraison, et non votre marge moyenne mélangée.
4. Orientez vers des modèles moins chers lorsque la qualité le permet. Toutes les requêtes n'ont pas besoin de votre modèle le plus performant (et le plus coûteux) — les tâches de classification, d'extraction et de mise en forme simple fonctionnent souvent de manière acceptable sur un modèle plus petit et moins cher, et le routage de modèles est l'un des rares leviers de marge que vous contrôlez entièrement, contrairement à la tarification des fournisseurs.

Tarifer pour protéger la marge que vous venez de découvrir​

Une fois l'inférence correctement classée en COGS, votre approche tarifaire change. Un point d'ancrage courant utilisé par les opérateurs consiste à facturer environ 3–5x votre coût de token unitaire, de sorte qu'une tâche à $0.30 soit tarifée à $1.00 ou plus — non pas parce que ce multiple a quelque chose de magique, mais parce qu'il laisse de la marge pour absorber la variance d'usage, la volatilité des prix des modèles, ainsi que les coûts de support et d'infrastructure qui accompagnent l'inférence brute.

La facturation à l'usage est devenue la méthode standard par laquelle les entreprises IA font évoluer tarification et COGS de concert : facturez par token, par requête ou par tâche accomplie, et vos revenus évoluent avec la même variable qui détermine votre coût, au lieu de s'en éloigner comme le fait un abonnement à taux fixe lors d'un pic d'usage. Si vous n'êtes pas prêt à passer entièrement à une tarification à l'usage, mettez au minimum en place des paliers avec un minimum engagé plus un dépassement, afin qu'un client qui dépasse largement l'usage habituel ne devienne pas discrètement un produit d'appel déficitaire pour le reste du mois.

Gardez votre structure de coûts aussi auditable que votre code​

Rien de tout cela n'est une hygiène comptable optionnelle — c'est la différence entre savoir que votre modèle économique fonctionne et le découvrir pendant un appel de due diligence lors d'une levée de fonds, quand l'associé d'un investisseur construit le modèle de coût par client que vous auriez dû construire six mois plus tôt. Les fondateurs qui évitent cette conversation sont ceux qui rattachent les coûts d'inférence aux clients et aux fonctionnalités dès le premier appel API, pas ceux qui attendent que la facture OpenAI soit trop grosse pour être ignorée.

Beancount.io vous offre une comptabilité en texte brut, gérée par contrôle de version, qui facilite le rattachement des dépenses d'inférence au bon compte, la séparation de l'usage d'API entre production et développement, et le rapprochement de votre COGS réel avec vos revenus chaque mois — sans catégorisation en boîte noire, sans dépendance à un fournisseur. Commencez gratuitement et découvrez pourquoi les développeurs et les fondateurs nativement IA passent à la comptabilité en texte brut.