Choisir une architecture d'application Google Chat

Cette page décrit les approches d'architecture de service courantes utilisées pour créer des applications Google Chat. Si vous souhaitez intégrer une application existante à Google Chat, vous pouvez utiliser ou adapter votre implémentation existante. Si vous créez une application Chat, cette page présente des informations similaires de différentes manières pour vous aider à choisir l'architecture adaptée à votre cas d'utilisation:

• Consultez un tableau récapitulatif.
• Consultez un résumé de chaque style d'architecture.
• Consultez un résumé de la logique de l'application Chat.
• Consultez un résumé par type de conversation dans l'application Chat.

Présentation par fonctionnalités et capacités

Le tableau suivant met en évidence les principales caractéristiques et fonctionnalités des applications Chat, ainsi que le style d'architecture de service recommandé (verified). Dans certains cas, il est possible de développer un autre style d'architecture avec ces fonctionnalités, mais il n'est pas aussi adapté au cas d'utilisation que d'autres styles (check_circle_outline).

Fonctionnalités et caractéristiques	Service Web ou HTTP	Pub/Sub	Webhooks	Apps Script	AppSheet	Dialogflow	Script
Audience visée
Votre équipe	check_circle_outline	check_circle_outline	verified	verified	verified	check_circle_outline	check_circle_outline
Votre entreprise	verified	verified	check_circle_outline	verified	check_circle_outline	check_circle_outline	check_circle_outline
Le public	verified	check_circle_outline		check_circle_outline		check_circle_outline
Interactivité utilisateur
Utiliser le traitement du langage naturel	check_circle_outline	check_circle_outline		check_circle_outline		verified
Modèles de messages
Envoyer et recevoir des messages synchrones	verified	check_circle_outline		verified	verified	verified
Envoyer et recevoir des messages synchrones, et envoyer des messages asynchrones	verified	check_circle_outline		verified	verified
Envoyer uniquement des messages asynchrones	verified		check_circle_outline	verified	check_circle_outline		verified
Envoyer des messages depuis un système externe vers un seul espace Chat	verified		verified	verified	verified		check_circle_outline
Accéder à d'autres services et systèmes
Intégration dans d'autres services Google	check_circle_outline	check_circle_outline		verified	verified
Communiquer derrière un pare-feu		verified
Interroger ou s'abonner à des événements Chat	check_circle_outline	verified		check_circle_outline
Styles de codage et de déploiement
Développement sans code					verified
Développement avec le low code			verified	verified		check_circle_outline	check_circle_outline
Développement dans un langage de programmation de votre choix	verified	verified	check_circle_outline				verified
DevOps simplifié			check_circle_outline	verified	verified	check_circle_outline	check_circle_outline
Gestion complète des DevOps et du CI/CD	verified	verified					check_circle_outline

Styles d'architecture de service

Cette section décrit certaines des approches architecturales les plus courantes utilisées pour créer des applications Chat.

Service Web ou HTTP

Un service Web ou HTTP est l'architecture la plus couramment déployée, car elle offre aux développeurs la plus grande flexibilité pour créer des applications Chat publiques. Cette architecture est recommandée pour les cas d'utilisation suivants:

• L'application Chat est déployée auprès du public sur Google Workspace Marketplace.
• L'application Chat peut envoyer et recevoir tous les modèles de messagerie: envoyer et recevoir des messages synchrones, envoyer des messages asynchrones et envoyer des messages à partir d'un système externe.
• L'application Chat est développée dans n'importe quel langage de programmation.
• L'application Chat nécessite une gestion complète des DevOps et de l'intégration/livraison continue.
• Le service de l'application Chat est implémenté sur des serveurs cloud ou sur site.

Dans cette conception, vous configurez Chat pour l'intégrer à un service distant à l'aide d'HTTP, comme illustré dans le schéma suivant:

Dans le diagramme précédent, un utilisateur qui interagit avec une application Chat HTTP a le flux d'informations suivant:

1. Un utilisateur envoie un message dans un espace Chat à une application Chat.
2. Une requête HTTP est envoyée à un serveur Web, qui est un système cloud ou sur site contenant la logique de l'application Chat.
3. La logique de l'application Chat peut éventuellement interagir avec des services tiers externes, tels qu'un système de gestion de projet ou un outil de gestion des tickets.
4. Le serveur Web renvoie une réponse HTTP au service de l'application Chat dans Chat.
5. La réponse est transmise à l'utilisateur.
6. L'application Chat peut éventuellement appeler l'API Chat pour publier des messages de manière asynchrone ou effectuer d'autres opérations.

Cette architecture vous permet d'utiliser les bibliothèques et composants existants de votre système, car ces applications Chat peuvent être conçues à l'aide de différents langages de programmation. Il existe différentes façons d'implémenter cette architecture. Sur Google Cloud, vous pouvez utiliser Cloud Functions, Cloud Run et App Engine. Pour commencer, consultez la section Créer une application Google Chat.

Pub/Sub

Si l'application Chat est implémentée derrière un pare-feu, elle ne peut pas y passer d'appels HTTP. Une approche consiste à utiliser Pub/Sub pour permettre à l'implémentation de l'application Chat de s'abonner à un sujet qui transporte des messages de Chat. Pub/Sub est un service de messagerie asynchrone qui dissocie les services de production de messages des services qui traitent ces messages. Cette architecture est recommandée pour les cas d'utilisation suivants:

• L'application Chat est compilée derrière un pare-feu.
• L'application Chat reçoit des événements concernant un espace Chat.
• L'application Chat est déployée dans votre organisation.
• L'application Chat peut envoyer et recevoir des messages synchrones, et peut envoyer des messages asynchrones.
• L'application Chat est développée dans n'importe quel langage de programmation.
• L'application Chat nécessite une gestion complète des DevOps et de l'intégration/livraison continue.

Le schéma suivant illustre l'architecture d'une application de chat créée avec Pub/Sub:

Dans le schéma précédent, un utilisateur qui interagit avec une application de chat Pub/Sub a le flux d'informations suivant:

1. Un utilisateur envoie un message dans Chat à une application Chat, en passant par un message privé ou un espace Chat, ou un événement se produit dans un espace Chat pour lequel l'application Chat dispose d'un abonnement actif.

2. Chat envoie le message à un sujet Pub/Sub.

3. Un serveur d'application, qui est un système cloud ou sur site contenant la logique de l'application Chat, s'abonne au sujet Pub/Sub afin de recevoir le message via le pare-feu.

4. L'application Chat peut éventuellement appeler l'API Chat pour publier des messages de manière asynchrone ou effectuer d'autres opérations.

Pour commencer, consultez la section Utiliser Pub/Sub comme point de terminaison pour votre application Chat.

Webhooks

Vous pouvez créer une application Chat qui ne peut envoyer des messages qu'à un espace Chat spécifique à l'aide d'appels à une URL de webhook Chat. Cette architecture est recommandée pour les cas d'utilisation suivants:

• L'application Chat est déployée auprès de votre équipe.
• L'application Chat envoie des messages à partir d'un système externe vers un seul espace Chat.

Avec cette architecture, l'application Chat est limitée à un espace Chat spécifique et n'autorise pas les interactions utilisateur, comme illustré dans le diagramme suivant:

Dans le schéma précédent, le flux d'informations d'une application Chat est le suivant:

1. La logique de l'application Chat reçoit des informations de services tiers externes, tels qu'un système de gestion de projet ou un outil de gestion des tickets.
2. La logique de l'application Chat est hébergée dans un système cloud ou sur site qui peut envoyer des messages à l'aide d'une URL de webhook vers un espace Chat spécifique.
3. Les utilisateurs peuvent recevoir des messages de l'application Chat dans cet espace Chat spécifique, mais ne peuvent pas interagir avec l'application Chat.

Ce type d'application Chat ne peut pas être partagé dans d'autres espaces Chat ni avec d'autres équipes, et ne peut pas être publié sur Google Workspace Marketplace. Les webhooks entrants sont recommandés pour les applications Chat afin de signaler des alertes ou un état, ou pour certains types de prototypage d'applications Chat.

Pour commencer, consultez la section Envoyer des messages à Chat avec des webhooks.

Apps Script

Vous pouvez créer entièrement la logique de votre application Chat en JavaScript. Google Apps Script est une plate-forme de développement low-code pour les applications Chat. Apps Script gère le flux d'autorisation et les jetons OAuth 2.0 pour l'authentification des utilisateurs. Vous pouvez utiliser Apps Script pour créer des applications Chat publiques, mais cela n'est pas recommandé en raison des quotas et limites quotidiens.

Cette architecture est recommandée pour les cas d'utilisation suivants:

• L'application Chat est déployée dans votre équipe ou votre organisation.
• L'application Chat peut envoyer et recevoir tous les modèles de messagerie: envoyer et recevoir des messages synchrones, envoyer des messages asynchrones et envoyer des messages à partir d'un système externe.
• L'application Chat nécessite une gestion DevOps simplifiée.

Cette architecture est utile pour les applications Chat qui s'intègrent également à d'autres services Google et Google Workspace, tels que Google Sheets, Google Slides, Google Agenda, Google Drive, Google Maps et YouTube, comme illustré dans le diagramme suivant:

Dans le diagramme précédent, un utilisateur qui interagit avec une application Chat Apps Script suit le flux d'informations suivant:

1. Un utilisateur envoie un message à une application Chat, en passant par un message privé ou un espace Chat.
2. La logique de l'application Chat implémentée dans Apps Script, qui se trouve dans Google Cloud, reçoit le message.
3. La logique de l'application Chat peut éventuellement s'intégrer à des services Google Workspace, tels qu'Agenda ou Sheets, ou à d'autres services Google, tels que Google Maps ou YouTube.
4. La logique de l'application Chat renvoie une réponse au service de l'application Chat dans Chat.
5. La réponse est envoyée à l'utilisateur.

Pour commencer, consultez Créer une application Chat avec Apps Script.

AppSheet

Vous pouvez créer une application Chat partagée par le domaine sans code à l'aide d'AppSheet. Vous pouvez simplifier le processus de développement en utilisant le mode de configuration automatique et en suivant les modèles pour créer des actions d'application Chat courantes. Toutefois, certaines fonctionnalités des applications Web AppSheet ne sont pas disponibles dans les applications Chat.

Cette architecture est recommandée pour les cas d'utilisation suivants:

• L'application Chat est déployée pour vous et votre équipe.
• L'application Chat peut envoyer et recevoir des messages synchrones, et peut envoyer des messages asynchrones.
• L'application Chat nécessite une gestion DevOps simplifiée.

Le schéma suivant montre l'architecture d'une application de chat créée avec AppSheet:

Dans le diagramme précédent, un utilisateur qui interagit avec une application Chat AppSheet suit le flux d'informations suivant:

1. Un utilisateur envoie un message dans Chat à une application Chat, soit par message privé, soit dans un espace Chat.
2. La logique de l'application Chat implémentée dans AppSheet, qui se trouve dans Google Cloud, reçoit le message.
3. La logique de l'application Chat peut éventuellement s'intégrer aux services Google Workspace, tels qu'un Apps Script ou Google Sheets.
4. La logique de l'application Chat renvoie une réponse au service de l'application Chat dans Chat.
5. La réponse est transmise à l'utilisateur.

Pour commencer, consultez Créer une application Chat avec AppSheet.

Dialogflow

Vous pouvez créer une application Chat avec Dialogflow, une plate-forme de langage naturel pour les conversations automatisées et les réponses dynamiques. Cette architecture est recommandée pour les cas d'utilisation suivants:

• L'application Chat peut envoyer et recevoir des messages synchrones.
• L'application Chat utilise le traitement du langage naturel pour répondre et interagir avec les utilisateurs.

Le schéma suivant montre l'architecture d'une application Chat créée avec Dialogflow:

Dans le diagramme précédent, un utilisateur qui interagit avec une application Chat Dialogflow a le flux d'informations suivant:

1. Un utilisateur envoie un message dans Chat à une application Chat, soit par message privé, soit dans un espace Chat.
2. Un agent virtuel Dialogflow, qui réside dans Google Cloud, reçoit et traite le message pour générer une réponse.
3. L'agent Dialogflow peut également interagir avec des services tiers externes à l'aide d'un webhook Dialogflow, comme un système de gestion de projet ou un outil de gestion des tickets.
4. L'agent Dialogflow renvoie une réponse au service de l'application Chat dans Chat.
5. La réponse est envoyée à l'espace Chat.

Pour commencer, consultez Créer une application Google Chat Dialogflow.

Application ou script de ligne de commande

Vous pouvez créer une application de ligne de commande ou un script qui envoie des messages à Chat ou effectue d'autres opérations, telles que la création d'un espace ou la gestion de ses membres, sans autoriser les utilisateurs à appeler directement l'application Chat ni à y répondre dans Chat. Cette architecture est recommandée pour les cas d'utilisation suivants:

• L'application Chat est développée dans n'importe quel langage de programmation.
• L'application Chat ne peut envoyer que des messages asynchrones.

Le schéma suivant présente l’architecture :

Dans le schéma précédent, l'application Chat présente le flux d'informations suivant:

1. L'application Chat appelle l'API Chat pour envoyer un message ou effectuer une autre opération.
2. Chat exécute l'opération demandée.
3. L'application Chat peut également imprimer une confirmation dans la CLI.

Implémentation de la logique de l'application Chat

Chat ne limite pas la façon dont vous implémentez la logique de l'application Chat. Vous pouvez créer un analyseur de commandes à syntaxe fixe, utiliser des bibliothèques ou des services d'IA et de traitement du langage avancés, vous abonner et répondre à des événements, ou tout autre élément adapté à vos objectifs spécifiques.

Gérer les interactions des utilisateurs

L'application Chat peut recevoir et répondre aux interactions des utilisateurs de plusieurs façons. Une interaction utilisateur correspond à toute action effectuée par un utilisateur pour appeler ou interagir avec une application Chat.

Analyseur de commandes

Les applications Chat basées sur les commandes examinent la charge utile des événements d'interaction avec l'application Chat, puis extraient les commandes et les paramètres de ce contenu. Par exemple, consultez Configurer des commandes à barre oblique pour interagir avec les utilisateurs de Chat.

Une autre approche consiste à tokeniser le message, à extraire la commande, puis à référencer un dictionnaire qui mappe les commandes aux fonctions de gestionnaire pour chaque commande.

Interface utilisateur basée sur des boîtes de dialogue

Les applications basées sur des boîtes de dialogue répondent aux événements d'interaction avec l'application Chat en affichant des boîtes de dialogue basées sur des cartes, dans lesquelles l'utilisateur peut interagir avec l'application Chat, par exemple en remplissant des formulaires ou en demandant des actions.

Chaque fois qu'un utilisateur exécute une action dans une boîte de dialogue, un nouvel événement d'interaction est envoyé à l'application Chat, qui peut répondre en mettant à jour la boîte de dialogue ou en envoyant un message.

Traitement du langage naturel

De nombreuses implémentations d'applications Chat utilisent le traitement du langage naturel (TLN) pour déterminer ce que l'utilisateur demande. Il existe de nombreuses façons d'implémenter le NLP, et vous pouvez choisir de l'implémenter comme vous le souhaitez.

Vous pouvez utiliser le NLP dans l'implémentation de votre application Chat avec Dialogflow ES ou l'intégration de Chat dans Dialogflow CX, ce qui vous permet de créer des agents virtuels pour des conversations automatisées et des réponses dynamiques.

Envoyer des requêtes à Chat de manière proactive

Les applications Chat peuvent également envoyer des messages ou d'autres requêtes à Chat, qui ne sont pas déclenchées par des interactions directes des utilisateurs dans Chat. À la place, ces applications Chat peuvent être déclenchées, par exemple, par des applications tierces ou à l'aide d'une invocation de ligne de commande par un utilisateur. Toutefois, les utilisateurs ne peuvent pas interagir directement avec ces applications Chat dans Chat.

Les applications Chat non interactives utilisent l'API Chat pour envoyer des messages ou d'autres types de requêtes à Chat.

Modèles de conversation

Vous devez réfléchir à la façon dont vous souhaitez que votre application Chat interagisse avec les utilisateurs. Les sections suivantes décrivent les modèles de conversation que votre application Chat peut implémenter.

Appel et réponse (synchrone)

Dans un modèle d'appel et de réponse synchrone, l'application Chat répond aux messages des utilisateurs de manière individuelle. Un message envoyé par un utilisateur à l'application Chat génère une réponse de l'application Chat, comme illustré dans le diagramme suivant:

Dans le diagramme précédent, un utilisateur qui interagit avec une application de chat a le flux d'informations suivant:

1. Un utilisateur envoie un message synchrone à une application Chat (par exemple, "Quelle est ma prochaine réunion ?").
2. L'application Chat envoie un message synchrone à l'utilisateur, par exemple "Dr. Silva à 14h30".

Pour ce type de modèle de conversation, vous pouvez implémenter une architecture d'application de chat à l'aide d'un service Web, de Pub/Sub, d'Apps Script, d'AppSheet ou de Dialogflow.

Plusieurs réponses (asynchrone)

Le modèle de réponses multiples peut inclure des messages synchrones et asynchrones. Ce modèle se caractérise par une communication bidirectionnelle entre les utilisateurs et l'application Chat, l'application Chat générant un nombre illimité de messages supplémentaires, comme illustré dans le diagramme suivant:

Dans le diagramme précédent, un utilisateur qui interagit avec une application de chat a le flux d'informations suivant:

1. Un utilisateur envoie un message synchrone à une application Chat (par exemple, "Surveiller le trafic").
2. L'application Chat envoie un message synchrone à l'utilisateur pour confirmer la requête (par exemple, "Surveillance activée").
3. Par la suite, l'application Chat envoie un ou plusieurs messages asynchrones à l'utilisateur en appelant l'API REST (par exemple, "Nouveau trafic").
4. L'utilisateur envoie un message synchrone supplémentaire à l'application Chat (par exemple, "Ignorer le trafic").
5. L'application Chat envoie un message synchrone à l'utilisateur pour confirmer la requête (par exemple, "Surveillance désactivée").

Pour ce type de modèle de conversation, vous pouvez implémenter une architecture d'application de chat à l'aide d'un service Web, de Pub/Sub, d'Apps Script ou d'AppSheet.

Interroger ou s'abonner à des événements (asynchrone)

Dans un modèle asynchrone basé sur les événements, l'application Chat reçoit des événements en interrogeant l'API Chat ou en créant un abonnement à un espace ou un utilisateur Chat à l'aide de l'API Google Workspace Events. Les événements représentent des modifications apportées aux ressources Chat, par exemple lorsqu'un nouveau message est publié ou qu'un utilisateur rejoint un espace. Les applications Chat basées sur les événements examinent la charge utile de l'événement pour obtenir des données sur la ressource Chat modifiée, puis répondent en conséquence.

Les applications Chat peuvent recevoir de nombreux types d'événements, y compris des événements concernant les espaces, les membres, les messages et les réactions. Lorsqu'une application Chat reçoit un événement en interrogeant l'API Chat ou via un abonnement actif, elle peut éventuellement générer un nombre illimité de réponses asynchrones, qu'elle renvoie à Chat à l'aide de l'API Chat.

Vous pouvez utiliser ce type de logique pour mettre à jour des systèmes externes, tels qu'un système de gestion des demandes, ou pour envoyer des messages à un espace Chat de manière asynchrone (par exemple, en envoyant un message de bienvenue lorsqu'un nouvel utilisateur rejoint un espace Chat).

Le schéma suivant illustre un exemple de modèle de conversation basé sur les événements:

Dans le diagramme précédent, l'interaction entre Chat et l'application Chat suit le flux d'informations suivant:

1. L'application Chat s'abonne à un espace Google Chat.
2. L'espace auquel l'application Chat est abonnée change.
3. L'application Chat envoie un événement à un sujet dans Pub/Sub, qui sert de point de terminaison de notification pour l'abonnement. L'événement contient des données sur ce qui a été modifié dans la ressource.
4. L'application Chat traite le message Pub/Sub contenant l'événement et, si nécessaire, prend des mesures.

Pour ce type de modèle de conversation, vous pouvez implémenter une architecture d'application de chat à l'aide de Pub/Sub, d'un service Web ou d'Apps Script.

Pour en savoir plus sur la réception et la réponse aux événements, consultez la section Gérer les événements Google Chat.

Message à sens unique envoyé depuis une application Chat

Un message à sens unique à partir d'un modèle d'application Chat permet à une application Chat d'envoyer des messages asynchrones dans un espace Chat, mais n'autorise pas les utilisateurs à interagir directement avec l'application Chat. Ce modèle n'est pas conversationnel ni interactif, mais peut être utile pour des choses comme les rapports d'alarme, comme illustré dans le diagramme suivant:

Dans le diagramme précédent, un utilisateur dans le même espace que l'application Chat a le flux d'informations suivant:

• L'application Chat envoie un message asynchrone à l'utilisateur en appelant l'API Chat ou en publiant un message sur une URL de webhook (par exemple, "Alerte de dépassement de la file d'attente").
• L'application Chat peut également envoyer des messages asynchrones supplémentaires.

Pour ce type de modèle de conversation, vous pouvez implémenter une architecture d'application Chat à l'aide d'un service Web, d'un webhook, d'Apps Script, d'AppSheet, d'une application de ligne de commande ou d'un script.

Message à sens unique vers une application Chat

Un message à sens unique vers un modèle d'application Chat permet à un utilisateur d'envoyer un message à une application Chat sans que l'application Chat ne réponde tout en continuant de traiter la requête. Bien que cette architecture soit techniquement possible, elle entraîne une mauvaise expérience utilisateur. Nous vous déconseillons vivement d'utiliser ce modèle.

Articles associés

• Créer une application Google Chat
• Utiliser Pub/Sub comme point de terminaison pour votre application Chat
• Envoyer des messages à Chat avec des webhooks entrants
• Créer une application Chat avec Apps Script
• Envoyer un message Chat à partir d'une automatisation à l'aide d'AppSheet
• Intégration de Chat à Dialogflow ES
• Intégration de Chat dans Dialogflow CX