Article

Quand remplacer un agent IA par un workflow prévisible

Quand les étapes et les règles se stabilisent, un workflow peut remplacer le travail répété de l’agent. Il reste à tester le code et à organiser sa maintenance.

Chaque semaine, un agent télécharge les mêmes données, applique les mêmes filtres et produit le même rapport. S'il n'a plus de choix nouveau à faire, un programme peut exécuter ces étapes directement. Le passage à un workflow consiste à conserver la procédure devenue stable, à la tester et à réserver le modèle aux étapes qui demandent encore une interprétation.
L'escalier de capitalisation : code éphémère, script nommé, outil réutilisable, API
L'escalier de capitalisation, du code éphémère à l'API : le passage du probabiliste au déterministe.

Distinguer l'exploration d'une procédure déjà connue

Lors de la première exécution, l'agent peut devoir chercher les bonnes sources, comprendre les fichiers et essayer plusieurs traitements. Une fois le chemin connu, il peut être inutile de lui demander de le redécouvrir à chaque rapport.

Je commencerais par stabiliser une étape répétitive, plutôt que de remplacer tout le parcours d'un coup. Cela permet de mesurer ce qui devient plus rapide, moins coûteux et plus facile à vérifier.

La sortie progressive du modèle demande des règles explicites : quelles entrées sont acceptées, quel résultat est attendu, quelles erreurs sont possibles et que faire dans chaque cas. Une réussite ponctuelle ne fournit pas à elle seule cette description.

Ce que la bascule fait gagner

  • La fiabilité : un code déterministe donne toujours le même résultat, et vous pouvez exiger qu'il soit idempotent, donc relançable sans dégât.
  • La latence : plus d'appel au modèle dans le cas normal.
  • Le coût : vous ne payez plus un modèle pour refaire une décision déjà prise.
  • L'auditabilité : un programme se lit, se teste et se versionne ; une décision de modèle, beaucoup moins.

Basculez dès que les cas se répètent et que les règles se stabilisent

Il faut aussi que les contrôles soient explicites. La capacité passe alors dans un workflow déterministe ou un outil dédié, et l'agent se replie sur les exceptions et le cadrage. Tant que les entrées restent ambiguës ou variables, il garde sa place.

Anthropic (2024) fait la même distinction : les workflows suivent des chemins de code définis d'avance, les agents dirigent eux-mêmes leur exécution. Anthropic recommande de réserver les agents aux cas où leur souplesse vaut son surcoût. Ma lecture y ajoute une trajectoire : industrialiser, c'est faire passer une capacité des agents aux workflows, à mesure qu'elle se stabilise.

Transformer la procédure en code testé

Le code produit pendant l'exploration peut servir de point de départ. Il faut le relire, retirer les hypothèses propres au premier essai et définir ses paramètres. Une procédure en langage naturel reste utile pour comprendre l'intention et assurer la maintenance ; l'exécution répétée repose sur le programme.

Le papier CodeAct établit la première moitié du raisonnement : un agent gagne à agir en code exécutable plutôt qu'en JSON, parce que le code forme un espace d'action unifié. Il s'arrête là. Le modèle y reste dans la boucle, à chaque tour. Je vais plus loin, et cette part est la mienne : ce code sort de la boucle, et se rejoue sans personne.

Le passage se fait par marches.

MarcheCe qui resteCe que le modèle fait encore
Code éphémèrele code écrit et exécuté pour la tâche du momenttout : il écrit et décide
Script nomméun code qui a fait ses preuves, rappelé tel quelil choisit quand l'appeler
Outil réutilisableun programme paramétrable, exécuté hors du modèleil fournit les paramètres
API ou serviceun point d'entrée testé, surveillé, que d'autres peuvent appelerplus rien dans le cas normal

À chaque étape, une part du parcours devient explicite et testable. Le gain de fiabilité dépend ensuite de la qualité du code, de ses tests et de ses dépendances. Un programme déterministe peut reproduire fidèlement une erreur s'il a été mal conçu.

Garder le modèle pour les étapes qui le nécessitent

Certaines étapes peuvent rester variables : comprendre une demande libre, choisir entre des sources nouvelles ou expliquer un résultat. Vous pouvez conserver le modèle à ces endroits et automatiser les calculs ou transferts connus. L'article sur le choix d'un LLM aide à délimiter ces responsabilités.

Pour chaque tâche confiée à un agent, demandez-vous si ses entrées sont encore ambiguës ou variables. Si ce n'est plus le cas, faites-la monter d'une marche.

Le programme doit enfin avoir un responsable, des versions identifiables et une surveillance adaptée. Si une API change ou si un fichier ne respecte plus le format attendu, le traitement doit signaler l'écart. Retirer le modèle ne retire pas le besoin de maintenance.

Sources

Explorer

Sur le même sujet

Choisis dans l’index d’après les étiquettes de cet article — les plus proches d’abord, hors de sa série. Rien n’est écrit à la main : un article publié demain avec les mêmes étiquettes y prendra place.

Laisser un commentaire

Elle n'est jamais affichée ni publiée. Elle sert à regrouper vos commentaires et, si vous vous inscrivez un jour avec elle, à vous les rendre.

Votre commentaire sera relu avant d'être publié.