Remédie une panne de connectivité Windows sans correction à l'aveugle

01Contrat de l’évaluation

assessmentId : BTS-SISR-Y1-WIN-001
blocs        : Bloc 1 + Bloc 2 SISR
compétences  :
- Répondre aux incidents et aux demandes d'assistance et d'évolution
- Exploiter, dépanner et superviser une solution d'infrastructure réseau
format       : remédiation poste client
contexte     : SORIA Distribution — laboratoire synthétique
objectif     : diagnostiquer, corriger, vérifier, documenter

Cette évaluation réutilise la méthode de la leçon conduire-diagnostic-remediation et les outils Windows déjà enseignés. Elle n’introduit pas une nouvelle recette technique.

La cause réelle n’est pas annoncée dans l’énoncé. L’environnement de laboratoire ou l’évaluateur prépare un état dégradé contrôlé parmi les familles autorisées plus bas.

02État de référence connu

Le service attendu est l’intranet pédagogique de SORIA Distribution.

Poste                 : CLIENT-LAB-07
Réseau client         : 10.20.10.0/24
Adresse attendue      : 10.20.10.57/24
Passerelle attendue   : 10.20.10.1
DNS attendu           : 10.20.10.53
Nom du service        : intranet.corp.soria.test
Adresse du service    : 10.20.30.15
Port attendu          : TCP 443
Comportement normal   : la page HTTPS répond depuis les postes autorisés

Un autre poste du même réseau, CLIENT-LAB-08, accède normalement au service au moment du signalement.

Tu dois considérer ces informations comme l’état attendu, pas comme la preuve que CLIENT-LAB-07 les respecte actuellement.

03Symptôme initial

« Depuis CLIENT-LAB-07, intranet.corp.soria.test ne s'ouvre plus.
CLIENT-LAB-08 fonctionne normalement. »

Tu n’as pas le droit de :

réinitialiser toute la pile réseau sans diagnostic ;
désactiver globalement le pare-feu ;
modifier DNS ou routes sur plusieurs postes ;
redémarrer les serveurs par réflexe ;
changer simultanément plusieurs paramètres ;
utiliser une adresse ou un secret réel de production.

04Commence par une collecte reproductible

Tu dois d’abord établir l’état réel du client.

Commandes disponibles côté ligne de commande :

hostname
whoami
ipconfig /all
route print
arp -a
nslookup intranet.corp.soria.test
tracert -d 10.20.30.15

Commandes disponibles côté PowerShell :

Get-NetIPConfiguration
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric
Resolve-DnsName intranet.corp.soria.test -ErrorAction SilentlyContinue
Test-NetConnection 10.20.30.15 -Port 443 -InformationLevel Detailed
Get-NetConnectionProfile
Get-NetFirewallProfile

Tu n’es pas obligé d’exécuter toutes les commandes. Tu dois expliquer pourquoi chaque commande choisie peut confirmer ou affaiblir une hypothèse.

05Établis les faits avant les hypothèses

Produis une fiche de faits :

interface active
adresse / masque
passerelle
serveur DNS
route par défaut
résolution du nom
adresse renvoyée
trajet réseau utile
résultat TCP 443
profil de pare-feu

Écris ensuite au minimum quatre hypothèses distinctes couvrant :

configuration DNS du client
routage / passerelle
service distant ou écoute
pare-feu local ou règle applicable

Une hypothèse n’est pas une conclusion. Pour chacune, précise le test qui peut réellement la départager des autres.

06Utilise des tests discriminants

Exemple de raisonnement attendu :

Si la résolution de nom échoue mais que l'accès direct à 10.20.30.15:443 réussit,
la couche DNS devient prioritaire.

Si le nom se résout correctement mais qu'aucune route utile n'existe,
le diagnostic doit se concentrer sur la configuration de routage.

Si la route et la résolution sont correctes mais que le port est inaccessible,
il faut encore distinguer service arrêté, filtrage local et filtrage intermédiaire.

Ne conclus jamais « pare-feu » uniquement parce qu’un port ne répond pas.

07Inspecte service et pare-feu seulement quand les faits le justifient

Selon l’hypothèse restante :

Get-NetFirewallRule -Enabled True |
  Select-Object DisplayName,Direction,Action,Profile

Get-NetFirewallPortFilter |
  Select-Object Protocol,LocalPort,RemotePort

Get-WinEvent -FilterHashtable @{
  LogName = 'System'
  StartTime = (Get-Date).AddHours(-2)
} | Select-Object TimeCreated,Id,ProviderName,LevelDisplayName,Message

Si tu disposes d’un accès autorisé au serveur pédagogique, l’état du service distant peut être vérifié séparément. Ne transforme pas cette possibilité en obligation : un technicien client doit déjà exploiter les preuves disponibles depuis son périmètre.

08Familles de panne autorisées pour l’environnement d’évaluation

L’évaluateur ou l’environnement automatisé peut préparer une seule cause principale parmi :

A — configuration DNS client incorrecte
B — passerelle ou route client incorrecte
C — service pédagogique indisponible ou non à l'écoute
D — règle de pare-feu locale ciblée qui bloque le flux attendu

La variante réellement utilisée ne doit pas être annoncée à l’étudiant.

Pour une première évaluation de première année, une seule cause principale suffit. Les scénarios multi-causes seront réservés aux remédiations plus avancées.

09N’applique qu’une correction justifiée

Avant le changement, écris :

cause retenue
niveau de certitude
fait décisif
correction proposée
objet exact modifié
risque
condition d'arrêt
rollback
preuve attendue

La correction doit être la plus petite modification raisonnable qui traite la cause démontrée.

Exemples de mauvaises pratiques :

changer DNS + passerelle + pare-feu en même temps ;
réinitialiser toutes les interfaces ;
désactiver la sécurité pour voir si « ça marche » ;
appliquer la correction à tout le réseau pour une panne d'un poste.

10Prépare et vérifie le retour arrière

Le rollback dépend de la variante préparée, mais il doit toujours contenir :

valeur ou état avant changement
commande ou procédure de restauration
condition qui déclenche le rollback
test après restauration

Si l’environnement est virtualisé, un instantané peut servir à remettre le laboratoire dans son état de départ. Il ne remplace pas la documentation du changement effectué par l’étudiant.

11Fais une vraie recette après correction

Le succès doit être démontré à plusieurs niveaux :

1. composant corrigé conforme à l'état attendu ;
2. test discriminant initial rejoué ;
3. résolution DNS correcte si le service utilise un nom ;
4. TCP 443 accessible ;
5. intranet réellement utilisable depuis CLIENT-LAB-07 ;
6. comportement non concerné toujours intact ;
7. si pertinent, un test négatif reste négatif.

Une commande qui retourne « succès » n’est pas forcément une recette de service complète.

12Livrables attendus

Remets :

1. état de référence ;
2. collecte initiale ;
3. tableau faits / hypothèses / tests ;
4. cause retenue et niveau de certitude ;
5. correction et justification ;
6. rollback ;
7. résultats avant/après ;
8. recette du service ;
9. entrée dans le dossier de preuves ;
10. limite de la conclusion.

Entrée minimale du dossier de preuves :

EXIGENCE
Rétablir l'accès au service sans correction à l'aveugle.

CONTEXTE
CLIENT-LAB-07 — laboratoire synthétique SORIA Distribution.

ACTION
Lister les tests et la correction réellement réalisés.

RÉSULTAT + VÉRIFICATION
Conserver la preuve que le symptôme initial a disparu et que le service répond.

LIMITE
Préciser les composants non inspectés ou les causes non exclues par les preuves.

13Grille de correction sur 20

4 pts — collecte initiale exacte et pertinente
5 pts — hypothèses, ordre des tests et raisonnement discriminant
4 pts — correction minimale, sécurité et rollback
4 pts — recette technique et preuve de service
3 pts — documentation, niveau de certitude et limites

Une solution trouvée par essais successifs sans pouvoir expliquer les faits et la cause ne valide pas la méthode de remédiation.

14Indices gradués

Indice 1
Compare CLIENT-LAB-07 à l'état de référence avant de regarder le serveur.

Indice 2
Cherche le premier point de la chaîne où le résultat diverge : adresse, route, DNS,
port ou service.

Indice 3
Un test direct par adresse IP et port peut aider à séparer résolution de nom et
accessibilité du service.

15Remise à zéro du scénario

La remise à zéro doit être contrôlée par l’environnement ou l’évaluateur :

restaurer la valeur de référence du composant modifié ;
relancer les tests de base ;
confirmer que CLIENT-LAB-07 accède au service ;
supprimer les preuves locales de la tentative précédente si elles ne font pas partie du dossier étudiant ;
réinjecter ensuite une variante propre pour une nouvelle tentative.

Le scénario ne doit jamais dépendre d’une infrastructure SORIA réelle.