GLPI : les cinq signes qu'il est temps de changer

GLPI est un bon outil. Libre, connu, avec une communauté francophone active, il a sorti des milliers d'équipes de la messagerie partagée, et il reste excellent pour ce pour quoi il a été conçu : inventorier un parc et suivre des tickets. Les organisations que j'ai vues le quitter ne le faisaient pas par déception. Elles le faisaient parce que leurs besoins avaient changé de nature, et que l'outil de tickets était devenu un outil de contournement.

Voici les cinq signes, dans l'ordre où ils apparaissent en général, puis ce qu'une plateforme change et comment migrer sans rien perdre.

Signe 1 : le catalogue de services vit dans un plugin

Les premières demandes structurées (accès, matériel, congés informatiques) passent par un plugin de formulaires. Ça marche, jusqu'au jour où une demande exige deux approbations successives, une tâche pour l'équipe réseau puis une pour l'équipe poste de travail, et une notification au demandeur à chaque étape. Le plugin n'a pas été conçu pour ça ; on bricole avec des règles, puis avec des mails.

Un catalogue de plateforme porte tout cela nativement : variables, chaîne d'approbation, tâches d'exécution, notifications. Ce n'est pas un formulaire, c'est un processus.

Signe 2 : les règles se multiplient et se contredisent

Au début, trois règles d'affectation. Trois ans plus tard, quatre-vingts, écrites par cinq personnes dont deux sont parties. Un ticket arrive dans la mauvaise file, personne ne sait laquelle des quatre-vingts l'a envoyé là, et on ajoute une quatre-vingt-unième pour corriger.

Le problème n'est pas le nombre de règles, c'est l'absence d'un modèle : quand la catégorie, le site et le service sont des données structurées reliées entre elles, les règles deviennent courtes et lisibles, et la plupart disparaissent.

Signe 3 : la CMDB dit quel serveur est tombé, pas ce qui est indisponible

L'inventaire GLPI est précis ; avec l'agent, il l'est même remarquablement. Mais un inventaire répond à « quel matériel avons-nous », pas à « quel service est touché ». Quand le serveur de messagerie tombe, la direction ne demande pas son numéro de série. Elle demande combien d'agences n'ont plus de courrier.

Une CMDB alignée CSDM relie les services métier aux applications et aux composants. L'incident se rattache au service, l'impact se calcule, la priorité aussi. L'inventaire reste utile ; il devient une source, pas le modèle.

Signe 4 : un SLA global, mesuré par équipe

« Résolution en huit heures » pour tout le monde est faux pour tout le monde. Les engagements réalistes sont par service et par priorité, avec des calendriers différents selon les équipes. Quand l'outil ne sait attacher qu'un SLA par entité ou par catégorie, le reporting vers la direction se refait à la main, chaque mois, dans un tableur.

Signe 5 : les tableurs reviennent

C'est le signe définitif. Un tableur pour les demandes d'accès en attente d'approbation, un autre pour les changements du mois, un troisième pour le suivi des prestataires. Chacun est né d'une limite de l'outil, et chacun est maintenant le vrai système pour quelqu'un. Le jour où ces tableurs existent, l'organisation a déjà quitté GLPI ; elle ne l'a pas encore dit.

Ce qu'une plateforme change, concrètement

Sur une plateforme de gestion de services, tout est une table décrite par un dictionnaire. Ajouter un champ, une règle, un flux, une vue se fait depuis l'interface, sans plugin ni développeur. Le catalogue porte ses variables, ses approbations et ses tâches. La CMDB relie les services aux composants. Les engagements s'attachent selon le service touché et tournent sur le bon calendrier. Le portail employés se compose page par page.

Les compétences ITIL 4 de votre équipe restent valables. Ce qui change, c'est que l'outil suit vos processus au lieu de les contraindre, et que la question « peut-on faire ça ? » a une réponse en configuration plutôt qu'en devis.

Et les assistants IA (champs prédits, résumé, solution suggérée, réponse rédigée, assistant au portail) travaillent dans ce modèle, avec vos clés, pas dans un plugin à côté.

Migrer sans tout perdre

L'export de GLPI en CSV couvre l'essentiel : utilisateurs, entités, groupes, matériels, logiciels, tickets. Dans TRAMEWORK, les jeux d'import font la correspondance automatique des colonnes et transforment à la volée. L'ordre qui marche :

1. Utilisateurs, groupes et entités. Une heure ; les entités deviennent des sites ou des services selon votre usage.
2. Matériels et logiciels vers les classes CMDB correspondantes. Une demi-journée, en gardant l'inventaire GLPI comme source le temps de la bascule.
3. Catégories et catalogue. À réconcilier à la main : c'est le vrai travail, et l'occasion de supprimer ce qui ne sert plus.
4. Tickets ouverts uniquement. L'historique clos reste consultable dans GLPI, archivé ; le migrer coûte cher et fausse les rapports.

Comptez deux à trois semaines à temps partiel pour une organisation de taille moyenne, sans interruption : les deux outils tournent en parallèle le temps de la bascule. Le guide Migrer depuis GLPI détaille les correspondances de champs et la liste de contrôle.

Et si GLPI suffit

Alors gardez-le. Pour un inventaire de parc précis avec agent et un service desk simple, il reste le bon outil, et il est gratuit en auto-hébergement. La comparaison avec GLPI dit, point par point, ce que chaque outil fait, en renvoyant aux pages publiques de GLPI.

Si vous reconnaissez deux des cinq signes, ouvrez une instance gratuite, importez un export CSV de vos utilisateurs et refaites votre demande d'accès la plus compliquée dans le catalogue. Il n'y a rien à installer, et vous saurez en une après-midi.