Comment réduire vos coûts avec la prompt compression ?

La prompt compression réduit les tokens envoyés au modèle sans jeter le contexte utile. Je l’utilise surtout sur les RAG, agents IA, support client et analyse documentaire. Le vrai sujet c’est quoi couper, comment mesurer la perte, et jusqu’où compresser avant d’abîmer la réponse.

Qu’est-ce qu’on compresse vraiment ?

Compresser un prompt, ce n’est pas le rendre “petit” pour le plaisir. C’est le raccourcir tout en gardant ce qui permet au modèle de comprendre la tâche, respecter les consignes et produire une réponse fiable.

Ce qu’on compresse vraiment, ce sont les tokens. Un token, c’est un morceau de texte lu par le modèle. Ça peut être un mot, une partie de mot, un signe de ponctuation. Plus votre prompt contient de tokens, plus ça coûte cher, plus la réponse peut être lente, et plus vous remplissez la fenêtre de contexte. La fenêtre de contexte, c’est la quantité maximale d’informations que le modèle peut garder “sous les yeux” pendant une requête.

La compression joue donc sur trois leviers très concrets : le coût, la latence et la place disponible dans le contexte. Si vous envoyez 20 pages au modèle alors que 2 paragraphes suffisent, vous payez pour du bruit. Et parfois ce bruit dégrade même la réponse, parce que le modèle doit arbitrer entre trop d’informations.

Mais attention, compresser ne veut pas dire résumer au hasard. Ni supprimer tout ce qui semble long. J’ai souvent vu des prompts système gonflés par des formulations polies, des répétitions et des explications qui ne changent rien à la sortie. Le problème n’est pas la longueur en soi. Le problème, c’est la longueur inutile.

Le bon angle, c’est de trier. Je garde le contexte utile. Je protège les instructions critiques. Je conserve les contraintes métier, celles qui changent vraiment la décision ou le format attendu. Je garde les exemples seulement s’ils aident le modèle à mieux répondre. Et je coupe les détails décoratifs, les phrases de confort, les doublons, les “sois très intelligent et fais de ton mieux” qui ne servent à rien.

La compression vaut surtout le coup quand le prompt revient souvent, ou quand le contexte devient lourd :

• RAG, quand on injecte des extraits de documents dans le prompt.
• Agents IA, quand plusieurs appels s’enchaînent dans un même workflow.
• Support client, avec historiques de conversation et bases de connaissance.
• Analyse de documents, contrats, comptes rendus, tickets, emails longs.
• Workflows automatisés, où chaque token se répète à grande échelle.
• Prompts réutilisables, surtout en production.

La vraie question devient donc simple : Qu’est-ce que je peux enlever sans perdre en qualité ? Et là, on peut passer aux techniques concrètes.

Quelles techniques utiliser ?

La meilleure approche, c’est de mixer plusieurs techniques, mais sans tout mélanger. Chaque compression a son rôle. J’ai vu des prompts divisés par deux juste en nettoyant le texte, sans modèle spécialisé, sans pipeline compliqué.

Manual prompt rewriting, c’est la méthode la plus simple. Je reprends le prompt à la main et j’enlève les répétitions, les mots de remplissage, les explications inutiles. C’est parfait pour les prompts système et les templates qu’on réutilise souvent. Le problème, c’est que ça scale mal. Si vous avez 500 prompts ou des contenus qui changent tout le temps, ça devient vite pénible.

Structural compression, c’est le fait de remplacer du texte long par des formats compacts. Listes, tableaux, paires clé-valeur, JSON ou YAML. Le modèle comprend très bien ces formats, souvent mieux qu’un pavé flou. Un point important quand même : les noms de champs doivent rester explicites. “usr_req” coûte moins cher que “user_request”, mais vous perdez en clarté, et parfois en qualité.

Sentence-level filtering, c’est supprimer des phrases entières peu utiles. Je l’utilise surtout dans les RAG, les rapports, les politiques internes et les conversations longues. Un RAG, c’est un système qui va chercher des documents pour les donner au modèle avant de répondre. Le risque ici, c’est de couper une phrase qui ne répond pas directement à la question, mais qui aide à comprendre le contexte.

Phrase-level compression, c’est plus fin. On garde l’idée, mais on raccourcit la phrase. “Vous devez répondre de manière concise, claire et sans ajouter d’informations non demandées” devient “Répondez clairement, sans ajout inutile”. Même sens, moins de tokens.

Token-level filtering, c’est plus agressif. On enlève des mots ou morceaux de mots jugés peu utiles. C’est efficace sur de très longs contextes, mais beaucoup moins lisible. Il faut absolument protéger les mots critiques comme “pas”, “sauf”, “jamais”, “uniquement”. Sinon, vous inversez une règle sans vous en rendre compte.

Technique	Meilleur usage	Gain attendu	Risque principal
Manual prompt rewriting	Prompts système et templates stables	Moyen à fort	Peu scalable
Structural compression	Données structurées, consignes récurrentes	Fort	Champs trop cryptiques
Sentence-level filtering	RAG, rapports, politiques, longues conversations	Fort	Perte de contexte de soutien
Phrase-level compression	Consignes longues mais importantes	Moyen	Sens légèrement appauvri
Token-level filtering	Très longs contextes, optimisation avancée	Très fort	Perte de lisibilité ou inversion du sens

Où la compression fait vraiment gagner ?

La compression fait vraiment gagner quand vous envoyez souvent le même type de contexte au modèle, ou quand vos prompts deviennent longs par accumulation. Pas quand vous avez trois lignes de consigne une fois par semaine. Là, le gain est marginal. Le vrai sujet, c’est la répétition et le volume.

Je le vois surtout dans les systèmes RAG, c’est-à-dire les systèmes qui vont chercher des passages dans une base documentaire avant de répondre. Le réflexe classique, c’est d’envoyer au LLM les 5 ou 10 chunks récupérés. Sauf que tous les passages ne méritent pas d’être envoyés. Parfois, une seule phrase porte l’information utile, et le reste ajoute du bruit, du coût, et parfois même de la confusion.

• En RAG, je peux filtrer les phrases les plus utiles, réduire les chunks, supprimer les répétitions, ou garder uniquement les définitions, chiffres, clauses et exceptions importantes.
• Dans les agents IA, l’historique d’actions, les observations, les outils disponibles et les traces opérationnelles grossissent très vite. Au bout de quelques appels, le contexte ressemble à un journal de bord illisible.
• En support client, les longues conversations, les fiches clients, les règles internes et les procédures prennent beaucoup de place. Tout n’a pas la même valeur pour répondre au prochain message.
• En analyse documentaire, les contrats, politiques, rapports et bases de connaissance peuvent exploser la fenêtre de contexte. Là, compresser avant génération devient presque obligatoire.

Les approches comme LLMLingua et LongLLMLingua montrent bien que ce n’est pas juste une astuce bricolée. Ces méthodes utilisent des modèles plus petits ou des stratégies de sélection pour garder les tokens les plus informatifs. Un token, c’est un morceau de texte facturé et traité par le modèle. Leur intérêt est surtout visible sur les contextes longs et les scénarios RAG, où on veut réduire sans perdre le sens.

Le point important, c’est de ne pas compresser pour compresser. Si vous retirez une condition juridique, une exception métier ou une préférence client, vous économisez quelques centimes et vous créez un mauvais résultat. J’ai déjà vu ça chez un client support : le prompt était plus court, oui, mais l’agent oubliait une règle de remboursement sur dix. Mauvais calcul.

Une compression moyenne mais stable vaut souvent mieux qu’une compression spectaculaire qui casse une réponse sur dix. C’est moins sexy, mais c’est ce qui tient en production.

Comment mesurer sans casser la qualité ?

Je le dis clairement : je ne mesure jamais une prompt compression uniquement avec un taux de réduction de tokens. C’est tentant, parce que c’est simple. Mais si vous gagnez 60 % de tokens et que le modèle oublie une exception métier, vous n’avez pas optimisé. Vous avez cassé le système.

Je regarde toujours plusieurs métriques ensemble, parce que la compression touche au coût, à la vitesse, mais aussi à la qualité réelle de la réponse. Les indicateurs utiles sont ceux-là :

• Nombre de tokens avant-après : Pour voir ce qui a vraiment été retiré.
• Pourcentage de compression : Pour mesurer le gain brut, sans le confondre avec le succès.
• Temps de réponse : Pour vérifier si la compression réduit vraiment la latence.
• Coût estimé : Pour traduire les tokens économisés en euros, pas juste en score technique.
• Exactitude de la réponse : Pour contrôler si la réponse reste factuellement correcte.
• Respect des consignes : Pour vérifier que le modèle suit encore le format, le ton, les règles métier.
• Taux d’hallucination : Pour repérer les réponses inventées ou trop confiantes.
• Couverture des informations importantes : Pour voir si les points clés sont encore présents.
• Satisfaction utilisateur : Pour savoir si la réponse reste utile dans la vraie vie.

Sur un RAG, c’est encore plus sensible. Un RAG, c’est un système qui récupère des documents avant de répondre, comme une base de connaissances branchée sur un modèle. Là, je mesure aussi la fidélité à la source, la précision des citations si le système en produit, et surtout le risque de supprimer un passage qui justifie la réponse. J’ai déjà vu un client compresser des extraits juridiques en retirant “sauf si”. Résultat : réponse plus courte, mais complètement fausse.

Le bon réflexe, c’est de créer un petit jeu de tests représentatif. Pas besoin de 500 cas au départ. Je prends des cas faciles, des cas limites, et des cas sensibles. Puis je compare le prompt complet avec le prompt compressé, sur les mêmes questions, avec les mêmes documents, et idéalement le même modèle.

Les mots à ne jamais supprimer à la légère sont souvent les plus petits. Les négations, conditions, exceptions, montants, dates, noms propres, contraintes légales. Un “ne pas”, un “avant le 31 mars”, un “sauf validation”, ça peut changer toute la réponse.

Bon indicateur	Piège courant
Comparer coût, latence et qualité ensemble.	Se satisfaire d’un gros taux de compression.
Tester sur des cas réels et sensibles.	Tester seulement sur des exemples faciles.
Vérifier la fidélité aux sources en RAG.	Compresser les preuves qui soutiennent la réponse.
Surveiller les exceptions, dates et montants.	Supprimer les petits mots qui portent le sens.

Quel workflow appliquer simplement ?

Je pars toujours du plus simple : je ne compresse pas tout. Je regarde d’abord les prompts qui coûtent vraiment quelque chose. Ceux qui tournent souvent, ceux qui embarquent beaucoup de contexte, ou ceux qui appellent un modèle cher. C’est là que les gains sont rapides, sans passer trois jours à optimiser un prompt qui tourne deux fois par mois.

Mon workflow ressemble à ça. Je prends les prompts les plus fréquents, puis je les découpe en trois blocs : ce qui est indispensable, ce qui se répète partout, et ce qui est optionnel. Souvent, on découvre des phrases “de confort” qui n’apportent rien. Ou des consignes répétées dans le prompt système, le template, puis le contexte. Ça arrive tout le temps chez mes clients.

Bloc	Ce que je fais
Indispensable	Je garde intact, surtout les règles métier, les contraintes légales, les formats de sortie.
Répétitif	Je factorise dans un template plus court, avec des formulations stables.
Optionnel	Je supprime, ou je ne l’ajoute que quand le cas le demande.

Ensuite, j’applique une compression douce sur les templates. Rien de magique. Je raccourcis les phrases, je retire les exemples inutiles, je remplace les longs paragraphes par des règles claires. Pour les contextes longs, comme des documents, tickets support ou historiques de conversation, je passe à une compression plus dynamique : résumé ciblé, extraction des passages utiles, ou limitation aux éléments liés à la question.

Le point important, c’est de ne jamais faire ça “au feeling”. Je versionne les prompts. Je mesure avant et après. Je teste sur un jeu stable de questions, toujours le même, pour comparer les réponses. Sinon, on économise 30% de tokens et on casse une règle métier sans s’en rendre compte.

# Pseudo-code Python lisible
# Installer une librairie de tokenisation comme tiktoken

original = charger_prompt("prompt_v1.txt")
compresse = charger_prompt("prompt_v2.txt")

tokens_original = compter_tokens(original)
tokens_compresse = compter_tokens(compresse)

reduction = (tokens_original - tokens_compresse) / tokens_original * 100
afficher(reduction)

questions_test = charger_questions("jeu_stable.json")

pour chaque question dans questions_test:
    reponse_v1 = appeler_modele(original, question)
    reponse_v2 = appeler_modele(compresse, question)
    comparer(reponse_v1, reponse_v2)

Je déploie ensuite progressivement. D’abord en interne, puis sur un petit pourcentage du trafic, avec un rollback prêt. Le rollback, c’est juste la capacité à revenir à l’ancienne version du prompt si les réponses se dégradent. C’est simple, mais ça évite les sueurs froides.

• Consignes critiques conservées
• Contexte métier conservé
• Négations protégées
• Tests passés
• Coût mesuré
• Rollback possible

Et si le meilleur prompt était juste plus propre ?

La prompt compression n’est pas une astuce pour faire court à tout prix. C’est une façon de nettoyer ce qu’on envoie au modèle, de garder le contexte qui compte et de supprimer le bruit qui coûte cher. Je commencerais toujours par les prompts réutilisés, les systèmes RAG, les agents IA et les longs historiques de support. Ensuite je mesure, je compare, je protège les informations sensibles au sens. Quand c’est bien fait, vous gagnez sur trois fronts : moins de tokens, moins de latence, et des réponses plus stables. Le bénéfice pour vous est simple : une IA moins chère, plus rapide, et plus maîtrisée.

FAQ

• Qu’est-ce que la prompt compression ?

  La prompt compression consiste à réduire la taille d’un prompt tout en gardant les informations nécessaires pour que le modèle réponde correctement. L’objectif est de consommer moins de tokens, réduire les coûts et accélérer les réponses sans perdre le contexte important.

• Est-ce que la prompt compression dégrade les réponses ?

  Elle peut les dégrader si elle est trop agressive. Le risque principal c’est de supprimer une exception, une négation, une contrainte métier ou une information qui semblait secondaire mais qui change la réponse. C’est pour ça que je conseille toujours de tester prompt complet contre prompt compressé.

• Quelle technique de prompt compression utiliser en premier ?

  Je commence souvent par la réécriture manuelle et la compression structurelle. C’est simple, lisible et efficace sur les prompts système, les templates et les données client. Le filtrage par phrase ou par token devient intéressant quand on traite de longs documents, des conversations ou des systèmes RAG.

• Pourquoi la prompt compression est utile dans un RAG ?

  Dans un RAG, on récupère souvent plusieurs passages avant de les envoyer au modèle. Tous ne sont pas utiles au même niveau. Compresser ou filtrer ces passages permet de garder les éléments qui répondent vraiment à la question, tout en réduisant les tokens et la latence.

• Comment mesurer une bonne compression de prompt ?

  Je regarde le taux de réduction de tokens, le coût, le temps de réponse, mais aussi la qualité finale. Une bonne compression conserve l’exactitude, les consignes, les contraintes et les informations critiques. Si le prompt coûte moins cher mais produit plus d’erreurs, ce n’est pas une optimisation.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des équipes sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA en entreprise et le SEO/GEO. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez industrialiser vos usages IA sans exploser vos coûts ni perdre le contrôle sur la qualité, je peux vous aider. Contactez-moi.