Pourquoi les workflows IA qui marchent vraiment sont ceux qui savent dire stop ?

DERRIÈRE UNE API CLIENT, UNE RÉPONSE PARFAITE NE SUFFIT PAS

Derrière une API client, un résultat de qualité ne suffit pas. Il doit arriver à temps. Fournir cela de manière constante n’est pas un problème de vitesse, mais de régularité. Et les solutions sont contre-intuitives.

Lancer un workflow d’IA en interne dans une entreprise coûte peu d’efforts : on relance, on contourne l’échec, ou on l’ignore. Mais placer ce même workflow derrière une API client ou un serveur MCP change tout. La grâce a disparu. Une seule chose compte désormais : le client a-t-il obtenu un résultat correct et utilisable ? Son processus dépend du vôtre, et c’est lui qui décide ce qui compte comme « livré ». Chez Databook, nous traitons des milliards de tokens pour les plus grandes entreprises mondiales. Cet article s’appuie sur des données réelles issues de flux de production à grande échelle. J’espère qu’il vous offrira des insights utiles.

LES ÉCHECS DES MODÈLES IA : QUATRE FLAVORS DE PROBLÈMES

Fournir ce résultat est plus difficile qu’il n’y paraît, car les modèles de langage sont notoirement peu fiables. Ils échouent fréquemment, sous quatre formes : une réponse invalide (vide, non analysable ou simplement fausse), une erreur bloquante, aucune réponse du tout, ou une réponse qui arrive trop tard. Et l’ensemble du workflow ne réussit que si chaque étape le fait. Plus on enchaîne d’étapes, plus les chances qu’une d’elles échoue augmentent. Un workflow composé d’étapes individuellement excellentes peut finir par ressembler à un lancer de pièce.

EN INTERNE, ON PEUT ABSORBER LES ÉCHECS. DEVANT UN CLIENT, PLUS.

En interne, on peut absorber chacun de ces échecs, car on dispose de marge sur tous les axes : relancer l’étape échouée, attendre une étape lente, dépenser un peu plus, ou relâcher la barre si nécessaire. Placer le même workflow derrière une API client fait disparaître cette marge, car le workflow doit désormais respecter trois budgets de ressources simultanément, sans qu’aucun ne soit défini par vous :

Sous ces trois budgets se trouve un plancher strict que vous ne pouvez pas franchir : la qualité. La réponse doit être correcte pour compter. Une réponse rapide, peu coûteuse et à l’heure, mais fausse, reste un échec. La qualité n’est pas un budget que l’on peut dépenser.

TROIS BUDGETS QUI S’OPPOSENT ET SE COMPENSENT

Chacun de ces budgets pourrait être géré séparément. Le problème est qu’ils s’appliquent ensemble et s’opposent : la solution évidente pour l’un dépense l’autre. Attendre une étape lente fait exploser le budget temps. Lancer une deuxième copie pour battre la montre brûle le budget coût et quota. Utiliser un modèle plus puissant pour franchir le plancher qualité ralentit le processus. Aucun de ces budgets ne peut être relâché, donc la seule solution est de les échanger délibérément entre eux, sans jamais franchir le plancher.

C’est ce qui rend un workflow orienté client radicalement différent à construire. Parfois, cela force une stratégie qui, vue de l’intérieur, semble totalement à l’envers :

En interne, on ne se soucierait jamais d’une étape lente. On attendrait simplement qu’elle se termine. Et le budget qui vous punit le plus silencieusement est le temps : le manquer ne fait rien paraître cassé de votre côté. Une réponse parfaite qui arrive quelques secondes en retard apparaît comme un succès sur vos tableaux de bord, mais comme un échec pour le client. Et c’est la seule limite que rien dans votre infrastructure n’impose.

LA RÉGULARITÉ VAUT PLUS QUE LA VITESSE

Voici la thèse principale, dès le départ, car tout le reste en découle : une fois la qualité au niveau requis, la livraison fiable est une question de régularité, pas de vitesse. Un temps de fin prévisible bat un temps rapide mais avec une longue traîne, car vos clients ne peuvent pas construire leur infrastructure sur votre meilleur cas. Ils doivent se préparer au pire.

Une distinction essentielle, car elle change tout. Cet article parle d’un workflow agentique : un flux de processus connu avec des étapes alimentées par des modèles de langage, piloté par un orchestrateur déterministe. Ce n’est pas un agent de raisonnement qui décide de sa prochaine action à l’exécution. Pour une même tâche, un workflow est simplement plus rapide : il connaît déjà le plan, évite la délibération, et exécute chaque étape indépendante en parallèle. Il obtient la même réponse en une fraction du temps et du coût qu’un agent de raisonnement prendrait. Les deux ont leur place (les agents de raisonnement sont bien plus flexibles), mais ils échouent différemment et se corrigent différemment. Le problème d’un agent de raisonnement est de décider quoi faire. Le problème d’un workflow (celui que ressentent les clients) est de livrer ce qu’il sait déjà faire, avec qualité et à temps. Cet article traite de ce dernier cas.

LES DONNÉES : UNE ARCHITECTURE PERSONNALISÉE SUR DES API TIERCES

Les conclusions ci-dessous proviennent de notre architecture et devraient se généraliser. Il s’agit d’appels API directs ordinaires. Pourtant, il est utile de connaître la configuration pour comparer avec la vôtre.

Nous utilisons un orchestrateur personnalisé sur des API tierces gérées (aucun modèle auto-hébergé dans cet ensemble de données). Nous utilisons des modèles phares à la fois directement via leurs fournisseurs (OpenAI, Anthropic, etc.) et via des plateformes gérées (Bedrock, Databricks, etc.), donc les meilleurs modèles ont plus d’un fournisseur. Cela nous permet de comparer les chemins de service et de déplacer le travail entre eux.

Nos charges de travail sont variées : appels d’agents simples, raisonnement approfondi, extractions, sorties JSON et texte libre. Pour une grande partie des appels, nous synthétisons une base de faits importante en une réponse, donc des entrées larges et des sorties moyennes à petites. Les analyses de cet article maintiennent la taille des entrées et des sorties constantes au sein des groupes (voir annexe).

Les longues traînées que nous rencontrons sont largement transitoires. Notez que si votre architecture est auto-hébergée ou sur une capacité dédiée, la traîne peut se comporter différemment et nécessiter une autre approche. Deuxièmement, exécuter plusieurs fournisseurs permet de router une couverture contre un budget séparé de manière pratique. Avec un seul fournisseur, moins de ces mouvements sont possibles.

LA SOLUTION QUI SEMBLE À L’ENVERS : COUPER UNE ÉTAPE À 20-30 SECONDES

Voici le mouvement qui semble à l’envers : nous coupons une étape à 20-30 secondes même si nous savons qu’elle aurait pu répondre parfaitement un peu plus tard — et cela rend le système plus fiable, pas moins.

Ce n’est pas une intuition. C’est vrai sur le papier — les maths des relances à queue lourde sont sans ambiguïté — et c’est vrai dans les données : un scan de plus d’un million d’appels récents de modèles de langage en production dans nos charges de travail d’entreprise — du trafic client réel. La première chose que ce trafic vous révèle est à quel point le timing d’un seul appel est étrange. Un appel typique à sortie longue revient en une douzaine de secondes. Mais un appel sur cent prend trente secondes, parfois une minute complète ou plus — pour aucune raison liée à la quantité de travail qu’il effectuait.

Cet écart entre l’appel typique et l’appel lent sous-tend une grande partie de cet article. Le reste de l’article examine quoi faire à ce sujet.

UN WORKFLOW N’EST PAS JUGÉ SUR SA MOYENNE, MAIS SUR UN DÉLAI

Un workflow n’est pas jugé sur sa moyenne. Il est jugé contre un délai. En moyenne, nos flux se terminent confortablement. Cependant, les exécutions outliers dans les longues traînées ne le font pas. Ces exécutions de traîne ne sont pas cassées. Elles retourneraient une réponse parfaite un peu plus tard, et sur un flux interne, elles seraient comptées comme des succès. Du côté du client, chacune d’elles est un échec. L’ensemble de la traîne de votre distribution de latence, aussi correcte soit-elle, devient une addition à votre taux d’échec.

C’est pourquoi le chiffre qui compte ici n’est pas la latence moyenne, mais la variance. Une médiane rapide ne vous sert à rien si votre traîne est longue.

LE COÛT IRRÉCUPÉRABLE : PLUS ON AVANCE, PLUS ÇA COÛTE CHER

Le deuxième facteur est le coût irrécupérable. Plus vous êtes avancé dans un workflow, plus vous avez déjà dépensé : du temps, des dollars, et votre quota TPM. Un échec à l’étape neuf coûte bien plus cher que le même échec à l’étape deux. Vous jetez tout ce que le workflow a construit et il vous reste moins de temps pour ajuster la stratégie. Nous ne relançons jamais l’ensemble du workflow nous-mêmes, mais le client le fera. Si nous échouons, ils relanceront presque certainement, en reprenant le flux complet depuis le début. Cela aggrave le problème de notre côté. Cela brûle plus de coût, plus de budget de tokens, et le budget d’erreur sur le SLA. Et parce que les conditions qui ont fait échouer l’exécution n’ont généralement pas changé, la relance a une chance similaire d’échouer. Pire encore, cela a tendance à se produire pendant une fenêtre de TPM élevée. Le pire moment possible pour ajouter une charge supplémentaire sur un système déjà sous tension, et exactement quand les chances d’échouer à nouveau sont les plus élevées.

Il existe un second multiplicateur, facile à manquer. Le premier vient de l’introduction : la fiabilité se multiplie, donc une chaîne d’étapes individuellement excellentes peut finir par ressembler à un lancer de pièce. Mais cet échec est toujours raconté comme une histoire de correction : obtenir une mauvaise réponse.

Voici ce dont on entend presque jamais parler : le même effet multiplicateur s’applique sur le temps. Chaque étape ajoute sa propre petite chance de finir dans la traîne lente, et ces chances s’additionnent. Plus vous enchaînez d’étapes, plus il est probable qu’au moins une d’elles dépasse le délai, même si chaque étape est individuellement rapide. C’est le multiplicateur dont parle cet article, et c’est celui que la littérature omet. Alors regardons les chiffres.

LES CHIFFRES : UNE MÉDIANE RAPIDE NE GARANTIT PAS UNE LIVRAISON PRÉVISIBLE

Les temps typiques dans le graphique ci-dessus se situent dans une bande assez étroite : chaque modèle termine un appel typique quelque part entre huit et vingt secondes. Les traînées ne sont pas du tout étroites. L’appel au 99e percentile d’un modèle arrive autour de 30 secondes, celui d’un autre au-delà de 80. Même médiane, pire cas radicalement différent. Promettre à un client votre médiane revient à mentir aux appels 1 sur 20 et 1 sur 100 dans la traîne, et un workflow multi-étapes les atteint constamment. Un temps typique rapide n’est pas un temps prévisible.

L’objection évidente est que les appels lents font simplement plus de travail : des prompts plus grands, des réponses plus longues. Ce n’est pas le cas. Fixer à la fois la taille du prompt et la longueur de la réponse ne fait presque pas bouger la traîne : au sein d’un même groupe de taille (le travail est maintenu constant), le p99 reste deux à sept fois la médiane (Figure 4). La lenteur ne dépend pas de la quantité de travail à effectuer — dans notre trafic, elle est largement transitoire (mise en file d’attente, planification, contention en cours de flux, un hoquet du fournisseur) — ce qui la rend exactement digne d’être interrompue.

On pourrait penser qu’un workflow rate son délai parce que de nombreuses étapes étaient chacune un peu lentes. Cela n’arrive presque jamais de cette façon. Lorsqu’une chaîne dépasse son budget, c’est généralement une seule étape qui s’est perdue dans sa traîne tandis que tout le reste se comportait bien. Mathématiquement, le dépassement d’une chaîne est dominé par sa pire étape, pas par l’accumulation d’étapes légèrement lentes. L’ensemble se comporte comme son maximum, pas comme sa somme.

C’est une bonne nouvelle. Vous n’avez pas besoin que chaque étape soit rapide. Vous devez empêcher une seule étape de s’emballer. C’est le rôle du seuil de coupure.

POURQUOI ATTENDRE UNE ÉTAPE LENTE EST LA PIRE DES SOLUTIONS

Si une étape s’est perdue dans sa traîne, attendre est la pire chose à faire — vous dépensez votre ressource la plus rare pour le gain le moins probable. Donc vous abandonnez tôt et essayez à nouveau en parallèle : lancez une nouvelle tentative et prenez celle qui revient en premier. Une nouvelle tentative a rarement le même problème, donc deux d’entre elles tiennent dans le temps qu’un seul appel bloqué aurait mangé — et les chances que les deux soient lentes sont minimes (si une est lente avec une probabilité q, deux le sont toutes les deux avec une probabilité q²).

La médiane bouge à peine : environ 10 secondes au lieu de 12. La traîne fait le contraire : le 99e percentile chute d’environ 60 secondes à 25, et l’écart entre les exécutions est plus que divisé par deux. Vous achetez de la prévisibilité au prix de quelques tokens supplémentaires.

Ce prix est réel et pousse à la baisse. La course double la facture de tokens pour cette étape, et les tokens sont un budget partagé et plafonné. Donc le coût est une force réelle qui limite la fréquence à laquelle vous relancez et faites la course. Mais faites le calcul : il est déséquilibré. Doubler une seule étape vous coûte les tokens de cette étape, une fois. Manquer le délai jette tout ce que vous avez déjà payé, et le client relancera presque toujours, en réexécutant les N étapes du workflow, au moins une fois, parfois plus. Plus vous êtes avancé dans le flux, plus l’échange est déséquilibré : une tentative redondante à l’étape neuf est bon marché comparée à jeter les étapes une à neuf et les voir s’exécuter à nouveau. Donc vous couvrez quand même. Mais pas indistinctement, car ce budget partagé de tokens vous mord le plus fort exactement quand vous voulez le dépenser le plus (nous y reviendrons bientôt).

DEUX PHASES D’UN TEMPS D’EXÉCUTION : LA DÉCISION DÉPEND DU TYPE DE RÉPONSE

Une nuance qui décide quelle solution de repli utiliser : la direction doit correspondre à la raison pour laquelle l’étape échoue.

Un temps d’exécution est en réalité deux phases. La attente du premier token est principalement de la mise en file d’attente et de la planification. La Génération qui suit, token par token, est le reste. La phase qui porte la traîne décide quoi couper. Et cela dépend de la quantité que l’étape écrit.

Pour les étapes longues dont parle cet article (celles qui appuient contre un délai), la traîne vit dans la génération, pas dans l’attente du premier token. Une file lente est une petite tranche d’un appel de quarante secondes ; l’écart qui fait exploser le budget est dans les tokens. Donc coupez ces étapes sur le temps total écoulé, ou sur les tokens émis jusqu’ici par rapport au temps qu’il vous reste, pas sur le temps jusqu’au premier token. (Pour les étapes courtes, l’équilibre s’inverse : avec peu à générer, l’attente du premier token représente la majorité de l’appel, et le temps jusqu’au premier token devient la coupure la plus propre. Mesurez vos propres étapes pour voir de quel côté vous êtes.)

UN ÉCHEC QUE AUCUNE HORLOGE NE PEUT CAPTER : LA RÉPONSE JETON OU TRONQUÉE

Et un échec qu’aucune horloge ne peut attraper : une étape qui retourne à temps mais retourne des déchets (par exemple, elle est vide, tronquée ou non analysable). Une coupure de latence passe droit à travers ; seule une vérification de qualité en aval le fera. Pour toute étape censée retourner une forme spécifique, la vérification la moins chère est une validation stricte juste après l’appel. Analysez le résultat par rapport au schéma ou à l’objet attendu, et traitez un échec de validation exactement comme tout autre échec : coupez et faites un repli (redessinez, ou remontez vers un modèle plus capable). Cela attrape une partie significative des mauvaises réponses avant qu’elles n’atteignent l’étape suivante. Couper tôt vous achète de la prévisibilité, pas de la correction. Gardez ces deux tâches séparées.

LA COURSE A UNE PROPRIÉTÉ DÉSAVANTAGEUSE : ELLE COÛTE CHER QUAND TOUT VA MAL

La course a une propriété gênante. La traîne est la pire quand le système est occupé. Et « occupé » est exactement quand votre budget de tokens par minute a le moins de marge. Donc le seul mouvement qui corrige la traîne veut dépenser des tokens au moment précis où ils sont les plus difficiles à obtenir. Le faire aveuglément crée un effet boule de neige : les appels lents déclenchent des couvertures, les couvertures ajoutent de la charge, la charge rend tout plus lent, plus d’appels dépassent leur seuil. Un problème de latence devient un problème de limite de débit.

Deux faits rendent cela moins indulgent qu’il n’y paraît au premier abord. Le coût est engagé dès que vous lancez le deuxième appel. Annuler le perdant libère votre connexion, mais le fournisseur continue de générer et de facturer la tentative abandonnée. Il n’y a pas de remboursement, donc tout le contrôle doit vivre dans la décision de couvrir, pas après. Et vous ne pouvez généralement pas voir combien de budget il reste. L’estimer est possible mais complexe, donc tout schéma qui « ralentit quand le quota se remplit » est difficile à mettre en pratique.

Ce qui fonctionne en pratique est plus brut et plus structurel :

Un levier que nous n’avons pas construit, et que nous proposons seulement comme piste : un plafond global explicite qui limite les appels couverts à une petite fraction du trafic total, indépendamment des décisions par étape. C’est le filet de sécurité théorique vers lequel pointe le travail sur la traîne à grande échelle ; nous avons défini des seuils de coupure conservateurs et n’en avons pas eu besoin, mais à des taux de couverture plus élevés, ce serait notre prochaine étape.

LES COUPS DE CUT-OFF SONT UNE ASSURANCE. MAIS ON PEUT DIMINUER LA PRIME.

Les coupures et les couvertures sont une assurance. Vous en achetez moins si le workflow est bien construit dès le départ. Les valeurs par défaut qui s’appliquent à chaque requête, avant toute astuce réactive :

Le point ici : dépensez votre budget de fiabilité sur la structure en premier, pour que le travail sur le temps ait moins à réparer.

Le seuil de coupure est un bouton, pas une constante. À quel point vous le tournez dépend de trois questions simples sur chaque étape :

Plus une étape est indispensable, porteuse, et à court de temps, plus tôt vous déclenchez la sauvegarde et plus vous dépenserez pour la couvrir. Une étape optionnelle, terminale et précoce n’obtient rien de tout cela. (« Tôt ou tard dans le flux » n’a jamais été l’axe réel. C’était un proxy pour combien dépend encore de cette étape.)

Et vous ne devinez pas le nombre. Vous exécutez le workflow de nombreuses fois, mesurez la courbe de latence de chaque étape (P95), et définissez le seuil de coupure à partir de cette courbe en dessous du pire cas de l’étape, pondéré par les trois questions. Une étape qui répond généralement en 20 secondes est coupée à 30, même si elle aurait pu réussir à 60.

Ce n’est pas difficile. C’est subtil, et la plupart des équipes n’ont pas le moteur pour le faire.

LES OUTILS DE WORKFLOW CLASSIQUES SONT FAITS POUR LA DURABILITÉ, PAS POUR LA PONCTUALITÉ

Les outils de workflow populaires, les Airflows et Temporals, ont été conçus pour rendre les pipelines durables : relancer, reprendre, ne pas perdre d’état, et ils sont très bons pour cela. Leurs conseils de timeout découlent de cet objectif : définir un timeout par étape plus long que le plus lent des runs et relancer jusqu’à ce qu’il réussisse. C’est la bonne intuition quand le travail consiste à achever durablement, et c’est exactement le mauvais conseil quand le travail consiste à finir à temps. Votre moteur de workflow relancera joyeusement une étape de nombreuses fois. Il n’a aucune notion du temps typique mesuré d’une étape et des implications en aval, donc il ne peut pas couper tôt et changer de modèle. Ce n’est pas un défaut. C’est par conception.

Les fondamentaux des systèmes distribués sont déjà de notre côté : travaillez à partir d’un budget de délai, alignez chaque timeout sur la latence mesurée. Nous ne contredisons pas cela. Nous l’appliquons à un cas que ces outils n’anticipent pas : un budget court, non reprisable, où le bon mouvement au seuil est une alternative plus rapide, pas le même appel à nouveau. Même principe, direction inversée.

Une chose à retenir, si vous ne gardez rien d’autre : un temps de fin prévisible bat un temps rapide mais avec une longue traîne. Une faible variance bat une faible latence. Vous ne pouvez pas promettre à un client une médiane, seulement une borne. Tout ici sert cette borne. Couper tôt, couvrir, faire la course, concevoir pour éliminer les dépendances : chacun échange un peu de vitesse moyenne contre beaucoup moins de variance. Vous abandonnez la traîne de droite pour acheter la gauche.

EN RÉSUMÉ : QUATRE RÈGLES POUR UN WORKFLOW FIABLE

1. La régularité prime sur la vitesse : une médiane rapide ne sert à rien si la traîne est longue. Un workflow client doit garantir un délai, pas un temps moyen.

2. Une étape lente peut faire échouer tout le workflow : la latence totale se comporte comme son maximum, pas comme sa somme. Une seule étape dans la traîne suffit à dépasser le délai.

3. Couvrir tôt coûte moins cher que rater le délai : relancer en parallèle une étape suspecte coûte moins cher que jeter tout le travail déjà fait et recommencer depuis le début.

4. Concevoir le workflow pour minimiser les dépendances : chaque étape ajoutée augmente les chances qu’une d’elles échoue. Moins il y a d’étapes, plus c’est fiable.

D’OÙ VIENNENT CES CHIFFRES ?

Les chiffres de latence proviennent de trafic de production récent (juin 2026), anonymisé, sur des charges de travail clients d’entreprise — environ 1,2 million d’appels de modèles de langage sur une fenêtre de 30 jours, pas de benchmarks synthétiques ni de traces publiques. Comme décrit dans Comment notre système est construit, il s’agit d’appels directs à des API tierces gérées, ce qui explique pourquoi la traîne lente est largement transitoire. Les chiffres dans le texte décrivent les appels longs (sortie ≥ 600 tokens), puisque ce sont ceux qui appuient réellement contre un délai. Les appels plus courts sont plus rapides et moins variables. Partout, un « ratio de traîne » (p99/p50) maintient la taille des appels constante au sein d’un groupe sauf indication contraire. Les modèles sont étiquetés par famille et chemin de service uniquement. La prévisibilité dépend du chemin de service (par exemple, une API gérée vs. un appel direct), pas seulement du modèle, donc ces données ne sont pas un classement de modèles. Les durées ont été regroupées en intervalles d’une seconde ; un plafond strict à 90 secondes ne tronque que les 0,2 % d’appels les plus longs, donc la traîne que vous voyez est réelle, pas un artefact de la limite.

POURQUOI LA TAILLE DES PROMPTS N’EXPLIQUE PAS LA TRAÎNE

L’objection légitime à la Figure 4 : chaque ligne est un groupe de tokens, pas un nombre fixe de tokens, donc peut-être que les appels lents dans une cellule sont simplement les plus grands — plus à précharger, plus à générer — et la traîne est juste une question de taille, pas de transitoire.

Ce n’est pas le cas, et la forme des données le montre. Si la taille expliquait la traîne au sein d’une cellule, deux choses suivraient : le ratio de traîne augmenterait avec la quantité de travail, et les cellules les plus bornées auraient presque pas de traîne. Aucune de ces hypothèses ne tient.

LE PRINCIPE DU « SAUT UNIQUE » : POURQUOI UNE SEULE ÉTAPE DOMINE TOUT

10 étapes à 95 % chacune ≈ 60 % de succès global ; 20 étapes ≈ 36 % (en supposant l’indépendance).

La distribution lognormale appartient à la classe sous-exponentielle, où la traîne d’une somme de termes indépendants est asymptotiquement la somme des traînées individuelles : P(Sn > t) ∼ Σi P(Xi > t) ∼ P(maxi X_i > t) quand t → ∞ — le principe du « saut unique ».

LE VERDICT : LA FIABILITÉ CLIENT, C’EST DU CONTRÔLE, PAS DE LA VITESSE

Dans un workflow agentique orienté client, la fiabilité est le produit. Le savoir-faire ne consiste pas à posséder une boîte à outils de relances et replis — ce sont des acquis de base. Il s’agit de décider, étape par étape, si couvrir et quand abandonner, en fonction des contraintes et du comportement mesuré de votre propre système.