Cas pratique corrigé et preuves pour l'E5

1. Par exemple : « Quel message s'affiche exactement ? » (quoi) ; « Tout le site est-il touché, ou certains postes ? » (qui) ; « Depuis quand ? Ça marchait vendredi ? » (quand) ; « Les autres applications, la messagerie, Internet fonctionnent-ils ? » (quoi, délimitation) ; « Quelque chose a changé sur le site ce week-end ? » (comment) ; « Combien de personnes et de locataires attendent ? » (impact).
2. Titre : « Vénissieux : logiciel de gestion locative inaccessible pour tout le site ». Description : « Depuis l'ouverture à 8 h, aucun des 35 postes du site de Vénissieux n'accède au logiciel de gestion locative : message "Le serveur est introuvable". La messagerie en ligne et Internet fonctionnent. Le siège n'est pas touché. Locataires en attente à l'accueil. Signalé par M. Petitjean, responsable du site, à 8 h 35. »
3. Incident (un service ne fonctionne plus), catégorie « Réseau > Liaison inter-sites » ou « Logiciel métier > Gestion locative » selon l'arborescence ; la première est plus juste au vu des faits, puisque seul le site distant est touché.

1. Impact fort (tout un site, 35 personnes, le service métier principal, des locataires à l'accueil) ; urgence haute (aucun moyen de travailler, l'accueil du public est bloqué) → P1 critique.
2. Le ticket est créé vers 8 h 37 : prise en charge en 15 minutes, soit avant 8 h 52 ; résolution en 4 heures ouvrées, soit avant 12 h 37.
3. Thomas (groupe Systèmes) en escalade fonctionnelle, car le lien entre sites relève du N2 ; Inès en escalade hiérarchique, car c'est un P1 qui touche le public ; M. Petitjean reçoit le numéro du ticket et l'heure du prochain point.

1. Le changement de vendredi soir sur le routeur du site : la panne touche exactement ce site, depuis la première heure ouvrée qui suit. « Qu'est-ce qui a changé ? » est la question qui rapporte le plus.
2. Délimiter d'abord (c'est fait : seul le site distant, seul ce qui passe par le siège) ; puis, du siège, tester la joignabilité du routeur du site (ping 192.168.30.1) ; consulter la supervision du lien VPN ; vérifier qu'un poste du site joint Internet (déjà confirmé par l'utilisateur) ; si possible, tester la résolution de srv-app depuis un poste du site (le message « serveur introuvable » peut aussi venir du DNS, qui passe lui aussi par le tunnel).
3. Par exemple : « P1, Vénissieux : logiciel de gestion locative injoignable pour les 35 postes depuis 8 h, message "Le serveur est introuvable". Internet et la messagerie en ligne fonctionnent sur le site. Depuis le siège, le routeur du site (192.168.30.1) ne répond pas au ping. Supervision : tunnel VPN Vénissieux DOWN depuis vendredi 22 h 14, juste après le changement de remplacement du routeur. Hypothèse : configuration du tunnel incomplète sur le nouveau routeur. Pas de contournement côté N1. M. Petitjean informé, prochain point promis à 9 h 15. »

1. Nouveau (8 h 37) → En cours (prise en charge par Sarah, puis réattribution au groupe Systèmes) → Résolu à 9 h 24, avec la solution rédigée → Clos quand M. Petitjean confirme que tout le site travaille, ou au terme du délai de clôture automatique.
2. Par exemple : « Bonjour Monsieur Petitjean, l'accès au logiciel de gestion locative est rétabli pour tout le site depuis 9 h 24. Un réglage de la liaison entre votre site et le siège avait été oublié lors du remplacement de votre routeur vendredi soir ; il est corrigé. Pouvez-vous me confirmer que vos équipes travaillent normalement ? Nous allons aussi vérifier pourquoi cette coupure n'a pas été repérée dès vendredi. »
3. Oui : prise en charge avant 8 h 52 (Sarah a pris l'appel à 8 h 35 et travaillé dessus aussitôt), résolution à 9 h 24, bien avant 12 h 37.

1. Oui : c'est un incident majeur (P1, tout un site, accueil du public), et sa cause tient à la façon dont le changement a été mené : on veut éviter que cela recommence lors du prochain remplacement d'équipement.
2. Le site n'accédait plus au logiciel → pourquoi ? Le tunnel VPN vers le siège était coupé → pourquoi ? La clé partagée manquait sur le nouveau routeur → pourquoi ? La configuration a été recopiée à la main, sans liste de contrôle → pourquoi ? Le changement n'avait pas de procédure de migration ni de test du tunnel après la bascule → pourquoi ? Les remplacements de routeurs n'ont jamais été formalisés et la supervision n'alerte personne le week-end. Cause racine : un changement sans plan de tests couvrant le tunnel, et une alerte de supervision que personne ne reçoit hors heures ouvrées.
3. Par exemple : (a) écrire une procédure de remplacement de routeur avec liste de contrôle et test du tunnel, et la classer en modèle de changement : c'est un document de procédure, validé par Inès ; il ne modifie pas l'infrastructure, mais il servira de modèle au prochain changement normal de ce type ; (b) envoyer l'alerte « tunnel VPN DOWN » par SMS à la personne d'astreinte ou, à défaut, en tête de la file du lundi 8 h : c'est une modification de la configuration de la supervision, donc un changement, normal à faible risque (autorisé par Inès) ou standard si la DSI a déjà une procédure pré-autorisée pour ajouter une alerte.
4. Après la bascule : vérifier que le tunnel est monté (état du tunnel sur les deux routeurs, supervision au vert) ; depuis un poste du site, ouvrir le logiciel de gestion locative, accéder à un partage du siège, imprimer ; vérifier la résolution des noms internes. Et un critère de retour arrière : si un test échoue à 22 h 30, remettre l'ancien routeur.

1. Un article interne, par exemple : « Un site entier n'accède plus aux applications du siège mais a Internet : vérifier le tunnel VPN du site ». Symptôme (message « serveur introuvable », Internet fonctionne, un seul site touché) ; cause fréquente (tunnel VPN coupé) ; vérifications N1 (supervision du tunnel, ping du routeur du site depuis le siège) ; escalade immédiate au groupe Systèmes avec ces résultats, en P1 si tout le site est touché. Lié au ticket et au problème.
2. Le volume de tickets (avec les éventuels appels en double rattachés au ticket principal), la disponibilité du logiciel de gestion locative pour le site (1 h 24 d'arrêt en heures ouvrées, de 8 h à 9 h 24), le MTTR des P1 et le taux de respect du SLA (tenu ici). Le post-mortem doit aussi noter que la coupure a commencé vendredi à 22 h 14 et n'a été détectée que le lundi : en heures calendaires, le lien est resté coupé plus de 59 heures.

1. Utile après anonymisation (noms masqués) : elle montre le volume et la variété, mais ne prouve aucune méthode à elle seule.
2. La meilleure preuve, anonymisée : elle montre la qualification, le diagnostic, l'escalade, la communication et le compte rendu.
3. Faible : elle montre un geste, pas le circuit de la demande. Elle n'a de valeur qu'accompagnée du ticket correspondant.
4. Très bonne : elle prouve la capitalisation et la maîtrise de l'outil.
5. Complément : utile pour attester ton rôle, mais trop vague pour prouver la compétence. Une attestation qui cite précisément tes missions vaut mieux.

Une réponse solide cite la priorité, les faits et la limite des droits. Par exemple :

« C'était un P1 : tout le site était bloqué, avec des locataires à l'accueil, donc chaque minute comptait. J'ai d'abord fait les vérifications de mon niveau : délimitation au seul site, routeur injoignable depuis le siège, tunnel VPN en panne dans la supervision juste après le changement de vendredi. La correction demandait d'accéder à la configuration du routeur, ce que mes droits ne permettent pas. J'ai donc escaladé au bout d'une dizaine de minutes avec ces résultats, ce qui a permis à mon collègue de trouver la cause en quelques minutes. »