workflow

En profondeur

Un workflow s’écrit avant de s’exécuter : des étapes qui agissent à travers des outils, des conditions de passage, des branches, des reprises en cas d’échec. Cette écriture préalable a des conséquences que l’on sous-estime : le chemin suivi est reproductible, donc auditable et testable étape par étape, et une panne se localise. Le coût devient prévisible lui aussi, puisque le nombre d’appels au modèle est connu avant de lancer quoi que ce soit. On rejoue un workflow à l’identique, et c’est précisément ce qu’on ne peut pas promettre d’un agent.

La distinction décisive avec l’agent ne porte ni sur la complexité, ni sur la présence d’un modèle, mais sur l’endroit où se prend la décision. Une étape peut très bien confier à un modèle le soin de classer une demande, puis orienter vers l’une des branches prévues : la décision reste dans le plan, écrit par un humain. Dans un agent, le plan n’existe pas à l’avance, car le modèle observe l’état du travail et choisit la suite, tour après tour. Entre les deux se loge une zone grise, celle des enchaînements dont la structure est fixée mais dont certains choix sont délégués ; c’est elle que l’on qualifie le plus souvent, un peu vite, d’agentique.

Le premier piège est de payer l’imprévisibilité d’un agent là où un workflow suffisait : si vous savez écrire les étapes, les écrire coûte moins cher et se surveille mieux. Le second lui répond en miroir, car un workflow devient ingérable quand les exceptions se multiplient, chaque cas particulier ajoutant une branche jusqu’à ce que le plan ne soit plus compréhensible par personne. C’est ce foisonnement, et non l’envie d’autonomie, qui justifie honnêtement de passer à un agent. Enfin, une part des systèmes présentés comme des agents sont des workflows : ce n’est pas un défaut, mais cela change ce qu’il faut en attendre et ce qu’il faut mesurer.