Cas d'utilisation de l'IA agentique : activer le streaming multimodal bidirectionnel en direct

Last reviewed 2026-10-14 UTC

Ce document fournit une architecture de haut niveau pour un système d'IA multi-agent bidirectionnel en direct sur Google Cloud. Le système aide les utilisateurs à effectuer des tâches techniques, comme l'assemblage de composants complexes, le diagnostic de dysfonctionnements d'équipements ou la navigation dans des procédures de réparation complexes. Le système d'IA agentique fournit des conseils techniques ancrés et une surveillance automatisée de la sécurité via un flux continu et bidirectionnel de données multimodales.

Ce document s'adresse aux architectes, aux développeurs et aux administrateurs qui créent et gèrent des infrastructures et des applications d'IA dans le cloud. Ce document suppose que vous avez des connaissances de base sur les agents et les modèles d'IA. Ce document ne fournit pas de conseils spécifiques pour la conception et le codage d'agents IA.

La section Déploiement de ce document liste des exemples de code que vous pouvez utiliser pour apprendre à créer et à déployer des systèmes d'IA multi-agents.

Architecture

Le schéma suivant montre une vue d'ensemble d'une architecture qui utilise un système d'IA multi-agent pour permettre le streaming de données multimodales bidirectionnel en direct :

Architecture de haut niveau d'un système d'IA multi-agent qui permet le streaming bidirectionnel de données multimodales.

L'architecture du diagramme précédent comporte deux workflows : les conseils techniques et la surveillance de la sécurité.

  • Le workflow de conseils techniques permet aux utilisateurs de recevoir des solutions commentées en temps réel à des questions techniques complexes. Ce workflow utilise l'API Gemini Live pour traiter les flux multimodaux et se coordonner avec un sous-agent afin de récupérer des informations produit ancrées dans la base de connaissances.
  • Le workflow de surveillance de la sécurité permet de détecter automatiquement les dangers afin d'assurer la sécurité des utilisateurs lors des procédures techniques. Ce workflow utilise Gemini pour analyser des segments vidéo en direct, identifier les risques potentiels et déclencher des avertissements immédiats via le tableau de bord client.

Les onglets suivants fournissent des diagrammes de l'architecture qui illustrent les workflows de conseils techniques et de surveillance de la sécurité :

Workflow des conseils techniques

Le schéma suivant présente une architecture détaillée pour un workflow de conseils techniques.

Architecture montrant le workflow des conseils techniques.

Le schéma précédent montre le flux de données suivant :

  1. Un utilisateur lance une session en posant une question technique par commande vocale via le tableau de bord client. Par exemple, un technicien peut pointer son appareil photo vers un panneau de configuration et demander : "Aide-moi, que signifie ce voyant d'erreur rouge clignotant ?"

  2. Le tableau de bord client établit une connexion WebSocket persistante entre l'interface et le serveur backend.

  3. Les messages WebSocket empaquettent les données multimédias brutes dans des objets Blob. Le composant Agent Development Kit (ADK) LiveRequestQueue diffuse en continu les données d'entrée vers l'agent de distribution.

  4. L'agent de distribution détecte les commandes audio ou visuelles qui nécessitent des conseils techniques et envoie le flux d'entrée à l'API Gemini Live.

  5. Le modèle Gemini Live recherche les données brutes pour identifier les événements. Les événements sont des mots-clés audio, tels que "assembler" ou "aide", ou des indices visuels, tels que des gestes de la main.

    Gemini évalue chaque événement pour déterminer s'il est pertinent pour la requête de l'utilisateur. Par exemple, un geste de la main ou des mots de remplissage peuvent ne pas être pertinents. Gemini ne traite donc pas ces événements.

  6. Pour chaque événement pertinent, Gemini active l'appel de fonction pour évaluer s'il a besoin de contexte supplémentaire. Selon qu'un contexte supplémentaire est nécessaire ou non, Gemini ou un agent architecte renvoie une réponse à l'agent répartiteur.

    1. S'il a besoin de plus de contexte, Gemini consulte la fiche de l'agent architecte pour comprendre comment structurer sa requête.

    2. Gemini envoie une requête structurée à l'agent de répartition. La requête contient des détails sur l'événement, tels que le type de produit, le numéro de modèle, le type d'événement et les attributs.

    3. L'agent de répartition utilise le protocole Agent2Agent (A2A) pour envoyer la requête structurée à l'agent architecte.

    4. L'agent architecte envoie la requête via un connecteur d'accès au VPC sans serveur . Le connecteur permet à l'agent d'accéder de manière sécurisée aux ressources du réseau cloud privé virtuel (VPC) utilisé pour les ressources de stockage dans cette architecture.

    5. Le connecteur d'accès au VPC sans serveur interagit avec les données mises en cache qui sont stockées dans Memorystore pour Redis Cluster. Si les données ne sont pas disponibles dans la couche mise en cache, l'agent architecte interagit avec les instances Compute Engine qui hébergent la base de connaissances.

    6. L'agent architecte reçoit les informations produit à partir du cache de données ou de la base de connaissances. L'agent architecte envoie les informations produit à Gemini pour générer une réponse. Par exemple, "Code d'erreur 3B : dysfonctionnement du ventilateur. Action recommandée : vérifiez qu'il n'y a pas d'obstruction."

    7. L'agent architecte renvoie les informations produit à l'agent répartiteur.

    Si ce n'est pas le cas, Gemini génère directement une réponse à la requête de l'utilisateur.

  7. L'agent de distribution reçoit la réponse de Gemini ou de l'agent architecte, et génère une réponse multimodale :

    1. Utilise le modèle Gemini Live et la boucle run_live d'ADK pour générer une réponse multimodale contenant la solution technique.

    2. Stocke la réponse sous la forme d'un objet Blob.

    3. Envoie la solution technique via le tampon de flux et la connexion WebSocket persistante pour la transmettre au tableau de bord du client.

  8. Le tableau de bord client extrait les données Blob de la solution technique pour fournir des conseils narrés immédiats et met à jour l'interface utilisateur avec les transcriptions pertinentes. La boucle de requête est terminée, tandis que le flux bidirectionnel actif est maintenu.

Workflow de surveillance de la sécurité

Le schéma suivant présente une architecture détaillée pour un workflow de surveillance de la sécurité.

Architecture illustrant le workflow de surveillance de la sécurité.

Le schéma précédent montre le flux de données suivant :

  1. Le tableau de bord client établit une connexion WebSocket persistante entre l'interface et le serveur backend pour observer le flux vidéo en direct. Le message WebSocket empaquette ces données multimédias brutes dans des objets Blob et les envoie en continu au tampon de streaming à l'aide du composant ADK LiveRequestQueue.
  2. Le tampon de flux dirige le flux d'entrée vers un outil de streaming qui s'exécute en boucle continue en arrière-plan pour détecter les dangers dans l'image vidéo.
  3. L'outil de streaming envoie la dernière image vidéo du tampon de streaming à Gemini.
  4. Gemini observe les images vidéo pour détecter les dangers, comme une lumière vive ou de la vapeur.
    • Si aucun danger n'est détecté, rien ne se passe.
    • Si un danger est détecté, Gemini génère une réponse multimodale contenant le type de danger, ses attributs et son emplacement, et la stocke en tant qu'objet Blob. Gemini renvoie la réponse d'avertissement de danger à l'outil de streaming.
  5. L'outil de streaming transmet la réponse d'avertissement de danger au tampon de streaming.
  6. Le tampon de flux utilise la connexion WebSocket persistante pour envoyer la réponse d'avertissement de danger au tableau de bord du client.
  7. Le tableau de bord client extrait les données Blob de la réponse d'avertissement de danger pour fournir des conseils narrés immédiats et met à jour l'UI avec les transcriptions pertinentes. La boucle de requête est ainsi terminée, tandis que le flux bidirectionnel actif est maintenu.

Produits utilisés

Cette architecture de référence utilise les produits et outils Google Cloud suivants :

  • Cloud Run : plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs directement sur l'infrastructure évolutive de Google.
  • Gemini : famille de modèles d'IA multimodaux développés par Google.
  • Gemini Enterprise Agent Platform : plate-forme complète qui vous permet de créer, de faire évoluer, de gérer et d'optimiser des agents IA de niveau entreprise.
  • Agent Development Kit (ADK) : ensemble d'outils et de bibliothèques permettant de développer, de tester et de déployer des agents IA.
  • Protocole Agent2Agent (A2A) : protocole ouvert qui permet la communication et l'interopérabilité entre les agents, quels que soient leur langage de programmation et leur environnement d'exécution.
  • Accès au VPC sans serveur : service qui permet à vos environnements sans serveur de se connecter aux ressources d'un réseau cloud privé virtuel.
  • Cloud privé virtuel (VPC) : système virtuel qui fournit des fonctionnalités de mise en réseau mondiales et évolutives pour vos charges de travail Google Cloud . Le VPC inclut l'appairage de réseaux VPC, Private Service Connect, l'accès aux services privés et le VPC partagé.
  • Memorystore pour Redis Cluster : service de data store en mémoire entièrement géré pour Redis.
  • Compute Engine : service de calcul sécurisé et personnalisable qui vous permet de créer et d'exécuter des machines virtuelles au sein de l'infrastructure de Google.

Pour en savoir plus sur la sélection d'autres composants pour votre système d'IA agentique, y compris le framework, l'Agent Runtime, les outils, la mémoire et les modèles de conception, consultez Choisir les composants de votre architecture d'IA agentive.

Cas d'utilisation

Cette architecture de référence est conçue pour les cas d'utilisation qui nécessitent la synthèse en temps réel de flux de données multimodaux continus et bidirectionnels. Voici des exemples de cas d'utilisation de l'architecture décrite dans ce document :

  • Fabrication industrielle et maintenance sur le terrain : permettez aux techniciens de réparer des machines complexes sans utiliser leurs mains en leur fournissant un assistant IA qui traite les données audio et vidéo en direct provenant de lunettes connectées. Le technicien discute avec l'assistant IA pour récupérer les schémas de la machine. L'assistant IA utilise un agent de base de données interne qui accède à la documentation du produit pour fournir des instructions de réparation et d'assemblage ancrées. Un outil de vision en arrière-plan simultané surveille le flux bidirectionnel pour avertir de manière proactive le technicien des risques mécaniques ou des étapes d'assemblage incorrectes.
  • Assistance technique à distance : améliorez les résultats de dépannage des clients en leur permettant de partager un flux de la caméra de téléphone en direct avec un système d'IA agentique multimodal. L'architecture de streaming bidirectionnel permet une conversation dynamique dans laquelle le système observe le matériel en temps réel. Si un processus de vision en arrière-plan identifie une connexion défectueuse, comme un câble branché sur le mauvais port, le système utilise le flux à faible latence pour interrompre immédiatement l'utilisateur et lui fournir des instructions correctives.

Considérations de conception

Cette section décrit les facteurs de conception, les bonnes pratiques et les recommandations à prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie répondant à vos exigences spécifiques en termes de sécurité, d'opérations, de coût et de performances.

Les conseils de cette section ne sont pas exhaustifs. Pour en savoir plus sur les facteurs de conception et les bonnes pratiques, et pour obtenir des recommandations sur la création et le déploiement d'un système d'IA multi-agent, consultez Système d'IA multi-agent dans Google Cloud.

Sécurité, confidentialité et conformité

Pour aider à gérer les risques de sécurité uniques des agents d'IA, Google recommande une approche qui combine des contrôles de sécurité déterministes avec des défenses dynamiques basées sur le raisonnement :

  • Supervision humaine : intégrez un flux human-in-the-loop (avec intervention humaine) dans les systèmes critiques pour l'entreprise afin que les superviseurs humains puissent examiner les résultats et approuver, ignorer ou suspendre les actions des agents.
  • Agent Identity : attribuez à chaque agent une identité liée à la charge de travail pour appliquer le contrôle des accès basé sur le principe du moindre privilège et gérer de manière centralisée les identifiants des outils externes.
  • Agent Gateway : appliquez la gouvernance du trafic entrant et sortant, des règles d'accès de refus par défaut, ainsi que l'inspection intégrée des prompts et des outils avec Model Armor.

  • Agent Registry : vérifiez que les agents ne se connectent qu'aux sous-agents et aux outils MCP approuvés.

  • Sécurité d'entrée de l'application : pour contrôler l'accès à l'application, désactivez l'URL run.app par défaut du service Cloud Run d'interface et configurez un équilibreur de charge d'application externe régional. En plus d'équilibrer la charge du trafic entrant vers l'application, l'équilibreur de charge gère les certificats SSL. Pour une protection renforcée, vous pouvez utiliser des stratégies de sécurité Google Cloud Armor afin de fournir un filtrage des requêtes, une protection contre les attaques DDoS et une limitation du débit pour le service.

  • Sécurité WebSocket : protégez les données multimodales sensibles, telles que les empreintes vocales et les vidéos, en appliquant le chiffrement TLS pour toutes les connexions WebSocket bidirectionnelles.

  • Communication A2A sécurisée :

Efficacité opérationnelle

Pour vous assurer que les configurations de votre agent répondent à vos exigences d'efficacité opérationnelle, tenez compte des recommandations suivantes :

  • Scripts de boucle de contrôle : écrivez des requêtes système pour les agents Live bidirectionnels sous forme de boucles de comportement de machine d'état strictes plutôt que de simples consignes de personnalité. La requête système doit explicitement ordonner à l'agent de rester silencieux jusqu'à ce qu'il soit déclenché. Il doit imposer des réponses brèves et axées sur l'action, afin que l'interaction vocale soit concise et naturelle.
  • Séparation des tâches : utilisez un outil de streaming en arrière-plan dédié pour surveiller les flux vidéo indépendamment de l'agent principal. L'agent racine de l'architecture est bidirectionnel et peut interrompre instantanément son propre discours pour diffuser ces avertissements de sécurité critiques à l'utilisateur. De plus, demander à un seul agent de surveiller en permanence un flux vidéo peut entraîner une surcharge cognitive et des hallucinations.

Optimisation des coûts

Pour vous assurer que les configurations de votre agent répondent à vos exigences de coût, tenez compte des recommandations suivantes :

  • Coûts d'ingestion des données : pour réduire les coûts des jetons et éviter l'épuisement de la fenêtre de contexte, utilisez un échantillonnage d'images à basse fréquence, par exemple deux images par seconde, et compressez toutes les données dans des fichiers JPEG Base64.
  • Prompting économique : la longueur de vos prompts (entrée) et des réponses générées (sortie) affecte directement les performances et les coûts. Rédigez des prompts courts, directs et fournissant suffisamment de contexte. Concevez vos requêtes de manière à obtenir des réponses concises du modèle. Par exemple, incluez des expressions telles que "résumer en deux phrases" ou "lister trois points clés". Pour en savoir plus, consultez les bonnes pratiques pour la conception de requêtes.

Optimisation des performances

Pour vous assurer que vos configurations d'agent répondent à vos exigences de performances, tenez compte des recommandations suivantes :

  • Mise en mémoire tampon asynchrone : pour dissocier les paquets audio et vidéo entrants du moteur d'inférence du modèle, utilisez un tamon FIFO (First-In-First-Out) asynchrone et thread-safe. Ce tampon agit comme un multiplexeur qui garantit que le système reste réactif aux interruptions de l'utilisateur sans figer l'interface utilisateur lors de calculs lourds.
  • Mise en cache en mémoire : pour obtenir des vitesses de lecture inférieures à la milliseconde, utilisez une base de données Memorystore pour Redis Cluster en mémoire pour le coffre-fort de schémas de l'agent architecte. Cette implémentation minimise la latence, évite les silences lors des interactions vocales en temps réel et fournit une source unique de vérité évolutive.
  • Allocation des ressources : en fonction de vos exigences de performances, configurez les limites de mémoire et les limites de processeur à allouer au service Cloud Run.

Déploiement

Pour déployer un exemple d'implémentation de cette architecture, essayez Codelabs suivants :

Étapes suivantes

Contributeurs

Auteurs :

Autres contributeurs :