Installer un plugin pour chaque besoin semble la solution évidente dans GLPI - jusqu'au jour de la montée de version, quand la moitié d'entre eux ne redémarre pas. Après des années à maintenir des environnements GLPI 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 publication, 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 publication propre. C'est une force de la communauté open source, mais cela devient un passif dès que vous en accumulez 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 bloquer tout l'environnement lors de la montée de version.
- 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 généralement 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, c'est un changelog à suivre, une CVE à surveiller et un « est-ce qu'il redémarrera la prochaine fois ? » à chaque fenêtre de maintenance.
Avant tout : inventoriez ce que vous avez déjà
Avant toute montée de version - et avant d'installer un plugin de plus - la première chose que nous faisons est de lister ce qui est installé et dans quel état. La requête que nous lançons 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 montee de version.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;Pour chaque ligne qui remonte, trois questions : qui le maintient, à quel rythme de publication, et qu'est-ce qui casse s'il ne redémarre pas à la prochaine montée de version. Un plugin auquel personne ne sait répondre est candidat à sortir avant la fenêtre, pas pendant.
Les trois approches, côte à côte
Tous les besoins n'appellent pas la même réponse. Le tableau résume l'arbitrage entre combler une lacune 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 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 | Chaque plugin à son rythme ; un retardataire bloque la montée de version | Un seul paquet à mettre à jour, avec une compatibilité testée par l'éditeur | Monte avec GLPI |
| Conflits | Risque réel entre plugins de mainteneurs différents | Moindre : les modules sont testés ensemble. Cela n'élimine pas les bugs - cela concentre la responsabilité en un seul endroit | Zéro - c'est le cœur lui-même |
| Couverture des versions | Variable selon le plugin ; peut ne pas exister pour votre version | La base tourne sur GLPI 10 et 11 ; chaque module déclare les versions qu'il prend en charge (plusieurs sont exclusifs à la 11) | Suit la version installée |
| Support | Communauté / bénévole, sans SLA | Éditeur unique avec un canal de support | Feuille de route officielle du projet GLPI |
| Dépendance à l'éditeur | Faible - code ouvert, vous pouvez forker et maintenir | Élevée - feuille de route, prix et pérennité dépendent d'une seule entreprise | Celle du projet GLPI lui-même |
| Courbe de maintenance | Croît avec le nombre de plugins | Plate - un seul point à suivre | Minimale, mais limitée à ce que couvre le cœur |
Comment fonctionne l'approche modulaire
L'alternative n'est pas de renoncer aux 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 la marketplace.
- N'activez que ce que vous utilisez - le catalogue couvre l'IA, la communication, les documents, la sécurité, l'automatisation et plus encore ; vous activez module par module selon le besoin, sans embarquer ce que vous n'utilisez pas.
- Pas de dépendances à gérer entre modules - la compatibilité entre eux relève d'un éditeur unique, testée conjointement à chaque publication.
- 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 bonne partie des modules sont FREE ; les modules sous licence cohabitent au même endroit, et vous ne payez que ce que vous activez.
Ce que nous avons appris en maintenance
Chez un client avec plus de 15 plugins isolés, une montée de version mineure de GLPI en a fait tomber la moitié : l'environnement redémarrait, mais quatre plugins restaient à l'état « à mettre à jour » et disparaissaient du menu. Ce que personne n'avait prévu, 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. Nous avons passé une fenêtre entière rien qu'à cartographier quel plugin bloquait lequel. À partir de là, nous avons décidé de traiter chaque nouveau plugin comme une dette de maintenance, pas comme une fonctionnalité gratuite. 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 devienne la raison pour laquelle une montée de version ne passe 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 WhatsApp, bon d'intervention en PDF, circuit de validation - et que vous voulez un éditeur unique 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 montée de version bloquée par un plugin orphelin, centraliser est rentable.
Mais soyez honnête sur l'inverse : si un seul plugin de la communauté répond déjà bien à votre unique besoin, installez-le et passez à autre chose - il n'y a aucune raison 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 les 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.
Il reste un arbitrage que la centralisation ne résout pas, elle ne fait que le déplacer : concentrer les fonctionnalités chez un éditeur unique concentre aussi le risque. Avec des plugins open source isolés, si le mainteneur abandonne le projet, vous pouvez forker et continuer. Avec un hub propriétaire, la feuille de route, le prix et la pérennité dépendent d'une seule entreprise. Ce n'est pas une raison d'écarter l'approche - c'est une raison d'évaluer l'éditeur comme vous en évalueriez n'importe quel autre : historique de publications, canal de support, et ce qu'il advient de vos données si vous décidez de partir.
Comment activer un module
- Installez le plugin de base NexTool comme n'importe quel plugin GLPI : décompressez dans
plugins/, puis installez et activez dans Configuration > Plugins. - Dans le menu, allez dans Configuration > NexTool > Modules.
- Repérez le module souhaité dans le catalogue, vérifiez les versions de GLPI qu'il prend en charge et cliquez sur activer.
- Ouvrez l'écran configurer du module et ajustez 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.
Compatibilité
Le plugin de base NexTool est gratuit et tourne aussi bien sur GLPI 10 que sur GLPI 11. La compatibilité des modules, en revanche, est déclarée module par module : une partie du catalogue est cross-version et tourne sur les deux, tandis qu'une bonne partie des modules récents est exclusive à GLPI 11, car elle s'appuie sur des fonctionnalités qui n'existent que là. Le catalogue affiche les versions prises en charge par chaque module, et l'activation est bloquée par un message explicite quand l'environnement n'est pas compatible - vous le découvrez avant d'installer, pas au milieu de la montée de version.
En pratique, pour qui migre de la 10 vers la 11 : vérifiez dans le catalogue lesquels des modules que vous utilisez sont cross-version. C'est le même inventaire que ce billet recommande pour n'importe quel plugin - à la différence près qu'ici l'information tient en un seul endroit, au lieu d'être éparpillée sur une douzaine de dépôts.
Si votre exploitation en est arrivée au point où gérer les plugins est devenu un travail en soi, 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à.
Revu par l'équipe NexTool Solutions.
