meta données pour cette page
  •  

Ceci est une ancienne révision du document !


Gestion des tickets

Informations qualité

Suivi des modifications majeures juin 2026 - Nicolas Marchand - Refonte complète
5 mars 2015 - Nicolas Marchand - Création du document
27 novembre 2015 - Nicolas Marchand - Evolution vocabulaire, non-gestion du temps dans projeQtOr
27 novembre 2015 - Valentin Barrere - Correction orthographique
02 aout 2017 - Nicolas Marchand - Portage sur DoKuWiKi & Evolutions ajout “A tester”
Suivi des approbations ce fait sur la plateforme de cartographie fonctionnelle
Objet L'objet de ce document est d'indiquer la procédure à suivre lors de la vie d'un ticket
Destinataires - Validation des modifications : Gérant
- Approbation du document : Equipe dev & Equipe Ass

Qualification des tickets

Types de tickets

Type Quand l'utiliser ? Info clé à fournir Priorité Traitement En savoir plus
Bug Le logiciel produit un résultat incorrect ou inattendu Étapes de repro + résultat observé vs attendu Bloquant → Majeur → Mineur Investigation immédiate si bloquant types_tickets_bug.pdf
types_tickets_bug.odt
Évolution La fonctionnalité demandée n'existe pas encore Besoin métier + cas d'usage + critères d'acceptation Selon impact métier et charge estimée Planification sprint / roadmap types_tickets_evolution.pdf
types_tickets_evolution.odt
Amélioration La fonction existe mais pourrait être mieux conçue Usage concerné + problème concret + gain estimé Faible à moyenne selon contexte Backlog, trié par valeur types_tickets_amelioration.pdf
types_tickets_amelioration.odt
Question / Assistance L'utilisateur cherche à comprendre comment faire Ce qu'il essaie de faire + ce qu'il a tenté Non applicable Réponse assistance, pas devs types_tickets_question-assistance.pdf
types_tickets_question-assistance.odt
Arbre de décision
  1. Le logiciel produit un résultat incorrect ou inattendu ? → Bug
  2. La fonctionnalité demandée n'existe pas encore dans le logiciel ? → Évolution
  3. La fonctionnalité existe mais est difficile à utiliser ou trop lente ? → Amélioration
  4. L'utilisateur cherche à comprendre comment utiliser le logiciel ? → Question / Assistance

Les niveaux de gravité

Niveaux de gravité des tickets

Niveau Situation Contournement Délai cible Traitement En savoir plus
Bloquant Travail totalement à l'arrêt, aucun contournement Aucun < quelques heures Investigation immédiate, escalade fiche_bloquant.pdf
fiche_bloquant.odt
Majeur Fonctionnalité dégradée, contournement pénible Pénible ou risqué < quelques jours Priorité haute fiche_majeur.pdf
fiche_majeur.odt
Mineur Bug limité, contournement simple Simple et sans risque Prochain sprint Planification normale fiche_mineur.pdf
fiche_mineur.odt
Amélioration Pas de bug, confort ou nouvelle capacité Non applicable Selon roadmap Backlog, par valeur fiche_amelio_evol.pdf
fiche_amelio_evol.pdf
La règle du contournement
Contournement disponible ? Niveau
Aucun contournement possible Bloquant
Contournement pénible, lent ou risqué Majeur
Contournement simple et sans risque Mineur
Pas de bug — logiciel fonctionnel Amélioration / Évolution
Arbre de décision
  1. Est-ce que personne (ou presque) ne peut travailler normalement ? → Bloquant
  2. Y a-t-il un contournement simple et sans risque ? → Non = Majeur
  3. L'impact est limité et le contournement facile ? → Mineur
  4. Le logiciel fonctionne correctement mais pourrait être mieux ? → Amélioration / Évolution

<note tip> En cas de doute entre deux niveaux → choisir le plus élevé et laisser l'assistance ajuster après investigation. </note>

Le piège le plus courant

<note warning> “Urgent” n'est pas un niveau de gravité. C'est une émotion. Le niveau se base sur l'impact métier réel et l'existence d'un contournement, pas sur la pression ressentie par l'utilisateur. </note>

Etapes de traitement

ResponsableType de ticketUrgence
Niveau 1 (plus urgent)NicolasProblème sur base ClientBloquant
Niveau 2NicolasProblème sur base ClientUrgent
Niveau 3NicolasProblème sur base ClientNon Urgent
Niveau 4NicolasDysfonctionnementBloquant
Niveau 5NicolasDysfonctionnementUrgent
Niveau 6NicolasDysfonctionnementNon Urgent

Etape 1 : Référencement d'une demande

Procédure vis-à-vis du client

La première action à faire vis-à-vis du client est d'identifier sur quelle version du logiciel il travaille. S'il n 'est pas sur la dernière version disponible, il lui est demandé de bien vouloir le mettre à jour, puis de vérifier si le problème persiste.

AUCUNE assistance sur les fonctionnalités n'est faite sur les versions antérieures du logiciel à partir du moment où une mise à jour est publiée. Seules l'assistance à l'évolution de la version et/ou l'aide à la correction conséquente à un problème dû à une version antérieure seront prises en compte.

Chaque cas sera étudié et une réponse sera émise au client dans tous les cas. Celle-ci sera obligatoirement tracée au travers de la procédure d'assistance

Cas où une correction est nécessaire

Si lors d'une demande d'assistance, d'une formation ou de test, un problème nécessitant une action sur le code ou les fichiers annexes est repéré, la procédure est la suivante :

Cas 1 : Problème impliquant uniquement une correction du code
  1. Lancer une session Projeqtor
    • Sélectionner le Projet et la sous-version correspondant à la prochaine version [PROC-Nflog-5 : gestion des versions]
    • Dans “Travail\Bugs”, créer un nouveau Ticket et le remplir comme indiqué plus loin en tenant compte des spécificités listées ci-dessous :
      • Projet = Prochaine sous-version (par défaut si le projet est sélectionné)
      • Type de ticket = “Anomalie / Bug issue - origine client” ou “Anomalie / Bug issue - origine autre”
      • Référence externe = Numéro de ticket OTRS s'il existe. Exemple :Ticket#2015022310000059
      • Responsable = vide
    • NB : Dans le cas où la demande est un doublon par rapport à une demande existante, on se contentera de compléter le ticket existant en ajoutant la référence à la demande du client.
  2. Revenir sur le ticket OTRS
    • Envoyer une réponse à l'utilisateur
    • Faire une note en indiquant en titre “PROJEQTOR –BUGS#XX” et le texte de votre choix
Cas 2 : Problème impliquant uniquement une décision du groupe de travail EPUdF-Logeas
  1. Lancer une session Projeqtor
    • Sélectionner le Projet et la sous-version correspondant à la prochaine version [certif:procedure:develop:gestionversion|PROC-Nflog-5 : gestion des versions]
    • Dans “Journaux des revues\Questions”, créer un nouveau Ticket et le remplir comme indiqué plus loin en tenant compte des spécificités listées ci-dessous :
      • Projet = Prochaine sous-version (par défaut si le projet est sélectionné)
      • Type de ticket = “Assistance - demande d'explication EPUdF” ou “Assistance - demande de correction EPUdF
      • Référence externe = Numéro de ticket OTRS s'il existe. Exemple :Ticket#2015022310000059
      • Responsable = “Jean-Marc DEGON & Michel HAFFNER”
    • NB : Dans le cas où la demande est un doublon par rapport à une demande existante on se contentera de compléter le ticket existant en ajoutant la référence à la demande du client.
  2. Revenir sur le ticket OTRS
    • Envoyer une réponse à l'utilisateur
    • Faire une note en indiquant en titre “PROJEQTOR – TICKET #XX” et le texte de votre choix (obligatoire, mais sans intérêt ..)
Cas 3 : Demande d'évolution du logiciel
  1. Lancer une session Projeqtor
    • Sélectionner le Projet et la sous-version correspondant à la prochaine version [PROC-Nflog-5 : gestion des versions]
    • Dans “Travail\Evolutions”, créer un nouveau Ticket et le remplir comme indiqué plus loin en tenant compte des spécificités listées ci-dessous :
      • Projet = Prochaine sous-version (par défaut si le projet est sélectionné)
      • Type de ticket = “Assistance - demande d'évolution ''
      • Référence externe = Numéro de ticket OTRS s'il existe. Exemple :Ticket#2015022310000059
      • Responsable = vide
    • NB : Dans le cas où la demande est un doublon par rapport à une demande existante, on se contentera de compléter le ticket existant en ajoutant la référence à la demande du client.
  2. Revenir sur le ticket OTRS
    • Envoyer une réponse à l'utilisateur
    • Faire une note en indiquant en titre “PROJEQTOR – TICKET #XX” et le texte de votre choix

Information générique sur la saisie d'un ticket

DescriptionProjetSelon le cas
DescriptionType de ticketSelon le cas
DescriptionNomDonner un titre compréhensible
DescriptionRéférence externeSelon le cas
DescriptionUrgenceNon utilisé
DescriptionDate de créationAutomatique
DescriptionÉmetteurAutomatique, nom de l'utilisateur connecté
NB : Chaque utilisateur doit avoir une session distincte
DescriptionDemandeurNon utilisé
DescriptionOrigineNon utilisé
DescriptionTicket en doublonUtilisation postérieure
DescriptionContexteA remplir si connu
DescriptionProduitIndiquez le produit
DescriptionVersion d'origineIndiquer la version du produit où a été constaté le problème, si connue
DescriptionDescriptionIndiquer le détail du problème
TraitementActivité de planningNe pas utiliser
TraitementEtatMettre “Assigné”
TraitementResponsableAssigner le ticket à la personne qui doit s'en occuper, ce qui envoie un mail à la personne
TraitementCriticitéSelon le cas
TraitementPrioritéSelon le cas
TraitementÉchéance initiale,; actuelleNon utilisé
TraitementTravail estimé, restantNon utilisé
TraitementPris en charge, Fait, ClosAutomatique
TraitementVersion cibleNon utilisé
Avancement Sans objet
Élément prédécesseur / Successeur Généralement Sans Objet
Élément liés Ne pas utiliser
Fichiers attachés Ajouter les documents, bases … qui permettent de mettre en lumière le problème et de tester la solution
Notes Permet d'ajouter des éléments textuels


Etape 2 : Prise en charge par le dev d'une demande

Lancer une session Projeqtor

  1. Sélectionner le ticket correspondant
  2. Le basculer en “En cours”
  3. Initialiser le Traitement\Responsable s'il ne l'est pas

Etape 2bis : Prise en charge par le dev d'une demande (Echec)

Lancer une session Projeqtor

  1. Sélectionner le ticket correspondant : “Travail\Bugs
    • Compléter le ticket dans la partie “Traitement”:
      • Initialiser le Traitement\Responsable s'il ne l'est pas
Activité de planningInitialisé à la création du ticket
Etat Mettre “Assigné”
Responsable Changer le responsable pour l'assigner à quelqu'un d'autre
CriticitéNon utilisé
PrioritéNon utilisé
Échéance initiale,; actuelleNon utilisé
Travail estimé, restantNon utilisé
Pris en charge, Fait, ClosAutomatique
Version cibleNon utilisé
Résultatvide
  • Enregistrer
  • Lier les documents, si il y a lieu (base de test, copie …)
  • Mettre une note si il y a lieu

Etape 3 : Prise en charge par le dev d'une demande (Succès)

Au niveau développement :

  1. Effectuer la correction, la tester
  2. Publier le code sur SVN, en indiquant dans le commentaire le tag du ticket (id=#20)

Au niveau ProjeQtOr

Lancer une session Projeqtor

  1. Sélectionner le ticket correspondant : “Travail\Bug
    • Compléter le ticket dans la partie “Traitement”:
      • Initialiser le Traitement\Responsable s'il ne l'est pas
Activité de planningInitialisé à la création du ticket
Etat Mettre “FAIT”
Responsable ne pas changer
CriticitéNon utilisé
PrioritéNon utilisé
Échéance initiale,; actuelleNon utilisé
Travail estimé, restantNon utilisé
Pris en charge, Fait, ClosAutomatique
Version cibleNon utilisé
Résultatvide
  • Enregistrer
  • Lier les documents, si il y a lieu (base de test, copie …)
  • Mettre une note si il y a lieu

Etape 4 : Mise en place d'une version de test (alpha ou beta)

  1. Lancer une session Projeqtor
  2. Dans les tickets sur le projet concerné, cliquer sur le bouton à droite “Mise à jour multiple”
  3. Sélectionner le(s) ticket(s)/activité(s) correspondant à un état “FAIT”
  4. Initialiser le Traitement\Responsable au créateur du ticket
  5. Les basculer en “A TESTER”