Comparaison des systèmes de tickets Znuny et OTOBO
Znuny et OTOBO sont des forks de l'ancienne édition communautaire OTRS, désormais abandonnée, et se sont développés en tant que systèmes de tickets open source indépendants. Ces deux solutions comptent parmi les forks OTRS les plus connus et offrent de nombreuses fonctionnalités pour gérer efficacement les demandes de support client. Toutefois, elles diffèrent sur plusieurs points clés. Dans cette comparaison Znuny contre OTOBO, nous examinons leurs similitudes et différences – des fonctionnalités, en passant par la prise en charge Docker, l’API REST, jusqu’à l’intelligence artificielle (IA), l’installation et les options de démonstration.
OTOBO : un système de tickets open source moderne
OTOBO s’appuie sur OTRS 6 et l’enrichit avec des fonctionnalités modernes et une expérience utilisateur améliorée. Il s’agit d’un système d’aide en ligne (Helpdesk) basé sur le web, conçu pour gérer les demandes clients. Les principales caractéristiques d’OTOBO incluent :
- Portail client moderne : interface utilisateur entièrement repensée, conviviale et optimisée pour les appareils mobiles.
- Formulaires optimisés : création simplifiée de tickets grâce à des formulaires et champs configurables.
- Fonctionnalités de sécurité étendues : par exemple, politiques de mot de passe, protection contre les attaques par force brute, authentification à deux facteurs (2FA) et droits d’accès finement granulaires.
- Migration facile depuis OTRS : des scripts intégrés permettent une transition fluide depuis une installation OTRS 6 vers OTOBO.
- Recherche en direct avec Elasticsearch : résultats de recherche plus rapides et précis grâce à l’intégration d’Elasticsearch pour la recherche plein texte.
- Intégration avec OpenStreetMap : les données géographiques peuvent être affichées directement dans le ticket (utile par exemple pour les tickets liés à un lieu).
- Options d’escalade flexibles : règles d’escalade étendues pour un meilleur contrôle du processus d’escalade.
- Conformité RGPD : des fonctionnalités pour respecter le RGPD sont intégrées (par exemple, anonymisation des tickets).
- Performances améliorées : base de code revue et mise en cache (Redis) pour des temps de réponse plus rapides.
- Classification des tickets assistée par IA : un plugin IA optionnel est disponible, utilisant le machine learning pour classer automatiquement les tickets et définir leurs priorités.
Znuny : l’évolution directe du projet OTRS
Znuny est la suite directe du projet OTRS par la communauté (maintenu par Znuny GmbH), avec un accent mis sur la stabilité à long terme, la compatibilité et l’ajout sélectif de nouvelles fonctionnalités. Parmi les fonctionnalités et caractéristiques notables de Znuny :
- Évolution continue : Znuny reçoit des mises à jour régulières avec correctifs et nouvelles fonctionnalités. Par exemple, des versions récentes ont ajouté des filtres de calendrier, le support OAuth2 pour les services externes (Invoker), les mentions d’utilisateurs (@-mentions dans les notes de ticket) et des extraits de texte prédéfinis.
- Options de sécurité et conformité : prise en charge des groupes LDAP imbriqués (Nested Groups) pour la gestion des droits, amélioration du traitement S/MIME (gestion des clés) et autres correctifs de sécurité pour un système plus sûr.
- Personnalisation flexible : grâce à un système de modules et aux services web GenericInterface, Znuny peut être étendu et intégré à d’autres systèmes. Les filtres et ACL permettent une configuration personnalisée de l’interface et des processus.
- Traçabilité complète : toutes les modifications de tickets sont enregistrées de manière exhaustive, permettant de retracer chaque action à tout moment (essentiel par exemple pour les processus auditables).
- Composants ITIL disponibles : Znuny propose des modules optionnels comme le module ITSM (incluant une CMDB pour la gestion des actifs) et un module FAQ, disponibles gratuitement, offrant des fonctionnalités similaires à l’ancienne suite OTRS::ITSM.
- Soutien actif de la communauté : en tant que fork officiel de la communauté OTRS, Znuny dispose d’un forum actif et de contributions communautaires. De nombreuses fonctionnalités autrefois payantes dans OTRS ont été reprises et maintenues dans Znuny par la communauté.
Versions et développements récents
Les deux projets ont continué à évoluer régulièrement depuis leur séparation d’avec OTRS :
OTOBO version 10 (publiée pour la première fois en 2020) constitue la base des installations actuelles. Cette version a introduit une interface web modernisée et de nombreuses améliorations mentionnées ci-dessus. Depuis, des mises à jour correctives régulières (ex. 10.0.17, 10.0.18, etc.) apportent des correctifs et de petites fonctionnalités. OTOBO version 11 est déjà annoncée, avec de nouvelles optimisations et fonctionnalités (Softoft a publié des informations préliminaires). Les développeurs d’OTOBO (Rother OSS GmbH) misent sur une feuille de route innovante – par exemple, l’intégration de l’IA a été proposée tôt sous forme de module optionnel.
Znuny a repris la base de code OTRS 6 et l’a d’abord maintenue sous le nom Znuny 6 (y compris Znuny LTS 6.5, une version à support long terme destinée aux entreprises souhaitant une stabilité maximale). En mars 2023 est sortie Znuny 7.0, une avancée majeure : l’interface client a été redessinée à 70 % (Bienvenue Znuny 7), pour être plus moderne et conviviale, tandis que l’interface agent a été modernisée avec prudence, tout en restant familière (Bienvenue Znuny 7). Actuellement (début 2025), Znuny 7.1 est la version stable principale, et Znuny 7.2 est prévu pour le troisième trimestre 2025 (Feuille de route). Znuny 7 inclut également des modernisations techniques « sous le capot », facilitant les adaptations et extensions futures (Bienvenue Znuny 7). À noter : les versions Znuny 7.x sont des versions fonctionnelles nécessitant une maintenance active de l’utilisateur, tandis que Znuny LTS 6.5 continuera à recevoir des correctifs de sécurité jusqu’à fin 2025 au moins (Feuille de route). Ainsi, Znuny propose à la fois une branche LTS conservatrice et une branche de versions progressives.
Comparaison des fonctionnalités
Voici un tableau comparatif des principales caractéristiques d’OTOBO et de Znuny :
| Caractéristique | OTOBO | Znuny |
|---|---|---|
| Base | Fork de l’édition communautaire OTRS 6 | Fork de l’édition communautaire OTRS 6 |
| Développeur | Rother OSS GmbH (initiateur et principal développeur) | Znuny GmbH (dirigée par d’anciens développeurs de la communauté OTRS) |
| Licence | 100 % open source (GNU GPL v3) – aucun module propriétaire | 100 % open source (GNU GPL v3) – entièrement gratuit |
| Support Docker | Oui – images Docker officielles et modèles Docker-Compose disponibles pour une installation rapide | Aucune image officielle (installation classique sur serveur Linux ou via conteneurs Docker communautaires non officiels) |
| Portail client | Portail client entièrement repensé (interface moderne, design responsive, utilisation intuitive) | Portail client hérité d’OTRS 6 avec améliorations ; partiellement redessiné dans Znuny 7, mais pas entièrement reconstruit comme chez OTOBO |
| Elasticsearch | Intégré avec options de configuration étendues (configuration d’index complexe, recherche en direct) | Intégré comme moteur de recherche optionnel avec les fonctionnalités standards d’OTRS (indexation des champs de base du ticket) |
| OAuth2 pour les e-mails | Oui – support OAuth2 pour IMAP/POP3 depuis OTOBO 10.0.11 (ex. pour Office 365 sans authentification basique) | Actuellement limité – le support OAuth2 direct pour les comptes e-mail devrait arriver avec Znuny 7.2 via l’API Microsoft Graph (Feuille de route) (jusque-là, des solutions de contournement sont nécessaires) |
| Outils de migration | Migration d’OTRS 6 vers OTOBO prise en charge (scripts et guides disponibles) | Migration d’OTRS 6 vers Znuny possible sans heurts ; une migration d’une base de données OTOBO existante vers Znuny a également été réalisée avec succès par la communauté (avec étapes de conversion) |
| Communauté | Communauté active, forum et contributions régulières (encore plus petite que celle de Znuny, mais en croissance) | Communauté très active avec forum officiel (community.znuny.org) et nombreuses extensions fournies par les utilisateurs |
| Mises à jour de sécurité | Correctifs de sécurité réguliers par les développeurs (Rother OSS) et contributions communautaires | Correctifs de sécurité et versions correctives réguliers (Znuny GmbH fournit rapidement les mises à jour, surtout pour les versions LTS) |
Autres fonctionnalités
| Fonctionnalité | OTOBO | Znuny |
|---|---|---|
| Gestion de workflow/processus | Oui – prise en charge complète (incluant un concepteur graphique de processus) | Oui – prise en charge de base (gestion de processus issue d’OTRS 6, fonctionnelle mais moins ergonomique) |
| Composants ITIL/ITSM | Oui – modules ITSM (gestion des changements, gestion des configurations/CMDB, etc.) intégrés ou disponibles en tant que packages | Oui – ITSM (incluant CMDB) disponible comme module complémentaire gratuit (porté sur Znuny 7 et installable) (Bienvenue Znuny 7) |
| Rapports & Analytique | Statistiques et rapports complets via le module intégré, visualisations supplémentaires possibles via modules complémentaires | Module de statistiques standard d’OTRS avec rapports prédéfinis (extensible via modules complémentaires communautaires) |
| Support API | Oui – API REST et services web SOAP (Generic Interface) pour intégration avec systèmes tiers, incluant des points d’entrée étendus | Oui – API REST et SOAP (GenericInterface) similaire à OTRS, pleinement compatible ; extensions possibles via modules de services web supplémentaires |
| Gestion SLA | Oui – gestion complète des SLA et des services (contrats, délais de réponse/résolution par service définissables) | Oui – gestion SLA similaire à OTRS (définition des délais de service et des escalades par file d’attente/service possible) |
| Support multi-canal | Oui – e-mail, portail web, tickets téléphoniques, chat (via module complémentaire), etc. | Oui – e-mail, portail web, téléphone. (Chat ou médias sociaux via modules complémentaires tiers) |
| Accès mobile | Partiel – interface client responsive ; interface agent optimisée pour bureau, utilisation mobile possible via navigateur avec limites | Partiel – similaire à OTOBO : portail client dans Znuny 7 responsive ; interface agent principalement conçue pour bureau |
| Intégration d’outils externes | Oui – nombreuses intégrations disponibles (ex. synchronisation calendrier, lien CRM, chatbots) ; raccordement flexible via REST/SOAP | Oui – intégrations via GenericInterface (REST/SOAP) et modules complémentaires communautaires (ex. pour outils de supervision, import CMDB, etc.) |
| Fonctionnalités payantes | Aucune – toutes les fonctionnalités sont open source (pilotées par la communauté ; support et hébergement éventuellement payants) | Aucune – Znuny est entièrement open source ; support professionnel optionnel via Znuny GmbH ou partenaires |
(Tableau : différences et similitudes entre OTOBO et Znuny)
Support Docker dans Znuny et OTOBO
Un aspect important dans le choix d’un système de tickets est le déploiement et l’installation. Sur ce point, les deux forks adoptent des approches très différentes concernant Docker :
OTOBO fournit une environnement Docker prêt à l’emploi. Des images Docker officielles sont disponibles, et grâce à Docker-Compose, un système OTOBO complet (serveur web, base de données, cache Redis, Elasticsearch, etc.) peut être installé et lancé en quelques minutes. Cela simplifie grandement les tests et les mises en production, car les dépendances sont préconfigurées. La documentation OTOBO inclut une section dédiée à l’installation avec Docker, listant les conteneurs utilisés (ex. otobo_web_1, otobo_db_1, otobo_elastic_1, etc.). Grâce à cette intégration Docker complète, OTOBO est rapidement opérationnel, et les mises à jour sont également faciles dans un environnement conteneurisé.
Znuny, en revanche, ne fournit aucune image Docker officielle. La méthode d’installation recommandée est l’installation classique sur un serveur Linux (Debian/Ubuntu, Red Hat, CentOS, etc.) via gestionnaire de paquets ou compilation depuis les sources. Bien que des conteneurs Docker non officiels existent dans la communauté (par exemple sur Docker Hub, fournis par des tiers), ils ne sont pas maintenus par le projet Znuny lui-même. Les administrateurs souhaitant utiliser Znuny en conteneur peuvent recourir à ces projets communautaires, mais doivent savoir que le support officiel se concentre sur les installations traditionnelles. Pour Znuny, cela signifie un peu plus de travail manuel lors de la configuration, mais aussi un contrôle total sur l’environnement serveur. De nombreux utilisateurs de Znuny apprécient l’installation classique, car elle s’inspire du déploiement OTRS. Néanmoins, la communauté Znuny a exprimé un besoin croissant d’images Docker officielles – une évolution possible à l’avenir, mais pour l’instant, OTOBO prend clairement l’avantage.
API REST et intégrations
Les deux systèmes, Znuny et OTOBO, offrent des interfaces puissantes pour s’intégrer à des écosystèmes existants. Grâce au GenericInterface, il est possible de définir des services web REST et SOAP pour créer, récupérer ou exécuter d’autres actions sur les tickets depuis l’extérieur.
Dans OTOBO, l’API REST a été davantage améliorée et étendue. La documentation décrit en détail comment mettre en œuvre diverses automatisations via REST. Les cas d’usage typiques incluent l’intégration avec des systèmes CRM, la création automatique de tickets depuis des formulaires ou l’interaction avec des chatbots. OTOBO fournit par défaut plusieurs points d’entrée prédéfinis, et il est possible d’ajouter des points d’entrée personnalisés par configuration. L’authentification OAuth2 pour l’accès à l’API peut également être configurée pour garantir des intégrations sécurisées.
Znuny mise sur la compatibilité éprouvée pour les API. Toutes les interfaces de services web connues d’OTRS fonctionnent de manière identique dans Znuny. Ainsi, les entreprises ayant déjà des intégrations basées sur l’API OTRS peuvent migrer vers Znuny sans modifier leurs interfaces. L’API REST Znuny permet également des opérations CRUD sur les tickets, utilisateurs, articles, etc. Les services web (REST/SOAP) peuvent être configurés via l’interface d’administration avec des mappings. Les différences avec OTOBO ne concernent pas tant la fonctionnalité de l’API elle-même – les deux systèmes prennent en charge des cas d’usage similaires – que la documentation et l’évolution : OTOBO documente l’API REST de manière exhaustive dans son manuel et pourrait proposer à l’avenir des fonctionnalités API étendues, tandis que Znuny se concentre sur la stabilité et la compatibilité ascendante des interfaces existantes. En pratique, l’API REST Znuny et l’API REST OTOBO sont comparables en termes de puissance – le choix du système dépendra davantage d’autres critères que de l’API.
Intelligence artificielle dans les systèmes de tickets
Un critère différenciant intéressant est l’utilisation de l’intelligence artificielle (IA) pour améliorer les processus de gestion des tickets. Ici, OTOBO a pris une longueur d’avance, tandis que Znuny adopte une approche plus prudente :
OTOBO propose un module IA optionnel pour la classification des tickets. Ce plugin (aussi appelé OTOBO AI) utilise des algorithmes de machine learning pour analyser automatiquement les tickets entrants et suggérer des catégories et priorités. Par exemple, il peut détecter, à partir de l’objet et du contenu, la file d’attente ou le sujet le plus probable et pré-remplir le ticket en conséquence. Le module IA fonctionne dans un conteneur Docker séparé et communique avec le cœur d’OTOBO via une interface. Les avantages incluent des temps de réponse accélérés et une réduction de la charge des agents de support lors de la qualification initiale des demandes. L’intelligence artificielle dans OTOBO en est encore à ses débuts, mais montre déjà des gains d’efficacité significatifs dans des projets pilotes. Par ailleurs, la communauté expérimente avec l’intégration de chatbots et d’outils de traitement du langage naturel (NLP) dans OTOBO.
Znuny ne dispose actuellement d’aucune fonction IA intégrée. Des fonctionnalités comme la catégorisation automatique ou les suggestions de réponse assistées par IA ne sont pas officiellement prises en charge par Znuny (en 2025). Toutefois, il est possible d’étendre Znuny avec de l’IA en connectant des services IA externes – par exemple, via l’API REST, les tickets peuvent être envoyés à un service externe de machine learning et les résultats récupérés. Cela nécessite toutefois un développement personnalisé. La communauté Znuny suit le sujet « IA dans Znuny », mais le projet privilégie la stabilité et les fonctionnalités de base. Les entreprises souhaitant bénéficier immédiatement de l’IA opteront plutôt pour OTOBO ou développeront leurs propres solutions pour Znuny. Il reste à voir si les futures versions de Znuny intégreront directement des fonctionnalités IA, mais pour l’instant, OTOBO est clairement en tête en matière d’intelligence artificielle dans les systèmes de tickets.
Installation et disponibilité des démonstrations
Les deux systèmes de tickets sont open source et peuvent être installés librement. L’installation de Znuny et OTOBO suit les principes classiques d’OTRS, mais OTOBO propose des méthodes supplémentaires qui facilitent l’adoption :
Installation Znuny : Znuny s’installe généralement sur un serveur Linux. Des paquets officiels (RPM/DEB) et des guides sont disponibles pour les distributions courantes. L’installation inclut la configuration de modules Perl, d’un serveur web (Apache/Nginx) et d’une base de données (MySQL/MariaDB ou PostgreSQL). Znuny fournit des tutoriels et le script d’installation OTRS Installer-Bash bien connu. Comme Znuny correspond à OTRS 6, les administrateurs ayant une expérience d’OTRS trouveront l’installation très familière. Aucun portage officiel pour Windows n’existe – Znuny cible les environnements serveur Linux/Unix. L’aide pour l’installation Znuny est abondante dans la documentation officielle et le forum communautaire.
Installation OTOBO : OTOBO peut également être installé manuellement sur Linux (similaire à Znuny, avec Apache/Perl, etc.). Toutefois, les développeurs recommandent vivement l’installation basée sur Docker, qui simplifie considérablement le processus. Grâce aux fichiers Docker-Compose fournis, OTOBO peut être déployé avec tous ses composants en quelques minutes. Cela réduit les erreurs de configuration et facilite les mises à jour. En alternative, Rother OSS propose un dépôt de paquets pour Ubuntu, permettant l’installation et la mise à jour via apt. En résumé, dans le cas de « Znuny vs OTOBO », l’installation initiale est généralement plus rapide avec OTOBO grâce à Docker, tandis que Znuny suit une approche plus traditionnelle. Les deux systèmes ont des exigences similaires (Perl 5, base de données, serveur web) ; les différences résident surtout dans les méthodes d’installation proposées.
En ce qui concerne la démonstration, il existe aussi des différences : aucune démonstration Znuny n’est proposée publiquement par le projet – les intéressés doivent installer Znuny eux-mêmes ou utiliser un conteneur de démonstration non officiel. OTOBO, en revanche, peut être testé facilement : soit en utilisant l’installation Docker en local, soit en contactant des prestataires comme Softoft, qui proposent une démonstration OTOBO hébergée. Sur le site officiel d’OTOBO, un formulaire permet de demander une démonstration personnalisée. Ainsi, les utilisateurs potentiels peuvent découvrir l’interface et les fonctionnalités d’OTOBO en direct, sans avoir à installer quoi que ce soit. En résumé : ceux qui souhaitent rapidement un environnement de test trouveront plus facilement leur bonheur avec OTOBO, tandis que Znuny exige une installation préalable – rapide toutefois avec une certaine expérience Docker.
Domaines d’application et avantages
Les deux systèmes conviennent à de nombreux cas d’usage en gestion des services. Znuny comme OTOBO sont utilisés avec succès pour le support informatique / helpdesk, les centres d’appels clients, les processus ITIL internes (gestion des incidents/problèmes/changements), la gestion des installations (facility management) et bien d’autres scénarios. Du fait de leurs racines communes OTRS, les deux systèmes remplissent un rôle similaire, mais selon les besoins, l’un ou l’autre peut présenter des avantages :
Znuny excelle là où la stabilité, le support à long terme et la continuité sont essentiels. Les entreprises ayant longtemps utilisé OTRS apprécient l’environnement familier de Znuny et la garantie de mises à jour de sécurité à long terme (surtout avec la version LTS). Autour de Znuny existe également un vaste ensemble de modules communautaires permettant des solutions sectorielles spécifiques. La courbe d’apprentissage pour les administrateurs et agents expérimentés en OTRS est quasi nulle – ils se sentent immédiatement à l’aise.
OTOBO brille dans les environnements qui mettent l’accent sur les fonctionnalités modernes et la convivialité. Le nouveau portail client et les éléments d’interface rafraîchis sont bien accueillis par les utilisateurs finaux. Des fonctionnalités comme la recherche Elastic ou l’IA intégrée améliorent l’efficacité du support. Grâce à Docker, OTOBO peut être rapidement mis à l’échelle dans des environnements cloud ou dupliqué pour des tests. OTOBO est souvent choisi par des organisations souhaitant une approche plus innovante et prêtes à adopter un fork plus récent, avec des équipes de développement plus petites mais agiles.
En fin de compte, le choix entre Znuny et OTOBO dépend des besoins spécifiques, de l’infrastructure existante et des objectifs stratégiques de l’entreprise. Les deux solutions sont gratuites et open source, sans risque de licence – tout dépend des priorités choisies (stabilité vs innovation, familiarité vs interface moderne, etc.).
Conclusion
Znuny et OTOBO partagent des racines communes dans l’édition communautaire OTRS, mais évoluent désormais parfois dans des directions différentes. OTOBO convainc par une interface utilisateur moderne, des fonctionnalités supplémentaires (ex. module IA) et un déploiement confortable via Docker. Znuny mise sur la fiabilité et un fort soutien communautaire – il intègre les nouveautés avec prudence et garantit la pérennité du patrimoine OTRS. Il n’y a pas de « gagnant » clair : les deux systèmes de tickets comptent parmi les meilleures solutions open source du marché. Le choix entre eux dépend finalement des besoins et préférences spécifiques de l’utilisateur. Il est recommandé de tester les deux systèmes, si possible, dans un environnement de démonstration ou de test, afin de déterminer quelle solution convient le mieux à votre entreprise. Dans tous les cas, vous bénéficierez de la flexibilité et de l’expertise de la communauté OTRS, qui vit encore dans ces deux projets.
Sources
- Site web Znuny : site officiel du projet Znuny, avec téléchargements, documentation et blog.
- Site web OTOBO : site officiel d’OTOBO (page du projet de Rother OSS GmbH), avec descriptions des fonctionnalités et annonces de nouvelles versions.
- Feuille de route et blog Znuny : annonces concernant Znuny 7 (ex. refonte de l’interface, support OAuth2 prévu) sur znuny.org.
- Documentation OTOBO : documentation en ligne sur otobo-docs.softoft.de (notamment pour l’installation Docker, l’API REST et le plugin IA).
- Forums communautaires : échanges d’expériences sur Znuny et OTOBO (community.znuny.org, forum OTOBO) – par exemple, rapports sur la migration d’OTOBO vers Znuny, ou utilisation de Docker pour les forks OTRS.