Un service desk qui tient la route en 2026 ne se résume plus à un tableur partagé et à une boîte mail dédiée. Les directions informatiques attendent désormais un point d’entrée unique, des tickets typés, des SLA mesurables, un inventaire à jour, une base de connaissances vivante et une intégration aux outils existants (annuaire, supervision, sauvegarde, ChatOps). GLPI 11, sorti le 30 septembre 2025 et désormais stabilisé en 11.0.7 (29 avril 2026), est devenu la solution open source de référence pour bâtir ce socle sans payer une licence ITSM SaaS qui pèse vite plusieurs milliers d’euros par an.
Ce guide vous montre comment passer d’une intuition (« il nous faut un helpdesk ») à un service desk opérationnel aligné sur les pratiques ITIL 4, avec une feuille de route claire, des choix d’architecture justifiés, des indicateurs lisibles, et un planning de déploiement réaliste pour une équipe IT de 2 à 20 personnes.
Pourquoi GLPI 11 pour un service desk ITIL en 2026
Le marché ITSM se polarise. D’un côté, des suites propriétaires (ServiceNow, BMC Helix, Ivanti) puissantes mais chères et complexes à customiser. De l’autre, des SaaS modernes (Jira Service Management, Freshservice, Zendesk) plus accessibles mais facturés au technicien et limités sur la gestion d’actifs. GLPI occupe un troisième espace : open source GPLv3, édité par Teclib’ depuis Nancy (France) avec une communauté mondiale active, sans facturation au siège, avec un cœur ITSM doublé d’un cœur ITAM (inventaire de parc) que peu de concurrents intègrent nativement.
GLPI 11 apporte cinq évolutions concrètes par rapport à GLPI 10 :
- Native Custom Assets — créer des types d’actifs personnalisés (caméras IP, kits de visioconférence, badges d’accès, GPU, abonnements logiciels) avec leurs propres champs et comportements, sans plugin
- Integrated Forms — un éditeur visuel pour publier des formulaires utilisateurs (demande de matériel, ouverture de compte, accès VPN, signalement d’incident) qui pré-typent le ticket et déclenchent automatiquement les bons workflows
- Self-Service Portal repensé — la page d’accueil utilisateur affiche le catalogue, l’état des tickets ouverts, les articles de connaissance, et oriente vers le bon formulaire ; le portail est utilisable sans formation
- Authentification à deux facteurs (2FA) native pour les comptes locaux et délégable au fournisseur d’identité externe
- Webhooks sortants — déclencher un appel HTTP vers un service externe (Slack, Teams, Mattermost, n8n, script maison) sur n’importe quel événement du cycle de vie d’un ticket ou d’un actif
Ces évolutions ne sont pas anodines : elles ferment trois trous qui forçaient autrefois à empiler des plugins (FusionInventory pour l’inventaire, Formcreator pour les formulaires, OAuth SSO pour la 2FA, et un connecteur tiers pour Slack). GLPI 11 absorbe ces fonctions dans le cœur, ce qui réduit le poids des mises à jour et le risque de rupture lors d’un upgrade majeur.
Aligner GLPI sur ITIL 4 (et préparer ITIL 5)
ITIL 4, publié par Axelos et désormais distribué par PeopleCert qui a racheté l’éditeur en 2021, reste le référentiel dominant en 2026 pour penser la gestion des services. PeopleCert déploie progressivement ITIL 5 annoncé pour l’ère numérique et l’IA, mais l’écrasante majorité des organisations vit encore sur les bases ITIL 4 : quatre dimensions (organisation et personnes, information et technologie, partenaires et fournisseurs, flux de valeur et processus), sept principes directeurs, et un Service Value System qui structure la chaîne du besoin client au service livré.
GLPI ne « livre pas ITIL clé en main » — aucune solution ne le fait. Le travail d’alignement consiste à mapper les pratiques ITIL utiles à votre contexte sur les objets natifs de GLPI :
| Pratique ITIL 4 | Objet GLPI 11 mobilisé |
|---|---|
| Service Request Management | Tickets de type Demande + formulaires intégrés + catalogue |
| Incident Management | Tickets de type Incident + matrices urgence/impact/priorité + SLA |
| Problem Management | Module Problèmes (cause racine, mesures palliatives, plan d’action) |
| Change Enablement | Module Changements (CAB léger, comité virtuel, planification) |
| Service Configuration Management | Inventaire GLPI Agent + relations entre actifs (CMDB) |
| Service Level Management | SLA / OLA / UC avec règles d’escalade automatiques |
| Knowledge Management | Base de connaissances avec articles publics, internes, et FAQ |
| Monitoring & Event Management | Webhooks entrants depuis votre supervision (Zabbix, Centreon, Prometheus) |
L’erreur classique consiste à activer toutes les pratiques d’un coup. Un service desk qui démarre sur incidents + demandes + base de connaissances, et qui ajoute Problèmes/Changements quatre à six mois plus tard, atteint sa maturité bien plus vite qu’une équipe qui tente de tout déployer en parallèle.
Architecture cible pour un service desk professionnel
Avant d’installer la première VM, posez l’architecture. Un service desk GLPI 11 stable pour 50 à 1 000 utilisateurs tient sur trois composants :
- Un serveur applicatif sous Ubuntu Server 24.04 LTS ou Debian 12, PHP 8.2 ou 8.3, Apache ou Nginx, qui héberge GLPI et sert l’interface web
- Une base de données MariaDB 10.6 LTS ou plus récent (MariaDB 11.4 LTS recommandée pour les nouveaux déploiements), ou MySQL 8.0+, séparable sur une seconde VM si la volumétrie augmente
- Une flotte d’agents GLPI Agent 1.17+ installés sur chaque poste et serveur Linux/Windows/macOS pour remonter l’inventaire matériel et logiciel
Pour une PME de 50 à 200 utilisateurs, une VM 4 vCPU / 8 Go RAM / 80 Go SSD suffit largement à héberger GLPI et MariaDB sur le même hôte. Au-delà, séparez la base sur un second serveur, ajoutez un reverse proxy Nginx avec mise en cache des assets statiques, et programmez des sauvegardes différentielles MariaDB quotidiennes.
Le détail pas-à-pas d’installation est traité dans le tutoriel Installer GLPI 11 sur Ubuntu Server 24.04 LTS. Pour un environnement à haute disponibilité, lisez plus tard la section dédiée du présent guide.
Feuille de route en six semaines
Un déploiement réussi suit un séquencement court mais discipliné. Cette feuille de route de six semaines part d’un service desk vide pour arriver à un outil opérationnel avec inventaire automatisé, SLA contractualisés, et premiers indicateurs de pilotage.
Semaine 1 — Socle technique et premier ticket
Installer le serveur GLPI 11, créer la base MariaDB, exécuter l’installeur web, créer les comptes des techniciens, configurer la connexion SMTP pour les notifications. Ouvrir le premier ticket de test, vérifier que les e-mails sortants arrivent bien, faire une sauvegarde manuelle de la base. Cette semaine vous montre que le tuyau fonctionne avant d’y investir du temps de paramétrage.
Semaine 2 — Annuaire et utilisateurs
Brancher GLPI sur votre Active Directory ou OpenLDAP existant, importer les utilisateurs, mapper les groupes en profils GLPI (Self-Service pour les utilisateurs finaux, Observer, Technician, Supervisor, Super-Admin). Cette étape évite la double saisie des comptes et garantit que tout salarié peut ouvrir un ticket avec son identifiant habituel. La procédure complète est détaillée dans Configurer l’authentification LDAP/AD avec GLPI 11.
Semaine 3 — Inventaire automatisé
Déployer GLPI Agent 1.17 sur tous les postes Windows via une stratégie de groupe (GPO) ou Intune, sur les serveurs Linux via apt ou rpm, et sur les Mac via le package PKG. Au bout de quelques heures, le parc apparaît dans GLPI avec les caractéristiques matérielles, les logiciels installés, l’adresse IP, le numéro de série. Plus de tableur d’inventaire obsolète. Le tutoriel Inventorier le parc IT avec GLPI Agent donne le détail commande par commande.
Semaine 4 — Catalogue, formulaires, base de connaissances
Publier 6 à 12 formulaires self-service qui couvrent 80 % des demandes récurrentes : déblocage de compte, remise à zéro de mot de passe, demande de logiciel, demande de matériel, ouverture d’accès VPN, changement de poste, signalement de panne, retour de matériel. Pour chaque formulaire, rédiger l’article de connaissance associé. Vos utilisateurs trouvent leurs réponses sans appeler un technicien.
Semaine 5 — SLA et matrice d’escalade
Définir trois ou quatre niveaux de priorité (P1 critique, P2 élevé, P3 normal, P4 faible), associer à chacun un temps de prise en compte (TTO) et un temps de résolution (TTR), définir les règles d’escalade quand un SLA glisse. Mesurer le respect des SLA sur les premiers tickets clos. Le détail méthodologique est dans SLA et matrice d’escalade dans GLPI.
Semaine 6 — Intégrations et tableaux de bord
Brancher les webhooks vers votre canal de discussion d’équipe (Slack, Teams, Mattermost), configurer une intégration entrante depuis la supervision pour ouvrir automatiquement un ticket sur alerte critique, exposer l’API REST pour les éventuels portails métier internes, créer les premiers dashboards (volume de tickets entrants par semaine, top 5 catégories, taux de respect des SLA, délai moyen de résolution).
À l’issue de la sixième semaine, vous avez un service desk qui mesure ce qu’il fait, qui montre une trajectoire d’amélioration, et qui peut justifier ses choix devant la direction.
Modèle de données et conventions de nommage
GLPI propose une hiérarchie d’entités qui modélise vos sites ou vos directions. Une entité racine contient des sous-entités. Chaque ticket, chaque actif, chaque utilisateur appartient à une entité. Pour une PME mono-site, une seule entité suffit. Pour un groupe avec plusieurs filiales, créer une entité par filiale permet de cloisonner les visibilités tout en mutualisant les techniciens du siège.
GLPI livre huit profils par défaut (Super-Admin, Admin, Supervisor, Technician, Hotliner, Observer, Self-Service, Read-only). Les cinq les plus utilisés au quotidien sont :
- Self-Service — utilisateur final, voit ses propres tickets et la base de connaissances publique
- Observer — lit les tickets sans pouvoir les modifier, utile pour les managers
- Technician — prend en charge les tickets, modifie l’inventaire
- Supervisor — gère son équipe, attribue les tickets, lit les rapports
- Super-Admin — accès complet, à limiter à 1 ou 2 personnes
Sur les catégories de tickets, restez sobres au démarrage. Une dizaine de catégories de premier niveau bien choisies (Compte & identité, Poste de travail, Application métier, Réseau, Téléphonie, Demande de matériel, Demande de logiciel, Sécurité, Question RH-IT, Autre) traitera mieux le quotidien qu’une arborescence à trois niveaux que personne ne maintient. Vous pouvez toujours affiner six mois plus tard, une fois que les données chiffrées orientent la refonte.
Sécurité du service desk en production
Un GLPI exposé à Internet sans durcissement devient vite la cible de tentatives de connexion par dictionnaire et de scans de vulnérabilités. Trois mesures non négociables avant la mise en production :
- HTTPS avec certificat Let’s Encrypt renouvelé automatiquement par
certbot, redirection HTTP → HTTPS au niveau du serveur web, et HSTS activé - Fail2ban filtrant le journal d’authentification GLPI pour bloquer les IP qui multiplient les échecs en moins de 5 minutes
- 2FA native activée pour tous les comptes Technician, Supervisor et Super-Admin (la 2FA pour les utilisateurs Self-Service est facultative mais recommandée si le portail est exposé)
Le détail des commandes (configuration Nginx, règle Fail2ban, headers de sécurité, sauvegarde et restauration) est centralisé dans Sécuriser GLPI en production.
Indicateurs et tableaux de bord à suivre
Un service desk qui ne mesure pas son activité ne s’améliore pas. GLPI 11 expose nativement plusieurs widgets dans son module Dashboards. Pour un démarrage, concentrez-vous sur sept indicateurs :
- Volume de tickets ouverts cette semaine, vs la semaine précédente, vs il y a quatre semaines
- Top 5 des catégories par volume (révèle les chantiers de réduction à la racine)
- Taux de respect du SLA TTO (prise en compte) et TTR (résolution) par niveau de priorité
- Temps moyen et médian de résolution par catégorie
- Volume de tickets résolus en première intervention (first-call resolution)
- Volume de tickets ouverts depuis plus de 14 jours (vieillissement, signal d’engorgement)
- Volume de demandes traitées en self-service via le portail (sans intervention humaine)
L’erreur classique consiste à publier trente indicateurs dans un dashboard que personne ne lit. Mieux vaut un tableau de bord en sept lignes, projeté chaque lundi matin lors du stand-up d’équipe, qu’une cathédrale BI qui ne déclenche aucune décision.
Intégration avec l’écosystème IT existant
GLPI 11 ne vit pas isolé. Sa valeur monte fortement quand il s’interface avec les outils que vous utilisez déjà :
- Annuaire — Active Directory ou OpenLDAP pour l’authentification unique, et idéalement Azure Entra ID ou Google Workspace via SAML 2.0 pour les organisations passées au cloud
- Supervision — Zabbix, Centreon, Nagios, Prometheus + Alertmanager peuvent créer un ticket GLPI automatiquement quand une alerte critique se déclenche, via les webhooks entrants ou via l’API REST
- Sauvegarde — Veeam, Bacula, BorgBackup, Restic peuvent enregistrer leurs rapports dans GLPI sous forme de ticket fermé pour traçabilité
- ChatOps — Slack, Teams, Mattermost reçoivent les notifications de tickets critiques via les webhooks sortants, et certains plugins permettent même de créer un ticket depuis un message
- Outils métier — un portail RH, un ERP, une application interne peuvent ouvrir un ticket pour leur propre compte via l’API REST GLPI, comme détaillé dans API REST GLPI : intégrer un script Python ou un portail métier
Cette interopérabilité, longtemps fragile sur GLPI 9 et début 10, est désormais robuste grâce aux webhooks intégrés et à une API REST stabilisée.
Comparaison avec les autres solutions ITSM du marché
Choisir GLPI n’est pas un acte de foi ; c’est un arbitrage. Pour aider la décision, voici les critères qui tranchent réellement face aux alternatives les plus citées en 2026.
| Critère | GLPI 11 | Jira Service Management | Freshservice | ServiceNow |
|---|---|---|---|---|
| Licence | GPLv3 open source | SaaS, par agent/mois | SaaS, par agent/mois | SaaS, par agent/mois + plateforme |
| Hébergement | Auto-hébergé ou GLPI Network | SaaS Atlassian Cloud | SaaS Freshworks | SaaS ou on-prem grand compte |
| ITAM natif | Inclus (GLPI Agent) | Plugin Insight (payant) | Module ITAM séparé | Module CMDB (payant) |
| Personnalisation profonde | Élevée (custom assets, code PHP) | Limitée hors API | Limitée hors API | Très élevée (Now Platform) |
| Coût pour 10 techniciens | 0 € si auto-hébergé | environ 180 à 220 €/mois (Standard annuel) | 175 à 350 €/mois selon plan | plusieurs milliers d’euros par an |
| Public cible | PME et grands comptes mature open source | Équipes déjà dans Atlassian | PME et ETI | Grandes entreprises et grands comptes |
GLPI gagne sur trois axes : le coût (rien à payer hors infrastructure), la souveraineté (vos données restent sur votre infrastructure), et la richesse ITAM intégrée. Il perd sur deux axes face aux concurrents SaaS : la facilité de démarrage pour une équipe non technique (aucun serveur à administrer chez Jira ou Freshservice) et la qualité de l’écosystème de connecteurs prêts à l’emploi. Si vous avez un administrateur Linux sous la main et que la souveraineté compte, GLPI fait basculer la décision. Si vous voulez allumer l’outil en une heure sans toucher au système, regardez Freshservice.
Tirer parti des Custom Assets de GLPI 11
La fonction Native Custom Assets est probablement la plus structurante de la version 11 pour qui veut dépasser la simple gestion de tickets. Elle permet de créer des types d’actifs qui n’existent pas dans le modèle standard de GLPI, avec leurs propres champs, leurs propres états, et leurs propres relations avec les autres objets.
Trois exemples concrets de Custom Assets utiles dans la vraie vie :
- Abonnement SaaS — champs : éditeur, URL d’administration, nombre de licences, échéance de renouvellement, propriétaire métier, coût annuel. Vous pilotez votre portefeuille SaaS comme votre parc matériel, avec alertes 60 jours avant échéance
- Badge d’accès physique — champs : numéro, salarié titulaire, niveau d’accès, date d’émission, date de retour, statut. Le ticket de demande de badge déclenche la création de l’actif, son cycle de vie est traçable
- Salle de réunion équipée — champs : capacité, équipements (visio, écran tactile, paperboard), plages de maintenance, contact responsable. Combiné aux formulaires intégrés, vous bâtissez une mini-réservation interne sans installer un outil tiers
Cette extensibilité native ferme un trou que GLPI 10 ne comblait qu’avec le plugin GenericObject, plus complexe à maintenir et parfois cassé après une mise à jour majeure.
Le piège classique du déploiement maison sans gouvernance
La moitié des projets GLPI qui échouent ne meurent pas pour des raisons techniques. Ils meurent parce que l’équipe IT installe l’outil, importe les utilisateurs, et oublie qu’un service desk est d’abord un produit interne. Sans propriétaire métier, sans communication aux utilisateurs, sans capitalisation des incidents en articles de connaissance, GLPI devient un cimetière de tickets non lus.
Pour éviter ce piège, désignez dès la première semaine un Service Desk Manager (peut être un poste partagé) qui anime le rituel hebdomadaire : revue des tickets non résolus, identification des tendances, alimentation de la base de connaissances, formation des nouveaux arrivants au portail self-service. Cette personne n’est pas obligatoirement la plus technique de l’équipe — elle est la plus organisée et la plus orientée utilisateur.
Quand passer à la version Cloud GLPI Network
Teclib’ propose GLPI Network, une offre commerciale qui inclut le support officiel, des plugins certifiés (gestion des congés, financier, certifications), et une version SaaS hébergée. Le tarif est calculé selon le nombre d’utilisateurs déclarés et reste compétitif face aux ITSM SaaS du marché.
L’auto-hébergement reste pertinent tant que vous avez les compétences pour administrer la VM, sauvegarder MariaDB, suivre les mises à jour de sécurité, et déployer les agents. Si ces compétences manquent, ou si vous traitez des données sensibles soumises à des exigences de support contractuel (santé, finance, données régaliennes), l’offre Network apporte le filet juridique et opérationnel manquant.
Versions, support et calendrier
GLPI 10.0.x reste maintenu en parallèle de la branche 11, avec des versions de sécurité publiées de manière coordonnée (10.0.25 et 11.0.7 sont sorties le même jour, le 29 avril 2026). Pour un nouveau déploiement en 2026, démarrez directement sur 11.x : le saut de version interne (UI, formulaires, custom assets) est trop important pour qu’il soit pertinent d’installer un 10.x neuf aujourd’hui.
Le cycle de release de la branche 11 suit un rythme d’environ une version mineure tous les deux mois, dont la majorité sont des correctifs de sécurité. Programmez vos mises à jour le mois suivant la sortie pour laisser la communauté éprouver la version, et testez systématiquement sur un environnement de pré-production avant de toucher la production.
Articles associés pour mettre en pratique
Chaque étape évoquée dans ce guide est détaillée dans un tutoriel pas-à-pas dédié :
- Installer GLPI 11 sur Ubuntu Server 24.04 LTS
- Configurer l’authentification LDAP/AD avec GLPI 11
- Inventorier le parc IT avec GLPI Agent
- Workflows ITIL incidents et demandes dans GLPI 11
- SLA et matrice d’escalade dans GLPI
- API REST GLPI : intégrer un script Python ou un portail métier
- Sécuriser GLPI en production : TLS, Fail2ban, durcissement