Pratique des études de cas écrites jusqu'au format long chronométré

01Ce module n’est pas un nouveau cours technique

Tu as déjà travaillé :

poste client
Windows Server / AD / DNS / DHCP / GPO
Linux
routage / commutation / VLAN / pare-feu
services web / DMZ
sauvegarde / haute disponibilité
GLPI / patrimoine
supervision
Wi-Fi / ToIP / capacité
cybersécurité
incident / remédiation

Ici, l’objectif est différent : lire et exploiter un dossier que tu ne connais pas.

Le fil d’entraînement est :

micro-cas ciblé
-> cas multi-documents court
-> cas transversal intermédiaire
-> étude de cas longue chronométrée

02Adopte une grammaire de réponse stable

Pour toute question technique, sépare six éléments :

FAIT
ce que la pièce montre réellement

INTERPRETATION
ce que ce fait signifie dans le contexte

HYPOTHESE
ce qui pourrait expliquer le problème mais reste à démontrer

SOURCE
la pièce, la ligne, le schéma ou le journal utilisé

DECISION / TEST
ce que tu proposes et comment tu vérifieras

LIMITE
ce que les pièces ne permettent pas d'affirmer

Exemple :

Fait        : le ticket indique que le service répond par IP mais pas par nom.
Source      : pièce B, ticket 14.
Interprétation : la connectivité IP vers le service semble possible dans ce test.
Hypothèse   : la résolution DNS peut être en défaut.
Test        : interroger le résolveur configuré puis comparer l'enregistrement attendu.
Limite      : ce ticket seul ne prouve ni une panne DNS générale ni la disponibilité applicative.

03Lis les documents dans trois couches

Couche 1 — métier

qui utilise le service ?
pourquoi ?
quelle indisponibilité est acceptable ?
quelle donnée doit être protégée ?
quelle contrainte de coût / délai / exploitation existe ?

Couche 2 — architecture

zones
hôtes
services
flux
dépendances
identités
stockage / sauvegarde
supervision

Couche 3 — preuves

logs
captures
commandes
états de service
alertes
inventaires
historique de changement

Un détail technique n’a de sens que s’il est relié aux deux autres couches.

04Niveau 1 — micro-cas ciblé

Durée indicative : 20 à 30 minutes.

Nombre de pièces : 2 à 3.

Objectif : isoler une dépendance sans bruit documentaire important.

Exemple de sujet

Pièces :

A — ticket : CLIENT-07 n'accède plus à intranet.soria.lab
B — ipconfig/ifconfig synthétique du client
C — résultat de deux requêtes DNS

Questions :

1. relève trois faits ;
2. propose deux hypothèses ;
3. choisis le test qui les sépare le mieux ;
4. propose une correction seulement si les pièces la justifient ;
5. écris le test de recette.

Barème court : faits 3, hypothèses 2, test 2, décision 2, limite 1.

05Niveau 2 — cas multi-documents court

Durée indicative : 45 à 60 minutes.

Nombre de pièces : 4 à 6.

Objectif : croiser au moins deux domaines.

Exemple de sujet

Un service web interne devient inaccessible depuis un VLAN mais reste accessible depuis le réseau d’administration.

Pièces :

A — schéma réseau
B — ticket utilisateur
C — extrait de règles de pare-feu
D — état du service web
E — résolution DNS
F — historique de changement

Questions :

1. cartographie le chemin client -> service ;
2. indique quelles pièces démontrent que le service lui-même fonctionne ou non ;
3. classe les hypothèses ;
4. identifie le changement récent pertinent ou non pertinent ;
5. propose une modification minimale avec rollback ;
6. rédige un test positif et un test négatif.

06Niveau 3 — cas transversal intermédiaire

Durée indicative : 90 minutes.

Nombre de pièces : 6 à 9.

Objectif : traiter plusieurs symptômes sans supposer une cause unique.

Exemple de sujet

symptôme 1 : échecs d'ouverture de session sur un groupe d'utilisateurs
symptôme 2 : alerte Centreon sur le DNS secondaire
symptôme 3 : lenteur d'une application interne

Pièces possibles :

schéma AD/DNS
journaux d'authentification synthétiques
état de réplication
alerte de supervision
inventaire des VM
historique de changement
ticket métier
extrait réseau
politique de disponibilité

Livrable :

chronologie courte
faits par symptôme
hypothèses communes et indépendantes
preuves pour / contre
priorité métier
tests discriminants
plan d'action borné
limites

La bonne réponse peut conclure que deux symptômes ne sont pas liés.

07Niveau 4 — étude de cas longue chronométrée

Durée cible d’entraînement : 4 heures.

Cette durée prépare notamment au travail long sur dossier prévu dans le fil rouge. Le format exact d’une épreuve officielle doit toujours être vérifié dans les consignes officielles applicables à la session concernée.

Le dossier comporte typiquement 10 à 16 pièces :

contexte métier
schéma d'architecture
inventaire
plan d'adressage
configuration réseau
politique de sécurité
tickets
journaux
alertes de supervision
état de sauvegarde
historique de changement
contrainte budgétaire / capacité
extrait de procédure

Le sujet mélange conception, exploitation, sécurité, diagnostic et justification.

08Organise les quatre heures

Plan d’entraînement indicatif, à adapter :

0:00 - 0:20  lecture rapide du contexte et des questions
0:20 - 0:45  cartographie des pièces, services, zones et dépendances
0:45 - 2:45  traitement structuré des questions
2:45 - 3:30  questions transversales / calculs / préconisations
3:30 - 3:50  contrôle des preuves, cohérence et réponses incomplètes
3:50 - 4:00  relecture finale

Ce découpage est un outil pédagogique, pas une règle officielle.

Si une question bloque :

note l'hypothèse
cite ce que tu sais
identifie ce qui manque
avance
reviens ensuite

Ne sacrifie pas une heure à chercher une certitude impossible à partir des pièces.

09Construis une carte des pièces

Avant les réponses longues, crée un tableau rapide :

Important : une pièce peut être incorrecte, incomplète ou obsolète. Sa présence ne la rend pas vraie par définition.

10Interprète les schémas

Pour chaque schéma, cherche :

frontières de zone
routes / passerelles
services partagés
redondance annoncée
points uniques de panne possibles
flux d'administration
dépendances DNS / identité
exposition externe

Puis compare le schéma avec les configurations et les faits. Une incohérence entre documents est elle-même une information.

11Interprète les journaux et alertes

Un journal répond à des questions limitées :

qui / quoi ?
quand ?
où ?
quel résultat observé ?
quelle source a produit l'événement ?

Avant de corréler :

vérifie l'horodatage
vérifie la source
vérifie l'identité ou l'hôte
vérifie si plusieurs événements décrivent réellement la même action

Une alerte n’est pas une cause. Un log d’erreur n’est pas automatiquement l’erreur principale.

12Interprète les configurations

Ne réécris pas toute la configuration.

Extrait seulement :

paramètre concerné
valeur observée
valeur attendue d'après une autre pièce
impact possible
test permettant de confirmer

Pour une règle réseau, pense toujours :

source
destination
protocole / service
action
ordre
zone

13Interprète inventaires, tickets et politiques

Inventaire

Il informe sur :

actif
rôle
version / support si fourni
capacité
propriétaire ou service concerné

Il ne prouve pas que l’actif est réellement en ligne à l’instant du problème.

Ticket

Il informe sur l’expérience déclarée et l’heure approximative. Il ne remplace pas une mesure technique.

Politique

Elle donne l’attendu organisationnel : accès, sauvegarde, rétention, sécurité, disponibilité. Elle ne prouve pas que l’attendu est appliqué.

14Réponds aux questions de préconisation

Une préconisation solide contient :

besoin
faits utiles
contraintes
solution retenue
alternative crédible
raison du choix
risque résiduel
critère de recette
mesure de suivi
seuil de réévaluation

Évite :

"migrer vers le cloud" sans contrainte ni architecture
"ajouter de la redondance" sans dépendance identifiée
"renforcer la sécurité" sans contrôle précis
"augmenter la bande passante" sans mesure ni calcul

15Révise une hypothèse quand une nouvelle pièce arrive

Exercice pédagogique : le formateur distribue une pièce supplémentaire après 20 minutes.

Le candidat doit répondre :

quel fait nouveau apparaît ?
quelle hypothèse monte ?
quelle hypothèse baisse ?
quelle conclusion antérieure doit être réécrite ?
quel test devient prioritaire ?

Changer d’avis face à une meilleure preuve est une compétence, pas une erreur.

16Générateur de cas pour le formateur

Pour créer une variante sans changer les compétences :

1. choisir un besoin métier ;
2. choisir 3 à 5 domaines déjà enseignés ;
3. dessiner l'architecture saine de référence ;
4. injecter 1 à 3 écarts ;
5. produire une pièce factuelle par dépendance importante ;
6. ajouter au maximum un indice non causal ;
7. préparer les critères de preuve ;
8. définir ce que le dossier ne permet pas de conclure ;
9. construire le barème avant de distribuer le sujet ;
10. vérifier qu'aucune commande ou technologie non enseignée n'est indispensable sans documentation fournie.

Familles de variantes :

réseau + DNS + service web
AD + GPO + supervision
DHCP + VLAN + Wi-Fi invité
sauvegarde + stockage + disponibilité
ToIP + congestion + capacité
DMZ + TLS + pare-feu + supervision
patrimoine + capacité + incidents + budget
identité + journalisation + incident

17Barème commun des études de cas

Adapter la pondération au niveau, mais conserver les critères :

La note finale ne doit pas récompenser une bonne intuition non justifiée davantage qu’un raisonnement correctement sourcé.

18Grille d’auto-vérification

Avant de rendre :

[ ] ai-je répondu à la question posée ?
[ ] ai-je séparé faits et hypothèses ?
[ ] ai-je cité les pièces utiles ?
[ ] ai-je détecté les contradictions entre documents ?
[ ] mes calculs montrent-ils les hypothèses ?
[ ] mes changements sont-ils bornés ?
[ ] ai-je prévu une recette ?
[ ] ai-je inclus un test négatif quand il est pertinent ?
[ ] ai-je indiqué le risque / rollback ?
[ ] ai-je écrit ce que je ne peux pas conclure ?