La première fois qu’un client nous a signalé qu’un résumé automatique s’arrêtait en plein milieu d’une phrase sur ses articles les plus longs, le diagnostic a pris cinq minutes : l’article dépassait la fenêtre de contexte du modèle utilisé, et le texte était tronqué silencieusement avant même d’atteindre le prompt. Ce type de bug est fréquent, et il commence toujours par une mauvaise compréhension de ce qu’est un token.
Cet article pose les bases nécessaires pour manipuler des contenus WordPress avec un modèle de langage sans mauvaise surprise : ce que mesure réellement un token, comment estimer la taille d’un article, et comment le découper sans casser le sens.
Un token n’est ni un mot ni un caractère
Un LLM ne traite pas le texte lettre par lettre ni mot par mot : il le découpe en tokens, des fragments de sous-mots déterminés par le tokenizer du modèle. Le mot « développement » peut ainsi être découpé en plusieurs tokens, tandis qu’un mot court et fréquent comme « le » n’en occupe qu’un seul. En français, on compte en moyenne environ quatre caractères par token, un peu plus qu’en anglais à cause des accents et de la morphologie plus riche de la langue.
Cette moyenne reste approximative : la ponctuation, les balises HTML laissées dans le texte et les caractères spéciaux consomment aussi des tokens, parfois plus que prévu. Un article WordPress exporté avec ses balises <p> et <h2> encore présentes coûte systématiquement plus de tokens que son équivalent en texte brut.
Pourquoi la fenêtre de contexte limite tout, pas seulement l’entrée
La fenêtre de contexte d’un modèle est la quantité totale de tokens qu’il peut traiter en une seule requête, et elle couvre à la fois le texte envoyé et la réponse générée. Un modèle avec une fenêtre de 128 000 tokens ne garantit pas 128 000 tokens de contenu en entrée : si vous demandez un résumé de 2 000 tokens, il vous reste 126 000 tokens pour tout le reste, y compris les instructions système et l’historique de conversation le cas échéant.
Pour un article WordPress classique de 1 500 mots, on reste très loin de ces limites. Le problème apparaît sur les contenus longs : guides complets, pages piliers de plusieurs milliers de mots, ou traitement en lot de plusieurs articles concaténés dans un seul appel.
Estimer la taille d’un article avant de l’envoyer
Plutôt que de deviner, on peut estimer le nombre de tokens d’un contenu WordPress directement en PHP, avec une approximation suffisante pour décider s’il faut découper ou non.
function wpm_estimate_tokens( $post_id ) {
$content = get_post_field( 'post_content', $post_id );
$content = wp_strip_all_tags( $content );
$content = html_entity_decode( $content );
// Approximation : environ 4 caractères par token en français.
$char_count = mb_strlen( $content );
return (int) ceil( $char_count / 4 );
}Cette estimation reste volontairement grossière. Pour un chiffrage exact, il faut passer par l’API de comptage de tokens du fournisseur utilisé, qui applique le tokenizer réel du modèle plutôt qu’une moyenne.
Découper par structure, pas au nombre de caractères fixe
La méthode la plus simple pour découper un texte long — couper tous les 2 000 caractères — casse régulièrement les phrases et les listes en plein milieu, ce qui dégrade la qualité de tout traitement ultérieur. Sur du contenu WordPress, la structure des balises <h2> et <h3> offre des points de coupe naturels bien plus fiables.
- Parser le contenu de l’article pour repérer chaque section délimitée par un titre
h2. - Regrouper les sections tant que la limite de tokens fixée n’est pas atteinte.
- Démarrer un nouveau segment dès qu’une section ferait dépasser le budget, même si le segment précédent est plus court que prévu.
- Conserver le titre de l’article en tête de chaque segment, pour garder le contexte quand les segments sont traités indépendamment.
Le cas des tableaux et des listes longues
Un tableau comparatif de vingt lignes ou une liste à puces de quarante éléments doit rester dans un seul segment autant que possible : le couper au milieu produit des résumés ou des traductions incohérents, où une ligne de tableau se retrouve orpheline de son en-tête.
Ce que nous vérifions systématiquement
Sur les projets où le découpage automatique est en production, nous avons ajouté un contrôle simple : si le nombre de segments dépasse dix pour un seul article, une alerte est envoyée à l’équipe éditoriale, car cela signale presque toujours un article qui gagnerait à être scindé en plusieurs pages plutôt que traité comme un bloc unique par l’IA.
Le découpage par tokens n’est pas qu’une contrainte technique : il révèle souvent des articles trop longs qui mériteraient d’être restructurés pour les lecteurs humains aussi.
En résumé
Comprendre les tokens évite deux écueils opposés : sous-estimer la taille d’un contenu et se heurter à des erreurs de dépassement de contexte, ou sur-découper un texte court et perdre en cohérence ce qu’on gagnait en sécurité. Un découpage aligné sur la structure éditoriale de l’article, plutôt que sur un nombre de caractères arbitraire, reste la méthode la plus fiable sur des contenus WordPress.
