Des agents IA fiables ont besoin de deux modes : workflows et boucles de vérification

La plupart des démos d’agents IA échouent au moment précis où le vrai travail commence : l’étape sept.

Les six premières étapes ont l’air magiques. Le modèle comprend la demande, appelle un outil, trouve un document, met à jour une fiche et écrit quelque chose de malin. Puis une petite hypothèse se révèle fausse, l’action suivante l’aggrave, et l’agent annonce avec assurance que le travail est terminé.

Ce n’est pas un problème d’intelligence. C’est un problème d’architecture. Des agents IA fiables ont besoin de deux modes de fonctionnement distincts : des workflows déterministes pour le chemin que tu connais déjà, et des boucles de vérification pour les parties où le modèle doit explorer, juger et prouver que le travail est fini.

Le piège de l’autonomie

On a fait d’« autonome » le plus beau compliment possible pour un logiciel. Ce n’en est pas un. L’autonomie est utile quand le chemin ne peut pas être connu à l’avance. Partout ailleurs, c’est souvent une façon très coûteuse de remplacer une checklist.

Anthropic fait la distinction utile : les workflows font passer les modèles et les outils par des chemins de code prédéfinis, tandis que les agents décident dynamiquement de leur propre processus et de leur usage des outils. Leur conseil pratique est d’une sobriété rafraîchissante : commence par la solution la plus simple, puis n’ajoute de la complexité que lorsqu’elle justifie sa latence et son coût.

Je suis d’accord. Si un processus consiste toujours à « récupérer ces entreprises, nettoyer ces pages, extraire ces champs, valider le résultat et rédiger le rapport », laisser un agent réinventer ce chemin à chaque exécution, ce n’est pas de la flexibilité. C’est de la variance déguisée avec un chapeau malin.

Utilise un workflow déterministe quand le chemin est connu

Un workflow déterministe ne veut pas dire que chaque étape est du code bête. Les modèles peuvent toujours classer, extraire, résumer et décider au sein d’une étape délimitée. La différence, c’est que le système autour maîtrise la séquence, les outils autorisés, le contrat de données et la gestion des échecs.

C’est le bon choix par défaut pour les processus longs et répétables, avec des entrées et des sorties claires. L’enrichissement de données d’entreprises en est un bon exemple. Tu peux avoir besoin du jugement d’un modèle pour sélectionner le texte pertinent ou extraire des personnes de pages désordonnées, mais le pipeline lui-même ne devrait pas se réveiller chaque matin en se demandant ce que veut dire enrichir.

Des étapes fixes rendent aussi l’évaluation possible. Tu peux comparer des nettoyeurs, des tailles de découpage, des niveaux de modèles et des fournisseurs de secours sans changer cinq variables à la fois. Quand la qualité baisse, tu sais où regarder. Quand les coûts montent, tu peux les attribuer à une étape au lieu de hausser les épaules devant une trace d’agent géante.

C’est important, parce que la fiabilité n’est pas un score unique. C’est une chaîne. Le rappel de la sélection, la précision de l’extraction, les échecs d’outils, les sorties mal formées et les doublons peuvent chacun sembler acceptables isolément tout en produisant ensemble un mauvais résultat final.

Utilise une boucle d’agent quand la définition de « terminé » demande du jugement

Certaines tâches n’ont pas de chemin fixe. « Trouve pourquoi ce déploiement échoue et corrige-le » peut demander de lire des logs, d’inspecter du code, de lancer des tests, de changer d’hypothèse et de réessayer. Un workflow rigide peut devenir d’une complexité absurde, parce qu’il doit encoder chaque branche possible.

C’est là qu’un agent mérite son autonomie. Mais la boucle a besoin d’un objectif, de contraintes et d’une définition externe de « terminé ». L’agent doit planifier, agir, observer le résultat, évaluer les preuves et continuer jusqu’à ce que les critères d’acceptation soient remplis ou qu’une décision humaine soit nécessaire.

C’est proche de la boucle autonome qu’Anthropic décrit dans ses travaux sur les agents dignes de confiance : planifier, agir, observer, ajuster et recommencer. Point essentiel, ces mêmes travaux insistent sur le fait que des agents utiles ont toujours besoin d’un contrôle humain, de points d’étape calibrés et de garde-fous au niveau du modèle, du harnais d’exécution, des outils et de l’environnement.

« Terminé » est une affirmation. La preuve est le produit

La phrase la plus dangereuse d’un logiciel d’agent, c’est « Tâche terminée avec succès ». Elle ressemble à une preuve, mais ce n’est qu’une sortie de modèle de plus.

Un système fiable exige des preuves que l’agent ne peut pas simuler à coups d’assurance. Pour du code, ce sont des tests qui passent, une vérification de types propre et un diff limité aux fichiers demandés. Pour de la recherche, la couverture des sources, les dates et la vérification des contradictions. Pour de l’enrichissement de données, la validation du schéma, la déduplication, les taux de contacts joignables et un examen des cas atypiques les plus coûteux.

Les recommandations d’OpenAI traitent désormais ce sujet comme une discipline d’ingénierie plutôt que comme une décoration de prompt. Son guide d’évaluation des agents recommande des évaluations reproductibles, tandis que le trace grading note les décisions, les appels d’outils et le raisonnement au sein d’une exécution. La distinction est importante : une réponse finale chanceuse peut cacher un processus désastreux.

L’évaluateur a lui aussi besoin d’être calibré. Trop indulgent, la boucle s’arrête trop tôt. Trop strict, l’agent brûle de l’argent à peaufiner un travail que personne n’a demandé. Commence par des critères d’acceptation explicites, teste-les sur des exemples relus par des humains, et suis les faux succès avec autant de sérieux que les échecs.

Route l’intelligence selon l’étape, pas selon l’ego

Toutes les étapes ne méritent pas ton modèle le plus cher. Planifier dans l’incertitude peut demander beaucoup d’intelligence. Nettoyer du texte, appliquer une transformation connue ou vérifier un schéma simple, en général non.

C’est devenu encore plus pertinent le 30 juillet 2026, quand OpenAI a baissé le prix de GPT-5.6 Luna de 80 %. La leçon utile n’est pas « utilise le modèle bon marché partout ». C’est de relancer tes évaluations. Les anciennes hypothèses de coût expirent dès que le prix ou les performances d’un modèle changent.

L’architecture la plus solide utilise souvent un modèle plus capable pour lever l’ambiguïté et définir le plan, puis un modèle plus rapide pour exécuter les étapes bien spécifiées, lancer les tests et évaluer les résultats de routine. OpenAI donne d’ailleurs un exemple similaire, appliqué au code, dans cette annonce tarifaire. Le routage des modèles doit se mesurer au résultat, pas se choisir d’après une capture d’écran de classement.

L’architecture que je livrerais

Pour un système sérieux en plusieurs étapes, je mettrais un workflow déterministe autour du processus métier stable et je n’insérerais des boucles d’agent que là où le chemin exige vraiment de la découverte. Chaque boucle aurait un budget, une condition d’arrêt, des outils autorisés et des critères d’acceptation fondés sur des preuves. Les actions à fort impact exigeraient une validation humaine. Chaque exécution laisserait une trace évaluable après coup.

C’est aussi la direction produit que je trouve la plus utile pour Notis : des Workflows pour les séquences répétables, et des Goals pour les tâches où le stagiaire IA doit continuer à travailler jusqu’à pouvoir prouver que le résultat répond au brief. L’utilisateur ne devrait pas avoir à surveiller chaque clic, mais le système ne devrait jamais confondre silence et succès.

La prochaine fois que quelqu’un propose « un seul agent autonome » pour une opération en 20 étapes, pose une question moins glamour : quelles étapes ont vraiment besoin d’autonomie ?

Cette question t’épargnera plus d’argent, de débogage et de démos gênantes que n’importe quel prompt astucieux.