Je passe mes semaines de travail au sein de grandes institutions financières, à observer des équipes présenter des démos d'« agents IA » qui, à y regarder de plus près, ne sont que des boîtes de discussion avec un prompt système. L'interface est un flux de texte. L'utilisateur voit des tokens. L'agent voit des tokens en retour. Rien d'autre n'existe. Et puis quelqu'un du côté des opérations pose la question qui tue la démo : « Où se passe l'approbation ? » Parce que le vrai travail n'est pas une conversation. Un flux d'intégration de patrimoine n'est pas « parlez-moi de vous ». C'est une vérification d'identité, puis une évaluation des risques, puis une décision de routage, puis un examen par un conseiller pour les cas qui le nécessitent, puis l'ouverture du compte. Chaque étape a un état, une sortie et une décision. Au moment où un agent calcule un score de risque, l'utilisateur ne veut pas une phrase décrivant le score. Il veut la jauge. Lorsqu'il propose une allocation, il veut le graphique en anneau sur lequel il peut cliquer, pas un paragraphe qui l'approxime. Ce guide porte sur AG-UI, le protocole qui comble cette lacune : un flux d'événements typés entre un backend agentique et un frontend destiné à l'utilisateur. J'en ai construit une implémentation de référence complète (AURUM, une démo fictive d'intégration de banque privée, dépôt public lié à la fin), avec un moteur de processus comme orchestrateur au lieu d'une boucle de discussion. Ce choix architectural s'est avéré plus important que le protocole lui-même, et la seconde moitié de ce guide explique pourquoi. Les modèles présentés ici sont agnostiques au framework. J'ai utilisé Camunda 8 parce que je le connais bien ; tout ce que j'affirme sur l'état externalisé s'applique également à Temporal, LangGraph avec un checkpointer, ou une machine à états que vous auriez écrite vous-même. ## Le problème : les tokens ne sont pas une interface Le streaming de tokens a résolu un problème de latence, pas un problème d'interface. Le streaming de tokens donne l'impression qu'un modèle lent est réactif. Il ne fait rien pour la forme réelle du travail. Considérez ce qu'un agent natif du chat ne peut pas vous montrer : - **Progression dans un processus.** « Étape 3 sur 6 » est un concept d'interface utilisateur. Un flux de tokens n'a pas d'étapes, seulement plus de tokens. - **Un appel d'outil comme objet de première classe.** L'agent a appelé `verifyIdentity` et a reçu `{status: "verified", method: "document+biometric"}`. C'est une carte avec une coche verte, pas une phrase que le modèle paraphrase (et paraphrase parfois mal). - **Une pause.** Un humain doit approuver cela. Dans une boucle de discussion, « en attente d'un humain » signifie que la requête est soit maintenue ouverte, soit perdue. Aucune des deux n'est une vraie pause. - **État structuré.** L'enregistrement d'intégration comporte 40 champs qui intéressent à la fois l'agent et l'interface utilisateur. Le sérialiser en prose à chaque tour est une perte dans les deux sens. Chaque équipe que j'ai vue se heurter à ce mur le résout de la même manière : elle invente un vocabulaire d'événements privé entre son backend et son frontend. Un blob JSON avec un champ `type`, une instruction `switch` dans React. Cela fonctionne, puis cela se calcifie. Les événements ne sont pas documentés, le frontend et le backend divergent, et le deuxième client (l'application mobile, le tableau de bord des opérations) doit faire de la rétro-ingénierie sur le dialecte. AG-UI est ce vocabulaire privé, standardisé. C'est tout l'argument, et c'est suffisant. ## Ce qu'est AG-UI AG-UI (Agent-User Interaction Protocol) est un protocole ouvert, basé sur les événements, qui standardise la manière dont un backend agentique communique avec une application destinée à l'utilisateur. Il est issu de CopilotKit, développé en partenariat avec LangGraph et CrewAI, et est maintenant disponible en open source sous l'organisation `ag-ui-protocol` sur GitHub. Le côté agent émet des événements typés sur un flux. Le côté application rend chaque événement. L'entrée utilisateur retourne sous forme de messages structurés. C'est tout le modèle. | Fait | Détail | |---|---| | Origine | CopilotKit, avec LangGraph et CrewAI ; open-sourcé sous `ag-ui-protocol` | | Forme | Flux d'événements unidirectionnel agent-vers-application, plus un canal d'entrée structuré application-vers-agent | | Vocabulaire d'événements de base | ~16 types d'événements dans la spécification originale, répartis en cinq catégories : cycle de vie d'exécution, messages texte, appels d'outils, gestion d'état et spéciaux (RAW, CUSTOM). La spécification actuelle s'est enrichie d'événements de commodité (chunk events) et d'événements de raisonnement | | Modèle d'état | Store typé partagé : `STATE_SNAPSHOT` pour l'état complet, `STATE_DELTA` pour les diffs JSON Patch RFC 6902 | | Transport | Agnostique au transport. Les Server-Sent Events (SSE) sont le transport par défaut et de référence ; HTTP simple et WebSockets fonctionnent également | | Humain dans la boucle | De première classe : pause, approbation, édition, réessai en cours d'exécution sans perte d'état | | Ce qu'il standardise | Les types d'événements, la forme de leurs charges utiles, la sémantique de l'ordonnancement et le mécanisme de synchronisation d'état | | Ce qu'il laisse ouvert | Comment vous rendez quoi que ce soit, les schémas de composants pour l'interface utilisateur générative, l'authentification, l'autorisation, la persistance | | Intégrations | Plus de 16 bindings de frameworks : LangGraph, CrewAI, Microsoft Agent Framework, Google ADK, AWS Strands, Pydantic AI, LlamaIndex, et d'autres | La philosophie de conception est la « correspondance de format souple » : AG-UI standardise le flux de l'état de l'agent et l'intention de l'interface utilisateur, pas les pixels. Un événement `TOOL_CALL_START` ne dit pas à votre frontend de rendre un spinner dans une carte aux coins arrondis. Il indique à votre frontend qu'un appel d'outil a commencé, avec un nom et un ID, et le reste est votre problème. C'est la bonne approche. Chaque tentative que j'ai vue de standardiser la couche de rendu elle-même meurt sous le poids de sa propre bibliothèque de composants. ## Sa place dans la pile de protocoles Le paysage des protocoles agentiques s'est organisé, sur environ dix-huit mois, en quatre couches par contrepartie. Je trouve que c'est le seul cadre qui permet de retenir les acronymes : | Protocole | Connecte l'agent à... | Origine | Rôle en une ligne | |---|---|---|---| | MCP | Outils et contexte | Anthropic | Donner des mains à l'agent : accès standardisé aux systèmes et aux données | | A2A | Autres agents | Google | Permettre aux agents de déléguer et de coordonner entre fournisseurs et runtimes | | AG-UI | L'humain | CopilotKit | Le dernier kilomètre : transformer l'activité de l'agent en quelque chose qu'une personne peut voir et cliquer | | AP2 | L'argent | Google + partenaires de paiement | Mandats cryptographiquement responsables pour les paiements initiés par l'agent |  Un système de production utilise fréquemment trois de ces protocoles à la fois, et de plus en plus les quatre. Dans AURUM, l'agent accède à ses outils via la couche d'orchestration (le connecteur d'agent IA de Camunda joue le rôle MCP de courtage d'outils), et tout ce que l'utilisateur voit repose sur AG-UI. Je couvre les autres couches en détail dans le [guide de terrain A2A](/fr/guides/a2a-field-guide/) et le [guide de terrain AP2](/fr/guides/ap2-field-guide/) ; ce document reste sur la couche humaine. Les couches sont véritablement orthogonales. Rien dans AG-UI ne suppose que MCP se trouve en dessous, et rien dans A2A ne suppose l'existence d'une surface AG-UI. Cette orthogonalité explique pourquoi vous pouvez les adopter indépendamment, ce qui est la manière dont l'adoption se produit réellement au sein des entreprises : un protocole par cycle budgétaire. ## Anatomie d'un événement Les événements AG-UI sont des objets JSON plats avec un discriminateur `type`. Cinq catégories font le travail. #### Cycle de vie d'exécution `RUN_STARTED`, `RUN_FINISHED`, `RUN_ERROR`, plus `STEP_STARTED` / `STEP_FINISHED` pour les phases nommées au sein d'une exécution. Ce sont les événements sur lesquels votre interface utilisateur de progression s'appuie. Une exécution porte un `threadId` et un `runId` ; les étapes portent un `stepName`. Dans AURUM, la console opérateur est essentiellement un moteur de rendu pour les événements de cycle de vie : chaque activité BPMN correspond à une étape, de sorte que le flux brut se lit comme un journal de processus parce qu'il en est un. #### Streaming de texte Trois événements par message, corrélés par `messageId` : ```json { "type": "TEXT_MESSAGE_START", "messageId": "msg_042", "role": "assistant" } { "type": "TEXT_MESSAGE_CONTENT", "messageId": "msg_042", "delta": "Your risk profile " } { "type": "TEXT_MESSAGE_CONTENT", "messageId": "msg_042", "delta": "suggests a balanced allocation." } { "type": "TEXT_MESSAGE_END", "messageId": "msg_042" } ``` Le triple début/contenu/fin semble bureaucratique à côté de « juste streamer la chaîne », mais les limites explicites sont ce qui permet à un client d'entrelacer plusieurs messages concurrents et de savoir, de manière déterministe, quand un message est complet plutôt que bloqué. #### Appels d'outils `TOOL_CALL_START` (nom et ID), `TOOL_CALL_ARGS` (deltas d'arguments streamés), `TOOL_CALL_END`, et `TOOL_CALL_RESULT`. C'est la catégorie qui sépare une interface utilisateur d'agent d'une interface utilisateur de chat. Le frontend peut rendre l'appel comme un objet avec son propre cycle de vie : en attente, en cours, résolu, avec des arguments et des résultats inspectables. Dans AURUM, `parseApplicationForm → {fieldsParsed: 12}` s'affiche comme une puce d'étape terminée dans la vue client et comme un événement brut dans la vue opérateur. Même événement, deux rendus. #### Synchronisation d'état `STATE_SNAPSHOT` transporte l'objet d'état partagé complet. `STATE_DELTA` transporte un tableau JSON Patch RFC 6902 : ```json { "type": "STATE_DELTA", "delta": [ { "op": "replace", "path": "/application/riskScore", "value": 72 }, { "op": "add", "path": "/application/flags/-", "value": "PEP_SCREEN_REQUIRED" } ] } ``` Instantanés à la connexion, deltas pendant le streaming. Le modèle est l'event-sourcing appliqué à l'état de l'interface utilisateur, et c'est la partie que la plupart des dialectes maison ratent en envoyant l'état complet à chaque changement et en se demandant pourquoi le flux est 40 fois plus grand qu'il ne devrait l'être. #### Interface utilisateur générative Ici, la spécification est délibérément non-opinionnée : l'interface utilisateur générative repose sur des événements d'appel d'outil rendus comme des composants, ou sur des événements `CUSTOM`. Mon dialecte de démo le nomme explicitement, ce que la spécification classerait comme un événement personnalisé : ```json { "type": "GENERATIVE_UI", "pid": "2251799813737463", "ts": 1719849302144, "component": "PortfolioAllocationChart", "props": { "equities": 60, "fixedIncome": 30, "alternatives": 10 } } ``` Le frontend contient un registre mappant les noms `component` à de vrais composants React (`IdentityResultCard`, `PortfolioAllocationChart`, `ProjectedGrowthChart`, `AccountOpenedCard`). Nom de composant inconnu ? Rendre une carte de secours avec les props brutes. Cette décision défensive a sauvé la démo deux fois pendant le développement, et c'est la différence entre un dialecte qui se dégrade et un qui affiche un écran blanc. Les règles d'ordonnancement sont simples et essentielles : traiter les événements dans l'ordre d'arrivée, et considérer les événements partageant un ID (`messageId`, `toolCallId`) comme un seul flux logique. Tout le reste dans un client découle de ces deux règles. ## Le modèle que j'ai prouvé : une interface utilisateur générative orchestrée par processus Voici la partie qui me tient le plus à cœur, car c'est la partie que la documentation du protocole ne peut pas vous dire. AG-UI standardise le fil. Il ne dit rien sur qui possède l'état derrière le fil. Dans chaque démarrage rapide de type CopilotKit, la réponse est la boucle de l'agent elle-même : un runtime de chat maintient la conversation, appelle le modèle, émet des événements. Cela fonctionne jusqu'à ce que le processus plante, ou qu'un humain ait besoin de trois jours pour décider, ou qu'un auditeur demande ce qui s'est passé le 14 mars. Dans AURUM, je l'ai inversé. L'orchestrateur est un moteur de processus (Camunda 8, BPMN), et le flux AG-UI est une projection de l'état du processus. Le backend est un BFF Node avec un hub SSE ; les workers Zeebe et un poller de tâches traduisent les événements du moteur en événements AG-UI. L'agent (le connecteur d'agent IA de Camunda exécutant un sous-processus ad-hoc, avec Claude sur Bedrock et Gemini comme modèles interchangeables) choisit à chaque tour parmi 13 outils hétérogènes : tâches de service, un script FEEL, un connecteur HTTP pour les taux de change en direct, un transfert humain. Le flux est l'intégration, l'identité, le risque, une table de décision DMN pour le routage, puis soit l'ouverture de compte directe, soit un examen par un conseiller. Lorsque l'orchestrateur possède l'état, le flux de l'interface utilisateur hérite de trois propriétés que les architectures natives du chat ne peuvent pas avoir : **Reprenable.** Si le BFF ou l'agent plante en cours de flux, l'instance de processus est toujours dans le moteur à l'activité exacte qu'elle a atteinte. Redémarrez le backend, rejouez un `STATE_SNAPSHOT` à partir des variables de processus, et le flux continue. L'état vit dans le moteur, pas dans la fenêtre de contexte du LLM et pas dans le tas d'un processus Node. **Mettable en pause.** La table DMN achemine les cas supérieurs à 1,5 M$ vers une tâche utilisateur humaine. À ce moment-là, le token de processus s'arrête. Pas « l'agent interroge en boucle », pas « nous maintenons une requête HTTP ouverte avec un long timeout ». Le token est garé, durablement, pour une minute ou un mois. Le flux AG-UI émet l'événement `USER_TASK`, le client voit une carte honnête « votre conseiller examine ceci », le conseiller voit une carte d'approbation dans sa file d'attente. Lorsque le conseiller décide, le token se déplace et le flux reprend. L'humain dans la boucle est une construction de première classe de l'orchestrateur, pas un hack boulonné sur une boucle de discussion. De manière critique, l'IA n'a pas décidé d'attendre. C'est le processus qui l'a fait. Vous ne voulez pas que « pause pour examen de conformité » soit un comportement que vous sollicitez par un prompt. **Auditable.** Chaque transition d'état, chaque invocation d'outil, chaque décision de routage est enregistrée par le moteur comme un effet secondaire de l'exécution. Dans Camunda, cette piste est visible dans Operate sans aucun code de journalisation personnalisé. Lorsque l'auditeur demande pourquoi la demande de James Rodriguez a été soumise à un examen manuel et celle de Sarah Chen non, la réponse est une table DMN avec une sémantique de politique de correspondance et un historique de tokens horodaté, pas un grep dans les transcriptions de modèles. > Commentaire de relecture : si votre piste d'audit dépend d'un développeur qui se souvient d'ajouter une ligne de journalisation à côté de chaque appel d'outil, vous n'avez pas de piste d'audit. Vous avez un journal intime. Rien de tout cela n'est spécifique à Camunda. La propriété vient de l'externalisation de l'état dans quelque chose de durable qui n'est pas le contexte du modèle et pas la couche web. Temporal vous offre la même capacité de reprise grâce aux historiques de workflow basés sur les événements. LangGraph vous offre une version plus faible mais réelle via des checkpointers. Une machine à états que vous avez écrite vous-même, adossée à Postgres, est qualifiée. La règle de conception est : **le flux AG-UI doit être une vue sur un état durable, jamais le système d'enregistrement.** Faites cela correctement et le choix du protocole sur le fil est presque accessoire. Faites-le mal et aucun protocole ne vous sauvera. ## Un flux, plusieurs surfaces Le flux d'événements est typé et sémantique, donc rien en lui ne suppose un seul lecteur. AURUM gère trois personas à partir du même fil : | Surface | Route | Ce qu'il rend à partir du flux | |---|---|---| | Client | `#/customer` | Texte de conciergerie, cartes génératives diffusées une par une, états honnêtes « en attente d'examen » | | Conseiller | `#/advisor` | La file d'attente d'approbation : les événements `USER_TASK` deviennent des cartes actionnables ; les décisions retournent dans le processus | | Opérateur | `#/operator/{pid}` | Le journal d'événements brut, non rendu : chaque événement de cycle de vie, appel d'outil et delta d'état tel qu'il arrive |  La vue opérateur existe comme la vue « ne me croyez pas sur parole ». Ouvrez-la à côté d'une session client et vous verrez le fil brut produire l'interface utilisateur polie en temps réel. Dans les démos client, cela a plus d'impact que n'importe quelle diapositive d'architecture, car cela prouve que les cartes ne sont pas une mise en scène chorégraphiée du frontend. Ce sont des rendus des mêmes événements que la console d'opérations affiche bruts. Le point plus profond : dans la plupart des entreprises, l'interface utilisateur client, la file d'attente de back-office et le tableau de bord des opérations sont trois équipes, trois bases de code et trois projets d'intégration. Un flux d'événements typé réduit cela à un seul contrat avec trois moteurs de rendu. Les vues du bureau du conseiller (`#/desk`, `#/pipeline`) sont venues presque gratuitement une fois que le vocabulaire existait, et « presque gratuitement » n'est pas une expression que j'utilise à la légère. ## Honnêteté de l'implémentation : ce que ~150 lignes vous apportent Le frontend AURUM n'a pas de framework d'agent. Pas de CopilotKit, pas de ChatKit. Le client AG-UI est un petit wrapper `EventSource` plus un hook React `useAGUI`, environ 150 lignes au total. Je l'ai fait délibérément, pour trouver le vrai minimum dont un client a besoin. Voici le bilan honnête. **Ce que les ~150 lignes gèrent réellement :** l'ouverture de la connexion SSE par instance de processus, l'analyse de chaque événement, la répartition sur `type` dans l'état React (ajouter un delta de texte, insérer/mettre à jour un appel d'outil par ID, pousser une carte générative, définir le drapeau de tâche utilisateur), et s'appuyer sur la reconnexion automatique intégrée de `EventSource`. C'est vraiment tout ce dont un client de démo a besoin, et c'est pourquoi je dis aux équipes que le coût côté client de l'adoption d'AG-UI est faible. La partie coûteuse de l'UX agentique est la sémantique du backend, pas la gestion des sockets. **Ce qu'elles ne gèrent pas, et ce que je renforcerais pour la production :** - **Reconnexion avec continuité.** `EventSource` se reconnecte, mais mon serveur n'implémente pas `Last-Event-ID`, donc les événements émis pendant une déconnexion sont simplement perdus. La solution est standard : attribuer des ID d'événement monotones, maintenir un court tampon de relecture (ou redériver du moteur, qui est le véritable système d'enregistrement), et rejouer à partir du dernier ID du client lors de la reconnexion. Revenir à un nouveau `STATE_SNAPSHOT` lorsque le tampon est périmé couvre le reste. - **Rétropression.** SSE n'en a pas. Un client lent signifie que le serveur met en tampon. Avec un navigateur de démo, c'est invisible ; avec des milliers de flux concurrents, c'est un problème de mémoire. Réponses pour la production : plafonds de file d'attente par connexion avec instantané et réinitialisation en cas de débordement, ou fusion des deltas d'état (JSON Patch se compose, donc N deltas peuvent se réduire en un seul). - **Ordonnancement entre sources.** Au sein d'une connexion SSE, l'ordonnancement est garanti. Mais mon BFF agrège les événements de plusieurs workers et d'un poller de tâches. Deux workers émettant presque simultanément peuvent s'entrelacer dans un ordre qui diffère de l'ordre du moteur. La démo ignore cela ; la production devrait séquencer au niveau du hub en utilisant l'ordonnancement côté moteur (position ou horodatage de l'instance de processus) avant d'écrire sur le socket. - **Rendu idempotent.** La relecture plus la livraison au moins une fois signifie des doublons. L'upsert par `messageId`/`toolCallId` vous mène loin ; mon gestionnaire de cartes génératives ajoute, donc un événement `GENERATIVE_UI` rejoué est rendu deux fois. Les cartes ont aussi besoin d'ID stables. - **Authentification du flux.** Les personas de la démo sont des routes de hachage. Il n'y a aucune authentification sur l'endpoint SSE. La production nécessite un token de courte durée lié à l'instance de processus et au persona, vérifié au moment de l'abonnement, et revérifié à la reconnexion. Une autre part d'honnêteté concernant la démo elle-même : elle fonctionne sans aucune clé API. Sans `ANTHROPIC_API_KEY`, les workers de l'agent rejouent un scénario scripté déterministe (« mode fantôme »), de sorte que le flux AG-UI complet, la pause humain dans la boucle et la chorégraphie du moteur fonctionnent tous avant que vous ne dépensiez un centime en tokens. J'ai construit cela pour la fiabilité de la démo, mais cela a prouvé son utilité comme harnais de test : l'ensemble du pipeline d'événements est exercé avec une variance de modèle nulle, ce qui est exactement ce que vous voulez en CI. Si vous adoptez une idée de cette section, adoptez celle-ci. > Commentaire de relecture : un « mode fantôme » scripté n'est pas une démo inférieure. C'est un élément fixe pour votre contrat d'événements, et il détectera plus de régressions frontend que n'importe quelle évaluation de prompt. ## Ce qu'AG-UI ne résout pas Les protocoles gagnent la confiance en étant clairs sur leurs limites. Trois lacunes que vous devrez gérer vous-même : **Autorisation des actions affichées dans l'interface utilisateur.** AG-UI peut diffuser une carte d'approbation à un conseiller. Il n'a aucune opinion sur la question de savoir si ce conseiller est autorisé à approuver. L'événement est une instruction de rendu, pas une concession de permission, et un frontend qui traite « la carte est apparue » comme une autorisation a une faille de type IDOR. La vérification doit se faire là où l'action s'exécute. Dans AURUM, c'est le moteur : l'API de complétion des tâches utilisateur impose qui peut la compléter, et l'interface utilisateur n'est qu'une jolie façade sur ce fait. Partout où vos actions s'exécutent, appliquez la règle là, et traitez chaque message entrant « l'utilisateur a décidé X » comme une entrée non fiable. **Gouvernance des schémas des composants génératifs.** Le contrat `component` + `props` entre les émetteurs du backend et le registre du frontend est exactement aussi fort que votre discipline. Rien dans AG-UI ne valide que `PortfolioAllocationChart` accepte toujours `alternatives` après le refactoring de la semaine dernière. Vous avez besoin de ce dont vous auriez besoin pour toute API : des définitions de schéma partagées (j'utiliserais zod ou JSON Schema, validées à l'émission et au rendu), un moteur de rendu de secours pour les composants inconnus, et de traiter les props des composants comme une API publique versionnée, car c'est ce qu'elles sont. **Versionnement des événements entre les déploiements.** Les flux sont de longue durée ; les déploiements ne le sont pas. Lors d'un déploiement continu, un client construit avec les formes d'événements d'hier peut recevoir les événements d'aujourd'hui, et une instance de processus démarrée la semaine dernière peut reprendre le streaming vers un frontend repensé. La spécification vous donne les échappatoires `RAW` et `CUSTOM` mais pas d'histoire de versionnement. Réponse minimale viable : changements uniquement additifs aux charges utiles des événements, un champ de version dans vos événements personnalisés, et une politique pour vider les flux de longue durée avant les changements cassants. Les configurations orchestrées par processus le ressentent davantage, pas moins, car une tâche utilisateur en attente peut tranquillement attendre six déploiements. J'ajouterais un quatrième point plus souple : AG-UI ne rend pas votre agent bon. Un flux typé d'un mauvais processus est un mauvais processus bien formaté. Le protocole a déplacé mon problème de « comment obtenir une structure pour le frontend » à « de quelle structure ce workflow a-t-il réellement besoin », ce qui est le bon problème, mais c'est toujours du travail. ## La version en un paragraphe AG-UI est un protocole d'événements ouvert et typé entre un backend agentique et un frontend destiné à l'utilisateur : cycle de vie d'exécution, texte streamé, appels d'outils avec résultats, deltas d'état JSON Patch, et une voie ouverte pour les composants d'interface utilisateur générative, généralement sur SSE. Il occupe la couche agent-vers-humain de la pile, aux côtés de MCP (outils), A2A (autres agents) et AP2 (paiements), et un client performant est petit (le mien fait environ 150 lignes, sans framework). Le protocole standardise le fil et délibérément pas le rendu, l'autorisation ou la gouvernance des schémas, donc cela reste votre travail. La décision la plus stratégique ne se situe pas du tout sur le fil : faites du flux une projection d'un état durable et externalisé (un moteur de processus, Temporal, un graphe checkpointé), et l'interface utilisateur devient reprenable après des plantages, mettable en pause pour approbation humaine comme une construction de première classe, et auditable comme un effet secondaire de l'exécution. J'ai prouvé le modèle avec AURUM, un flux d'intégration de banque privée fictif où un flux d'événements alimente une vue client, une file d'attente d'approbation de conseiller et une console opérateur brute, et où la pause d'approbation de 1,5 M$ est un token de processus garé, pas un prompt. ## Références - Documentation du protocole AG-UI : [https://docs.ag-ui.com](https://docs.ag-ui.com/introduction) - Protocole AG-UI sur GitHub : [https://github.com/ag-ui-protocol/ag-ui](https://github.com/ag-ui-protocol/ag-ui) - Dépôt de démo AURUM (exécutable, le mode fantôme ne nécessite pas de clés API) : [https://github.com/letmereviewyourcode/camunda-agui-wealth-demo](https://github.com/letmereviewyourcode/camunda-agui-wealth-demo) - La vidéo de démo EP02 et la discussion sur LinkedIn : [https://www.linkedin.com/posts/zishanalikhan_agenticai-agui-camunda-ugcPost-7480344185674313728-ffd8](https://www.linkedin.com/posts/zishanalikhan_agenticai-agui-camunda-ugcPost-7480344185674313728-ffd8) - Guides complémentaires de cette série : [Guide de terrain A2A](/fr/guides/a2a-field-guide/) · [Guide de terrain AP2](/fr/guides/ap2-field-guide/) - RFC 6902 (JSON Patch), le mécanisme derrière `STATE_DELTA` : [https://datatracker.ietf.org/doc/html/rfc6902](https://datatracker.ietf.org/doc/html/rfc6902)