Les 9 meilleurs systèmes de tickets open source en 2026

La partie que personne ne met dans le business case

J'ai passé les trois dernières années à développer les connecteurs qui relient eesel aux helpdesks des autres. Zendesk, Freshdesk, Jira, Slack, et une longue traîne de serveurs auto-hébergés qui n'existent que dans le VPN d'une seule entreprise. Ce travail donne une vision particulière, et un peu cynique, du mot « gratuit » : on voit exactement combien d'attention humaine absorbe une stack de support auto-hébergée, parce qu'on parle généralement à la seule personne qui la maintient en vie.

Un de nos clients l'a formulé mieux que je ne pourrais le faire. Un lead engineering d'une entreprise de matériel de distributeurs Bitcoin, qui gère une base de connaissances Confluence de plus de 300 articles, nous a expliqué pourquoi ils avaient acheté plutôt que construit :

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

C'est tout l'arbitrage en une phrase, et il s'applique aussi bien à un helpdesk qu'à une application LLM. Donc avant la liste, voici où l'argent part réellement.

Trois schémas, et chaque projet de cette liste en utilise un :

• Modules payants. FreeScout est gratuit, puis vend 71 modules officiels depuis sa page des modules. Une base de connaissances coûte 12,00 $. Les workflows coûtent 14,99 $. Les rapports coûtent 14,99 $. Les 71 modules réunis reviennent à 564,72 $, en paiement unique, et la FAQ des modules est directe : pas de remise de volume, pas d'essai, pas de remboursement.
• Contrat de support payant. Zammad offre le produit complet et vous vend un humain. Le contrat auto-hébergé le moins cher coûte 2 999 € par an pour 15 demandes de service et un délai de réponse de six heures, selon sa page tarifaire. OTOBO fait pareil, à partir de 3 900 € par an.
• Édition payante du même dépôt. Chatwoot publie une édition Community à 0 $, puis facture 19 $ ou 99 $ par agent et par mois sur ses plans auto-hébergés pour Captain AI, le SSO, les politiques de SLA et les rôles. Même base de code, dossier de licence différent.

Aucun des trois n'est malhonnête. Quelqu'un doit être payé. Mais cela veut dire que la comparaison honnête avec un système de tickets hébergé n'est jamais « 0 $ contre 19 $ par poste ».

Et avant que le reste de cet article ne chiffre le coût d'exploitation, le camp du pour mérite d'être entendu, parce que quand l'auto-hébergement fonctionne, il fonctionne vraiment bien :

"We tried fresh desk, but left disappointed. We now use Zammad, written in ruby by one of the lead devs of otrs, which used to be awesome before it went closed source (ish).

unlimited users and agents for the cost of a $5 a month VPS"

woleium, Hacker News

La tarification sans coût par poste est toute la raison d'être de cette catégorie, et à vingt agents, c'est une économie véritablement énorme. La seule question est de savoir si les heures qu'il y a derrière sont, elles aussi, gratuites.

Faites le calcul vous-même

La ligne qui décide de tout ça n'est presque jamais l'hébergement. C'est les heures. Changez les valeurs et regardez quel côté l'emporte :

Comment j'ai choisi ces neuf outils

Trois filtres, dans cet ordre.

Est-il vivant ? J'ai interrogé l'API REST de GitHub le 2026-07-31 pour chaque candidat : les métadonnées du dépôt, la dernière version, et chaque commit arrivé sur la branche par défaut au cours des 90 jours précédents. La branche par défaut compte, parce que pushed_at ment. Trudesk affiche un push en mai 2026, mais c'est une branche de réécriture ui-next abandonnée ; master n'a pas bougé depuis juillet 2024. Faveo affiche mai 2026, mais sa branche development s'est arrêtée en octobre 2024 et l'activité récente vient de Dependabot.

La version gratuite fait-elle le travail de support ? Ingestion des emails, une file d'attente, l'assignation, et une forme quelconque de SLA ou d'automatisation. Un projet qui a besoin de six modules payants avant de pouvoir envoyer une réponse type est signalé comme tel.

Quelle est vraiment la licence ? Trois des quatorze retournent NOASSERTION depuis GitHub parce qu'ils sont open-core, ce qui vaut la peine d'être su avant de construire dessus.

Une clarification honnête sur la méthode : c'est une revue de documentation et de code, pas une année à faire tourner chacun en production. J'ai lu les pages tarifaires, la doc et les dépôts de chaque éditeur, et j'ai vérifié leur historique de commits. Là où j'ai une expérience directe, c'est du côté de l'intégration, ce qui est un angle différent, et je le signalerai quand ça compte.

Les neuf en un coup d'œil

Les décomptes de commits correspondent aux commits sur la branche par défaut entre le 2026-05-02 et le 2026-07-31, d'après l'API des commits GitHub. Zammad, OTOBO et Znuny publient des tags git plutôt que des objets Release GitHub, donc tout outil qui ne lit que /releases/latest déclarera à tort ces trois projets abandonnés.

1. Zammad

Idéal pour : une équipe de support qui veut un produit complet et refuse de se faire grignoter par des feature flags.

Zammad est celui que j'installerais en premier, et la raison est structurelle plutôt que cosmétique. Le code est sous licence AGPL-3.0 et le README indique qu'il appartient à la Zammad Foundation, « indépendante des prestataires commerciaux tels que Zammad GmbH ». Une fondation détentrice des droits d'auteur est la raison concrète pour laquelle un changement de licence en catimini est plus difficile ici que sur un projet open-core à éditeur unique.

Ce qui compte le plus, c'est ce que la version gratuite inclut. La doc admin de Zammad sur la page d'abonnement indique qu'elle est « disponible uniquement dans les environnements SaaS », selon la documentation sur les abonnements. Aucun objet « plan » n'existe sur une instance auto-hébergée, donc il n'y a rien à brider. La moitié auto-hébergée du tableau tarifaire de Zammad ne contient aucune ligne de fonctionnalité, seulement des délais de réponse et des quotas de demandes de service. L'argent auto-hébergé chez Zammad achète un humain, pas un feature flag.

En pratique, cela veut dire que les SLA, les Core Workflows et la base de connaissances sont tous dans la version AGPL, sans aucune mention de plan dans la doc, alors que le tableau hébergé facture 16 € ou 25 € par agent et par mois pour les mêmes choses. La documentation des Core Workflows est l'exemple le plus clair : en hébergé, c'est une exclusivité Plus v2, et la page de doc ne mentionne aucune exigence de plan.

Avantages : rien de bridé en auto-hébergement, code détenu par une fondation, 735 commits en 90 jours, des datacenters ISO27001 si vous prenez l'option hébergée, une vraie bonne API REST.

Inconvénients : Elasticsearch est un prérequis pour le reporting, et c'est vous qui l'installez. Le contrat auto-hébergé démarre à un plancher de 2 999 €, si vous voulez un fournisseur responsable. L'IA hébergée est facturée 0,03 € par appel et n'est même pas proposée sur le plan Starter.

Tarifs : logiciel gratuit. L'hébergé coûte 7 €, 16 € ou 25 € par agent et par mois en facturation annuelle, hors TVA. Le support auto-hébergé coûte 2 999 €, 5 999 € ou 9 999 € par an.

Mon avis : si vous avez une personne compétente sous Linux et voulez un vrai helpdesk sans astérisque, c'est le bon choix. Si vous n'avez pas cette personne, la ligne à 2 999 € est ce que vous achetez réellement, et à ce stade, il faut la comparer honnêtement à un système de help desk hébergé.

2. FreeScout

Idéal pour : une petite équipe email-first prête à accepter une liste de courses plutôt qu'un abonnement.

FreeScout est ce qui ressemble le plus à un Help Scout auto-hébergé, et c'est l'outil le mieux maintenu de tout cet ensemble : 179 commits en 90 jours et seulement 31 tickets ouverts, ce qui est remarquable pour un projet à 4 450 étoiles. Il a livré la version 1.8.232 le jour même où j'ai vérifié.

Le piège, c'est le modèle des modules. L'application de base gère les boîtes mail, les conversations et les agents. Presque tout le reste s'achète dans le catalogue de modules, en paiement unique et à vie, mais sous licence pour une seule instance, donc un serveur de staging a besoin de sa propre copie de tout.

Une fois le calcul fait, un socle minimal de sept modules (base de connaissances, workflows, rapports, tags, réponses enregistrées, notes de satisfaction, champs personnalisés) revient à 70,94 $. Atteindre une parité approximative avec un helpdesk hébergé de milieu de gamme demande dix-neuf modules et 159,89 $. Ajouter cinq canaux sociaux et six modules d'authentification porte le total à 292,87 $.

Avantages : le tracker de tickets le plus propre de la catégorie, une tarification one-shot qui vieillit bien, un module API et webhooks honnête à 12,99 $, des versions hebdomadaires actives.

Inconvénients : aucune remise de volume, aucun essai, aucun remboursement, tout est dit clairement dans la FAQ des modules. La licence par instance pénalise les environnements de staging. Et il n'y a aucun module d'IA parmi les 71.

Tarifs : application gratuite, modules de 1,99 $ à 24,00 $ chacun, 564,72 $ pour l'ensemble complet.

Mon avis : le meilleur rapport qualité-prix ici si votre support est vraiment de l'email plus un centre d'aide, et si vous acceptez que le plafond soit une boîte partagée bien gérée plutôt qu'une plateforme d'automatisation. Les équipes qui le dépassent le dépassent généralement en volume de tickets, pas en fonctionnalités.

3. Chatwoot

Idéal pour : les équipes dont le premier canal est le chat en direct, pas l'email.

Chatwoot est de loin le projet le plus étoilé de la catégorie, avec 35 028 étoiles, et il le mérite en grande partie : chat sur site, email, WhatsApp, Instagram, TikTok, SMS, Telegram, Line et un canal vocal, avec 439 commits ces 90 derniers jours.

C'est aussi l'exemple d'open-core le plus clair de cette liste. Le cœur est en MIT, mais il existe un dossier enterprise/ séparé à la racine, sous des conditions différentes, ce qui explique pourquoi GitHub indique la licence comme NOASSERTION. La page des plans auto-hébergés détaille ce à quoi l'édition Community renonce : Captain AI, les appels vocaux, le branding personnalisé, la capacité d'agents, les rôles et permissions, le SSO, les politiques de SLA et le support prioritaire. C'est une longue liste pour un plan gratuit, et elle inclut les deux choses qu'une équipe en croissance demande en premier, à savoir le SSO et les SLA.

Quand on paie effectivement pour l'IA, l'unité est le crédit. L'allocation incluse est de 300, 500 ou 800 par mois selon le plan, le dépassement coûte 20 $ par 1 000 crédits, et chaque action consomme un crédit par message car une seule configuration de modèle est prise en charge, selon la doc des crédits Captain. L'édition Community n'en reçoit aucun.

Avantages : de loin la couverture de canaux la plus large ici, une vraie équipe produit derrière, un chemin de mise à niveau documenté où « vos données et paramètres sont conservés », des chemins de déploiement Docker et Helm.

Inconvénients : la version gratuite est sérieusement amputée. La production demande 4 cœurs ou plus, 8 Go de RAM ou plus, PostgreSQL 12+ et Redis 6+. Le cloud tourne sur AWS aux États-Unis, sans certification revendiquée sur la page.

Tarifs : édition Community à 0 $. Support Premium auto-hébergé à 19 $ par agent et par mois, édition Enterprise à 99 $, les deux facturés annuellement. Le cloud est à 0 $, 19 $, 39 $ ou 99 $.

Mon avis : choisissez Chatwoot quand le chat est le canal principal et que vous pouvez vous passer du SSO, ou quand vous avez le budget pour le plan à 19 $. Si vous cherchez surtout à désamorcer les questions répétitives, lisez notre avis sur les applications d'IA pour le chat en direct avant de vous engager sur un outil orienté canal.

4. OTOBO

Idéal pour : l'ITSM et la gestion de services d'entreprise, surtout si vous voulez de l'IA sans éditeur séparé.

Voici la découverte qui m'a le plus surpris. OTOBO a 332 étoiles, moins que tout autre projet de ce comparatif, et il a reçu 940 commits en 90 jours, plus que tout autre projet de ce comparatif. Les étoiles et la maintenance sont presque inversement corrélées dans cette catégorie, et OTOBO en est la preuve la plus claire.

C'est un fork GPL-3.0 de la base de code OTRS maintenu par Rother OSS GmbH en Bavière, et la page d'accueil d'OTOBO affirme sans détour qu'« OTOBO est 100 % open source et sans licence ». Le mur de logos affiche l'OTAN, Siemens, Infineon et Hyundai, ce qui n'est pas une affirmation qu'on invente.

Il embarque aussi une couche IA baptisée Rotobo, actuellement en bêta. Le guide IA d'OTOBO décrit deux fonctionnalités : la génération augmentée de récupération qui produit des brouillons de réponse à partir des données déjà présentes dans votre OTOBO, et un système de chat qui permet de piloter OTOBO en langage naturel. L'architecture est précise plutôt que vague : une stack otobo-ai-services, un package otobo-ai, un serveur MCP exposant vos données OTOBO à un modèle, et deux conteneurs supplémentaires pour l'API et une base de données vectorielle ChromaDB. L'inférence tourne sur Ollama dans un datacenter allemand, un rejet délibéré des hyperscalers américains, et le serveur IA hébergé est gratuit pendant la bêta, sans prix post-bêta publié pour l'instant.

Avantages : la base de code la plus active ici, une tarification de support publiée (rare dans cette catégorie), des agents concurrents illimités sur tous les plans, de vraies références entreprise, et le seul projet ici qui publie des planchers matériels (8 Go de RAM, 40 Go de stockage, un Xeon 3 GHz pour la production).

Inconvénients : l'IA ajoute deux conteneurs de plus par-dessus OTOBO, Daemon, MariaDB, Redis et Elasticsearch, donc ce n'est pas une installation en une commande. L'interface porte deux décennies d'héritage OTRS. Le support démarre à 3 900 € par an avec seulement dix demandes de service d'une demi-heure chacune. Et la 11.1 est actuellement en bêta, sortie le 24 juin 2026.

Tarifs : logiciel gratuit. Le support auto-hébergé coûte 3 900 €, 9 900 € ou 24 500 € par an avec des agents concurrents illimités. L'hébergement managé coûte 11 400 €, 12 900 € ou 26 000 € par an, et sur ces plans managés, les mises à niveau de version entraînent un coût supplémentaire, l'inverse de ce qui se passe sur le plan Enterprise on-premise.

Mon avis : si vos tickets sont internes et que vous alliez comparer les options d'IA pour l'ITSM de toute façon, OTOBO mérite une place en shortlist qu'il n'obtient presque jamais. Les 332 étoiles sont le chiffre le plus trompeur de toute cette catégorie.

5. GLPI

Idéal pour : les équipes IT internes qui ont besoin de l'inventaire des actifs autant que des tickets.

GLPI est une suite d'ITSM et de gestion des actifs IT où le service desk n'est qu'un module parmi cinq. Les onglets de la page d'accueil sont Helpdesk, Cloud Inventory, CMDB, Finance et Workflow, et la liste des fonctionnalités inclut la gestion antivirus, le déploiement d'applications et le MDM. Cela vous dit exactement à qui c'est destiné.

Le point de précision compte : si vos tickets viennent d'employés, le socle actifs et CMDB est la raison de choisir GLPI. Si vos tickets viennent de clients payants, ce même socle est un poids que vous portez sans l'utiliser. Chaque client cité dans son bobine de témoignages est une histoire d'IT ou d'infrastructure, ce qui renforce cette lecture.

414 commits en 90 jours et la version 11.0.8 en juin 2026 le placent fermement dans la colonne des projets en bonne santé. Il fait aussi tourner une page de statut de service publique pour le produit hébergé, ce qui est une vraie maturité opérationnelle pour un projet open source.

Avantages : l'histoire actifs et CMDB la plus poussée ici, une vraie adoption entreprise en Europe, un réseau de partenaires Platinum pour l'implémentation, un développement actif.

Inconvénients : la page d'accueil ne mentionne jamais sa licence, sa version ni son dépôt, et chaque bouton mène vers le cloud GLPI Network plutôt que vers la voie de l'auto-hébergement. Il y a un logo « GLPI AI » dans la bande d'intégrations sans aucune description de ce qu'il fait, je ne le qualifierai donc pas.

Tarifs : auto-hébergé gratuit. GLPI Network a une page tarifaire séparée, avec 45 jours gratuits annoncés sur la page d'accueil.

Mon avis : la bonne réponse pour un helpdesk IT interne avec du matériel à gérer, et la mauvaise réponse pour le support orienté client. Ne laissez pas le module de tickets vous convaincre si vous n'avez aucun actif à suivre.

6. osTicket

Idéal pour : un formulaire de ticket ennuyeux et éprouvé qui fonctionne de la même façon depuis quinze ans.

osTicket est le projet auquel tout le monde pense en disant « ticketing open source ». Il est en GPL-2.0, il a livré les versions v1.17.8 et v1.18.4 le 17 juin 2026, et il fait toujours exactement ce qu'il promet : champs personnalisés, formulaires personnalisés, filtres de tickets, réponses types, un panneau agent.

Les chiffres autour sont moins flatteurs. 29 commits en 90 jours contre 1 200 tickets ouverts, c'est le pire ratio issues/commits de toute la catégorie. La page de téléchargement spécifie encore PHP 8.0.x et MySQL 5.5. Et les captures d'écran sur la page des fonctionnalités sont servies depuis wp-content/uploads/2021/01/, ce qui veut dire que l'imagerie du produit n'a pas été rafraîchie depuis janvier 2021.

Il y a aussi un problème d'URL à connaître avant de citer quoi que ce soit. osticket.com/pricing renvoie une 404, et osticket.com/cloud-hosting aussi. L'offre commerciale a migré vers une marque séparée, SupportSystem, à 12 $, 16 $ ou 24 $ par agent et par mois. Les deux seules fonctionnalités bridées par plan là-bas sont l'authentification SAML et le journal d'audit du help desk, toutes deux réservées au Premium, donc une exigence de SSO double votre prix par poste pour une seule case à cocher.

Avantages : vraiment éprouvé, une base installée énorme, aucun bridage de fonctionnalité sur la version auto-hébergée, un essai cloud de 30 jours sans carte requise.

Inconvénients : 1 200 tickets ouverts, des exigences techniques datées, une imagerie produit figée en 2021, aucune IA d'aucune sorte, et une limite de 2 Mo par pièce jointe sur le plan cloud le moins cher, où les pièces jointes trop lourdes sont silencieusement abandonnées plutôt que rejetées.

Tarifs : auto-hébergé gratuit. Le cloud SupportSystem coûte 12 $, 16 $ ou 24 $ par agent et par mois, sans remise annuelle publiée.

Mon avis : toujours correct si tout ce qu'il vous faut est un formulaire qui transforme l'email en file numérotée. Si quelqu'un dans l'équipe prononce les mots « automatisation » ou « IA », c'est le moment de le comparer à un système de tickets automatisé moderne plutôt que de planifier autour.

7. Znuny

Idéal pour : les organisations déjà installées sur OTRS Community Edition qui ont besoin de continuité.

Znuny est l'autre fork d'OTRS Community Edition, en GPL-3.0, sur znuny/Znuny avec un Z majuscule qui fait trébucher la moitié des outils qui essaient de l'indexer. 79 commits en 90 jours et le tag rel-7_3_5 en juillet 2026 le placent confortablement dans la colonne des projets maintenus, quoiqu'à environ un douzième du rythme d'OTOBO.

Toute sa proposition de valeur est la filiation, et le projet Znuny le dit sans détour : Znuny est une continuation d'OTRS Community Edition, version 6.0.30, « déclarée en fin de vie (EOL) fin décembre 2020 ». Si votre organisation a des années de process OTRS, de modules personnalisés et d'agents formés, c'est la voie qui ne demande de réapprendre à personne.

La surprise ici, c'est Znuny-LLM, l'implémentation d'IA la plus complète de toute cette liste, et elle n'est presque jamais mentionnée nulle part. C'est du « apportez votre propre modèle » avec Ollama, OpenAI, Azure ou n'importe quel endpoint compatible OpenAI, et cela embarque cinq fonctionnalités : des résumés de tickets par langue, du routage et de la classification où les pouces levés/baissés des agents reviennent comme exemples few-shot, l'extraction en langage naturel vers des champs dynamiques, des recommandations de modèles de réponse, et le matching FAQ avec des brouillons de connaissance. Ils publient aussi une contrainte honnête que la plupart des éditeurs enterreraient : les modèles de raisonnement ne sont pas pris en charge, parce que les variantes de type « thinking » produisent une sortie vide ou mal formée.

Avantages : une vraie continuité OTRS, une véritable couche IA « apportez votre propre modèle » sans surcoût, GPL-3.0 sans scission open-core, aucun bridage de fonctionnalité, et la 7.3.5 a corrigé deux CVE en juillet 2026.

Inconvénients : il ne publie aucune Release GitHub, seulement des tags, donc les vérifications automatiques de fraîcheur le signalent à tort. Il ne publie aucune exigence matérielle. Le plan d'hébergement Silver comporte des frais de mise en place d'environ 1 595, que les plans Gold et Platinum n'imposent pas.

Tarifs : logiciel gratuit. Le support coûte 4 499 $, 9 999 $ ou 28 900 $ par an, mesuré sur les demandes de service. L'hébergement coûte 799 $, 1 419 $ ou 3 169 $ par mois payés annuellement, et inclut le plan de support correspondant.

Mon avis : choisissez Znuny pour la continuité et l'IA, OTOBO pour l'élan brut. Si vous voulez une couche IA que vous contrôlez entièrement, pointée sur votre propre serveur Ollama, Znuny-LLM est la chose la plus crédible de ce comparatif, et presque personne ne sait qu'elle existe.

8. Request Tracker

Idéal pour : les équipes d'ingénierie, d'infrastructure, de sécurité et universitaires.

Request Tracker est le projet le plus ancien ici et livre encore environ 1,2 commit par jour, avec 108 ces 90 derniers jours et la version rt-6.0.3 en juin 2026. C'est le seul projet de cette liste sous licence GPL-2.0-only, le README disant explicitement « Version 2 » plutôt que le classique « ou ultérieure », et il a un terrain culturel bien précis : NOC, cellules abus, équipes sécurité et .edu. À noter si vous mettez à jour de vieux favoris, bestpractical.com/request-tracker redirige maintenant vers requesttracker.com, même si la doc est restée à sa place.

Il n'essaie pas d'être un service de support client, et vous ne devriez pas lui demander de l'être. Pas de widget de chat, pas de canal social, pas de tableau de bord CSAT. Ce qu'il a, c'est un modèle de files, un système de permissions et une couche de scripting qui survit au contact de workflows vraiment compliqués, ce qui explique pourquoi il a survécu à presque tout ce qui datait de son époque.

Il existe une extension IA sur CPAN plutôt que dans le cœur, et une seule fonctionnalité est documentée nommément : un assistant de création de file qui prend une description en langage naturel et construit le workflow, les champs personnalisés, les groupes et les droits, avec une étape de relecture avant toute application. L'IA n'apparaît nulle part dans la liste des fonctionnalités principales de RT, traitez-la donc comme un bonus plutôt qu'une raison de le choisir.

Avantages : trois décennies de stabilité, exceptionnel sur les règles de files et de permissions complexes, un tracker petit et propre avec 82 tickets ouverts, un vrai support commercial, plus des remises de 20 % académiques et 10 % associatives.

Inconvénients : l'interface est fonctionnelle plutôt qu'agréable, le public est technique, et Perl est une vraie contrainte de recrutement en 2026. Cloud RT lie deux compteurs à la fois : un prix par utilisateur et un plafond mensuel de tickets de 250, 1 000 ou 5 000 selon le plan. Le plan on-premise à 450 $ par mois inclut exactement une demande de support sous SLA par trimestre, soit quatre par an.

Tarifs : logiciel gratuit. Cloud RT coûte 15 $, 29 $, 39 $ ou 99 $ par utilisateur et par mois facturés annuellement, chacun avec son propre plafond de tickets. Le support on-premise est gratuit, à 450 $ par mois, 1 650 $ par mois, ou sur devis.

Mon avis : si vos « clients » sont d'autres ingénieurs, c'est un meilleur choix que tout le reste de cette liste. S'il s'agit de consommateurs, c'est le mauvais outil, et aucun habillage graphique n'y changera rien.

9. UVdesk

Idéal pour : le support ecommerce, si le projet redémarre.

J'inclus UVdesk parce qu'il convient vraiment à l'ecommerce, que son édition communautaire Symfony est une base raisonnable, et qu'il figure sur toutes les listes. Mais le signal de maintenance doit passer avant tout : zéro commit sur la branche par défaut ces 90 derniers jours, et le dernier commit, quel qu'il soit, date du 1er octobre 2025, il y a environ dix mois. La dernière version, v1.1.8, date de septembre 2025.

Il y a une deuxième bizarrerie. Le dépôt affiche 19 471 étoiles contre 47 observateurs et 564 forks. Tous les autres projets de cet ensemble ont des ratios d'un ordre de grandeur différent, et les étoiles sont la seule métrique GitHub qui peut s'acheter. Prenez ce chiffre avec précaution.

La tarification a son propre piège. Le tarif SaaS annoncé est de 8 $ ou 15 $ par agent et par mois, mais les deux plans payants imposent un minimum de 2 agents, donc l'entrée de gamme réelle est de 22 $ par mois, pas 8 $. Le plan gratuit est le squelette communautaire que vous auto-hébergez, et la page tarifaire renvoie les plans gratuit et payant vers deux listes de fonctionnalités différentes, ce qui est le propre signal d'UVdesk que les deux ne sont pas le même produit.

Avantages : conçu pour les workflows ecommerce, agents illimités sur l'édition communautaire auto-hébergée, OSL-3.0.

Inconvénients : dix mois sans commit, un nombre d'étoiles décalé par rapport à tous les autres signaux d'engagement, un minimum de 2 agents qui double le prix annoncé, et une séparation de fonctionnalités gratuit-contre-payant que l'éditeur documente sur des pages distinctes.

Tarifs : édition communautaire gratuite. Pro à 8 $ et Enterprise à 15 $ par agent et par mois en facturation annuelle, ou 11 $ et 18 $ au mois, les deux avec un plancher de 2 agents.

Mon avis : vérifiez le dépôt vous-même avant de vous engager sur quoi que ce soit. S'il a bougé au moment où vous lisez ceci, c'est une option ecommerce raisonnable. Si non, traitez-le comme je traite les quatre de la section suivante.

Les quatre qui ont arrêté de livrer, et qui trônent encore en tête des listes

C'est la partie que je veux le plus que les gens retiennent, parce qu'elle est vérifiable en environ quatre-vingt-dix secondes et que presque personne ne le fait.

Le rythme des versions dans cette catégorie est bimodal, sans rien au milieu. Chaque projet a soit livré au cours des dix dernières semaines, soit n'a rien livré depuis plus de vingt mois. Il n'y a pas de déclin progressif, pas de « calme mais ça va ». Un projet est soit travaillé ce trimestre, soit arrêté depuis deux ans.

• Peppermint — le dépôt est archivé, donc en lecture seule et incapable d'accepter des issues ou des pull requests. Sa dernière version datait de novembre 2024. Et peppermint.sh ne se résout plus du tout : le DNS renvoie SERVFAIL, et le sous-domaine de doc échoue de la même façon. Le domaine est encore enregistré jusqu'en 2028, donc c'est une délégation retirée plutôt qu'une facture impayée. Il porte encore 3 157 étoiles et apparaît toujours dans les comparatifs 2026.
• Helpy — dernière version en février 2020, il y a six ans et cinq mois. La branche master a bougé pour la dernière fois en octobre 2021. Il y a 230 tickets ouverts et plus de 100 branches Dependabot non fusionnées, ce qui est la forme typique d'un dépôt que personne ne regarde plus.
• Trudesk — trudesk.io est toujours en ligne et renvoie un HTTP 200, et le site de doc est actif, ce qui est exactement ce qui trompe les gens sur ce projet. Mais master a bougé pour la dernière fois le 24 juillet 2024. La date de push de 2026 appartient à une branche de réécriture ui-next qui n'a jamais été fusionnée.
• Faveo — la branche par défaut development a bougé pour la dernière fois le 3 octobre 2024, et la dernière version taguée datait d'octobre 2023. L'activité de 2026 est du Dependabot et du StyleCI. Deux des trois chemins de dépôt que les listicles citent pour Faveo renvoient désormais une 404 ; celui qui est actif est faveosuite/faveo-helpdesk.

La vérification prend deux clics. Ouvrez le dépôt, passez sur la branche par défaut, regardez la date du dernier commit en haut. Ne regardez pas les étoiles, et ne faites pas confiance au « dernière mise à jour » d'une page d'agrégateur.

La taxe de l'auto-hébergement, en heures

L'hébergement n'est pas la partie coûteuse. La partie coûteuse, c'est qu'un système de support est un système d'email, et l'email ne pardonne rien.

Cet écran, ce sont les paramètres de connexion de FreeScout, et c'est le visage honnête de l'auto-hébergement. SPF, PTR et DMARC doivent chacun être corrects, sinon vos réponses atterrissent en spam et vous l'apprenez par un client en colère plutôt que par un moniteur. Choisir mail() de PHP plutôt que SMTP parce que ça marche en test est une erreur qui se révèle trois semaines plus tard sous forme de falaise de délivrabilité.

Le mode de défaillance est pire que lent, parce qu'il est silencieux. Un sysadmin sur Reddit a raconté la version de cette histoire qui m'est restée en tête :

"I used zammad with the Microsoft sso for a while, worked well. Have since moved to cloud platform for tickets - the realization that our ability for users to submit tickets outside of email when vpn or other network services went down created more work than self hosting was worth.

Also saw a previous employer miss an email about a mass phishing attempt because the helpdesk server had stopped consuming emails. Wasn't worth the risk."

u/unofficialtech, Reddit

Un helpdesk qui arrête discrètement d'ingérer les emails ne déclenche aucune alerte. Il devient simplement plus silencieux, et le silence ressemble à une bonne journée jusqu'à ce qu'on découvre que c'était un incident de sécurité manqué.

L'autre moitié du problème de l'email, c'est que les éditeurs de plateformes continuent de bouger sous vos pieds. Quand Microsoft a retiré l'authentification basique sur IMAP et POP, ça a cassé les helpdesks auto-hébergés en masse, et ça coûte encore du temps aux gens en 2026 :

"Actually fighting [f] to get mail in/out working with freescout right now - and having had learn more than I care to about o365 and PowerShell etc"

e12e, Hacker News

« Plus que je ne voudrais » est l'heure non facturée, et personne ne la met dans le tableau.

Ensuite il y a les mises à jour. L'inscription à la mailing-list d'osTicket existe, selon ses propres mots, pour être informé des mises à jour disponibles et des correctifs de sécurité quand ils sortent. C'est la taxe de l'auto-hébergement énoncée par l'éditeur lui-même : le patching, c'est votre travail, selon votre calendrier, pour toujours. Zammad n'effectue les mises à jour de patch, de version mineure et de sécurité pour vous que sur son plan le plus haut à 9 999 €. OTOBO installe les correctifs de sécurité à distance à partir de son plan à 9 900 €, et ne fait les mises à niveau de version pour vous qu'à 24 500 €.

Remarquez ce que ces deux seuils de prix disent vraiment. Les éditeurs ont mis un chiffre sur le travail de maintenance, et ce chiffre est à cinq chiffres par an. Quand un business case suppose que ce travail est gratuit parce qu'un volontaire l'absorbera, les propres grilles tarifaires des éditeurs sont la preuve du contraire.

Il y a aussi une question d'échelle, et le propriétaire d'un MSP l'a formulé plus crûment que je n'oserais, dans un fil sur l'abandon d'osTicket :

"Your management is just used to paying nothing for open-source, but you simply can't run an MSP that size without a PSA."

u/CK1026, r/msp

Rien de tout cela n'est un argument contre l'auto-hébergement. C'est un argument pour mettre les heures dans le tableau. Si votre réponse est « on a une personne système et ça lui plaît », l'auto-hébergement est une vraie bonne affaire, et le calculateur ci-dessus vous le montrera. Si la réponse honnête est « personne n'en est responsable », un helpdesk hébergé plus une couche d'automatisation coûtera moins cher que la panne.

Où se trouve vraiment l'IA

Passons à la partie gênante. La plupart des équipes lisent une liste comme celle-ci parce que le volume de tickets grossit plus vite que les effectifs, ce qui est un problème d'automatisation plutôt qu'un problème de ticketing.

Les quatre projets les plus recommandés, ci-dessus, sont les quatre qui ont le moins à offrir ici. Le tableau complet sur les neuf outils :

• Znuny a l'implémentation la plus complète, et elle est gratuite et « apportez votre propre modèle ». OTOBO suit de près avec Rotobo, en bêta. Les deux sont des forks allemands d'OTRS que personne ne place en tête de liste.
• Zammad facture l'IA 0,03 € par appel, et seulement sur les plans Professional v2 et Plus v2. Le plan Starter ne liste aucune option d'IA. Voici ce qu'achète un de ces appels :

• Chatwoot a un bon produit IA avec Captain, et n'accorde aucun crédit à l'édition Community. Le dépassement coûte 20 $ par 1 000, un crédit par message.
• FreeScout n'a aucun module d'IA parmi 71. Les produits les plus proches sont un traducteur de tickets à 6,99 $ et un filtre anti-spam à 5,99 $.
• Request Tracker a une extension CPAN qui construit des files à partir d'une description. Utile, mais c'est un outil de mise en place, pas une couche de résolution.
• osTicket, GLPI et UVdesk ne publient rien qu'on puisse appeler une couche d'IA. GLPI affiche un logo « GLPI AI » sans description associée, ce qui n'est pas suffisant pour le qualifier.

Donc pour six des neuf outils, ajouter l'IA veut dire ajouter une couche séparée par-dessus. C'est normal, et généralement moins coûteux que de migrer, parce que le système de tickets n'est rarement ce qui est cassé. Un head of engineering qui fait tourner Zammad a décrit l'écart réel :

"It's not as polished as products like ZenDesk. In fact, it's not really an awesome experience. Some things you'd think ought to be standard are either not implemented or not implemented well or a bit clunky. For instance, it's laborious to try and find agent performance metrics. Really, it's more a system for tracking your currently open tickets but without a lot of richness in managing performance or reviewing history, finding root causes, identifying trends, etc."

David W., Head of Engineering, G2

C'est la forme honnête des choses. Ces outils suivent les tickets très bien. Ils ne les lisent pas.

Cette couche, c'est la pièce sur laquelle je travaille. Le schéma qui tient la route est le schéma ennuyeux : se connecter au helpdesk et aux sources de connaissances, apprendre de l'historique des tickets, puis démarrer étroit. Rédiger les réponses en notes internes d'abord, pour qu'un humain voie chaque réponse avant qu'un client ne la voie. Élargir la portée seulement là où les brouillons sont constamment justes. Un client a décrit l'exigence précisément lors d'un appel :

"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

C'est le bon instinct, et c'est pourquoi le routage basé sur la confiance compte plus que le taux de résolution brut. Une IA qui répond à tout avec 70 % de justesse est pire qu'une IA qui répond à 30 % des tickets avec 98 % de justesse et transfère le reste proprement. Nous avons vu des bots à l'air confiant donner discrètement de mauvaises réponses, c'est pourquoi chaque déploiement que nous lançons est maintenant simulé sur des tickets historiques avant de toucher une file en production.

Essayez eesel sur le système de tickets que vous avez déjà

Si vous êtes arrivé jusqu'ici, vous êtes probablement en train de peser « quel helpdesk open source » alors que la vraie question est « comment arrêter de retaper les quarante mêmes réponses ».

eesel est la couche IA, pas un système de tickets supplémentaire. Elle se connecte à votre helpdesk et à vos sources de connaissances, apprend de vos tickets passés, et commence par rédiger les réponses en notes internes pour qu'un humain approuve tout avant qu'un client ne le voie. Vous gardez la file, l'historique et les workflows que vous avez déjà construits. Une équipe analytics d'une entreprise de la gig economy sur Zendesk a obtenu 73 % des demandes de niveau 1 résolues dès le premier mois, ce résultat ayant été atteint pendant un essai de sept jours.

La limite honnête : si vous êtes auto-hébergé derrière un VPN sans accès API sortant, nous ne sommes pas la bonne réponse aujourd'hui, et je préfère le dire plutôt que de vous vendre un projet. Mais si votre système a une API et que quelqu'un dans votre équipe est fatigué du copier-coller, démarrez gratuitement et pointez-le sur une semaine de vrais tickets. C'est suffisant pour savoir si les brouillons sont bons.