Deux GLPI, un seul ticket. Lorsque siège et filiale, prestataire et client, ou production et recette exploitent des instances séparées, la même demande finit par exister deux fois — et quelqu'un paie le prix de les maintenir identiques.
Le problème
GLPI ne communique pas avec un autre GLPI. Chaque instance est un monde fermé, et leur intégration se réduit souvent à trois mauvaises options : copier-coller manuellement, écrire un script maison que plus personne ne comprend quelques mois plus tard, ou accepter que les deux bases divergent.
Le coût n'apparaît pas tout de suite. Il se manifeste quand le client demande pourquoi son ticket est "en cours" dans un système et "clos" dans l'autre, ou quand la solution saisie chez le partenaire n'est jamais remontée au siège.
Comment fonctionne GLPI Sync
Le module réplique les tickets d'une instance vers une autre en s'appuyant sur l'API REST native de GLPI — sans middleware, sans base partagée et sans intégration tierce.
- Trois directions par instance — envoi (le ticket ouvert ici est créé sur l'instance distante, en arrière-plan), import (chaque minute, le module récupère les nouveaux tickets distants et crée ici le ticket miroir) ou bidirectionnel.
- Suivis, tâches, solutions et statut — chaque type dispose de son propre interrupteur : vous ne synchronisez que l'essentiel.
- Plusieurs instances distantes — une source peut alimenter plusieurs destinations simultanément.
- Filtres d'envoi et d'import — à l'envoi, par catégorie, entité, demandeur et groupe ; à l'import, par catégorie, entité et groupe attribué du ticket distant, avec une date de coupure facultative.
- Correspondance des champs — entité, catégorie et autres données de la source sont converties vers les identifiants correspondants de la destination, qui coïncident rarement.
- File d'attente avec relance — si l'instance distante est indisponible, la synchronisation est retraitée plus tard au lieu d'être perdue. Les onglets Corrélations et Journaux montrent chaque ticket lié et chaque exécution et, avec le module Smart Notify, la cloche vous avertit quand un GLPI distant tombe.
Comment l'activer
- Installez NexTool sur votre GLPI 11, avec les actions automatiques de GLPI exécutées par le cron en ligne de commande.
- Rendez-vous dans NexTool > Modules et activez GLPI Sync.
- Déclarez l'instance distante avec son URL et le User-Token de l'API REST (ou identifiant et mot de passe) et, si le GLPI distant l'exige, l'App-Token ; choisissez la direction et utilisez Tester la connexion et les permissions.
- Définissez les filtres d'envoi et d'import, les valeurs par défaut de chaque côté et la correspondance des champs entre les instances.
- Choisissez ce qu'il faut synchroniser : suivis, tâches, solutions et statut.
À qui cela s'adresse
Aux prestataires qui exploitent à la fois le GLPI du client et le leur ; aux organisations dont le siège et les filiales sont sur des instances distinctes pour des raisons de conformité ou d'infrastructure ; et aux équipes qui maintiennent un GLPI de recette ayant besoin de cas réels.
Une précision d'architecture : chaque instance peut fonctionner en mode Outbound (local → distant), Inbound (distant → local) ou Bidirectionnel (dans les deux sens). Le sens est défini pour chaque intégration, et le module utilise des corrélations et des contrôles de direction pour éviter les doublons et les écritures dans un sens non autorisé. Dans un scénario bidirectionnel, il reste important de définir les champs et les équipes responsables de chaque côté.
Compatibilité
- GLPI : 11.0+
- Offre : Sous licence
- Plugin : NexTool 6.16.0 ou supérieur
Prochaine étape
GLPI Sync fait partie de NexTool, un écosystème de modules qui étend GLPI sans personnalisation de code. Découvrez la page du module ou réservez un échange pour le voir fonctionner dans votre environnement.
Relu par l'équipe NexTool Solutions.
