Comment réussir la prompt compression en IA ?

La prompt compression consiste à réduire les tokens sans enlever ce qui fait répondre correctement le modèle. Je vais montrer quoi garder, quoi supprimer, où l’utiliser dans un RAG ou un agent IA, et comment mesurer si les coûts baissent sans casser la qualité.

Qu’est-ce que la prompt compression ?

La prompt compression sert à raccourcir un prompt tout en conservant les instructions, les faits importants et le contexte utile.

L’objectif n’est pas de faire court pour faire court. Le vrai sujet, c’est de réduire le nombre de tokens, donc les morceaux de texte que le modèle lit et facture, tout en gardant une sortie fiable. Moins de tokens, c’est souvent moins de coût, moins de latence, et des workflows plus rapides. Un LLM, c’est un grand modèle de langage, il répond en fonction de ce qu’on lui donne. Si on lui donne trop de bruit, il peut aussi répondre avec plus de flou.

Dans les projets IA réels, surtout en automatisation, je vois toujours la même chose. Le prompt grossit vite. On ajoute des consignes système, du contexte client, un historique de conversation, des extraits de documents, des résultats d’outils, des contraintes de format. Au début, ça rassure. Puis ça finit par coûter cher et ralentir toute la chaîne. Un workflow qui prenait 4 secondes passe à 15 secondes, juste parce qu’on envoie un pavé à chaque appel API.

Ce que je cherche à garder, c’est ce qui influence vraiment la réponse :

• L’objectif exact de la tâche.
• Les contraintes non négociables, comme le format attendu ou les règles légales.
• Les données factuelles utiles, pas tout le dossier.
• Les définitions métier, quand elles évitent une mauvaise interprétation.
• Les exemples réellement discriminants, ceux qui changent la décision du modèle.
• Les interdictions importantes, surtout quand une erreur coûte cher.

Ce que je peux souvent enlever, c’est beaucoup moins noble, mais très rentable :

• Les répétitions.
• Les phrases de politesse.
• Les explications longues qui n’aident pas le modèle à décider.
• Le contenu hors sujet.
• Les exemples redondants.
• Le texte de soutien qui ne change rien à la sortie.

Chez un client, le vrai gain n’est pas venu d’un algorithme compliqué. On a juste nettoyé un prompt qui répétait trois fois la même consigne avec des mots différents. Résultat, moins de tokens, des réponses plus stables, et une automatisation plus rapide. C’est souvent aussi simple que ça.

Élément du prompt	À garder ou compresser	Raison
Objectif de la tâche	À garder	C’est ce qui guide toute la réponse du LLM.
Contraintes de format	À garder	Elles évitent les sorties inutilisables dans un workflow.
Répétitions et formulations longues	À compresser	Elles consomment des tokens sans améliorer la décision.

Quelles techniques réduisent les tokens ?

Les techniques les plus utiles sont assez simples à comprendre. Le vrai sujet, c’est de choisir le bon niveau de compression sans casser le sens. J’ai déjà vu un client économiser beaucoup de tokens juste en nettoyant ses consignes, puis perdre en qualité parce qu’il avait supprimé une négation. C’est souvent là que ça se joue.

La réécriture manuelle marche très bien pour les prompts importants. On remplace les phrases longues par des consignes plus directes.

Avant :
Prendre le temps de lire attentivement tout le contexte fourni et répondre uniquement à partir des informations disponibles.

Après :
Répondre uniquement avec le contexte fourni.

C’est simple, lisible, facile à relire. Le problème, c’est l’échelle. Si vous avez dix prompts, ça va. Si vous en avez des milliers, ça devient vite pénible et pas très scalable.

La compression structurelle est très efficace quand on manipule des données structurées. Les listes, tableaux, paires clé-valeur, JSON ou YAML évitent les phrases inutiles. L’idée, c’est de donner au modèle une forme claire, pas un roman.

<p>Avant : Le client s’appelle Nadia, il travaille dans le secteur assurance, il veut automatiser le traitement des emails entrants, et la priorité est de réduire le temps de réponse.</p>

<ul>
  <li>Client : Nadia</li>
  <li>Secteur : Assurance</li>
  <li>Besoin : Automatiser les emails entrants</li>
  <li>Priorité : Réduire le temps de réponse</li>
</ul>

Attention quand même aux noms de champs. Si vous remplacez “Priorité” par “P1” partout, vous gagnez quelques tokens, mais vous perdez du sens. Le modèle comprend mieux les libellés clairs.

Le filtrage par phrase consiste à extraire uniquement les phrases vraiment utiles d’un document long. Ça marche bien dans les systèmes RAG, pour Retrieval Augmented Generation, c’est-à-dire les systèmes qui vont chercher des documents avant de répondre. Le risque, c’est de supprimer une phrase qui semblait secondaire, mais qui change la réponse. Une réserve juridique, une date, une exception, ça paraît petit. Ça peut tout changer.

La compression au niveau des formulations retire les mots de remplissage sans modifier le sens.

Avant :
Il est important de noter que cette règle ne doit être appliquée que dans les cas où le client a donné son accord.

Après :
Appliquer cette règle uniquement si le client a donné son accord.

Le filtrage token-level va plus loin. Il supprime ou réduit au niveau des tokens, les petits morceaux de texte lus par le modèle. C’est plus agressif, moins lisible, et plus risqué. Il faut protéger les mots critiques comme Not, Never, sauf, sans, interdit, avant, après. Ces mots courts portent souvent le sens principal.

Technique	Meilleur usage	Limite principale
Réécriture manuelle	Prompts clés, consignes système	Peu scalable
Compression structurelle	Données structurées, profils, fiches, paramètres	Risque de champs trop cryptiques
Filtrage par phrase	Documents longs, RAG	Peut supprimer un contexte important
Compression des formulations	Nettoyage fin des consignes	Peut affaiblir une nuance
Filtrage token-level	Optimisation très contrainte	Moins lisible, plus risqué

Où l’utiliser dans un RAG ou un agent ?

La prompt compression est surtout utile là où le contexte grossit vite. Dans un RAG, un agent IA, un support client, une analyse documentaire ou une conversation longue, on finit vite avec trop d’informations, trop de bruit, et une facture qui monte. Les techniques vues juste avant ne valent pas grand-chose si on ne sait pas où les appliquer dans le pipeline.

Dans un RAG, pour Retrieval Augmented Generation, le principe est simple : on récupère des morceaux de documents pour aider le modèle à répondre. Mais tout ce qui est récupéré n’a pas la même valeur. Certains passages sont centraux, d’autres répètent la même chose, d’autres sont juste vaguement liés à la question.

J’aime bien appliquer la compression comme un tri intelligent, pas comme un résumé brutal. Il faut garder ce qui aide vraiment la réponse.

• Filtrer les passages faibles, ceux qui parlent du bon sujet mais n’apportent rien.
• Fusionner les doublons, surtout quand plusieurs documents disent la même chose avec des mots différents.
• Garder les phrases qui répondent directement à la requête.
• Préserver les preuves, comme une date, une clause, une source, un montant, une exception.

Le piège, c’est le timing. Si on compresse trop tôt dans un RAG, on peut supprimer une preuve utile avant même que le modèle ait pu la voir. Si on compresse trop tard, on envoie trop de tokens au modèle, donc on paie plus cher et on ralentit tout.

Pour les agents IA, c’est encore plus visible. Un agent accumule des instructions, des observations, des résultats d’outils, des erreurs, parfois trois tentatives ratées qui ne servent plus à rien. Là, la bonne logique, c’est de résumer les anciennes étapes, conserver les décisions prises, garder les sorties d’outils encore utiles, et supprimer les traces qui ne changent plus l’action suivante.

Dans le support client, je l’ai vu plusieurs fois. Un client arrive avec un historique long, des données de compte, un problème actuel et des règles de remboursement. Si on donne tout au modèle, il se noie. La compression utile garde le produit concerné, la date d’achat, le statut du compte, le problème exact, les échanges récents, et la règle de remboursement applicable. Le reste peut être résumé ou ignoré.

Cas d’usage	Ce qu’on compresse	Ce qu’on ne doit pas perdre
RAG documentaire	Passages faibles, doublons, contexte trop large	Preuves, sources, clauses, chiffres clés
Agent IA	Anciennes étapes, erreurs, observations périmées	Décisions prises, objectifs, résultats d’outils utiles
Support client	Historique ancien, messages répétitifs, détails non actionnables	Problème actuel, données de compte, règles applicables
Analyse documentaire	Paragraphes redondants, annexes peu utiles	Arguments, exceptions, références vérifiables

Comment mesurer si ça marche ?

Je mesure une compression de prompt comme je mesurerais une optimisation en prod. Pas seulement avec un compteur de tokens, mais avec ce que ça change vraiment côté coût, vitesse et fiabilité. Un prompt deux fois plus court mais deux fois moins fiable, ce n’est pas une optimisation. C’est une régression maquillée.

Les métriques utiles sont simples, mais il faut les regarder ensemble :

• Nombre de tokens avant et après. Un token, c’est un morceau de texte lu par le modèle, parfois un mot, parfois un bout de mot.
• Taux de compression. Par exemple 40 % de tokens en moins.
• Coût estimé. Surtout si vous avez beaucoup d’appels API.
• Temps de réponse. Moins de contexte peut réduire la latence, mais pas toujours.
• Taux de réponses correctes. C’est la métrique qui évite de se raconter des histoires.
• Respect des consignes. Format, ton, interdictions, contraintes métier.
• Présence des faits clés. Dates, montants, conditions, noms, exceptions.
• Taux d’hallucination observé. C’est-à-dire les infos inventées ou mal déduites.
• Satisfaction utilisateur. Très utile quand le prompt sert un vrai usage métier.

Attention à un détail que je vois souvent oublié chez les clients : la tokenisation dépend du modèle. Le même texte ne donne pas toujours le même nombre de tokens selon le tokenizer, c’est-à-dire l’outil qui découpe le texte pour le modèle. Il faut donc mesurer avec un tokenizer compatible avec le modèle utilisé. Une librairie comme tiktoken peut aider, mais elle reste optionnelle si vous avez déjà les longueurs mesurées.

Ma méthode est assez directe. Je prends un jeu de prompts représentatifs, pas juste trois exemples propres. Je produis une version compressée. Je compare les réponses sur les mêmes questions, avec les mêmes paramètres quand c’est possible. Puis je vérifie à la main les cas sensibles : négations, montants, dates, obligations légales, exclusions, conditions contractuelles. C’est souvent là que la compression casse quelque chose.

# Longueurs déjà mesurées avec un tokenizer compatible
tokens_avant = 1200
tokens_apres = 720

tokens_economises = tokens_avant - tokens_apres
taux_compression = tokens_economises / tokens_avant * 100

print(f"Tokens économisés : {tokens_economises}")
print(f"Taux de compression : {taux_compression:.1f}%")

Après ça, j’automatise une partie du scoring. Par exemple : réponse correcte ou non, présence des faits obligatoires, respect du format attendu, absence d’affirmations interdites. Je garde quand même une revue humaine sur les sujets à risque.

Résultat observé	Interprétation	Action à prendre
Moins de tokens, qualité stable	Compression utile	Déployer progressivement
Moins de tokens, plus d’erreurs	Compression trop agressive	Réinjecter les consignes ou faits clés
Coût réduit, latence identique	Gain financier seulement	Valider si le volume justifie l’effort
Réponses plus rapides, mais format instable	Contraintes trop compressées	Renforcer les règles de sortie
Hallucinations en hausse	Contexte critique supprimé	Remettre les sources et limites explicites

Quel workflow appliquer en production ?

En production, je fais simple : je pars d’un prompt clair, je retire le bruit, je structure les données, je filtre le contexte, je mesure, puis j’itère avec des garde-fous. Ce n’est pas une recette magique. Le bon niveau de compression dépend surtout du risque métier. Pour un brouillon marketing, je peux compresser fort. Pour une réponse juridique, financière ou médicale, je garde beaucoup plus de matière et je contrôle mieux.

Je commence par découper le prompt en blocs. Les instructions système, le rôle, les contraintes de format, les exemples, le contexte, les données utilisateur. Puis je classe chaque bloc selon son utilité réelle.

• Je garde ce qui change le comportement du modèle.
• Je supprime les répétitions et les phrases décoratives.
• Je remplace les longues consignes par des consignes courtes et vérifiables.
• Je transforme les descriptions floues en champs structurés, souvent en JSON, un format clé-valeur facile à lire pour une machine.
• Je limite le contexte récupéré aux passages vraiment utiles.
• Je résume les historiques longs, surtout dans les conversations ou les dossiers clients.
• Je teste sur des cas réels, pas seulement sur deux exemples propres.

Les garde-fous comptent autant que la compression. Je ne supprime jamais les consignes de sécurité. Je garde les contraintes de format, sinon l’automatisation casse derrière. Je protège les négations, parce qu’un “ne pas rembourser” compressé trop vite peut devenir une catastrophe. Et je ne compresse pas agressivement des données juridiques ou financières sans contrôle humain ou tests solides.

J’aime bien versionner les prompts comme du code. Une version non compressée reste disponible pour comparer. C’est encore plus important quand plusieurs automatisations ou agents dépendent du même prompt. J’ai déjà vu un petit changement “inoffensif” dans un prompt partagé casser trois workflows derrière. Pas drôle à débugger.

Dans n8n, je ferais un mini workflow comme ça : un nœud récupère le contexte, un nœud filtre les passages utiles, un nœud reformate en JSON compact, un nœud envoie au LLM, le modèle de langage, puis un dernier nœud logge les tokens, le coût et un score qualité.

Étape	Objectif	Risque à surveiller
Inventorier les blocs	Savoir ce qui compose le prompt	Supprimer une consigne critique
Filtrer le contexte	Réduire les tokens inutiles	Perdre une information décisive
Structurer en JSON	Rendre les données plus compactes	Mal nommer les champs
Tester sur cas réels	Mesurer la qualité en conditions normales	Optimiser sur des exemples trop propres
Logger coût et qualité	Suivre l’impact en production	Compresser sans preuve de gain

Et si votre meilleur prompt était simplement plus court ?

La prompt compression, ce n’est pas juste couper du texte. C’est garder ce qui aide vraiment le modèle à répondre, et retirer le reste. Les meilleurs gains viennent souvent d’un mix simple : consignes plus nettes, données structurées, contexte filtré, historiques résumés et mesure sérieuse derrière. Sur un RAG, un agent IA ou un workflow de support, ça peut vite réduire les coûts et accélérer les réponses. Je fais juste attention à ne pas compresser les éléments critiques : négations, règles métier, montants, dates, preuves. Le bénéfice pour vous est clair : des automatisations IA plus rapides, moins chères et plus fiables.

FAQ

• Qu’est-ce que la prompt compression ?
  La prompt compression consiste à raccourcir un prompt sans retirer les informations nécessaires à la réponse. On réduit les répétitions, les phrases inutiles et le contexte faible, tout en gardant les consignes, les faits importants et les contraintes métier.
• Est-ce que la prompt compression réduit vraiment les coûts IA ?
  Oui, quand elle réduit le nombre de tokens envoyés au modèle. Moins de tokens veut dire moins de coût et souvent moins de latence. Le point important, c’est de vérifier que la qualité de réponse reste stable après compression.
• Quelle technique de compression utiliser en premier ?
  Je commence presque toujours par la réécriture manuelle et la structuration. C’est simple, lisible et très efficace. Ensuite seulement, je filtre les phrases ou je résume le contexte si le prompt reste trop long.
• La prompt compression est-elle utile pour un système RAG ?
  Oui, surtout quand le RAG récupère trop de passages. La compression aide à garder les extraits utiles, supprimer les doublons et limiter le bruit. Il faut juste éviter de supprimer les preuves ou les phrases qui changent le sens de la réponse.
• Quels sont les risques d’un prompt trop compressé ?

Le principal risque, c’est de perdre une nuance importante. Une négation, une date, une exception ou une règle métier supprimée peut changer toute la réponse. C’est pour ça que je mesure toujours la qualité, pas seulement le nombre de tokens économisés.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, analytics engineering, automatisation no/low code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent industrialiser leurs usages data et IA sans empiler des usines à gaz. J’ai travaillé pour des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez mettre en place des workflows IA plus propres, mesurables et rentables, contactez-moi.