Workflows déterministes et outillage

Nous concevons des pipelines d'IA où l'orchestration est déterministe et où l'appel de modèle constitue l'unique composant probabiliste. Chaque décision de routage, contrôle de validation, politique de réessai et transition d'état s'exécute sous la forme d'un code explicite et auditable. Le LLM opère au sein de nœuds délimités avec des entrées et sorties validées par schéma, et lorsqu'une défaillance survient, vous rejouez à partir du dernier point de contrôle, et non depuis le début. C'est cette architecture qui rend le chaos des agents auditable dans la surveillance des marchés, l'extraction de données cliniques et la génération de déclarations réglementaires.

Le calcul mathématique qui condamne les pipelines d'agents

Une chaîne d'agents IA de 10 étapes où chaque étape s'exécute avec une précision de 95 % produit un résultat correct de bout en bout seulement 59,9 % du temps. Cela signifie que quatre exécutions sur dix échouent. Dans une démonstration de chatbot, on réessaie et on passe à la suite. Dans la surveillance des transactions boursières, l'extraction de données cliniques ou la génération de déclarations réglementaires, un taux d'échec de 40 % est rédhibitoire. Gartner prévoit que plus de 40 % des projets d'IA agentique seront annulés d'ici la fin de 2027, et l'arithmétique des erreurs composées en est l'une des raisons majeures.

Notre réponse consiste à confiner l'appel de modèle probabiliste dans des nœuds délimités aux entrées et sorties validées par schéma. Chaque décision de routage, contrôle de validation, politique de réessai et transition d'état s'exécute sous la forme d'un code explicite et auditable — de sorte qu'un échec est rejoué à partir du dernier point de contrôle, et non depuis le début (voir nos recherches sur l'architecture, la fiabilité et la divergence stratégique dans l'IA avancée).

Pourquoi la plupart des frameworks d'agents échouent en production

Le retour d'expérience de la communauté est sans équivoque, et les défaillances sont précises :

• LangChain : les agents s'enlisent dans des boucles de raisonnement, appellent les mauvais outils de manière répétée et se dégradent sans lever d'exception.
• Les modèles préfixent le JSON par un texte explicatif ; les analyseurs renvoient des données structurées avec assurance mais erronées.
• CrewAI : les boucles de délégation divergent face à des graphes de tâches concurrentes.
• AutoGen exécute plus de 20 appels de LLM par tâche à 0,45 $ chacun, là où un pipeline déterministe obtient le même résultat avec moins d'appels à 0,08 $.

Ces défaillances proviennent d'un choix de conception commun : laisser le modèle contrôler le flux d'exécution. Lorsque le LLM décide de l'outil à appeler, de la branche à suivre et du moment où s'arrêter, vous obtenez une autonomie de démonstration et un chaos en production. La solution est architecturale — transférer le contrôle de l'exécution vers un moteur déterministe, une approche détaillée dans notre livre blanc sur l'architecture d'une IA d'entreprise résiliente au-delà de la simple enveloppe de LLM, et ne laisser au modèle que ce pour quoi il est fait : raisonner sur un contenu au sein de limites bien définies.

Comment nous construisons des pipelines d'IA déterministes

Notre approche s'appuie sur des moteurs d'exécution durable — Temporal, Prefect ou Inngest, choisis en fonction de votre infrastructure existante — comme colonne vertébrale de l'orchestration. Chaque étape constitue une activité ou une tâche dotée d'entrées, de sorties, de politiques de réessai et de budgets de délai d'expiration explicites. Le moteur gère l'état, traite les défaillances et fournit la capacité de point de contrôle et de rejeu qui rend le débogage possible.

À chaque nœud où un LLM génère une sortie, nous encapsulons l'appel dans un harnais de validation qui impose des schémas de sortie avec l'outil adapté à la situation. Chaque approche présentant des modes de défaillance distincts, nous adaptons la stratégie de validation à la tolérance aux erreurs et au budget de latence de chaque nœud :

L'appel d'outils passe par un planificateur contraint, et non par une génération libre du LLM. Plutôt que de présenter 50 outils en espérant que le modèle choisisse correctement, nous filtrons le catalogue d'outils en fonction de l'état actuel du workflow, de sorte que le modèle ne voie que les outils valides pour cette étape. Cela élimine les noms d'outils hallucinés et les schémas d'arguments invalides — les deux modes de défaillance les plus fréquents lors de l'appel d'outils en production.

Points de contrôle, rejeu et équation économique

Un workflow à trois agents coûtant entre 5 et 50 $ en démonstration génère entre 18 000 et 90 000 $ de factures mensuelles en production. 96 % des entreprises déclarent que les coûts de la GenAI ont dépassé leurs prévisions. La majeure partie de ce gaspillage provient de la réexécution d'étapes réussies après une défaillance en aval.

Les points de contrôle bouleversent cette équation économique. Dès qu'un nœud est terminé, le moteur capture un instantané de l'état complet — entrées, sorties, métadonnées, tâches en attente. Lorsqu'une défaillance survient à l'étape 7 sur 10, vous corrigez le problème et rejouez à partir de l'étape 7, et non de l'étape 1. LangGraph atteint un taux de récupération d'erreurs de 96 % avec cette approche. Le modèle d'exécution durable de Temporal va plus loin : il survit aux plantages de processus et reprend exactement là où le workflow s'est arrêté, y compris pour les appels de LLM en cours d'exécution.

Nous concevons des stratégies de points de contrôle intégrant :

• Des identifiants de threads déterministes liés à des entités métier — une demande de prêt, un dossier médical, une confirmation de transaction boursière.
• Des appels externes idempotents articulés autour de l'identité combinée du workflow et de l'étape.
• Des tests délibérés par injection de pannes.

La seule gestion par points de contrôle réduit les traitements gaspillés de 60 % ou plus sur les flux de travail à étapes multiples.

Gouvernance des outils en production

L'adoption de MCP progresse plus vite que sa sécurisation. L'analyse de près de 2 000 serveurs MCP exposés sur Internet n'a révélé aucune authentification sur l'ensemble d'entre eux, mettant en péril environ 200 000 serveurs. Il existe également un problème de coût : un simple serveur MCP GitHub consomme environ 50 000 tokens rien que pour son initialisation, et un serveur de base de données doté de 106 outils engloutit 54 600 tokens avant même la moindre requête.

Nous concevons des interfaces d'outils gouvernées quel que soit le protocole utilisé par vos outils. Chaque appel d'outil transite par une couche de validation qui vérifie les types et plages d'entrées, applique des limites de débit et des quotas de ressources, valide le format de sortie et consigne l'intégralité du contexte d'invocation. La sélection des outils est pilotée par l'état : le moteur de workflow détermine les outils disponibles à chaque étape en fonction de l'état courant et des capacités déclarées de l'étape. Il ne s'agit pas d'une suggestion adressée au modèle — c'est une contrainte stricte imposée au niveau de l'infrastructure.

Architecture pensée pour l'audit pour les secteurs régulés

Les contrôles SOX, la gestion des risques de modèles SR 11-7, HIPAA, l'EU AI Act et les directives d'aide à la décision clinique de la FDA exigent tous une combinaison de reproductibilité, de traçabilité et d'explicabilité. Greffer un outil d'observabilité sur un framework d'agents après le déploiement ne suffit pas à répondre à ces exigences. C'est l'architecture elle-même qui doit produire la piste d'audit.

Les pipelines que nous concevons sont configurés pour journaliser chaque appel de LLM avec son prompt complet, sa réponse, son résultat de validation, son nombre de réessais et son identifiant de point de contrôle. Chaque transition d'état est immuable. Les définitions de workflow sont versionnées et associées à des versions de modèles spécifiques, de sorte que les auditeurs puissent reconstituer le pipeline exact ayant généré n'importe quelle sortie historique. Pour les environnements GxP, nous concevons des versions de workflow verrouillées sur des points de contrôle de modèles validés assortis de processus formels de gestion du changement — le type même de pipeline clinique déterministe que nous illustrons dans notre démonstration fonctionnelle de sécurité de l'IA clinique.