Les premières démonstrations d’agents IA se font presque toujours dans une console. C’est logique. La console simplifie tout : pas d’interface graphique, pas d’état visuel, pas de gestion fine de l’expérience utilisateur, pas de transport HTTP apparent, pas de rendu progressif à synchroniser avec une UI. Mais la réalité est un peu différente de ce cadre simplifié et il faut une architecture solide ...
Pour apprendre les fondamentaux d’un framework agentique, la console c’est même souvent la meilleure approche.
Mais il faut être clair : une console n’est pas un produit fini.
Elle permet de vérifier qu’un agent répond. Elle ne montre pas comment cet agent s’insère dans une application réelle. Elle ne dit rien de la fluidité perçue, de la séparation des responsabilités, de la testabilité, de l’intégration avec un frontend, ni de la façon dont plusieurs interfaces pourraient exploiter le même moteur agentique.
C’est précisément le sujet de ma nouvelle vidéo : « UI Desktop & Web pour Agent IA ».
L’objectif n’est pas de faire une jolie fenêtre. L’objectif est beaucoup plus important : montrer comment exposer proprement un agent Microsoft Agent Framework derrière une vraie interface applicative.
La console masque le vrai problème
Quand on regarde une démo console, on a facilement l’impression que le cœur du sujet est l’appel au modèle.
On envoie un prompt, l’agent répond, le résultat s’affiche. Cela donne l’illusion que l’intégration est simple.
En réalité, dans une application professionnelle, l’appel au modèle n’est qu’une partie du problème.
Dès que l’on passe à une interface, plusieurs questions apparaissent immédiatement :
- comment afficher une réponse qui arrive progressivement ?
- comment signaler que l’agent est en train de travailler ?
- comment gérer les erreurs sans casser l’expérience utilisateur ?
- comment éviter de bloquer le thread UI ?
- comment séparer la logique agentique de la logique de présentation ?
- comment réutiliser le même agent depuis une autre interface ?
- comment tester le backend sans dépendre de WPF ?
- comment faire évoluer l’agent sans réécrire l’écran ?
Ces questions sont absentes ou invisibles dans une console.
Et c’est précisément pour cela qu’il faut en sortir.
Un agent n’est pas une fenêtre
Le piège classique consiste à mettre trop de logique dans l’interface.
Dans une application WPF ou même Web, cela peut prendre une forme très concrète : on commence avec une fenêtre simple, puis on ajoute progressivement dans le code-behind l’appel au modèle, les instructions de l’agent, la gestion des messages, le formatage, les paramètres, les erreurs, les retries, voire certains outils métiers.
Au bout de quelques itérations, l’interface devient un mélange de présentation, de transport, de logique applicative et de logique agentique.
Cela ne marche pas, ou plutôt : cela marche au début, puis cela se dégrade.
Un agent ne doit pas être pensé comme un composant visuel. Il doit être pensé comme un moteur applicatif.
L’interface est là pour permettre à l’utilisateur d’interagir avec ce moteur. Elle ne doit pas devenir le lieu où toute l’intelligence est assemblée.
Une architecture plus saine consiste à séparer clairement les rôles :
Interface WPF/Web...
│
▼
Backend ASP.NET Core
│
▼
Agent Microsoft Agent Framework
│
▼
Modèle / outils / contexte
Serveur(s) MCP
Cette structure change complètement la nature du projet.
L’interface reste concentrée sur l’expérience utilisateur. Le backend expose des points d’entrée clairs. L’agent reste isolé dans une couche où l’on peut gérer ses instructions, ses dépendances, ses outils et son évolution.
C’est beaucoup plus propre.
Important : Je donne ici l'exemple de l'intégration d'un Agent avec un frontend type WPF ou Web, mais la logique présentée, le concept architectural développé, reste valable même dans le cas où l'Agent est utilisé "en sous marin", sans interaction aussi franche et directe avec l'utilisateur. La présence d'une UI permet de rendre la démo et sa vidéo plus agréable mais rien n'oblige la présence d'une UI, en revanche tout oblige à utiliser l'architecture proposée !
Pourquoi ajouter un backend entre WPF et l’agent ?
On pourrait objecter que dans le cas précis d'une application desktop type WPF, le code est capable d’appeler directement un agent .NET localement.
Techniquement, oui.
Architecturalement, ce n’est pas toujours le meilleur choix.
L’ajout d’un backend ASP.NET Core, même local, apporte plusieurs bénéfices immédiats.
- Une frontière claire
Le backend devient le point d’entrée de l’intelligence applicative.
L’interface n’a pas besoin de connaître les détails de construction de l’agent, ses instructions système, ses plugins, son modèle, ses dépendances ou ses stratégies internes.
Elle envoie une requête. Elle reçoit une réponse.
C’est une frontière simple, lisible, testable.
- Une meilleure testabilité
Un endpoint HTTP peut être testé indépendamment de WPF ou de toute autre application utilisatrice.
On peut vérifier :
- le format des requêtes ;
- le comportement du backend ;
- les erreurs ;
- le streaming ;
- les temps de réponse ;
- les cas limites ;
- la stabilité des contrats.
C’est beaucoup plus difficile lorsque toute la logique est mélangée dans le même code que le programme appelant.
- La possibilité de multiplier les frontends
C’est sans doute le bénéfice le plus important.
Si l’agent est correctement exposé par un backend, alors WPF n’est qu’un client parmi d’autres.
On peut imaginer :
- une application WPF ;
- un frontend web (second exemple de la vidéo);
- une interface mobile ;
- un client MAUI ;
- un outil interne en ligne de commande ;
- une intégration dans un autre logiciel.
Tous peuvent exploiter le même agent, sans recoder l’intelligence à chaque fois.
C’est exactement ce que montre la vidéo avec une démonstration WPF, puis un frontend Web consommant le même agent côté serveur.
Le point important n’est donc pas WPF contre Web. Le point important est que l’agent ne dépend pas du frontend.
La réponse progressive change la perception du produit
Un détail paraît parfois secondaire dans les démonstrations agentiques : le streaming de la réponse.
Pourtant, côté utilisateur, c’est un élément majeur.
Une réponse qui arrive progressivement donne immédiatement une impression de fluidité. L’application semble active. L’utilisateur voit que quelque chose se passe. L’attente devient plus acceptable.
À l’inverse, une réponse qui arrive d’un seul bloc après plusieurs secondes peut donner l’impression que l’application est bloquée, même si le traitement fonctionne correctement. Il existe bien entendu des cas où le mode progressif n'est pas intéressant (surtout si l'agent est consommé par le code sans interaction directement avec l'utilisateur).
Dans une application avec UI, cette différence est particulièrement sensible.
Une bonne intégration visuelle doit donc gérer proprement :
- l’appel asynchrone au backend ;
- la réception progressive des fragments ;
- la mise à jour de l’interface sans bloquer le thread UI ;
- l’état visuel pendant le traitement ;
- l’annulation éventuelle ;
- la fin du flux ;
- les erreurs intermédiaires.
Ce n’est pas du décor. C’est de l’intégration produit.
Un agent qui répond bien mais dont l’interface se fige pendant cinq secondes donne une mauvaise impression. À l’inverse, une interface sobre, stable, avec une réponse progressive et un état visible, suffit souvent à rendre le système crédible.
Si l'agent n'est pas connecté directement avec du visuel mais effectue un traitement qui demande à l"utilisateur d'attendre on utilisera alors d'autres procédés type "sablier" ou autre artifice visuel pour indiquer clairement l'état du système.
WPF reste un excellent terrain pour ce type d’intégration
La vidéo et cet article ne sont pas du tout destinés à promouvoir WPF bien que cela reste pour moi le seul véritable XAML, le plus beau, le plus puissant jamais égalé même chez Microsoft (et d'ailleurs ils le font toujours évoluer, ce n'est pas sans raison). Mais je veux en dire quelques mots tout de même.
D'autant qu'il est de bon ton, depuis des années, d’opposer WPF aux technologies plus récentes. Mais c’est souvent une mauvaise lecture du sujet.
WPF reste très pertinent dès que l’on parle d’applications desktop professionnelles sous Windows, notamment dans des contextes où l’on doit intégrer :
- des processus métiers existants ;
- des applications internes ;
- des composants desktop riches ;
- des flux de données locaux ;
- des outils d’administration ;
- des postes utilisateurs contrôlés ;
- des environnements industriels ou métier.
Pour intégrer un agent IA dans une application d’entreprise existante, WPF est donc loin d’être hors sujet.
Au contraire, il représente un cas très réaliste : beaucoup d’applications professionnelles importantes sont encore en WPF, et toutes ne vont pas être réécrites en Web ou en MAUI du jour au lendemain. En l'état de ces technologies ce n'est pas même souhaitable pour beaucoup d'applications WPF.
La bonne question n’est donc pas : “Faut-il abandonner WPF pour faire de l’IA ?”
La bonne question est :
Comment injecter proprement de l’intelligence dans une application WPF sans détruire son architecture ? Chacun remplacera dans cette phrase "WPF" par le frontend qu'il préfère.
Et la réponse passe rarement par un gros bloc de code dans le code-behind. Peu importe la techno et ce qui correspond à du code-behind dans celle-ci. Ce n'est pas non plus le rôle d'un ViewModel en MVVM par exemple.
Le code de l'appelant ne doit pas devenir le cerveau de l’application
Dans une démonstration courte, il est normal d’utiliser un peu de code-behind pour orchestrer l’interface. Cela peut être parfaitement acceptable si le code reste limité à son rôle : gérer l’interaction utilisateur et mettre à jour la vue. Mais même là, on préfèrera découpler en utilisant MVVM. Alors que dire du découplage avec l'IA !
Mais il faut éviter la dérive classique : faire du code de l'appelant le centre de l’application.
Dans une architecture WPF ou Web plus industrialisée, on cherchera généralement à respecter une séparation du type :
Vue (WPF, Web, MAUI, WinUI...)
│
▼
ViewModel (ou équivelent)
│
▼
Service client HTTP
│
▼
Backend agentique
Le ViewModel peut gérer l’état affichable :
- message saisi ;
- historique ;
- indicateur de chargement ;
- réponse en cours ;
- erreurs utilisateur ;
- commandes disponibles.
Le service HTTP peut gérer la communication avec le backend.
Le backend peut gérer l’agent. Il sera généralement impléménté sous la forme d'un service injectable.
L’agent peut gérer le raisonnement, les instructions, les outils et les appels au modèle.
Cette séparation n’est pas de la théorie. Elle évite que le code de l'appelant devienne impossible à maintenir dès que le scénario s’enrichit.
Un “chat” visuel ne signifie pas que l’on construit seulement un chatbot
C’est un point important.
Dès qu’une interface affiche une zone de saisie, un historique et une réponse générée progressivement, elle ressemble à un chat.
Mais cela ne signifie pas que l’on construit seulement un chatbot.
Derrière cette apparence, on peut très bien avoir un véritable agent capable de :
- interroger des outils ;
- consulter des données ;
- appeler des services métier ;
- analyser un contexte ;
- produire une synthèse ;
- déclencher une action ;
- orchestrer plusieurs étapes.
L’interface de type conversationnel n’est qu’un mode d’interaction. Il a l'avantage d'être intuitif et visuel, c'est pour cela que j'ai choisi ce type d'affichage pour les 2 démos de la vidéo. Mais ne vous l'aissez pas tromper !
Il faut donc éviter de réduire l’intégration agentique à une imitation de ChatGPT dans une fenêtre WPF ou Web. Ce serait une erreur.
L’enjeu réel est de permettre à l’utilisateur d’interagir naturellement avec une capacité logicielle plus riche que ce que l’on peut produire avec des formulaires classiques ou des menus traditionnels. Mais c'est juste un choix esthétique pour le visuel des démos.
Ce que montre la vidéo
Dans la vidéo, je pars d’une idée simple : un agent utile doit pouvoir être exposé proprement dans une vraie application.
La première démonstration repose sur une architecture volontairement lisible :
Client WPF
│
▼
Backend ASP.NET Core
│
▼
Agent Microsoft Agent Framework
Le backend propose notamment un point d’entrée permettant de recevoir une réponse progressive.
Le client WPF affiche une interface sobre : une zone de saisie, un historique, un état visible, puis une réponse qui s’écrit au fil de l’eau.
Ensuite, une démonstration complémentaire montre qu’un frontend Web peut consommer le même agent, preuve que la séparation initiale n’est pas décorative mais réellement structurante. Dans l'UI de la version Web j'ai placé deux boutons pour envoyer la question, l'un donne une réponse directe, l'autre utilise justement le mode "streaming" de l'Agent (mode progressif) cela permet de tester et voir la diférence entre ces deux méthodes.
Ce qu’il faut observer, ce n’est donc pas seulement le rendu visuel.
Ce qu’il faut observer, c’est l’architecture :
- l’agent n’est pas codé dans la fenêtre ;
- le backend centralise la logique agentique ;
- l’interface reste remplaçable ;
- le streaming améliore la perception utilisateur ;
- le même moteur peut servir plusieurs frontends.
C’est cela qui rend la démonstration intéressante.
Ce que cette approche apporte dans un projet réel
Dans un projet professionnel, cette architecture donne trois bénéfices majeurs.
- Centralisation
L’agent, ses instructions et ses points d’entrée vivent côté backend.
Cela évite de disperser la logique agentique dans plusieurs clients.
- Remplaçabilité
On peut faire évoluer l’interface sans réécrire l’agent.
On peut également exposer le même agent à une autre interface, par exemple Web, sans repartir de zéro.
- Crédibilité produit
Une application qui affiche proprement l’état du traitement, diffuse progressivement la réponse et garde une interface stable paraît immédiatement plus professionnelle.
Ce n’est pas une question d’esthétique gratuite. C’est une question de qualité perçue et de robustesse applicative. C'est aussi ce qu'on appelle l'UX.
Le vrai message : intégrer l’IA sans casser l’architecture
L’intégration de l’IA dans les applications ne doit pas se faire au détriment des principes d’architecture que nous connaissons déjà.
Au contraire, plus l’IA devient puissante, plus il faut être rigoureux.
Un agent peut comprendre du langage naturel, raisonner sur un contexte, sélectionner des outils, produire des synthèses ou assister l’utilisateur. C’est précisément pour cela qu’il faut l’encadrer correctement.
Il ne faut pas confondre puissance fonctionnelle et désordre architectural.
La bonne approche consiste à garder :
- une UI sobre ;
- un backend clair ;
- un agent isolé ;
- des contrats explicites ;
- une gestion propre du flux ;
- une séparation nette entre présentation, transport et logique agentique.
C’est ce que cette vidéo illustre concrètement.
En résumé
Sortir de la console n’est pas une étape cosmétique.
C’est le moment où l’on découvre les vrais problèmes d’intégration : interface, flux, état, découplage, testabilité, réutilisation et expérience utilisateur.
Une console permet de prouver qu’un agent répond. Une application WPF ou Web bien conçue permet de montrer comment cet agent peut devenir une vraie capacité applicative.
Et c’est toute la différence.
Voir la vidéo : UI Desktop & Web pour Agents IA https://youtu.be/9zuLajUF8G0
Stay Tuned !