Choisir une architecture d'application Google Chat

Cette page décrit les approches courantes de l'architecture des services 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:

Présentation par fonctionnalités

Le tableau suivant présente les principales fonctionnalités et capacités des applications Chat, ainsi que le style d'architecture de service recommandé (). Dans certains cas, il est possible de développer un autre style d'architecture avec ces caractéristiques, mais il ne convient pas aussi bien au cas d'utilisation que d'autres styles ().

Fonctionnalités et capacités

Service Web ou HTTP

Pub/Sub

Webhooks

Apps Script ;

AppSheet

Dialogflow

Script

Audience visée

Votre équipe

Votre entreprise

Le public

Interactivité des utilisateurs

Utiliser le traitement du langage naturel

Schémas de messages

envoyer et recevoir des messages synchrones ;

Envoyez et recevez des messages synchrones, et envoyez des messages asynchrones.

Envoyer uniquement des messages asynchrones

Envoyer des messages depuis un système externe vers un seul espace Chat

Accéder à d'autres services et systèmes

Intégration dans d'autres services Google

Communiquer derrière un pare-feu

S'abonner aux événements Google Workspace

Styles de codage et de déploiement

Développement sans code

Développement avec peu de code

Développement dans le langage de programmation de votre choix

DevOps simplifié

Gestion complète du DevOps et de la CI/CD

Styles d'architecture des services

Cette section décrit certaines des approches architecturales les plus courantes pour créer des applications de 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 au public sur Google Workspace Marketplace.
  • L'application Chat peut envoyer et recevoir tous les modèles 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:

Architecture d'une application Chat utilisant un service Web sur un serveur sur site.

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 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 billetterie.
  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 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 d'implémenter 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 effectuer d'appels HTTP vers celle-ci. Une approche consiste à utiliser Pub/Sub pour permettre à l'implémentation de l'application Chat de s'abonner à un sujet qui contient des messages de Chat. Pub/Sub est un service de messagerie asynchrone qui dissocie les services produisant des messages des services 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 les é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:

Architecture d'une application Chat implémenté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 dans Chat à 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'application, qui est un système cloud ou sur site contenant la logique d'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 en utilisant des 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 depuis 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:

Architecture permettant aux webhooks entrants d'envoyer des messages asynchrones à Chat.

Dans le schéma précédent, une application Chat comporte 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 projet 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 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, ni publié sur Google Workspace Marketplace. Les webhooks entrants sont recommandés pour les applications Chat afin de signaler les alertes ou l'état, 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 Chat nécessitant peu de code. 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 compiler des applications Chat publiques. Toutefois, cette opération n'est pas recommandée en raison de 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 modèles 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:

Architecture d'une application Chat implémentée avec Apps Script

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, dans un message privé ou dans un espace Chat.
  2. La logique de l'application Chat mise en œuvre 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 d'application Chat dans Chat.
  5. La réponse est transmise à l'utilisateur.

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

AppSheet

Vous pouvez créer une application Chat partagée au sein d'un domaine sans code avec 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:

Architecture d'une application Chat implémentée avec AppSheet

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

  1. Un utilisateur envoie un message dans Chat à une application Chat, dans un message privé ou dans un espace Chat.
  2. La logique de l'application Chat mise en œuvre 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 d'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 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:

Architecture d'une application Chat mise en œuvre avec Dialogflow.

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

  1. Un utilisateur envoie un message dans Chat à une application Chat, dans un message privé ou dans un espace Chat.
  2. Un agent virtuel Dialogflow, qui réside dans Google Cloud, reçoit et traite le message pour produire 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 projet 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 transmise à l'utilisateur.

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

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, telles que la création d'un espace ou la gestion de 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 :

Architecture d'une application Chat implémentée avec une application de ligne de commande ou un script.

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 toute autre méthode adaptée à 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 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 sur des 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 les applications 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 d'implémenter 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 du chat 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 des messages ou d'autres requêtes à Chat, qui ne sont pas déclenchées par des interactions directes de l'utilisateur dans Chat. À la place, ces applications Chat peuvent être déclenchées, par exemple par des applications tierces ou via un appel de ligne de commande à partir d'un utilisateur, mais ne peuvent pas interagir avec ces applications directement dans Chat.

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

Schémas conversationnels

Vous devez réfléchir à la manière dont vous souhaitez que votre application Chat interagit avec les utilisateurs. Les sections suivantes décrivent les modèles de conversation que votre application Chat peut mettre en œuvre.

Appel et réponse (synchrones)

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

Architecture d'un message synchrone.

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 conversationnel, 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:

Architecture d'un message asynchrone.

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, "Monitoring on" (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, "New traffic").
  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 schéma conversationnel, vous pouvez implémenter une architecture d'application Chat à l'aide d'un service Web, Pub/Sub, Apps Script ou 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'abonnement 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. Celle-ci peut éventuellement générer un nombre illimité de réponses asynchrones, qu'elle renvoie ensuite à 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 le modèle de conversation basée sur des événements:

Architecture d'un message basé 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 est modifié.
  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 prend les mesures nécessaires, le cas échéant.

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

Message à sens unique depuis une application Chat

Un message unidirectionnel issu 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 la création de rapports d'alarmes, comme illustré dans le schéma suivant:

Architecture d'un message à sens unique.

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 file d'attente").
  • L'application Chat peut éventuellement envoyer des messages asynchrones supplémentaires.

Pour ce type de schéma conversationnel, 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 unidirectionnel 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 d'utiliser ce modèle.