Comment optimiser l’efficacité des tokens dans les workflows multi-étapes

L’efficacité des tokens dans les workflows multi-étapes s’améliore lorsque vous traitez l’usage des tokens comme un problème au niveau du système plutôt que comme un problème de formulation. Les principaux postes de coût ne sont pas vos prompts eux-mêmes, mais le contexte accumulé, la récupération redondante, les schémas d’outils inutilisés et une mémoire non gérée qui s’amplifie à chaque étape d’un workflow.

La plupart des guides d’optimisation se concentrent sur la réduction de prompts individuels. C’est utile, mais cela passe à côté de l’endroit où se trouve le vrai gaspillage. Dans les workflows agentiques où un modèle planifie, sélectionne des outils, lit des observations et conserve l’état d’une étape à l’autre, chaque action élargit le contexte et multiplie le coût.

Les stratégies les plus importantes fonctionnent sur l’ensemble du cycle de vie d’un workflow : ce qui entre dans le prompt, ce qui est récupéré, quels outils sont exposés, comment la mémoire est réécrite, et quand le système est autorisé à continuer d’itérer.

Comment optimiser l’efficacité des tokens dans les workflows multi-étapes

Commencez par reformuler l’objectif. Vous ne cherchez pas le moins de tokens par appel. Vous cherchez le maximum de travail utile par token.

Cette distinction compte, car une réduction agressive des tokens dégrade souvent la qualité des résultats ou impose des tours supplémentaires qui coûtent plus cher que les tokens économisés. Une approche pragmatique couvre six axes, à peu près par ordre d’impact : mesurer l’usage à chaque étape, réduire le contexte avant qu’il n’atteigne le modèle, repenser la mémoire, contraindre les outils, arrêter les boucles inutiles et router le travail vers le bon modèle. L’urgence grandit : selon Gartner, les modèles agentiques nécessitent 5 à 30 fois plus de tokens par tâche qu’un chatbot standard, ce qui signifie que même la baisse des prix par token ne compensera pas des workflows non optimisés.

La mesure vient en premier, parce que les moyennes au niveau de la session masquent les vrais problèmes. Un workflow peut sembler acceptable dans l’ensemble alors qu’une seule étape consume discrètement l’essentiel du budget. Suivez les tokens d’entrée, les tokens de sortie, les lectures et écritures de cache, et le nombre total de tours par exécution.

Lorsque l’équipe des workflows agentiques de GitHub a audité ses pipelines, elle a constaté que les enregistrements d’outils MCP inutilisés étaient l’inefficacité la plus courante. Un serveur GitHub MCP exposant 40 outils ajoutait 10 à 15 KB de schéma par tour. Supprimer les outils qu’aucun workflow n’appelait réellement a réduit le contexte par exécution de 8 à 12 KB sans aucun changement de comportement.

Le calcul des coûts renforce pourquoi la mesure par étape est essentielle. Les tokens de sortie coûtent généralement trois à huit fois plus que les tokens d’entrée, selon le fournisseur et le niveau de modèle. Même un workflow modeste générant quelques centaines de tokens par appel s’additionne vite à grande échelle — et chaque token dépensé pour du contexte non pertinent ou une sortie verbeuse est de l’argent dépensé pour un travail que votre produit n’utilise jamais. Des tests menés par l’équipe d’ingénierie de Glean confirment que le nombre de tokens d’entrée est directement corrélé à la latence, faisant d’un contexte gonflé un problème de performance autant que de coût.

Des recherches menées par les universités de Zhejiang et de Westlake ont montré qu’un framework de supervision léger appelé SupervisorAgent a réduit la consommation de tokens de 29,68% sur le benchmark GAIA sans nuire aux taux de réussite des tâches. Le framework fonctionne via une intervention en temps réel qui corrige en cours d’exécution les comportements inefficaces du modèle.

Dans les environnements d’entreprise, les plateformes dotées d’un contexte organisationnel approfondi, comme l’Enterprise Graph de Glean, améliorent la pertinence de la récupération en combinant le contexte de la tâche, le contexte utilisateur et les autorisations. Une récupération tenant compte des autorisations signifie que le modèle dépense moins de tokens à traiter des documents non pertinents ou non autorisés. Ce double avantage fait de la conception de la récupération l’un des leviers à plus fort impact pour l’efficacité des tokens à grande échelle.

1. Mesurer l’usage des tokens par étape, pas par session

Un budget de tokens pour l’ensemble de votre workflow est plus utile qu’un budget pour un prompt individuel. Cartographiez chaque étape — appel du planificateur, appel du récupérateur, invocation d’outil, transmission des observations, mise à jour de la mémoire, passe de vérification, synthèse finale — et attribuez à chacune une référence de tokens avant de commencer à optimiser.

Les moyennes au niveau de la session sont l’endroit où le gaspillage se cache. Un workflow en quatre tours qui, occasionnellement, gonfle jusqu’à 18 tours semble correct en moyenne, mais triple votre coût sur ces exécutions anormales. Le pattern Daily Token Usage Auditor de GitHub détecte précisément ce problème : il signale les workflows avec des pics d’usage anormaux, et un agent Optimizer complémentaire crée ensuite des issues avec des correctifs concrets pour les étapes en cause. Sans visibilité par étape, vous optimisez la mauvaise chose.

La métrique la plus importante est le score d’efficacité des tokens — la sortie utile divisée par le total de tokens consommés. Normalisez selon la taille de la charge de travail : tokens par tâche réussie, tours par workflow terminé, et ratio entrée/sortie par étape. Si la conception de votre système a évolué à partir d’un prototype de chat, examinez comment des prompts de conversation multi-tours sont devenus des historiques persistants rejoués à chaque appel. Cet artefact de migration est souvent une source majeure de tokens d’entrée inutiles. Les plateformes qui modélisent la manière dont les utilisateurs travaillent individuellement, comme le Personal Graph de Glean, réduisent la surcharge de récupération à chaque étape en faisant remonter des informations pertinentes au contexte, sans forcer le modèle à trier parmi des résultats larges et non personnalisés.

2. Réduire ce qui entre dans le modèle avant chaque tour

Le contexte s’accumule plus vite que la tâche n’avance dans tout workflow multi-étapes. Le comportement par défaut de la plupart des frameworks d’agents est de transmettre l’intégralité de la transcription, le catalogue complet d’outils et chaque document récupéré à chaque appel au modèle. Ce défaut est coûteux et contre-productif. Ces coûts fragmentés passent souvent inaperçus — ce que certains analystes appellent le coût caché de l’IA — car ils se répartissent sur les factures d’infrastructure plutôt que d’apparaître sur une seule ligne budgétaire.

Adaptez les instructions à la tâche en cours. Votre étape de planification a besoin de règles de planification, pas de contraintes de mise en forme. Votre formateur de sortie a besoin de définitions de structure, pas de logique de récupération. Quand chaque étape ne reçoit que les instructions dont elle a besoin, vous réduisez les tokens d’entrée et vous renforcez la concentration du modèle en même temps. Un contexte trop chargé dégrade la qualité du raisonnement — lorsque votre agent ne charge que ce dont il a besoin, la sortie est plus précise, pas seulement moins chère.

Récupérez moins, mais récupérez mieux. Au lieu d’extraire des documents entiers, extrayez les passages spécifiques qui répondent à la requête — le principe clé derrière la retrieval-augmented generation. L’architecture de recherche de Glean est conçue pour renvoyer des résultats pertinents plutôt que des fichiers complets, ce qui signifie que moins de tokens entrent dans la boucle de raisonnement tout en maintenant une forte pertinence. Pour les définitions d’outils, chargez les capacités à la demande. Une équipe en production l’a démontré avec 30 workflows spécialisés : tout charger d’emblée consommait environ 150 000 tokens, mais une architecture orientée compétences qui ne charge que des métadonnées légères — environ 100 tokens par description de compétence — et injecte les instructions complètes à la demande a fait tomber ce total à environ 3 000 tokens. Résumez les sorties d’outils longues avant qu’elles ne réintègrent la boucle de raisonnement. Une observation qui renvoie 2 000 tokens de JSON brut alors que le modèle n’a besoin que de trois champs est un pur gaspillage. Extrayez l’essentiel, écartez le reste et transmettez un résumé compact.

3. Remplacer la mémoire en historique complet par une mémoire en couches

L’architecture mémoire dans les systèmes agentiques façonne directement les coûts futurs en tokens, car chaque fait que vous stockez est rejoué dans les prompts suivants. L’erreur la plus courante est « tout stocker, tout rejouer ». Un workflow de dix tours qui transporte l’intégralité de sa transcription peut dépenser plus de tokens sur l’historique que sur la tâche elle-même.

Séparez la mémoire par objectif. La mémoire épisodique à court terme conserve l’état de la tâche en cours et les observations récentes. La mémoire sémantique à long terme stocke les faits susceptibles de compter d’une session à l’autre — contexte de projet, préférences utilisateur, connaissances métier. La mémoire procédurale capture les schémas appris sur la manière d’accomplir des tâches récurrentes. Chaque type se requête différemment, et seule la tranche pertinente entre dans un prompt donné. Faites suivre des résumés d’état, pas des transcriptions brutes. Quand une étape de planification se termine, résumez sa sortie dans un objet d’état compact — la décision prise, les faits clés trouvés, la prochaine étape — et faites-le suivre à la place de la trace complète de raisonnement.

Écrivez en mémoire de façon sélective et gardez l’ensemble ancré dans le réel. Ne sauvegardez que les faits ayant une probabilité raisonnable d’être réutilisés, étiquetez-les avec la source, la récence et le niveau de confiance, et validez avant de les réécrire. Un mauvais contexte en mémoire se propage et s’amplifie d’une exécution à l’autre, créant un multiplicateur de coûts silencieux. Le knowledge graph de Glean applique une version de ce principe au niveau de la plateforme : il comprend comment les utilisateurs individuels travaillent, à quoi ils accèdent et ce qui compte pour leur rôle, afin que la récupération reste personnalisée sans rejouer un contexte organisationnel trop large dans chaque requête. Cette approche sélective, sensible à l’identité, du contexte est l’une des voies les plus rapides vers de meilleures performances d’agents et un coût par exécution plus faible.

4. Restreindre l’accès aux outils et sortir le travail déterministe de la boucle de raisonnement

Chaque outil auquel votre agent peut accéder ajoute des tokens au prompt. Les définitions d’outils, les schémas d’arguments, les descriptions d’usage et les observations renvoyées entrent tous dans la fenêtre de contexte. Un vaste catalogue d’outils crée un gonflement permanent du prompt qui s’amplifie à chaque tour d’un workflow en plusieurs étapes.

N’enregistrez que les outils dont une étape de workflow donnée a réellement besoin. Un ensemble d’outils plus petit et plus sélectionné améliore la précision de sélection et réduit les tokens dépensés à décrire des options que le modèle n’utilisera jamais. Une équipe a conçu une architecture pour 30 workflows spécialisés où chaque compétence ne charge que les outils requis à la demande, puis les décharge ensuite. Ce cycle chargement-exécution-déchargement a fait passer leur prompt système d’environ 150 000 tokens à environ 3 000 — une réduction qui a rendu les tâches agentiques multi-étapes viables à grande échelle.

Sortez entièrement le travail déterministe de la boucle du modèle. La récupération de métadonnées, la lecture de fichiers, la validation de champs, la conversion de formats et les contrôles d’autorisation sont des problèmes de code, pas de raisonnement. Chaque fois que le modèle effectue un travail qu’un appel de fonction pourrait gérer, vous payez des coûts en tokens de niveau « raisonnement » pour des opérations de commodité. Gardez des sorties d’outils structurées et compactes — ne renvoyez que les champs dont l’étape suivante a besoin, dans un format cohérent. Standardisez les formats d’observation entre les outils afin que le modèle n’ait pas à analyser des structures différentes à chaque étape. L’agent builder de Glean prend en charge cette approche : lorsque vous créez un agent, vous configurez les connecteurs et les actions qu’il utilise, de sorte que l’agent opère avec un ensemble d’outils ciblé, adapté à sa tâche, plutôt qu’avec le catalogue complet de plus de 100 intégrations enterprise.

5. Mettre fin au gaspillage de tokens dû aux relances, boucles et transferts inutiles

Les workflows en plusieurs étapes peuvent continuer à consommer des tokens jusqu’à ce qu’une limite stricte les arrête. Sans garde-fous, un seul appel d’outil échoué peut déclencher une boucle de relance qui brûle des milliers de tokens en répétant la même erreur. Le contrôle des boucles est l’un des investissements au meilleur rendement dans tout système agentique.

Fixez des limites explicites sur le nombre de tours, les relances et les extensions de contexte. Un budget de relances force l’agent soit à réussir dans une fenêtre définie, soit à escalader proprement au lieu de s’enliser. La recherche sur les systèmes multi-agents a documenté des agents entrant dans des boucles d’actions répétitives — appeler le même outil avec les mêmes arguments, relire le même document, ou poser la même question de clarification — sans reconnaître le schéma. Les analyses en production montrent que l’orchestration multi-agents peut consommer 4 à 15 fois plus de tokens qu’un agent unique bien conçu lorsque ces boucles ne sont pas maîtrisées. Un filtre adaptatif qui détecte les comportements répétés et redirige l’agent vers une autre stratégie ou une sortie maîtrisée empêche ces boucles de consommer votre budget. Traitez les actions répétées comme un signal de supervision, pas seulement comme un problème de coût. Elles indiquent souvent un problème en amont : instructions ambiguës, contexte manquant, ou un outil qui renvoie des observations peu utiles.

Réduisez les transferts évitables entre agents. Chaque transfert duplique les instructions, l’état et les preuves, car l’agent qui reçoit doit disposer de suffisamment de contexte pour agir. N’utilisez plusieurs agents que lorsque la spécialisation de la tâche justifie clairement le coût du transfert. Ajoutez une vérification légère aux points de décision critiques — pas une auto-réflexion constante après chaque étape. L’Agentic Engine de Glean gère l’orchestration avec le contexte d’entreprise : il planifie des séquences en plusieurs étapes et s’adapte lorsque des résultats intermédiaires modifient la trajectoire. Mettre en cache les résultats pour des sous-problèmes répétés au sein d’une exécution réduit encore les calculs redondants — le seul caching sémantique peut réduire les coûts d’API LLM jusqu’à 68,8% dans des charges de production typiques, selon des données de Redis. Si deux branches d’un workflow ont besoin du même passage récupéré, servez-le depuis le cache plutôt que de le récupérer et de le retraiter.

6. Acheminer le bon modèle et le bon format de sortie à chaque étape

Toutes les étapes d’un workflow n’ont pas besoin du même modèle. Utiliser un grand modèle de raisonnement pour une simple classification, une sélection d’outil ou une extraction de champs est un défaut courant et coûteux. Adapter les capacités du modèle à la complexité de la tâche est l’un des moyens les plus rapides de réduire les coûts sans affecter la qualité des résultats.

Acheminez selon le type de tâche. Des modèles plus petits et plus rapides gèrent bien la classification, le routage, la synthèse et l’extraction structurée. Réservez votre modèle le plus performant aux étapes qui nécessitent synthèse, jugement, génération nuancée ou raisonnement multi-sources. Un workflow qui route un ticket de support peut utiliser un modèle léger pour classifier la catégorie du problème, un modèle intermédiaire pour récupérer et résumer la documentation pertinente, et un modèle de raisonnement performant pour rédiger la réponse au client. Chaque étape reçoit le modèle dont elle a besoin, et rien de plus. La tendance générale va dans ce sens : des recherches d’Epoch AI montrent que les prix d’inférence des LLM ont baissé de 9x à 900x par an selon la tâche, rendant les petits modèles nettement moins chers tout en atteignant encore les benchmarks de performance que les modèles de pointe fixaient il y a seulement un an ou deux.

Contraignez la forme des sorties à chaque étape. Lorsqu’une étape n’a besoin que d’un objet JSON avec trois champs, demandez exactement cette structure. Fixez des plafonds de tokens par étape afin qu’aucune étape ne puisse s’étendre silencieusement. Séparez les sorties intermédiaires des sorties destinées à l’utilisateur — les traces de raisonnement internes et les observations d’outils n’ont pas besoin du niveau de finition ni de la longueur d’une réponse finale. Le Model Hub de Glean donne aux équipes accès à une gamme de modèles et la capacité d’acheminer différentes tâches vers différents modèles au sein d’une même plateforme. La combinaison d’une sélection de modèle adaptée à la tâche et de contraintes strictes de sortie signifie que vous ne payez le raisonnement que là où il apporte de la valeur, et que vous évaluez la qualité en parallèle du coût plutôt que de les traiter comme des forces opposées.

Comment optimiser l’efficacité des tokens dans des workflows en plusieurs étapes : questions fréquentes

Quels facteurs influencent l’efficacité des tokens dans des workflows en plusieurs étapes ?

Les principaux facteurs sont l’accumulation du contexte au fil des étapes, le nombre et la taille des définitions d’outils chargées à chaque tour, la stratégie de relecture de la mémoire, le comportement de retry et de boucle, et la sélection du modèle par étape. Les workflows qui traitent ces cinq axes constatent généralement des réductions significatives des coûts de tokens par exécution par rapport à des versions non optimisées.

Comment optimiser l’utilisation des tokens lors de l’utilisation d’outils dans des systèmes agentiques ?

N’enregistrez que les outils dont chaque étape a réellement besoin, chargez les définitions d’outils à la demande plutôt qu’en amont, et gardez les sorties d’outils compactes en ne renvoyant que les champs requis pour l’étape suivante. Déplacer des opérations déterministes comme la validation et la recherche de métadonnées dans du code plutôt que dans la boucle du modèle élimine les coûts de tokens de niveau “raisonnement” pour des tâches standard.

Quelles sont les meilleures pratiques pour gérer la mémoire dans des workflows IA en plusieurs étapes ?

Séparez la mémoire en couches : épisodique à court terme, sémantique à long terme et procédurale. Faites avancer des résumés d’état plutôt que des transcriptions brutes, écrivez de manière sélective avec des tags de source et de récence, et validez les faits avant de les stocker. Une mauvaise mémoire se propage dans les prompts futurs et amplifie les coûts à chaque exécution suivante.

Comment la complexité d’un workflow affecte-t-elle les coûts de tokens ?

Chaque étape supplémentaire d’un workflow multiplie le contexte, car les observations, les sorties d’outils et le raisonnement intermédiaire sont reportés. Un workflow en cinq étapes ne coûte pas cinq fois un appel unique — il coûte souvent sensiblement plus à cause de la duplication de contexte aux points de transfert. Délimiter le contexte par étape et résumer entre les étapes maintient le multiplicateur plus proche du linéaire. Des approches comme l’agentic RAG aident en adaptant dynamiquement la profondeur de récupération aux besoins réels de chaque étape plutôt qu’en récupérant un ensemble fixe de documents quelle que soit la requête.

Quelles stratégies améliorent l’efficacité des tokens dans des agents IA sans nuire à la qualité ?

La mesure par étape identifie où se situe réellement le gaspillage. Un contexte délimité et le chargement d’outils à la demande réduisent les tokens d’entrée. Une mémoire en couches évite la relecture de l’historique. Des limites de boucle et des budgets de retry stoppent les dépenses incontrôlées. Le routage de modèles fait correspondre les capacités à la complexité des tâches. Appliquées ensemble, ces stratégies réduisent les coûts tout en améliorant la qualité des résultats, car un contexte focalisé produit un raisonnement plus précis.

L’efficacité des tokens dans des workflows en plusieurs étapes revient à traiter chaque étape comme une décision de conception — quel contexte entre, quel modèle s’exécute et quand le système s’arrête. Les équipes qui réussissent cela dépensent moins par exécution tout en produisant des résultats plus fiables et mieux étayés. Demandez une démo pour découvrir comment Glean et l’IA peuvent transformer votre environnement de travail.