Qu’est-ce qu’un token ? Comprendre le coût et les limites d’une IA
Un token est une unité de texte traitée par un modèle. Ce n’est ni exactement un mot, ni exactement un caractère. Un mot fréquent peut tenir dans un token ; un terme rare peut être découpé en plusieurs fragments. Les espaces, la ponctuation et certaines parties de mots comptent également.
Cet article prolonge notre vidéo TikTok pour expliquer sans jargon pourquoi les tokens influencent la facturation des API, la taille des documents utilisables et la longueur maximale d’une conversation.
Comment le texte est découpé
Avant d’interpréter votre demande, le modèle la convertit en une séquence de tokens. Il prédit ensuite des tokens de sortie, qui sont reconvertis en texte lisible.
Pour l’anglais, un repère souvent utilisé est environ quatre caractères ou trois quarts de mot par token. Ce n’est qu’une moyenne. Le décompte dépend du modèle, de la langue, du vocabulaire, du code et de la ponctuation.
Pourquoi le français peut utiliser davantage de tokens
Les systèmes de tokenisation sont fortement influencés par les fréquences rencontrées pendant leur conception et leur entraînement. Les langues autres que l’anglais peuvent présenter un rapport tokens-caractères plus élevé.
Il est donc imprudent d’estimer un budget français à partir d’une règle anglaise. Utilisez le compteur associé au modèle ou une bibliothèque compatible, surtout pour un grand volume.
Tokens d’entrée, de sortie et mis en cache
Les fournisseurs distinguent généralement plusieurs catégories. Les tokens d’entrée correspondent au prompt, aux documents et au contexte. Les tokens de sortie correspondent à la réponse. Les tokens mis en cache peuvent être facturés différemment lorsque le même préfixe est réutilisé. Certains modèles comptabilisent aussi des tokens de raisonnement internes.
Les tarifs ne sont donc pas un simple prix par mot. Ils dépendent du modèle et du type de token.
La fenêtre de contexte
Chaque modèle accepte une quantité maximale combinée d’informations. Cette fenêtre doit accueillir les instructions, l’historique, les fichiers pertinents et la réponse. Dans une interface, une partie peut aussi être réservée aux outils et au fonctionnement interne.
Une fenêtre gigantesque ne garantit pas que chaque détail sera utilisé avec la même précision. Organiser et sélectionner le contexte reste nécessaire.
Un exemple de calcul
Supposons un traitement de 100 documents contenant chacun 2 000 tokens d’entrée et produisant 300 tokens de sortie. Le volume est de 200 000 tokens d’entrée et 30 000 de sortie.
Multipliez ces volumes par le tarif du modèle pour un million de tokens. Ajoutez les appels d’outils éventuels, les nouvelles tentatives et le contexte répété. Ce calcul simple permet de comparer plusieurs architectures avant de développer.
Pourquoi le coût réel dépasse parfois l’estimation
Un agent peut effectuer plusieurs appels pour une seule tâche : planification, recherche, outils, contrôle et réécriture. Une conversation peut renvoyer une partie de l’historique à chaque tour. Un document peut être segmenté et plusieurs passages récupérés.
Mesurez donc le coût par tâche terminée, pas seulement le prix affiché du modèle. Une réponse moins chère mais souvent corrigée peut coûter davantage au final.
Comment réduire l’usage sans perdre la qualité
Résumez les historiques, utilisez une recherche ciblée dans les documents, évitez les instructions répétées et imposez un format de sortie adapté. Réservez les modèles coûteux aux étapes qui nécessitent réellement leur capacité.
Ne compressez pas aveuglément les données critiques : supprimer une clause, une valeur ou un exemple nécessaire peut provoquer une erreur plus coûteuse que les tokens économisés.
Faire une estimation réaliste
Prenez un échantillon de votre contenu français et comptez les tokens avec le modèle ciblé. Ajoutez les instructions permanentes, le format de sortie et les passages de documents récupérés. Estimez ensuite plusieurs scénarios : normal, long et nouvelle tentative.
Pour un produit, ne communiquez pas un nombre de « mots inclus » sans tester la langue et le format. Du code, des tableaux ou des identifiants peuvent être découpés très différemment d’un article.
Suivre les bons indicateurs
Dans un tableau mensuel, distinguez entrée, sortie, cache, outils et coût par fonctionnalité. Ajoutez le taux de réussite et le temps économisé. Une hausse des tokens peut être acceptable si elle réduit fortement les erreurs. À l’inverse, une baisse apparente peut masquer des utilisateurs qui abandonnent ou corrigent manuellement. Le token est une unité de consommation, pas une mesure directe de valeur.
Checklist de validation avant de passer à l’action
Avant d’intégrer cette méthode à votre fonctionnement quotidien, contrôlez les points suivants :
- Cadrage : Les tokens d’entrée et de sortie sont-ils suivis séparément ?
- Fiabilité : Le scénario long et les nouvelles tentatives sont-ils inclus dans l’estimation ?
- Mise en œuvre : Un plafond ou une alerte empêche-t-il une consommation anormale ?
Cette vérification évite de confondre une démonstration convaincante avec un processus réellement exploitable. Testez la méthode sur un cas représentatif, conservez la version utilisée et notez les corrections humaines nécessaires. Après plusieurs essais, vous pourrez distinguer ce qui doit être automatisé, ce qui mérite un gabarit et ce qui doit rester une décision humaine.
Le bon indicateur n’est pas le nombre de réponses générées. C’est la proportion de résultats suffisamment justes, utiles et cohérents pour être intégrés à votre activité sans créer davantage de relecture, de risque ou de confusion.
Ce qu’il faut retenir
Le token est l’unité de base qui relie le texte, les limites techniques et la facture. Il faut distinguer entrée, sortie, cache et raisonnement, puis mesurer l’usage réel sur vos tâches. Les règles approximatives sont utiles pour comprendre ; un compteur et des journaux d’utilisation sont nécessaires pour budgéter.
Passer de l’idée au système
Idevart accompagne les projets d’API avec estimation, suivi et optimisation des volumes. Le but est de choisir l’architecture qui atteint le niveau de qualité attendu avec un coût prévisible.