Mesurer le budget de tokens avant d’appeler un LLM

L'essentiel à retenir

Un document entre dans une automatisation. Le prompt tient. Puis un second document arrive, plus long, moins propre, chargé d'annexes. L'appel au LLM dépasse la limite prévue ou consomme un volume que personne n'avait anticipé. Le problème commence avant le modèle : personne n'a mesuré l'entrée.

Pour une PME de 10 à 50 personnes, un budget de tokens sert à poser une règle simple pour chaque étape : combien de texte accepte-t-on, que garde-t-on si la limite approche, et qui décide de la coupe ? Cette mesure doit être faite sur des données représentatives, avec le tokenizer correspondant au modèle visé et une marge de sécurité explicite.

ttok, le projet open source de Simon Willison, compte et tronque localement du texte avec la bibliothèque tiktoken. Il accepte du texte fourni directement, par entrée standard ou depuis un fichier. C'est utile pour tester un traitement documentaire, une base de connaissances, une automatisation ou un flux de support avant l'appel au fournisseur.

Mais le compteur local n'est ni une facture ni une garantie. Il faut comparer ses résultats aux observations du fournisseur, surveiller les écarts et retester à chaque changement de modèle, de tokenizer ou de chaîne de traitement.

Le problème que ça résout

Un budget de tokens donne une limite observable à un traitement qui, sinon, dépend de la longueur imprévisible des données entrantes. Dans une petite structure, cette discipline évite qu'un prototype correct sur quelques fichiers devienne opaque dès qu'il rencontre la variété réelle des documents.

Prenons un flux documentaire. Un contrat, une note interne et un export de tickets peuvent alimenter le même LLM, mais ils n'ont ni la même structure ni la même quantité de texte utile. Une base documentaire ajoute encore des extraits récupérés par recherche. Le support peut joindre l'historique d'un échange. Une automatisation peut empiler une consigne, des données métier et un format de réponse. Chaque morceau consomme une partie de la fenêtre disponible.

Sans mesure en amont, l'équipe découvre trop tard que le texte ne tient plus, que la troncature a supprimé une annexe importante ou qu'une étape envoie beaucoup plus de contenu que prévu. Réduire arbitrairement la taille ne règle rien. Une coupe aveugle peut préserver l'introduction et perdre la clause recherchée, conserver les anciens messages et supprimer la demande la plus récente, ou retirer les métadonnées nécessaires à l'interprétation.

Le budget doit donc exister par étape, pas seulement pour le flux complet. La préparation du document a son plafond. La récupération d'extraits a le sien. Le prompt système, le contexte métier et la place réservée à la réponse doivent aussi être visibles dans la décision. Cette décomposition aide le dirigeant ou la personne responsable des opérations à arbitrer : raccourcir, découper, résumer, différer le traitement ou envoyer le cas vers une revue humaine.

Il faut aussi mesurer sur un échantillon qui ressemble au travail réel. Un fichier bien mis en page ne représente pas une boîte documentaire entière. Le bon jeu de test contient les formats, les longueurs et les irrégularités que l'organisation accepte effectivement de traiter. Il ne sert pas à produire une moyenne rassurante. Il sert à trouver les cas qui forcent une décision.

Ce que c'est concrètement

ttok est un outil en ligne de commande qui compte et tronque du texte selon des tokens. D'après son README, il s'appuie sur la bibliothèque OpenAI tiktoken et peut recevoir le texte dans les arguments, via l'entrée standard ou depuis un fichier. Il peut également choisir un modèle ou un tokenizer, encoder et décoder du texte, afficher le détail des tokens, autoriser des tokens spéciaux et lister les modèles ou préfixes reconnus.

Depuis ttok 1.0, le tokenizer utilisé par défaut est o200k_base, présenté par le projet comme celui de GPT-5. Un choix par défaut ne suffit pas pour garantir la correspondance avec chaque modèle appelé. Pour une décision opérationnelle, la règle reste plus sobre : sélectionner explicitement le modèle ou le tokenizer attendu, puis vérifier le résultat contre ce que rapporte le fournisseur réellement appelé.

Ce point compte parce qu'un token n'est pas une unité universelle. Le même texte peut être découpé différemment selon le tokenizer. Le README recommande d'ailleurs d'employer le même modèle pour encoder puis décoder. Si l'équipe compte avec une configuration et exécute avec une autre, la précision apparente du nombre devient trompeuse.

Le matching par préfixe demande la même prudence. ttok peut associer un préfixe de nom de modèle à un tokenizer, mais cette association ne vérifie pas que le modèle existe. C'est pratique pour sélectionner un encodage. Ce n'est pas une validation du catalogue du fournisseur.

L'intérêt de l'outil tient à sa place dans la chaîne. Il est local et composable : on peut l'insérer avant une étape d'appel, l'utiliser pendant la préparation d'un corpus ou l'ajouter à un contrôle automatisé. Le texte peut ainsi être mesuré avant de quitter le poste ou l'environnement où le traitement est préparé. Cette caractéristique ne dispense toutefois pas d'examiner les règles internes applicables aux données, aux journaux et aux fichiers temporaires.

Le projet est public, écrit en Python et placé sous licence Apache-2.0. Son README décrit une installation par pip, uv ou Homebrew, ainsi qu'une exécution avec uvx. Le choix dépend de l'environnement de l'entreprise. Pour gouverner un budget, l'essentiel est ailleurs : fixer la version utilisée, rendre la configuration visible et éviter qu'un changement implicite de tokenizer modifie les seuils sans revue.

Comment s'en servir

Une utilisation sérieuse commence par le processus métier, pas par le compteur. L'objectif est de transformer une limite technique en règles que les opérations comprennent et peuvent contester.

Étape 1 : cartographier ce qui entre dans chaque appel

Listez séparément la consigne, le document principal, les extraits récupérés, l'historique éventuel et les éléments ajoutés par l'automatisation. Pour un traitement de support, cela peut inclure la demande actuelle et des échanges antérieurs. Pour une base documentaire, il faut distinguer la question des passages remontés par la recherche.

Cette carte évite de traiter le document comme l'unique source de volume. Elle révèle aussi qui maîtrise chaque partie. Les opérations peuvent décider quels champs sont nécessaires. La personne qui maintient l'automatisation peut expliquer ce qui est ajouté en coulisse. Le dirigeant peut fixer les situations où la continuité du service compte davantage qu'un traitement intégral.

Étape 2 : mesurer des données représentatives

Faites passer dans ttok un ensemble de contenus réellement représentatifs des cas acceptés, après la même extraction et la même préparation que celles utilisées en production. Mesurer le fichier brut alors que l'automatisation envoie du texte nettoyé, ou l'inverse, donne un résultat sans rapport direct avec l'appel final.

Ne retenez pas seulement le cas habituel. Examinez aussi les documents longs, les historiques encombrés, les contenus multilingues et les entrées dont la structure résiste au nettoyage. Il ne s'agit pas d'inventer un scénario extrême. Il s'agit de couvrir les variations déjà présentes dans le périmètre décidé par l'entreprise.

Conservez avec le résultat la version de ttok, le modèle ou tokenizer choisi et l'étape mesurée. Sans ces éléments, un nombre isolé ne permet ni comparaison ni diagnostic.

Étape 3 : attribuer un budget et une règle de dépassement

Fixez un plafond pour chaque composant, puis gardez une marge de sécurité avant la limite applicable à l'appel. Cette marge ne doit pas être un pourcentage copié ailleurs. Elle dépend de ce que la chaîne ajoute encore, de la variabilité observée et de la place que l'organisation veut préserver pour la réponse.

Associez chaque dépassement à une action explicite. Un document peut être découpé selon sa structure. Une recherche documentaire peut réduire le nombre d'extraits ou leur longueur. Un historique de support peut retirer des éléments devenus inutiles. Certains cas doivent être bloqués et revus par une personne, surtout si la coupe risque de changer le sens ou de retirer une information nécessaire.

La responsabilité doit être nommée. Quelqu'un approuve le budget, quelqu'un maintient la règle, quelqu'un traite les exceptions. Dans une PME, ces rôles peuvent appartenir à la même personne. Ils ne doivent pas disparaître pour autant.

Étape 4 : tronquer avec une intention métier

ttok sait tronquer selon un nombre de tokens. Cette capacité constitue un garde-fou technique, pas une politique documentaire. Couper la fin d'un texte n'a pas le même effet selon qu'il s'agit d'une procédure, d'un contrat, d'une conversation ou d'une série de tickets.

Définissez d'abord ce qui doit survivre. Une automatisation peut préserver les instructions et les champs obligatoires, puis limiter la matière documentaire. Un flux de support peut protéger la demande actuelle. Un traitement de documents structurés peut découper par section avant de compter chaque lot. Lorsque cette hiérarchie ne peut pas être exprimée proprement, la troncature automatique doit céder la place à une autre stratégie ou à une validation humaine.

Encodez et décodez avec le même modèle, conformément à l'avertissement du README. Sinon, le contrôle risque de modifier le texte de manière incohérente avec le comptage qui l'a déclenché.

Étape 5 : comparer, surveiller et tester les régressions

Après l'appel, relevez les informations que le fournisseur met effectivement à disposition et comparez-les à l'estimation locale. Un écart n'est pas à maquiller. Il doit être documenté, car il peut venir de la configuration, du contenu réellement envoyé ou d'éléments ajoutés ailleurs dans la chaîne.

Créez ensuite un petit corpus de régression avec des cas importants pour l'activité. À chaque changement de modèle, de tokenizer, de version de l'outil, d'extracteur ou de prompt, refaites les mesures. Vérifiez à la fois le volume et le contenu conservé après troncature. Un test qui confirme seulement que le texte « passe » peut rater la disparition d'une clause, d'une référence ou de la question utile.

La gouvernance tient dans cette boucle : mesurer avant, observer après, expliquer les écarts, corriger les règles. Sans elle, le budget devient un seuil oublié dans un script.

Ce que ça coûte vraiment

ttok est un projet open source sous licence Apache-2.0, mais l'absence de prix affiché pour l'outil ne rend pas le dispositif gratuit. Le coût se déplace vers l'intégration, la maintenance et le contrôle.

Il faut d'abord préparer les données de test. Quelqu'un doit sélectionner des documents représentatifs, retirer ou protéger ce qui ne peut pas être utilisé dans un environnement d'essai, puis vérifier que l'extraction correspond à la chaîne réelle. Ce travail appartient aux opérations autant qu'à la technique. Une équipe technique seule peut compter parfaitement un contenu qui ne représente pas le métier.

Il faut ensuite intégrer le comptage au bon endroit. Mesurer trop tôt ignore les transformations ultérieures. Mesurer trop tard réduit la capacité à choisir une autre stratégie. Les journaux doivent conserver assez de contexte pour comprendre une anomalie, sans recopier inutilement les données sensibles. Cette tension demande une décision, pas un réglage par défaut.

La maintenance compte aussi. Un modèle peut changer dans la configuration interne. Une automatisation peut ajouter un bloc de contexte. Un extracteur peut produire davantage de texte. Une nouvelle version de l'outil peut modifier un comportement attendu. Chaque changement appelle un test de régression et, parfois, une nouvelle validation du budget.

Enfin, il reste le coût des exceptions. Une troncature contestable réclame une revue. Un document mal structuré peut nécessiter une préparation spécifique. Un écart persistant entre la mesure locale et l'observation du fournisseur demande une enquête. Ces tâches prennent du temps, mais elles rendent la responsabilité visible. Le choix utile n'oppose donc pas « outil gratuit » et « solution payante ». Il oppose un volume subi à un volume gouverné.

La facture réelle des appels ne se déduit pas de ttok seul. Le compteur estime un découpage local selon un tokenizer. Le fournisseur reste la référence pour ses propres règles, ses informations d'usage et sa facturation. Les deux vues doivent être rapprochées sans être confondues.

Pour qui ce n'est pas

ttok n'est pas une réponse complète pour une organisation qui cherche une plateforme de suivi, une politique de conservation des données ou un système d'approbation. Il compte et tronque du texte. Il ne décide pas quelles informations ont une valeur métier, quelles coupes sont acceptables ni qui assume une erreur.

Ce n'est pas non plus un substitut aux observations du fournisseur. Si l'objectif est de réconcilier précisément les usages et la facture, il faut partir des données fournies par le service appelé, puis utiliser la mesure locale pour prévenir et expliquer. Inverser cette priorité transforme une estimation en vérité comptable.

L'outil convient mal à une équipe qui ne peut pas maintenir une ligne de commande dans sa chaîne ou qui n'a personne pour suivre les versions et les tests. Dans ce cas, la simplicité apparente risque de créer un contrôle que personne ne possède. Une solution intégrée, même moins flexible, peut être plus cohérente avec les capacités internes.

Enfin, la troncature automatique n'est pas adaptée lorsque chaque partie du document peut modifier une décision sensible et qu'aucune règle fiable ne permet de hiérarchiser le contenu. Le bon résultat n'est alors pas de faire tenir le texte à tout prix. Il faut revoir le découpage du traitement, demander une validation humaine ou ne pas automatiser ce cas.

Pour une PME, le critère n'est donc pas la sophistication. C'est la capacité à nommer un responsable, à tester sur ses propres données et à maintenir la règle dans le temps. Compter est facile. Assumer ce que l'on coupe demande une organisation.

Source : https://github.com/simonw/ttok

FAQ

Qu'est-ce qu'un budget de tokens pour un LLM ?

C'est une limite définie pour le texte envoyé à une étape donnée, accompagnée d'une règle lorsque cette limite approche ou est dépassée. Le budget peut distinguer les instructions, les documents, les extraits d'une base documentaire et l'historique. Il réserve aussi de la place pour ce que la chaîne doit encore ajouter et pour la réponse attendue.

ttok donne-t-il le coût exact d'un appel ?

Non. ttok compte localement des tokens selon le modèle ou tokenizer sélectionné. Ce résultat aide à préparer l'appel, mais ne remplace ni les informations d'usage ni les règles de facturation du fournisseur. Une PME doit rapprocher l'estimation locale de ce que le service appelé rapporte effectivement.

Peut-on tronquer automatiquement tous les documents ?

Techniquement, ttok peut tronquer un texte à une limite de tokens. Opérationnellement, la coupe doit respecter la structure et l'usage du document. Supprimer la fin d'un contrat, d'une procédure ou d'un échange de support peut retirer l'information recherchée. Il faut définir ce qui doit être conservé et prévoir une revue lorsque la règle est incertaine.

Quel tokenizer faut-il choisir ?

Choisissez explicitement celui qui correspond au modèle visé lorsque cette correspondance est connue, puis vérifiez les résultats avec les observations du fournisseur. Le tokenizer par défaut de ttok 1.0 est o200k_base. Un préfixe reconnu par l'outil peut sélectionner un tokenizer sans confirmer que le modèle nommé existe.

Quand faut-il refaire les mesures ?

Refaites-les dès qu'un élément susceptible de modifier le texte ou son découpage change : modèle, tokenizer, version de l'outil, extraction, prompt ou composition de l'appel. Le test doit contrôler le nombre de tokens et le sens du contenu conservé. Une limite respectée avec une information essentielle en moins reste une régression.

---

Publié le 9 octobre 2026.

Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.