Journal : Retour d’expérience sur la personnalisation du logiciel libre de gestion d’incident « Request Tracker »

Posté par Christophe Nowicki (Jabber id, page perso, ) le 12 février 2006

Après plusieurs mois de travail sur la personnalisation de cet outils pour un client, j’ai le plaisir de vous presenter un article qui décrit mon travail. Mais tout d’abord une rapide présentation du logiciel.

Request Tracker

RT ( http://www.bestpractical.com/rt/ ) est un logiciel libre de gestion d’incident, en anglais ticketing, il permet la prise en charge des demandes client. Lorsqu’un problème survient chez un de nos clients (plantage serveur, coupure de service, etc…) celui-ci envoie un mail ou bien téléphonne au support pour signaler l’incident.
Cet incident donne lieu à un ticket qui sera pris en charge par le support technique.
Grace à ce système :

* Les clients peuvent suivre en temps réel, la résolution de l’incident
* Communiquer avec le support
* Le support facture les interventions
* L’ensemble des interventions sont archivées.

Nous utilisons ce système chez Easter-eggs ( http://www.easter-eggs.com/ ) depuis près de 3ans avec succés et nous en sommes très content, comme beaucoup d’autres.
La mise en place de système est assez complexe et nécessite de bonnes compétances en administration système et en programmation Perl ( si vous voulez modifier l’outils pour l’adapter aux besoins spécifiques de votre entreprise).
Pour vous aider dans l’installation de l’outil, un article est paru dans le Linux Magazine France de ce mois-ci (Janvier 2006), mais celui-ci ne parle pas de la personnalisation de l’outils.

L’application de Suivi Qualité

L’Application de Suivi Qualité développée par Easter-eggs à partir de RT offre la possibilité de :

* s’interfacer avec l’annuaire LDAP de l’entreprise ;
* importer les bases de données d’un outil existant ;
* effectuer des recherches dynamiques simplifiées ;
* réaliser des imports CSV à partir d’un ERP ;
* avoir une interface dynamique sans rechargement avec Javascript, méthodologie AJAX;
* personnaliser les emails ;
* gérer de manière automatisée les relances des tâches échues ;
* extraire des statistiques d’activité.

Biensûr l'ensemble des développement est sous licence GPL, mais comme souvent dans ce genre de cas très lier au métier du client.

Le retour d’expérience sur la modification

Mon article est disponible au format PDF à l’adresse suivante :
http://www.csquad.org/pub/rt_qualite/20060207-rt_qualite.pdf

Bonne lecture

> Lire le journal (7 commentaires, moyenne: 2,3).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Coquilles ;-)

Posté par Antoine (page perso, ) le 12/02/2006 à 09:25. (lien). Évalué à 2.

J'ai remarqué quelques coquilles...

- page 3, sur le schéma : "résoluton" -> "résolution" ; "employer" -> "employé"

- page 9, sur le schéma : "rélationnel" -> "relationnelle"

mon avis

Posté par Matthieu () le 12/02/2006 à 11:52. (lien). Évalué à 4.

RT est en effet un outil très pratique et bien pensé pour tout pôle de support d'une entreprise.
Pour préciser un peu son fonctionnement, le ticket, qui matérialise la demande et son processus de traitement/résolution, est déclenché soit par la création d'une telle demande via l'interface web, soit directement par un interlocuteur envoyant un mail à une adresse spécifique : RT contient un module de passerelle mail qui ouvre le ticket lors de la réception du mail.
A partir du tikcet créé, on peut lui assigner un statut pour suivre son état (nouveau, ouvert/en cours de traitement, résolu, bloqué), un intervenant unique, ainsi que des champs personnalisés (nom du client, plateforme par exemple) définissables à volonté. Lorsque le demandeur envoie le mail à l'adresse qu'on lui a indiquée, RT lui envoie un accusé de réception, certifiant que la demande est en cours de traitement, avec un login/mot de passe permettant de suivre l'évolution de tous ses tickets.

Il est possible de gérer plusieurs types de support, ou de classer les demandes en queues, ayant chacune leur adresse mail (ainsi on peut séparer les demandes, par exemple, de support, d'incident, de renseignement etc...).
Contrairement à ce que tu dis dans ton pdf, je ne trouve pas l'interface de recherche difficle à appendre même pour un non informaticien, puisque cette recherche se fait en fonction de critères du ticket (demandeur, date d'ouverture, statut, intervenant, sujet... , et il n'y a pas à maîtriser la moindre notion informatique ou de sql.

On est d'accord sur ce qui concerne l'interface web : assez colossalement laide, elle paraît vieillote. La css a elle seule ne permet pas de tout modifier, j'ai du pour ma part ajouter des styles dans le code là ou certaines choses étaient codées en dur.

Quelques scripts et modules permettent de compléter RT : entre autre le modules Statistics, qui permet de voir sur une période de temps le nombre de demandes reçues, traitées, le temps de résolution, avec des graphiques ; le module RTFM, qui permet d'écrire et gérer une base documentaire d'articles.

Un autre bon point : la migration d'une version de RT vers une nouvelle est simple grace aux scripts SQL fournis, qui permettent de garder l'ancienne base de données en l'adaptant comme il faut.

L'installation de l'outil n'est pas difficile à mon avis perso, elle est surtout un peu longue, il y a une tonne de modules perl à installer, mais RT propose un script qui tente de le faire tout seul. Dans tous les cas, les modules manquants sont présents sur le CPAN Perl. A noter : l'installation est bien plus smple et rapide sur une Debian (il existe même des paquets) que sur une redhat 9.0....

Voilà, si il y a des questions je tenterai d'y répondre avec plaisir (tout comme l'auteur de ce journal je pense!).

Et ton interface Ajax, c'est juste un projet ou c'est en cours? Ca sera dispo un jour en GPL? ;-)

[^]Re: mon avis

Posté par Christophe Nowicki (Jabber id, page perso, ) le 13/02/2006 à 19:50. (lien). Évalué à 2.

Et ton interface Ajax, c'est juste un projet ou c'est en cours? Ca sera dispo un jour en GPL? ;-)

L'application de suivi qualité que nous avons developpé est remplie de fonctionnalitées Ajax (complétion automatique, verification automatique, etc...).

Mais je pense que les parties les plus importantes de nos modifications sont les suivantes :

- alimentation de la liste des valeurs de "customfields" à partir d'une source de données externe. (comme une table dans la base).
- classement des custom fields par catégorie
- vision métier de la base de données

Je vais extraire ces modifications pour les mettre à disposition (sur le Wiki de RT, ou bien sur mon blog).

OTRS me semble plus simple...

Posté par Médéric RIBREUX (page perso, ) le 12/02/2006 à 17:20. (lien). Évalué à 3.

Hello,

il y a quelques temps (6 mois), je me suis posé la question de mettre en place un système de gestion de tickets (pas de bugs hein, c'est différent) pour les utilisateurs de ma structure.

J'en ai testé quelques-uns dont RT qui ne m'a pas convaincu pour les arguments suivants:
- Interface franchement moche (un peu trop austère à mon goût et surtout pas vraiment simple à utiliser pour le end-user).
- L'installation est assez galère (enfin, c'est pas trivial dans mes souvenirs)
- j'ai eu d'énormes difficultés à mettre en place l'interfaçage avec l'annuaire LDAP(ldaps je précise) malgré les docs sur le wiki.
- je ne parle même pas de l'intégration avec la plateforme d'envoi/réception de mails (qui est tout en secure sur des ports exotiques).
- pas de gestion de FAQ native (un truc à installer en plus).
Pour résumer, c'est d'ailleurs dit dans le message initial, c'est chaud time à l'installation...

Au final, je me suis tourné vers OTRS qui fait globalement la même chose, est plus beau, plus simple à mettre en place (interfaçage LDAPS, mails très rapide), offre directement une plateforme pour la FAQ (essentiel dans mon cas), reste très personnalisable, est bien intégré à la Debian Sarge, se combine avec postgreSQL, etc...

[^]Re: OTRS me semble plus simple...

Posté par Gilles Mocellin () le 12/02/2006 à 18:23. (lien). Évalué à 1.
Tout pareil...

C'est marrant, en peu de temps, j'entends parler partout de RT (notre fournisseur réseau, Linux Mag et ici) mais jamais d'OTRS.

Alors qu'ayant du mettre en place un tel système il y a 2 ou 3 ans, OTRS m'était apparu supérieur à RT.

En plus , la doc de RT, c'était le néant, j'éspere que ça a évolué.
- [^]Re: OTRS me semble plus simple...
  
  Posté par Yann Richard (Jabber id, page perso, ) le 13/02/2006 à 08:23. (lien). Évalué à 2.
  Je suis assez d'accord, j'ai mis en place OTRS et quand le choix d'avoir un SSD (Système de Suivie de Demandes) je suis partie en quête. RT me parraissait très laid, peu modulaire. OTRS par contre m'a parru tout de suite plus limpide. L'outil écrit en Perl n'est pas comme beaucoup d'autres outils écrit en Perl illisible et pas organisé (Ceci n'est pas un troll, trolleurs professionnels passez votre chemin...). Ce code Perl est très clair et lisible, la configuration permet de faire vraiment ce que l'on veux, les connecteurs
  permettent d'externaliser l'authentification et les sources de données, un système de template permet de personnaliser les interfaces facilement...
  
  Une chose manque cruellement c'est un thème compatible XHTML CSS2 WAI, je travaille à en faire un pour le coté client et je compte bien le fournir aux developpeurs.

Flyspray

Posté par Nÿco (Jabber id, page perso, ) le 13/02/2006 à 10:01. (lien). Évalué à 2.

Bravo et merci pour ce retour d'expérience.

Chez mon client, on a éliminé OTRS, Eventum, Bugzilla et Mantis pour retenir Flyspray, le système de gestion de ticket libre en PHP développé par et pour Psi, le client Jabber libre et multiplateforme basé sur Qt.

Le plus, outre sa simplicité, c'est son intégration à Jabber... qui permet le suivi en temps-réel...

--
Jabber ID : xmpp:Nyco@jabber.fr

Revenir en haut de page