# Output Filtering

> L'output filtering compacte les sorties bruyantes de commandes et d'outils — logs, builds, tests — en ne gardant que le signal utile avant qu'il n'atteigne le modèle, réduisant les tokens sans perte de sens.

Source: https://tokenade.net/fr/glossary/output-filtering · Updated: 2026-10-07

## Qu'est-ce que l'output filtering ?

L'output filtering est la pratique qui consiste à compacter les sorties de commandes et d'outils avant qu'elles n'entrent dans la [context window](https://tokenade.net/fr/glossary/context-window) du modèle. Quand un agent exécute `git status`, un build, une suite de tests ou `kubectl get`, le résultat brut est verbeux et surtout générique — barres de progression, avertissements répétés, lignes de fichiers inchangés, tableaux décoratifs. L'output filtering réduit tout cela à ce qui compte vraiment : ce qui a changé, ce qui a échoué, ce sur quoi l'agent doit agir.

C'est une optimisation sans risque car le contenu supprimé est réellement à faible valeur informative. Des formats de commandes plus concis (comme `git status --porcelain` ou `kubectl get -o name`) atteignent le même résultat à la source.

## Pourquoi l'output filtering est important en 2026

Il est important parce que les sorties de commandes sont l'une des plus grandes sources de [tokens](https://tokenade.net/fr/glossary/token) gaspillés dans le codage agentique. Un seul log de build bruyant peut représenter des dizaines de milliers de tokens, et comme l'agent relit sa transcription à chaque tour, ce bruit est payé de façon répétée. Le filtrer est souvent la façon la plus rentable et la moins risquée de réduire la facture d'un agent — plus efficace que n'importe quel ajustement de prompt. C'est un levier central dans la [réduction de l'utilisation des tokens](https://tokenade.net/fr/articles/reduce-ai-coding-agent-token-usage).

Deux évolutions de 2026 le rendent plus pertinent, pas moins. D'abord, la documentation d'Anthropic indique que Claude 4.7 et les modèles suivants utilisent un tokenizer qui produit environ 30 % de tokens en plus pour le même texte : le même log de build coûte désormais plus cher à transporter. Ensuite, l'API Claude a ajouté le context editing, qui peut effacer selon des règles les anciens résultats d'outils de l'historique. C'est utile, mais cela agit après que la sortie bruyante a déjà été envoyée au moins une fois ; filtrer à la source signifie que la version gonflée n'entre jamais dans le transcript.

## Quand l'output filtering peut nuire

- **Quand on a besoin de la sortie brute verbatim** — déboguer une ligne de log spécifique implique de vouloir la sortie non filtrée.
- **Avec des règles trop agressives** — un filtrage qui supprime l'erreur réelle avec le bruit est pire qu'aucun filtrage.

## À lire aussi

- [Glossaire : Context window](https://tokenade.net/fr/glossary/context-window)
- [Glossaire : Context compression](https://tokenade.net/fr/glossary/context-compression)
- [Article : Réduire l'utilisation de tokens de Claude Code](https://tokenade.net/fr/articles/reduce-claude-code-token-usage)