Aller au contenu

Comparaison des systèmes de tickets Znuny et OTOBO

Comparaison des systèmes de tickets Znuny et OTOBO

Section intitulée « Comparaison des systèmes de tickets Znuny et OTOBO »

Znuny et OTOBO sont des forks de l’édition OTRS Community Edition, aujourd’hui abandonnée, et ont évolué pour devenir des systèmes de tickets open source indépendants. Ces deux solutions comptent parmi les forks d’OTRS les plus connus et offrent de nombreuses fonctionnalités pour la gestion efficace des demandes de support client. Elles diffèrent néanmoins sur certains aspects centraux. Dans cette comparaison Znuny vs OTOBO, nous mettons en lumière leurs points communs et leurs différences – de la richesse fonctionnelle au support Docker et à la REST API, en passant par l’intelligence artificielle (IA), l’installation et les possibilités de démo.

OTOBO : Un système de tickets open source moderne

Section intitulée « OTOBO : Un système de tickets open source moderne »

OTOBO est basé sur OTRS 6 et l’enrichit de fonctionnalités modernes ainsi que d’une expérience utilisateur améliorée. Il s’agit d’un système de helpdesk basé sur le web pour la gestion des demandes clients. Les caractéristiques principales d’OTOBO incluent :

  • Portail client moderne : Interface entièrement repensée et conviviale pour les utilisateurs finaux, optimisée également pour les appareils mobiles.
  • Formulaires optimisés : Création de tickets simplifiée grâce à des formulaires et des champs de saisie configurables.
  • Fonctions de sécurité avancées : Par ex. politiques de mots de passe, protection contre les attaques par force brute, authentification à deux facteurs (2FA) et droits d’accès finement granulaires.
  • Migration simple depuis OTRS : Des scripts de migration intégrés permettent une transition fluide d’une installation OTRS 6 vers OTOBO.
  • Recherche en direct Elasticsearch : Résultats de recherche plus rapides et plus précis grâce à l’intégration d’Elasticsearch pour la recherche en texte intégral.
  • Intégration avec OpenStreetMap : Les données géographiques peuvent être affichées directement dans le ticket (utile par ex. pour les tickets liés à un lieu).
  • Options d’escalade flexibles : Règles d’escalade étendues pour un meilleur contrôle dans la gestion des escalades.
  • Support RGPD : Des fonctions pour le respect du RGPD (par ex. anonymisation des tickets) sont intégrées.
  • Performance améliorée : Base de code révisée et mise en cache (Redis) conduisant à des temps de réponse plus rapides.
  • Classification de tickets assistée par IA : Un plugin IA est disponible en option, utilisant le machine learning pour catégoriser automatiquement les tickets et attribuer des priorités.

Znuny est la continuation directe du projet OTRS par la communauté (maintenu par Znuny GmbH) et met l’accent sur la stabilité et la compatibilité à long terme, complétées par des nouveautés sélectionnées. Parmi les fonctionnalités et caractéristiques marquantes de Znuny, on trouve :

  • Développement continu : Znuny reçoit des mises à jour régulières avec des correctifs de bugs et de nouvelles fonctionnalités. Par exemple, dans les versions récentes, des fonctions telles que le filtrage des rendez-vous dans le calendrier, le support OAuth2 pour les services externes (Invoker), les mentions d’utilisateurs (@-mentions dans les notes de ticket) et les extraits de texte ont été ajoutées.
  • Options de sécurité et de conformité : Le support des groupes LDAP imbriqués (Nested Groups) pour l’attribution des droits, une gestion améliorée du S/MIME (gestion des clés) et d’autres mises à jour de sécurité assurent un système sécurisé.
  • Adaptabilité flexible : Grâce à un système de paquets et aux services web GenericInterface, Znuny peut être largement étendu et intégré dans d’autres systèmes. Les options de filtrage et les ACL permettent une configuration individuelle de l’interface et des processus.
  • Intégrité des révisions : Toutes les modifications de tickets sont consignées sans lacunes, de sorte que les changements et les actions sont traçables à tout moment (important par ex. pour les processus auditables).
  • Composants ITIL disponibles : Znuny propose des add-ons optionnels comme le module ITSM (incluant une CMDB pour la gestion des actifs) et le module FAQ en tant qu’extensions libres, afin de fournir une étendue fonctionnelle similaire à l’ancienne suite OTRS::ITSM.
  • Support communautaire fort : En tant que fork communautaire officiel d’OTRS, Znuny dispose d’un forum actif et de contributions de la communauté. De nombreuses fonctionnalités OTRS autrefois payantes ont été poursuivies par la communauté dans Znuny.

Les deux projets ont évolué continuellement depuis la séparation d’OTRS et publient régulièrement de nouvelles versions :

  • OTOBO version 10 (publiée pour la première fois en 2020) constitue la base de l’installation OTOBO actuelle. Cette version a apporté l’interface web modernisée et de nombreuses améliorations mentionnées ci-dessus. Depuis, des patch releases réguliers apparaissent (par ex. 10.0.17, 10.0.18, etc.), fournissant des corrections d’erreurs et des fonctionnalités mineures. Pour l’avenir, OTOBO version 11 est déjà annoncée, laquelle devrait apporter d’autres optimisations et nouvelles fonctionnalités (Softoft a publié des informations préliminaires à ce sujet). Les développeurs d’OTOBO (Rother OSS GmbH) accordent de l’importance à une roadmap innovante – par exemple, une intégration IA a été proposée très tôt en tant que module optionnel.

  • Znuny a repris la base de code d’OTRS 6 et l’a d’abord maintenue sous le nom de Znuny 6 (incluant Znuny LTS 6.5, une version de support à long terme pour les entreprises misant sur une stabilité maximale). En mars 2023 est apparu Znuny 7.0, qui représente un pas en avant significatif : l’interface client a été repensée à 70% (Welcome Znuny 7) pour être plus moderne et conviviale, tandis que l’interface agent a été prudemment modernisée, mais délibérément maintenue familière (Welcome Znuny 7). Actuellement (début 2025), Znuny 7.1 est la version principale stable, et Znuny 7.2 est déjà prévue pour le T3 2025 (Roadmap). Znuny 7 apporte également des modernisations techniques « sous le capot », censées faciliter les adaptations et extensions futures (Welcome Znuny 7). Important à mentionner : les Znuny 7.x sont des versions de fonctionnalités et nécessitent un entretien actif par l’utilisateur, tandis que Znuny LTS 6.5 continue de recevoir des mises à jour de sécurité au moins jusqu’à fin 2025 (Roadmap). Ainsi, Znuny propose à la fois une ligne LTS conservatrice et une ligne de version progressive.

Voici un tableau comparatif des caractéristiques importantes d’OTOBO et de Znuny :

CaractéristiqueOTOBOZnuny
BaseFork de l’OTRS Community Edition 6Fork de l’OTRS Community Edition 6
DéveloppeurRother OSS GmbH (initiateur et développeur principal)Znuny GmbH (dirigé par d’anciens développeurs de la communauté OTRS)
Licence100% Open Source (GNU GPL v3) – aucun module propriétaire100% Open Source (GNU GPL v3) – entièrement disponible gratuitement
Support DockerOui – images Docker officielles et modèles Docker-Compose pour une installation rapide disponiblesAucun image officielle (installation classique sur serveur Linux ou via des conteneurs Docker communautaires non officiels)
Portail clientPortail client entièrement repensé (UI moderne, design responsive, utilisation intuitive)Portail client issu d’OTRS 6 avec améliorations ; partiellement redessiné dans Znuny 7, mais pas développé de zéro comme chez OTOBO
ElasticsearchIntégré avec des options de configuration étendues (configuration d’index complexe, recherche en direct)Intégré en tant que moteur de recherche optionnel avec les fonctions standard d’OTRS (indexation des champs de ticket de base)
OAuth2 pour e-mailOui – supporte OAuth2 pour IMAP/POP3 depuis OTOBO 10.0.11 (par ex. pour Office 365 sans Basic Auth non sécurisé)Actuellement limité – le support direct OAuth2 pour les comptes e-mail sera probablement réalisé dans Znuny 7.2 via l’API Microsoft Graph (Roadmap) (des solutions de contournement sont nécessaires jusque-là)
Outils de migrationMigration d’OTRS 6 vers OTOBO supportée (scripts et guides disponibles)Migration d’OTRS 6 vers Znuny possible de manière transparente ; une reprise d’une base de données OTOBO existante vers Znuny a également été réalisée avec succès par la communauté (avec des étapes de conversion)
CommunautéCommunauté active, forum et contributions régulières (encore plus petite que chez Znuny, mais en croissance constante)Communauté très active avec forum officiel (community.znuny.org) et de nombreuses extensions par les utilisateurs
Mises à jour de sécuritéPatchs de sécurité réguliers par les développeurs (Rother OSS) et contributions de la communautéPatchs de sécurité et versions de correction de bugs réguliers (Znuny GmbH fournit les mises à jour rapidement, surtout pour les versions LTS)
FonctionnalitéOTOBOZnuny
Gestion des workflows/processusOui – support complet (incl. concepteur de processus graphique pour les flux)Oui – support de base (gestion des processus issue d’OTRS 6, fonctionnelle mais moins confortable)
Composants ITIL/ITSMOui – modules ITSM (Change Management, Configuration Management/CMDB, etc.) intégrés ou disponibles sous forme de paquetsOui – ITSM (incl. CMDB) disponible en tant qu’add-on libre (porté et installable pour Znuny 7) (Welcome Znuny 7)
Reporting & AnalyticsStatistiques et rapports complets via le module de statistiques intégré, évaluations graphiques supplémentaires possibles via add-onModule de statistiques standard issu d’OTRS avec rapports prédéfinis (extensible via des add-ons communautaires)
Support APIOui – REST API et services web SOAP (Generic Interface) pour l’intégration avec des systèmes tiers, incl. points de terminaison étendus dans OTOBO 10Oui – REST et SOAP API (GenericInterface) analogue à OTRS, entièrement compatible ; extensions possibles via des paquets de services web supplémentaires
Gestion SLAOui – gestion complète des SLA et des services (contrats, temps de réponse/solution définissables par service)Oui – gestion SLA analogue à OTRS (définition des heures de service et escalades possibles par file/service)
Support Multi-ChannelOui – e-mail, portail web, tickets téléphoniques, chat (via add-on) et bien plusOui – e-mail, portail web, téléphone. (Chat ou réseaux sociaux via des add-ons de fournisseurs tiers)
Accès mobilePartiel – frontend client responsive ; UI agent optimisée pour desktop, utilisation mobile via navigateur possible avec des limitationsPartiel – Similaire à OTOBO : portail client responsive dans Znuny 7 ; interface agent conçue principalement pour desktop
Intégration d’outils externesOui – nombreuses intégrations (par ex. synchronisation de calendrier, connexion CRM, chatbots) disponibles ; connexion flexible via REST/SOAPOui – intégrations via GenericInterface (REST/SOAP) et add-ons communautaires (par ex. pour outils de monitoring, importation CMDB, etc.)
Fonctionnalités payantesAucune – toutes les fonctionnalités sont open source (piloté par la communauté ; support et hébergement éventuellement payants via des prestataires)Aucune – Znuny est entièrement open source ; support professionnel disponible en option via Znuny GmbH ou des partenaires

(Tableau : Différences et points communs entre OTOBO et Znuny)

Un aspect important lors du choix du système de tickets est le déploiement et l’installation. Ici, les approches des deux forks diffèrent nettement en ce qui concerne Docker :

OTOBO fournit un environnement Docker prêt à l’emploi. Des images Docker officielles sont disponibles, et via Docker-Compose, un système OTOBO complet (serveur web, base de données, cache Redis, Elasticsearch, etc.) peut être installé et démarré en un temps record. Cela simplifie considérablement les tests et les mises en production, car les dépendances sont préconfigurées. La documentation OTOBO propose une section dédiée à l’installation avec Docker et liste les conteneurs (par ex. otobo_web_1, otobo_db_1, otobo_elastic_1, etc.) utilisés pour l’exploitation. Grâce à cette intégration Docker complète, OTOBO est très rapidement opérationnel et les mises à jour peuvent également être effectuées facilement dans des environnements de conteneurs.

Znuny, en revanche, ne fournit pas d’images Docker officielles. La méthode d’installation privilégiée pour Znuny est l’installation classique sur un serveur Linux (Debian/Ubuntu, Red Hat, CentOS, etc.) via un gestionnaire de paquets ou une installation à partir du code source. Bien qu’il existe des conteneurs Docker non officiels issus de la communauté (par exemple sur Docker Hub par des tiers), ceux-ci ne sont pas maintenus par le projet Znuny lui-même. Les administrateurs souhaitant utiliser Znuny via des conteneurs peuvent recourir à ces projets communautaires, mais doivent noter que le support officiel se concentre sur les installations traditionnelles. Pour Znuny, cela signifie un peu plus d’efforts manuels lors de la configuration, mais en contrepartie un contrôle total sur l’environnement serveur. De nombreux utilisateurs de Znuny apprécient l’installation classique car elle est calquée sur le déploiement OTRS. Néanmoins, l’appel à des images Docker officielles s’est fait entendre dans la communauté Znuny – un changement pourrait éventuellement survenir à l’avenir, mais à l’heure actuelle, OTOBO marque clairement des points.

Znuny comme OTOBO offrent des interfaces puissantes pour l’intégration dans des paysages système existants. Via la GenericInterface, des services web REST et SOAP peuvent être définis pour, par exemple, créer des tickets en externe, les récupérer ou effectuer d’autres actions.

Dans OTOBO, la REST API a été encore améliorée et étendue. La documentation OTOBO décrit en détail comment mettre en œuvre des automatisations variées via REST. Les cas d’utilisation typiques sont la connexion de systèmes CRM, la création automatique de tickets à partir de formulaires ou l’intégration avec des chatbots. OTOBO propose quelques points de terminaison prédéfinis prêts à l’emploi et des points de terminaison personnalisés peuvent être ajoutés par configuration. L’authentification OAuth2 pour les accès API peut également être configurée pour garantir des intégrations sécurisées.

Znuny mise sur une compatibilité éprouvée en matière d’API. Toutes les interfaces de services web connues d’OTRS fonctionnent de manière identique dans Znuny. Ainsi, les entreprises qui avaient déjà des intégrations basées sur l’API OTRS peuvent passer à Znuny sans avoir à adapter leurs interfaces. La Znuny REST API permet également des opérations CRUD sur les tickets, les utilisateurs, les articles, etc. Via l’interface d’administration, des services web (REST/SOAP) peuvent être configurés avec des configurations de mapping. Les différences avec OTOBO ne résident pas tant dans la fonctionnalité de l’API elle-même – les deux systèmes supportent des cas d’utilisation similaires – que dans la documentation et le développement continu : OTOBO documente la REST API de manière exhaustive dans son propre manuel et pourrait éventuellement offrir des fonctions API étendues à l’avenir, tandis que Znuny se concentre sur le maintien des interfaces existantes de manière stable et rétrocompatible. En pratique, la « Znuny REST API » et la « OTOBO REST API » sont tout aussi performantes – le choix du système est ici davantage influencé par d’autres facteurs que par l’API.

Intelligence artificielle dans le système de tickets

Section intitulée « Intelligence artificielle dans le système de tickets »

Un point de différenciation passionnant est l’utilisation de l’intelligence artificielle (IA) pour le support dans le processus de ticket. Ici, OTOBO a posé des jalons très tôt, tandis que Znuny se montre (encore) réservé :

OTOBO propose un module IA optionnel pour la classification de 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 ainsi que des priorités. Il peut, par exemple, reconnaître en fonction de l’objet et du contenu quelle file ou quel sujet est probable, et pré-remplir le ticket en conséquence. Le module IA tourne dans un conteneur Docker séparé et communique avec le cœur d’OTOBO via une interface. Les avantages de cette solution sont des temps de réponse accélérés et un soulagement pour les collaborateurs du support lors de la pré-qualification des demandes. L’intelligence artificielle dans OTOBO n’en est certes qu’à ses débuts, mais montre déjà des gains d’efficacité nets dans des projets pilotes. De plus, la communauté expérimente l’intégration de chatbots et d’outils NLP dans le contexte OTOBO.

Znuny ne dispose actuellement d’aucune fonction IA intégrée. Des sujets comme la catégorisation automatique ou les suggestions de réponses assistées par IA ne sont pas officiellement couverts par Znuny (au début 2025). Cependant, on peut étendre Znuny avec l’IA en connectant des services IA externes – par exemple, via la REST API, les tickets peuvent être envoyés à un service de machine learning externe et ses évaluations renvoyées. Cela nécessite cependant un customizing individuel. La communauté Znuny a certes le sujet « IA dans Znuny » en ligne de mire, mais l’accent du projet est plutôt mis sur la stabilité et les fonctions de base. Les entreprises souhaitant bénéficier immédiatement de l’IA se tournent plutôt vers OTOBO ou implémentent leurs propres solutions pour Znuny. Il reste à voir si les futures versions de Znuny intégreront directement des fonctionnalités IA, mais actuellement, OTOBO a clairement une longueur d’avance en matière d’intelligence artificielle dans le système de tickets.

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 a ouvert des voies supplémentaires qui facilitent l’entrée en matière :

  • Installation de Znuny : Znuny est généralement installé sur un serveur Linux. Des paquets officiels (RPM/DEB) et des guides existent pour les distributions courantes, et l’installation comprend la mise en place de modules Perl, d’un serveur web (Apache/Nginx) et d’une base de données (MySQL/MariaDB ou PostgreSQL). Znuny fournit pour cela des tutoriels et le célèbre installateur Bash OTRS. Comme Znuny correspond à OTRS 6, les administrateurs ayant de l’expérience avec OTRS peuvent effectuer l’installation de manière très familière. Il n’existe pas de portage officiel pour Windows – Znuny s’adresse à l’exploitation serveur sous Linux/Unix. On trouve amplement d’aide pour l’installation de Znuny dans la documentation officielle et sur le forum communautaire.

  • Installation d’OTOBO : OTOBO peut également être installé manuellement sur Linux (similaire à Znuny, avec Apache/Perl/etc.). Cependant, les développeurs recommandent l’installation basée sur Docker, qui simplifie radicalement le processus. Avec les fichiers Docker-Compose fournis, OTOBO peut être monté en quelques minutes avec tous ses composants. Cela réduit les erreurs de configuration et facilite les mises à jour. Alternativement, Rother OSS propose également un dépôt de paquets pour Ubuntu, de sorte que l’installation et la mise à jour puissent se faire via apt. Dans l’ensemble, l’installation initiale dans le cadre de “Znuny vs OTOBO” est généralement plus rapide avec OTOBO grâce à Docker, tandis que Znuny suit plutôt des étapes de configuration traditionnelles. Les deux systèmes nécessitent des prérequis similaires (Perl 5, base de données, serveur web) ; les différences résident davantage dans les voies d’installation proposées.

En ce qui concerne la disponibilité de la démo, il existe également des différences : une démo Znuny pour essayer directement n’est pas proposée publiquement par le projet lui-même – les personnes intéressées doivent installer Znuny de manière autonome ou utiliser l’un des conteneurs de démo non officiels. OTOBO, en revanche, peut être testé facilement : soit on utilise l’installation Docker localement, soit on s’adresse à des prestataires comme Softoft, qui proposent une démo OTOBO hébergée. Un formulaire est disponible sur le site officiel d’OTOBO pour demander une démo personnelle. 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 cherchent rapidement un environnement pour essayer trouveront plus facilement leur bonheur avec OTOBO, tandis qu’avec Znuny, il faut être prêt à effectuer une courte installation – ce qui, avec un peu d’expérience Docker, peut également aller très vite.

Les deux systèmes conviennent à une multitude de domaines d’application dans la gestion de service. Znuny comme OTOBO sont utilisés avec succès pour le support IT/helpdesk, les hotlines de service client, les processus ITIL internes (gestion des incidents/problèmes/changements), la gestion des installations et bien d’autres scénarios. Grâce à leur racine commune OTRS, les deux remplissent un objectif similaire, mais selon les exigences, l’un ou l’autre système peut offrir des avantages :

  • Znuny déploie ses forces surtout là où la stabilité, le support à long terme et la continuité sont demandés. Les entreprises travaillant depuis longtemps avec OTRS apprécient chez Znuny l’environnement familier et l’assurance de mises à jour de sécurité à long terme (notamment avec la version LTS). De plus, il existe autour de Znuny un grand fonds de modules communautaires permettant des solutions sectorielles spécifiques. La courbe d’apprentissage pour les administrateurs et agents expérimentés OTRS est minimale – on se sent immédiatement chez soi.

  • OTOBO marque des points dans les environnements qui mettent en avant les fonctionnalités modernes et la convivialité. Le nouveau portail client et les éléments d’UI frais sont bien accueillis par les utilisateurs finaux. Des fonctions comme la recherche Elastic ou l’IA intégrée augmentent l’efficacité dans le processus de support. Grâce à Docker, OTOBO peut être rapidement mis à l’échelle dans des environnements cloud ou dupliqué à des fins de test. OTOBO est souvent choisi par des organisations qui empruntent une voie plus innovante et ne craignent pas d’utiliser un fork un peu plus jeune avec des équipes de développement plus petites (mais agiles).

Finalement, la décision Znuny vs OTOBO dépend des exigences spécifiques, de l’infrastructure existante et des objectifs stratégiques de l’entreprise. Les deux solutions sont gratuites et open source, de sorte qu’il n’y a aucun risque lié aux licences – tout dépend des priorités que l’on se fixe (stabilité vs innovation, familiarité vs UI moderne, etc.).

Znuny et OTOBO partagent des racines communes dans l’OTRS Community Edition, mais continuent d’évoluer dans des directions parfois différentes. OTOBO convainc par une interface utilisateur moderne, des fonctionnalités supplémentaires (par ex. module IA) et un déploiement confortable via Docker. Znuny mise sur la fiabilité et un support communautaire fort – il intègre les nouveautés avec prudence et garantit l’entretien à long terme de l’héritage OTRS. Il n’y a pas de « gagnant » clair : les deux systèmes de tickets comptent parmi les meilleures solutions open source sur le marché. Le choix entre eux dépend finalement des besoins et préférences individuels de l’utilisateur. Il est recommandé d’essayer les deux – si possible – dans une démo ou un environnement de test afin de découvrir quelle solution est la plus appropriée pour sa propre entreprise. Dans tous les cas, on profite de la flexibilité et du savoir-faire de la communauté OTRS, qui continue de vivre dans les deux projets.

  • Site web Znuny : Site web officiel du projet Znuny avec téléchargements, documentation et blog.
  • Site web OTOBO : Site web officiel d’OTOBO (page projet de Rother OSS GmbH) avec descriptions des fonctionnalités et annonces de nouvelles versions.
  • Roadmap & Blog Znuny : Annonces concernant Znuny 7 (par ex. refonte de l’UI, support OAuth2 prévu) sur znuny.org.
  • Documentation OTOBO : Documentation en ligne sur otobo-docs.softoft.de (notamment sur l’installation Docker et la REST API, ainsi que le plugin IA).
  • Forums communautaires : Échange d’expériences sur Znuny et OTOBO dans les forums (community.znuny.org, forum OTOBO) – par ex. rapports sur la migration d’OTOBO vers Znuny, ou utilisation de Docker pour les forks OTRS.