Chapitre 14 — Gestion du cycle de vie du ticket
14.1–14.2 Le ticket, actif central du N1
Le ticket est la seule trace légale, technique, managériale et financière de votre travail. Investir 2 minutes à la création économise 20 minutes en suivi.
Champs obligatoires du « ticket parfait » : titre standardisé ([Catégorie] Symptôme court - Contexte), description structurée, catégorie/type sur 3 niveaux, CI lié, priorité justifiée, groupe/assigné.
14.3–14.4 Catégorisation, affectation
Arborescence : INC-HARD, INC-SOFT, INC-NET, INC-ID, INC-SEC / REQ-ONBOARD, REQ-OFFBOARD, REQ-ACCESS, REQ-SOFT, REQ-HARD. Modèles d'affectation : Pull, Push, Hybride (recommandé). Règle de propriété : celui qui prend le ticket devient Case Owner.
14.5–14.6 Suivi, communication, clôture
Distinction cruciale : Work Notes (privées, jargon technique autorisé) vs Public Notes (visibles utilisateur, langage clair, jamais de jargon).
14.7–14.8 Réouverture & reporting
Réouverture automatique si même utilisateur/symptôme/CI sous 7-10 jours. Vues quotidiennes : « Ma file - Action requise », « Équipe - Entrée (Triage) », « Équipe - SLA en danger », « Équipe - Vieillissement ».
Résumé du chapitre
| Phase | Action clé | Temps |
|---|---|---|
| Triage | Qualifier complètement, envoyer le 1er message | 2-5 min |
| Résolution | Valider l'utilisateur, remplir cause racine, lier la KB | 5-10 min |
| Clôture | Vérifier la checklist zéro défaut | 1 min |
Exercices de validation — Chapitre 14
Q1. Ticket « Urgent : Outlook ne marche plus » en Urgence « Critique ». Première action obligatoire ?
Réponse : qualifier le ticket (symptôme exact, OWA testé, impact réel) et corriger l'urgence si elle n'est pas objectivement justifiée.
Q2. Un reset de cache Teams a corrigé un crash. Pourquoi le code FIXED serait-il incorrect ?
Réponse : c'est un Workaround (la cause racine persiste) — le code correct est WORKAROUND, lié à un Known Error.
Chapitre 15 — Résolution incidents standards (POS)
15.2–15.4 Comptes, messagerie, impression
POS-AUTH-01 (Reset mot de passe) : vérifier l'identité, reset AD/Entra ID, invalider les sessions, communiquer via canal chiffré. POS-AUTH-02 (déverrouillage en boucle) : identifier la source via l'EventID 4740 (CallerComputerName).
POS-MAIL-01 (Outlook déconnecté) : test OWA → nouveau profil → réparation Office → Autodiscover/DNS → add-ins COM.
POS impression : physique/réseau → file d'attente/spouleur → SNMP (piste prioritaire) → pilote V4/Universal → droits/GPO.
15.5–15.9 VPN, performance, logiciels, OneDrive/Teams, fichiers
POS-VPN-01 : routes (split tunnel) → DNS/NRPT → MTU/fragmentation → authentification/certificat/MFA.
POS-PERF-01 : disque 100% → identifier le processus/fichier via Moniteur de ressources ; RAM 95%+ → fuite mémoire, profil volumineux.
POS-FILE-01 : accès refusé → permissions NTFS + partage + profil réseau (Public bloque SMB !).
Résumé du chapitre
| Catégorie | Action moteur |
|---|---|
| Auth | Reset MDP + Unlock + Revoke Sessions |
| OWA test → nouveau profil → réparation Office | |
| Restart Spooler → SNMP OFF → Driver V4 → Droits/GPO | |
| VPN | Routes → DNS/NRPT → MTU → Certificat/MFA |
Exercices de validation — Chapitre 15
VPN connecté, ping IP OK, ping nom d'hôte KO. Piste prioritaire ?
Réponse : Split DNS/NRPT manquant.
Outlook bloqué sur « Chargement du profil », OWA fonctionne. Action N1 #1 ?
Réponse : créer un nouveau profil Outlook.
Chapitre 16 — Exécution des demandes de service
16.3–16.4 Onboarding & offboarding
Onboarding en 10 phases : identité & cloud (J-3) → licences (J-2) → groupes AGDLP → messagerie → matériel (staging Autopilot) → VPN → sécurité/MFA → logiciels métier → périphériques → documentation.
Si on retire la licence avant de révoquer les sessions, l'utilisateur peut rester connecté jusqu'à expiration du token — d'où l'ordre strict.
16.6–16.9 Accès, logiciels, matériel, paramétrages
Workflow Zero Trust pour les demandes d'accès : demande → approbateur (Data Owner/Sécurité) → exécution tracée → validation utilisateur → révision périodique (6-12 mois). Procédure Break-Glass : validation orale tracée, droits limités (4h max), alerte SIEM.
Résumé du chapitre
| Type de demande | Checklist « Prêt à exécuter » |
|---|---|
| Onboarding (J-1) | Compte créé + sync, licence, groupes de rôle, poste pré-stagé, VPN |
| Offboarding (Jour J) | Compte désactivé, sessions révoquées, MFA supprimé, boîte partagée, matériel récupéré |
Exercices de validation — Chapitre 16
Boîte convertie en partagée, Full Access donné au manager, mais boîte non visible après 2 jours. Correction ?
Réponse : vérifier l'AutoMapping ; pour un accès immédiat, ajouter la permission avec -AutoMapping $false et guider le manager pour l'ajouter manuellement.
Chapitre 17 — Escalade & collaboration N2/N3
17.1–17.3 Critères et dossier d'escalade
Le N1 reste Case Owner : l'utilisateur ne doit jamais être renvoyé directement vers le N2/N3. Six critères avant d'escalader : périmètre dépassé, temps/essais épuisés, isolation documentée, dossier technique complet, impact confirmé, workaround appliqué.
17.5–17.6 Suivi, relance, REX
Aucun ticket escaladé ne doit rester sans nouvelle plus de 24h (P2/P3) ou 4h (P1). REX déclenché par : incident majeur, réouverture > 2 fois, gap processus N1 révélé, résolution > 2x le SLA cible.
Résumé du chapitre
| Moment | Action clé | Piège à éviter |
|---|---|---|
| Avant d'escalader | Isolation + workaround + dossier complet | Escalader sans logs |
| Suivi | Relance normée, MAJ quotidienne utilisateur | Oublier le ticket |
Exercices de validation — Chapitre 17
Le N2 demande une capture réseau que vous n'avez pas faite. Meilleure réaction ?
Réponse : la lancer immédiatement via prise en main à distance et la transmettre rapidement.
Un ticket clôturé FIXED revient (réouverture J+2) suite à une régression. Action immédiate ?
Réponse : rouvrir votre ticket (vous restez Case Owner), documenter la régression, relancer le N2.