GLPI NinjaOne Connector

Le problème traité

Les équipes qui utilisent à la fois GLPI et NinjaOne doivent souvent choisir entre deux mauvaises options : maintenir deux inventaires indépendants, ou considérer le RMM comme une nouvelle source de vérité et perdre une partie de la logique ITSM déjà construite dans GLPI.

GLPI NinjaOne Connector adopte une séparation plus nette :

• GLPI conserve les assets natifs, les entités, les lieux et les workflows ITSM ;
• NinjaOne reste la plateforme RMM et la source d’orchestration des endpoints ;
• le plugin maintient la relation durable entre l’identifiant NinjaOne et l’ordinateur GLPI ;
• aucun périmètre client n’est importé tant qu’un administrateur ne l’a pas explicitement validé.

Ce que le plugin couvre

Le tableau de bord affiche les connexions déclarées et actives, les organisations autorisées, les mappings de lieux, les ordinateurs liés et les associations encore en attente.

Le parcours d’administration comprend :

1. la création d’une application NinjaOne Services API utilisant Client Credentials ;
2. le test de la connexion depuis GLPI ;
3. la découverte des organisations et locations ;
4. le choix entre mode mono-organisation et multi-organisations ;
5. le mapping vers les entités et lieux GLPI ;
6. l’activation explicite des périmètres à synchroniser.

Les nouvelles organisations découvertes restent désactivées par défaut. Ce garde-fou évite qu’un nouveau tenant ou un nouveau client soit importé automatiquement dans la mauvaise entité.

Deux stratégies d’inventaire

Le second mode évite l’installation permanente d’un agent supplémentaire tout en conservant la qualité d’inventaire de GLPI Agent.

Architecture

Le plugin ne modifie pas le schéma du cœur de GLPI. Ses tables propres stockent uniquement :

• les configurations de connexion ;
• les mappings organisations → entités ;
• les mappings locations → lieux ;
• les relations devices NinjaOne → ordinateurs GLPI ;
• les journaux de synchronisation.

Les objets métiers restent des ordinateurs GLPI natifs. Cette décision facilite les recherches, règles d’import, tickets, workflows et futures migrations.

Automatisation et exploitation

Deux actions automatiques sont enregistrées :

• NinjaoneSync, prévue toutes les douze heures pour les connexions actives arrivées à échéance ;
• NinjaoneLogPurge, prévue tous les trois jours avec une rétention des logs de trente jours.

Une vue NinjaOne est ajoutée aux ordinateurs liés avec l’état du mapping, la source d’inventaire, les dates de première et dernière synchronisation, le dernier contact et un accès direct à l’appareil dans NinjaOne.

Sécurité et limites actuelles

• Le scope NinjaOne actif est limité à Monitoring. Management et Control restent réservés à des évolutions futures.
• La suppression d’un appareil NinjaOne ne supprime jamais automatiquement l’asset GLPI.
• Les alertes NinjaOne ne créent pas encore de tickets GLPI.
• Les données CPU, mémoire et disques nécessitent encore une validation complète des mappings natifs GLPI 11 selon les environnements.
• Antivirus, sauvegardes, conformité des correctifs et champs personnalisés figurent dans la roadmap consultative.

Pourquoi ce projet mérite une fiche dédiée

Ce connecteur illustre bien le type de projet que cette nouvelle section doit mettre en valeur : un besoin terrain précis, des choix d’architecture explicables, une interface visible, de vraies contraintes de sécurité et une roadmap assumée.

Le dépôt contient le code, la documentation technique et les notes d’installation. La fiche UOpsLab apporte une lecture plus rapide du problème, des décisions et de l’état réel du projet.