> For the complete documentation index, see [llms.txt](https://help.glpi-project.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.glpi-project.org/glpi-12/fr/administration/entities.md).
# Entités
Les entités sont un **concept clé dans GLPI**. Ayant de nombreuses similitudes avec une hiérarchie ou une division au sein d'une entreprise, elles permettent sur une seule instance de GLPI d'isoler des ensembles organisés de manière hiérarchique. Le terme choisi est volontairement neutre afin de s'adapter à de nombreux systèmes d'information.
Une seule instance (ou installation) de GLPI, lorsqu'elle est composée de plusieurs entités, permet de consolider des données et des règles communes. L'utilisation d'entités permet de créer une isolation stricte entre les unités organisationnelles.
{% hint style="success" %}
Lorsque cette isolation n'est pas souhaitée, il est préférable d'utiliser les fonctionnalités offertes par les *Groupes* de GLPI.
{% endhint %}
La segmentation en entités peut avoir plusieurs objectifs :
* isoler les actifs de chaque division afin de limiter la visibilité des actifs pour les groupes ou les utilisateurs
* isoler les actifs des clients
* reproduire la hiérarchie existante de l'annuaire (LDAP, Active Directory...).
L'utilisation d'entités est très utile pour une entreprise où la gestion est hiérarchique et où les employés doivent avoir accès aux actifs en fonction de la division à laquelle ils appartiennent.
Une fois qu'une entité est créée dans GLPI, l'inventaire des actifs, les utilisateurs, les profils et le service d'assistance deviennent dépendants des entités : un ordinateur peut être affecté à une entité, un ticket peut être déclaré sur une entité, les profils et les autorisations peuvent être spécifiques aux entités... L'affectation automatique d'entités pour les utilisateurs et les actifs est possible grâce à la [gestion des règles](/glpi-12/fr/administration/rules/userauthorizations.md).
{% hint style="info" %}
**Exemple : entités au sein d'une entreprise**
{% endhint %}
L'entité racine a deux filiales (Entité 1 et Entité 2) qui ont elles-mêmes deux divisions chacune (Sous-entité 1 et 2). Chaque entité a accès à ses actifs et aux entités subsidiaires :
> * **Entité racine** a accès à ses actifs ainsi qu'à tous les actifs de toutes les entités
> * **Entité 1** a accès à ses actifs ainsi qu'aux actifs de la sous-entité 1 et 2
> * **Sous-entité 1** n'a accès qu'à ses propres actifs
Un utilisateur peut avoir des autorisations différentes dans différentes entités et ces autorisations peuvent être rendues récursives pour s'appliquer optionnellement aux entités enfants.
Par exemple, un utilisateur peut être rattaché à plusieurs entités avec des permissions différentes dans chaque entité, ces permissions étant conservées (ou non) dans les entités enfants. Sans permission, il ne pourra alors visualiser que les éléments de sa propre entité qu'il souhaiterait lier à ce ticket (FAQ, actif, catégorie, etc.).
En revanche, si un utilisateur dispose des permissions suffisantes (voir profil, et je fournirai un lien vers cette partie de la documentation), il pourrait alors voir certains éléments qui ne sont pas autorisés pour d'autres profils. Par exemple, un utilisateur avec un profil technicien pourrait voir l'inventaire de son entité, tandis qu'un manager pourrait voir l'inventaire de l'entité parente et de toutes les entités enfants. On peut également supposer qu'un technicien informatique ne pourrait voir que les ordinateurs de son entité, tandis qu'un technicien infrastructure pourrait voir tous les actifs (équipements réseau, racks, baies, etc.) de cette même entité.
Par défaut, GLPI possède une seule entité générique nommée *Entité racine*. Cette entité peut être renommée à la convenance de l'utilisateur.
Les processus peuvent varier en fonction de l'entité ; pour cette raison, les entités peuvent avoir une administration déléguée (autorisation *Entités* dans le profil). Cette délégation doit être accordée à un nombre très limité d'utilisateurs qui seront en charge de la gestion complète de l'entité.
Lors de l'utilisation de GLPI en mode multi-entités, la gestion de certains paramètres de configuration peut s'appliquer différemment dans chaque entité.
## Entités
Cet onglet liste les sous-entités existantes et permet d'ajouter une sous-entité à l'entité courante.
***
## Adresse
Cet onglet regroupe les informations administratives de l'entité courante :
* Téléphone
* Numéro administratif
* Fax
* Site web
* Email
* Code postal
* Adresse
* Ville
* État
* Pays
* Localisation sur la carte
* Longitude
* Latitude
* Altitude
***
## Informations avancées
Cet onglet regroupe les données d'identification technique de l'entité, celles concernant les règles génériques d'affectation d'entité et celles concernant l'interface de recherche d'utilisateurs. Ces données seront utilisées par les règles d'affectation automatique à l'entité (matériel si couplé à un outil d'inventaire, utilisateur ou groupe si connecté à un annuaire LDAP, ticket si création de ticket via collecteur mail activée) ainsi que pour l'import et la synchronisation des utilisateurs issus d'un annuaire LDAP.
### Valeurs pour les règles génériques d'affectation aux entités
Trois options sont disponibles pour les règles génériques d'affectation d'entité :
* Information dans l'outil d'inventaire (TAG) représentant l'entité : provenant de l'outil d'inventaire
* Attribut d'information de l'annuaire LDAP représentant l'entité : par exemple le `DN` de l'entité
* Entité substitut de domaine de messagerie : le domaine de messagerie associé à l'entité
### Valeurs utilisées dans l'interface pour rechercher des utilisateurs depuis un annuaire LDAP
Afin d'offrir à un administrateur d'entité la possibilité d'importer des utilisateurs depuis un annuaire LDAP,
* Annuaire LDAP : annuaire associé à l'entité
* Filtre LDAP associé à l'entité (si nécessaire) : associé au filtre de recherche de l'entité
Ce filtre de recherche n'a de sens que si la définition de l'entité se fait en ajoutant une restriction sur le filtre LDAP. Il est également possible de définir le domaine de messagerie spécifique à l'entité qui pourra être utilisé pour affecter les utilisateurs à cette entité.
***
## Notifications
Le paramétrage des notifications se fait au niveau de l'entité.
### Options de notification
* Adresse email de l'administrateur
* Nom de l'administrateur
* Adresse email de l'expéditeur
* Nom de l'expéditeur
* Adresse de non réponse
* Nom du de non réponse
* Adresse de non réponse
* Nom de non réponse
* Préfixe pour les notifications
* Délai pour envoyer des notifications par mail (héritage de l'entité parente ou délai en minutes)
* Activer les notifications par défaut (Non/Oui/Héritage de l'entité parente)
* Signature des e-mails
* URL de l'application
{% hint style="info" %}
Pour chaque entité, le délai appliqué avant l'envoi d'une notification peut être défini. Ce délai permet par exemple en cas de modifications rapides et multiples d'un ticket de n'envoyer qu'un seul email de notification. Le suivi par email d'un acteur peut également être défini sur Oui ou Non.
{% endhint %}
### Options des alertes
{% hint style="info" %}
Si un affinage des notifications au niveau de l'entité n'est pas souhaité, ces paramètres peuvent être définis une seule fois au niveau de l'entité racine ; chaque entité récupérera alors par défaut les valeurs définies au niveau de l'entité parente.
{% endhint %}
{% hint style="warning" %}
Chaque option d'alerte est associée à une action automatique. Si l'action est désactivée par l'administrateur GLPI, aucune notification ne sera envoyée.
{% endhint %}
#### Cartouches
* **Fréquence de rappel des alarmes sur les consommables** : Héritage de l'entité parente/Jamais/Chaque jour/Chaque semaine/Chaque mois
* **Seuil par défaut pour les cartouches** : Héritage de l'entité parente/jamais/de 0 à 100
#### Consommables
* **Fréquence des rappels pour les alarmes sur les consommables** : Héritage de l'entité parente/Jamais/Chaque jour/Chaque semaine/Chaque mois
* **Seuil par défaut sur les consommables** : Héritage de l'entité parente/jamais/de 0 à 100
#### Contacts
* **Alertes sur les contacts** : Non/Oui/Héritage de l'entité parente
* **Valeur par défaut** : Héritage de l'entité parente/Fin/Avis/Fin+avis/Fin de période/Fin de période + avis
* **Envoyer des alertes sur les contrats avant** : Non/Héritage de l'entité parente/de 1 à 365 jours
#### Informations financières et administratives
* **Alertes sur les informations financières et administratives** : Non/Oui/Héritage de l'entité parente
* **Valeur par défaut** : Héritage de l'entité parente/Date d'expiration de la garantie
* **Envoyer les alertes sur les informations financières et administratives avant** : Non/Héritage de l'entité parente/de 1 à 365 jours
#### Licences
* **Alarmes sur licences expirées** : Non/Oui/Héritage de l'entité parente
* **Envoyer les alarmes de licence avant** : Non/Héritage de l'entité parente/de 1 à 365 jours
#### Certificats
* **Alertes à l'expiration des certificats** : Non/Oui/Héritage de l'entité parente
* **Envoyer d'une alerte avant** : Non/Héritage de l'entité parente/de 1 à 365 jours
* **Fréquence de rappel des alarmes sur les certificats** : Héritage de l'entité parente/Jamais/Chaque jour/Chaque semaine/Chaque mois
#### Réservations
* **Alertes sur les réservations** : Non/Héritage de l'entité parente/de 1 à 365 heures
#### Tickets
* **Alertes sur tickets non résolus depuis** : Non/Héritage de l'entité parente/de 1 à 365 jours
#### Tickets / Changements
* **Fréquence de rappel des validations** : Héritage de l'entité parente/Jamais/Chaque jour/Chaque semaine/Chaque mois
#### Domaines
* **Alarmes sur l'expiration des domaines** : Non/Oui/Héritage de l'entité parente
* **Domaine proche de l'expiration** : Non/Héritage de l'entité parente/de 1 à 365 jours
* **Domaines expirés** : Non/Héritage de l'entité parente/de 1 à 365 jours
***
## Assistance
Cet onglet est visible si l'autorisation *Lire ou Modifier les paramètres de l'entité* est accordée dans le profil. L'onglet regroupe les paramètres de l'entité applicables aux tickets :
### Configuration des modèles
* **Gabarit de ticket** : le modèle sélectionné sera utilisé pour chaque création de ticket ;
* **Gabarit de changement** : le modèle sélectionné sera utilisé pour chaque création de ticket ;
* **Gabarit de problème** : le modèle sélectionné sera utilisé pour chaque création de ticket ;
### Configuration des tickets
* **Calendrier** : calendrier par défaut de l'entité pour le calcul du temps de résolution des tickets et du décalage de la date cible ; ce calendrier sera présélectionné lors de la création d'un SLA ;
* **Type par défaut pour les tickets** : type prédéfini pour la création de ticket ; utile pour la création de ticket via le collecteur d'e-mails ;
* **Assignation automatique des tickets, changements et problèmes** : permet d'assigner automatiquement un ticket ;
* *Non*
* *basé sur l'élément puis sur la catégorie* : si le ticket a un élément associé et que cet élément a un responsable technique ou un groupe, il sera assigné à ce technicien et/ou groupe ; sinon, si le ticket a une catégorie définie, il sera assigné au responsable technique ou au groupe de la catégorie
* *basé sur la catégorie puis sur l'élément* : si le ticket a une catégorie définie et que cette catégorie a un responsable technique ou un groupe, il sera assigné à ce responsable technique ou groupe ; sinon, si le ticket a un élément associé, il sera assigné au technicien et/ou groupe de l'élément
* **Marquer comme privé le suivi ajouté par un fournisseur via un collecteur d'email** : Non/Oui/Héritage de l'entité parente
* **Anonymiser les agents de support** :
* *Héritage de l'entité parente*
* *Désactivé*
* *Remplacer le nom de l'agent et du groupe par un nom générique*
* *Remplacer l'agent et le groupe par un pseudonyme personnalisable*
* *Remplacer le nom de l'agent par un nom générique*
* *Remplacer le nom de l'agent par un nom personnalisable*
* *Remplacer le nom du groupe par un nom générique*
* **Afficher les initiales pour les utilisateurs sans images** : Non/Oui/Héritage de l'entité parente
* **Contrat par défaut** : Héritage de l'entité parente/Contact dans l'entité ticket
{% hint style="success" %}
Lorsque vous sélectionnez l'option d'anonymisation pour utiliser un nom personnalisé, un nouveau champ de pseudonyme apparaîtra dans le profil du groupe et/ou de l'utilisateur (si vous êtes dans l'entité où vous avez sélectionné cette option). Ce nom personnalisé sera donc visible par les utilisateurs.
{% endhint %}
### Configuration de la clôture automatique
{% hint style="success" %}
Si le message `L'action de purge des tickets est désactivée` est présent, allez dans Configuration > Actions automatiques et activez l'action `purgeticket`.
{% endhint %}
* **Clôture automatique des tickets résolus après** : permet d'effectuer une clôture dite "administrative" ; si la clôture est définie sur *immédiatement*, le ticket sera clôturé dès qu'il sera résolu, ce qui bloquera l'approbation de la solution par le demandeur. Cette clôture est effectuée par une action automatique qui doit donc être active. De jamais à 365 jours
* **Purge automatique des tickets clôturés après** : permet de clôturer les tickets une fois qu'ils ont été résolus après une certaine période. De jamais à 365 jours
### Configuration de l'enquête de satisfaction : Tickets
* **Configuration de l'enquête de satisfaction** : Externe ou interne (si externe, un champ URL apparaîtra pour indiquer l'URL de l'enquête)
* **Déclencher l'enquête après** : Envoyer un e-mail après la résolution du ticket (dès que possible à 90 jours)
* **Taux d'enquêtes à déclencher** : Désactivé à 100%
* **Durée de l'enquête** : Durée pendant laquelle l'enquête sera active (non spécifié à 100 jours)
* **Taux maximum** : Score maximum autorisé (1 à 10)
* **Taux par défaut** : Nombre par défaut saisi à la réception de l'enquête
* **Commentaire requis si la note est <= à** : 1 à 10
* **Pour tickets clôturés après** : Indiquer une date pour commencer à envoyer des enquêtes
{% hint style="success" %}
L'enquête peut être interne (formulaire de satisfaction GLPI) ou déléguée à un outil tiers. Pour chaque entité, la date de l'enquête peut être définie (délai après clôture du ticket) ainsi que le taux de génération de l'enquête. Afin d'éviter que les anciens tickets ne soient pris en compte lors de l'activation de l'enquête, un champ *Pour les tickets clôturés après* contient la date d'activation pour savoir quels tickets doivent être pris en compte. En effet, si les enquêtes sont réactivées après une période de désactivation, ce champ doit être défini pour exclure les anciens tickets. Pour les enquêtes externes, l'URL de l'enquête peut être générée automatiquement à l'aide des balises définies ci-dessous.
{% endhint %}
**Liste des balises disponibles pour l'URL de l'enquête :**
| TAG | Nom |
| ----------------------- | ------------------------------------------------------------------- |
| `[TICKET_ID]` | ID du ticket |
| `[TICKET_NAME]` | Nom du ticket |
| `[TICKET_CREATEDATE]` | Date de création du ticket |
| `[TICKET_SOLVEDATE]` | Date de résolution du ticket |
| `[TICKET_PRIORITY]` | ID de priorité du ticket |
| `[TICKET_PRIORITYNAME]` | Nom de la priorité du ticket |
| `[ITILCATEGORY]` | ID de la catégorie ITIL |
| `[ITILCATEGORY_NAME]` | Nom de la catégorie ITIL |
| `[SOLUTIONTYPE_ID]` | ID du type de solution |
| `[SOLUTIONTYPE_NAME]` | Nom de la solution |
| `[REQUESTTYPE_ID]` | ID de la source de la demande |
| `[REQUESTTYPE_NAME]` | Nom de la source de la demande (téléphone, help desk...) |
| `[TICKETTYPE_ID]` | Type de ticket |
| `[TICKETTYPE_NAME]` | Nom du type de ticket (gestion des incidents ou demande de service) |
| `[SLA_TTO_ID]` | ID TTO (Time To Own) |
| `[SLA_TTO_NAME]` | Nom TTO (Time To Own) |
| `[SLA_TTR_ID]` | ID TTR (Time To Resolve) |
| `[SLA_TTR_NAME]` | Nom TTR (Time To Resolve) |
| `[SLALEVEL_ID]` | ID du niveau SLA |
| `[SLALEVEL_NAME]` | Nom du niveau SLA |
### Configuration de l'enquête de satisfaction : Changements
* **Configuration de l'enquête de satisfaction** : Externe ou interne (si externe, un champ URL apparaîtra pour indiquer l'URL de l'enquête)
* **Déclencher l'enquête après** : Envoyer un e-mail après la résolution du ticket (dès que possible à 90 jours)
* **Taux d'enquêtes à déclencher** : Désactivé à 100%
### Helpdesk
* **Afficher les propriétés des tickets sur le helpdesk** : Cette option permet d'afficher ou non les informations liées aux tickets visibles par les profils self-service (urgent, catégorie, assignation, etc.)
***
## Parc
Cet onglet permet de configurer les différentes dates présentes dans les informations administratives et financières ainsi que certaines autres options d'actifs au niveau de l'entité.
### Remplissage automatique des dates pour les informations financières et administratives
* **Date d'achat**
* **Date de commande**
* **Date de livraison**
* **Date de mise en service**
* **Date de début de garantie**
* **Date de réforme**
Les actions automatiques possibles sont :
* Remplissage lorsque l'élément obtient un statut particulier ;
* Remplissage en copiant une autre date (garantie, livraison, etc.) ;
* Pas de remplissage automatique
### Logiciel
L'option *Entité pour la création de logiciels* permet de rediriger la création de logiciels vers une autre entité de niveau supérieur dans la hiérarchie. Cette fonctionnalité s'applique à *tous* les logiciels de l'entité ; si une redirection doit être définie uniquement pour certains logiciels, le [dictionnaire de logiciels](/glpi-12/fr/administration/dictionnaries.md) doit être utilisé.
### Transférer
* **Modèle des inventaires pour le transfert automatique d'entités**
GLPI permet également de transférer un ordinateur dans une autre entité si l'un des critères utilisés pour l'affectation à une entité est modifié. Si l'option Modèle pour le transfert automatique d'ordinateurs dans une autre entité indique un modèle existant, alors chaque fois qu'un ordinateur est mis à jour depuis l'outil d'inventaire, le moteur de règles d'affectation d'entité sera rejoué. Si l'entité résultante est différente de l'entité actuelle, l'ordinateur sera transféré vers la nouvelle entité.
**Choix possibles** :
* *Complet*
* *Pas de transfert automatique*
{% hint style="info" %}
Cette option de configuration n'est pas présente si vous n'avez qu'une seule entité dans votre instance.
{% endhint %}
### Inventaire automatique
Ce champ est utilisé si vous avez plusieurs serveurs GLPI. Lorsque ce champ est défini, l'agent pourra récupérer la configuration des tâches de déploiement, de collecte et d'inventaire ESX à partir du serveur spécifié. Cela évite les redirections de serveur web si vous ne souhaitez pas les utiliser.
### Mise à jour automatique des éléments liés aux ordinateurs
Ce champ vous permet de spécifier si les informations relatives aux équipements (imprimantes, périphériques, etc.) connectés aux PC peuvent être mises à jour lors de la connexion d'un utilisateur ou de la prochaine mise à jour de l'inventaire. Vous pouvez également choisir le comportement lorsque l'équipement est déconnecté.
Les informations qui peuvent être gérées
* Nom d'utilisateur alternatif
* Utilisateur
* Groupe
* Lieu
* Statut
Vous pouvez **copier** ou **ne pas copier** **lors de la connexion ou de la mise à jour du champ pertinent**. Vous pouvez **supprimer** ou **ne pas supprimer** **lors de la déconnexion**.
## Personnalisation de l'interface utilisateur
Cet onglet permet de configurer des règles CSS personnalisées par entité, de spécifier l'héritage de CSS personnalisées d'une entité parente, ou de désactiver complètement le CSS personnalisé.
{% hint style="info" %}
Pour créer des palettes personnalisées, consultez [Créer des palettes personnalisées](/glpi-12/fr/configuration-avancee/custom_palettes.md).
{% endhint %}
***
## Sécurité
Cet onglet permet de forcer ou non l'authentification à deux facteurs (2FA). Vous pouvez consulter l'article [dédié](https://github.com/glpi-network/gitbook-fr/blob/develop/first-steps/preferences.md#two-factor-authentication-tab) pour plus d'informations.
Voir 2FA
***
## Accueil du Helpdesk
Cet onglet permet de personnaliser la page d'accueil (la page d'accueil du profil libre-service) et les informations qu'elle contient.
À partir de la vignette **+ Ajouter une vignette**, vous pouvez ajouter 3 types de vignettes :
* **Page GLPI** : par exemple, catalogue de services, FAQ, etc.
* **Page externe**
* **Formulaire** : permet de sélectionner un formulaire existant
Pour les pages GLPI et les pages externes, vous pouvez choisir :
* *Un titre*
* *Une description*
* *Une illustration* (existante ou en ajouter une nouvelle)
Pour les formulaires, ils peuvent être créés à partir de **`Administration`** *>* **`Formulaires`**, consultez l'article dédié pour plus d'informations.
Voir Formulaires
### Illustrations personnalisées
Il est possible de personnaliser l'affichage de la page d'accueil du portail self-service avec des illustrations. Vous pouvez modifier les illustrations de droite et de gauche.
### Général
* **Titre principal** : Afficher un message personnalisé sur la page d'accueil
* **Barre de recherche** : Active ou non la barre de recherche sous le message d'accueil
* **Catalogue de services** : Active ou désactive le catalogue de services
* **Déplier les catégories dans le catalogue de services** : Déplie les catégories du catalogue de service si celui-ci est activé
* **Ordre de tri par défaut du catalogue de services** : Ordre alphabétique / alphabétique inversé / Populaires
### Traductions
Ces éléments peuvent être traduits dans la langue souhaitée pour s'adapter à la langue sélectionnée par l'utilisateur.
Ces traductions sont disponibles dans **`Configuration`** > **`Générale`** > **`Helpdesk`**
Voir Traductions helpdesk
***
## Utilisateurs
Cet onglet permet d'ajouter un utilisateur à l'entité actuelle et d'attribuer à l'utilisateur un profil, récursif ou non. L'onglet liste également, triés par profil, les utilisateurs de l'entité.
1. Pour ajouter un utilisateur dans l'entité, sélectionnez le profil dans la liste déroulante
2. Sélectionnez l'utilisateur
3. Indiquez la récursivité
4. Cliquez sur **`+ Ajouter`**
***
## Règles
Cet onglet permet de créer des règles.
* **Affectation automatique d'utilisateurs**
* **Affectation d'un élément à une entité**
* **Affectation d'un ticket créé via un récepteur d'e-mails** ; si la règle doit être basée sur des critères, la nouvelle règle doit être ouverte pour définir ces critères. Les règles déjà applicables à l'entité actuelle sont également affichées.
Voir Règles
***
## Documents
L'onglet document vous permet de lier différents types de fichiers à un matériel (PDF, txt, png, etc.). Vous pouvez joindre un document déjà uploadé sur GLPI ou en ajouter un nouveau directement depuis cet onglet.
Voir Documents
***
## Notes
La section Notes vous permet d'ajouter du texte enrichi et de joindre un document.
Voir Notes
***
## Historique
L'onglet *Historique* est utilisé pour afficher toutes les modifications apportées à un élément. Les informations suivantes sur les modifications sont disponibles :
* ID de la modification.
* Date et heure de la modification.
* Utilisateur ayant effectué la modification. Si ce champ n'est pas renseigné, cela signifie que l'action a été effectuée automatiquement (Par exemple : mise à jour automatique de l'inventaire).
* Champ qui a été modifié.
* Description de la modification qui a été effectuée.
La description de la modification représente soit la différence entre l'ancienne et la nouvelle valeur (Par exemple, pour le champ localisation : Changement de Siège à Bureau à distance A), soit l'explication de l'action qui a été réalisée (Par exemple : Désinstallation d'un logiciel : "Gimp 2.0").
{% hint style="info" %}
Pour les listes déroulantes ou les objets ayant une relation parent/enfant, la modification d'un enfant apparaîtra dans l'historique de l'élément parent.
{% endhint %}
***
## Tous
Pour un élément, toutes les informations sont affichées sur une seule page dans l'onglet *Tout*. Cela présente tous les onglets du formulaire d'un objet en une seule vue, les uns en dessous des autres.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://help.glpi-project.org/glpi-12/fr/administration/entities.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
