A2UI et AG-UI : concevoir une interface métier pilotée par un agent IA

Un outil d’exploration de données peut proposer des dizaines de filtres et rester difficile à utiliser. L’utilisateur connaît sa question, mais pas nécessairement le jeu de données, la métrique ou la visualisation qui permettra d’y répondre. Ajouter une conversation à côté du dashboard ne résout qu’une partie du problème.

L’approche que je privilégie consiste à partir de l’intention métier, puis à composer la vue utile. Pour un dirigeant, cela peut rendre une analyse accessible sans solliciter systématiquement un analyste. Pour votre équipe technique, cela impose une architecture précise : qui décide de la représentation, qui calcule les chiffres, et quelles libertés donne-t-on au modèle ?

Partir d’une question exploitable

Prenons un exemple illustratif dans la distribution. « Quel est mon chiffre d’affaires ce mois-ci ? » peut appeler un indicateur accompagné de sa période et de sa définition. « Comment évolue-t-il par région et par canal depuis trois ans ? » demande une série temporelle, une comparaison et éventuellement un tableau de détail.

Avant de choisir un composant, l’application doit toutefois lever des ambiguïtés. Parle-t-on de commandes, de factures ou d’encaissements ? Le mois est-il complet ? Faut-il déduire les avoirs ? Une belle courbe sur une mauvaise définition du chiffre d’affaires reste une mauvaise réponse.

Je sépare donc la demande en trois objets : une intention comprise, un plan de requête validé et une proposition de présentation. Le modèle peut contribuer aux trois, mais chaque objet est contrôlé avant d’alimenter le suivant. Une ambiguïté importante déclenche une clarification ; elle ne doit pas disparaître derrière une visualisation convaincante.

A2UI définit ce que le client peut afficher

A2UI permet de décrire une interface de manière déclarative. L’agent produit des messages structurés ; le client les interprète avec un catalogue de composants. Votre application conserve ainsi la responsabilité du rendu, du style et des composants autorisés. Le protocole distingue les descriptions d’interface de leur implémentation concrète. Documentation des catalogues A2UI.

Dans le cas précédent, je définirais un catalogue limité : indicateur, série temporelle, tableau, filtre et bloc d’explication. Pour chaque composant, le contrat préciserait les propriétés acceptées, les formats de données et les interactions possibles. Un graphique demanderait notamment une unité, un axe temporel cohérent et une référence aux données validées.

Cela évite de demander au modèle de réinventer une interface complète à chaque échange. Votre équipe développe et teste les composants ; l’agent choisit leur combinaison dans ce périmètre. L’identité visuelle et les comportements d’accessibilité restent des propriétés de l’application.

Cette séparation ne dispense pas de contrôles. Les textes restent des contenus non fiables, les destinations des liens doivent être maîtrisées et les actions proposées doivent correspondre à des opérations autorisées. Un composant connu peut toujours afficher une information incorrecte ou déclencher une demande inappropriée si ses entrées ne sont pas validées.

AG-UI relie le déroulement de l’agent à l’écran

AG-UI couvre une autre responsabilité : les échanges entre le backend agentique et l’interface. Il définit des événements pour le cycle d’exécution, les messages, les appels d’outils et la synchronisation d’état. L’écran peut ainsi suivre une opération au lieu d’attendre une réponse finale opaque. Événements AG-UI.

A2UI et AG-UI sont complémentaires : le premier décrit une interface, le second peut transporter les échanges qui la font évoluer. Leur combinaison est une option d’architecture, pas une obligation. Positionnement des protocoles dans la documentation A2UI.

Si votre orchestration utilise LangGraph, une intégration AG-UI permet de connecter ses graphes à une application cliente. Il faut choisir et configurer cet adaptateur ; la présence de LangGraph ne rend pas automatiquement votre frontend compatible. Intégration officielle AG-UI pour LangGraph.

Garder les calculs et les droits côté serveur

Pour un outil analytique, je recommande de faire passer les requêtes par une couche métier. Le modèle sélectionne une métrique et des dimensions dans un vocabulaire documenté. Le serveur vérifie les droits, applique les filtres d’organisation et exécute les calculs selon les définitions retenues.

Dans notre exemple, la proposition pourrait demander « chiffre d’affaires facturé, par mois et par région ». Le backend vérifierait la disponibilité de ces dimensions avant de construire une requête. Les montants proviendraient de la base ; l’agent rédigerait ensuite une synthèse à partir du résultat. Une valeur absente resterait absente, avec une explication, plutôt que complétée par génération.

Je prévoirais également des limites de période, de volume et de durée. Une demande très large ne doit pas lancer sans contrôle une jointure coûteuse sur les données de production. Un résultat agrégé et paginé peut être plus utile qu’un export exhaustif injecté dans le contexte du modèle.

Concevoir aussi les états incomplets

Le parcours nominal ne suffit pas pour évaluer cette architecture. Que voit l’utilisateur lorsqu’une source répond lentement ? Lorsqu’il change de filtre pendant une analyse ? Lorsqu’une reconnexion ramène un résultat associé à sa demande précédente ?

Je rattache chaque résultat à l’identifiant de sa demande et à ses paramètres. L’interface distingue les valeurs confirmées, les chargements et les erreurs. Une mise à jour tardive ne doit pas écraser une vue plus récente. Les interactions importantes doivent aussi conserver une stabilité visuelle : déplacer un bouton pendant que l’utilisateur clique crée un problème que le protocole ne résout pas à votre place.

L’observabilité des agents permet ensuite de relier demande, sélection des composants, requêtes et rendu. On peut comprendre si un échec vient de l’intention, des données ou de leur présentation.

Où cette approche mérite un investissement

Je la considère particulièrement pertinente quand les utilisateurs explorent des combinaisons variables de données et que les vues prédéfinies couvrent mal leurs questions. Un écran réglementé ou un processus répétitif avec quelques actions stables peut rester plus efficace avec une interface classique.

Pour décider, je propose de partir d’un parcours limité, de définir les questions réellement utiles et de comparer l’interface adaptative à votre fonctionnement actuel. Les critères sont concrets : exactitude des indicateurs, temps nécessaire pour trouver la réponse, fréquence des clarifications et compréhension des résultats.

Chez LeoWeb, je peux vous accompagner sur ce cadrage, le contrat entre agent et frontend et l’intégration aux données métier. Si votre outil interne accumule les écrans sans rendre l’analyse plus accessible, échangeons sur un premier parcours à simplifier.