Le connecteur GLPI permet de synchroniser de façon bidirectionnelle les tickets entre ISI-APP (module Isi-Ticket) et une instance GLPI (par exemple MY WIDIP). Un ticket créé dans ISI-APP est répliqué dans GLPI, et inversement, avec ses commentaires, sa solution et ses pièces jointes. Les statuts, priorités et catégories sont traduits dans les deux sens via des tables de correspondance configurées par le client.
Le connecteur s'inscrit dans le Store de connecteurs ISI-APP, au même titre que le connecteur OCS Inventory.
Le connecteur GLPI apparaît dans le Store d'ISI-APP (/admin/store/connecteurs). L'admin local du tenant l'installe pour son entité, ce qui crée une StoreInstance rattachée. Une fois installé :
/glpi) listant l'instance.Si aucune instance n'est encore créée, la page /glpi affiche un état vide invitant à passer par le Store.
L'onglet « Synchro GLPI » de la sidebar et l'ensemble des pages /glpi/* sont réservés aux administrateurs locaux du tenant (profils 100/110/150 ou membres Isi-DSI, via isAdminLocalUser()). Un utilisateur standard ne voit pas l'entrée de menu et se voit refuser l'accès (HTTP 403) s'il tente d'ouvrir une URL GLPI directement. Cette page étant purement technique (paramétrage de synchronisation), elle n'a pas vocation à être exposée aux utilisateurs finaux.
La gestion se répartit sur deux écrans :
/store/instances/{id}/mapping) : 2 onglets — Paramétrage et Correspondances ;/glpi/{id}) : 3 onglets — Synchronisation, Santé et IDs liés.Configuration technique de la connexion à GLPI :
| Champ | Description |
|---|---|
| URL API GLPI | URL complète de l'API REST (ex : https://glpi.client.fr/apirest.php). Doit être en HTTPS. |
| App Token | Jeton applicatif fourni par GLPI. Stocké chiffré, jamais affiché en clair. |
| User Token | Jeton utilisateur fourni par GLPI. Idem. |
| Fréquence de synchro | Manuelle, 5 / 10 / 20 / 60 minutes |
| Mode utilisateur | Anonyme, Par email, Reprise manuelle (voir ci-dessous) |
| Envoi des mails | ISI-APP ou GLPI — qui envoie les notifications pour éviter les doublons |
| Sujets à envoyer vers GLPI | Périmètre de la synchronisation ISI-APP → GLPI. Vide = tous les sujets |
| Clôturer dans GLPI les tickets sortis du périmètre | Voir Périmètre des sujets. Désactivé par défaut |
| IP autorisée | Optionnel, restreint l'accès API à une IP donnée |
Un bouton "Tester la connexion" valide les paramètres en direct sans sauvegarder.
Trois tables de mapping à renseigner par le client :
itilcategories_id), avec son type (Incident ou Demande). Une catégorie peut être marquée "par défaut" pour servir de filet en cas de catégorie non mappée.Les listes GLPI sont chargées à la volée via l'API au moment où l'utilisateur ouvre l'onglet.
/glpi/{id})/glpi/{id})Indicateurs de bon fonctionnement de l'instance (connexion, dernières synchronisations, anomalies récentes).
/glpi/{id})Tableau lecture seule listant toutes les correspondances d'identifiants (objets ISI-APP ↔ objets GLPI). Utile pour le support et le débogage. Filtrable par type d'objet — la liste des types proposés reflète ceux réellement présents pour l'instance (tickets, entités, utilisateurs, commentaires, tâches, solutions, demandeurs, documents et images, dans les deux sens). Exportable en CSV.
Le connecteur récupère les tickets GLPI modifiés depuis la dernière synchro. Pour chacun :
Les actions suivantes, réalisées dans GLPI, sont répercutées dans ISI-APP :
| Action dans GLPI | Effet dans ISI-APP |
|---|---|
| Changement de statut, titre, description, priorité, catégorie, entité | Ticket mis à jour |
| Ajout d'un suivi | Nouveau commentaire dans le fil du ticket |
| Ajout, modification ou suppression d'une tâche | La tâche est créée, mise à jour ou retirée du ticket ISI-APP (voir Tâches) |
| Correction du texte d'un suivi | Le commentaire correspondant est mis à jour |
| Suppression d'un suivi | Le commentaire est retiré du fil du ticket |
| Ajout d'une solution | Commentaire « [Solution] » et passage du ticket en résolu/clos selon le statut |
| Clôture du ticket | Ticket clôturé, avec réponse de clôture reprise de la solution GLPI. Si le statut est passé à « Clos » sans solution, la réponse porte une mention datée (« Ticket clôturé depuis GLPI le … sans solution renseignée »), pour qu'un ticket clos ne reste jamais sans réponse. Le type de résolution est positionné sur « Résolu » s'il n'a pas déjà été choisi — il est obligatoire lors d'une clôture faite dans ISI-APP. Une réponse déjà saisie dans ISI-APP n'est jamais remplacée |
| Mise à la corbeille | Ticket archivé |
| Sortie de corbeille | Ticket de nouveau visible — uniquement si c'est la synchronisation qui l'avait archivé. Un ticket archivé par un technicien dans ISI-APP reste archivé : le connecteur ne défait pas une décision humaine |
| Changement de technicien assigné | Technicien affecté mis à jour |
| Ajout ou retrait d'un demandeur | Le demandeur est rattaché au ticket ISI-APP, ou son rattachement retiré |
Un commentaire rédigé dans ISI-APP puis transmis à GLPI n'est jamais réécrit ni retiré par ces mécanismes : il reste tel quel dans son fil d'origine.
Aucune de ces actions n'est répercutée sur un ticket sorti du périmètre des sujets (cf. Périmètre des sujets) : il n'est plus piloté par GLPI.
Non synchronisé : les observateurs d'un ticket. L'option « Synchroniser les observateurs » du paramétrage est présente mais reste sans effet à ce jour.
Le connecteur récupère les tickets ISI-APP modifiés depuis la dernière synchro. Pour chacun :
[GLPI#1234] pour permettre au support de retrouver facilement le ticket dans les deux outils.Le demandeur d'un ticket ISI-APP est transmis à GLPI. Trois cas, dans cet ordre :
Un ticket mis à la corbeille dans ISI-APP n'est plus poussé vers GLPI (il pouvait s'y recréer entièrement). La suppression n'est en revanche pas propagée à GLPI : le ticket y reste ouvert.
Un ticket ISI-APP peut aussi porter un demandeur saisi à la main, sans compte ni adresse (un nom et éventuellement un téléphone, quand la demande est enregistrée pour un tiers). GLPI n'a alors nulle part où le ranger : son identité est consignée une seule fois en commentaire du ticket GLPI (« Demandeur Isi-APP : Jean Dupont — 06 12 34 56 78 »), pour que l'information ne se perde pas.
GLPI ne notifie le demandeur que si le paramètre « Envoi des mails » lui en donne la charge, afin de ne pas doubler les notifications d'ISI-APP.
Plusieurs demandeurs peuvent être rattachés à un même ticket : ils sont tous transmis, GLPI sachant lui aussi en porter plusieurs. Un demandeur ajouté à la main dans GLPI, qu'ISI-APP ne connaît pas, est conservé : la synchronisation ne retire que les demandeurs qu'elle a elle-même déclarés — et elle le fait quand leur adresse change (l'ancienne ne reste pas à côté de la nouvelle) ou quand le rattachement est supprimé dans ISI-APP.
Enfin, un demandeur qu'ISI-APP a exclu de ses notifications ne sera pas notifié par GLPI non plus.
Dans l'autre sens, tous les demandeurs d'un ticket GLPI sont rattachés au ticket ISI-APP, y compris ceux sans compte (tickets créés par le collecteur de mails, par exemple), rapprochés par leur adresse. Auparavant, seul le premier demandeur arrivait — et un ticket GLPI ouvert avec deux demandeurs n'en montrait qu'un dans ISI-APP, définitivement. Un demandeur retiré dans GLPI voit son rattachement ISI-APP disparaître ; un demandeur rattaché depuis ISI-APP, lui, reste intact.
L'affectation circule dans les deux sens :
GLPI → ISI-APP : le technicien assigné dans GLPI devient le technicien affecté du ticket ISI-APP (rapprochement par email, au sein de votre organisation). GLPI acceptant plusieurs techniciens sur un ticket alors qu'ISI-APP n'en gère qu'un, c'est le premier assigné correspondant à un compte ISI-APP qui est retenu — et non le premier de la liste GLPI, qui peut être un compte technique sans adresse email. À défaut de correspondance, le ticket revient au technicien ISI-APP par défaut s'il est renseigné.
ISI-APP → GLPI : le technicien affecté dans ISI-APP est posé comme assigné du ticket GLPI, et les éventuels autres assignés sont retirés — ISI-APP n'en désignant qu'un. Le rapprochement se fait là aussi par email, dans cet ordre :
Si le ticket n'a aucun technicien affecté dans ISI-APP, la synchronisation ne retire pas l'assigné éventuellement présent dans GLPI : l'absence d'affectation ne se distingue pas d'une désaffectation volontaire, et un retrait automatique effacerait le travail fait côté GLPI.
GLPI distingue deux statuts de fin, Résolu (une solution est proposée) puis Clos. ISI-APP n'a pas d'état intermédiaire : la résolution y qualifie une clôture. Le mapping des statuts laisse donc le choix, pour le statut GLPI « Résolu » :
| Correspondance choisie | Effet sur le ticket ISI-APP |
|---|---|
| Résolu sans clôture | Le ticket est marqué résolu sans être clôturé : son statut ISI-APP n'est pas modifié, la réponse est reprise de la solution GLPI, et le résolveur est renseigné. Comme pour une résolution saisie dans ISI-APP, la clôture automatique intervient 3 jours plus tard ; le gestionnaire peut clôturer avant, et un passage de GLPI en « Clos » clôture immédiatement. Si le ticket est réouvert entre-temps (des deux côtés), la clôture automatique est abandonnée : elle ne vient pas refermer un ticket reparti en traitement |
| Clôturé immédiatement | Le ticket est clôturé sur-le-champ, avec sa réponse et son type de résolution |
| Affecté / Ouvert | La résolution GLPI n'est pas reflétée ; la solution reste visible en commentaire |
Un ancien choix « Résolu ET clôturé » subsiste dans la liste pour les instances qui l'ont déjà enregistré : il clôture immédiatement, exactement comme « Clôturé ». Il est signalé comme tel dans l'écran ; il n'y a rien à changer si votre paramétrage l'utilise et que la clôture immédiate vous convient.
Un ticket « résolu non clôturé » est renvoyé vers GLPI comme Résolu, pas comme Clos : les deux outils restent alignés sans que l'un reclôture ce que l'autre a seulement résolu.
Le champ "Mode utilisateur" contrôle comment ISI-APP traite les utilisateurs côté GLPI :
| Mode | Comportement |
|---|---|
| Anonyme | Aucun compte GLPI n'est créé. Si le technicien affecté dans ISI-APP n'a pas de compte GLPI portant la même adresse email, l'affectation ne peut pas être transmise et la synchronisation le signale dans ses logs |
| Par email | Recherche du compte GLPI par email et le crée s'il est absent, au moment où un utilisateur ISI-APP doit réellement être référencé dans GLPI (et non en déversant tout l'annuaire) |
| Reprise manuelle | Utilise uniquement les correspondances déjà saisies, ne crée jamais de compte |
Le mode Par email crée de véritables comptes dans le GLPI du client (login = partie gauche de l'adresse, nom et prénom repris d'ISI-APP, compte actif). C'est la contrepartie d'une affectation qui « passe » toujours : à choisir en connaissance de cause, notamment si les comptes GLPI sont soumis à licence ou provisionnés depuis un annuaire.
Dans le sens GLPI → ISI-APP, les utilisateurs GLPI (demandeur, technicien affecté, auteur d'un suivi, auteur de la solution) sont rapprochés des comptes ISI-APP par email, au sein de votre organisation uniquement.
Un email présent dans GLPI mais rattaché à un compte d'une autre organisation n'est jamais utilisé : c'est fréquent, par exemple pour les techniciens de l'éditeur présents dans votre GLPI. Le ticket est alors affecté au technicien par défaut de l'instance (s'il est renseigné, et lui aussi doit appartenir à votre organisation) ou laissé non affecté, plutôt que d'attribuer le ticket à une personne extérieure.
Conséquence pratique : pour qu'un technicien GLPI soit reconnu, son email doit correspondre à un compte ISI-APP de votre organisation.
Le paramétrage permet de restreindre la synchronisation ISI-APP → GLPI à certains sujets de ticket (champ « Sujets à envoyer vers GLPI » ; laissé vide, tous les sujets partent). Un ticket dont le sujet n'est pas dans cette liste n'est jamais poussé vers GLPI.
Requalifier un ticket (changer son sujet) est une action courante : une demande arrivée en « Connexions Internet — Wi-Fi » se révèle être un achat de matériel, et passe en « Achats », sujet hors périmètre. Deux comportements en découlent :
Une fois soldé, le ticket est détaché de la synchronisation : les actions faites côté GLPI ne redescendent plus dans ISI-APP — en particulier, la clôture qui vient d'être posée dans GLPI ne clôture pas le ticket ISI-APP, qui poursuit sa vie sous son nouveau sujet. Le lien entre les deux tickets n'est pas détruit pour autant : si le sujet revient dans le périmètre, la synchronisation reprend au cycle suivant et rouvre le ticket GLPI selon l'état ISI-APP.
L'option est désactivée par défaut, y compris sur les instances existantes : l'activer clôture, au cycle suivant, tous les tickets déjà sortis du périmètre. C'est en général l'effet recherché, mais il vaut mieux le déclencher en connaissance de cause. Une solution GLPI déjà enregistrée n'est jamais remplacée par le motif de sortie de périmètre, sauf si elle a été refusée (une réouverture vaut refus dans GLPI) — le ticket se fermerait sinon sur une réponse invalidée.
Les tâches d'un ticket circulent dans les deux sens : une tâche créée dans GLPI apparaît sur le ticket ISI-APP, une tâche créée dans ISI-APP apparaît sur le ticket GLPI. Les modifications suivent, et une tâche supprimée d'un côté disparaît de l'autre.
Les deux outils ne décrivent pas une tâche de la même façon ; voici ce que devient chaque information :
| Information | GLPI | ISI-APP |
|---|---|---|
| Intitulé | GLPI n'a pas de titre : sa tâche est un simple texte | Le titre ISI-APP ouvre le texte GLPI ; à l'inverse, la première ligne du texte GLPI devient le titre ISI-APP et la suite la description |
| Avancement | « À faire » / « Terminée » | « Terminée » ↔ 100 % avec sa date de réalisation. Les valeurs intermédiaires (10 %, 50 %…) n'ont pas d'équivalent GLPI : elles sont conservées telles quelles tant que GLPI ne dit pas « terminée » |
| Dates | Début et fin planifiés | Début ↔ début, fin planifiée ↔ échéance. La fenêtre n'est transmise à GLPI que si le début et l'échéance sont renseignés, GLPI refusant une fin antérieure au début |
| Intervenant | Technicien de la tâche | Rapproché par email au sein de votre organisation, comme pour l'affectation d'un ticket. Sans correspondance, le technicien ISI-APP par défaut prend le relais ; côté GLPI, la tâche part sans technicien plutôt que de ne pas partir |
| Visibilité | Tâche privée | Visibilité « Privée » |
| Priorité | absente des tâches GLPI | « Normale » à l'import, jamais réécrite ensuite |
| Durée | Temps passé (heures) | Jours estimés. Les deux ne mesurent pas la même chose : ce champ n'est pas synchronisé |
Deux comportements à connaître :
Documents et images circulent dans les deux sens, en même temps que le ticket qui les porte. Un fichier n'est transmis qu'une fois : il ne revient jamais en second exemplaire du côté d'où il part.
Deux limites propres à GLPI méritent d'être connues :
Dans l'autre sens, la taille d'une pièce jointe importée de GLPI est mesurée sur le fichier reçu. Les pièces jointes importées avant cette correction, affichées « 0 Ko », voient leur taille rétablie automatiquement au passage suivant de la synchronisation — le fichier lui-même, lui, avait toujours été correctement téléchargé.
Enfin, un document présent dans GLPI sans fichier associé (résidu des envois défectueux décrits ci-dessus) est signalé dans le journal et non importé : il n'y a rien à récupérer. Ces documents vides peuvent être supprimés dans GLPI.
Pour éviter qu'un même événement génère deux notifications (une par ISI, une par GLPI), le client choisit qui envoie : ISI ou GLPI. La partie qui n'envoie pas doit avoir ses notifications désactivées pour les tickets synchronisés. À documenter dans le guide utilisateur du client.
Pour limiter la complexité, ne sont pas synchronisés :
ITILValidation)Toute extension du périmètre doit faire l'objet d'une nouvelle évolution.
Chaque ticket est traité indépendamment : une erreur sur un ticket est journalisée dans les logs et n'arrête pas la synchronisation des autres. La synchronisation est toujours asynchrone — il n'y a pas de mode "temps réel" qui répliquerait instantanément chaque action.
Selon la fréquence choisie dans le paramétrage, une commande Artisan (glpi:sync) tourne toutes les 5, 10, 20 ou 60 minutes via le scheduler. Elle parcourt toutes les instances GLPI actives et synchronise chacune indépendamment. La dernière date de synchro est mise à jour à la fois sur la StoreInstance (visible dans la card de l'index) et dans le paramétrage.
Si la fréquence est sur Manuel (0), seule l'action via le bouton "Synchroniser maintenant" déclenche une sync.
La synchronisation ne modifie jamais la date de dernière modification du ticket (colonne « Dernière modif. » des listes) : celle-ci ne bouge que sur une action faite dans ISI-APP — commentaire, affectation, changement de sujet, clôture… Les changements importés de GLPI sont bien appliqués au ticket, mais sans repousser cette date, qui reste ainsi un indicateur d'activité humaine exploitable pour le tri et le suivi.
La date de prise en charge suit la même logique : elle est posée à la première affectation, ou lors d'un changement de technicien, et n'est plus réécrite par les cycles suivants. C'est cette date qui sert au calcul du temps de prise en charge et du temps de résolution — les cycles de synchronisation ne faussent donc plus ces indicateurs.
Les journaux affichés dans l'onglet dédié sont conservés 30 jours, puis supprimés automatiquement chaque nuit. Chaque cycle écrivant une ligne par objet traité, sans cette purge la table grossit indéfiniment (elle avait atteint plus de 250 000 lignes) et ralentit l'affichage de la page du connecteur. Les journaux servent au diagnostic à chaud ; pour conserver la trace d'un incident plus ancien, il faut l'exporter ou le recopier avant expiration.
encrypt() Laravel — jamais stockés en clair, jamais retournés dans les vues, jamais loggés.session('user.info._id')).docs/store/store-connectors-spec.mddocs/store/store-connectors-spec.mdDoc technique : .claude/technical-docs/store/connecteur_glpi.md