Le fournisseur facture le traitement de tokens, pas la justesse du résultat. Si une requête échoue à mi-parcours, si le timeout se déclenche alors que la réponse était déjà en cours de génération, ou si votre code jette la sortie parce qu’elle ne respecte pas le format, ce travail est facturé quand même et il faut le refaire.
C’est la part de la facture qui n’apparaît sur aucun tableau de bord, parce que les tableaux de bord comptent les requêtes, pas les requêtes utiles.
En un coup d’œil
| Ce qui se passe | Le travail raté est facturé comme le bon |
| Sources | Reprises, timeouts, validations échouées, réponses en double |
| Comment le voir | Comparer requêtes facturées et tâches terminées |
| Le levier | Échouer plus tôt, reprendre plus finement, valider moins cher |
D’où viennent les répétitions
Les reprises automatiques sont le premier suspect. Beaucoup de bibliothèques reprennent par défaut sur une erreur réseau ou une limite de débit, et le font trois fois sans rien dire. Si la panne venait du modèle et que la génération avait déjà commencé, vous avez payé trois réponses pour en utiliser une.
Les timeouts mal réglés viennent ensuite. Un timeout plus court que la longue réponse que le modèle produit parfois coupe la connexion mais pas la facturation : le fournisseur a déjà fait le travail.
Le troisième est de votre côté : la validation a posteriori. Si vous demandez un format et que votre code rejette la sortie quand elle ne colle pas, chaque rejet est une requête payée et jetée.
Comment le voir dans vos chiffres
Comparez deux chiffres sur la même période : requêtes facturées par le fournisseur et tâches terminées par votre système. L’écart, c’est le gaspillage. Si vous n’avez pas le second, c’est la première chose à instrumenter, et cela va de pair avec le suivi des dépenses.
Sur les agents, l’effet se multiplie, car une étape ratée traîne tout l’historique accumulé. C’est l’une des raisons pour lesquelles un agent coûte plus cher qu’il n’y paraît.
Quoi changer
Ne reprenez que ce qui mérite d’être repris. Une erreur réseau, oui. Une réponse déjà générée qui ne vous plaît pas, non : cela ne se règle pas en répétant, mais en changeant le prompt.
Réglez le timeout sur la réponse longue, pas sur la moyenne. Et si vous devez vraiment couper, plafonnez les tokens de sortie plutôt que la connexion.
Validez à bas coût. Si le format échoue souvent, utilisez la sortie structurée du fournisseur au lieu de la demander dans le prompt et de vérifier après.
Journalisez le motif de chaque reprise. Sans cette étiquette, le gaspillage est invisible et personne ne le corrige.
Questions fréquentes
Une requête en timeout m’est-elle facturée ? En général oui, si le modèle a déjà commencé à traiter. La coupure vient de votre côté, pas du sien.
Quel poids cela représente-t-il ? Cela varie beaucoup, mais sur des systèmes non instrumentés il est courant de trouver une part de la dépense qui ne paie que du travail jeté.
Est-ce un problème de coût ou de qualité ? Les deux. Chaque reprise est de l’argent et aussi de la latence pour l’utilisateur qui attend.
Chez e-ficient, nous mesurons le coût par tâche d’entreprises qui exploitent déjà l’IA en production et vous disons combien vous économiseriez avec chaque levier à votre volume réel. Le premier audit est gratuit si vous souscrivez un forfait avec un engagement de trois mois et rend un diagnostic sous 72 heures.