Référents : Bug inconnu : Traitement N2

Référents : Bug inconnu : Traitement N2

Cet article s'adresse aux techniciens Niveau 2 et aux référents habilités à créer un bug dans Azure DevOps (outil de suivi des développements). Il décrit la marche à suivre lorsqu'un bug n'est référencé ni dans Stonly ni dans une remontée précédente, généralement à la suite d'une escalade N1 vers N2.

Vue d'ensemble du processus

La criticité du bug détermine immédiatement la branche à suivre :

• Bug critique ou multi-utilisateurs : contact immédiat de l'Incident Manager.

• Bug ponctuel : demande sur le canal Teams Dev, puis validation avant création dans AzureDEV.

Le bug est-il critique ou multi-utilisateurs ?

• Oui — critique / généralisé : contactez immédiatement l'Incident Manager. Le processus s'arrête après la transmission des éléments.

• Non — bug ponctuel : publiez une demande sur le canal Teams Dev, puis attendez la validation des développeurs.

Décision après validation DEV

• Validé : créez le bug sur AzureDEV, puis reportez son numéro dans Salesforce.

• Non validé : appliquez la solution ou le contournement donné par les développeurs.

• À approfondir : complétez l'échange Teams avec logs, captures ou étapes de reproduction.

Préparer la qualification et la sévérité

Avant de qualifier un bug, le N2 consulte les références à jour et vérifie que la procédure n'a pas évolué.

Documentation à consulter

1. Consultez la documentation « Gestion des bugs web » sur Confluence.

2. Vérifiez le canal Teams « Les N2 SOFIA / AIR » pour identifier toute modification récente de procédure.

Déterminer si le bug est critique

• Bug critique / multi-utilisateurs : panne impactant plusieurs utilisateurs, grand nombre d'appels ou blocage généralisé → contactez immédiatement l'Incident Manager.

• Bug ponctuel non critique : bug isolé ou générant peu d'appels → passez par une demande Teams, puis créez le bug AzureDEV si les développeurs valident.

Grille de sévérité

• HIGH : bloquant, avec peu d'appels ou un contournement disponible. Délai indicatif : 2 à 3 semaines.

• MEDIUM : non bloquant ou non impactant. Délai indicatif : plusieurs semaines.

• LOW : mineur. Délai indicatif : plusieurs mois.

--- ALERTE INCIDENT MANAGER --- 
Nombre de clients impactés jusqu'ici : [ex. : 3 cabinets, 8 appels depuis ce matin] 
Criticité supposée : [CRITIQUE / HIGH / MEDIUM / LOW] 
Produit + version : [produit concerné + version] 
DESCRIPTION DU PROBLÈME : [Décrire précisément le comportement observé, les étapes, le message d'erreur...] 
--- FIN --- 

--- REMONTÉE BUG N2 --- 
Équipe concernée : [sélectionner l'équipe / file bug] 
Évaluation de la criticité : [HIGH / MEDIUM / LOW] 
Client(s) impacté(s) : [nom du cabinet / numéro SF] 
Client en ligne ? : [Oui / Non] 
Client dépanné ? : [Oui / Non] 
DESCRIPTION DU PROBLÈME : [Décrire précisément le problème observé] 
IMPACT (nombre d'appels / périmètre) : [ex. : 5 appels, tous les cabinets, depuis ce matin] 
ÉTAPES DE REPRODUCTION : 
1. ... 
2. ... 
3. ... 
Message d'erreur : [message exact affiché, ou « Aucun »] 
Captures / éléments joints : [captures d'écran, logs, vidéo...] 
--- FIN --- 

Publication Salesforce et validation DEV

Publication sur le ticket Salesforce

1. Assignez-vous le ticket.

2. Positionnez le statut sur En attente.

3. Définissez la date d'échéance à aujourd'hui.

4. Reprenez dans la publication Salesforce le contenu du formulaire publié sur le canal Teams Dev.

Validation de la création par les développeurs

Les équipes de développement valident d'abord que la création d'un bug dans AzureDEV est nécessaire.

• Validé : les développeurs confirment la création → passez à AzureDEV.

• Non validé : une solution ou un contournement est fourni directement dans Teams.

Si la demande doit être approfondie

• Retournez dans la conversation Teams Dev.

• Fournissez les logs, captures ou étapes complémentaires demandés.

• Attendez la validation ou la solution avant de poursuivre.

Si validé : créer le bug sur AzureDEV

La création est réalisée par un N2 ou un référent habilité, après validation des développeurs.

Création dans AzureDEV

1. Ouvrez AzureDEV, puis le Backlog Features.

2. Identifiez la Feature « A développer support technique infirmiers et kinés ».

3. Cliquez sur le bouton (+) placé à gauche de la Feature, puis choisissez « BUG ».

4. Titrez le bug au format : (JJ/MM/AA) — Titre du BUG.

5. Copiez-collez le contenu du ticket Salesforce : informations et explication.

6. Choisissez la criticité : HIGH, MEDIUM ou LOW.

7. Renseignez le Produit, le Projet « Support technique » et l'Origine du besoin « Hotline ».

8. Reportez le numéro Azure généré dans le ticket Salesforce, après création.

Champs essentiels AzureDEV

• Titre : (JJ/MM/AA) — Titre du BUG

• Criticité : HIGH / MEDIUM / LOW

• Produit : produit concerné

• Projet : Support technique

• Origine du besoin : Hotline

• Description : contenu du ticket Salesforce (contexte, impact, reproduction et pièces disponibles)

Si non validé ou après résolution DEV

Solution donnée par les développeurs

Les développeurs peuvent résoudre le cas ou fournir un contournement directement dans le canal Teams, sans création AzureDEV.

• Bug résolu : informez le client et clôturez le ticket. Aucune création AzureDEV n'est nécessaire.

• À approfondir : reprenez l'échange Teams et apportez les éléments complémentaires.

Le développeur notifie le N2

Une fois le bug résolu, le développeur identifie le N2 ayant créé le bug et le notifie dans le canal Teams « Bugs résolus ».

Choisir le parcours de retour client

• Le N2 conserve la prise en charge : contactez le client par téléphone ou SMS, informez-le de la résolution et vérifiez si possible que tout fonctionne.

• Le ticket provenait d'une escalade N1 : remettez le ticket au statut Nouveau afin que le N1 reprenne la main et contacte lui-même le client.

Statut « Nouveau » : le retour à ce statut s'applique lorsque le ticket avait été escaladé par un N1 et doit lui être rendu pour le contact client. Reportez-vous à l'article Escalade N1 vers N2 pour plus de détails.

Recontacter le client

• 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.

• Vérifiez, si possible, que tout fonctionne correctement de son côté.

Clôture du ticket Salesforce

La clôture intervient après information du client ou transmission du ticket au N1, selon le parcours retenu.

Actions de clôture

1. Joignez le client pour l'informer de la résolution, si cela n'a pas déjà été fait.

2. Positionnez le ticket au statut Clôturé.

3. Documentez la résolution dans le ticket.

Modèle à copier-coller — rapport d'intervention

--- RAPPORT D'INTERVENTION - BUG INCONNU (AZUREDEV) --- 
N° AZURE DEV : [Numéro du bug créé sur AzureDEV, ou « Résolu sans création Azure »] 
CRITICITÉ RETENUE : [HIGH / MEDIUM / LOW / Basculé en CRITICAL] 
RÉSOLUTION APPORTÉE PAR LE DÉVELOPPEMENT : [Décrire la correction ou le contournement apporté] 
ACTION RÉALISÉE CÔTÉ CLIENT : [Client informé de la résolution / Ticket remis en Nouveau au N1] 
RÉSULTAT : [Résolu / À approfondir / En attente de retour Dev] 
--- FIN DU RAPPORT --- 

Checklist finale

• La branche critique a été arrêtée au niveau de l'Incident Manager, sans création AzureDEV.

• Pour un bug ponctuel, la validation DEV a été obtenue avant toute création AzureDEV.

• Le numéro Azure est reporté dans Salesforce lorsqu'un bug a été créé.

• Le client a été informé ou le ticket a été remis en « Nouveau » au N1.

• La résolution et le résultat sont documentés dans le ticket.

Contacter le N2 : informations à préparer

Ce processus s'applique déjà au niveau N2. Si le bug s'avère finalement connu (référencé dans Stonly ou déjà remonté), redirigez-vous vers l'article Bug Connu N1 plutôt que de poursuivre ce circuit. Avant toute remontée vers l'Incident Manager ou le canal Teams Dev, assurez-vous d'avoir préparé :

• Le nombre de clients impactés et le contexte d'apparition du bug.

• La criticité supposée du bug.

• Le produit et la version concernés.

• Une description précise du comportement observé, avec étapes de reproduction et message d'erreur.