Dot.Blog

Dans beaucoup de projets, l’Agent IA finit par recevoir une responsabilité qui ne devrait jamais lui appartenir.

Au départ, tout semble raisonnable. On lui demande d’interpréter une intention, de sélectionner un outil, de produire un brouillon, de reformuler une sortie ou de classifier une demande. Tant que le problème reste ouvert, avec une part réelle d’exploration ou d’ambiguïté, cette approche tient encore debout.

Mais ce cadre s’effondre dès que le processus est connu.

À partir du moment où l’on sait déjà qu’il faut analyser une demande, vérifier si elle est exploitable, demander une précision quand elle ne l’est pas, enrichir les données lorsqu’elle devient claire, puis produire un contrat final, on n’est plus face à une simple tâche linguistique. On est face à un processus.

Et un processus n’a pas vocation à être improvisé par un modèle.

C’est le sujet central de cette vidéo consacrée auw Frameworks avec Microsoft Agent Framework en C#.

Voir la vidéo : https://youtu.be/4C-AePnMiHY

Que valent les plans générés par le LLM ou Workflow ?

Un plan JSON généré par un LLM n’est pas un moteur de workflow.

Oui, un plan JSON peut être un pattern utile pour décider d’une sélection d’agent à utiliser dans un certain ordre. Oui, demander au modèle de proposer une séquence peut rendre service pour certains cas simples ou, au contraire, extrêmement variables en fonction du contexte. J'aborde cette question dans mon cours (Cours et Workshop Programmation Agentique). Mais cela ne change pas la nature du problème : tant que le modèle reste responsable de la structure du chemin, vous êtes encore dans une orchestration fragile.

Le problème n’est pas que le LLM soit mauvais. Le problème est que vous lui déléguez quelque chose qui relève de l’architecture.

Dans un vrai workflow :

• l’ordre des étapes est défini dans le code ;
• les branches sont explicites ;
• les transitions sont lisibles ;
• les points de contrôle sont identifiables ;
• le système devient observable ;
• l’agent conserve une place utile, mais à l’intérieur d’un cadre gouverné.

C’est exactement l’intérêt des Workflows de Microsoft Agent Framework. Le framework permet de modéliser un workflow sous forme de graphe avec exécuteurs, arêtes, routage conditionnel, événements et contrats typés. Autrement dit, il permet de sortir du bricolage consistant à envelopper un modèle avec quelques conventions en espérant obtenir une orchestration fiable.

Ce que la vidéo montre par l’exemple

Le cas retenu est volontairement simple : validation d’une demande métier avant exécution.

Le flot est le suivant :

• 1. analyser la demande ;
• 2. décider si elle est exploitable ;
• 3. demander une précision si elle est ambiguë ;
• 4. enrichir la demande si elle devient claire ;
• 5. produire un contrat final.

Ce qui compte ici n’est pas la complexité fonctionnelle. Ce qui compte, c’est la lisibilité architecturale et la fiabilité du process. Le spectateur doit voir immédiatement qu’il ne s’agit plus de demander à un agent de “trouver la bonne séquence”, mais d’exprimer un processus de manière explicite dans le code C#.

C’est là que la rupture devient nette.

Dans une architecture improvisée autour d’un agent, on essaie souvent de sécuriser après coup : on ajoute des validations, des garde-fous, des contraintes de sortie, puis d’autres validations encore. Ce travail n’est pas inutile, mais il arrive trop tard. Si le chemin lui-même devait être déterministe, c’est le chemin qu’il fallait reprendre en main.

Workflow Et LLM : Quel rapport de force ?

Il serait absurde de présenter les workflows comme un remplacement pur et simple des agents. Ce n’est pas le sujet. Un workflow n’existe pas pour éliminer le LLM. Il existe pour l’empêcher de gouverner ce qu’il ne devrait pas gouverner.

Le bon partage est simple.

L’agent reste utile pour ce qui relève du langage et de l’interprétation :

• reformuler ;
• classer ;
• résumer ;
• produire un texte intermédiaire ;
• aider à analyser une entrée incertaine.

Le workflow, lui, prend en charge ce qui relève de la structure du système :

• l’ordre ;
• le branchement ;
• les arrêts ;
• les transitions ;
• l’observabilité ;
• la cohérence globale du flot.

C’est cette hiérarchie qu’il faut rétablir. Trop de systèmes deviennent instables parce qu’un seul agent est censé planifier, arbitrer, agir, valider et suivre implicitement l’état du processus. Ce n’est pas une preuve d’intelligence. C’est une surcharge de responsabilité.

Agents et Workflows servent à englober des appels LLM, c’est la façon de le faire qui change. L’agent embarque toute sa logique et ses outils, le Workflow contraint le LLM dans un couloir déterministe.

Pourquoi l’Observabilité change tout

Le point souvent sous-estimé dans ce type de sujet est l’observabilité. Une architecture qui ne permet pas de voir clairement quel exécuteur a été invoqué, quelle branche a été suivie, où le flot s’est arrêté et quelle sortie a été produite reste faible, même si elle semble fonctionner pendant la démonstration.

Avec un workflow explicite, le chemin devient auditable.

Ce bénéfice paraît secondaire tant qu’on raisonne en mode prototype. Il devient central dès qu’il faut expliquer un comportement, investiguer une dérive, justifier une décision ou simplement comprendre pourquoi le système a suivi une branche plutôt qu’une autre.

Autrement dit : un bon workflow ne produit pas seulement un résultat. Il expose aussi la logique de son exécution. Il fait revenir le LLM dans le giron de l’informatique de gestion, dans un monde où 2 et 2 font toujours 4, où les bugs doivent être pistés, logués, gérés. Un monde où les décisions sont prévues par les concepteurs et non par des LLM au fonctionnement variable et à la compréhension fluctuante. Bref, on fait de nouveau de l’informatique et les LLM sont utilisés uniquement pour leur capacité linguistique ce que des centaines de pages C# ou de RegEx ne pourraient pas faire avec fiabilité.

Le vrai critère de décision

La bonne question n’est donc pas : “Puis-je faire cela avec un agent ?”

La bonne question est : “Le processus est-il déjà suffisamment connu pour que le chemin doive appartenir au code ?”

Si la réponse est non, un agent garde tout son intérêt.
Si la réponse est oui, il faut sortir de la logique “agent central” et assumer une orchestration explicite.

C’est la raison pour laquelle cette vidéo est utile. Elle ne propose pas une API de plus. Elle montre le moment où il faut changer de niveau de conception. Dans notre métier, très souvent, la bonne architecture résoud plus de problèmes que du bon code...

Quand un agent devient instable, le réflexe le plus courant consiste à retravailler le prompt, enrichir la sortie attendue ou multiplier les validations périphériques. Dans certains cas, cela aide. Mais dans d’autres, cela ne marche pas parce que le problème n’est plus dans le prompt. Il est dans l’architecture.

On ne “prompt” pas plus fort un mauvais découpage de responsabilités.

Voir la vidéo

La vidéo est disponible ici : https://youtu.be/4C-AePnMiHY

Si vous développez en C# et que vous cherchez à comprendre quand un agent doit cesser de piloter seul, cette vidéo met précisément le doigt sur ce basculement.

Elle montre aussi une chose importante : les workflows ne remplacent pas les agents. Ils leur imposent enfin un cadre cohérent en proposant une autre façon d’encapsuler les appels aux LLM.

Conclusion

Cet article et la vidéo font partie de mon effort constant d'information vers la communauté des développeurs et des entreprises qui utilisent les techniques Microsoft. Cela prend du temps, des moyens, mais je le fais avant tout avec plaisir et passion que j'espère partagée avec vous.
Mais je ne suis pas un être éthéré, je suis un consultant expert Dotnet, et je vis grâce à vous... Alors n'hésotez pas à me contacter !