Évalue une intervention de support et qualifie la décision

01Contrat de l’évaluation

assessmentId : BTS-SISR-Y1-SUPPORT-001
bloc         : Bloc 1
compétences  :
- Gérer le patrimoine informatique
- Répondre aux incidents et aux demandes d'assistance et d'évolution
format       : scénario de support évalué
contexte     : SORIA Distribution — données entièrement fictives
objectif     : qualifier, décider, agir de manière bornée, vérifier et documenter

Cette activité n’est pas une nouvelle leçon GLPI. Elle réutilise les compétences déjà travaillées : ticket, impact, urgence, priorité, inventaire, habilitation, diagnostic et dossier de preuves.

Aucune donnée réelle de SORIA, aucun secret et aucune topologie de production ne sont utilisés.

État de référence pédagogique

Avant dégradation, l’utilisateur pédagogique OPERATEUR-EXP-07 doit accéder au partage \\FS-LAB-01\EXPEDITION grâce au rôle approuvé OPERATEUR_EXPEDITION. L’accès doit être accordé par appartenance au groupe prévu par le modèle d’habilitation ; aucun droit direct sur l’utilisateur n’est nécessaire. Le poste LAB-WS-107 est inventorié et le service de fichiers est disponible.

Variantes contrôlées pour l’évaluateur

Une seule variante principale est préparée par tentative et elle n’est pas annoncée à l’étudiant :

A — habilitation métier approuvée, mais appartenance au groupe attendu absente ;
B — aucune preuve d'approbation métier : l'accès ne doit pas être accordé ;
C — habilitation et groupe corrects, mais la session conserve un jeton antérieur au changement.

Conséquences attendues :

A → restaurer uniquement l'appartenance justifiée, puis renouveler la session si nécessaire ;
B → ne modifier ni groupe ni ACL ; documenter et escalader pour obtenir l'autorisation ;
C → actualiser la session et vérifier le jeton avant toute modification d'habilitation.

Le scénario interdit les droits directs ajoutés sur le partage pour contourner le modèle d’habilitation.

Remise à zéro du scénario

Après chaque tentative, l’environnement ou l’évaluateur doit :

restaurer l'appartenance de référence selon la variante ;
supprimer tout droit direct éventuellement ajouté pendant la tentative ;
restaurer l'état de session attendu ;
remettre le ticket pédagogique dans son état initial ;
supprimer les preuves locales qui ne font pas partie du dossier étudiant ;
vérifier que l'état de référence est retrouvé avant d'injecter une nouvelle variante.

Cette procédure garantit qu’une seconde tentative ne dépend pas des modifications de la précédente.

02Symptôme initial

À 14 h 10, le service expédition ouvre un ticket :

« Depuis le remplacement de mon poste ce matin, je n'arrive plus à ouvrir
le dossier des bons de livraison. Mes collègues y accèdent.
Un départ transport est prévu à 14 h 50. »

Tu prends en charge le ticket à 14 h 15.

Tu n’as pas le droit de modifier un groupe, un partage, une règle de sécurité ou un serveur tant que la nécessité et l’autorisation ne sont pas démontrées.

03Données synthétiques disponibles

Utilisateur pédagogique : OPERATEUR-EXP-07
Équipe                  : Expédition — 5 personnes
Poste actuel             : LAB-WS-107
Ancien poste             : LAB-WS-044
Partage attendu          : \\FS-LAB-01\EXPEDITION
Rôle métier déclaré      : opérateur expédition
Échéance métier          : départ transport dans 35 minutes

Extrait d’inventaire :

LAB-WS-107
- affecté ce matin au rôle OPERATEUR-EXP-07
- Windows 11
- inventaire à jour
- connectivité réseau générale disponible

LAB-WS-044
- ancien poste
- statut : RETRAIT_EN_ATTENTE_EFFACEMENT
- ne doit pas être remis en circulation avant preuve d'effacement

Extrait d’habilitation pédagogique :

Rôle : OPERATEUR_EXPEDITION
Accès attendu : EXPEDITION_RW
Propriétaire de l'accès : Responsable Expédition LAB
État d'approbation : fourni par la variante d'évaluation

Premières observations fournies :

- l'intranet pédagogique fonctionne depuis LAB-WS-107 ;
- les quatre autres membres de l'équipe ouvrent le partage ;
- OPERATEUR-EXP-07 obtient « Accès refusé » sur le partage ;
- aucune panne générale de FS-LAB-01 n'est signalée.

Ces éléments orientent le diagnostic, mais ils ne remplacent pas tes propres vérifications.

04Qualifie le ticket

Tu dois écrire dans le ticket :

nature de l'objet : incident, demande, problème ou changement ?
service affecté
utilisateur / équipe concernés
symptôme exact
heure de début connue
impact
urgence
priorité obtenue
justification de la priorité

Pour cette évaluation, utilise la matrice pédagogique suivante :

IMPACT
1 = service critique ou site entier
2 = équipe ou plusieurs utilisateurs
3 = utilisateur unique

URGENCE
A = blocage avec échéance métier inférieure à 1 heure
B = activité dégradée à traiter dans la journée
C = gêne sans échéance immédiate

PRIORITÉ
1A/2A = P1
3A/1B/2B = P2
3B/1C/2C = P3
3C = P4

La priorité est calculée à partir du contexte fourni. Tu dois signaler explicitement si une information te manque au lieu de l’inventer.

05Construis les hypothèses avant toute correction

Établis au minimum quatre hypothèses, par exemple autour de :

poste remplacé
identité ou session
résolution / accès réseau
appartenance à un groupe
permissions du partage
état du serveur

Pour chaque hypothèse, indique :

fait qui la soutient
fait qui l'affaiblit
test discriminant choisi
résultat observé
état : À TESTER / SOUTENUE / AFFAIBLIE / RÉFUTÉE / INCONCLUSIVE

Ne transforme pas « poste remplacé ce matin » en cause certaine : c’est seulement un événement corrélé dans le temps.

06Collecte des preuves minimales

Tu dois conserver au moins :

preuve de l'identité de session
preuve de connectivité vers le serveur ou le service attendu
preuve d'appartenance aux groupes pertinents
preuve de l'habilitation ou de son absence
preuve de l'état du partage ou du chemin
lien avec l'actif LAB-WS-107

Exemples d’outils possibles selon l’environnement :

whoami /user
whoami /groups
Test-NetConnection FS-LAB-01 -Port 445
Test-Path '\\FS-LAB-01\EXPEDITION'

Une capture « Accès refusé » seule ne suffit pas : elle prouve le symptôme, pas la cause ni l’autorisation de corriger.

07Décide une action bornée

Avant toute action, produis une fiche :

cause retenue + niveau de certitude
modification proposée
périmètre exact
preuve que l'action est autorisée
risque
condition d'arrêt
retour arrière
preuve attendue après correction

Si l’habilitation n’est pas explicitement approuvée, tu ne dois pas accorder l’accès pour « aller plus vite ». L’escalade avec un dossier propre est alors la bonne décision professionnelle.

Si l’action est autorisée, elle doit viser l’objet minimal nécessaire. Une correction globale du partage ou du serveur pour un problème limité à un utilisateur est disproportionnée.

08Vérifie le service après intervention

La recette doit comprendre :

1. vérifier l'état du composant modifié ;
2. rejouer l'accès qui échouait ;
3. confirmer que l'utilisateur ouvre réellement le dossier attendu ;
4. confirmer qu'un accès non prévu n'a pas été ajouté ;
5. enregistrer l'heure et le résultat dans le ticket.

Si une nouvelle ouverture de session est nécessaire pour actualiser le jeton, documente-la au lieu de conclure trop tôt que la correction a échoué.

09Ne perds pas la dimension patrimoine

Le remplacement du poste fait partie du contexte, même si le poste n’est finalement pas la cause.

Tu dois vérifier que :

LAB-WS-107 est bien relié à l'utilisateur pédagogique ;
LAB-WS-044 reste en retrait contrôlé ;
aucune remise en service de l'ancien poste n'est proposée comme contournement non tracé ;
la preuve d'effacement de LAB-WS-044 reste une action patrimoine distincte.

Une bonne intervention de support ne dégrade pas le cycle de vie des actifs pour résoudre plus vite un ticket.

10Livrables attendus

Remets :

1. ticket qualifié et priorisé ;
2. tableau faits / hypothèses / tests ;
3. preuves limitées aux éléments utiles ;
4. décision d'intervention ou d'escalade ;
5. rollback ;
6. recette après action ;
7. entrée pour le dossier de preuves ;
8. limite : ce que tes preuves ne démontrent pas.

Entrée minimale du dossier de preuves :

EXIGENCE
Qualifier et traiter un incident utilisateur sans contourner les habilitations.

CONTEXTE
SORIA Distribution — scénario synthétique BTS de première année.

ACTION
Décrire les observations, tests et action réellement réalisés.

RÉSULTAT + VÉRIFICATION
Conserver le test qui montre le retour du service attendu ou la décision justifiée de ne pas modifier les droits.

LIMITE
Expliquer ce qui n'a pas été vérifié au-delà du périmètre de l'intervention.

11Grille de correction sur 20

4 pts — qualification du ticket, impact, urgence, priorité
4 pts — qualité et pertinence des preuves
4 pts — diagnostic et décision bornée / autorisée
4 pts — recette, rollback et absence de contournement
4 pts — documentation, patrimoine et limite de preuve

Une intervention qui « rétablit l’accès » mais contourne une habilitation ou modifie inutilement un périmètre large ne peut pas obtenir la totalité des points techniques.

12Indices gradués

N’utilise un indice qu’après avoir documenté ce que tu as déjà vérifié.

Indice 1
Compare ce qui dépend du poste avec ce qui dépend de l'identité.

Indice 2
Cherche une preuve qui distingue « le serveur refuse tout le monde » de
« cet utilisateur ne possède pas le droit attendu ».

Indice 3
Relie toujours une correction d'habilitation à son approbation avant de l'appliquer.