💳 Flow Tokens - Pourquoi l’optimisation des tokens est un problème de flux, pas de vocabulaire

le 21 juin 2026

L’essor des agents IA a remis un sujet au centre de nombreuses architectures logicielles : le coût du contexte.

Lorsqu’un agent exécute un workflow, il ne consomme pas uniquement un prompt utilisateur. Il consomme également une grande quantité de données annexes :

• logs d’exécution
• sorties de commandes CLI
• résultats d’outils
• traces de debugging
• chunks issus de RAG
• fichiers bruts ou semi-structurés

Dans la pratique, ce contexte représente souvent le coût principal du workflow, bien avant la phase de raisonnement du modèle.

La question devient alors :

Comment réduire la consommation de tokens sans dégrader la qualité du signal transmis au modèle ?

Une intuition fréquente consiste à optimiser le vocabulaire : raccourcir des mots, abréger certains concepts métier, condenser artificiellement les textes.

Cette intuition est généralement mauvaise.

L’optimisation des tokens n’est pas un problème lexical.

C’est un problème de flux.

Le vrai problème : un contexte non maîtrisé

Dans de nombreux systèmes, les données entrent dans la chaîne IA sous la forme d’une immense chaîne de caractères.

Prenons un exemple classique.

Un agent doit analyser le résultat d’une commande Symfony ou Composer.

La sortie peut contenir :

• des lignes de debug répétitives
• des timestamps
• des séquences ANSI
• des stack traces
• des lignes de progression
• des informations réellement utiles

Pour un humain, la séparation entre bruit et signal est immédiate.

Pour un LLM, tout est initialement équivalent.

Chaque caractère peut devenir un token.

Chaque token a un coût.

Chaque coût consomme une partie de la fenêtre de contexte.

Le problème n’est donc pas seulement la taille du texte.

Le problème est l’absence de structure dans la manière dont les données circulent.

Token optimization is stream discipline

La thèse de cet article est simple :

Token optimization is not word shortening. Token optimization is stream discipline.

Autrement dit :

ce qui compte n’est pas la manière dont les mots sont orthographiés, mais la manière dont les données se déplacent dans le système.

Une architecture orientée flux permet de :

• nettoyer les données
• segmenter les données
• mesurer leur coût
• compresser les répétitions
• appliquer un budget explicite

Ce changement de perspective est important.

Nous ne cherchons plus à compresser des mots.

Nous cherchons à contrôler un flux.

Flow comme modèle d’orchestration

C’est précisément l’angle exploré avec Flow.

Flow n’est pas seulement un moteur d’exécution de tâches.

Flow peut être vu comme une couche d’orchestration du mouvement de la donnée.

Les données peuvent circuler :

• comme un pipe
• comme un stream
• comme des chunks
• comme un contexte mesurable
• comme un contexte budgeté

Ce modèle est particulièrement intéressant pour les workflows agentiques, car un agent consomme rarement des objets métier fortement typés.

Il consomme essentiellement du texte.

Ce texte devient alors une ressource qu’il faut piloter.

Démonstration : flow-pipe

Pour explorer cette idée, j’ai construit une démonstration Symfony disponible ici :

flow-pipe repository

Le projet expose une commande console :

php bin/console app:flow-token-demo \
  --input=flow-engine-log --show-chunks

Le but n’est pas d’appeler un LLM.

Le but est de simuler localement une pipeline de traitement de contexte.

Le pipeline suit huit étapes :

1. Charger une source
2. Retirer les séquences ANSI
3. Supprimer le bruit
4. Normaliser les espaces
5. Découper en chunks
6. Compresser
7. Appliquer un budget
8. Produire une sortie exploitable

Une pipeline déclarative

La pipeline peut être exprimée sous forme déclarative :

source |> strip_ansi |> remove_noise |> normalize_whitespace
  |> chunk:300 |> compress |> budget:1000 |> sink

Cette notation permet de lire le pipeline de gauche à droite.

Chaque étape transforme la précédente.

L’intérêt est double :

• meilleure lisibilité
• meilleure extensibilité

L’ajout d’une nouvelle opération ne nécessite pas de modifier une structure conditionnelle centrale.

Chaque opération devient un composant autonome.

Trois sens du pipe

Dans cette démonstration, le symbole |> apparaît à trois niveaux.

1. DSL d’expression

Premier niveau : le pipe représente un langage déclaratif lisible par l’humain.

source |> compress |> sink

2. Pipe operator de PHP 8.5

PHP 8.5 introduit nativement l’opérateur pipe.

Il permet une composition de callables plus explicite.

Exemple :

yield $step |> (fn ($step) => new ClosureJob(...));

Le code devient plus proche de la lecture du DSL.

3. Composition runtime avec Flow

Troisième niveau : la composition effective des jobs dans Flow.

Chaque transformation devient un job appliqué sur un contexte partagé.

C’est cette couche qui exécute réellement la pipeline.

Inspiration : Pratt parsing

La partie parsing du DSL s’inspire directement des nouveaux expression parsers de Twig 4.

Au lieu d’avoir un parseur monolithique, chaque opération possède :

• son nom
• sa logique de parsing
• sa logique d’exécution

Cette approche permet d’éviter un parser central surchargé.

La pipeline devient extensible par design.

Résultat

Prenons la fixture flow-engine-log.

Avant transformation :

• 17 398 caractères
• ~ 4 488 tokens estimés

Après pipeline :

• 334 caractères
• ~ 88 tokens estimés

Soit environ :

98 % de réduction

Le point important n’est pas seulement le ratio.

Le point important est que le vocabulaire métier reste intact.

Les concepts :

• flow
• stream
• pipeline
• source
• sink

n’ont pas été raccourcis.

Ce qui a disparu, c’est :

• le bruit
• les répétitions
• les lignes sans valeur

Autrement dit :

le signal est resté.

Le bruit a disparu.

Signal vs bruit

Une deuxième fixture, flow-lexicon, est volontairement peu compressible.

La réduction observée est faible.

Et c’est une bonne chose.

Cela signifie que le contenu contient déjà majoritairement du signal.

Un bon pipeline ne cherche pas à tout compresser.

Il cherche à supprimer uniquement ce qui n’apporte rien.

Et après ?

Cette démonstration est volontairement synchrone et locale.

Mais elle ouvre une direction intéressante.

Une évolution naturelle serait d’aller vers :

• des streams non bloquants
• stream_select()
• des fibers
• des process pipes
• des PTY / TTY
• un event loop

Cela permettrait de traiter les flux au moment où ils apparaissent, et non après coup.

Autrement dit :

ne plus attendre la fin d’un process pour analyser sa sortie.

Lire et transformer le flux en temps réel.

Conclusion

Le coût des workflows agentiques n’est pas seulement un problème de modèle.

C’est un problème d’orchestration.

Un agent performant n’est pas celui qui lit tout.

C’est celui qui reçoit un contexte propre, structuré et contraint.

La vraie optimisation ne consiste donc pas à raccourcir les mots.

Elle consiste à contrôler le flux.

Control the stream, not the spelling.

Ressources

• Guillaume Moigneu about tokeniser context discipline
• flow-pipe
• slidewire presentation
• PHP 8.5 pipe operator