Plugin GLPI NinjaOne Connector

Je vous présente un petit morceau de lab qui me fait particulièrement plaisir : GLPI NinjaOne Connector, mon premier plugin GLPI, avec l’aide de Codex. Je ne m’en cache pas 😉

Alors oui, premier plugin, donc forcément il y a ce mélange assez sympathique entre “ça fonctionne” et “j’ai encore mille idées”.

Le besoin, lui, était très simple.

Je me considère comme un Aficionado de GLPI. C’est un outil que je connais, que j’aime bien, et qui garde une vraie logique ITSM : parc, tickets, entités, lieux, règles d’import, suivi dans le temps.

De l’autre côté, je découvre et utilise maintenant NinjaOne, qui est dans une logique très différente : RMM, supervision, orchestration endpoint, actions à distance, automatisation.

Et justement, c’est là que ça devient intéressant : ce sont deux produits bien distincts. Le but n’est pas de transformer GLPI en NinjaOne, ni NinjaOne en GLPI.

Le but, c’est de les faire se parler proprement.

Pourquoi ce plugin

J’ai toujours voulu faire des plugins pour GLPI en fonction de mes besoins. Même si j’ai quelques connaissances, je ne suis pas développeur à la base, et il faut admettre que Codex et Claude nous ouvrent de sacrées portes.

Donc je voulais pouvoir coupler GLPI et NinjaOne au mieux pour bénéficier des deux mondes :

• 🗂️ GLPI pour l’ITSM, les assets, les entités, les lieux, les règles et la vie du parc
• 🛠️ NinjaOne pour le RMM, la remontée terrain, le contact endpoint et l’orchestratio
• 🔗 un lien durable entre un device NinjaOne et un ordinateur GLPI
• 🧭 une synchronisation contrôlée, sans importer tout ce qui bouge
• ⏱️ moins de doublons, moins de clics, moins de temps perdu à maintenir deux référentiels à la main.

Dans les environnements réels, le piège arrive vite : on a des machines dans GLPI, des devices dans NinjaOne, parfois les mêmes noms, parfois des doublons, parfois des entités ou des lieux qui ne collent pas exactement.

Et au bout d’un moment, si tout doit être corrigé à la main, ça devient vite chronophage.

La logique retenue

Le plugin ne part pas du principe que NinjaOne doit tout envoyer dans GLPI automatiquement.

Au contraire, j’ai voulu une approche volontairement explicite :

Connexion à NinjaOne

Le plugin utilise une application API NinjaOne de type Services API avec Client Credentials.

Pour cette première version, le scope utilisé reste volontairement limité à Monitoring. Les scopes Management et Control apparaissent comme pistes futures, mais ils ne sont pas activables dans l’interface pour le moment.

Une fois la connexion enregistrée dans GLPI, on peut tester l’API, lancer une synchronisation manuelle, choisir le mode d’organisation, définir la source d’inventaire et consulter les logs.

Organisations et emplacements

Un point important : le plugin ne synchronise pas toutes les organisations NinjaOne les yeux fermés. On peut vouloir l’utiliser comme un MSP ou comme un client final, donc il faut pouvoir choisir.

La séquence est plutôt :

1. 1️⃣ Créer la connexion NinjaOne ;
2. 2️⃣ Lancer une première synchronisation pour découvrir les organisations et les emplacements ;
3. 3️⃣ Choisir le mode single-organization ou multi-organization ;
4. 4️⃣ Mapper les organisations NinjaOne vers les entités GLPI ;
5. 5️⃣ Activer uniquement ce qui doit être synchronisé.

Les nouvelles organisations découvertes restent désactivées par défaut. C’est un petit garde-fou, mais il évite les mauvaises surprises.

Mode organisation unique

Dans le mode simple, une organisation NinjaOne est associée directement à une entité GLPI.

Mode multi-organisations

Dans le mode multi-organisations, chaque organisation NinjaOne peut être mappée séparément, activée ou désactivée, puis reliée à la bonne entité GLPI.

Mapping des lieux

Même logique pour les lieux : une localisation NinjaOne peut être associée à un lieu GLPI existant, ou aider à créer une nouvelle localisation côté GLPI.

Deux modes d’inventaire

Le plugin propose deux approches.

La première, c’est la synchronisation minimale. Elle permet de créer ou mettre à jour des ordinateurs GLPI avec les informations disponibles via NinjaOne : nom, numéro de série, identifiants d’asset, dernier contact, dates d’inventaire, fabricant, modèle, quelques informations matérielles selon ce que le tenant expose.

La seconde, c’est le mode avancé avec GLPI Agent portable.

Dans cette logique :

• NinjaOne identifie et orchestre l’endpoint ;
• le plugin maintient le lien NinjaOne ↔ GLPI ;
• GLPI Agent portable réalise l’inventaire complet ;
• l’inventaire est injecté dans GLPI avec la qualité attendue côté GLPI.

Ce que le plugin ajoute dans GLPI

Quand un ordinateur GLPI est lié à un device NinjaOne, le plugin ajoute un onglet et un résumé avec les informations utiles :

• ➡️ ID du device NinjaOne ;
• ➡️ statut technique de synchronisation ;
• ➡️ source d’inventaire ;
• ➡️ première synchronisation ;
• ➡️ dernière synchronisation ;
• ➡️ dernier contact NinjaOne ;
• ➡️ configuration utilisée pour le lien ;
• ➡️ bouton direct pour ouvrir le device dans NinjaOne.

Le plugin enregistre aussi deux actions automatiques GLPI :

• NinjaoneSync, pour synchroniser les configurations actives ;
• NinjaoneLogPurge, pour purger les anciens logs de synchronisation.

Et comme toujours avec GLPI, le cron système doit être configuré proprement.

Limites actuelles

Je préfère être clair : c’est un premier plugin, et il y a encore des sujets à durcir.

• les suppressions côté NinjaOne ne suppriment pas automatiquement les assets GLPI ;
• les alertes NinjaOne ne créent pas encore de tickets GLPI ;
• les scopes Management et Control sont réservés pour plus tard ;
• une vraie validation sur tenant réel reste recommandée avant production.

Pour finir

Je suis plutôt content de ce premier pas.

Il reste des choses à améliorer, forcément. Mais la base est là : une connexion NinjaOne, un mapping propre vers GLPI, une synchronisation explicite, et une approche qui respecte les deux produits.

Si vous êtes dans le même cas, avec un GLPI déjà bien en place et une adoption progressive de NinjaOne, ce plugin peut servir de point de départ.

Et puis bon, premier plugin GLPI : il fallait bien lui faire un petit article.

Sources

• GitHub - DooSys/glpi-ninjaone-connector
• README du plugin GLPI NinjaOne Connector