Cas d'usage IA : le coût réel par tâche

TL;DR

Un business case défendable pour des cas d’usage IA chiffre une tâche, pas une direction. Prenez les vrais comptes de tokens, appliquez les tarifs actuels, ajoutez le cache, puis comparez au coût complet des heures que la tâche consomme aujourd’hui. La plupart des cas d’usage qui échouent à ce test échouent d’un ordre de grandeur.

Pourquoi chiffrer une tâche et non une direction ?

Chiffrer une tâche donne un nombre vérifiable en une semaine. Chiffrer une direction donne un nombre que personne ne peut réfuter, et c’est précisément pourquoi ces nombres survivent dans les présentations et meurent aux achats. Une tâche a une taille d’entrée mesurable, une taille de sortie mesurable, un volume mensuel mesurable et un coût humain mesurable aujourd’hui.

L’arithmétique tient dans un tableur, et c’est le but. Quatre entrées : tokens d’entrée par tâche, tokens de sortie par tâche, tâches par mois, et coût horaire complet de la personne qui le fait actuellement. Tout le reste est une recherche de tarif.

Deux erreurs ruinent la plupart des business cases :

1. Compter les heures libérées comme de la trésorerie. Une capacité libérée n’est pas une réduction de coût tant que personne ne part et qu’aucun recrutement n’est annulé. Écrivez-la comme capacité et laissez le métier décider si elle se convertit.
2. Chiffrer contre le mauvais modèle. Une tâche de tri paraît catastrophique sur Opus et gratuite sur Haiku. Le choix du modèle fait partie du business case, pas des détails d’implémentation.

Combien coûte une tâche aux tarifs actuels ?

Prenez un tri de documents avec 8 000 tokens en entrée et 1 500 en sortie. Aux tarifs catalogue actuels, la même tâche va d’environ 0,0016 USD sur Haiku 5.5 à environ 0,155 USD sur Fable 5.1, soit un facteur 100. Le choix du modèle déplace le business case plus que toute autre décision.

Tarifs de la page des modèles, avec notre arithmétique pour la tâche exemple :

Modèle	Entrée par Mtok	Sortie par Mtok	Coût par tâche	20 000 tâches par mois
Claude Haiku 5.5	0,10 USD	0,50 USD	0,0016 USD	31 USD
Claude Sonnet 5.5	2 USD	10 USD	0,031 USD	620 USD
Claude Opus 5.5	4 USD	20 USD	0,062 USD	1 240 USD
Claude Fable 5.1	10 USD	50 USD	0,155 USD	3 100 USD

Mettez cela face au côté humain. Si la tâche prend 12 minutes et que le coût complet de la personne est de 60 EUR par heure, la tâche coûte 12 EUR aujourd’hui. À 20 000 tâches par mois, cela représente 240 000 EUR d’effort mensuel. La ligne Sonnet 5.5 est à 620 USD. C’est la forme de presque tout cas d’usage documentaire bien choisi : le coût en tokens est une erreur d’arrondi, et la vraie question porte sur la qualité et l’effort de relecture, non sur le prix.

Cela vous dit aussi quels cas d’usage couper. Quand le coût en tokens arrive dans le même ordre de grandeur que le coût humain, le cas d’usage est mauvais : soit le modèle est trop grand, soit le prompt porte trop de contexte, soit la tâche ne se répète pas assez. Notre comparatif Sonnet et Opus détaille quelles charges justifient le modèle supérieur.

Quelles quatre corrections changent vraiment le chiffre ?

Quatre corrections déplacent un modèle de coût Claude de plus de 10 pour cent chacune : la mise en cache des prompts vers le bas, le nouveau tokeniseur vers le haut, les points de terminaison régionaux vers le haut et le traitement par lots vers le bas. Appliquez les quatre avant de présenter un chiffre, car les relecteurs les trouveront ensuite.

La mise en cache, vers le bas. Si 6 000 des 8 000 tokens d’entrée forment un préfixe stable, les lectures de cache sur Sonnet 5.5 coûtent 0,10 USD par million au lieu de 2 USD. La tâche passe de 0,031 USD à environ 0,0196 USD, soit environ 37 pour cent de moins, et 20 000 tâches tombent de 620 USD à environ 392 USD. L’écriture coûte 2,50 USD par million une fois par durée de vie du cache, donc le cache devient rentable dès que le préfixe est réutilisé plus de deux fois. Notre guide du prompt caching de Claude traite ce qui invalide un préfixe.

Le tokeniseur, vers le haut. Claude 4.7 et les modèles suivants utilisent un tokeniseur qui produit environ 30 pour cent de tokens en plus pour le même texte, alors que Sonnet 4.6 et antérieurs utilisent le précédent. Un modèle bâti sur des comptes mesurés avec Sonnet 4.6 sous-estime Sonnet 5.5 d’environ un tiers : la tâche exemple devient environ 10 400 tokens en entrée et 1 950 en sortie, donc 0,031 USD devient environ 0,040 USD. Remesurez sur le modèle que vous allez exécuter.

La résidence, vers le haut. Les points de terminaison régionaux et multirégionaux coûtent 10 pour cent de plus que les points globaux pour Claude Sonnet 4.5, Haiku 4.5, Opus 4.5 et tous les modèles suivants. Sur l’API de première partie, l’inférence limitée aux États-Unis via inference_geo est facturée 1,1 fois le tarif standard sur l’entrée, la sortie, les écritures et les lectures de cache. Si le cas d’usage touche des données personnelles et exige une région européenne, ajoutez les 10 pour cent avant que quiconque voie le chiffre.

Les lots, vers le bas. Amazon Bedrock propose certains modèles, dont ceux d’Anthropic, en inférence par lots à un tarif inférieur de 50 pour cent à l’inférence à la demande. Pour tout cas d’usage qui n’exige pas une réponse en quelques secondes, cela divise la ligne par deux. Le traitement documentaire nocturne et les reprises d’historique appartiennent ici.

Cumulées, sur la tâche exemple avec cache, nouveau tokeniseur et point de terminaison européen :

Correction	Coût par tâche	20 000 tâches par mois
Tarif catalogue Sonnet 5.5, sans correction	0,031 USD	620 USD
Plus nouveau tokeniseur, 30 pour cent de tokens en plus	0,040 USD	806 USD
Plus préfixe en cache à 90 pour cent	0,025 USD	507 USD
Plus point de terminaison régional, 10 pour cent	0,028 USD	558 USD
Le même, en lot nocturne sur Bedrock	0,014 USD	279 USD

Notre guide des prix de l’API Claude en Europe tient à jour les grilles tarifaires par route.

Comment chiffrer les sièges et les cas d’usage d’ingénierie ?

Les sièges et l’ingénierie suivent un autre modèle : vous payez par personne, pas par tâche, et le coût en tokens ne s’optimise pas tâche par tâche. Chiffrez ces deux lignes à partir des tarifs par siège publiés et des chiffres de déploiement d’Anthropic, non à partir d’un modèle de tâche.

Pour les travailleurs du savoir sur le chat et Cowork, claude.com/pricing donne les sièges Team Standard à 20 USD par siège et par mois en facturation annuelle, ou 25 USD en mensuel, pour des équipes de 2 à 150 personnes, avec jusqu’à 500 USD de crédits API mutualisés par mois. Enterprise coûte 20 USD par siège et par mois en annuel, la consommation étant facturée à part aux tarifs API, avec un minimum de 20 sièges. Les sièges Premium Team coûtent 100 USD par siège et par mois en annuel et portent cinq fois l’usage d’un siège Standard.

Pour l’ingénierie, utilisez les chiffres de déploiement publiés plutôt qu’un modèle de tâche. La page des coûts d’Anthropic rapporte environ 13 USD par développeur et par jour actif et 150 à 250 USD par développeur et par mois sur l’ensemble des déploiements en entreprise, en restant sous 30 USD par jour actif pour 90 pour cent des utilisateurs. À 40 développeurs, cela représente 72 000 à 120 000 USD par an, et c’est ce chiffre qu’il faut porter dans le business case.

Là où le modèle par siège déraille : sur les formules Enterprise par siège, le rapport de dépenses n’apparaît que si les usage credits sont activés et ne couvre alors que le dépassement, car l’usage inclus dans le quota de siège n’est pas mesuré en dollars. Un business case qui promet un reporting de coût par tâche sur une formule par siège promet ce que la plateforme ne produit pas. Calez la mesure sur ce que l’analytique rapporte réellement : membres actifs hebdomadaires, niveau d’adoption, fidélité produit, temps économisé estimé et un rapport de dépenses quotidien avec un jour de décalage.

Comment classer un portefeuille de cas d’usage ?

Classez sur deux axes seulement : la répétitivité de la tâche et le coût d’une réponse fausse. Le volume justifie l’effort de construction, le coût d’erreur détermine le volume de relecture à financer. Tout le reste, y compris l’enthousiasme de la direction, est un bruit qui ne survivra pas au premier trimestre.

Notre grille de notation, quatre questions par cas d’usage :

1. Volume. Combien de fois par mois ? En dessous d’environ 200 fois par mois, l’effort de construction et de relecture se rentabilise rarement, quelle que soit l’économie apparente par tâche.
2. Coût d’erreur. Que se passe-t-il si la réponse est fausse et que personne ne le remarque ? Si la réponse est « un client est mal facturé », l’étape de relecture est obligatoire et le business case doit la porter.
3. Vérifiabilité. Un relecteur peut-il contrôler le résultat en moins de temps qu’il n’en faut pour faire la tâche ? Sinon, l’économie est illusoire, car la relecture devient le nouveau goulot.
4. Classe de données. Des données personnelles ou réglementées sont-elles touchées ? Si oui, ajoutez le surcoût de résidence et le travail contractuel avant de comparer.

La décision de portefeuille qui en découle :

Volume	Coût d’erreur	Verdict
Élevé	Faible	Construire en premier. Meilleur rendement, gouvernance minimale
Élevé	Élevé	Construire en second, avec une relecture financée
Faible	Faible	Donner un siège de chat et un skill, ne pas construire
Faible	Élevé	Laisser aux humains. L’automatisation ajoute du risque sans rendement

Les cas d’usage qui meurent dans cette grille sont ceux qu’on présente le plus souvent en premier : un processus à fort coût d’erreur et faible volume qui agace quelqu’un d’important. Dites-le franchement dans le business case plutôt que de le noter poliment.

Chiffrer en interne ou externaliser ?

Construisez le business case vous-même. Il exige quatre nombres que vous seuls détenez : les vrais comptes de tokens de vos propres prompts, le vrai volume, le coût horaire complet et l’effort de relecture honnête. L’aide externe se justifie sur la mesure des tokens et la modélisation tarifaire, fastidieuse et sensible aux versions, et pour contester les volumes annoncés.

Ce que le travail demande, comme notre estimation et non comme référence sourcée :

Étape	Effort	Responsable
Mesurer les vrais comptes de tokens sur 20 tâches échantillons	1 à 2 jours par cas d’usage	Ingénieur avec une clé Console
Établir le volume actuel et le temps de traitement	2 à 5 jours par cas d’usage	Responsable du processus
Construire le modèle tarifaire avec cache et résidence	3 jours une fois, puis mises à jour	Finance et ingénierie
Estimer l’effort de relecture à partir d’un pilote	5 jours par cas d’usage	L’équipe qui relira
Notation du portefeuille et liste des coupes	3 jours	Celui qui peut dire non

Notre avis : la mesure est peu coûteuse, et c’est dans les volumes annoncés que se niche la fraude. Un business case bâti sur l’estimation d’un responsable de processus à « environ 2 000 cas par mois » qui se révèle être 300 est la façon la plus courante dont ces programmes perdent leur crédibilité. Tirez le nombre d’un système, pas d’une personne.

Ce qu’il faut exiger de quiconque construit un business case pour vous :

1. Des comptes de tokens mesurés sur vos prompts et sur le modèle que vous exécuterez, avec la génération de tokeniseur nommée.
2. Un volume tiré d’un système de référence, avec la requête montrée.
3. L’effort de relecture inclus comme coût, non supposé nul.
4. Le surcoût de résidence appliqué là où la classe de données l’exige.
5. Une liste de coupes nommée. Un portefeuille où chaque cas d’usage passe n’a pas été évalué.

Notre aperçu des tarifs Claude porte les grilles de formules et d’API sur lesquelles ces modèles reposent. La place du business case dans le programme figure dans notre stratégie IA pour l’UE.

FAQ

Qu’est-ce qu’un business case pour un cas d’usage IA ?

Un business case pour un cas d’usage IA chiffre une tâche précise aux tarifs de tokens actuels, ajoute l’effort de relecture nécessaire et compare le total au coût complet des heures que la tâche consomme aujourd’hui. Les sièges sont chiffrés à part aux tarifs par siège, et l’usage d’ingénierie aux chiffres publiés par développeur.

Combien coûte une seule tâche Claude ?

Pour une tâche de 8 000 tokens en entrée et 1 500 en sortie : environ 0,0016 USD sur Haiku 5.5, 0,031 USD sur Sonnet 5.5, 0,062 USD sur Opus 5.5 et 0,155 USD sur Fable 5.1 aux tarifs catalogue. Un préfixe en cache réduit le chiffre Sonnet d’environ un tiers, un point de terminaison régional l’augmente de 10 pour cent.

Quelles corrections manquent le plus souvent aux modèles de coût ?

Quatre. Le cache abaisse le chiffre, le nouveau tokeniseur à partir de Claude 4.7 l’augmente d’environ 30 pour cent pour le même texte, les points de terminaison régionaux ajoutent 10 pour cent, et l’inférence par lots sur Bedrock le divise par deux. Un modèle auquel il manque l’une d’elles se trompe de plus de 10 pour cent.

Chiffrer par tâche ou par siège : lequel s’applique ?

Par tâche pour les cas d’usage API et d’automatisation, où vous contrôlez le prompt et le volume. Par siège pour les personnes sur le chat, Cowork et Claude Code, où vous payez 20 USD par siège et par mois en Team Standard ou Enterprise annuel. L’usage d’ingénierie se chiffre mieux à 150 à 250 USD par développeur et par mois.

Comment décider quels cas d’usage abandonner ?

Notez le volume contre le coût d’erreur. Volume élevé et coût d’erreur faible : construire en premier. Volume faible et coût d’erreur élevé : laisser aux humains, car l’automatisation ajoute du risque sans rendement. En dessous d’environ 200 cas par mois, l’effort de construction et de relecture se rentabilise rarement.

Peut-on reporter le coût par tâche sur une formule par siège ?

Pas de façon fiable. Sur les formules Enterprise par siège, le rapport de dépenses n’apparaît qu’une fois les usage credits activés et ne couvre que le dépassement, car l’usage inclus dans le quota de siège n’est pas mesuré en dollars. Pour un coût par tâche, faites passer la charge par l’API ou un fournisseur cloud, où les tokens sont facturés directement.

Sources

1. Anthropic : tarifs des modèles (28 octobre 2026)
2. Anthropic : tarifs et formules Claude (28 octobre 2026)
3. Claude Code : maîtriser les coûts (28 octobre 2026)
4. Anthropic : data residency (28 octobre 2026)
5. AWS : tarifs Amazon Bedrock (28 octobre 2026)
6. Support Anthropic : analytique d'usage Team et Enterprise (28 octobre 2026)