Comme la plupart des entreprises, nous avons besoin d'organiser et de suivre l'évolution notre travail. Si les logiciels de gestion de projet classiques répondent aux besoins des grandes organisations, les nôtres sont cependant différents. Par exemple, nos disponibilités varient fortement, notamment pour les tâches internes réalisées en marge de prestations chez un client.

De plus, la plupart des solutions libres dédiées à la gestion de projet souffrent d'un manque chronique de maturité, en particulier dans le domaine de l'ergonomie. Le but d'un tel logiciel est de faire gagner du temps, pas d'en perdre à naviguer dans une interface web apathique pour créer quelques malheureux sous-travaux !

1. Présentation

Nous recherchions donc un outil :

• de gestion de tâches : ce domaine est bien mieux représenté dans le monde du libre et conviendra aussi bien à nos besoins ;
• arrivé à maturité : ceci n'est pas notre cœur de métier, nous laissons volontiers à d'autres le privilège d'essuyer les plâtres !
• simple mais extensible : nos besoins n'ont que peu en commun avec ceux d'un centre d'appel de 1000 collaborateurs... d'un autre coté, nous souhaitons pouvoir l'adapter aisément si nécessaire.

RT (abréviation de Request Tracker) a retenu notre attention. Son utilisation pour le suivi de bugs sur tous les modules du CPAN, l'énorme bibliothèque libre du langage Perl, atteste de sa robustesse et de son extensibilité. Quelques fonctionnalités intéressantes :

• trois interfaces : e-mail (utilisable pour une adresse de type support@... par exemple), web simplifiée "self-service" (pour les utilisateurs extérieurs à l'entreprise) et web complète ;
• rapide : son installation en FastCGI notamment donne une interface très réactive ;
• multilingue et accessible ;
• possède une gestion fine des droits pour chaque file de tickets ;
• facile à adapter, en premier lieu via l'interface web et ensuite en Perl si nécessaire - plusieurs mécanismes sont prévus pour ne pas créer de conflits lors des mises à jour.

Cet article devait au départ être un simple mémo relatif à son utilisation courante, mais fidèle à notre philosophie nous avons décidé d'en rédiger une version à destination de la communauté. Je ne parlerai pas de son installation ici (elle est déjà bien couverte par la documentation et dépend de toutes façons de votre serveur) ni de son utilisation basique (le logiciel est facile à prendre en main).

Il me semble cependant nécessaire de documenter certaines fonctionnalités qui ne sont pas immédiatement évidentes, tout d'abord du point de vue de l'utilisateur et ensuite de l'administrateur.

2. Utilisation courante

RT est un outil de gestion de tickets (par exemple des incidents dans un centre d'appel). Nous l'avons détourné pour gérer des tâches, ce dont il s'acquitte tout aussi bien. Par la suite, j'utiliserai donc ces deux termes indifféremment.

2.1. Distinguer commentaires et réponses

Premièrement, il est utile de faire la distinction entre un commentaire et une réponse. Un commentaire n'est consultable que sur l'interface RT et donc uniquement par les utilisateurs privilégiés. Par contre, une réponse est envoyée par e-mail au demandeur (la personne renseignée comme créateur du ticket) et peut donc parvenir à des personnes tierces sans accès particulier.

Si l'on prend le cas d'un incident remonté par un client de l'entreprise, un commentaire permet de discuter en interne de la problématique tandis qu'une réponse  constitue la position officielle sur le sujet, communiquée par e-mail au client.

2.2. Gérer des priorités

Chaque ticket possède une priorité, exprimée sous la forme d'un entier. RT n'impose aucune limite sur cette valeur, il suppose juste qu'elle est croissante (1000 est plus important que 10). Cependant, il est utile de définir des règles de bonne pratique quant à son utilisation au sein de votre organisation.

Voici un exemple tiré de la documentation : la priorité initiale d'une tâche varie entre 0 et 50 suivant son importance et culmine à 100 (priorité finale). Dans le cas d'une gestion de bugs :

• 1-10 : désagrément mineur ou souhait de nouvelle fonctionnalité ;

• 11-20 : désagrément ;

• 21-30 : désagrément majeur ;

• 31-40 : problème affectant la productivité ;

• 41-50 : problème bloquant, faille de sécurité, ...

2.3. Escalader les priorités

Ces valeurs initiales et finales sont généralement fixées par défaut pour chaque file de tickets, mais il est bien entendu possible de les modifier pour chaque ticket. Le but de ces deux bornes est évidemment de pouvoir faire évoluer automatiquement la priorité selon la proximité de l'échéance (si spécifiée), le nombre de jours écoulés, ... Deux algorithmes sont disponibles :

• EscalatePriority, la version historique non linéaire. Son inconvénient majeur est de pas affecter la priorité si le nombre de jours restants est supérieur à la différence entre la priorité et la priorité finale ;

• LinearEscalate, qui comme son nom l'indique possède une évolution linéaire et est indépendant des valeurs numériques des priorités.

Il est bien entendu possible d'en implémenter un nouveau si ceux-ci ne vous conviennent pas.

2.4. Relier les tickets : fils et dépendances

Comme vous l'aurez certainement remarqué, il est possible d'établir des relations entre les tickets. Ces relations sont aux nombres de six, organisées en binômes (un fils a toujours un parent, etc) :

• « se rapporte à » est un lien générique vers un autre ticket et génère automatiquement un « mentionné par » en retour ;
• « dépend de » est une déclaration assez intuitive avec en retour « en dépend » ;
• « fils » / « parent » est sémantiquement identique aux dépendances, mais empêche de résoudre le ticket tant qu'il existe un fils en état « nouveau », « ouvert » ou « stagnant ».

2.5. "RT en un coup d'œil" : modifier la page d'accueil

La page d'accueil d'un site RT, « RT en un coup d'œil », est plutôt bien conçue mais ne correspond pas nécessairement aux besoins de votre organisation en général ou aux vôtres en particulier. Heureusement, il est très facile de la réorganiser complètement avec le lien « Modifier » en haut à droite du cadre.

Les éléments du « body » sont affichés en grand format sur la gauche de la page, ceux du « summary » en résumé sur la droite. Il est ainsi possible d'y inclure toutes sortes d'informations, notamment des recherches sauvegardées.

2.6. Tableaux de bord

Mais cette page n'est pas la seule vue d'ensemble dont vous disposez. RT permet de créer des tableaux de bord spécifiques à partir de recherches sauvegardées et de graphiques de relations entre les tickets. Si leur utilisation première est de générer des rapports expédiés par e-mail, il est bien entendu possible de les inclure dans la page d'accueil.

J'aime à les insérer dans la page d'accueil en mode « résumé », mais ils sont aussi disponibles dans le menu « Outils ».

3. Administration

Sans rentrer non plus dans les détails, quelques remarques utiles...

3.1. Types d'utilisateurs

On peut classer les utilisateurs RT en trois grands groupes selon leurs autorisations :

• Ceux qui n'ont accès à rien : ils existent dans la base de données mais ne peuvent pas se connecter à l'interface web. De tels utilisateurs peuvent être générés automatiquement lors de la création d'un ticket par e-mail, si telle est la configuration du système. Dans l'interface d'administration, la case « Donner accès à RT à cet utilisateur » est désactivée.

• Les invités autorisés à utiliser l'interface web : ce sont typiquement des clients, ils peuvent se connecter mais sont limités au « self-service », ils ne voient que leurs propres tickets. Dans ce cas, « Donner accès à RT à cet utilisateur » est activé mais pas « Autoriser cet utilisateur à recevoir des droits ».

• Les utilisateurs privilégiés : ils ont accès à l'interface complète du logiciel, dans la limite des droits qui leur ont été accordés néanmoins.

3.2. Exemples de configurations de droits

Afin de permettre la création de tickets par de tierces personnes via e-mail, le pseudo-groupe « Everyone » doit posséder les droits SeeQueue, CreateTicket, ReplyToTicket, CommentOnTicket sur la file concernée.

Autre configuration typique mais cette fois pour des utilisateurs de confiance, SeeQueue, CreateTicket, ShowTicket, ShowTicketComments, Watch, WatchAsAdminCc, OwnTicket, ModifyTicket, DeleteTicket, TakeTicket, StealTicket, ShowOutgoingEmail, Forward.

Quelques explications :

• « SeeQueue » permet de lister les tickets d'une file ;

• « TakeTicket » autorise un utilisateur à s'assigner un ticket sans propriétaire ;

• « StealTicket » permet au contraire de prendre de force le ticket d'un autre utilisateur ;

• « ModifyTicket » autorise la modification des méta-données du ticket mais inclut aussi « ReplyToTicket » et « CommentOnTicket » ;

• « ShowOutgoingEmail » décrit à quels utilisateurs une notification sera envoyée lors de la création d'un ticket ou de l'ajout d'une réponse/commentaire et permet d'altérer cette liste ;

• « Forward » permet le transfert d'un commentaire à un tiers via e-mail à partir de l'interface web.

4. Adaptation du logiciel (« customization »)

Il est possible d'adapter fortement RT aux besoins d'une organisation via les scrips et templates.

Les scrips (sans « t ») permettent d'associer des actions à des déclencheurs. Plusieurs de ces éléments sont fournis en standard avec RT, et il est bien entendu possible d'en créer d'autres facilement, pour qui possède les rudiments du Perl.

5. Références

• RT Essentials par Jesse Vincent & al, paru en 2005 chez O'Reilly. Un excellent ouvrage (inutile de le préciser, vu l'éditeur) mais qui décrit la version 3.4 du logiciel.

• RT 3.6.0 Released, les nouveautés de la 3.6.

• 3.8.0 now available, les nouveautés de la 3.8.

• RT Wiki, une documentation rédigée par la communauté des utilisateurs.

6. Propriété intellectuelle

Quelques fonctionnalités de RT par Straton IT est mis à disposition selon les termes de la licence Creative Commons Paternité-Pas d'Utilisation Commerciale-Partage des Conditions Initiales à l'Identique 2.0 France.
Basé(e) sur une oeuvre à www.straton-it.fr.