Une comptable écrit au technicien informatique : son imprimante ne répond plus. Il lit le message entre deux tâches, se dit qu'il regardera après la réunion, et l'oublie. Deux jours plus tard, elle relance, cette fois en copiant son responsable. Le technicien répond qu'il n'a jamais reçu le premier message, ce qu'il croit sincèrement. Le responsable, lui, demande combien de demandes sont en attente dans le service. Personne ne peut répondre, parce que les demandes n'existent nulle part : elles sont dans des messageries, dans des couloirs et dans deux ou trois conversations de messagerie instantanée.
Ce scénario n'a rien à voir avec la compétence des gens. Il vient d'un manque précis : la demande n'existe nulle part en tant qu'objet. Elle n'a ni identifiant, ni propriétaire désigné, ni date de fin attendue. Un outil de ticket ne fait rien d'autre que lui donner ces trois attributs.
Deux outils, deux métiers
GLPI est d'abord un gestionnaire de parc. Il sait ce que possède l'entreprise : postes, serveurs, imprimantes, licences, contrats, garanties, et qui utilise quoi. Il embarque aussi une gestion de tickets, correcte et suffisante pour une équipe interne. Son interface est dense et administrative, ce qui convient à un technicien et rebute un utilisateur occasionnel.
Zammad est d'abord un outil de support. Il traite la conversation : un message arrive par courriel, par formulaire ou par téléphone, devient un fil, et reste lisible de bout en bout. Son interface est agréable, la recherche est rapide, et la fusion de fils en double se fait sans douleur. Il ne sait rien du parc, et ce n'est pas son rôle. Il est sous licence AGPL version 3.
La question n'est donc pas de choisir le meilleur des deux : ils ne font pas le même travail.
Un seul outil, quand c'est suffisant
Pour une structure de moins de cinquante postes avec un technicien, GLPI seul suffit, et c'est la réponse honnête. Le parc et les tickets au même endroit, une seule base à sauvegarder, une seule montée de version à suivre. L'interface n'est pas séduisante, les utilisateurs déposent leurs demandes depuis un portail simplifié, et le gain par rapport au courriel est immédiat.
Ajouter un second outil à ce stade, c'est doubler l'exploitation pour un confort d'interface. On s'en passe.
Deux outils, quand le volume le justifie
Le couple se justifie quand le support reçoit un volume qui se compte en dizaines de demandes quotidiennes, ou quand ce support s'adresse aussi à des clients externes.
Zammad devient alors le point d'entrée unique : une adresse de courriel de support y aboutit, chaque message devient un fil, et le technicien travaille dans un outil conçu pour la conversation. GLPI reste la source de vérité du parc, et continue de gérer les actifs, les contrats et les échéances de garantie.
L'intérêt réel de l'assemblage tient dans un seul geste : quand le technicien ouvre un fil, il voit quel matériel utilise la personne, sa garantie et son historique d'incidents. Sans ce lien, il faut basculer d'une fenêtre à l'autre et taper un nom dans une recherche, ce qui semble anodin et ne se fait jamais dans les faits. Avec ce lien, on constate qu'un modèle d'imprimante génère à lui seul le tiers des tickets, ce qu'aucune intuition n'avait relevé.
Le raccordement passe par les interfaces de programmation des deux outils, et demande un vrai travail d'intégration : identification commune des personnes, correspondance entre un utilisateur Zammad et un utilisateur GLPI, sens de la synchronisation. Une authentification unique partagée, du type Keycloak, simplifie considérablement la moitié du problème en donnant aux deux outils la même notion d'identité.
L'inventaire qui se remplit tout seul
Un inventaire tenu à la main est faux au bout de six mois. C'est une constante, et il n'y a pas d'exception disciplinée.
GLPI accepte un agent installé sur les postes qui remonte automatiquement le matériel, les logiciels installés, les numéros de série et les changements. C'est ce qui distingue un inventaire vivant d'un tableur avec une jolie interface. L'agent s'installe par les moyens habituels de gestion de parc, et la remontée se planifie une fois par jour.
Pour l'infrastructure réseau, la découverte par SNMP complète le tableau : commutateurs, imprimantes, points d'accès apparaissent sans intervention. Sur le périmètre des équipements réseau et de l'adressage, un outil spécialisé comme NetBox reste plus précis, et les deux cohabitent sans conflit tant que la frontière est claire : GLPI porte ce qui a un utilisateur et un contrat, NetBox ce qui a une adresse et un port.
Pour un suivi fin des logiciels et de la configuration des postes, osquery apporte une granularité que l'agent standard n'a pas, au prix d'une chaîne supplémentaire à exploiter.
Le point de sécurité qu'il faut regarder en face
GLPI contient l'inventaire complet de l'entreprise : machines, versions de logiciels, contrats, parfois des identifiants stockés dans des champs de documentation. C'est exactement la carte que cherche quelqu'un qui prépare une intrusion.
Or la version 11.0.9, publiée le 16 septembre 2026, est une version de sécurité qui corrige une liste sérieuse : plusieurs injections de code dans des champs d'affichage, une injection SQL non authentifiée dans la fonction de planification, un contournement de l'authentification à double facteur, des défauts de vérification de certificats, et des problèmes d'accès non autorisé à la base de connaissances.
Deux conclusions pratiques. La première : GLPI n'a rien à faire directement exposé sur Internet. Un accès par réseau privé virtuel, ou à défaut derrière une authentification en amont, est la position par défaut. La seconde : les montées de version de sécurité s'appliquent vite, ce qui suppose de les surveiller, donc de s'abonner aux annonces du projet plutôt que de découvrir le correctif six mois plus tard.
Ce que ça demande une fois en place
La base de données est le point unique de défaillance des deux outils. Elle contient les tickets, l'inventaire, les contrats et l'historique. Sauvegarde quotidienne, restauration testée, et pour une structure qui ne peut pas se passer de son support une journée entière, une réplication MariaDB plutôt qu'une machine seule.
L'arrivée des demandes par courriel mérite une attention particulière, parce que c'est le chemin par lequel tout entre. Une boîte de réception qui se remplit sans être relevée, une authentification de messagerie mal configurée qui envoie les réponses en indésirable, et le système redevient exactement ce qu'il remplaçait : des demandes perdues. Les réponses automatiques sortantes doivent passer les contrôles d'authentification du courrier, ce qui suppose que les enregistrements SPF, DKIM et DMARC du domaine couvrent bien le serveur émetteur.
Reste la discipline, qui n'est pas technique : une demande arrivée autrement que par le canal officiel se transforme en ticket avant d'être traitée. Sans cette règle, appliquée y compris quand le directeur passe la tête par la porte, les chiffres du support ne veulent rien dire et l'imprimante de la comptable restera en panne deux jours de plus.
Ce qu'on conseille
En dessous de cinquante postes, GLPI seul, à jour, non exposé, avec l'agent d'inventaire déployé. Au-dessus, ou dès qu'il y a des clients externes, Zammad en façade et GLPI en source de vérité du parc, avec le raccordement entre les deux.
L'installation prend une journée. La reprise de l'existant, le déploiement de l'agent sur le parc et le raccordement au courrier prennent les trois semaines suivantes, et c'est ce travail-là que nous menons chez nos clients, avec l'exploitation qui va avec.
Sources
- Notes de version GLPI 11.0.9, version de sécurité publiée le 16 septembre 2026, injection SQL non authentifiée et contournement d'authentification à double facteur
- Dépôt GitHub zammad/zammad, système de support open source sous licence AGPL v3
- Documentation GLPI, inventaire automatique, agent et découverte SNMP
- Documentation Zammad, canaux d'entrée, interface de programmation et intégration
