Des flux de travail où les agents décident du chemin

Un agent seul répond. Mais quand le travail a des étapes, des conditions et des moments où quelqu'un doit approuver, une réponse ne suffit pas : il faut un processus. Microsoft Foundry propose une façon déclarative de les construire (déclaratif : vous décrivez ce qui doit se passer, vous n'écrivez pas le code qui le fait se passer) : des workflows pilotés par agents, dessinés comme des nœuds connectés. Le module « Build agent-driven workflows with Microsoft Foundry » les couvre de bout en bout. Ce qui suit l'explique par parties : ce qu'est un flux, comment il s'enrute, ce qu'apporte Power Fx, comment il se maintient et quand il vaut mieux dessiner que coder.

Ce qu'est un workflow piloté par agent

C'est l'orchestration visuelle et déclarative d'actions contrôlées par l'IA. Au lieu de code, vous définissez une séquence d'étapes : des nœuds connectés (nœuds : les petites boîtes du canevas, chacune avec une tâche) qui forment un chemin d'exécution. La plateforme exécute le flux et gère son état. Vous combinez raisonnement IA, logique et interaction utilisateur dans le même processus. La partie déclarative change où vit la logique : le chemin est sur le canevas, pas dans un code que vous compilez et déployez.

Et il y a une deuxième raison d'être, moins évidente : coordonner plusieurs agents avec des responsabilités différentes. Classification, décision, résolution. Chacun fait la sienne et le flux les fait travailler sur le même cas, avec des motifs qui équilibrent automatisation et supervision, comme les pauses pour approbation humaine. C'est la façon déclarative d'orchestrer : ce qui s'écrivait avant en code, ici se dessine.

Le scénario qui le justifie

L'exemple de référence est un triage d'incidents de support SaaS, choisi parce que c'est le cas où un agent seul reste court : classifier il le fait bien, décider de la suite pour chaque cas est déjà un processus. Un flux combine plusieurs agents IA, de la logique conditionnelle et une escalade humaine. Les incidents sont classés en facturation, erreurs d'API et questions simples. Le flux applique la même logique aux trois : classifier, regarder la confiance et décider entre réponse automatique ou revue manuelle. Ceux de faible confiance s'escaladent à un humain avec le contexte de l'incident.

flowchart TD
    I[Un incident de support arrive] --> C[L'agent le classe : facturation, erreur d'API ou question simple]
    C --> P{Le score de confiance dépasse-t-il 0,8 ?}
    P -->|Oui| R[Réponse automatique, sans toucher à la file]
    P -->|Non| H[Escalade vers un humain avec le contexte de l'incident]

En clair : ce qui est clair se résout tout seul, ce qui est douteux est vu par une personne, et cette décision ne se cache pas dans le code : elle est dessinée dans le flux, avec son seuil en vue.

C'est le problème qu'un agent seul ne résout pas sans code : le chemin change selon le cas. Le flux rend ce branching visible et éditable. Et l'équilibre est dit dans l'exemple : automatiser le clair, réviser le douteux et escalader le basse confiance sans bloquer toute la file. Le motif tient même si cent incidents arrivent par heure : le flux est le même, les données qui le parcourent changent.

Les cinq types de nœuds

Le concepteur visuel offre des motifs prédéfinis, comme le séquentiel, et des nœuds de cinq familles. La classification sert à lire un flux que vous n'avez pas écrit : en regardant le type de nœud vous savez s'il y a un agent en scène, une décision ou seulement des données qui bougent. Les cinq courent le parcours complet : agents, décisions, données, conversation avec l'utilisateur et fin.

Invoke : invoque ou crée des agents du projet, avec sortie texte libre ou structurée en JSON (JSON, le format avec lequel les systèmes échangent des données).
Flow : If/Else pour bifurquer, Go to pour sauter et For-Each pour itérer des collections.
Transformation de données : Set variable, Reset variable et Parse value pour extraire des données des sorties structurées.
Chat basique : messages et questions à l'utilisateur.
End : marque la conclusion, avec résultat ou état optionnel.

Un détail à garder clair : pour invoquer un agent vous utilisez le nœud Invoke Agent. Les nœuds logiques bifurquent et les nœuds de transformation de données manipulent des variables, et aucun des deux n'invoque d'agents. La frontière est simple : Invoke met les agents en scène ; Flow décide du chemin ; transformation déplace les données.

Invoke Agent et la sortie qui prédit le flux

Pour ajouter un agent au flux, on insère un nœud Invoke Agent. Depuis là on configure ses outils, bases de connaissances, mémoire et garde-fous : le même panneau de contrôle qu'en dehors du flux, maintenant comme une petite boîte du canevas. Et si l'agent dont vous avez besoin n'existe pas encore, le même nœud le crée : Invoke invoque un agent du projet ou en crée un nouveau.

La clé est dans la sortie. Si vous la définissez avec un schéma JSON dans les paramètres de l'éditeur (un schéma est un contrat : il dit à l'agent quels champs exacts il doit renvoyer), la réponse de l'agent sort prévisible. Une sortie prévisible peut être stockée dans une variable, évaluée avec des conditions et utilisée pour déclencher des étapes suivantes : routage, affectation de variables, activation de branches. La capture est simple : la sortie du nœud est enregistrée dans une variable et référencée le long du flux. De là viennent les décisions que vous prenez ensuite. Cette sortie est la matière première du flux, pas la réponse que voit l'utilisateur. Ce n'est jamais du texte libre pour la fin : ce sont des données pour que le flux décide.

Power Fx : la colle

Power Fx est le langage low-code façon Excel qui soutient la logique du flux. Qui sait faire un tableur lit les conditions du flux sans traduire rien. Il évalue des expressions sur des variables du système (activité courant, dernier message, informations de l'utilisateur) et des variables locales. Trois usages typiques : convertir les entrées avec Upper(Local.Input), évaluer des conditions avec Local.Confidence > 0.8 et sommer des listes avec Sum(Local.ItemList, Amount). Ses lieux d'usage sont les conditions If/Else et les boucles For-Each. Le seuil de 0,8 du diagramme vit ici : une formule que n'importe qui lit sans être programmeur.

L'exemple de confiance referme le cercle. L'agent renvoie un score de confiance comme sortie structurée. Un nœud If/Else évalue Local.Confidence > 0.8 pour continuer automatiquement ou escalader à un humain. Un nœud For-Each parcourt la liste des tickets avec Sum(Local.ItemList, Amount) et applique les mêmes actions par élément. For-Each répond justement à ce cas : gérer plusieurs tickets sans dupliquer nœuds ni logiques. If/Else bifurque par condition et le nœud de message conversa avec l'utilisateur. La formule de confiance du diagramme ci-dessus vit dans un nœud If/Else, et la liste des tickets est traitée une seule fois quoi qu'elle grossisse.

Les trois motifs

Le concepteur offre trois motifs de flux, et la différence est combien de décision le flux laisse seul :

Séquentiel : étape par étape prévisible. Quand le chemin ne change pas, comme une recette qui a toujours les mêmes étapes dans le même ordre.
Human-in-the-loop : pauses pour approbation ou contexte. Quand quelque chose de sensible dépend d'une personne avant de continuer. C'est un motif de design, pas un patch collé dessus.
Chat de groupe : contrôle dynamique entre plusieurs agents. Quand plusieurs agents parlent entre eux et que quelqu'un doit décider qui suit.

Le maintenir : canevas, YAML et versions

Le flux a une représentation double : canevas et YAML synchronisés (YAML, un fichier texte brut avec la configuration du flux, du même style que celui des agents déclaratifs). Vous dessinez où cela vous convient le mieux et les deux vues restent alignées. Le YAML rend possible ce que le canevas seul ne donne pas : revue, modèles et diff. Chaque enregistrement crée une version immuable, donc annuler un changement est possible sans risquer ce qui précédait. Et les notes attachées aux nœuds laissent du contexte pour qui maintiendra le flux ensuite. C'est la raison pour laquelle un flux survit à son auteur : le YAML et les notes servent de mémoire. Quand le flux passe à plusieurs mainteneurs, cette mémoire fait la différence entre le comprendre en cinq minutes et le reconstruire.

L'invoquer depuis le code

Le flux dessiné ne reste pas dans le portail. Avec AIProjectClient et le client compatible OpenAI on crée une conversation et on invoque le flux par nom (le code vous sera familier si vous avez déjà appelé une API Responses) :

responses.create(
    conversation,
    input,
    extra_body={"agent": {"name": NOMBRE, "type": "agent_reference"}},
    stream=True,
)

Ensuite les événements du stream sont traités : response.completed, la sortie de messages et les sorties de nœuds. « En streaming » veut dire que les morceaux de réponse arrivent au fur et à mesure, sans attendre le bloc final. Ligne par ligne, l'appel fait trois choses : reprend la conversation, envoie la saisie de l'utilisateur et dit au client que ce qu'il invoque est un flux par nom (agent_reference), pas un agent. Le détail qui compte : ce qui s'invoque par nom, c'est le flux. Le stream amène le résultat de nœud en nœud jusqu'à ce que la réponse se complète.

Du canevas au portail

Ce qui n'a pas tourné, c'est l'exercice du portail Foundry (créer un workflow piloté par agent) : il exige un abonnement Azure. Le streaming des événements de flux n'a pas non plus été testé dans une vraie application (response.output_item.do_snapshot et compagnie), donc ce comportement n'a toujours pas d'essai propre. Le post a couvert les nœuds, les sorties structurées, Power Fx et les motifs.

Si vous allez consommer un flux en streaming, ce comportement est le premier point à tester dans votre labo, avant de promettre des délais à qui que ce soit. Et l'ordre recommandé pour démarrer est celui du post : d'abord le scénario avec une seule branche, ensuite les sorties structurées qui l'alimentent, ensuite Power Fx et seulement après les motifs avec intervention humaine.

Mon avis

Le déclencheur pour dessiner, c'est le processus avec des décisions : si votre agent fait une chose, restez avec l'agent seul. Quand apparaissent des branches, des étapes répétées ou un humain qui approuve, le flux dessiné vous laisse voir et toucher la logique sans toucher au code. L'intervention humaine non plus ne reste hors du flux : c'est une pause de plus, avec son approbation et son contexte. Et il y a une condition pour que tout le reste fonctionne : la sortie structurée. Sans schéma JSON, pas de variables, pas de branches et pas d'escalade ; il reste un agent qui répond du texte libre.

---

*Source : le module « Build agent-driven workflows with Microsoft Foundry » de Microsoft Learn.*