ℹ️
Bug connu : Traitement N1
Cet article s'adresse aux techniciens support Niveau 1. Il décrit la marche à suivre lorsqu'un comportement est déjà référencé dans la BDC Interne ou a déjà fait l'objet d'une remontée précédente, depuis la vérification du bug jusqu'à la clôture du ticket.
Vue d'ensemble du processus
Le N1 confirme d'abord que le bug est connu, transmet le cas au canal existant, puis suit l'intervention du DEV (équipe de développement) jusqu'à la clôture du ticket. Aucune escalade N2 n'est nécessaire lorsque la référence du bug est confirmée : le N1 reste responsable du suivi client et de la clôture.
Le bug est-il référencé dans Stonly ou dans une remontée précédente ?
Oui — bug connu : le N1 applique ce processus directement, sans escalade N2.
Non — bug inconnu : le N1 bascule vers le processus Bug Inconnu N2.
Séquence opérationnelle
Vérifier : confirmez la référence dans Stonly ou dans une remontée précédente.
Documenter : complétez le template de bug connu avec les données du cas client.
Publier : collez le même contenu dans Salesforce et dans le canal Teams du bug existant.
Mettre en attente : informez le client et suivez l'avancement dans Teams.
Recontacter : informez le client ou réalisez l'opération de déblocage demandée.
Clôturer : tracez la résolution et positionnez le ticket au statut Clôturé.
Principe : le bug est déjà identifié. Le plus souvent, une opération doit être réalisée côté développement sur un cas client spécifique.
Vérifier la référence du bug
Avant toute remontée, le technicien doit confirmer qu'il s'agit bien d'un bug déjà connu.
Contrôles obligatoires
Recherchez dans Stonly si une procédure ou une fiche bug existe pour ce comportement.
Vérifiez si une remontée précédente a déjà été effectuée, notamment un ticket Salesforce comportant un numéro Azure associé.
Notez le numéro Azure uniquement lorsqu'il est indiqué dans la fiche Stonly.
Accès Azure : le technicien N1 n'a pas d'accès direct à Azure DevOps (outil de suivi des développements). Le numéro Azure ne doit donc être repris que s'il figure dans Stonly.
Décision après vérification
Référence confirmée : poursuivez le traitement N1 et préparez la remontée de bug connu.
Aucune référence : ne traitez pas le cas comme un bug connu. Suivez le processus Bug Inconnu N2.
Points de vigilance
Ne pas inventer ni rechercher directement un numéro Azure en dehors de Stonly.
S'assurer que le comportement du client correspond réellement à la fiche bug existante.
Utiliser le canal Teams du bug existant afin de conserver tout l'historique au même endroit.
Remplir le template de remontée
Une fois la référence confirmée, le N1 complète un message unique qui sera publié à l'identique dans les deux outils : Salesforce et Teams.
Détail des champs
Équipe concernée : sélectionnez l'équipe adaptée parmi : Alerte plateforme Air ; Bugs - Ancien dossier de soins ; Bugs - Mobile - Donnée bloquée ; Bugs - Mobile - INF ; Bugs - Mobile - KINE ; Bugs - Nouveau dossier de soins ; Bugs critiques - Albus Air et Topaze Air ; Bugs critiques - Comptabilité ; Problèmes - Ordinateur.
Ticket SF (Salesforce) : renseignez le numéro du ticket Salesforce.
Utilisateur : renseignez le prénom et le nom du client. Ce champ sert également de titre au thread Teams ; il doit être renseigné avec soin.
Cabinet : renseignez le nom du cabinet.
Produit + Version : indiquez le produit concerné — AA (Albus Air), TA (Topaze Air), Orthomax by Topaze, Logicmax ou Télévital — ainsi que le numéro de version.
Client toujours en ligne ? : indiquez Oui ou Non.
Client dépanné ? : indiquez Oui ou Non.
N° Azure du bug existant : à renseigner uniquement s'il est présent dans la fiche Stonly.
Explication / cas client : décrivez le comportement observé, les étapes concernées et le message d'erreur, le cas échéant.
Règle de publication
Le contenu publié dans Salesforce et dans Teams doit être strictement identique.
La conversation Teams doit être celle du bug existant, et non une nouvelle conversation isolée.
Modèle à copier-coller — template bug connu
--- REMONTÉE BUG CONNU ---
Équipe concernée :
Ticket SF :
Utilisateur (Prénom Nom) :
Cabinet :
Produit :
Version :
Client toujours en ligne ? (Oui / Non) :
Client dépanné ? (Oui / Non) :
N° Azure du bug existant (si présent dans Stonly) :
Explication / cas client :
--- FIN --- Mettre le ticket en attente et suivre le DEV
Après publication de la remontée, le N1 place le ticket en attente et suit l'intervention dans la conversation Teams associée.
Mettre le ticket en attente
Positionnez le ticket au statut En attente.
Informez le client que le bug a été remonté aux équipes de développement.
Suivez l'avancement dans la conversation Teams associée à la publication.
Statut du ticket : le ticket reste au statut En attente tant que l'intervention développement ou le retour attendu n'est pas finalisé.
Le développeur notifie le N1
Une fois le bug résolu ou l'opération réalisée côté développement, le développeur notifie directement le technicien N1 dans la conversation Teams. Trois cas peuvent alors se présenter :
Résolution DEV : informez le client de la résolution lorsque celui-ci attend un retour.
Action N1 requise : réalisez l'opération de déblocage nécessaire côté N1.
Informations manquantes : reprenez l'échange Teams et fournissez les éléments demandés.
Suite : après le retour du développeur, le N1 revient sur le ticket Salesforce pour recontacter le client et finaliser la clôture.
Recontacter le client
Le N1 reprend contact avec le client après la résolution ou l'opération réalisée côté développement.
Actions à réaliser
Contactez le client par téléphone ou SMS, selon sa préférence ou le contexte.
Informez le client de la résolution du bug si un retour était attendu, ou réalisez l'opération de déblocage nécessaire.
Vérifiez, lorsque cela est possible, que tout fonctionne correctement après l'action.
Choisir la suite
Tout fonctionne : documentez la résolution et clôturez le ticket.
Client à recontacter : conservez le suivi ouvert jusqu'à confirmation ou nouvelle tentative de contact.
Demande complémentaire DEV : retournez dans la conversation Teams du bug existant.
Traçabilité : la publication Salesforce doit indiquer la résolution apportée par le développement, l'action réalisée côté client et le résultat obtenu.
Clôture opérationnelle
Ajoutez une publication dans le ticket Salesforce.
Positionnez le ticket au statut Clôturé uniquement lorsque le suivi est terminé.
Documentez la résolution dans le ticket.
Clôture et demande complémentaire
Modèle à copier-coller — rapport d'intervention
--- RAPPORT D'INTERVENTION - BUG CONNU ---
BUG CONCERNÉ : [N° Azure et/ou lien Stonly]
RÉSOLUTION APPORTÉE PAR LE DÉVELOPPEMENT : [Décrire la correction ou l'opération réalisée côté DEV]
ACTION RÉALISÉE CÔTÉ CLIENT : [Client informé de la résolution / Opération de déblocage réalisée / Aucune action nécessaire]
RÉSULTAT : [Résolu / Client à recontacter / Demande complémentaire en cours]
--- FIN RAPPORT --- Retour vers la conversation Teams
Les développeurs peuvent demander des informations complémentaires avant de finaliser leur intervention.
Reprenez la conversation Teams de la publication.
Apportez les éléments demandés par le développeur.
Reprenez le suivi normal une fois la demande traitée, jusqu'à la clôture du ticket.
Boucle de suivi : tant qu'une information complémentaire ou une action reste attendue, le ticket n'est pas clôturé. Le suivi reprend dans Teams puis revient vers le client.
Checklist de clôture
Le client a été informé de la résolution, si nécessaire.
Le ticket Salesforce contient la résolution et les actions réalisées.
Le statut du ticket est positionné sur Clôturé.
La conversation Teams contient les éléments utiles au suivi du bug existant.
Contacter le N2 : informations à préparer
Ce processus s'applique uniquement lorsque le bug est confirmé comme connu ; aucune escalade N2 n'est donc requise dans ce cas. Si la vérification ne permet pas de confirmer la référence du bug, préparez les éléments suivants avant de basculer vers le processus Bug Inconnu N2 :
Le comportement observé et les étapes permettant de le reproduire.
Le résultat de la recherche Stonly, même infructueuse.
Les informations client (utilisateur, cabinet, produit et version concernés).