AG-UI : La Nouvelle Vague d’Applications d’Agents IA Vient d’Être Lancée

AG-UI : La Nouvelle Vague d’Applications d’Agents IA Vient d’Être Lancée

AG-UI : La Nouvelle Vague d’Applications d’Agents IA Vient d’Être Lancée

2025 a définitivement été l’année des agents IA, mais plus encore, c’est l’année des protocoles d’agents comme le MCP d’Anthropic, qui facilite la connexion d’outils à nos agents, ou l’A2A de Google, qui permet une intégration fluide entre différents agents. Cependant, malgré la puissance de ces protocoles, il manque encore une pièce essentielle.

En effet, si nous voulons que nos utilisateurs puissent interagir avec nos agents, nous avons besoin d’une interface, d’un moyen de transformer notre agent en une application complète. Jusqu’à présent, il n’existait pas de standard pour connecter facilement nos agents à n’importe quelle interface, comme nous pouvons le faire avec des outils et d’autres agents.

Mais tout cela vient de changer avec l’introduction d’AGUI. Il s’agit d’un protocole permettant de connecter vos agents à votre interface et à vos utilisateurs de manière standardisée. Et tout comme MCP et A2A, je pense que ce protocole va vraiment s’imposer comme un véritable changement de paradigme.

Dans cet article, je vais vous présenter AGUI et vous montrer comment l’utiliser. Il vaut vraiment la peine d’investir du temps pour apprendre ce protocole dès maintenant, car il représente la pièce manquante pour faire passer vos agents au niveau supérieur en les transformant en applications complètes. Alors, plongeons directement dans le sujet.

Qu’est-ce qu’AGUI et pourquoi est-ce important ?

Voici l’annonce officielle d’AGUI, développé par l’équipe CopilotKit. Si vous ne le saviez pas, Copilot Kit est une bibliothèque front-end open-source pour construire des applications basées sur des agents. Il est donc logique que cette équipe ait développé ce type de standard pour connecter nos interfaces aux agents.

Le graphique présenté montre clairement comment cela fonctionne. Nous avons AGUI qui sert d’intermédiaire, tout comme MCP, entre notre application construite avec quelque chose comme React et nos agents IA développés avec des frameworks comme Langraph, Crew AI ou Pyantic AI. C’est un protocole qui rend cette connexion très fluide, à l’image de MCP et A2A.

Cette approche est extrêmement puissante car elle nous permet de connecter nos agents aux utilisateurs, ce qui est crucial. En effet, la plupart des agents nécessitent une interaction avec les utilisateurs. La documentation fait d’ailleurs une distinction intéressante entre agents autonomes et agents conversationnels. CopilotKit et AGUI ne seront pas utiles si nous avons un agent fonctionnant entièrement de manière autonome, en arrière-plan. Mais pour la plupart des agents, nous voulons que les utilisateurs puissent travailler avec eux, notamment pour des aspects comme le « human in the loop » (l’humain dans la boucle), afin de s’assurer que nous restons partie prenante du processus, quelle que soit l’action de l’agent.

Ainsi, nous voulons presque toujours une interface pour travailler avec nos agents. Mais avant AGUI, ce n’était pas facile à mettre en place.

Les défis résolus par AGUI

Il existe de nombreux défis liés à la construction d’une interface connectée à notre agent sans un standard comme AGUI :

  1. Sortie en temps réel : Il est désormais attendu que votre agent IA produise la sortie en temps réel, donnant l’impression que l’agent tape la réponse, comme dans Claude ou GPT. Mais ce n’est pas trivial à mettre en place. Vous avez besoin d’un point d’API qui exécute votre agent et diffuse ces tokens en temps réel vers votre interface, qui doit également les gérer correctement.

  2. Orchestration d’outils : Lorsque votre agent utilise différents outils, l’interface doit souvent montrer la progression et les résultats de ces outils. Il y a de nombreux composants impliqués dans une seule exécution d’agent que vous voulez afficher dans votre interface.

  3. Prolifération des frameworks : Il existe de nombreuses façons de construire nos agents en back-end avec Langchain, Crew AI, Mao, etc. Mais ils fonctionnent tous légèrement différemment. Nous devons connecter notre interface à des agents construits avec ces frameworks de manières différentes, réinventer des adaptateurs et gérer différents cas particuliers. Avec AGUI comme intermédiaire standardisé entre les interfaces et ces différents frameworks, nous avons beaucoup moins à nous soucier de ces problèmes dans nos interfaces.

Le meilleur aspect est qu’AGUI est complètement open-source et c’est un standard qui ne dépend pas d’un framework spécifique. Tout comme avec MCP (Anthropic a construit le Model Context Protocol mais nous ne sommes pas obligés d’utiliser Claude comme LLM), avec AGUI, développé par Copilot Kit, nous pouvons construire n’importe quelle interface avec n’importe quel framework et la connecter à n’importe quel agent.

Comment fonctionne AGUI

Voici comment cela fonctionne : l’utilisateur interagit avec notre application construite avec React (ou autre). Puis nous avons cet intermédiaire, AGUI, qui nous connecte à nos agents IA. Chaque fois que notre agent effectue une opération, comme diffuser du texte ou faire un appel d’outil, nous émettons des événements standard via AGUI vers notre interface.

Ainsi, notre interface dispose d’une méthode standardisée pour afficher tout ce que fait l’agent. C’est ce qui résout bon nombre des problèmes mentionnés précédemment concernant la diffusion en temps réel, l’orchestration d’outils et la prolifération des frameworks. Nous n’avons plus qu’à nous appuyer sur ces événements entrants dans notre interface, les affichant comme nous le souhaitons, en utilisant éventuellement Copilot Kit pour faciliter le développement front-end.

Mise en pratique d’AGUI : un exemple concret

Passons maintenant à la pratique avec un exemple complet pour voir AGUI en action. Dans la documentation officielle d’AGUI, que je vous recommande de consulter, ils expliquent comment construire un agent IA en back-end compatible avec ce protocole, et comment développer des applications front-end qui fonctionnent avec AGUI pour connecter nos agents à nos utilisateurs.

Je vais vous guider à travers les deux aspects. Je vais parcourir le guide de démarrage rapide pour vous montrer comment AGUI fonctionne à un niveau fondamental, puis je vous montrerai comment construire des agents en back-end avec AGUI et comment nous pouvons utiliser n’importe quel framework.

Pour suivre ce tutoriel, vous aurez besoin de quelques prérequis : Node.js, npm et une clé API OpenAI. Vous pouvez ensuite suivre les instructions pour cloner le dépôt contenant l’exemple, installer toutes les dépendances et l’exécuter.

Démonstration et exemples

Voici la démo que j’ai lancée, que vous pouvez reproduire en une minute environ. Nous pouvons explorer quelques exemples fournis pour voir AGUI en action. Tout est intégré avec Copilot Kit, mais rappelez-vous que nous n’avons pas à utiliser Copilot Kit avec AGUI – cela simplifie simplement les choses.

Dans le premier exemple, je peux obtenir une réponse basique du LLM qui s’affiche en streaming. C’est aussi un exemple d’utilisation d’AGUI pour des outils front-end : je peux dire « change the background to red » (change l’arrière-plan en rouge), et notre backend envoie une réponse qui indique à l’interface de mettre à jour la couleur d’arrière-plan. Essayons maintenant avec « change it to blue » (change-le en bleu) et voilà, c’est fait rapidement.

Essayons un autre exemple, l’interface utilisateur générative basée sur des outils. Ici, nous allons parler à notre agent et la sortie sera interactive, nous permettant de modifier ce que nous voyons. Je vais dire « generate a haiku about AI » (génère un haïku sur l’IA) et voilà notre haïku. Je peux ensuite interagir avec l’appel d’outil dans l’interface pour l’appliquer, ce qui va mettre à jour un autre état dans notre interface.

Ces exemples montrent à haut niveau comment nous pouvons rendre notre agent IA super interactif avec des appels d’outils directement dans notre interface. Sans quelque chose comme AGUI, ce ne serait pas si facile.

Les composants clés d’AGUI

Revenons aux composants fondamentaux qui rendent tout cela possible. Le cœur d’AGUI, ce sont tous ces événements que notre backend émet vers notre frontend.

Voici un exemple simple : nous émettons un événement indiquant que l’exécution a commencé, avec l’ID du fil de discussion pour suivre la conversation spécifique, et un ID pour l’exécution actuelle. Ces métadonnées sont importantes pour pouvoir récupérer l’historique de la conversation si nécessaire.

Ensuite, nous indiquons que nous commençons un message, nous diffusons le contenu, puis nous signalons la fin du message. À la fin de l’exécution de l’agent, nous émettons un événement final indiquant que l’exécution est terminée.

Lorsque nous utilisons un LLM comme GPT-4.1 Mini, le processus est similaire. Nous commençons par émettre un événement indiquant que l’exécution a démarré, puis nous utilisons le client OpenAI pour obtenir une réponse. Nous fournissons également des outils, comme la possibilité de changer la couleur d’arrière-plan.

Nous transmettons l’historique de la conversation depuis le frontend avec AGUI, puis nous commençons à recevoir la réponse. Nous parcourons tous les fragments (chunks) que nous recevons en temps réel de GPT-4.1 Mini et nous les envoyons au fur et à mesure. Nous renvoyons le delta, c’est-à-dire les fragments les plus récents produits, afin que notre frontend puisse construire la réponse progressivement, l’affichant en temps réel à l’utilisateur.

Pour les appels d’outils, nous faisons la même chose, mais au lieu d’un événement de fragment de message texte, c’est un événement de fragment d’appel d’outil. Nous indiquons au frontend que tous les paramètres sont liés à un appel d’outil, comme changer la couleur de notre arrière-plan.

Une fois tout cela terminé, nous envoyons un dernier message indiquant que l’exécution est terminée, afin que le frontend sache qu’il peut passer à ce qu’il doit faire après l’exécution de l’agent, comme indiquer à l’utilisateur qu’il peut envoyer son prochain message.

Nous avons également la possibilité d’envoyer des événements d’erreur, ce qui est important pour s’assurer que lorsqu’une erreur survient dans le backend, l’application ne plante pas simplement sans que le frontend ne sache ce qui s’est passé. Nous pouvons envoyer un événement qui indique à notre frontend quel problème l’agent a rencontré afin que nous puissions le gérer de manière appropriée.

Au total, il existe 16 types d’événements que nous pouvons envoyer. C’est tout ce que notre frontend pourrait avoir besoin de savoir sur ce qui se passe avec notre agent IA.

Flexibilité et interopérabilité

L’un des aspects les plus puissants d’AGUI est que vous n’êtes pas limité à l’utilisation d’OpenAI. Vous pouvez utiliser n’importe quel LLM, n’importe quel framework, tant que vous émettez ces événements standard qui montrent les différents appels d’outils et messages de sortie. Peu importe ce que vous utilisez, vous pourrez le faire avec AGUI.

La façon dont nous exploitons cet agent en tant que point d’API dépendra du framework que vous utilisez. Dans les exemples présentés, ils utilisent Copilot Kit. Dans notre page React principale, nous configurons cette instance de Copilot Kit en lui donnant cette URL d’exécution qui pointe vers ce point d’API où cet agent s’exécute.

Je ne vais pas trop approfondir Copilot Kit maintenant, il mérite son propre tutoriel. Mais en résumé, Copilot Kit nous donne un moyen de configurer ces composants React pour interagir avec nos agents via des points d’API qui implémentent des choses comme AGUI.

Vous n’êtes pas obligé d’utiliser Copilot Kit. Vous pourriez construire quelque chose entièrement par vous-même qui exploiterait ces différents événements que nous recevons de notre point d’API compatible AGUI. Vous pouvez surveiller les messages texte et les diffuser, surveiller les appels d’outils et les afficher comme vous le souhaitez. Il y a beaucoup de flexibilité ici.

Utilisation d’AGUI avec un backend Python

J’ai pu facilement adapter cet exemple pour utiliser un backend Python pour mon agent au lieu de quelque chose construit en JavaScript comme le frontend. Dans la documentation, sous « Build with AGUI », vous pouvez voir l’exemple utilisant Python.

C’est très similaire à ce que nous avons vu, où nous allons simplement générer ces différents événements comme le début de l’exécution, la fin de l’exécution, ou le prochain message texte. Cela ressemblera beaucoup à ce que nous avons vu, mais cette fois en Python. Nous pouvons utiliser des bibliothèques comme Crew AI ou Pyantic AI.

J’ai créé un point d’API Fast API hébergé avec /AWP. J’obtiens l’ID du message, puis j’envoie cet événement indiquant que je commence la réponse de l’agent. J’utilise GPT-4.1 Mini comme je l’ai fait avec JavaScript, puis je vais parcourir tous les fragments que je reçois dans le flux lorsque je diffuse la réponse du LLM. Je vais envoyer beaucoup de ces fragments en les générant, et le type d’événement pour chacun d’eux est simplement « text_message_content ». J’envoie également ce delta pour que nous puissions construire cette réponse au fil du temps dans le frontend. Puis j’envoie « text_message_end » et « run_finished » à la fin.

C’est un exemple basique qui ne gère pas les appels d’outils, donc je ne peux pas changer l’arrière-plan avec cet agent comme je peux le faire avec celui en JavaScript. Mais je voulais juste vous montrer à un niveau très basique comment nous pouvons utiliser Python à la place.

En revenant à mon agent personnalisé, j’ai remplacé tout le code par ce que j’ai créé (avec l’aide d’un assistant de codage IA bien sûr) pour utiliser notre point d’API Python. Au lieu d’avoir toute la logique ici pour interagir avec GPT-4.1 Mini, je vais maintenant appeler ce point d’API que j’ai en cours d’exécution. Nous allons créer ce lecteur où nous allons simplement traiter le flux, affichant les choses exactement de la même manière que lorsque nous avions tout implémenté en JavaScript.

Dans notre frontend, j’ai également le terminal ouvert pour vous montrer que nous utilisons maintenant notre point d’API Python avec AGUI. Je vais envoyer un message comme « what are the best AI agent frameworks » (quels sont les meilleurs frameworks d’agents IA). Nous pouvons voir que nous avons maintenant une requête POST vers notre point d’API, nous obtenons notre réponse diffusée de manière très fluide.

C’était aussi facile d’adapter, en changeant essentiellement complètement notre agent sous le capot, mais il est connecté à notre frontend de la même manière. C’est la principale chose que je voulais vous montrer : je suis passé d’un agent JavaScript à un agent Python, ce qui pourrait signifier passer de MRA à Crew AI, ou ce que vous voulez faire, mais je n’ai toujours pas à changer quoi que ce soit dans le frontend. Je peux toujours interagir avec l’agent exactement de la même manière.

Développement assisté par IA avec AGUI

Si tout cela vous semble compliqué, ne vous inquiétez pas. Vous n’êtes pas seul. Les développeurs d’AGUI fournissent un moyen très simple d’utiliser des assistants de codage IA comme Windsurf et Cursor pour vous aider à construire avec AGUI, tant pour développer vos agents et vos backends compatibles que pour construire vos frontends avec votre propre code ou en utilisant un outil comme Copilot Kit.

Dans la documentation, si vous faites défiler vers le bas, vous verrez « Developing with Cursor », ils ont ce fichier llms-fold.ext. Vous pouvez le prendre et le donner comme documentation à votre assistant de codage IA. Cursor a leur fonction de documentation intégrée, vous pouvez simplement coller cela dans votre prompt. Il existe également des serveurs MCP comme le mien pour l’IA où vous pourriez explorer cela et l’utiliser comme base de connaissances RAG pour Windsurf, Ruode ou ce que vous voulez faire.

Cela rend donc très accessible la construction avec AGUI, connectant vos agents à vos utilisateurs.

L’état actuel d’AGUI

La dernière chose que je veux aborder est l’état actuel d’AGUI. Évidemment, ce protocole est tout nouveau et n’est donc pas super mature à ce stade. Comme je l’ai dit, il vaut certainement la peine d’explorer ce protocole, de commencer à apprendre comment il fonctionne, mais peut-être pas de l’utiliser pour absolument tout tout de suite. Je n’irais pas jusque-là car il y a encore beaucoup à développer.

Nous avons vu cela avec d’autres protocoles comme MCP et A2A. A2A n’a toujours pas été largement adopté. Et MCP commence à l’être, mais cela a pris du temps. C’est en novembre de l’année dernière que MCP a été publié pour la première fois par Anthropic. Il n’a pas été largement adopté avant mars de cette année environ, soit quatre ou cinq mois plus tard. La principale raison était qu’au début, leur documentation n’était pas la meilleure, le protocole n’était pas le plus mature et gérait à peine des aspects comme la sécurité.

Je pense que nous voyons beaucoup de cela avec AGUI, du moins pour commencer. Et honnêtement, ils font un bien meilleur travail que MCP au début. Donc, bravo à eux. Je suis très impressionné. Et oui, c’était vraiment facile à utiliser. Et cela a définitivement du sens la façon dont ils ont configuré tous ces différents événements pour nos agents et comment cela communique avec le frontend.

Conclusion

Voilà qui conclut notre introduction à AGUI. Je vais certainement continuer à suivre ce protocole, peut-être même commencer à l’intégrer dans mes propres applications. Si cela vous a intéressé et que vous souhaitez approfondir la construction d’applications basées sur des agents, je vous encourage à explorer davantage ce domaine passionnant.

AGUI représente une avancée significative dans la façon dont nous connectons nos agents IA aux utilisateurs, comblant une lacune importante dans l’écosystème des agents. Bien qu’il soit encore à ses débuts, le potentiel est immense, et il vaut la peine de commencer à l’explorer dès maintenant pour être prêt lorsqu’il deviendra un standard incontournable dans le développement d’applications basées sur des agents IA.