Installer un plugin pour chaque besoin semble le réflexe évident dans GLPI - jusqu'au jour de la mise à niveau, quand la moitié ne redémarre pas. Après des années à maintenir des parcs GLPI de clients, nous avons appris que le goulot d'étranglement est rarement un mauvais plugin : c'est la somme d'une douzaine de plugins isolés, chacun avec son cycle de version, sa dépendance et son mainteneur. Ce guide montre comment choisir et combiner des extensions sans tomber dans le "plugin sprawl", où l'approche modulaire de NexTool s'insère - et, en toute honnêteté, où elle n'est pas nécessaire.
Le problème : le "plugin sprawl"
Chaque plugin de l'écosystème GLPI est un projet à part : mainteneur propre, dépôt propre, rythme de version propre. C'est une force de la communauté open source, mais cela devient un passif dès que vous en empilez une douzaine dans le même environnement. Les symptômes que nous voyons le plus souvent :
- Compatibilité décalée avec le cœur - GLPI publie une version majeure et chaque plugin a besoin de sa propre mise à jour pour suivre. Il suffit qu'un seul n'ait pas été porté pour que tout l'environnement se bloque à la mise à niveau.
- Conflits entre plugins - deux plugins qui surchargent le même hook, injectent du CSS concurrent ou enregistrent la même route. Le symptôme apparaît souvent loin de la cause.
- Dépendances implicites - un plugin qui ne fonctionne qu'avec un autre installé, sans que ce soit documenté. Désactiver le mauvais fait tomber une fonction que personne ne lui associait.
- Surface de maintenance multipliée - chaque plugin est un journal des modifications à suivre, une CVE à surveiller et un "va-t-il redémarrer la prochaine fois ?" à chaque fenêtre de maintenance.
Comment fonctionne l'approche modulaire
L'alternative n'est pas de renoncer à des fonctionnalités - c'est de réduire le nombre de choses indépendantes à gérer. NexTool inverse la logique : au lieu de N plugins, un seul plugin de base (gratuit) qui héberge des modules activés à la demande.
- Un point d'installation unique - vous installez et mettez à jour le plugin de base ; les modules vivent à l'intérieur, sans que chacun soit un paquet séparé sur le marketplace.
- Activez uniquement ce que vous utilisez - le catalogue couvre l'IA, la communication, les documents, la sécurité, l'automatisation et plus ; vous allumez module par module selon le besoin, sans transporter ce que vous n'utilisez pas.
- Aucune gestion de dépendances entre modules - la compatibilité entre eux est la responsabilité d'un seul éditeur, testée ensemble à chaque version.
- Un catalogue qui grandit - les nouveaux modules arrivent sans exiger une nouvelle installation de plugin ; ils apparaissent dans l'écran des modules du plugin déjà installé.
- Une base gratuite - le plugin de base et une grande partie du catalogue sont FREE ; les modules sous licence cohabitent au même endroit, et vous ne payez que ce que vous activez.
Comment l'activer
- Installez le plugin de base NexTool comme n'importe quel plugin GLPI : décompressez dans
plugins/, puis installez et activez sous Configuration > Plugins. - Dans le menu, allez dans Configuration > NexTool > Modules.
- Repérez le module voulu dans le catalogue et cliquez sur activer.
- Ouvrez l'écran configurer du module et réglez les paramètres (clés d'API, canaux, profils, ce qui s'applique).
- Répétez pour chaque module. Aucune étape n'exige de réinstaller le plugin de base ni de résoudre des dépendances à la main.
Les trois approches, côte à côte
Tout besoin n'appelle pas la même réponse. Le tableau résume le compromis entre combler un manque avec un plugin isolé de la communauté, avec un module NexTool ou avec une fonctionnalité déjà native de GLPI 11 :
| Critère | Plugin isolé de la communauté | Module NexTool | Fonctionnalité native de GLPI 11 |
|---|---|---|---|
| Dépendances | Une par plugin, souvent implicites | Un seul plugin de base ; modules testés ensemble | Aucune - fait partie du cœur |
| Mise à jour / mise à niveau | Chaque plugin à son rythme ; un retardataire bloque la mise à niveau | Un seul paquet à mettre à jour, compatibilité garantie par l'éditeur | Monte avec GLPI lui-même |
| Conflits | Risque réel entre plugins de mainteneurs différents | Les modules cohabitent dans le même espace, sans collision de hooks | Zéro - c'est le cœur |
| Support | Communauté / bénévole, sans SLA | Éditeur unique avec un canal de support | Feuille de route officielle du projet GLPI |
| Courbe de maintenance | Croît avec le nombre de plugins | Plate - un seul point à suivre | Minimale, mais limitée à ce que le cœur couvre |
Avant toute mise à niveau, la première chose que nous faisons est d'inventorier ce qui est installé et dans quel état. La requête que nous exécutons directement en base :
-- Inventaire des plugins installes dans GLPI et l'etat de chacun.
-- state = 1 signifie active ; les autres etats meritent attention avant la mise a niveau.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;Ce que nous avons appris en maintenance
Chez un client avec plus de 15 plugins isolés, une mise à niveau mineure de GLPI en a fait tomber la moitié : l'environnement remontait, mais quatre plugins restaient en état "à mettre à jour" et disparaissaient du menu. Ce que personne n'attendait, c'est qu'un plugin de rapports dépendait d'une table créée par un autre plugin - désactiver le second effaçait silencieusement le premier. Il nous a fallu une fenêtre entière rien que pour cartographier quel plugin bloquait quel autre. À partir de là, nous avons décidé de traiter chaque nouveau plugin comme une dette de maintenance, pas comme une fonctionnalité gratuite : avant d'installer, la question est devenue "qui le maintient, à quel rythme de version, et qu'est-ce qui casse s'il ne remonte pas à la prochaine mise à niveau ?". L'erreur courante - que nous avons commise - est d'installer un plugin pour un seul rapport et de l'oublier installé pendant deux ans, jusqu'à ce qu'il soit la raison pour laquelle une mise à niveau ne se termine pas.
Pour qui c'est fait (et quand NE PAS l'utiliser)
L'approche modulaire brille quand vous avez besoin de plusieurs fonctionnalités cohérentes - IA sur le ticket, notification par WhatsApp, ordre de service en PDF, flux d'approbation - et voulez un seul éditeur responsable de la compatibilité et du support. Si votre exploitation vit sur des fenêtres de maintenance serrées et ne peut pas se permettre une mise à niveau bloquée par un plugin orphelin, centraliser est rentable.
Mais soyez honnête sur l'inverse : si un seul plugin de la communauté résout déjà bien votre unique besoin, installez-le et passez à autre chose - inutile d'amener un plugin de base pour activer un seul module. Et surtout, regardez d'abord ce que GLPI fait déjà nativement. L'inventaire natif (GLPI Inventory, depuis GLPI 10) remplace l'ancien FusionInventory dans la plupart des cas ; les formulaires et objets personnalisés qui exigeaient FormCreator et GenericObject ont été intégrés au cœur dans GLPI 11. Tout n'a pas besoin d'un plugin, encore moins de NexTool : le meilleur plugin est souvent celui que vous n'avez pas à installer.
Compatibilité
Le plugin de base NexTool est gratuit et tourne à la fois sur GLPI 10 et GLPI 11 - les modules fonctionnent sur les deux versions sans adaptation. Cela compte en pratique : qui migre du 10 vers le 11 garde la même base de modules des deux côtés, sans réécrire l'intégration. Les modules sous licence cohabitent avec les gratuits sur le même écran, et vous n'activez que ce dont vous avez besoin.
Si votre exploitation a atteint le point où gérer les plugins est devenu un travail à part entière, il vaut la peine de découvrir NexTool comme hub modulaire - ou parlez à l'équipe pour évaluer si votre cas appelle une centralisation ou si le cœur suffit déjà.
Ce contenu a été produit avec l'aide de l'intelligence artificielle et révisé par l'équipe Nextool Solutions.
