NexTool Solutions

GLPI open source n'a pas d'abonnement mensuel, mais « sans licence » est très loin de « sans coût ». Comparer seulement le prix affiché de GLPI auto-hébergé à celui d'un ServiceNow se trompe dans les deux sens : cela sous-estime ce que l'auto-hébergé consomme en exploitation et surestime ce que le SaaS livre d'origine. Ce comparatif aligne les quatre modèles que nous déployons le plus - GLPI auto-hébergé, GLPI Cloud, ServiceNow et Jira Service Management - sur l'axe qui pilote vraiment le TCO : l'unité de facturation et le travail d'exploitation.

Les quatre modèles, en une phrase chacun

• GLPI auto-hébergé (open source) : logiciel gratuit, sans limite d'utilisateurs ; vous payez l'infrastructure et la main-d'œuvre.
• GLPI Cloud (Teclib) : le même GLPI, hébergé et maintenu par Teclib, avec un abonnement par technicien.
• ServiceNow : plateforme ITSM enterprise, licence par agent sur devis, orientée automatisation et gouvernance à grande échelle.
• Jira Service Management : l'ITSM d'Atlassian, abonnement par agent en formules, solide pour ceux qui vivent déjà dans l'écosystème Jira/Confluence.

Les trois payants facturent par agent ou technicien : le coût croît de façon à peu près linéaire avec la taille de l'équipe de support. L'auto-hébergé inverse la logique - le logiciel est fixé à zéro et le coût vient de l'exploitation. C'est cette différence de nature, et non le prix d'un mois isolé, qui décide lequel est le moins cher sur un horizon de trois ans.

Comparatif direct

Combien d'« agents » vous payez vraiment

Voici le piège qui n'apparaît qu'au moment de la facture : dans les modèles par agent, ce qui coûte, c'est l'utilisateur avec l'interface technique (centrale), pas le demandeur qui ouvre seulement des tickets en libre-service. Les demandeurs sont généralement illimités et gratuits dans les trois. Autrement dit, le nombre qui définit votre facture n'est pas « combien de personnes utilisent GLPI » mais « combien ont un profil de technicien ».

En auto-hébergé, ce nombre est invisible - personne ne le facture, alors les organisations distribuent le profil central largement : le coordinateur qui veut juste voir un tableau de bord, le manager qui « doit parfois regarder la file », le stagiaire qui a clôturé deux tickets l'an dernier. Lors de la migration vers un SaaS par agent, chacun d'eux devient une ligne sur la facture. Avant de demander un devis, lancez cette requête sur la base de votre GLPI pour connaître le nombre réel :

-- Combien d'« agents » paieriez-vous dans un SaaS à l'agent ?
-- Agent facturable = utilisateur avec un profil à interface centrale (technicien),
-- pas l'utilisateur en libre-service (helpdesk), généralement illimité.
SELECT COUNT(DISTINCT pu.users_id) AS agents_facturables
FROM glpi_profiles_users pu
JOIN glpi_profiles p ON p.id = pu.profiles_id
JOIN glpi_users     u ON u.id = pu.users_id
WHERE p.interface = 'central'   -- interface centrale (exclut le helpdesk)
  AND u.is_active  = 1
  AND u.is_deleted = 0;

Nous avons vu ce nombre revenir 40% au-dessus de ce que le client estimait « de tête ». Avant de comparer les prix avec le SaaS, faites le ménage : rétrogradez en libre-service ceux qui ne traitent pas réellement de tickets. Cela réduit la facture future et, en prime, nettoie les rapports de productivité au sein même de GLPI.

Le coût caché qui n'entre jamais dans le tableur

Dans la maintenance de parcs GLPI pour des clients, l'élément qui fait le plus exploser le TCO de l'auto-hébergé n'apparaît dans aucun tableau : c'est la dette de mise à jour. Le client monte GLPI, ça marche, et personne n'y touche pendant deux ans. Quand il a enfin besoin d'une nouvelle fonction ou d'un plugin compatible, il découvre que passer d'une 9.5 à une 11 n'est pas « cliquer sur mettre à jour » - c'est migrer le schéma, revoir les plugins cassés et tester en préproduction. Ce qui était 2h/mois de maintenance est devenu un projet. L'erreur courante est de budgéter l'auto-hébergé seulement au VPS et de traiter la mise à jour comme un événement rare ; elle est récurrente et exige une fenêtre, une sauvegarde testée et un environnement de test.

Et il y a l'autre coût que personne ne compte : la sauvegarde qui existe mais n'a jamais été restaurée. En auto-hébergé, le PRA est entièrement votre responsabilité - et un dump que personne n'a testé est une sauvegarde que vous n'avez pas. Le minimum viable est un dump quotidien de la base et des fichiers, avec vérification périodique :

# /etc/cron.d/glpi-backup - sauvegarde quotidienne de la base + fichiers de GLPI.
# En auto-hébergé, la sauvegarde et le PRA sont 100% à vous ; un dump jamais restauré ne compte pas.
30 2 * * *  root  mysqldump --single-transaction glpi | gzip > /backup/glpi-$(date +\%F).sql.gz
45 2 * * *  root  tar czf /backup/glpi-files-$(date +\%F).tar.gz /var/www/glpi/files
# Conservez une copie HORS du serveur et testez la restauration au moins une fois par trimestre.

Sur GLPI Cloud, ServiceNow et Jira SM, la mise à jour, la sauvegarde et la disponibilité sont incluses dans le prix de l'abonnement - c'est exactement ce que vous achetez en payant par agent. La bonne question n'est pas « lequel est le moins cher » mais « ce travail d'exploitation reste-t-il dans mon équipe ou est-il externalisé dans l'abonnement ? ».

Verdict par scénario

• Choisissez GLPI auto-hébergé quand vous avez (ou recrutez) quelqu'un pour exploiter Linux, la base et les sauvegardes, vous tenez à la souveraineté des données et vous voulez un plafond de coût prévisible même en doublant l'équipe d'agents. Il est imbattable en coût par agent à mesure que l'équipe grandit ; si c'est votre voie, commencez par l'installation via Docker.
• Choisissez GLPI Cloud quand vous voulez le même GLPI - même base, mêmes concepts, mêmes plugins compatibles - sans maintenir d'infrastructure, et l'équipe de techniciens est assez petite pour que l'abonnement reste inférieur à un sysadmin dédié.
• Choisissez ServiceNow quand le vrai besoin est l'automatisation et la gouvernance enterprise (flux complexes, intégrations d'entreprise, conformité) et qu'il y a un budget pour le palier le plus élevé du marché. Prendre ServiceNow juste pour ouvrir des tickets, c'est payer un avion pour traverser la rue.
• Choisissez Jira Service Management quand l'entreprise tourne déjà sur Jira/Confluence et veut l'ITSM collé à cet écosystème, en acceptant la facturation par agent et les limites d'inventaire/CMDB face à GLPI.

Coût et effort, avec des fourchettes honnêtes

L'axe de la décision n'est pas la licence - c'est où va le travail d'exploitation. En auto-hébergé, la dépense en argent est faible (un VPS de quelques dizaines à quelques centaines par mois, selon l'échelle), mais elle exige des heures techniques récurrentes : un déploiement bien fait tient rarement en moins de quelques jours de travail, et la maintenance demande une fenêtre mensuelle pour la mise à jour et la vérification de sauvegarde. Dans les modèles par agent, la dépense est plus élevée et croît linéairement avec l'équipe, mais les heures d'exploitation d'infrastructure tendent vers zéro. Le calcul à trois ans favorise généralement l'auto-hébergé plus l'équipe d'agents est grande et plus l'heure technique disponible est bon marché ; il favorise le SaaS quand l'équipe est réduite et qu'il n'y a personne pour exploiter l'infrastructure. Ne fixez pas un chiffre de TCO fermé avant d'avoir le total d'agents facturables et le coût réel de votre heure technique - sans ces deux données, tout comparatif est une supposition.

Chez NexTool, nous déployons et maintenons les quatre scénarios chez des clients - du GLPI auto-hébergé allégé au migré vers Cloud - et la décision la plus rentable est toujours la même : dimensionner le coût selon la bonne unité (agents facturables) et selon le travail d'exploitation que votre équipe peut absorber. Si vous voulez un TCO honnête pour votre cas, sans deviner un prix affiché, notre conseil construit ce comparatif avec vos chiffres.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.