Le coût d’usage d’une fonctionnalité d’IA générative se résume à une multiplication : le nombre de tokens envoyés et reçus, multiplié par le tarif du modèle, multiplié par le nombre d’appels. Pour le maîtriser, on agit sur ces trois facteurs : envoyer moins de contexte (ou le mettre en cache), choisir le modèle le plus léger qui fait correctement le travail, et regrouper ou éviter les appels inutiles. Bien conçue, une fonctionnalité IA a une facture aussi prévisible qu’un hébergement ; mal conçue, elle peut dériver sans que personne ne s’en aperçoive avant la fin du mois.
Cet article s’adresse aux dirigeants et responsables métier qui intègrent de l’IA dans une application (assistant interne, extraction de documents, rédaction de réponses, agent) et veulent comprendre d’où vient la dépense et comment la piloter.
De quoi se compose la facture d’une fonctionnalité IA ?
Les fournisseurs de modèles facturent à l’usage, au token. Un token est un fragment de texte, souvent un morceau de mot, que le modèle lit (tokens d’entrée) ou produit (tokens de sortie). Chez la plupart des fournisseurs, les tokens de sortie coûtent plus cher que les tokens d’entrée, et les modèles dits « de raisonnement » facturent aussi les étapes de réflexion intermédiaires qu’ils génèrent avant de répondre.
Ce qui surprend le plus souvent, c’est la taille de l’entrée. À chaque appel, l’application envoie bien plus que la question de l’utilisateur :
- les instructions système (le rôle de l’assistant, les règles, le ton, le format attendu) ;
- l’historique de la conversation, renvoyé intégralement à chaque nouveau message ;
- les documents récupérés pour répondre, dans une architecture RAG ;
- les définitions des outils que le modèle peut appeler (recherche, consultation d’une fiche client, création d’un ticket).
Une question de trois lignes peut donc embarquer plusieurs milliers de tokens de contexte. Et dans une conversation de vingt échanges, le dernier message transporte les dix-neuf précédents.
Quels sont les leviers pour réduire la facture ?
Six leviers couvrent l’essentiel des économies possibles. Ils se cumulent.
| Levier | Principe | Effet principal | À utiliser quand |
|---|---|---|---|
| Choix du modèle par tâche | Un modèle léger pour les tâches simples, un modèle avancé pour les cas difficiles | Divise le tarif unitaire | Toujours : c’est le premier réglage |
| Cache de prompt | Le début du prompt, identique d’un appel à l’autre, est relu depuis le cache | Réduit fortement le coût de l’entrée | Instructions longues, documents de référence, outils nombreux |
| Traitement par lots | Les demandes sont soumises en masse et traitées en différé | Remise de 50 % chez les principaux fournisseurs | Traitements de nuit, classement de stock, analyses en volume |
| Contexte réduit | Moins de documents, historique résumé, champs utiles seulement | Moins de tokens d’entrée | Conversations longues, RAG trop généreux |
| Sortie maîtrisée | Format structuré, longueur plafonnée, pas de préambule | Moins de tokens de sortie | Extraction, classement, réponses courtes |
| Pas d’IA du tout | Règles, recherche classique, cache applicatif de réponses identiques | Supprime l’appel | Tâches déterministes ou questions répétitives |
Choisir le modèle tâche par tâche
Les écarts de tarif entre modèles d’un même fournisseur sont considérables, et la plupart des tâches d’une application métier ne demandent pas le modèle le plus puissant. Classer un e-mail entrant, extraire un numéro de commande, reformuler une note : un modèle léger suffit très souvent.
Des chercheurs de Stanford ont formalisé cette idée sous le nom de cascade de modèles dans l’étude FrugalGPT : on interroge d’abord un modèle peu coûteux, et l’on ne passe à un modèle plus cher que si la réponse n’est pas jugée suffisante. Ils rapportent pouvoir égaler les performances du meilleur modèle de l’époque avec une réduction de coût allant jusqu’à 98 % sur leurs jeux de test. Le chiffre dépend fortement des tâches, mais le principe est robuste : réserver le modèle haut de gamme aux cas qui le justifient.
Mettre en cache le début du prompt
Le cache de prompt est une fonction proposée par les grands fournisseurs : lorsque le début d’un prompt est strictement identique à celui d’un appel récent, le modèle réutilise un calcul déjà fait et facture ces tokens à prix réduit. Chez Anthropic, la lecture depuis le cache coûte 0,1 fois le tarif d’entrée normal pour la plupart des modèles, l’écriture dans le cache coûtant 1,25 fois ce tarif pour une durée de cinq minutes. OpenAI annonce des remises allant jusqu’à 95 % sur les tokens en cache, avec aussi un gain de latence.
La condition est exigeante : tout le préfixe doit correspondre au caractère près. La règle de conception qui en découle est simple : le contenu stable d’abord (instructions, définitions d’outils, documents de référence), le contenu variable à la fin (date du jour, données de l’utilisateur, question). Une simple date placée en tête du prompt suffit à rendre le cache inopérant.
Traiter en différé ce qui peut attendre
Toutes les tâches n’ont pas besoin d’une réponse en deux secondes. Requalifier un fichier de 50 000 fiches produits, classer l’historique des réclamations, générer des résumés pour le reporting du lundi : ces traitements peuvent passer par les API de traitement par lots. OpenAI comme Anthropic les facturent 50 % moins cher que les appels synchrones ; OpenAI s’engage sur un traitement sous 24 heures, et Anthropic indique que la plupart des lots se terminent en moins d’une heure.
Comment estimer le coût avant de lancer ?
L’estimation se fait en tokens, puis se convertit avec la grille tarifaire du fournisseur retenu. Trois mesures, relevées sur un prototype avec des cas réels, suffisent :
- Les tokens d’entrée moyens par demande, en distinguant la partie stable (cachable) et la partie variable.
- Les tokens de sortie moyens par demande.
- Le volume : nombre d’utilisateurs, demandes par utilisateur et par jour, pics éventuels.
Prenons un exemple hypothétique : un assistant interne qui traite 2 000 demandes par jour, avec 3 000 tokens d’entrée par demande, dont 2 500 d’instructions et de documents de référence stables, et 400 tokens de sortie. Sans optimisation, l’application consomme 6 millions de tokens d’entrée par jour. Si les 2 500 tokens stables sont relus depuis le cache au dixième du tarif, chaque demande ne pèse plus que l’équivalent de 750 tokens d’entrée (500 variables + 2 500 × 0,1), soit une entrée réduite d’environ 75 %, avant même de toucher au choix du modèle. Les tokens de sortie, eux, ne bougent pas : c’est le format de réponse qu’il faut alors resserrer.
Ce calcul a un autre mérite : il montre au métier ce que coûte chaque choix fonctionnel. Garder tout l’historique d’une conversation, joindre dix documents plutôt que trois, demander une réponse rédigée plutôt qu’un tableau, tout cela se traduit en tokens.
Comment piloter la consommation en production ?
Les API renvoient, à chaque appel, le nombre de tokens consommés (y compris ceux lus depuis le cache). Une application bien conçue les enregistre et les rattache à leur contexte métier. Le pilotage repose sur quelques pratiques :
- Mesurer par fonctionnalité, par client et par utilisateur, et non seulement au niveau de la facture globale du fournisseur.
- Poser des quotas : par utilisateur et par jour, par client dans un produit multi-clients, avec un message clair quand la limite est atteinte.
- Alerter sur les anomalies : une consommation qui double d’un jour à l’autre signale souvent une boucle, un bug ou un usage détourné.
- Plafonner les agents : un agent IA qui enchaîne des appels d’outils doit avoir un nombre maximal d’étapes et un budget de tokens par tâche.
- Afficher les indicateurs dans un tableau de bord partagé entre l’équipe technique et le métier : coût par demande, taux de cache, répartition par modèle.
Dans un produit SaaS, cette mesure devient une donnée commerciale : elle sert à définir les volumes inclus dans chaque offre et à facturer les dépassements, un sujet que nous détaillons dans l’article sur les abonnements et la facturation récurrente.
Les pièges qui font dériver la facture
Les dérives viennent rarement d’un usage intensif légitime. Elles viennent de choix de conception invisibles pour l’utilisateur :
- L’historique renvoyé en entier à chaque message, sans résumé ni fenêtre glissante.
- Le RAG trop généreux qui joint vingt extraits quand trois suffisent, souvent faute d’un bon classement des résultats.
- Un élément variable en tête de prompt (horodatage, identifiant de session) qui casse le cache.
- Le même modèle partout, choisi pendant le prototype et jamais remis en question.
- Les nouvelles tentatives sans limite : un appel en erreur relancé en boucle, parfois par plusieurs composants à la fois.
- Les réponses bavardes : formules de politesse, reformulation de la question, explications que personne ne lit.
- Les tests automatisés branchés sur le modèle réel, lancés à chaque modification du code.
Chacun de ces points se corrige en quelques jours lorsqu’il est identifié. Le plus difficile est de le voir, d’où l’importance de la mesure.
Coût, qualité, latence : comment arbitrer ?
Réduire le coût ne doit pas dégrader le service. Avant de changer de modèle ou de raccourcir un contexte, on constitue un jeu d’évaluation : une centaine de cas réels avec la réponse attendue, sur lesquels on compare les configurations. On change de configuration quand la qualité est équivalente, pas quand elle « semble correcte ».
La latence entre aussi dans l’équation. Un modèle léger répond généralement plus vite, et le cache de prompt réduit le temps de traitement de l’entrée. À l’inverse, le traitement par lots n’a de sens que là où personne n’attend la réponse.
Enfin, la question la plus économique est celle de la nécessité. Le référentiel AFNOR sur l’IA frugale, présenté par la Direction générale des Entreprises, recommande de choisir la solution en considérant les alternatives à l’IA, et d’y renoncer si nécessaire. Une règle métier, une recherche plein texte ou une liste déroulante bien conçue font parfois mieux, plus vite et sans facture à l’usage. C’est aussi l’une des clés du choix entre un assistant du marché et une IA intégrée sur mesure.
Les questions à poser avant de développer
- Quelle tâche précise l’IA accomplit-elle, et existe-t-il une solution sans IA aussi bonne ?
- Quel est le volume attendu, et quels sont les pics ?
- Quelle part du prompt est stable et peut être mise en cache ?
- Quel est le modèle le plus léger qui réussit le jeu d’évaluation ?
- Quelles demandes peuvent être traitées en différé ?
- Où la consommation sera-t-elle mesurée, plafonnée et affichée ?
Ces réponses se construisent pendant le cadrage, avec un prototype et des données réelles. Si vous envisagez d’intégrer de l’IA dans une application métier et souhaitez en estimer l’usage avant de vous engager, décrivez votre projet dans notre diagnostic en ligne : nous revenons vers vous avec une première analyse.
