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 l'utiliser ou l'adapter. 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 de présentation.
• Consultez un résumé de chaque style d'architecture.
• Consultez un résumé de la logique de l'application Chat.
• Consultez un résumé des modèles de conversation des applications Chat.

Présentation par fonctionnalités

Le tableau suivant présente les principales 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 capacités	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 organisation	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é des utilisateurs
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
Envoyez et recevez des messages synchrones, et envoyez 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
S'abonner aux événements Google Workspace		verified
Styles de codage et de déploiement
Développement sans code					verified
Développement nécessitant peu de programmation			verified	verified		check_circle_outline	check_circle_outline
Développement dans le 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 du DevOps et de la CI/CD	verified	verified					check_circle_outline

Styles d'architecture des services

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 il offre aux développeurs la plus grande flexibilité pour créer des applications de chat publiques. Cette architecture est recommandée pour les cas d'utilisation suivants:

• L'application Chat est déployée publiquement sur Google Workspace Marketplace.
• L'application Chat peut envoyer et recevoir tous les formats de messagerie: envoi et réception de messages synchrones, envoi de messages asynchrones et envoi de 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 du DevOps et de la CI/CD.
• Le service d'application Chat est mis en œuvre sur des serveurs cloud ou sur site.

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

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

1. Un utilisateur envoie un message à une application Chat dans un espace Chat.
2. Une requête HTTP est envoyée à un serveur Web, qu'il s'agisse d'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 projets ou un outil de billetterie.
4. Le serveur Web renvoie une réponse HTTP au service de l'application Chat dans Chat.
5. La réponse est envoyée à 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 des bibliothèques et des composants existants qui existent déjà dans votre système, car ces applications Chat peuvent être conçues à l'aide de différents langages de programmation. Il existe différentes manières de mettre en œuvre cette architecture. Sur Google Cloud, vous pouvez utiliser Cloud Functions, Cloud Run et App Engine. Pour commencer, consultez la page Créer une application Google Chat avec Cloud Functions.

Pub/Sub

Si l'application Chat est mise en œuvre derrière un pare-feu, Chat ne peut pas y effectuer d'appels HTTP. Une approche consiste à utiliser Pub/Sub pour permettre à l'implémentation de l'application Chat de s'abonner à un sujet qui contient des messages depuis Chat. Pub/Sub est un service de messagerie asynchrone qui dissocie les services produisant des messages de ceux qui les traitent. Cette architecture est recommandée pour les cas d'utilisation suivants:

• L'application Chat est protégée par 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 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 du DevOps et de la CI/CD.

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

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

1. Un utilisateur envoie un message à une application Chat dans un message privé ou dans 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'applications, qu'il s'agisse d'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 de 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 vers une URL de webhook Chat. Cette architecture est recommandée pour les cas d'utilisation suivants:

• L'application Chat est déployée pour 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 ne permet pas d'interaction utilisateur, comme illustré dans le schéma suivant:

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

1. La logique de l'application Chat reçoit des informations de services tiers externes, tels qu'un système de gestion de projets ou un outil de billetterie.
2. La logique de l'application Chat est hébergée dans un système cloud ou sur site qui peut envoyer des messages à un espace Chat spécifique à l'aide d'une URL de webhook.
3. Les utilisateurs peuvent recevoir des messages de l'application Chat dans cet espace Chat, 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, ni publié sur Google Workspace Marketplace. Les webhooks entrants sont recommandés pour les applications Chat pour signaler des alertes ou des états, ou pour certains types de prototypage d'applications Chat.

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

Apps Script ;

Vous pouvez créer la logique de votre application Chat entièrement en JavaScript. Google Apps Script est une plate-forme de développement d'applications de chat nécessitant peu de programmation. 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 de chat publiques, mais cette opération n'est pas recommandée 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 pour votre équipe ou votre organisation.
• L'application Chat peut envoyer et recevoir tous les formats de messagerie: envoi et réception de messages synchrones, envoi de messages asynchrones et envoi de 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 Workspace et Google, tels que Google Sheets, Google Slides, Google Agenda, Google Drive, Google Maps et YouTube, comme illustré dans le schéma suivant:

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

1. Un utilisateur envoie un message à une application Chat, soit par message privé, soit dans un espace Chat.
2. La logique de l'application Chat implémentée dans Apps Script, qui réside 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'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 la page Créer une application Chat avec Apps Script.

AppSheet

Vous pouvez créer une application Chat partagée au niveau du 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 des modèles pour créer des actions courantes dans les applications Chat. Cependant, 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 envoyer des messages asynchrones.
• L'application Chat nécessite une gestion DevOps simplifiée.

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

Dans le schéma précédent, un utilisateur qui interagit avec une application Chat AppSheet présente 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 réside 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'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 envoyée à l'utilisateur.

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

Dialogflow

Vous pouvez créer une application Chat à l'aide de Dialogflow, une plate-forme en 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 illustre l'architecture d'une application Chat créée avec Dialogflow:

Dans le schéma précédent, un utilisateur qui interagit avec une application Dialogflow Chat présente 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. La logique de l'application Chat peut éventuellement interagir avec des services tiers externes, tels qu'un système de gestion de projets ou un outil de billetterie.
4. L'agent Dialogflow renvoie une réponse au service de l'application Chat dans Chat.
5. La réponse est envoyée à l'utilisateur.

Pour commencer, consultez Intégration de Chat Dialogflow ES ou Intégration de Chat avec Dialogflow CX.

Application de ligne de commande ou script

Vous pouvez créer une application de ligne de commande ou un script qui envoie des messages à Chat ou effectue d'autres opérations, comme créer un espace ou gérer ses membres, sans permettre aux utilisateurs d'appeler directement l'application Chat ou d'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 peut uniquement envoyer des messages asynchrones.

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

Dans le schéma précédent, l'application Chat comporte 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 imprime éventuellement une confirmation dans la CLI.

Implémentation de la logique de l'application Chat

Chat ne limite pas la manière 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 avancés d'IA et de traitement du langage, vous abonner à des événements et y répondre, ou tout autre élément adapté à vos objectifs.

Gérer les interactions des utilisateurs

L'application Chat peut recevoir les interactions des utilisateurs et y répondre de différentes manières. Une interaction utilisateur est une action effectuée par un utilisateur pour appeler une application Chat ou interagir avec elle.

Analyseur de commandes

Les applications Chat basées sur des commandes examinent la charge utile des événements d'interaction avec les applications Chat, puis extraient les commandes et les paramètres de ce contenu. Par exemple, consultez la section 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 les 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 fiches dans lesquelles l'utilisateur peut interagir avec l'application Chat, par exemple remplir des formulaires ou demander des actions.

Chaque fois que l'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 de mettre en œuvre le TLN, et vous pouvez choisir de le faire comme vous le souhaitez.

Vous pouvez utiliser le TLN dans la mise en œuvre de votre application Chat avec Dialogflow ES ou l'intégration de Chat avec Dialogflow CX, qui vous permet de créer des agents virtuels pour les conversations automatisées et les réponses dynamiques.

Envoyer des demandes à Chat de manière proactive

Les applications de chat peuvent également envoyer à Chat des messages ou d'autres requêtes 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'un appel de ligne de commande à partir d'un utilisateur. Toutefois, celui-ci ne peut pas interagir avec ces applications de chat directement 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 conversationnels

Vous devez déterminer la manière dont votre application Chat interagira avec les utilisateurs. Les sections suivantes décrivent les modèles de conversation que votre application Chat peut implémenter.

Appel et réponse (synchrones)

Avec 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 schéma suivant:

Dans le schéma précédent, un utilisateur qui interagit avec une application Chat présente 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 à 2:30".

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

Réponses multiples (asynchrone)

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

Dans le schéma précédent, un utilisateur qui interagit avec une application Chat présente 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 accuser réception de 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 accuser réception de 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 Chat à l'aide d'un service Web, de Pub/Sub, d'Apps Script ou d'AppSheet.

S'abonner à des événements (asynchrone)

Dans un modèle asynchrone basé sur des événements, l'application Chat s'abonne aux événements à l'aide de l'API Google Workspace Events. Les applications Chat basées sur des événements examinent la charge utile des événements d'abonnements à Chat, puis répondent en fonction du type d'événement. Lorsqu'un événement se produit dans un espace Chat pour lequel l'application Chat dispose d'un abonnement actif, Chat l'envoie à l'application Chat. L'application Chat peut ensuite 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 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 le modèle de conversation basée sur des événements:

Dans le schéma précédent, l'interaction entre Chat et l'application Chat présente 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 les mesures nécessaires.

Pour ce type de modèle de conversation, vous pouvez implémenter une architecture d'application Chat à l'aide de Pub/Sub.

Message à sens unique depuis une application Chat

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

Dans le schéma précédent, un utilisateur se trouvant dans le même espace que l'application Chat présente le flux d'informations suivant:

• L'application Chat envoie un message asynchrone à l'utilisateur en appelant l'API Chat ou en publiant un post 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 schéma d'application Chat permet à un utilisateur d'envoyer un message à une application Chat sans que celle-ci ne réponde, tout en continuant à traiter la requête. Bien que cette architecture soit techniquement possible, elle nuit à l'expérience utilisateur et nous vous déconseillons vivement de le faire.

Articles associés

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