06 - Mesurer qualite, cout et latence#

Trois chiffres. Tu ne peux pas optimiser les trois a la fois, mais tu dois savoir ou tu en es sur chacun.

Temps de lecture : 13 min | Niveau : Intermediaire

Ce que tu sauras faire apres#

• Suivre les 3 seules metriques qui comptent vraiment au quotidien.
• Calculer le cout reel d'un prompt a partir des tokens et de la grille tarifaire.
• Mesurer la latence correctement (median et p95, pas la moyenne).
• Tenir un tableau de suivi d'experimentations de prompts.
• Choisir entre modele, cache et batch en fonction de ce que tu veux optimiser.

🎯 Les 3 metriques#

La documentation Anthropic sur les criteres de succes liste plusieurs dimensions possibles : fidelite a la tache, coherence, pertinence, ton, preservation de la vie privee, utilisation du contexte, latence et prix. En pratique, au quotidien, tu en suis trois.

Les trois sont lies. Un modele plus gros ameliore souvent la qualite, mais coute plus cher et repond plus lentement. Un prompt plus long avec des exemples ameliore la qualite, et augmente le cout d'entree. Tu arbitres. Pour arbitrer, il faut des chiffres.

1️⃣ La qualite#

Rien de nouveau : c'est le score de ton jeu de tests. Deux regles.

Un seul chiffre principal. Si tu suis huit metriques, tu ne suis rien. Choisis la metrique principale de ta tache (exactitude par champ, taux de reponses acceptees, taux d'erreur de parsing) et mets les autres en contraintes bloquantes.

Une contrainte bloquante. Un score qui monte alors qu'une contrainte casse, ce n'est pas un progres. Exemple : tu passes de 94 % a 96 % d'exactitude, mais le nombre de valeurs inventees passe de 0 a 3. C'est une regression.

La doc Anthropic donne un exemple de critere multidimensionnel bien ecrit, adapte ici a ton contexte :

Sur un jeu de reference de 200 factures :
- exactitude par champ >= 96 %
- 0 valeur inventee la ou la donnee est absente
- 95 % des appels repondent en moins de 8 secondes
- cout moyen par facture < 0,01 EUR

2️⃣ Le cout#

Comment c'est facture#

Tu paies au token, separement en entree et en sortie. La grille tarifaire Anthropic est exprimee en dollars par million de tokens (/ MTok) et elle distingue :

• les tokens d'entree de base ;
• les ecritures dans le cache de prompt (5 minutes ou 1 heure) ;
• les lectures de cache ;
• les tokens de sortie.

Les tokens de sortie coutent nettement plus cher que les tokens d'entree. Ordre de grandeur constant sur toute la grille : un facteur 5. Donc : demander une sortie courte et structuree n'est pas seulement plus propre, c'est aussi moins cher.

Compter avant de payer#

Anthropic expose un endpoint dedie qui compte les tokens d'un message sans l'envoyer au modele, et son usage est gratuit (soumis a des limites de requetes par minute).

import anthropic

client = anthropic.Anthropic()

reponse = client.messages.count_tokens(
    model="claude-sonnet-5",
    system="Tu extrais des champs de factures.",
    messages=[{"role": "user", "content": prompt_complet}],
)
print(reponse)  # {"input_tokens": 1843}

Avec ce chiffre tu estimes le cout avant de lancer un traitement sur 40 000 lignes.

PRIX_ENTREE_PAR_MTOK = 2.00   # remplace par le prix du modele que TU utilises
PRIX_SORTIE_PAR_MTOK = 10.00  # verifie la page de tarification officielle

def cout(tokens_entree: int, tokens_sortie: int) -> float:
    return (tokens_entree * PRIX_ENTREE_PAR_MTOK
            + tokens_sortie * PRIX_SORTIE_PAR_MTOK) / 1_000_000

print(f"Cout pour 40 000 factures : {40_000 * cout(1843, 180):.2f} USD")

Les prix changent. Ne code jamais un tarif en dur sans un commentaire qui renvoie a la page officielle et une date. Mets-les dans un fichier de configuration.

Deux pieges documentes a connaitre :

• Le comptage depend du modele. La doc indique que les modeles Claude 4.7 et suivants utilisent un tokenizer plus recent, qui produit environ 30 % de tokens en plus pour le meme texte (l'ecart exact depend du contenu). Ne reutilise pas un comptage fait sur un ancien modele pour estimer le cout d'un nouveau : recompte avec l'identifiant du modele que tu vas utiliser. Methode recommandee par la doc : compte deux fois la meme requete, une fois avec ton modele actuel, une fois avec le modele vise, et compare les deux input_tokens.
• Les outils coutent des tokens. Le simple fait de declarer des outils ajoute des tokens d'entree : les definitions que tu ecris, plus un prompt systeme d'activation ajoute automatiquement, de l'ordre de quelques centaines de tokens selon le modele. Certains outils cote serveur ont en plus une tarification propre (la recherche web est facturee a la requete). Si ton agent declare 15 outils, tu paies leur description a chaque appel.

Mesurer le cout reel#

Ne te contente pas de l'estimation. La reponse de l'API renvoie l'usage reel. Journalise-le systematiquement.

reponse = client.messages.create(model=MODELE, max_tokens=512, messages=msgs)
u = reponse.usage
journal.append({
    "prompt_version": "v3",
    "input_tokens": u.input_tokens,
    "output_tokens": u.output_tokens,
})

Les trois leviers pour baisser le cout#

La doc precise que les remises Batch et cache se cumulent.

Le cache a une regle de rentabilite simple, donnee par la doc : avec une ecriture a 1,25x et une lecture a 0,1x, le cache 5 minutes est rentable des la premiere relecture. Pour un cache 1 heure (ecriture a 2x), il faut deux relectures.

Traduction pour toi : si tu traites 500 factures d'affilee avec le meme prompt systeme de 3 000 tokens, mets ce prefixe en cache. Tu paies le prefixe une fois plein tarif, puis 500 fois a 10 %.

3️⃣ La latence#

Mesure-la correctement#

Ne regarde jamais la moyenne. Une moyenne cache les cas lents, et ce sont eux qui cassent ton pipeline.

import statistics

def resume_latences(latences: list[float]) -> dict:
    tri = sorted(latences)
    return {
        "n": len(tri),
        "median": statistics.median(tri),
        "p95": tri[int(len(tri) * 0.95) - 1],
        "max": tri[-1],
    }

La doc Anthropic donne des exemples de criteres operationnels sous cette forme : « 95 % response time < 200ms ». C'est exactement l'idee : un percentile, pas une moyenne.

Ce qui fait la latence#

• Le nombre de tokens de sortie. C'est le facteur dominant. Le modele genere token par token. Une sortie deux fois plus longue prend a peu pres deux fois plus de temps. Limiter max_tokens et demander une sortie compacte, c'est du gain direct.
• La taille du prompt d'entree, dans une moindre mesure.
• Le modele choisi. Un modele plus petit repond plus vite.
• Le mode de raisonnement etendu, quand il est active.
• Le nombre d'allers-retours d'outils dans un agent : chaque appel d'outil est un tour supplementaire.

Reduire la latence percue#

• Streaming : l'utilisateur voit le texte arriver. La latence totale ne change pas, mais l'attente percue s'effondre. A privilegier des qu'il y a un humain en face.
• Parallelisation : pour un traitement par lot, lance N appels en parallele plutot qu'en serie. Attention aux limites de debit de ton palier.
• Cache de prompt : il reduit aussi le temps de traitement de l'entree, pas seulement le cout.
• Traitement asynchrone : si personne n'attend, la latence n'est pas une metrique. Passe en Batch et economise 50 %.

📊 Le tableau de suivi d'experimentations#

C'est l'outil le plus utile de cette fiche. Un simple fichier Markdown ou CSV dans ton repo, a cote du prompt.

Lis ce tableau. Il raconte une histoire complete :

• v3 a gagne 5 points de qualite mais coute 50 % de plus. Arbitrage accepte.
• v4 a supprime les inventions sans cout supplementaire. C'est le meilleur rapport de tout le tableau.
• v5 divise le cout par 4 mais perd 6 points : rejete.
• v6 garde la qualite de v4 et retrouve le cout de v2 grace au cache. C'est la version retenue.

Sans ce tableau, tu aurais garde v3 ou v5 "au feeling" et tu n'aurais jamais su.

📋 Template pret a copier : fiche d'experimentation#

# Suivi de prompt : [NOM DU PROMPT]

Jeu de tests : [CHEMIN DU FICHIER] ([NOMBRE] cas)
Metrique principale : [EX : EXACTITUDE PAR CHAMP]
Contrainte bloquante : [EX : 0 VALEUR INVENTEE]
Contrainte operationnelle : [EX : P95 < 8 S] et [EX : COUT < 0,01 EUR / UNITE]
Modele de reference : [IDENTIFIANT EXACT DU MODELE]

| Version | Date | Changement (UN SEUL) | Score | [CONTRAINTE] | p95 | Cout/1000 | Decision |
| --- | --- | --- | --- | --- | --- | --- | --- |
| v1 | [DATE] | baseline | | | | | baseline |
| v2 | [DATE] | [CE QUE TU AS CHANGE] | | | | | [garde/rejete] |

Regles que je m'impose :
- Un seul changement par version. Sinon je ne saurai pas ce qui a agi.
- Je remesure la baseline si je change de modele.
- Je ne garde jamais une version qui casse une contrainte bloquante.
- J'archive le texte exact de chaque version dans prompts/[NOM]_vN.txt

Cette derniere regle est importante : versionne le texte du prompt dans Git, a cote du code. Un prompt est du code. Il merite une diff, une revue et un historique.

🔁 AVANT / APRES : la facon de decider#

Avant#

« La v3 rend beaucoup mieux, on la garde. »

Aucune idee du cout, aucune idee de la latence, aucune idee de ce que "mieux" veut dire, aucune trace dans six mois.

Apres#

« v3 : 96 % contre 91 %, +50 % de cout, +1,2 s de p95. On garde parce que le critere est la qualite et qu'on est sous le budget de 0,01 EUR par unite. On teste le cache en v6 pour recuperer le cout. Detail dans prompts/extraction_facture/SUIVI.md. »

Meme decision, mais defendable, reproductible, et transmissible a un collegue.

A retenir#

• Trois metriques : qualite (ton jeu de tests), cout (tokens x tarif), latence (median et p95).
• La sortie coute environ 5 fois l'entree : une sortie courte et structuree est plus fiable ET moins chere.
• Compte les tokens avant d'envoyer, c'est gratuit, et recompte quand tu changes de modele (les tokenizers different).
• Les trois leviers de cout : le bon modele d'abord, puis le cache de prompt, puis l'API Batch (50 % de remise, cumulable avec le cache).
• Un changement par version, et un tableau de suivi versionne dans Git a cote du prompt.
• Ne regarde jamais la moyenne de latence : regarde le p95.

Sources#

Toutes ces pages ont ete ouvertes et verifiees le 26 septembre 2026. Les tarifs changent souvent : aucun montant en euros ou en dollars n'est recopie dans cette fiche. Va lire la grille officielle.

• Anthropic - Pricing : grille par modele, multiplicateurs de cache, remise Batch de 50 %, cout des outils.
• Anthropic - Token counting : endpoint gratuit, limites par minute, ecart de tokenizer entre generations de modeles.
• Anthropic - Define success criteria and build evaluations : criteres multidimensionnels, exemple « 95 % response time < 200ms ».
• Anthropic - Messages API : champs usage renvoyes par l'API, max_tokens.
• Microsoft Foundry - Built-in evaluators reference : si tu veux industrialiser la mesure de qualite cote Azure.