Échelonnez les nœuds, pas les tâches : un escalier à six niveaux pour maîtriser les coûts des workflows de LLM

De nombreuses équipes qui développent des pipelines alimentés par des LLM commencent par une seule question architecturale pour chaque nouvelle fonctionnalité : faut-il que cela s’exécute sous forme de DAG fixe ou en tant qu’agent autonome ? Il s’agit d’une revue de conception logique, mais y répondre au niveau d’une tâche globale fixe en silence détermine le coût de l’étape la plus incertaine pour toutes les autres étapes. Cet article explique comment cela se produit, puis présente une échelle d’escalade en six niveaux où chaque nœud part du niveau le moins coûteux viable et ne monte qu’en cas d’échec d’un contrat explicite. À la fin, vous devriez être en mesure de décomposer vos propres tâches « agent », de voir quelle partie d’entre elles est réellement déterministe, et d’établir des limites strictes pour ce que le reste peut consommer en ressources.

Le scénario utilisé tout au long est celui d’un produit qui effectue deux choses : il convertit les formats de fichiers courants et il gère des flux de travail avec des fichiers en entrée et en sortie, tant sous forme de pipelines à un clic que via un outil de création qui génère un pipeline à partir d’une demande rédigée en langage courant. La partie de conversion fonctionne de manière fiable. C’est dans la partie relative aux flux de travail que la question du DAG ou de l’agent est constamment revenue, et il a fallu presque un an pour comprendre que c’était cette question elle-même qui posait problème.

Le point de départ : classer chaque tâche au préalable

Le processus initial pour chaque flux de travail à un clic était méthodique. Il fallait d’abord étudier le cas d’usage, rédiger une spécification, puis faire en sorte qu’une personne décide si le pipeline serait mis en œuvre sous forme de DAG ou d’agent.

Les tâches ouvertes étaient confiées à un agent

Les tâches considérées comme véritablement ouvertes ont été mises en œuvre sous forme d’un seul agent ReAct sur LangGraph. Le cas de référence était la recherche d’emploi basée sur un CV. Un utilisateur télécharge son CV, et le système doit identifier des postes pour lesquels il convient de postuler ainsi que créer un CV personnalisé pour chacun d’eux. Cela implique des CV rédigés dans plusieurs langues, l’association des candidats aux postes en fonction de critères que la correspondance par mots-clés ne peut pas capturer (temps de trajet depuis le domicile, composition de l’équipe, activités quotidiennes du poste, fourchette salariale) et enfin la génération d’un document sur mesure. Personne ne peut prédire à l’avance le nombre d’étapes nécessaires, ce qui en faisait un cas typique pour un agent.

Les tâches prévisibles ont été traitées par un DAG statique

Le travail séquentiel et prévisible est devenu un graphe fixe. Le cas de référence consistait à transformer une vidéo en sous-titres : extraire la piste audio, effectuer une reconnaissance vocale, diviser le texte transcrit en segments chronométrés, puis écrire le fichier de sous-titres. Même les éléments optionnels pouvaient être listés à l’avance, tels que la mise en forme du texte transcrit pour en améliorer la lisibilité ou la vérification de la fiabilité des affirmations présentées. Comme chaque décision pouvait être prise avant le début de l’exécution, tout le graphe pouvait être dessiné avant même que celle-ci ne commence.

La division du travail semblait logique, et le projet a été mis en œuvre. Le problème, c’est que les coûts n’ont jamais diminué.

Pourquoi la taxe sur les agents ne disparaît jamais

Le mécanisme à l’origine de cette courbe de coûts plate est banal, ce qui explique précisément pourquoi il est facile de l’ignorer.

Lorsqu’une tâche est étiquetée « agent », chaque étape qui s’y trouve s’exécute au sein de la boucle de l’agent et en paie le coût. Une boucle ReAct ne peut choisir une action que si les schémas de ses outils se trouvent dans la fenêtre de contexte. Vous pouvez compresser la conversation, résumer l’état intermédiaire et supprimer les documents récupérés, et l’équipe a fait tout cela, mais le coût minimal par tour reste inchangé, car ce minimum correspond au bloc de schémas d’outils qui est renvoyé à chaque tour. De même, vous ne pouvez pas simplement donner à l’agent moins d’outils s’il doit rester flexible : la raison pour laquelle il s’agit d’un agent, dès le départ, c’est que personne ne sait à l’avance quels outils une exécution donnée aura besoin.

Une solution possible consiste à prédire l’ensemble d’outils pertinent pour chaque tâche. Il s’agit d’une direction de recherche légitime, mais elle nécessite des investissements supplémentaires ainsi qu’un modèle capable de faire de bonnes prédictions. Ce que l’équipe souhaitait plutôt, c’était quelque chose de spécifiable : une architecture dont le coût est déterminé par sa structure, et non par la précision d’un prédicteur. Si l’approche basée sur les prédictions vous intéresse, la découverte progressive d’outils pour des agents à grande échelle l’examine en profondeur.

La relecture de la littérature, associée à des mois d’analyses des journaux de production, a abouti à une conclusion presque embarrassamment simple :

L’incertitude concerne les nœuds individuels, et non les tâches dans leur ensemble.

La décision concernant l’approche DAG ou agent était prise pour chaque tâche. Mais une tâche n’est rien de plus qu’un ensemble d’étapes, et dans presque toutes les tâches classées comme « agent », la plupart des étapes étaient entièrement déterministes. Prendre une décision au niveau de la tâche signifie que chaque nœud doit subir les conséquences du nœud le plus incertain du graphe.

Si l’on analyse en détail le flux de travail de recherche d’emploi, le schéma devient évident :

• L’extraction de champs structurés à partir d’un CV en PDF ne nécessite absolument aucun raisonnement par modèle.
• L’identification de la langue utilisée dans le CV est tout aussi mécanique.
• La localisation de l’adresse domicile et le calcul du temps de trajet relèvent d’une seule invocation d’outil.
• La récupération des offres d’emploi implique l’utilisation d’une API dédiée.
• Évaluer dans quelle mesure un poste correspond à un candidat nécessite une seule requête au modèle, un prompt fixe et aucun outil supplémentaire.

Seul un cas comme « découvrir ce que cette équipe spécifique a livré récemment » ne présente pas de nombre de étapes prévisible.

Cet dernier élément correspond à un seul nœud. Tout le graphe devait payer les tarifs des agents pour être traité.

L’échelle d’escalade

La solution consistait à cesser de prendre des décisions à l’avance. Selon la nouvelle règle, chaque flux de travail commence au niveau le moins cher qui puisse fonctionner, et seuls les nœuds qui échouent sont promus vers un niveau supérieur. Il existe six niveaux.

• L0 : uniquement des appels d’outils, sans LLM. Si une demande peut être satisfaite entièrement par des opérations déterministes, aucun modèle n’est exécuté. Dans le produit, il s’agit du chemin rapide existant qui reste une entité distincte. Le coût correspond simplement aux appels d’outils.
• L1 : DAG statique de nœuds mécaniques. Un véritable graphe avec des branches et des sorties multiples, mais chaque nœud est constitué de code ordinaire. Aucun appel de modèle non plus.
• L2 : DAG statique avec des nœuds LLM à utilisation unique. La structure du graphe reste inchangée, mais certains nœuds invoquent désormais un modèle une seule fois, avec un contexte étroitement défini. En pratique, le nœud ne prend en compte que ses entrées directes : aucune historique de conversation, aucun état global et, ce qui est crucial, aucun schéma d’outil. À ce niveau, le modèle se comporte comme une fonction pure plutôt que comme un agent. Le coût correspond à O(n) appels, où n est connu avant le début de l’exécution.
• L3 : boucles de précision limitées. Un nœud L2 peut tenter à nouveau d’exécuter une action conformément à un contrat jusqu’à un maximum fixe de N tentatives. C’est le contrat, et non le modèle, qui détermine lorsque la sortie est acceptable. Le coût est de O(n·N), valeur également connue avant le début de l’exécution.
• L4 : un nœud opaque devient un sous-agent. Un nœud qui ne peut pas être spécifié à l’avance dispose d’un véritable cycle ReAct, mais ses outils sont limités à ce nœud et il dispose d’un budget d’étapes fixe. Personne ne peut prédire ce qu’il dépensera, et c’est cette imprévisibilité qui oblige à fixer un plafond explicite.
• L5 : replan complet. Le plan lui-même était erroné, donc le graphe est reconstruit. Il s’agit de la solution la plus coûteuse possible et devrait être rare.

Contrats, portée et budgets

Une simple taxinomie ne serait qu’un vocabulaire plus élégant. Trois mécanismes permettent à cette structure de fonctionner réellement :

• Les contrats déclenchent une escalade. Chaque nœud définit la forme d’un résultat acceptable, et seul un échec de vérification par rapport à cette définition justifie une montée d’échelon.
• Le champ d’application maintient L4 abordable. Les schémas des outils des sous-agents se trouvent dans le contexte de ce seul nœud et n’apparaissent nulle part ailleurs pendant l’exécution, de sorte que le coût lié aux schémas est supporté localement.
• Les budgets fixent une limite supérieure. Chaque niveau au-dessus de L2 dispose d’un nombre maximal d’essais ou d’étapes ; une fois atteint, le nœud soit abandonne, soit passe à un niveau supérieur.

Une façon pratique de le comprendre : le contrat répond à la question « est-ce suffisant ? », le champ d’application répond à « que peut voir et appeler ce nœud ? », et les budgets répondent à « combien peut-il dépenser en essais ? ». Si l’un de ces trois éléments fait défaut, le niveau correspondant cesse d’être prévisible. Pour en savoir plus sur la maîtrise des boucles comme L3 et L4 dans le code, consultez les boucles agentes bornées en TypeScript.

Parcours du pipeline de sous-titres

La plupart des traitements ne quittent jamais le niveau L1. Le pipeline extrait l’audio, effectue une reconnaissance vocale, segmente le contenu selon les timestamps et génère un fichier SRT, tout cela sans aucune appel à un modèle. Le résultat est ensuite vérifié conformément aux critères préétablis : les indications temporelles ne doivent pas se chevaucher, aucune ligne ne doit dépasser la limite de caractères et la vitesse de lecture doit rester en dessous d’un seuil donné. Une vidéo avec un narrateur et un audio de bonne qualité est acceptée, et le traitement ne nécessite pas plus que ffmpeg associé à une seule passe de reconnaissance.

Lorsqu’une indication temporelle en particulier viole les règles de longueur de ligne ou de lisibilité, seule cette indication passe au niveau L2. Elle fait l’objet d’un seul appel à un modèle, dont le contexte comprend cette indication ainsi que ses voisines immédiates. La transcription complète, les métadonnées de la vidéo et tous les schémas des outils restent exclus du prompt, et le reste du réseau n’est pas affecté.

L3 est justifié par la terminologie. Dans une présentation technique accompagnée d’un glossaire, les vérifications terminologiques peuvent continuer à échouer même après une seule correction, ce qui permet à ce nœud d’affiner sa sortie exactement deux fois, le contrôle du glossaire déterminant lorsque le résultat est acceptable.

L4 n’apparaît qu’en un seul endroit : pour vérifier que les affirmations faites dans la présentation sont correctes. Cela nécessite des recherches, et personne ne peut dire combien d’entre elles sont nécessaires. Ainsi, ce nœud unique devient un sous-agent dont les outils se limitent à la recherche et au récupération de données, et dont les étapes sont limitées. Le pipeline de sous-titres qui l’entoure reste mécanique.

L5 gère le cas où le plan était erroné dès le départ. Supposons que le fichier s’avère être une capture d’écran dont le sens réside dans le texte affiché à l’écran, tandis que l’audio n’est qu’accidentel. Aucune amélioration des nœuds individuels ne pourra sauver un plan basé sur la reconnaissance vocale ; par conséquent, le graphe est reconstruit en utilisant plutôt la reconnaissance optique de caractères.

Progresser dans la recherche d’emploi

C’est cet exemple qui a changé la façon de penser de l’équipe, car il ressemblait évidemment à un agent.

L1 couvre plus de fonctions que prévu : l’analyse du CV, la détection de sa langue, le géocodage et le calcul du temps de trajet, ainsi que la récupération des offres d’emploi. Tout cela est du code simple.

L2 s’occupe de la correspondance. Pour chaque poste candidat, il y a une seule appel à un modèle ciblé qui renvoie une note structurée selon les dimensions pertinentes, le résumé du CV et la description unique du poste constituant tout son contexte. Il s’agit donc d’appels de type O(n) vers un modèle peu coûteux, sans aucun schéma d’outil, et cela a remplacé un agent qui raisonnait à partir de la même liste en rechargant l’ensemble des outils à chaque étape.

L3 s’occupe de la réécriture du CV, et c’est là que les contrats passent d’un outil de contrôle des coûts à un outil de contrôle de la fiabilité. Le contrat exige que chaque affirmation dans le CV réécrit soit traçable jusqu’à l’original, interdit d’inventer des employeurs ou des dates, et fixe une longueur maximale. Si un brouillon enfreint ces règles, il est affiné, au maximum deux fois, puis le processus s’arrête. Il s’agit d’un modèle utile au-delà du simple contrôle des coûts : un contrat qui vérifie l’origine constitue une protection peu coûteuse et fiable contre le fait qu’un modèle embellisse l’historique professionnel de quelqu’un.

L4 correspond à un seul nœud : la recherche concernant l’équipe de l’entreprise en question et son orientation récente. Il est par nature ouvert, mais limité par sa structure de conception.

L5 est déclenché lorsque les catégories elles-mêmes ne correspondent pas. Imaginez un physicien postulant à des emplois dans le domaine de la finance quantitative : les catégories d’emplois analysées ne correspondent pas bien au véritable parcours du candidat, et le plan de correspondance doit être entièrement reconstruit plutôt que simplement ajusté.

Le résultat principal est que la tâche, autrefois classée comme relevant d’un agent, s’avère être à environ 80 % du travail de type L1 et L2. Il ne s’agit pas simplement d’ajuster un prompt ; cela place le flux de travail sur une courbe de coûts complètement différente.

Ce que l’échelle d’analyse offre aux produits de type fichier à fichier

Les flux de travail d’entrée et de sortie des fichiers se chevauchent fortement. Les 80 % premiers de presque tous les deux types de pipelines ressemblent beaucoup. Pourtant, la qualité que perçoivent les utilisateurs réside entièrement dans ces 20 % restants, et cette partie varie à chaque fois. C’est le piège de la personnalisation : soit les ingénieurs conçoivent manuellement les détails pour chaque tâche, ce qui empêche le produit de se développer, soit ces détails sont omis, ce qui donne un résultat médiocre.

L’échelle constitue une issue à ce piège. La personnalisation a toujours lieu, mais elle s’effectue grâce à des décisions de hiérarchisation dictées par les contrats plutôt que par le temps consacré aux tâches d’ingénierie. Le résultat est un ajustement par tâche sans effort humain supplémentaire pour chaque tâche.

Lorsque le ladder n’est pas utile

Cette approche part du principe que l’on peut rédiger des contrats significatifs. Si la qualité de la sortie d’un nœud ne peut être évaluée que par un humain, il n’existe aucun déclencheur fiable pour une escalade, et le système se réduit à des suppositions. De plus, elle nécessite des mécanismes d’orchestration ; pour un pipeline composé de deux ou trois étapes et à faible volume, une seule appel à un modèle bien défini peut être suffisamment simple et peu coûteuse.

Déployer d’abord l’échelon le plus bas

Lorsque chaque flux de travail prend des fichiers en entrée et en renvoie d’autres, la couche de gestion des fichiers se trouve au niveau le plus bas. Chacun des échelons décrits ci-dessus se réduit finalement à une opération mécanique : ouvrir le conteneur, extraire le texte, conserver les tableaux intactes. Rien dans cette couche n’est incertain, donc payer pour des calculs y serait purement du gaspillage ; sa prévisibilité en fait également le premier composant évident à déployer.

Il a été publié sous forme de SDK Python open source, disponible sur PyPI sous la licence Apache-2.0 et pouvant être utilisé comme serveur MCP à l’intérieur de Claude Code. Son installation se fait en une seule commande, que ce soit avec uv ou pip.

uv add convilyn          # or: pip install convilyn

Cet SDK convertit les documents en Markdown, transforme les images entre 26 formats et réorganise les pages PDF, tout cela localement, sans nécessiter de compte ni d’accès réseau. Lorsqu’une tâche requiert réellement l’aide d’un modèle pour lire quelque chose, comme une page scannée, une photo ou un fichier audio, elle est envoyée vers un service cloud hébergé, et c’est là que les frais de utilisation commencent à être facturés.

Cette division correspond à l’échelle représentée par la conception de produits plutôt que par l’architecture interne. Le chemin local gratuit est L0 : lorsque du code déterministe classique peut terminer une tâche, aucun modèle n’est chargé, et le travail ne passe sur un chemin payant que lorsque la méthode peu coûteuse a clairement échoué. Selon le projet, le convertisseur hors ligne ne nécessite ni compte, ni clé, ni quota, et n’envoie aucune donnée de telemétrie ; consultez le README actuel du répertoire pour obtenir des détails sur l’installation ainsi que la liste exacte des fonctionnalités, car ces éléments sont susceptibles d’évoluer.

État actuel du moteur de flux de travail

Au moment de la rédaction, les fonctionnalités liées aux workflows et aux outils de création étaient encore en cours d’ajustement, tandis que la refonte décrite ici était réalisée en arrière-plan ; l’équipe prévoit de terminer ce travail dans environ un mois. La raison est pertinente : il vaut mieux retarder le déploiement d’un moteur de workflows dont on sait qu’il est en voie d’être remplacé plutôt que de le promouvoir et de devoir migrer les utilisateurs à deux reprises.

États de l’art et travaux connexes

Aucun des éléments individuels n’est nouveau, et chacun a déjà été décrit précédemment. Ce qui ne semble pas avoir été publié, c’est cette combinaison spécifique : une escalade par nœud déclenchée par des contrats, un périmètre d’outil utilisé comme levier de coût, une expansion récursive autorisée mais encadrée par un budget, appliquée à des tâches de transfert de fichiers. Les travaux suivants couvrent ces différents aspects.

Commencer simple et n’ajouter de complexité que lorsque c’est nécessaire

• Building effective agents, publié par Anthropic en décembre 2024, distingue les flux de travail des agents et recommande la solution la plus simple et fonctionnelle, n’ajoutant de complexité que lorsque c’est nécessaire. La méthode à échelons diffère en appliquant ce principe pendant l’exécution, étape par étape, plutôt que de le faire une seule fois par tâche lors de la conception.

Ne passez en mode échelonné que pour la composante qui a échoué

• Le article ADaPT, dont le nom signifie décomposition et planification selon les besoins (Findings of NAACL 2024), commence par un plan de haut niveau et décompose une sous-tâche de manière récursive uniquement après l’échec de son exécution, laissant intactes les parties qui ont réussi. Il s’agit de la description publiée la plus proche du déclencheur L4, bien qu’elle ne soit pas formulée en termes de coût.

Contrats, récupération limitée et règles d’escalade

• Un cadre théorique de planification pour exécuter des agents LLM sous forme de graphes structurés, publié sur arXiv en avril 2026, utilise un DAG statique avec des contrats de sortie par nœud ainsi qu’un protocole de récupération en trois étapes : tentative répétée, correction locale et replanification complète, accompagné d’invariants d’escalade explicites. Selon cet approche, les nœuds basés sur des modèles doivent être validés contre ces contrats, car les vérifications de type ne suffisent pas, et la répétition d’opérations non idempotentes nécessite des budgets limités. Il exclut délibérément l’expansion de sous-graphes récursifs, domaine d’application des L4.

La planification découplée des tâches (TDP), abordée dans le même article, divise le travail en un graphe de sous-objectifs, chacun disposant de son propre contexte restreint, et limite tout replanification au sous-tâche actuellement en cours d’exécution. Elle indique des réductions de tokens allant jusqu’à 82 %, ce qui constitue la mesure publiée la plus proche à l’appui de l’argument relatif au ciblage L2.

L’étendue des outils comme principale variable de coût

• Skillflow définit un DAG en YAML que l’engine, et non le modèle, parcourt. Ses entrées/sorties sont contrôlées en fonction des capacités : une étape ne reçoit que le contexte qu’elle demande, et tout outil non prévu par son contrat n’apparaît simplement pas dans son schéma. Sa conclusion, selon laquelle un contexte restreint spécifique au rôle permet aux modèles peu coûteux de suffire, correspond à l’argument L2.

Échelles en étapes déjà en production

• PraisonAI intègre une fonction d’escalade dans son SDK d’agents qui définit quatre étapes progressives : une réponse directe sans utilisation d’outils ni de planification, l’utilisation d’outils heuristiques sans appel supplémentaire au modèle, un appel limité au modèle, et enfin un cycle entièrement autonome incluant des outils, des sous-agents et une vérification. Cela correspond approximativement aux niveaux L0 à L4 compressés en quatre étapes.
• le routeur d’escalade de NVIDIA NeMo Switchyard applique la même logique au choix du modèle plutôt qu’à l’architecture : on commence avec un modèle moins puissant et on passe à un modèle plus performant lorsque le système détecte des problèmes persistants.

La même logique ailleurs

• Agentic Design Patterns (systemdesign.one, avril 2026) utilise l’expression « échelle d’escalade » pour désigner le choix entre flux de travail et agent, et recommande de privilégier l’organisation la moins complexe capable d’accomplir la tâche.
• Le guide de Vercel sur les cadres d’évaluation des agents IA pour le environnement de production (juillet 2026) applique une logique de priorisation par coût le plus bas pour l’évaluation : exécuter la vérification la moins chère capable de détecter une erreur donnée, et n’escalader que lorsque cette vérification ne peut pas structurellement identifier le problème.

Points clés

• Décider « DAG ou agent » pour chaque tâche permet à chaque étape de compenser la plus incertaine d’entre elles.

Le coût irréductible d’un boucle d’agent est le bloc schéma-outil qui est renvoyé à chaque tour, et que la compression de l’historique ne peut pas éliminer.

Démarrez chaque nœud au niveau le moins coûteux et ne passez à un niveau supérieur qu’en cas d’échec d’un contrat explicite.

Restreignez les schémas outil au nœud qui en a besoin et attribuez un budget fixe à chaque niveau supérieur à L2.

On peut s’attendre à ce que la plupart des charges de travail « agent » soient largement déterministes une fois décomposées ; dans le cas de la recherche d’emploi, environ 80 % relevaient des niveaux L1 et L2.

Lectures complémentaires

• Concevoir des systèmes multi-agents sur A2A : nœuds, mémoire et gouvernance — Une architecture de référence pour les systèmes multi-agents basés sur le protocole A2A, couvrant les modules d’agent, les types de mémoire, l’orchestration, les risques de sécurité et une liste de contrôle de conception.
• LangGraph en pratique : états, nœuds, arêtes et cinq patterns d’agents — Apprenez à définir les états de LangGraph à l’aide d’annotations et de réducteurs, à relier les nœuds par des arêtes, ainsi qu’à mettre en œuvre les cinq patterns fondamentaux de flux de travail basés sur des agents en JavaScript.