NexTool Solutions

Intégration bidirectionnelle entre systèmes, sans script sur mesure ni middleware externe. Le module Automatisations de NexTool transforme GLPI en un hub capable de recevoir des événements de n'importe quel système et d'y réagir de façon autonome - le webhook arrive, les données sont mappées et une action se déclenche, le tout dans votre propre environnement.

Le problème

Les équipes qui exploitent plusieurs outils - supervision, ITSM, e-commerce, ERP, plateformes d'observabilité - vivent avec l'écart entre les systèmes. Quand une alerte se déclenche dans Zabbix ou qu'une commande arrive dans l'e-commerce, quelqu'un doit ouvrir le ticket dans GLPI, remplir les champs et affecter un responsable. Chaque étape manuelle est un point de défaillance et une source de retard.

Les solutions génériques comme Zapier ou Make traitent les cas simples, mais elles exigent un compte externe, facturent à l'opération et vivent hors du contrôle de l'équipe. Pour les opérations qui exigent traçabilité, sécurité et intégration profonde avec GLPI, la réponse doit vivre dans l'environnement lui-même - et c'est ce que fournit le module Automatisations.

Comment fonctionne Automatisations

Le module fonctionne en trois piliers enchaînés :

• Entrée (Trigger) - un endpoint webhook stateless reçoit des requêtes POST de n'importe quel système. Chaque flux a un token unique et une authentification HMAC SHA-256, pour que seules les sources autorisées déclenchent des actions.
• Traitement (PayloadMapper) - le payload JSON reçu est mappé avec JSONPath. Des transformations comme map_priority, resolve_user_by_email et resolve_category_by_name convertissent les données externes en champs natifs GLPI sans code.
• Sortie (ActionRunner) - deux types d'action : créer un ticket GLPI (avec session impersonation pour affecter le bon demandeur) ou déclencher une requête HTTP vers un système externe via un connecteur enregistré.

Un Visual Flow Wizard permet de construire et d'éditer des flux dans une interface à trois cartes reliées : Trigger, Mappage et Action. Pas besoin d'éditer du JSON à la main. Les flux s'activent, se désactivent et se surveillent dans le panneau. Le module gère aussi des Connecteurs - des dizaines de fournisseurs classés par catégorie, avec plusieurs types d'authentification (API Key, Bearer, Basic, OAuth2, HMAC) et des identifiants stockés avec chiffrement AES-256-GCM. Ainsi, une action de flux fait des appels authentifiés vers des API externes comme Microsoft 365, Jira, Slack ou tout service avec une API REST.

Un flux réel, du payload à l'action

Le flux le plus courant que nous montons transforme une alerte de supervision en ticket. Le système externe fait un POST signé sur l'endpoint du flux :

# Zabbix (ou tout systeme) declenche un POST signe sur l'endpoint du flux
curl -X POST 'https://glpi.votreentreprise.com/plugins/nextool/automations/webhook/...token...' \
  -H 'Content-Type: application/json' \
  -H 'X-Signature: sha256=...signature-hmac...' \
  -d '{
    "event": {
      "host": "srv-db-01",
      "severity": "High",
      "trigger": "Espace disque < 10%",
      "requester": "supervision@votreentreprise.com"
    }
  }'

Dans la carte de mappage, chaque JSONPath devient un champ natif du ticket. Les transformations traduisent les valeurs - "High" devient l'urgence 4, l'e-mail devient l'utilisateur demandeur :

$.event.trigger    -> name                    (titre du ticket)
$.event.host       -> content                 (description)
$.event.severity   -> urgency  (map_priority: High=4, Disaster=5)
$.event.requester  -> _users_id_requester (resolve_user_by_email)

Le détail que seuls les intégrateurs connaissent

En maintenance, l'erreur classique est que le système externe envoie l'e-mail du demandeur alors que cet e-mail n'existe pas comme utilisateur GLPI. Sans un resolve_user_by_email avec un plan B, le ticket naît orphelin ou l'action échoue en silence - et personne ne s'en aperçoit avant qu'il ne manque l'historique. Nous standardisons un demandeur technique de secours (quelque chose comme "integration-automatique") pour ne jamais perdre l'événement, en laissant l'e-mail d'origine dans le corps du ticket pour le suivi. Le deuxième détail est la signature HMAC : les deux côtés doivent calculer le hash sur exactement le même corps brut (raw body). Un proxy qui resérialise le JSON en route change un espace, casse la signature et le webhook est rejeté avec un 401 - c'est pourquoi la validation se fait sur le raw body, pas sur le JSON re-parsé. Qui l'ignore perd des heures à croire que la clé est mauvaise.

Entrée native vs. ce que le module ajoute

Comment l'activer

1. Installez le plugin NexTool sur GLPI.
2. Allez dans Configuration > NexTool > Modules.
3. Repérez la carte Automatisations et cliquez sur Installer puis Activer.
4. Créez un flux avec le Visual Flow Wizard et copiez l'URL du webhook générée.
5. Configurez le système externe pour envoyer les événements vers cette URL, avec le token et la signature HMAC.

Pour qui (et quand non)

Pour ceux qui exploitent des environnements avec plusieurs outils intégrés : supervision (Zabbix, Grafana, Nagios), e-commerce, ERP, RH ou tout service capable de déclencher des webhooks. C'est particulièrement précieux quand l'opération exige traçabilité et audit - chaque exécution est journalisée avec input, output, durée et statut. Ce n'est pas fait pour automatiser ce qui n'est pas conçu : si votre processus d'ouverture de ticket n'a pas encore de catégorie, d'urgence et de responsable définis, l'automatisation ne fera qu'accélérer le désordre. Définissez d'abord le flux manuel, puis automatisez.

Compatibilité

• GLPI : 10.0+ et 11.0+
• Plan : Enterprise
• Plugin : NexTool 3.x ou supérieur

Étape suivante

Le module Automatisations fait partie de NexTool. Prêt à supprimer les étapes manuelles entre vos systèmes ? Parlez à l'équipe et nous concevons le premier flux avec vous.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et révisé par l'équipe NexTool Solutions.