Le vrai coût de l'IA en entreprise : API, modèles frontières et local

« On a testé, ça marche super bien. » Puis arrive la facture du mois suivant, et la question devient : « Attends, on a dépensé combien ? »

Le coût d’un projet IA n’est jamais celui qu’on avait estimé, parce que l’estimation porte presque toujours sur la mauvaise variable. Voici comment le calculer avant de le subir.

TL;DR

• On ne paie pas au « nombre de questions », on paie au token : c’est-à-dire à la quantité de texte qui entre et qui sort. Le calcul se fait par tâche, pas par utilisateur.
• La sortie coûte structurellement plus cher que l’entrée, souvent 5 fois plus. Un modèle bavard coûte cher deux fois : en tokens et en temps de relecture.
• Le coût caché numéro un, c’est le contexte renvoyé à chaque tour. Dans un agent qui boucle, tu repaies l’historique à chaque appel.
• Le local devient rentable quand le volume est régulier, répétitif et prévisible, typiquement la transcription et l’OCR. Il reste inadapté aux tâches de raisonnement complexe.

Comment se facture réellement un modèle ?

La facturation se fait au token : environ 4 caractères, soit à peu près 0,75 mot en français. Un document d’une page fait grosso modo 500 à 700 tokens. Une conversation nourrie peut en consommer plusieurs dizaines de milliers.

Deux compteurs distincts tournent, à des tarifs différents : les tokens en entrée (ce que tu envoies : consigne, documents, historique) et les tokens en sortie (ce que le modèle génère).

À titre de repère, voici les tarifs publics de la gamme Anthropic, en dollars par million de tokens, au 12 août 2026 :

Modèle	Entrée	Sortie
Claude Opus 5	5 $	25 $
Claude Sonnet 5	3 $	15 $
Claude Haiku 4.5	1 $	5 $

Ces chiffres évoluent, vérifie toujours la page de tarification officielle avant de bâtir un budget. La structure, elle, ne bouge pas : la sortie coûte cinq fois l’entrée, et l’écart entre le modèle d’entrée de gamme et le modèle le plus capable est d’un facteur 5.

La conséquence pratique : le choix du modèle n’est pas un détail de configuration, c’est une ligne budgétaire. Faire tourner une classification de mails sur le modèle le plus puissant, c’est payer cinq fois le prix d’une tâche que le plus petit fait aussi bien.

Pourquoi la facture ne suit pas le nombre d’utilisateurs

C’est l’erreur d’estimation la plus courante : raisonner en « X euros par utilisateur par mois », comme pour un SaaS classique.

Le coût réel dépend de trois choses :

1. La taille du contexte envoyé. Un mail seul : quelques centaines de tokens. Le même mail avec l’historique du client, la documentation produit et vingt exemples : plusieurs milliers. C’est un facteur 10 sur la même tâche.
2. La longueur de la réponse. Un modèle qui répond en trois pages là où deux phrases suffisaient coûte cher, et te fait perdre du temps à la relecture.
3. Le nombre d’allers-retours. C’est le point que tout le monde découvre trop tard.

Le coût caché : l’historique repayé à chaque tour

Un modèle de langage n’a pas de mémoire. À chaque appel, on lui renvoie toute la conversation depuis le début. Dans un échange simple, c’est négligeable. Dans un agent qui enchaîne dix étapes avec des appels d’outils, l’historique grossit à chaque tour, et tu le repaies intégralement à chaque appel.

Un agent qui fait dix tours ne coûte donc pas dix fois un appel simple : il coûte bien plus, parce que le contexte du dixième tour contient les neuf précédents. C’est la raison pour laquelle un projet peut passer d’un coût anecdotique en test à une facture inconfortable en production, sans que le nombre d’utilisateurs ait changé.

Trois leviers concrets pour réduire cette facture :

• Choisir le bon modèle par tâche. Classer, extraire, reformater : un petit modèle suffit. Réserve le modèle le plus capable aux étapes qui demandent réellement du raisonnement.
• Contraindre les sorties. Demander une valeur parmi une liste fermée plutôt qu’un paragraphe divise le coût de sortie, et rend le résultat exploitable, comme vu dans l’article sur la différence entre déterministe et probabiliste.
• Nettoyer le contexte. Ne renvoie pas systématiquement tout l’historique. Un agent bien conçu transmet un état compact, pas la totalité de ce qui s’est dit.

Comment estimer un budget avant de coder ?

La méthode qui fonctionne tient en quatre étapes, et se fait sur un tableur en une heure.

1. Isole une unité de travail. Pas « le service client », mais « traiter un mail ». Une tâche, un début, une fin.
2. Mesure les tokens sur dix cas réels. Pas estimés : mesurés. Prends dix cas représentatifs, compte les tokens en entrée et en sortie. Tu obtiens une moyenne et, surtout, une valeur haute.
3. Multiplie par le volume mensuel réel. Le vrai nombre de mails par mois, pas la projection optimiste.
4. Applique un facteur 2. Les reprises, les erreurs, les cas complexes qui repassent, les tests. Cette marge n’est pas de la prudence excessive : c’est la différence habituelle entre l’estimation et la réalité.

Ce calcul te donne un ordre de grandeur fiable. S’il donne un montant dérisoire, tu peux avancer. S’il donne un montant qui fait tiquer, c’est le moment de revoir le choix du modèle ou le découpage des tâches, pas après la mise en production.

Quand l’IA locale devient-elle rentable ?

Faire tourner un modèle sur ta propre machine change complètement l’équation : tu n’as plus de coût variable, mais un investissement matériel et du temps d’exploitation.

Sur un test réel de développement assisté en local, la configuration utilisée était un i9 13900K, une RTX 4070 et 32 Go de RAM, une machine de travail costaude, pas un serveur de datacenter. C’est le bon ordre de grandeur pour faire tourner un modèle de taille moyenne sans frustration.

Le local gagne clairement sur :

• La transcription audio. Volume régulier, tâche répétitive, données souvent confidentielles. Le trio parfait.
• L’OCR de documents. Factures, contrats, dossiers : gros volumes, traitement bien cadré, données sensibles.
• Tout traitement où les données ne doivent pas sortir, indépendamment du calcul économique. C’est alors un critère de conformité, pas de budget.

Le local perd sur :

• Les tâches de raisonnement complexe. Un modèle local de taille moyenne n’a pas le niveau d’un modèle frontière, et l’écart est réel sur les tâches difficiles.
• Les usages irréguliers. Une machine amortie sur trois ans qui sert deux heures par semaine coûte plus cher qu’un usage à la demande.
• Le coût invisible du temps. Installer, configurer, maintenir, mettre à jour : ce temps est un coût, même s’il n’apparaît sur aucune facture.

La règle de décision simple : si ta tâche est répétitive, à volume régulier, et qu’elle manipule des données que tu ne veux pas voir sortir, calcule le local. Sinon, l’API à la demande sera presque toujours moins chère et surtout moins pénible.

Le coût qu’on n’anticipe jamais : la relecture humaine

Il ne figure sur aucune facture et il est souvent le plus élevé.

Chacun des cas d’usage réellement déployés en entreprise suppose une validation humaine à un moment. Ce temps de relecture est un coût, et il doit entrer dans le calcul du gain net.

L’arithmétique est simple : si l’IA fait gagner 8 minutes sur une tâche mais impose 3 minutes de relecture, le gain net est de 5 minutes. Un projet dont le gain net est proche de zéro n’est pas un projet, c’est un déplacement de charge.

Et si la tentation est de supprimer la relecture pour retrouver le gain complet, relis l’histoire du litige à 5 000 € : c’est exactement le calcul qui l’a produit.

Checklist : budgéter un projet IA

• J’ai défini une unité de travail précise (une tâche, pas un service).
• J’ai mesuré les tokens en entrée et en sortie sur dix cas réels.
• J’ai multiplié par le volume mensuel réel, avec un facteur 2 de sécurité.
• J’ai vérifié quel est le plus petit modèle capable de faire chaque tâche.
• J’ai regardé combien de fois l’historique est renvoyé dans les boucles d’agent.
• J’ai chiffré le temps de relecture humaine et calculé le gain net.
• J’ai identifié les tâches répétitives à gros volume, candidates au local.
• J’ai mis en place un suivi de consommation avant la mise en production, pas après.

FAQ

Comment savoir combien de tokens consomme réellement une tâche ?

Les fournisseurs exposent la consommation dans la réponse de chaque appel : nombre de tokens en entrée, en sortie, et éventuellement en cache. Il existe aussi des endpoints dédiés au comptage avant envoi. Le point important : ne jamais estimer avec un outil de comptage générique, car chaque famille de modèles a son propre découpage, un même texte ne donne pas le même nombre de tokens d’un modèle à l’autre.

Le cache permet-il vraiment de réduire la facture ?

Oui, et significativement, quand une grande partie de ton contexte est identique d’un appel à l’autre, une consigne système longue, une documentation, un référentiel produit. La partie mise en cache est facturée à une fraction du prix normal en lecture. La contrainte : le préfixe doit être strictement identique. Un simple horodatage inséré en début de consigne suffit à invalider tout le cache et à annuler le bénéfice.

Faut-il choisir le modèle le plus puissant par défaut ?

Non. C’est le réflexe le plus coûteux et le moins justifié. La bonne approche est de partir du modèle le plus économique capable de faire la tâche, de mesurer la qualité obtenue, et de ne monter en gamme que si le résultat ne tient pas. Beaucoup de tâches d’entreprise (classer, extraire, reformater, résumer) sont parfaitement traitées par les modèles d’entrée de gamme.

Un abonnement grand public suffit-il pour une entreprise ?

Pour de l’usage individuel exploratoire, oui. Dès qu’il s’agit d’intégrer l’IA dans un processus (appels automatisés, traitement en volume, intégration à un outil métier) il faut passer par l’API : c’est le seul moyen de contrôler le modèle utilisé, de mesurer la consommation, et de gérer les questions de conservation des données. Ce sont deux usages différents, pas deux niveaux de prix du même produit.

Conclusion

Le coût de l’IA n’est ni négligeable ni prohibitif : il est simplement variable, et c’est ce qui le rend inconfortable pour des directions habituées aux licences forfaitaires.

La bonne nouvelle, c’est qu’il est entièrement pilotable. Choisir le bon modèle par tâche, contraindre les sorties, nettoyer le contexte des boucles d’agent : ces trois leviers font régulièrement varier une facture d’un facteur 5, à qualité constante.

Fais le calcul sur ton cas d’usage avant d’écrire la première ligne de code. Une heure de tableur t’évitera une conversation désagréable au troisième mois.

Cet article s’appuie sur la MasterClass « Les vrais cas d’usage de l’IA » et sur le live consacré au développement avec un modèle local.