Diète de tokens : Caveman vs RTK pour réduire coûts et latence des LLM

Chaque token généré par un LLM, c’est trois choses à la fois : du coût, de la latence et du bruit potentiel. Quand vous passez de “tests” à des automatisations en production (CRM, support, reporting, extraction), l’optimisation des outputs devient un sujet de marge, pas un détail technique.

Et c’est cohérent avec un changement plus large : en 2026, l’IA ne se vend plus comme “un gain de productivité”, mais comme un levier de valeur (qualité, fiabilité, scalabilité). La diète de tokens est exactement dans cette logique.

Dans ce guide, on compare deux écoles simples et efficaces pour forcer le modèle à aller droit au but :

Caveman : minimaliste mais lisible par un humain.
RTK (Return to Keywords) : minimalisme extrême, orienté data/pipeline.

Pourquoi ce sujet est important

1) Vos coûts explosent “en silence”

Sur la plupart des APIs, la facture dépend surtout du volume de tokens en entrée + en sortie. Or, l’entrée est souvent contrainte (contexte, consignes, données), mais la sortie est pilotable.

2) La latence suit le nombre de tokens

La génération est séquentielle : plus vous demandez (ou laissez produire) de tokens, plus le temps de réponse augmente. Dans une automatisation (n8n, Make, scripts), ça devient vite un goulot.

3) La longueur crée des erreurs

Un output trop long :

augmente les risques d’ambiguïtés,
dilue les points importants,
complique le parsing,
rend les contrôles qualité plus difficiles.

Ce qu’il faut comprendre : “réduire” n’est pas de rendre l’IA stupide. L’objectif est de conserver l’information utile en retirant :

le remplissage (politesse, transitions),
les répétitions,
la grammaire non nécessaire selon le destinataire.

La bonne question n’est pas “comment raccourcir ?”, mais :

Qui consomme l’output : un humain ou une machine ?

C’est ce qui détermine Caveman vs RTK.

1) Le style Caveman : l’efficacité brute pour les humains

Le principe

On garde une structure logique, mais on coupe :

articles, pronoms, formules,
phrases longues,
connecteurs inutiles.

On vise une structure Sujet + Action + Objet, en phrases courtes.

Exemple

Normal : “Le moteur semble perdre en puissance. Vous devriez vérifier les bougies, puis réessayer.”

Caveman : “Moteur perte puissance. Vérifier bougies. Nettoyer/remplacer. Tester.”

Quand l’utiliser

instructions pour un humain “pressé”
checklists d’action
résumés opérationnels
comptes-rendus internes (réunions, tickets)

Prompt prêt à l’emploi (Caveman)

Réponds en phrases courtes. Pas de politesse. Pas d'intro.
- 1 idée = 1 ligne.
- Verbes d'action. Pas de blabla.
- Max: 6 lignes.
Format:
PROBLÈME: …
CAUSES: …
ACTIONS: …
RISQUES: …

Ce que vous gagnez

En pratique, Caveman permet souvent une réduction significative sans perdre la lisibilité. C’est le meilleur compromis quand l’output est lu par un humain.

2) L’approche RTK : le minimalisme absolu pour la data

Le principe

RTK supprime presque toute grammaire. On produit :

des mots-clés
des paires clé: valeur
des listes compactes
des formats faciles à parser

L’output devient un objet exploitable (classification, extraction, routage).

Exemple

RTK : Moteur: perte_puissance | cause: bougies_encrassées | action: nettoyer/remplacer | priorité: haute

Ou, encore plus compact : perte_puissance; bougies_encrassées; nettoyer; retester

Quand l’utiliser

sortie injectée dans un workflow (n8n, Make)
tagging / catégorisation
extraction d’entités (nom, email, statut, priorité)
décisions de routage (selon type de demande)
scoring (lead chaud/froid, urgence)

Prompt prêt à l’emploi (RTK)

Règle de sortie: RTK (Return to Keywords).
- Aucune phrase.
- Uniquement paires clé:valeur, séparées par " | ".
- Valeurs courtes (1 à 5 mots). Pas d'explication.
- Si inconnu: "NA".
Schéma:
type:...
urgence:...
cause:...
action:...
next_step:...

Ce que vous gagnez

RTK est idéal quand l’output est un composant d’un système plus large. Moins de tokens, moins de latence, et surtout : moins d’interprétation humaine.

Comment choisir : une règle simple

Caveman si…

un humain doit lire et agir
vous voulez une consigne claire et rapide
vous avez besoin d’un minimum de contexte

RTK si…

une machine doit parser et exécuter
vous faites du tri, du routage, du tagging
vous visez la performance et la robustesse

Le meilleur des deux mondes : le format hybride

Dans beaucoup d’organisations, l’output sert à la fois :

à déclencher une action automatique,
à être lu ensuite par une personne.

Dans ce cas, combinez les deux blocs :

Bloc 1 : RTK (pour la machine)
Bloc 2 : Caveman (pour l’humain)

Exemple :

RTK: type:incident | urgence:haute | cause:bougies | action:remplacer | next_step:test
HUMAN: Moteur perte puissance. Remplacer bougies. Tester.

Applications concrètes en PME, OBNL, institutions

1) Support client : tri automatique

RTK extrait : type de demande, urgence, produit, intention
le workflow route vers la bonne équipe
Caveman fournit une note interne actionnable

2) CRM : qualification de leads

RTK : secteur, budget, échéance, probabilité, prochaine action
votre CRM reçoit des champs propres
votre équipe lit un résumé Caveman en 3 lignes

3) Comptes rendus : de “texte long” à “décisions”

Caveman pour décisions / actions / responsables
RTK pour tags (projet, priorité, risques, échéance)

Points de vigilance

1) Trop compresser = ambiguïté

Plus c’est court, plus chaque mot compte. Si vos clés ne sont pas strictes, vous obtenez du flou.

Solution : définir un schéma stable (clés fixes) + valeurs limitées.

2) RTK sans contrôle de schéma, ça casse

Si vous parsez “à l’œil” (regex sur du texte variable), ça casse.

Solution : utilisez un séparateur unique (|) et des clés fixes (urgence:, action:). Testez sur 30–50 cas.

3) Perte de nuance (volontaire)

Caveman et RTK ne sont pas faits pour :

persuasion,
pédagogie,
communication externe.

Solution : réservez ces formats aux outputs opérationnels.

Ce que les organisations devraient faire maintenant

Mesurer : sur 7 jours, loggez tokens_in / tokens_out par scénario.
Identifier les workflows où la sortie est “trop bavarde” (support, extraction, résumé).
Standardiser 2 gabarits :
- 1 prompt Caveman (humain)
- 1 prompt RTK (machine)
Mettre des garde-fous :
- limite de lignes
- clés obligatoires
- valeur “NA” si incertain
Industrialiser :
- une petite librairie interne de formats (par cas d’usage)
- tests réguliers sur des exemples réels

Conclusion

La “diète de tokens” n’est pas un hack. C’est une discipline : définir un format de sortie adapté au destinataire.

Caveman : rapide, structuré, idéal pour les humains pressés.
RTK : compact, structuré, idéal pour l’automatisation.

Les équipes qui maîtrisent ces formats gagnent sur trois axes : coûts, latence, fiabilité des workflows. Et à l’échelle d’une organisation, ça se traduit en marge et en capacité de livrer plus intelligemment — pas juste plus vite.

Vous souhaitez appliquer ces idées à votre organisation ? FD Stratégies peut vous accompagner dans la création de solutions numériques, l’automatisation de vos processus et la structuration de votre présence en ligne.