meta données pour cette page
 Retour au Dossier Organisationnel |
|
 Sujets connexes | Cartographie fonctionnelle de LoGeAs Proc#145 : Procédure de Gestion des Versions Proc#168 - Chaîne de qualification et de livraison |
Proc#8 - Gestion des tickets
Informations qualité
| Suivi des modifications majeures | ||
|---|---|---|
| Date | Auteur | Modifications |
| 5 mars 2015 | Nicolas MARCHAND | Création du document |
| 27 novembre 2015 | Nicolas MARCHAND | Évolution du vocabulaire, non-gestion du temps dans ProjeQtOr |
| 27 novembre 2015 | Valentin BARRÈRE | Correction orthographique |
| 2 août 2017 | Nicolas MARCHAND | Portage sur DokuWiki et évolutions : ajout de « À tester » |
| Juin 2026 | Nicolas MARCHAND | Refonte complète |
| Suivi des approbations | Cartographie fonctionnelle – fiche de la procédure |
| Objet | Définir comment qualifier un ticket (type et niveau de gravité) et les étapes de son traitement. |
| Destinataires | - Validation des modifications : Gérant - Approbation du document : Équipe développement et équipe assistance |
| Origine | Ce document correspond à l'ancien élément ProjeQtOr Document #04 « Procédure de prise en charge d'un ticket ». |
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 reproduction + résultat observé et résultat 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 par l'assistance, pas par les développeurs | types_tickets_question-assistance.pdf types_tickets_question-assistance.odt |
Arbre de décision
- Le logiciel produit un résultat incorrect ou inattendu ? → Bug
- La fonctionnalité demandée n'existe pas encore dans le logiciel ? → Évolution
- La fonctionnalité existe mais est difficile à utiliser ou trop lente ? → Amélioration
- L'utilisateur cherche à comprendre comment utiliser le logiciel ? → Question / Assistance
Niveaux de gravité
| 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 / Évolution | Pas de bug, confort ou nouvelle capacité | Non applicable | Selon roadmap | Backlog, par valeur | fiche_amelio_evol.pdf fiche_amelio_evol.odt |
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 : le logiciel fonctionne | Amélioration / Évolution |
Arbre de décision
- Est-ce que personne (ou presque) ne peut travailler normalement ? → Bloquant
- Y a-t-il un contournement simple et sans risque ? → Non = Majeur
- L'impact est limité et le contournement facile ? → Mineur
- 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 fonde sur l'impact métier réel et sur l'existence d'un contournement, pas sur la pression ressentie par l'utilisateur. </note>
Étapes de traitement
Les numéros sont ceux du schéma.
| N° | Étape | Qui | Ce qui se passe | Suite |
|---|---|---|---|---|
| 1 | Saisie du ticket | Utilisateur | L'utilisateur décrit sa demande ou son problème. | 2 |
| 2 | Qualification | Assistance | L'assistance détermine le type du ticket et son niveau de gravité (voir « Qualification des tickets »). | 3 |
| 3 | Infos suffisantes ? | Assistance | L'assistance vérifie que le ticket contient les informations nécessaires. | Oui : 5 Non : 4 |
| 4 | Demande d'informations | Utilisateur | L'utilisateur reçoit une demande de précisions et complète son ticket. | 1 |
| 5 | Type de ticket ? | Assistance | Le ticket est orienté selon son type. | Question / Assistance : 6 Bug : 11 Amélioration / Évolution : 10 |
| 6 | Escalade si nécessaire | Assistance | L'assistance traite la question et la transmet au niveau supérieur si besoin. | 7 |
| 7 | Réponse de l'assistance | Utilisateur | L'utilisateur reçoit la réponse. | 8 |
| 8 | Résolu ? | Utilisateur | L'utilisateur indique si la réponse règle sa demande. | Oui : 9 Non : 1 |
| 9 | Clôture | Utilisateur | Le ticket est clos comme résolu. | fin |
| 10 | Analyse et planification | Équipe | L'équipe analyse la demande d'amélioration ou d'évolution et la planifie. | 13 |
| 11 | Analyse et qualification | Développeur | Le développeur analyse le bug. | 12 |
| 12 | Infos suffisantes ? | Développeur | Le développeur vérifie qu'il a de quoi reproduire et corriger. | Oui : 13 Non : 7 |
| 13 | Développement | Développeur | Correction ou réalisation. | 14 |
| 14 | Tests de recette | Équipe | Tests des fonctions concernées et de non-régression. | 15 |
| 15 | Tests passés ? | Équipe | Décision à l'issue des tests. | Oui : 16 Non : 13 |
| 16 | Déploiement en production | Développeur | La version corrigée est mise en production. | 17 |
| 17 | Notification et clôture | Utilisateur | L'utilisateur est informé, le ticket est clos. | fin |
Pour LoGeAs Web, les étapes 14 à 16 (tests de recette, décision, déploiement) suivent Proc#168 - Chaîne de qualification et de livraison.