Comment optimiser l’efficacité des tokens dans les systèmes agentiques

L’efficacité des tokens dans les systèmes agentiques s’améliore lorsque les équipes d’ingénierie cessent de raccourcir la formulation des prompts et commencent à traiter les véritables facteurs de coût : une récupération surdimensionnée, des historiques de messages non maîtrisés et des boucles de raffinement non contraintes.

La plupart des équipes abordent la réduction des dépenses en tokens comme un problème d’édition de texte — en raccourcissant les prompts système ou en compressant des exemples few-shot. Mais dans les systèmes multi-agents, le travail coûteux se déroule tout au long de la planification, de l’utilisation d’outils, de la communication inter-agents, de la vérification et des tentatives de reprise. Retirer quelques mots d’un prompt tout en laissant ces étapes intactes change à peine la donne en matière de réduction des coûts dans les workflows d’IA.

Cet article passe en revue les pratiques de context engineering — la discipline qui consiste à organiser ce qui entre dans chaque prompt — qui ciblent l’ensemble du cycle de vie des tokens, depuis l’observation des endroits où les dépenses s’accumulent réellement jusqu’à la correction des schémas architecturaux qui les gonflent.

Reformuler l’efficacité des tokens comme un problème d’architecture, pas de prompt

L’efficacité des tokens n’est pas un objectif en soi. Le véritable objectif est d’obtenir des résultats fiables par token dépensé — produire un résultat de même qualité avec moins de cycles gâchés. Formuler le problème ainsi déplace l’attention du simple raccourcissement cosmétique des prompts vers les décisions structurelles qui déterminent la performance des agents IA : la façon dont le contexte circule entre les agents, la quantité d’historique que chaque étape transporte et le nombre de boucles exécutées avant qu’une tâche ne se termine.

Une étude de l’Université Concordia portant sur 30 tâches de développement logiciel multi-agents dans ChatDev illustre où vont réellement les tokens. La revue de code à elle seule a consommé 59,4% de tous les tokens, et les tokens d’entrée — le contexte fourni aux modèles, et non le texte qu’ils ont généré — représentaient 53,9% de l’utilisation totale. La taxe de communication entre agents, et non la génération elle-même, dominait le coût.

Les recherches d’Anthropic sur la « context rot » — la dégradation de la précision de rappel du modèle à mesure que le nombre de tokens dans un prompt augmente — renforcent ce constat. Des contextes plus larges ne coûtent pas seulement plus cher — ils sont moins performants. Les équipes d’ingénierie qui se concentrent sur la gestion du contexte plutôt que sur la longueur des prompts obtiennent des gains cumulatifs à la fois en coût et en qualité.

Le schéma se vérifie aussi en production. Répartir le travail entre des types d’agents spécialisés avec une couche de routage réduit l’utilisation de tokens en limitant le transfert redondant de contexte, tout en diminuant la latence sans sacrifier la précision. Chaque agent ne recevait que le contexte dont il avait besoin, éliminant la récupération redondante et les historiques de messages gonflés.

Agentic Engine de Glean applique le même principe au niveau de la plateforme — en orchestrant des workflows en plusieurs étapes afin que chaque phase d’agent ne reçoive que le contexte d’entreprise requis pour sa tâche, plutôt que de rejouer l’intégralité de la conversation. Ce choix architectural est le levier le plus important pour améliorer l’efficacité des tokens dans les déploiements en production. Les étapes ordonnées des sections suivantes suivent ce chemin : observez d’abord votre cartographie des coûts, puis corrigez la gestion du contexte, la mémoire, le routage, les boucles itératives et le travail répété.

1. Mesurez où vont réellement les tokens avant d’optimiser quoi que ce soit

La première erreur que commettent la plupart des équipes consiste à traiter la consommation de tokens comme un nombre unique — le total de tokens par requête ou le coût total par jour. Ce nombre masque tout ce qui est utile. Pour trouver de vraies économies, vous devez décomposer l’utilisation par étape : récupération, planification, appels d’outils, exécution, revue, réflexion, mises à jour de mémoire et tentatives de reprise.

Suivez séparément les tokens d’entrée, les tokens de sortie et les tokens de raisonnement. Les tokens d’entrée dominent généralement la facture, mais les tokens de raisonnement sont là où se niche l’imprévisibilité. L’étude de l’Université Concordia a constaté que les tokens de raisonnement variaient de 17 280 à 40 000 selon les tâches de codage, rendant le coût par tâche presque impossible à prédire à partir des seules moyennes.

Les volumes de tokens ne disent pas à eux seuls si la dépense en valait la peine. Superposez des métriques métier et des métriques de workflow aux données de tokens :

• Taux de réussite des tâches. À quelle fréquence le workflow se termine-t-il sans intervention humaine ?
• Ancrage. L’agent a-t-il utilisé des sources réelles, ou a-t-il halluciné ?
• Temps jusqu’à l’achèvement. Combien de temps dure le workflow complet de bout en bout ?
• Taux de correction humaine. À quelle fréquence une personne doit-elle corriger la sortie ?
• Latence par étape. Quelles phases ralentissent le workflow ?

Un workflow qui coûte 0,12 $ par exécution mais échoue 40% du temps est plus coûteux qu’un workflow qui coûte 0,30 $ et réussit de manière fiable.

Construisez une cartographie des coûts par workflow, pas par appel de modèle. Un appel peu cher répété 10 fois lors des reprises coûte plus qu’un appel robuste qui termine le travail. Une étude de 2026 du Stevens Institute of Technology présente cela comme la « Unreliability Tax » — le coût caché d’agents qui terminent partiellement le travail, puis nécessitent un nettoyage humain ou des exécutions répétées.

Recherchez des points chauds de tokens liés à des schémas d’échec. La plupart des équipes optimisent la dépense moyenne, mais la queue coûteuse — les 10% d’exécutions qui consomment cinq ou six fois la médiane — entraîne souvent davantage de coût total que les 90% restants réunis. Ces queues proviennent généralement d’instructions ambiguës, d’un contexte manquant ou de boucles non bornées.

L’Enterprise Graph de Glean, qui cartographie les relations entre les documents, les personnes et les outils de votre organisation, peut faire ressortir les sources de données d’entreprise interrogées le plus fréquemment dans les workflows d’agents, aidant les équipes à identifier les points chauds de récupération avant de deviner où couper.

2. Arrêtez d’entasser tout le contexte à chaque tour

Plus de contexte ne signifie pas un meilleur contexte. Les grands prompts diluent le signal dont le modèle a besoin, augmentent la latence et réduisent la fiabilité. La relation entre la taille du prompt et la qualité de sortie n’est pas linéaire — au-delà d’un certain point, ajouter des tokens nuit activement.

L’erreur la plus courante dans la conception d’agents en entreprise consiste à charger des documents entiers, des historiques de chat complets et des sorties d’outils brutes à chaque étape « au cas où ». Les équipes traitent la fenêtre de contexte (le volume total de texte qu’un modèle peut traiter en un seul appel) comme un stockage bon marché. Les recherches d’Anthropic sur la dégradation du contexte montrent l’inverse : le rappel du modèle se détériore à mesure que le nombre de tokens dans le prompt augmente, en particulier pour les faits enfouis au milieu d’entrées longues.

Claude Code, par exemple, utilise des chemins de fichiers combinés à des commandes ciblées comme grep et head pour analyser des bases de code sans charger des fichiers complets dans le contexte. Le modèle récupère les données juste-à-temps plutôt que de tout transporter d’une étape à l’autre.

L’ingénierie du contexte — la pratique consistant à sélectionner délibérément ce qui entre dans chaque prompt — est un levier plus puissant pour réduire la dépense en tokens que la compression des prompts. Les actions clés sont :

• Récupération progressive. Stockez les références et identifiants en dehors du prompt. Récupérez l’extrait exact au moment de l’action.
• Classement des preuves. Évaluez les résultats de recherche selon leur pertinence et leur récence avant de les insérer. Incluez les trois ou quatre meilleurs, pas les 15.
• Filtrage tenant compte des autorisations. Ne récupérez que les données auxquelles l’utilisateur est autorisé à accéder. Des prompts plus petits et conformes valent mieux que des prompts gonflés et trop permissifs.
• Hygiène de la mémoire de travail. Supprimez les informations qui ne sont plus nécessaires pour la prochaine décision. Le contexte doit se réduire entre les étapes, pas grossir.

Envoyer 2 000 tokens très pertinents vaut mieux qu’en envoyer 20 000 vaguement liés, à la fois en coût et en qualité de sortie.

Les workflows d’entreprise ajoutent une couche supplémentaire : les données que vous récupérez doivent respecter les frontières d’accès existantes. Injecter un document entier dans le contexte d’un agent alors que l’utilisateur n’a accès qu’à deux sections crée à la fois un problème de sécurité et un problème de gaspillage de tokens. La récupération tenant compte des autorisations et l’Enterprise Graph de Glean ne fournissent que les extraits pertinents et autorisés dont un agent a besoin — en réduisant la taille des prompts tout en préservant les contrôles d’accès.

3. Remplacer les transcriptions brutes par un état et une mémoire structurés

Un long historique de conversation n’est pas une mémoire durable. Chaque message ajouté à une transcription qui s’allonge devient une taxe cumulative — davantage de tokens en entrée par tour, des réponses plus lentes, et un risque plus élevé que le modèle perde le fil des décisions antérieures. La recherche confirme que cette dégradation est significative : une étude à grande échelle portant sur plus de 200 000 conversations simulées a constaté que les LLM présentent une baisse de performance moyenne de 39 % dans des contextes multi-tours par rapport au mono-tour, principalement due à une fiabilité accrue des défaillances plutôt qu’à une baisse d’aptitude.

Conservez ce qui compte : l’objectif de la tâche, les contraintes actives, les décisions clés prises, les sorties d’outils qui ont modifié le plan, les questions non résolues et l’action suivante. Stockez-les sous forme d’état structuré — résumés, paires clé-valeur ou diffs — plutôt que de rejouer chaque message mot pour mot.

Différents types de mémoire servent des objectifs différents. Le tableau ci-dessous détaille trois couches que les systèmes d’agents efficaces utilisent :

Couche de mémoire

Ce qu’elle stocke

Durée de vie

Impact en tokens

État de travail

Objectif actuel de la tâche, contraintes actives, résultats d’outils de la dernière étape, action immédiate suivante

Tâche unique ou séquence de tours

Faible et constant — actualisé à chaque étape, ne croît jamais sans limite

Résumé de session

Décisions prises, impasses explorées, questions ouvertes, points saillants de conversation compressés

Une session ou une exécution de workflow

Modéré — rédigé une fois aux points de contrôle, remplace la transcription brute

Faits à long terme

Préférences utilisateur validées, politiques organisationnelles, schémas de récupération réutilisables, résultats de tâches passées

D’une session à l’autre

Interrogés à la demande, non chargés par défaut — n’ajoutent des tokens que lorsque c’est pertinent

Les résumés doivent préserver les preuves et les questions ouvertes, pas seulement les conclusions. « Décidé d’utiliser l’approche B » est moins utile que « évalué A et B ; A a échoué à cause des limites de taux ; B a réussi avec une latence de 340 ms ; question ouverte : est-ce que B passe à l’échelle au-delà de 1 000 utilisateurs simultanés ».

Le LOOP Skill Engine pousse la mémoire structurée plus loin en compilant les traces d’agents réussies en recettes sans branchement — des séquences d’actions compactes qui évitent les étapes exploratoires. Des chercheurs du Stevens Institute proposent un schéma similaire : stocker les plans passés dans un vector store (une base de données optimisée pour la recherche de similarité sémantique) et interroger ce store avant une planification coûteuse, afin que l’agent parte de connaissances antérieures plutôt que de raisonner depuis zéro.

Une bonne conception de la mémoire améliore directement les workflows automatisés. Un agent capable de se remettre d’une interruption en lisant une représentation d’état compacte — plutôt qu’en retraitant une conversation entière — termine plus vite, coûte moins cher et produit des résultats plus cohérents. Le Personal Graph de Glean maintient, pour chaque utilisateur, le contexte et l’historique d’interactions dans un format structuré et tenant compte des autorisations, faisant office de couche de mémoire d’entreprise que les agents peuvent interroger sans charger un historique volumineux.

4. Router les tâches selon leur complexité au lieu de tout envoyer dans le chemin le plus lourd

De nombreuses équipes d’ingénierie construisent un workflow puissant et y font passer chaque requête. Chaque tâche reçoit les mêmes boucles de planification, le même nombre d’agents, le même modèle et le même ensemble d’outils — qu’il s’agisse d’une simple recherche ou d’une investigation en plusieurs étapes. Le résultat : une dépense en tokens évitable et une latence imprévisible.

Toutes les tâches n’ont pas besoin d’une planification approfondie, de plusieurs agents ou d’un raisonnement coûteux. Une recherche factuelle qui pourrait se terminer en un seul appel de récupération ne devrait pas déclencher un pipeline d’orchestration en cinq étapes. Ajoutez une couche de routage qui classe les requêtes entrantes avant exécution : légère et rapide pour les tâches simples, orchestration plus lourde pour les travaux ambigus ou à forts enjeux.

Routez selon trois facteurs : la complexité (combien d’étapes et de décisions), le risque (ce qui se passe si la réponse est fausse) et la profondeur de contexte requise (combien de données d’entreprise l’agent doit consulter). Une classification simple, même basée sur des règles, évite la majorité des consommations de tokens inutiles.

Gardez l’ensemble d’outils minimal par route. Lorsqu’un agent reçoit un prompt listant 30 outils disponibles, le modèle dépense des tokens à évaluer lesquels s’appliquent — et plus il y a d’options d’outils, plus le risque d’erreurs de sélection augmente. Une route qui n’a besoin que de recherche et de synthèse ne devrait pas voir d’outils d’écriture en base de données ou d’exécution de code dans son prompt.

L’équipe Gemini Robotics de Google a introduit le concept de « thinking budget » — ajuster la profondeur de raisonnement qu’un modèle applique selon la tâche. Le même principe fonctionne pour l’orchestration d’agents : adaptez le thinking budget et le nombre de couches d’orchestration à la difficulté réelle.

Les tâches plus simples se terminent plus vite lorsqu’elles évitent des étapes de planification inutiles. Le routage entre des types d’agents spécialisés réduit aussi la latence, car les chemins légers évitent la file d’attente derrière une orchestration plus lourde.

Le moyen le plus rapide de réduire les coûts dans les systèmes d’agents IA consiste à réduire l’orchestration inutile, pas à réduire l’intelligence là où elle compte. L’Agentic Engine de Glean route le travail entre des types d’agents spécialisés, en alignant la profondeur d’orchestration sur la complexité de la tâche, afin que les recherches simples se résolvent rapidement tandis que les investigations complexes en plusieurs étapes obtiennent la profondeur de raisonnement dont elles ont besoin.

5. Concevoir les boucles de revue, de réflexion et multi-agents pour qu’elles se terminent proprement

L’itération améliore la qualité — jusqu’à un certain point. Au-delà, chaque boucle supplémentaire brûle des tokens avec des rendements décroissants, voire nuls. Dans les systèmes multi-agents, les boucles de revue et de réflexion sont souvent la principale source de gaspillage de tokens, et des recherches récentes montrent qu’une supervision légère à l’exécution, à elle seule, peut réduire la consommation de tokens multi-agents de près de 30 % sans sacrifier les taux de réussite des tâches.

La taxe de communication s’accumule rapidement. Lorsque des agents se renvoient tout le contexte, chaque tour ajoute l’intégralité de la sortie précédente plus les commentaires de revue au prompt suivant. Une boucle Reflexion en 10 cycles — un pattern d’auto-réflexion où un agent critique et révisе sa propre sortie — peut consommer environ 50 fois plus de tokens qu’un passage unique, en raison d’une croissance quadratique du nombre de tokens par tour.

Une analyse 2026 du Stevens Institute of Technology sur l’économie des agents IA a constaté que des agents non contraints dépensaient 5 à 8 $ par tâche. Les mêmes tâches avec des limites dynamiques de tours coûtaient 24 % de moins avec une qualité de sortie comparable.

Définissez des boucles bornées avec des conditions de sortie claires :

• Nombre maximum de tours. Plafond strict du nombre de cycles de revue ou de révision pouvant s’exécuter avant que le système ne s’arrête ou n’escalade.
• Seuil minimum d’amélioration. Après chaque itération, mesurez si la justesse, l’ancrage dans les sources (groundedness) ou l’exhaustivité se sont réellement améliorés. Si le delta passe sous un seuil, arrêtez d’itérer.
• Conditions de passation claires. Définissez à quoi ressemble « terminé » avant le démarrage de la boucle — pas après que l’agent a déjà dépensé des tokens à en débattre.

Transmettez des diffs et des listes de points à vérifier aux étapes de revue, pas des artefacts entiers. Si un agent réviseur doit vérifier que trois problèmes spécifiques ont été corrigés, envoyez-lui ces trois problèmes et les sections modifiées. Envoyer le document complet de 4 000 tokens pour une correction de deux lignes gaspille tout le budget d’entrée du réviseur à relire du contenu inchangé.

Ajoutez des signaux d’évaluation à chaque frontière d’itération. Le dernier passage a-t-il introduit de nouvelles erreurs ? L’ancrage dans les sources s’est-il amélioré ou est-il resté stable ?

Si deux itérations consécutives ne montrent aucun gain mesurable, des révisions supplémentaires ont peu de chances d’aider.

La fiabilité nécessite parfois plus de tokens. Une étape de vérification qui détecte une erreur factuelle avant que la sortie n’atteigne un utilisateur vaut la dépense. L’objectif n’est pas d’avoir moins de boucles, mais des boucles contrôlées — où chaque itération a une finalité mesurable.

Glean Agents planifient, s’adaptent et agissent avec le contexte et la gouvernance de l’entreprise, avec des garde-fous intégrés qui empêchent les boucles incontrôlées de brûler les budgets sans produire de meilleurs résultats.

6. Transformer les workflows répétitifs en plans réutilisables, caches et chemins déterministes

Le token le plus coûteux est celui dépensé à redécouvrir un plan dont vous savez déjà qu’il fonctionne. Lorsque des agents re-déduisent le même schéma de retrieval, la même séquence d’outils et le même format de sortie pour une tâche qu’ils ont déjà réalisée des dizaines de fois, chaque exécution repaie l’intégralité du coût de raisonnement.

Faites passer les tâches répétées de l’exploration à une exécution guidée. Après qu’un agent a mené à bien un workflow — par exemple trier des tickets support ou générer un récapitulatif hebdomadaire des métriques — stockez le plan : quels outils il a appelés, dans quel ordre, quels schémas de retrieval il a utilisés, à quoi ressemblaient les sorties attendues. À l’exécution suivante, partez de ce plan stocké au lieu de laisser le modèle le reconstituer depuis zéro.

Le LOOP Skill Engine, publié dans un article arXiv de 2026 par Wang et al., illustre l’ampleur de cette approche. En compilant des traces d’agents réussies en recettes sans embranchements — stockées dans un format compact que les chercheurs appellent SKILL.md — le système a atteint 93,3 % d’économies de tokens sur les tâches quotidiennes répétées et 99,98 % sur les opérations à haute fréquence. La conception hybride préserve l’adaptabilité : le chemin stocké gère les parties prévisibles, et le raisonnement du modèle gère les cas limites qui s’écartent de la recette.

Mettez en cache des blocs de contexte stables, des résultats intermédiaires validés et des instructions réutilisables. Le prompt caching à lui seul — réutiliser les parties statiques d’un prompt d’un appel à l’autre — peut réduire les coûts de tokens d’entrée jusqu’à 90 %, selon la même analyse 2026 du Stevens Institute. Une évaluation complète auprès de trois grands fournisseurs de LLM a constaté qu’un caching stratégique réduisait les coûts d’API de 41 à 80 % pour des charges agentiques. Ajoutez des contrôles de fraîcheur et du versioning afin que le contenu en cache ne devienne pas obsolète, mais ne reconstruisez pas le cache à chaque appel.

L’efficacité en tokens dans les systèmes agentiques matures vient de la réutilisation, de la conception de l’orchestration et de la gouvernance — pas du fait de rendre chaque requête individuelle plus petite. Les recherches 2025 de Gartner sur l’AI engineering prévoyaient que les organisations utilisant une gouvernance structurée des agents et des patterns de réutilisation réduiraient les coûts d’inférence jusqu’à 30 % par rapport à celles qui déploient des agents de manière ad hoc. L’écart entre les équipes à faible coût et à coût élevé tient généralement à la capacité du système à apprendre des exécutions précédentes, ou à traiter chaque requête comme une première rencontre.

L’Agentic Engine de Glean peut stocker et réutiliser des patterns d’exécution validés, réduisant le coût de découverte pour les workflows d’entreprise récurrents. Lorsque le chemin de retrieval, la séquence d’outils et le format de sortie sont déjà connus, l’agent saute la phase de planification et consacre son thinking budget aux parties de la tâche qui nécessitent réellement du jugement.

Questions fréquemment posées sur l’efficacité en tokens dans les systèmes agentiques

Quelles sont les erreurs courantes des équipes d’ingénierie concernant l’efficacité en tokens ?

Les trois erreurs les plus fréquentes consistent à traiter la consommation de tokens comme un seul chiffre agrégé plutôt qu’à la décomposer par étape, à bourrer des documents complets et des historiques de conversation dans chaque tour de prompt, et à exécuter des boucles de revue non bornées où les agents itèrent sans conditions de sortie claires. Chacune de ces pratiques gonfle les coûts tout en masquant la véritable source du gaspillage.

Comment les équipes peuvent-elles réduire efficacement la consommation de tokens dans les systèmes agentiques ?

Commencez par cartographier où les tokens sont consommés à chaque étape du workflow — récupération, planification, exécution, revue et relances — puis ciblez les plus fortes concentrations. Les leviers les plus impactants consistent à orienter les tâches simples en dehors d’une orchestration lourde, à remplacer les transcriptions brutes de conversation par un état structuré et à mettre en cache des plans validés pour les workflows récurrents. Ces changements réduisent la consommation sans diminuer la qualité des résultats.

Quel est l’impact de l’efficacité des tokens sur les performances des agents IA ?

Un nombre plus faible de tokens par échange réduit la latence, améliore la capacité de rappel du modèle (moins de dégradation du contexte) et produit des résultats plus fiables et mieux ancrés dans les faits. Les agents qui reçoivent un contexte ciblé et pertinent surpassent ceux qui reçoivent tout — le modèle dépense moins de tokens à analyser des éléments non pertinents et davantage sur la tâche elle-même. L’utilisation efficace des tokens et de meilleures performances des agents IA relèvent du même problème.

Quelles sont les implications économiques d’une mauvaise gestion des tokens dans les projets IA ?

Les coûts augmentent plus vite que la plupart des équipes ne l’anticipent. La croissance quadratique des tokens dans les boucles multi-tours, la « Unreliability Tax » liée aux exécutions en échec nécessitant un nettoyage humain, et la planification redondante sur des workflows répétés peuvent faire passer le coût par tâche de quelques centimes à plusieurs euros. À l’échelle d’une entreprise — des milliers d’exécutions d’agents par jour — l’écart entre une consommation de tokens maîtrisée et non maîtrisée représente souvent un ordre de grandeur sur la dépense mensuelle.

Quelle est la règle la plus simple à retenir pour les équipes d’ingénierie ?

Mesurez avant de réduire. Cartographiez la consommation de tokens par étape du workflow, identifiez les queues d’échec coûteuses et corrigez-les en priorité. Les équipes qui optimisent la moyenne passent à côté des 10 % d’exécutions qui consomment 50 % du budget.

L’efficacité des tokens dans les systèmes agentiques est une discipline de conception, pas une astuce de retouche de prompt — et les équipes qui la traitent comme un problème d’architecture dépenseront moins, livreront plus vite et construiront des agents qui tiennent réellement en production. Les étapes ci-dessus vous donnent une séquence claire : mesurer, récupérer de manière sélective, structurer la mémoire, router selon la complexité, borner vos boucles et réutiliser ce qui fonctionne. Demander une démo pour découvrir comment Glean et l’IA peuvent transformer votre entreprise.