Le ticket le moins cher est celui qui n'est jamais ouvert. Quand l'utilisateur voit un avis clair sur l'écran même de GLPI avant de signaler quelque chose de déjà connu, il n'ouvre pas le ticket - et la file du service desk cesse de se remplir de doublons sur la même maintenance ou le même incident. Le plugin News règle exactement cela : bannières d'alerte, d'annonce et de maintenance dans l'interface, pour les techniciens et pour les personnes qui utilisent le self-service. En exploitation de parcs clients au quotidien, nous avons appris qu'allumer la bannière est la partie facile ; ce qui sépare une communication utile d'un portail encombré, c'est le bon ciblage, la date de fin et la discipline de retirer l'avis dès qu'il ne s'applique plus.
Avis statique vs notification au technicien : ne pas confondre
Avant d'installer quoi que ce soit, il vaut la peine de séparer deux problèmes différents. L'avis statique (plugin News, ou les Rappels Publics natifs) s'adresse à celui qui n'a pas encore ouvert le ticket - c'est de la communication préventive sur le self-service et le tableau de bord. La notification au technicien (e-mail natif ou la cloche de Smart Notify) s'adresse à celui qui traite déjà le ticket. L'erreur courante est de croire que l'un couvre l'autre : couper l'e-mail parce qu'il y a une bannière, ou poser une bannière en espérant que le technicien soit averti d'un suivi. Ce sont des couches complémentaires. Le plugin News est la couche extérieure - celle qui empêche le ticket de naître.
Installer et localiser le plugin News
News est distribué via le Marketplace de GLPI et le dépôt officiel. Après l'avoir téléchargé dans plugins/news, installez-le et activez-le. En ligne de commande, exécutez-le en tant qu'utilisateur du serveur web - le piège ici est d'utiliser --allow-superuser ou de lancer en root, ce qui écrit des fichiers avec un mauvais propriétaire et casse ensuite le cron :
# GLPI 10/11 (CLI) - executez en tant qu'utilisateur du serveur web, jamais avec --allow-superuser :
docker exec --user apache glpi php bin/console glpi:plugin:install news
docker exec --user apache glpi php bin/console glpi:plugin:activate news
# Alternative via l'interface : Configuration > Plugins, bouton Installer puis Activer.Une fois le plugin actif, la gestion des avis se trouve généralement dans Outils > Alertes (le libellé peut varier selon la version). Chaque alerte a quatre décisions qui comptent : le type, le message, où et pour qui elle apparaît, et pendant combien de temps.
Anatomie d'une alerte : les champs qui comptent
Le type définit la couleur et la lecture sémantique de la bannière - l'utilisateur décode l'urgence avant de lire le texte. Utilisez la sémantique avec parcimonie : si tout est rouge, rien n'est urgent.
| Type | Couleur / sémantique | Quand l'utiliser | Exemple |
|---|---|---|---|
| Information | Bleu - neutre | Annonce générale, nouveauté | "Nouvelle version de GLPI disponible" |
| Avertissement | Jaune - attention | Point à noter, sans urgence | "Indiquez le numéro d'inventaire à l'ouverture d'un ticket" |
| Problème | Rouge - critique | Incident actif en cours | "Nous avons connaissance de la lenteur de l'e-mail" |
| Maintenance | Mise en avant - planifié | Fenêtre planifiée avec horaire fixé | "Système X en maintenance le 15/07, 22h-2h" |
La visibilité contrôle deux axes : où la bannière apparaît (l'écran central du technicien, le portail self-service, l'écran de connexion) et pour qui (tous, des profils, des groupes ou des entités spécifiques). C'est là que se cache le piège qui gêne le plus dans les installations multi-entités : créer l'alerte sur l'entité racine avec "récursif" activé fait fuiter l'avis vers le self-service de TOUS les clients qui partagent la même instance. Une annonce de maintenance du Client A apparaît pour le Client B. En exploitation, la règle est de cadrer chaque alerte sur l'entité spécifique et de n'utiliser la racine récursive que pour les avis qui valent pour toute la base, comme une politique d'ouverture de ticket.
La période (date de début et de fin) est le champ que tout le monde sous-estime - et c'est celui qui encombre le plus le portail avec le temps.
Modèle prêt à l'emploi : bannière de maintenance planifiée
Le message accepte le HTML, vous pouvez donc standardiser une bannière lisible plutôt qu'un paragraphe continu. Ce modèle indique clairement ce qui tombe, quand cela revient et ce que l'utilisateur doit faire. Copiez-le, ajustez les valeurs et collez-le dans le champ message :
<strong>Maintenance planifiee - Systeme de messagerie</strong><br>
Fenetre : 15/07/2026, de 22h00 a 02h00 (heure locale).<br>
Impact : le webmail et l'envoi de messages seront indisponibles.<br>
A faire : reportez les envois critiques apres 02h00.<br>
<em>Inutile d'ouvrir un ticket au sujet de cette indisponibilite.</em>Cette dernière ligne - "inutile d'ouvrir un ticket" - fait plus pour réduire la file que toute la bannière. C'est l'instruction explicite que l'utilisateur cherche avant de décider de signaler.
Le piège de l'"alerte éternelle" et le SQL d'hygiène
Dans chaque installation que nous reprenons en exploitation, le schéma se répète : le portail self-service a accumulé six ou huit vieilles bannières que personne n'a expirées. L'utilisateur apprend à ignorer tout le bandeau - c'est la cécité aux bannières - et quand un avis qui compte arrive, personne ne le lit. La cause racine est presque toujours une alerte sans date de fin. Pire encore, la bannière "nous avons connaissance de la lenteur" restée en place trois jours après la résolution de l'incident, signalant une panne déjà terminée et érodant la confiance dans le canal. Nous avons adopté un balayage mensuel directement en base. Trouvez d'abord le schéma réel (les noms de colonnes varient selon les versions du plugin), puis chassez les éternelles :
-- 1. Localiser la table des alertes du plugin News :
SHOW TABLES LIKE 'glpi_plugin_news_%';
-- 2. Verifier les vrais noms de colonnes (ils varient selon la version du plugin) :
DESCRIBE glpi_plugin_news_alerts;
-- 3. Alertes "eternelles" - sans date de fin, la cause racine de la cecite aux bannieres :
SELECT id, name, type, date_start, date_end
FROM glpi_plugin_news_alerts
WHERE date_end IS NULL OR date_end = '0000-00-00 00:00:00'
ORDER BY date_start;
-- 4. Alertes encore actives dont la fenetre est deja passee (oubli de retrait) :
SELECT id, name, type, date_end
FROM glpi_plugin_news_alerts
WHERE date_end IS NOT NULL
AND date_end < NOW()
ORDER BY date_end DESC;La requête 4 est celle qui surprend le plus le client : elle liste l'incident "déjà résolu" mais toujours à l'écran. Lancer cela une fois par mois maintient la crédibilité du canal - et c'est peu coûteux.
News, Rappels Publics ou Smart Notify : lequel choisir
Toute annonce n'a pas besoin d'un plugin. GLPI dispose de Rappels Publics natifs, et NexTool maintient Smart Notify pour le côté dynamique. Chacun règle un segment :
| Critère | Rappels Publics (natif) | Plugin News | Smart Notify (NexTool) |
|---|---|---|---|
| Nature | Texte/avis simple | Bannière statique par type | Notification dynamique (cloche) |
| Public visé | Ceux qui n'ont pas encore ouvert | Ceux qui n'ont pas encore ouvert | Technicien en session |
| Où cela apparaît | Zone de planification / central | Central, self-service et connexion | Cloche dans la navbar GLPI |
| Ciblage | Profil / entité | Type, écran, profil, groupe, entité | Par événement et par technicien |
| Couleur par gravité | Non | Oui (info / avertissement / problème) | Son par priorité |
| Nécessite d'installer un plugin | Non (natif) | Oui | Oui (module NexTool) |
| Idéal pour | Note rapide sans plugin | Maintenance et incident sur self-service | Dire au technicien ce qui a changé |
En pratique : utilisez les Rappels Publics natifs pour une note simple sans rien installer ; le plugin News quand il faut une bannière colorée par type, un ciblage par écran et un avis sur l'écran de connexion ; et Smart Notify pour l'autre face de la médaille - avertir le technicien, en quasi temps réel, des suivis, validations et tâches à l'intérieur même de GLPI. Ils ne rivalisent pas : News empêche le ticket de naître, Smart Notify accélère le ticket qui existe déjà.
Bonnes pratiques de communication (issues de l'exploitation)
- Tout message a une date de fin. Sans exception. Si vous ne savez pas quand l'avis expire, vous ne savez pas pourquoi vous le publiez.
- Annoncez la maintenance 24h à l'avance et gardez la bannière jusqu'à la fin de la fenêtre. Pour des fenêtres planifiées annoncées à l'avance, nous avons vu la file de doublons sur "système en panne" baisser nettement - considérez cela comme une fourchette honnête, pas un chiffre magique.
- Retirez la bannière d'incident dès la résolution. Un avis de panne encore affiché après la panne est pire que pas d'avis du tout.
- N'empilez pas les bannières. Trois avis simultanés sur le self-service, c'est déjà du bruit ; personne ne lit le quatrième.
- Cadrez par entité sur les instances multi-clients. Récursif à la racine uniquement pour ce qui vaut pour tout le monde.
- Des couleurs qui ont du sens. Le rouge signifie un incident actif, pas "à lire attentivement".
Chez NexTool, nous traitons la communication dans GLPI comme une partie de l'exploitation : nous configurons les bons canaux, définissons la politique d'expiration des avis et croisons communication statique et notification dynamique pour le parc du client. Si vous voulez aller au-delà de la bannière, le module Smart Notify couvre le côté technicien, et notre équipe d'exploitation aide à concevoir le flux complet.
Révisé par l'équipe NexTool Solutions.
