Remarque : Cet ensemble de documentation concerne les éditions Standard, Plus, paiement à l'usage et Frontline de Gemini Enterprise. Pour la documentation de l'édition Business, consultez le Centre d'aide Gemini Enterprise - Business edition.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Configuration de ServiceNow

Cette page explique comment configurer une configuration tierce avant de créer le data store ServiceNow.

Prérequis

Pour effectuer cette configuration, vous avez besoin d'un [site ServiceNow pour l'instance de développeur personnel (PDI)]. Cette instance fournit un environnement dédié pour configurer OAuth et les autorisations.

URL d'instance : vous devez disposer d'une URL spécifique pour votre environnement. Par exemple, https://your-instance.service-now.com.
Identifiants : vous devez disposer d'un accès administrateur à l'instance.

Créer un compte ServiceNow

Si vous n'avez pas encore de compte ni de PDI, suivez ces étapes pour les configurer :

Pour créer un compte ServiceNow sur le site Developer :
1. Accédez au portail des développeurs ServiceNow, puis cliquez sur Se connecter.
2. Sélectionnez Nouvel utilisateur ? Obtenez un ID ServiceNow.
3. Saisissez vos informations, puis cliquez sur S'inscrire. Utilisez votre adresse e-mail et validez votre compte à l'aide du lien de confirmation envoyé dans votre boîte de réception.
Pour créer une instance de développeur personnelle (PDI) :
1. Connectez-vous au compte du portail des développeurs ServiceNow à l'aide des identifiants de votre compte.
2. Une fois connecté, suivez les instructions du portail pour demander une instance. Une fois le provisionnement terminé, une boîte de dialogue de confirmation s'affiche : "Votre instance est prête !".
3. Enregistrez vos identifiants : lorsque l'instance est prête, le portail fournit l'URL de l'instance, le nom d'utilisateur administrateur et le mot de passe administrateur. Enregistrez-les pour les prochaines étapes de configuration.
4. Pour accéder à votre nouvel environnement, cliquez sur le bouton Start Building (Commencer à créer) dans l'en-tête du site Developer. Votre instance s'ouvre dans un nouvel onglet.

Interface de l'instance ServiceNow Developer — Instance de développeur

Configuration

Pour connecter Gemini Enterprise à ServiceNow, vous devez configurer une application OAuth 2.0 dans votre instance ServiceNow. Les étapes de configuration dépendent de l'utilisation d'un connecteur d'ingestion ou d'un connecteur fédéré. Pour en savoir plus sur les différences, consultez Types de connecteurs.

Pour afficher les étapes de configuration de votre connecteur, sélectionnez-le dans le menu suivant :

Configurer OAuth pour un connecteur fédéré

Pour effectuer une recherche fédérée et des actions, il vous suffit de configurer le flux d'octroi du code d'autorisation OAuth. Cela fournit le code secret du client requis pour la découverte en temps réel et l'exécution des tâches.

Pour créer des identifiants OAuth pour un connecteur fédéré :

Accédez à All > System OAuth > Application registry (Tous > OAuth système > Registre des applications).
Cliquez sur Nouveau > Expérience d'intégration entrante > Nouvelle intégration.
Remplissez les champs obligatoires :
1. Nom de l'intégration : saisissez un nom unique pour l'identifiant OAuth, par exemple "Actions OAuth Gemini Enterprise".
2. Actif : cochez la case.
3. Type d'autorisation : sélectionnez Code d'autorisation OAuth.
4. URL de redirection : saisissez https://vertexaisearch.cloud.google.com/console/oauth/default_oauth.html,https://vertexaisearch.cloud.google.com/oauth-redirect.
5. Champ d'application et règle d'accès aux API : assurez-vous que la case Autoriser l'accès uniquement aux API du champ d'application sélectionné est décochée. De plus, ne sélectionnez aucun champ d'application d'authentification. Si vous laissez ce champ vide, l'intégration sera de portée générale.
Cliquez sur Submit (Envoyer) pour créer l'identifiant.
Une fois la demande envoyée, cliquez sur le nom de l'enregistrement pour afficher l'ID client et démasquer le code secret du client. Enregistrez-les pour une utilisation ultérieure.

Exigences d'accès à l'API Table

Pour que le LLM puisse récupérer les résultats, les utilisateurs finaux doivent disposer du rôle système (généralement snc_internal ou un rôle REST personnalisé) qui leur permet d'accéder aux points de terminaison de l'API Table.

Point de terminaison	Table ServiceNow	Données récupérées
`/api/now/table/incident`	Incident	Demandes, mises à jour de l'état et détails de la résolution.
`/api/now/table/sc_catalog`	Catalogue	Définitions et structures des catalogues de services disponibles.
`/api/now/table/sc_cat_item`	Élément de catalogue	Biens ou services individuels disponibles sur demande.
`/api/now/table/sys_attachment`	Pièce jointe	Métadonnées des fichiers joints aux enregistrements (noms de fichiers, tailles)
`/api/now/table/kb_knowledge`	Connaissances	Articles, procédures et guides de dépannage publiés.

Sécurité et confidentialité des données : authentification de l'utilisateur final

Le connecteur ServiceNow utilise les identifiants de l'utilisateur final pour effectuer des requêtes à l'aide de l'API Table. L'utilisation des identifiants de l'utilisateur final garantit que l'expérience de recherche maintient une parité de sécurité stricte de 1:1 avec l'UI ServiceNow.

Modèle de sécurité

Lorsqu'une requête est envoyée à l'API ServiceNow Table, le connecteur l'exécute dans le contexte de sécurité de l'utilisateur authentifié :

Parité d'identité : comme le connecteur utilise les identifiants de l'utilisateur, le système traite la requête API de la même manière qu'une requête dans la barre de recherche globale de ServiceNow.
LCA héritées : ServiceNow évalue toutes les listes de contrôle d'accès (LCA) au niveau de la base de données. Si un utilisateur ne dispose pas de l'autorisation de lecture pour un enregistrement, l'API Table renvoie un résultat vide ou une erreur 403 pour cet enregistrement.
Application des critères utilisateur : pour les éléments Knowledge (kb_knowledge) et Catalog (sc_cat_item), ServiceNow applique des critères utilisateur. L'API filtre automatiquement les éléments pour lesquels l'utilisateur ne répond pas aux exigences "Disponible pour".

Configurer OAuth pour le connecteur d'ingestion

Pour synchroniser et indexer vos enregistrements à l'aide du connecteur d'ingestion, vous devez créer des identifiants OAuth et configurer des rôles.

Obtenir des identifiants d'authentification

Pour créer des identifiants OAuth pour un connecteur d'ingestion à l'aide de l'intégration entrante, vous devez créer deux ensembles d'identifiants :

Identifiants d'ingestion : utilise le type d'attribution des identifiants de mot de passe du propriétaire de ressource OAuth.
Identifiants Actions : utilise le type d'autorisation "Code d'autorisation OAuth".

1. Créer des identifiants d'ingestion

Connectez-vous à l'instance ServiceNow PDI à l'aide de vos identifiants administrateur.
Accédez à All > System OAuth > Application registry (Tous > OAuth système > Registre des applications).
Cliquez sur New (Nouveau).
Cliquez sur Nouvelle expérience d'intégration entrante > Nouvelle intégration > Type d'autorisation d'identifiants de mot de passe du propriétaire de ressource OAuth.
Remplissez les champs obligatoires :
1. Nom : saisissez un nom unique.
2. Nom du fournisseur : saisissez un nom de fournisseur.
3. Actif : cochez la case.
4. Sécurité du champ d'application et des API : assurez-vous que la case Autoriser l'accès uniquement aux API du champ d'application sélectionné est décochée.
Cliquez sur Envoyer.
Cliquez sur le nom de l'enregistrement pour afficher l'ID client et démasquer le code secret du client. Enregistrez-les pour une utilisation ultérieure.

2. Créer des identifiants Actions

Accédez à All > System OAuth > Application registry (Tous > OAuth système > Registre des applications), puis cliquez sur New (Nouveau).
Cliquez sur Nouvelle expérience d'intégration entrante > Nouvelle intégration.
Renseignez les champs obligatoires :
1. Nom de l'intégration : saisissez un nom unique pour l'identifiant OAuth, par exemple "Actions OAuth Gemini Enterprise".
2. Actif : cochez la case.
3. Type d'autorisation : sélectionnez Code d'autorisation OAuth.
4. URL de redirection : saisissez https://vertexaisearch.cloud.google.com/oauth-redirect.
5. Champ d'application et règle d'accès à l'API : assurez-vous que la case n'est pas cochée et ne sélectionnez aucun champ d'application d'authentification.
Cliquez sur Submit (Envoyer) pour créer l'identifiant.
Cliquez sur le nom de l'enregistrement pour afficher l'ID client et démasquer le code secret du client. Enregistrez-les pour une utilisation ultérieure.

Configurer un compte utilisateur et attribuer des autorisations d'administrateur

Vous pouvez utiliser le compte d'administrateur système par défaut ou créer un utilisateur et attribuer le rôle d'administrateur à votre ID utilisateur.

Attribuer le rôle d'administrateur

Pour élever votre propre rôle à security_admin :

Connectez-vous à votre instance ServiceNow en tant qu'utilisateur disposant du rôle d'administrateur.
Cliquez sur l'icône de votre profil, puis sélectionnez Elevate role (Élever le rôle).
Sélectionnez security_admin, puis cliquez sur Update (Mettre à jour).

Pour accorder le rôle security_admin à un autre utilisateur :

Sélectionnez All (Tous), puis Users (Utilisateurs) sous User Administration (Administration des utilisateurs).
Recherchez et sélectionnez l'utilisateur pour lequel vous devez élever le rôle.
Dans l'onglet Rôles, cliquez sur Modifier.
Sélectionnez security_admin dans Collection et ajoutez-le à la liste des rôles.

Remarque : L'utilisateur disposant du rôle security_admin doit ensuite cliquer sur l'icône de son profil et sélectionner Elevate Role (Élever le rôle) pour l'utiliser.

Configurer des rôles et des autorisations utilisateur

Pour créer un data store ServiceNow dans Gemini Enterprise, vous devez accorder les rôles et autorisations appropriés aux utilisateurs.

Choisissez l'une des options suivantes pour définir les rôles et les autorisations des utilisateurs pour votre instance ServiceNow :

Créer un rôle personnalisé avec des règles LCA (recommandé)
Utiliser un rôle personnalisé avec des administrateurs d'entité
Utiliser un rôle d'administrateur

Pour en savoir plus sur la visibilité et le contrôle des accès, consultez Visibilité des incidents et contrôle des accès.

Créer un rôle personnalisé avec des règles LCA (recommandé)

Créez un rôle personnalisé avec l'ensemble minimal d'autorisations. Cette procédure fournit l'accès le plus sécurisé et le plus restrictif à l'entité incident. Les utilisateurs ne peuvent consulter que les incidents auxquels ils sont directement associés.

Accédez à All > User administration > Roles (Tous > Administration des utilisateurs > Rôles).
Cliquez sur New (Nouveau), saisissez un nom, puis cliquez sur Submit (Envoyer).
Accédez à System security > Access control (ACL) (Sécurité système > Contrôle des accès [LCA]).
Cliquez sur New (Nouveau) pour créer une règle LCA.
Répétez les étapes suivantes jusqu'à ce que vous accordiez l'accès à toutes les tables requises :
1. Utilisez sys_user_role comme exemple pour voir comment l'accès aux tables est accordé.
2. Cliquez sur Submit (Envoyer), puis sélectionnez le rôle.

Accès requis aux tables

Le connecteur a besoin d'accéder aux tables suivantes pour que chaque entité s'exécute.

Nom du tableau	Description
incident	Affichez les incidents dans les résultats de recherche.
sc_cat_item	Affichez les éléments du catalogue dans les résultats de recherche.
sc_cat_item_user_criteria_mtom	Affichez les utilisateurs qui peuvent accéder aux éléments du catalogue en fonction de critères les concernant.
sc_cat_item_user_criteria_no_mtom	Affichez les utilisateurs qui n'ont pas accès aux éléments du catalogue en fonction de critères les concernant.
sc_cat_item_user_mtom	Indiquez les utilisateurs qui peuvent accéder aux éléments du catalogue.
sc_cat_item_user_no_mtom	Affichez les utilisateurs qui n'ont pas accès aux éléments du catalogue.
kb_knowledge	Liste des articles de connaissances pouvant s'afficher dans les résultats de recherche.
kb_knowledge_base	Liste des bases de connaissances pouvant s'afficher dans les résultats de recherche.
kb_uc_can_contribute_mtom	Affichez qui peut contribuer aux bases de connaissances en fonction des critères utilisateur.
kb_uc_can_read_mtom	Indiquez qui peut lire les bases de connaissances en fonction des critères utilisateur.
kb_uc_cannot_read_mtom	Affichez les utilisateurs qui ne peuvent pas lire les bases de connaissances en fonction des critères utilisateur.
sys_user_role	Liste des rôles pouvant être attribués aux utilisateurs.
sys_user_has_role	Liste des rôles attribués aux utilisateurs.
sys_user_group	Liste des segments de groupes d'utilisateurs.
sys_user_grmember	Liste des membres pour les groupes.
sys_user	Liste de tous les utilisateurs.
core_company	Liste de tous les attributs de l'entreprise.
cmn_location	Liste de tous les attributs de lieu.
cmn_department	Liste de tous les attributs de service.
user_criteria	Liste des enregistrements de critères utilisateur.
sp_portal	URI du portail de liens dans les résultats de recherche.
m2m_sp_portal_knowledge_base	URI du portail de liens pour les articles de connaissances dans les résultats de recherche.
m2m_sp_portal_catalog	URI du portail de liens pour les éléments du catalogue dans les résultats de recherche.

Accorder et vérifier l'accès aux LCA

Le connecteur nécessite un accès LCA aux champs d'éléments du catalogue de la table sc_cat_item.

Pour accorder et vérifier l'accès, procédez comme suit :

Accordez un accès explicite en créant une règle LCA et en saisissant manuellement sc_cat_item.* dans le champ Name (Nom) du formulaire.

Saisissez sc_cat_item.*
Vérifiez que les LCA sont à jour.
Accédez à sys_security_acl_role_list.do dans la barre de recherche.
Définissez Role (Rôle) sur le rôle que vous souhaitez vérifier.

Sélectionner le rôle à valider
Vérifiez que les LCA requises sont attribuées au rôle.

Utiliser un rôle personnalisé avec des administrateurs d'entité

Le rôle d'administrateur ne convient pas forcément aux équipes ou aux organisations qui souhaitent éviter d'attribuer des autorisations trop importantes. Cette option fournit un rôle avec trois autorisations spécifiques qui accordent l'accès requis.

Accédez à All > System security > Users and groups > Roles (Tous > Sécurité système > Utilisateurs et groupes > Rôles).
Sélectionnez New (Nouveau), puis saisissez un nom.
Cliquez sur Envoyer.
Recherchez le rôle créé dans la liste.
Accédez à Contains roles > Edit (Contient les rôles > Modifier).
Ajoutez les rôles suivants au rôle que vous venez de créer, puis cliquez sur Enregistrer :
- catalog_admin
- knowledge_admin
- incident_manager
Ajoutez des rôles, puis cliquez sur le bouton "Enregistrer".
Confirmez les rôles mis à jour.

Confirmer les rôles

Utiliser un rôle d'administrateur

Vous pouvez utiliser un rôle d'administrateur pour extraire des données. Utilisez le rôle d'administrateur par défaut configuré avec l'instance ou créez un nouvel utilisateur avec un rôle d'administrateur en procédant comme suit :

Accédez à All > User administration > Users (Tous > Administration des utilisateurs > Utilisateurs).
Créez un nouvel utilisateur.
Activez l'option Web service access only (Accès au service Web uniquement). Lorsque vous sélectionnez Web service access only (Accès au service Web uniquement), vous créez un utilisateur non interactif.
- Les utilisateurs interactifs peuvent se connecter à l'UI et au portail de service ServiceNow à l'aide d'identifiants standards ou de l'authentification unique, avec un accès complet aux pages de l'UI et aux points de terminaison de l'API.
- Les utilisateurs non interactifs disposent d'un accès limité à l'UI et ne peuvent qu'autoriser les connexions API programmatiques pour l'intégration de service à service.
Une fois l'utilisateur créé, sélectionnez-le dans la liste des utilisateurs.
Cliquez sur Roles > Edit (Rôles > Modifier).
Ajoutez un Admin (Administrateur).
Cliquez sur Save (Enregistrer) pour ajouter une liste de rôles à l'utilisateur.
Cliquez sur Set password (Définir un mot de passe), générez-le automatiquement, puis enregistrez-le.

Attribuer un rôle à un utilisateur

Accédez à All > User administration > Users (Tous > Administration des utilisateurs > Utilisateurs).
Recherchez ou créez un utilisateur. Si aucun utilisateur n'est disponible, accédez à System security > Users and groups > Users (Sécurité système > Utilisateurs et groupes > Utilisateurs).
Cliquez sur Nouveau.
Créez un compte de service dans la table des utilisateurs. Veillez à cliquer sur Web service access only (Accès au service Web uniquement).
Faites défiler la page jusqu'à Roles (Rôles), puis cliquez sur Edit (Modifier).
Accordez le rôle que vous avez créé et attribuez-le à l'utilisateur. En fonction du type de rôle que vous avez créé à l'étape précédente, sélectionnez celui qui convient et attribuez-le à l'utilisateur. Cliquez sur Enregistrer.
Affichez le rôle personnalisé avec la LCA.
Obtenez le nom d'utilisateur et le mot de passe de l'utilisateur, puis cliquez sur Set password (Définir le mot de passe).
Générez automatiquement un mot de passe et conservez-le pour une utilisation ultérieure.

Visibilité des incidents et contrôle des accès

Pour renforcer la sécurité et éviter l'exposition involontaire des données, le connecteur ServiceNow utilise contrôle des accès restrictif pour l'entité incident. Cela permet de s'assurer que les utilisateurs finaux ne peuvent consulter que les incidents auxquels ils sont directement associés.

Dans cette approche restrictive, le connecteur ne respecte pas les autorisations générales basées sur les rôles pour la visibilité des incidents. Les rôles ServiceNow standards tels que itil et sn_incident_read, qui peuvent donner à un utilisateur une visibilité sur tous les incidents dans l'UI ServiceNow, n'accordent pas le même niveau d'accès dans Gemini Enterprise.

Les utilisateurs disposant de l'un des rôles suivants ont une visibilité globale sur les incidents et peuvent tous les consulter :

admin
incident_manager
change_manager

Tous les autres utilisateurs ne peuvent consulter un incident que s'ils l'ont ouvert, rouvert, résolu ou fermé. Ils peuvent également consulter un incident s'ils sont :

membres du groupe d'attribution de l'incident ;
un appelant associé à l'incident ;
une personne responsable ;
inclus dans une liste de surveillance ;
inclus dans une liste de notes de travail ;
inclus dans une liste de personnes responsables supplémentaires.

Ce comportement empêche un utilisateur de Gemini Enterprise de consulter un incident auquel il n'a pas accès. En raison des restrictions supplémentaires par rapport aux autorisations ServiceNow plus générales, ce comportement peut parfois empêcher un utilisateur de consulter un incident dans Gemini Enterprise auquel il a accès dans ServiceNow.