ℹ️
Processus de remontée/escalade N2 et de bugs
Cet article décrit la procédure à suivre par les agents de support de niveau 1 (N1) lorsqu'un problème rencontré nécessite d'être escaladé vers un référent de niveau 2 (N2). Il couvre les étapes de remontée sur le canal Teams, les informations à fournir, ainsi que les règles d'escalade vers les équipes spécialisées.
Quand remonter une anomalie au N2 ?
Une anomalie doit être escaladée au niveau 2 (N2) lorsque :
Le problème est trop complexe pour être résolu par l’agent N1 en autonomie.
Aucune solution n’a été trouvée après 15 minutes d’échange avec l’utilisateur.
La remontée s'effectue en premier lieu sur le canal Teams dédié : "Support Techno Air".
Informations obligatoires à fournir lors de la remontée :
Avant de publier sur le canal Teams, l'agent N1 doit rassembler et transmettre les informations suivantes :
Identification du client et du contexte
Nom et prénom du client concerné
Nom du cabinet
Version du logiciel cabinet utilisée
Description de l'anomalie
Décrivez clairement l'anomalie rencontrée en précisant les circonstances d'apparition.
Joignez le copier-coller du message d'erreur si celui-ci est disponible.
Ajoutez une capture d'écran uniquement si le copier-coller du message d'erreur est impossible.
Actions déjà réalisées
Listez l'intégralité des manipulations effectuées avant la publication dans le canal.
Cette information est essentielle : elle permet au N2 de connaître les actions déjà tentées et d'éviter de proposer des manipulations redondantes.
Pour finir n'oubliez pas de taguer la balise N2 sur votre demande.
Exemple de remontée :
Règles d'escalade vers le N2
Si la situation nécessite une prise en charge plus approfondie, le référent N2 indiquera à l'agent N1 l'une des deux options suivantes :
Escalader le ticket vers le niveau supérieur, ou
Effectuer une demande auprès du service Développement via le canal dédié.
⚠️ Important : Toute escalade effectuée sans validation préalable du N2 sera automatiquement rebasculée en niveau N1.
Informations à reprendre dans le ticket en cas de remontée N2
En cas de remontée au N2, l'ensemble des informations mentionnées dans les captures d'écran doit être repris intégralement dans le ticket. Cette exigence est indispensable pour assurer :
La bonne reprise du dossier
Le suivi de l'intervention
La résolution efficace de l'anomalie
Remontée Support Développement
Remontée de bugs non bloquant sur Air version Web :
Lorsqu'un bug est suspecté lors d'une remontée N2 sans être bloquant, le ticket d'origine doit être transféré aux N2 sans prise de créneau. Le N2 concerné effectuera ensuite la remontée du bug et assurera son suivi auprès des équipes concernées.
Remontée de bugs bloquant sur Air version Web :
Si, lors d'une remontée N2, un bug est confirmé par le N2 et considéré comme bloquant sans solutions de contournement, le technicien N1 doit publier une remontée dans le canal BUG Critique en utilisant le modèle ci-dessous prévu à cet effet et en joignant tous les éléments nécessaires à son analyse.
Modèle de post Teams à copier-coller et à compléter :
Titre du post : Nom et Prénom du client - Logiciel - Anomalie rencontrée
Contenu :
Utilisateur : Nom et Prénom du client
Cabinet : Nom du cabinet
Version : Albus / Topaze Air 1.20.x
Vu avec le N2 : Prénom du N2
Description détaillée du bug rencontré, accompagnée d'une capture d'écran et/ou d'une vidéo permettant de mieux comprendre l'anomalie et de faciliter son analyse par les développeurs.
Remontée de bugs sur Air Mobile :
Lorsqu'un bug mobile est suspecté ou confirmé par un N2 lors d'une remontée, le technicien N1 doit effectuer une publication dans l'un des canaux BUG Mobile correspondant en respectant le modèle de remontée défini et en joignant tous les éléments nécessaires à son analyse.
Modèle de post Teams à compléter :
Titre : Modèle du téléphone - Version de l'application mobile - Version iOS/Android - Anomalie rencontrée
Contenu :
Indiquer le N2 avec qui la remontée a été validé.
Indiquer le Nom et Prénom du client suivi de la description détaillée du bug rencontré et si possible ou nécessaire, accompagnée d'une capture d'écran et/ou d'une vidéo permettant de mieux comprendre l'anomalie et de faciliter son analyse par les développeurs.
Joindre un DUMP (voir la section Réalisation du DUMP) et indiquer la date et l'heure de celui-ci.
Réalisation du DUMP
Le DUMP (export technique des données de session permettant d'analyser l'état du système au moment de l'anomalie) doit être réalisé après que l'anomalie a été reproduite en présence du client, dans la mesure du possible.
Si la reproduction en direct n'est pas envisageable, il convient de demander au client d'indiquer le créneau horaire de la journée auquel l'anomalie s'est produite, afin de cibler la collecte des données.
Suivi des demandes du support Développement
Si le développeur répond et demande d’effectuer des manipulations complémentaires :
L’agent doit recontacter le client pour réaliser les actions demandées
Une fois le rappel effectué et les manipulations testées :
Faire un retour au développeur en précisant les résultats obtenus
Veiller à mettre à jour et compléter le ticket d’intervention avec :
Les actions réalisées
Les retours du client
Les résultats des tests
Retour après résolution d’une anomalie
Une fois que la résolution de l’anomalie est confirmée avec le client :
L’agent doit effectuer un retour auprès du support Développement.
Ce retour doit être fait là où la demande initiale a été créée.
L’objectif est d’informer de manière explicite de la bonne résolution du problème.