Diagnostiquer et dépanner un réseau local, un accès Internet, un partage et un Wi-Fi

P3.1 — « Câble réseau non connecté » / aucun voyant de lien

Fréquence : très fréquent · Gravité : bloquante pour le poste, faible pour le réseau

1. Symptômes observables

• Icône réseau : globe barré ou écran avec croix ; « Câble réseau non connecté » / « Non connecté ».
• ipconfig : « Statut du média . . . : Média déconnecté » ; Linux ip link : state DOWN, NO-CARRIER.
• Voyants de la carte et du port du switch éteints (ou orange fixe sans activité selon le modèle).

2. Causes possibles (classées)

1. Cordon débranché ou mal enfiché (clip cassé) — utilisateur/câble.
2. Cordon de brassage ou cordon poste abîmé — câble.
3. Port du switch éteint, désactivé (switch administrable) ou switch hors tension — équipement.
4. Carte réseau désactivée dans Windows (« Désactivé ») ou pilote absent — OS.
5. Prise murale / câble capillaire coupé, mauvais brassage au panneau — câblage (Fiche 3).
6. Carte réseau défectueuse — matériel (rare, à prouver par élimination).

3. Questions initiales et sécurité

• « Avez-vous déplacé le PC, fait le ménage, changé de bureau ? » « Les collègues ont-ils le réseau ? »
• Ne pas débrancher de câble au switch/panneau sans repérage (étiquette) : tu pourrais couper un autre utilisateur ou le serveur.

4. Diagnostic pas à pas

1. Vérifier l'enfichage aux deux bouts (clic du connecteur) — attendu : voyant de lien qui s'allume en 2–3 s.

   SI le voyant s'allume → cause : cordon mal enfiché ; contrôler que le clip tient.

   SINON → étape 2.

2. Panneau de configuration → Centre Réseau et partage → Modifier les paramètres de la carte (Windows 10/11 : ncpa.cpl) — attendu : carte « Ethernet » non grisée.

   SI « Désactivé » → clic droit → Activer. Si la carte n'apparaît pas → Gestionnaire de périphériques (→ Fiche 2 · Pilote).

   SINON → étape 3.

3. Remplacer le cordon poste–prise par un cordon testé — attendu : lien.

   SI le lien revient → cordon défectueux.

   SINON → étape 4.

4. Brancher le poste sur une prise voisine qui fonctionne (ou un portable connu sur la prise suspecte) — isole poste / infrastructure.

   SI le poste a le lien ailleurs → problème de prise / câble capillaire / brassage / port de switch : vérifier le voyant du port au switch, changer de port, tester le lien avec un testeur → Fiche 3 · Testeur.

   SINON (pas de lien nulle part, même avec cordon neuf) → carte ou pilote : tester une carte USB-Ethernet ; si elle fonctionne → carte intégrée en défaut.

5. Test de confirmation

Le symptôme suit l'élément suspect quand on le déplace (le cordon défectueux casse aussi le lien d'un poste sain). Limite : un câble qui « donne le lien » peut encore être défectueux (paires inversées ou split pair → lien à 100 Mb/s ou erreurs) : validation au testeur (F3).

6. Correction

• Remplacer le cordon / réparer ou ré-sertir la prise (F3) / réactiver la carte ou le port / changer de port et mettre à jour le repérage.
• Carte HS : carte additionnelle PCIe ou USB-Ethernet, désactivation de l'intégrée dans le BIOS si conflit.

7. Validation

Voyant fixe + activité ; « État » de la carte : vitesse 1,0 Gbit/s (pas 100 Mbit/s si câble Cat5e/6 et matériel Gigabit) ; ipconfig montre une adresse valide ; ping passerelle ; test utilisateur.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.2 — Adresse 169.254.x.x (APIPA) : pas d'adresse DHCP

Fréquence : très fréquent · Gravité : bloquante (le poste ne voit que les autres 169.254)

1. Symptômes observables

Carte Ethernet Ethernet :
   Suffixe DNS propre à la connexion. . . :
   Description. . . . . . . . . . . . . . : Intel(R) Ethernet Connection I219-V
   Adresse physique . . . . . . . . . . . : 3C-52-82-1A-2B-01
   DHCP activé. . . . . . . . . . . . . . : Oui
   Configuration automatique activée. . . : Oui
   Adresse IPv6 de liaison locale. . . . .: fe80::8d4c:2a1b:9e3f:12c4%12(préféré)
   Adresse d'autoconfiguration IPv4 . . . : 169.254.83.17(préféré)
   Masque de sous-réseau. . . . . . . . . : 255.255.0.0
   Passerelle par défaut. . . . . . . . . :
   Serveurs DNS. . .  . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1

• Lignes clés : « DHCP activé : Oui » + « Adresse d'autoconfiguration IPv4 » 169.254.x.x + masque 255.255.0.0 + AUCUNE passerelle + pas de « Serveur DHCP » ni de bail.
• Icône « Réseau non identifié » / « Pas d'accès Internet ». Linux : pas d'adresse inet sur l'interface (ou 169.254 si avahi-autoipd).

2. Causes possibles (classées)

1. Le poste n'atteint pas le serveur DHCP : lien physique dégradé, mauvais port/VLAN, Wi-Fi associé mais authentification en cours.
2. Serveur/box DHCP arrêté, planté ou DHCP désactivé dans la box (souvent après remplacement de matériel).
3. Étendue DHCP épuisée (« no address available ») : trop d'appareils, baux trop longs (invités, smartphones).
4. Filtrage : contrôle d'accès MAC sur la box, port sécurisé 802.1X, pare-feu tiers.
5. Service « Client DHCP » arrêté sur le poste (rare), pilote.
6. Poste relié en direct à un autre PC sans DHCP : APIPA est NORMAL dans ce cas (voir P3.12).

3. Questions initiales et sécurité

• « Un seul poste ou plusieurs ? » « Le poste a-t-il déjà fonctionné ici ? » « Quelque chose a changé (box, switch, nombre d'appareils) ? »
• Avant de toucher à l'étendue DHCP d'un serveur : autorisation de l'administrateur, relevé de la configuration existante (adresses fixes et réservations à ne pas chevaucher).

4. Diagnostic pas à pas

1. Vérifier le lien (voyants, « Média déconnecté » ?) — APIPA exige un lien.

   SI pas de lien → P3.1.

   SINON → étape 2.

2. ipconfig /release puis ipconfig /renew — attendu : adresse dans la plage du réseau (ex. 192.168.1.100–199).

   Une erreur s'est produite lors du renouvellement de l'interface Ethernet :
   Impossible de contacter votre serveur DHCP. Le délai d'attente de la demande a expiré.

   SI une adresse correcte arrive → incident passager (box redémarrée, câble rebranché) ; noter et surveiller.

   SINON (message ci-dessus) → étape 3.

3. Comparer avec un poste voisin (même switch, même VLAN) : ipconfig.

   SI le voisin a une adresse valide → problème propre au poste ou à son port : brancher le poste à la place du voisin (même câble/port). Fonctionne → port/prise/VLAN (P3.14) ; ne fonctionne pas → poste (étape 5).

   SINON (tous en 169.254, ou les nouveaux postes seulement) → côté serveur DHCP : étape 4.

4. Côté serveur DHCP / box : état du service, journal, nombre de baux / taille de l'étendue.

   SI service arrêté / DHCP désactivé → le démarrer/activer.

   SINON SI journal « DHCPDISCOVER from 3c:52:82:1a:2b:01 … no address available » → étendue épuisée : la demande arrive (câble et réseau OK) mais il n'y a plus d'adresse libre. SINON (aucune trace de la demande) → la requête n'arrive pas : VLAN, relais DHCP, filtrage.

5. Côté poste : services.msc → « Client DHCP » démarré ; propriétés IPv4 = « Obtenir une adresse IP automatiquement » ; désactiver temporairement le pare-feu tiers ; mettre à jour le pilote.

5. Test de confirmation

Étendue pleine : nb d'adresses de l'étendue = dernière − première + 1 (ex. 192.168.50.100 à 192.168.50.149 → 149 − 100 + 1 = 50 adresses) comparé au nombre de baux actifs (50) → pleine. Panne du serveur : TOUS les nouveaux baux échouent alors que les postes avec bail encore valide continuent à fonctionner (piège : la panne n'apparaît qu'au fil des renouvellements). Test discriminant ultime : une adresse fixe temporaire HORS étendue (ex. 192.168.50.250/24) permet de pinguer la passerelle → le réseau est bon, seul le DHCP manque.

6. Correction

• Lien/VLAN : voir P3.1 / P3.14.
• Service : redémarrer le service DHCP / réactiver le DHCP de la box ; vérifier qu'un seul DHCP est actif.
• Étendue épuisée : agrandir l'étendue (ex. 192.168.50.100 → 192.168.50.199, soit 100 adresses) sans chevaucher les adresses fixes (serveurs, imprimantes) ; raccourcir les baux (8 h–1 jour pour un réseau à visiteurs) ; réseau invités séparé.
• Ne PAS « réparer » en fixant à la main une adresse prise DANS l'étendue : elle sera redistribuée → conflit (P3.4).
• Poste : ipconfig /renew après correction ; si le service Client DHCP était arrêté → le remettre en Automatique.

7. Validation

ipconfig /all : adresse dans la plage, masque du plan, passerelle, DNS, « Serveur DHCP » = serveur officiel, « Bail obtenu »/« Bail expirant » datés ; ping passerelle, 8.8.8.8, nom ; journal DHCP : DHCPACK pour la MAC du poste.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.3 — Adresse valide mais dans le mauvais réseau (DHCP parasite, second routeur)

Fréquence : fréquent (après ajout d'un routeur Wi-Fi) · Gravité : moyenne, perturbe plusieurs postes au hasard

1. Symptômes observables

• Certains postes reçoivent 192.168.0.x (passerelle 192.168.0.1) alors que le plan prévoit 192.168.1.0/24 ; ils n'accèdent plus au serveur ni à l'imprimante, parfois encore à Internet (via le second routeur, en double NAT).
• Problème « aléatoire » : dépend du serveur DHCP qui répond le plus vite.

2. Causes possibles (classées)

1. Routeur Wi-Fi grand public branché sur le LAN en mode routeur, avec son DHCP actif.
2. Ancienne box laissée branchée après remplacement.
3. Poste raccordé au SSID invités ou à un port de switch dans un autre VLAN (dans ce cas le serveur DHCP est légitime mais pour un autre réseau → P3.14).
4. Partage de connexion Internet Windows (ICS) actif sur un PC, qui distribue 192.168.137.x.

3. Questions initiales et sécurité

• « A-t-on ajouté un routeur, une borne Wi-Fi, un switch récemment ? » Demander l'accès aux équipements avant de les débrancher.

4. Diagnostic pas à pas

1. ipconfig /all : ligne « Serveur DHCP » — attendu : IP du serveur officiel (ex. 192.168.1.1).

   SI Serveur DHCP = 192.168.0.1 (inconnu du plan) → DHCP parasite : étape 2.

   SINON → configuration statique erronée (DHCP activé : Non) ou mauvais VLAN.

2. arp -a après ping 192.168.0.1 → relever la MAC du serveur parasite ; les 3 premiers octets (OUI) identifient le fabricant (ex. routeur TP-Link) ; rechercher la MAC dans la table d'adresses du switch administrable pour trouver le port.
3. Inspection physique : suivre le câble depuis ce port ; un routeur branché par son port LAN sur le réseau = coupable typique.

5. Test de confirmation

Débrancher (ou désactiver le DHCP de) l'équipement suspect, puis ipconfig /release + /renew sur un poste touché : le bail vient maintenant du serveur officiel.

6. Correction

• Passer le routeur Wi-Fi en mode « Point d'accès » / « Bridge » (DHCP désactivé), le relier par un port LAN, lui donner une IP fixe hors étendue dans le réseau officiel pour l'administrer.
• Retirer l'ancienne box ; désactiver ICS sur le PC.
• Sur switch administrable : DHCP snooping (ports de confiance) si disponible.
• Renouveler les baux de tous les postes touchés (/release /renew ou redémarrage).

7. Validation

Sur plusieurs postes, « Serveur DHCP » = serveur officiel ; accès serveur, imprimante et Internet ; tracert 8.8.8.8 : premier saut = passerelle officielle (plus de double saut 192.168.0.1 puis 192.168.1.1).

8. Réponse d'examen modèle

9. Pièges et variantes

P3.4 — Conflit d'adresse IP (doublon)

Fréquence : fréquent · Gravité : moyenne à forte (si le doublon est l'adresse d'un serveur ou de la passerelle, tout le monde est touché)

1. Symptômes observables

• Windows : « Windows a détecté un conflit d'adresses IP » ; ipconfig /all : « Adresse IPv4 . . . : 192.168.1.50(Doublon) » et, souvent, une adresse 169.254 de repli (« Adresse d'autoconfiguration IPv4 »).
• Coupures alternées entre deux appareils, connexions qui « sautent », imprimante qui répond une fois sur deux.

2. Causes possibles (classées)

1. Adresse fixe saisie DANS l'étendue DHCP (imprimante, NAS, PC configuré à la main) → le DHCP la donne à un autre.
2. Deux postes configurés en statique avec la même adresse (clonage d'image, copie de configuration).
3. Réservation DHCP sur une adresse déjà utilisée en fixe.
4. Équipement remplacé qui a repris l'adresse de l'ancien encore branché.

3. Questions initiales et sécurité

• « Un appareil a-t-il été ajouté ou reconfiguré ? » Consulter le plan d'adressage (adresses fixes, étendue). Si le doublon est un serveur : prévenir les utilisateurs avant intervention.

4. Diagnostic pas à pas

1. Relever MAC et IP du poste : ipconfig /all → Adresse physique 3C-52-82-1A-2B-01, IP 192.168.1.50.
2. Depuis un AUTRE poste : ping 192.168.1.50 puis arp -a.

   Interface : 192.168.1.20 --- 0xc
     Adresse Internet      Adresse physique      Type
     192.168.1.1           f4-ca-e5-11-22-33     dynamique
     192.168.1.50          00-80-77-4d-5e-6f     dynamique
     192.168.1.255         ff-ff-ff-ff-ff-ff     statique
     224.0.0.22            01-00-5e-00-00-16     statique

   SI la MAC associée à 192.168.1.50 (00-80-77-…) ≠ MAC du poste (3C-52-82-…) → une autre machine utilise cette adresse : étape 3.

   SINON → refaire le test le poste éteint : si l'adresse répond encore, c'est l'autre appareil.

3. Identifier l'autre appareil : OUI 00-80-77 → fabricant (ici Brother, imprimante) ; liste des baux DHCP de la box ; table MAC du switch ; page de configuration des imprimantes.
4. Vérifier si l'adresse est dans l'étendue DHCP (ex. étendue 192.168.1.20–199 : 50 est dedans).

5. Test de confirmation

Éteindre/débrancher l'un des deux : l'autre fonctionne sans coupure ; arp -d * (admin) puis nouveau ping → la MAC affichée change selon l'appareil allumé. Limite : la table ARP garde l'entrée quelques dizaines de secondes, vider avant de conclure.

6. Correction

• Équipement fixe (imprimante, NAS, serveur) : adresse fixe HORS étendue (ex. 192.168.1.210) OU réservation DHCP liée à sa MAC ; mettre à jour les ports d'impression/raccourcis qui visent l'ancienne adresse.
• Poste client : repasser en « Obtenir une adresse IP automatiquement ».
• Puis ipconfig /release, ipconfig /renew sur le poste ; mettre à jour le plan d'adressage.

7. Validation

Plus de message de conflit ; arp -a depuis un tiers : chaque IP associée à UNE seule MAC attendue ; ping -t sans pertes pendant 2 minutes ; impression et accès réseau OK.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.5 — Masque de sous-réseau incorrect

Fréquence : fréquent en configuration manuelle (examen : très fréquent) · Gravité : partielle et trompeuse

1. Symptômes observables

• Le poste joint CERTAINS postes du réseau et pas d'autres ; ou la passerelle est injoignable alors que le câble est bon ; ou Internet fonctionne mais pas un autre sous-réseau.
• Masque différent de celui des autres postes (comparer ipconfig).

2. Causes possibles (classées)

1. Masque trop LONG (ex. 255.255.255.128 au lieu de 255.255.255.0) : le poste croit que la moitié du réseau est « distante ».
2. Masque trop COURT (ex. 255.255.0.0 au lieu de 255.255.255.0) : le poste croit locales des adresses distantes.
3. Faute de frappe dans l'adresse elle-même (192.168.11.25 au lieu de 192.168.1.25).

3. Questions initiales et sécurité

• « Le poste est-il en adresse fixe ? Qui l'a configuré ? » Relever la configuration avant modification (réversibilité).

4. Diagnostic pas à pas

1. Calculer le réseau du poste avec SON masque. Ex. poste 192.168.1.200 masque 255.255.255.128 : bloc 256 − 128 = 128 ; 200 est entre 128 et 255 → réseau 192.168.1.128/25, hôtes .129 à .254.
2. Situer la passerelle et les cibles : passerelle 192.168.1.1 → réseau 192.168.1.0/25 (≠ 192.168.1.128/25).

   SI la passerelle n'est pas dans le réseau calculé du poste → configuration incohérente, le poste ne peut normalement pas la joindre : Windows peut même refuser la configuration (« passerelle par défaut n'est pas sur le même segment de réseau »). Internet KO, postes .1 à .127 KO, postes .129 à .254 OK : signature du masque trop long.

   SINON → étape 3.

3. Masque trop court : poste 192.168.1.50 masque 255.255.0.0 → réseau 192.168.0.0/16. Il croit 192.168.2.10 (serveur d'un autre sous-réseau) local, envoie une requête ARP qui reste sans réponse → « Impossible de joindre l'hôte de destination » venant de 192.168.1.50 ; Internet, lui, fonctionne (la passerelle 192.168.1.1 est bien dans 192.168.0.0/16).

5. Test de confirmation

Le calcul (ET logique adresse/masque) des deux côtés donne deux réseaux différents pour des machines qui DEVRAIENT être dans le même ; la comparaison avec un poste qui fonctionne montre un masque différent. Après correction temporaire du masque, les postes inaccessibles répondent.

6. Correction

• Saisir le masque du plan d'adressage (Paramètres → Réseau et Internet → Ethernet → Attribution IP → Modifier ; ou ncpa.cpl → Propriétés IPv4) ou, mieux, repasser en DHCP si le poste n'a pas besoin d'une adresse fixe.
• En ligne de commande (admin) : netsh interface ipv4 set address name="Ethernet" static 192.168.1.200 255.255.255.0 192.168.1.1.
• Linux (NetworkManager) : nmcli con mod "Connexion filaire 1" ipv4.addresses 192.168.1.200/24 puis nmcli con up "Connexion filaire 1".

7. Validation

Ping d'un hôte de chaque « moitié » (ex. .20 et .220), de la passerelle, de 8.8.8.8 et d'un nom ; ipconfig : masque identique aux autres postes.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.6 — Réseau local OK, Internet KO même par adresse IP (un seul poste)

Fréquence : fréquent (configuration manuelle, Linux installé à la main) · Gravité : bloquante pour l'accès Internet

1. Symptômes observables

• Le poste ouvre le NAS / le partage local, pinge la box ou un voisin, mais ping 8.8.8.8 échoue ; les autres postes ont Internet.
• Windows : « Passerelle par défaut » vide ou fausse ; ping 8.8.8.8 → « PING : échec de la transmission. Défaillance générale. » (pas de route) ou « Délai d'attente » (passerelle fausse mais existante).
• Linux :

  $ ip route
  192.168.50.0/24 dev enp3s0 proto kernel scope link src 192.168.50.40 metric 100
  $ ping -c 2 8.8.8.8
  ping: connect: Network is unreachable

2. Causes possibles (classées)

1. Passerelle non saisie (configuration statique incomplète).
2. Passerelle erronée : adresse d'un autre appareil (NAS, imprimante), ancienne box, faute de frappe.
3. Passerelle hors du réseau du poste (masque faux → P3.5).
4. Deux cartes actives avec deux passerelles (Wi-Fi + Ethernet sur des réseaux différents, VPN) : métrique qui envoie le trafic au mauvais endroit.
5. Filtrage sur la box (contrôle parental, blocage par MAC de ce poste).

3. Questions initiales et sécurité

• « Poste en adresse fixe ? Installé récemment ? Un VPN ? » Relever la configuration avant modification.

4. Diagnostic pas à pas

1. ipconfig / ip route — attendu : passerelle = IP LAN du routeur (plan), ligne default via 192.168.50.1 dev enp3s0.

   SI vide / pas de default via → cause confirmée : passerelle manquante.

   SINON → étape 2.

2. ping de la passerelle configurée.

   SI pas de réponse, ou elle répond mais arp -a montre une MAC qui n'est pas celle de la box → passerelle erronée (autre appareil).

   SINON (la vraie box répond) → étape 3.

3. tracert -d 8.8.8.8 — attendu : saut 1 = box, puis routeurs du FAI.

   SI saut 1 = autre adresse (VPN 10.8.0.1, Wi-Fi d'un autre réseau) → table de routage / métriques : route print.

   SINON (s'arrête après la box alors que les voisins passent) → filtrage spécifique au poste sur la box.

5. Test de confirmation

Ajout temporaire de la route par défaut : Windows route add 0.0.0.0 mask 0.0.0.0 192.168.50.1 ; Linux sudo ip route add default via 192.168.50.1 → ping 8.8.8.8 répond. Limite : ces ajouts ne survivent pas au redémarrage (ou à la reconnexion), ce n'est pas la correction.

6. Correction

• Windows : propriétés IPv4 → Passerelle par défaut 192.168.50.1 (ou repasser en DHCP) ; netsh interface ipv4 set address name="Ethernet" static 192.168.50.40 255.255.255.0 192.168.50.1.
• Linux : Paramètres → Réseau → IPv4 manuel → Passerelle, ou nmcli con mod "Connexion filaire 1" ipv4.gateway 192.168.50.1 ipv4.dns 192.168.50.10 puis nmcli con up "Connexion filaire 1" (Debian sans NetworkManager : ligne gateway 192.168.50.1 dans /etc/network/interfaces, puis sudo systemctl restart networking).
• Deux cartes : désactiver celle qui ne sert pas, ou ajuster la métrique.

7. Validation

ip route : default via 192.168.50.1 dev enp3s0 proto static metric 100 ; ping 8.8.8.8, ping d'un nom ; redémarrer le poste et revérifier (persistance).

8. Réponse d'examen modèle

9. Pièges et variantes

P3.7 — Ping par adresse OK, noms introuvables (DNS)

Fréquence : très fréquent · Gravité : bloquante pour l'utilisateur (« Internet ne marche pas ») mais réseau sain

1. Symptômes observables

• ping 8.8.8.8 répond ; ping www.google.be → « La requête Ping n'a pas pu trouver l'hôte www.google.be. Vérifiez le nom et essayez à nouveau. »
• Navigateur : « Ce site est inaccessible – DNS_PROBE_FINISHED_NXDOMAIN » ou « …_BAD_CONFIG » ; Linux : « Temporary failure in name resolution ».
• Variante interne : Internet OK mais \\srv01 ou intranet.entreprise.local introuvables.

2. Causes possibles (classées)

1. Serveur DNS saisi à la main faux ou disparu (ancien serveur, ancienne box).
2. Poste réglé sur un DNS public (8.8.8.8) dans un réseau à domaine : les noms internes ne sont pas connus des DNS publics.
3. Serveur DNS interne / box : service arrêté, redirecteurs cassés.
4. Cache DNS du poste avec une entrée erronée ou négative ; fichier hosts modifié (malware, ancien test).
5. Nom mal orthographié, enregistrement absent (nom interne jamais créé).
6. Port 53 bloqué par un pare-feu.

3. Questions initiales et sécurité

• « Tous les sites ou un seul ? Les noms internes aussi ? Tous les postes ? » Un seul site KO = souvent le site lui-même.

4. Diagnostic pas à pas

1. Confirmer que la connectivité IP est bonne : ping 8.8.8.8 OK (sinon → P3.6 / P3.8).
2. ipconfig /all → « Serveurs DNS » ; comparer avec le plan / un poste qui fonctionne.
3. nslookup www.google.be (utilise le DNS configuré).

   DNS request timed out.
       timeout was 2 seconds.
   Serveur :   UnKnown
   Address:  192.168.50.5
   
   DNS request timed out.
       timeout was 2 seconds.
   *** Le délai de la requête vers UnKnown a expiré

   SI délai expiré → le serveur DNS configuré ne répond pas (n'existe plus, éteint) : étape 4.

   SINON SI « *** srv01 ne parvient pas à trouver www.exemple.be : Non-existent domain » → le serveur répond mais ne connaît pas le nom : nom erroné ou enregistrement manquant (ou serveur DNS public interrogé pour un nom interne).

4. nslookup www.google.be 1.1.1.1 (force un autre serveur).

   Serveur :   one.one.one.one
   Address:  1.1.1.1
   
   Réponse ne faisant pas autorité :
   Nom :    www.google.be
   Addresses:  2a00:1450:400e:80d::2003
             142.250.179.195

   SI réponse → la résolution fonctionne ailleurs : le serveur DNS configuré est en cause.

   SINON → port 53 filtré (pare-feu, réseau d'entreprise qui impose son DNS).

5. Si nslookup répond mais le ping de nom échoue → cache local ou fichier hosts : ipconfig /displaydns, type C:\Windows\System32\drivers\etc\hosts (Linux /etc/hosts, resolvectl status).

5. Test de confirmation

nslookup nom serveur_dns_correct donne l'adresse alors que le serveur configuré échoue ; après correction, le ping par nom résout la bonne adresse. Limite : « Réponse ne faisant pas autorité » est NORMAL (le serveur relaie la réponse, il n'est pas propriétaire du domaine) — ce n'est pas une erreur.

6. Correction

• DNS = celui du plan : en réseau d'entreprise, le serveur DNS interne / contrôleur de domaine (qui relaie Internet) ; en petit réseau, la box (ou DHCP). Repasser en « Obtenir l'adresse des serveurs DNS automatiquement » si le DHCP distribue le bon.
• Commande (admin) : netsh interface ipv4 set dnsservers name="Ethernet" static 192.168.50.10 primary.
• Corriger l'option DNS dans le serveur DHCP si TOUS les postes ont la mauvaise valeur, puis ipconfig /renew.
• ipconfig /flushdns (vide le cache) ; restaurer le fichier hosts ; créer l'enregistrement manquant sur le serveur DNS interne.
• Linux : nmcli con mod … ipv4.dns 192.168.50.10 ipv4.ignore-auto-dns yes ; resolvectl flush-caches.

7. Validation

nslookup sans serveur forcé répond ; ping www.google.be affiche « Envoi d'une requête 'ping' sur www.google.be [142.250.179.195] » ; nom interne résolu ; navigateur OK ; test sur un second poste si correction faite au DHCP.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.8 — Plus aucun poste n'accède à Internet (panne générale)

Fréquence : fréquent · Gravité : forte (toute l'activité) — priorité haute

1. Symptômes observables

• Tous les postes, filaires et Wi-Fi : « Pas d'accès Internet » ; le partage local et l'imprimante fonctionnent encore.
• Box : voyant « Internet » / « DSL » / « Fibre » éteint, rouge ou clignotant ; voyant « LOS » rouge sur l'ONT fibre.

2. Causes possibles (classées)

1. Panne ou maintenance du FAI, coupure de ligne (travaux).
2. Box plantée (ne route plus) ou désynchronisée ; câble WAN / jarretière fibre / câble téléphonique débranché.
3. Box remplacée/réinitialisée : identifiants de connexion non saisis.
4. Abonnement suspendu (facture impayée) → page du FAI.
5. Si la box ne répond même pas au ping : switch central sans courant, box éteinte.

3. Questions initiales et sécurité

• « Depuis quand ? Orage, travaux, coupure de courant ? Quelqu'un a-t-il touché à la box ? » Relever les voyants AVANT tout redémarrage (preuve pour le FAI). Prévenir les utilisateurs de la coupure pendant le redémarrage. Ne jamais faire un reset usine (perte de configuration : redirections, Wi-Fi, DHCP) sans sauvegarde et accord.

4. Diagnostic pas à pas

1. Sur un poste : ping 192.168.1.1 (box).

   SI pas de réponse sur tous les postes → box éteinte/plantée ou switch central : vérifier alimentation et voyants du switch, puis de la box.

   SINON (box OK) → étape 2.

2. ping 8.8.8.8 + tracert -d 8.8.8.8.

   Détermination de l'itinéraire vers 8.8.8.8 avec un maximum de 30 sauts.
   
     1    <1 ms    <1 ms    <1 ms  192.168.1.1
     2     *        *        *     Délai d'attente de la demande dépassé.
     3     *        *        *     Délai d'attente de la demande dépassé.
     4     *        *        *     Délai d'attente de la demande dépassé.

   SI seul le saut 1 (box) répond → panne côté WAN/FAI : étape 3.

   SINON (s'arrête plus loin, ou 8.8.8.8 répond) → Internet par IP fonctionne : vérifier le DNS de la box (P3.7).

3. Interface de la box (http://192.168.1.1) : état de la synchronisation / connexion, adresse IP WAN, journal.

   SI « non synchronisé » / pas d'IP WAN → vérifier câble WAN/fibre, page d'incidents du FAI (depuis un smartphone en 4G), redémarrer la box (après relevé).

   SINON (connectée mais pas de trafic) → redémarrage, puis escalade FAI.

5. Test de confirmation

Le premier saut répond, les suivants non, sur PLUSIEURS postes ; l'état WAN de la box est déconnecté ; le portail d'incidents du FAI signale la panne. Limite : certains routeurs du FAI ne répondent jamais au tracert (des « * » isolés au milieu d'une route qui aboutit ne sont pas une panne).

6. Correction

• Rebrancher/réparer le câble WAN ; redémarrer la box (débrancher 30 s) ; ressaisir les identifiants de connexion fournis par le FAI.
• Panne FAI : ouvrir un ticket (référence client, voyants relevés, heure de début), solution de secours (partage 4G) si l'activité l'exige ; informer les utilisateurs (→ Fiche 5 · Escalade).

7. Validation

Voyant Internet vert ; depuis deux postes (filaire et Wi-Fi) : ping 8.8.8.8, ping nom, navigation ; services dépendants (messagerie, VPN, imprimante cloud).

8. Réponse d'examen modèle

9. Pièges et variantes

P3.9 — Ping ou service bloqué par le pare-feu / profil réseau « Public »

Fréquence : très fréquent (deux PC en direct, partage) · Gravité : faible, mais induit en erreur

1. Symptômes observables

• Ping d'un PC Windows allumé et bien adressé → « Délai d'attente de la demande dépassé ».
• Partage / imprimante partagée inaccessible depuis un poste, réseau classé « Réseau public » (Paramètres → Réseau et Internet → Ethernet ou Wi-Fi → Type de profil réseau).

2. Causes possibles (classées)

1. Profil réseau Public : règles « Partage de fichiers et d'imprimantes » et écho ICMP désactivées.
2. Pare-feu tiers (antivirus) plus strict.
3. Règle d'entreprise (stratégie de groupe).
4. Hôte réellement absent (à distinguer !).

3. Questions initiales et sécurité

• Ne jamais DÉSACTIVER le pare-feu comme correction : seulement comme test bref, sur réseau de confiance, puis le réactiver.

4. Diagnostic pas à pas

1. ping de la cible puis arp -a.

   SI l'IP de la cible apparaît avec sa MAC → elle est présente sur le segment et a répondu à l'ARP : c'est l'ICMP qui est filtré.

   SINON → cible absente / autre réseau : revoir adressage, câble.

2. Sur la cible : type de profil réseau (PowerShell : Get-NetConnectionProfile).

   SI NetworkCategory : Public → étape 3.

   SINON → règles de pare-feu (wf.msc) ou pare-feu tiers.

3. Tester le service lui-même : Test-NetConnection 192.168.10.1 -Port 445 → TcpTestSucceeded : False/True.

5. Test de confirmation

Activer la règle (ou le profil Privé) → le ping répond immédiatement ; le désactiver → délai dépassé. Limite : un ping qui répond ne prouve pas que le port 445 (partage) est ouvert, et inversement.

6. Correction

• Réseau de confiance : Type de profil réseau → Privé ; Paramètres réseau avancés → Paramètres de partage avancés → Activer la découverte du réseau et le partage de fichiers et d'imprimantes (profil Privé).
• Ou règle ciblée : netsh advfirewall firewall set rule group="Partage de fichiers et d'imprimantes" new enable=yes (nom du groupe en français sur Windows FR) ; PowerShell : Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private.

7. Validation

Ping OK, port 445 True, accès au partage ; le pare-feu reste ACTIF (vérifier « Pare-feu Windows Defender : activé »).

8. Réponse d'examen modèle

9. Pièges et variantes

P3.10 — Réseau lent, pertes de paquets, coupures intermittentes (filaire)

Fréquence : fréquent · Gravité : variable ; difficile car intermittent

1. Symptômes observables

• Copies de fichiers lentes, visioconférence qui saccade, déconnexions de quelques secondes ; ping -t avec des « Délai d'attente » épisodiques ou des temps qui montent (1 ms → 300 ms).
• État de la carte : vitesse 100 Mbit/s au lieu de 1 Gbit/s ; compteur d'erreurs.

2. Causes possibles (classées)

1. Saturation : sauvegarde, mises à jour, téléchargement massif, Wi-Fi + filaire sur une liaison Internet faible.
2. Câble/connecteur abîmé ou mal serti (paire défectueuse → repli à 100 Mbit/s, erreurs CRC).
3. Négociation de vitesse/duplex incorrecte (duplex forcé d'un côté seulement).
4. Boucle sur le réseau (tempête de diffusion) → P3.14.
5. Conflit IP intermittent → P3.4 ; pilote/gestion d'énergie de la carte.
6. Hub ancien (domaine de collision partagé) encore en place.

3. Questions initiales et sécurité

• « À quels moments ? Tous les postes ou un seul ? Une activité particulière (sauvegarde à 12 h) ? » Noter les horaires pour corréler.

4. Diagnostic pas à pas

1. ping -t 192.168.1.1 pendant quelques minutes (Ctrl+C → statistiques).

   Statistiques Ping pour 192.168.1.1:
       Paquets : envoyés = 300, reçus = 271, perdus = 29 (perte 9%),
   Durée approximative des boucles en millisecondes :
       Minimum = 0ms, Maximum = 412ms, Moyenne = 23ms

   SI pertes vers la passerelle sur le LAN filaire → problème local (câble, port, carte, boucle, conflit) : étape 2.

   SINON (LAN propre, seul Internet lent) → saturation de la liaison Internet : mesurer le débit, identifier le gros consommateur.

2. État de la connexion (ncpa.cpl → double-clic) : vitesse.

   SI 100 Mbit/s avec matériel Gigabit → câble/prise à tester (→ Fiche 3 · Testeur), changer le cordon, vérifier que le duplex est en « Négociation automatique » (Gestionnaire de périphériques → carte → Avancé → Speed & Duplex).

   SINON → étape 3.

3. Comparer avec un autre poste sur le même switch et sur un autre switch ; observer les voyants du switch (clignotement frénétique et simultané de tous les ports = boucle/tempête).
4. Gestion de l'alimentation de la carte (Gestionnaire de périphériques → Propriétés → Gestion de l'alimentation : décocher « Autoriser l'ordinateur à éteindre ce périphérique ») si coupures après inactivité.

5. Test de confirmation

Le défaut disparaît en changeant UN élément (cordon, port, duplex) et réapparaît en le remettant ; les pertes coïncident avec l'horaire d'une activité. Limite : intermittent = observer assez longtemps (au moins la durée habituelle entre deux coupures).

6. Correction

• Remplacer le cordon, réparer la prise ; remettre la négociation automatique des deux côtés ; supprimer la boucle ; remplacer le hub par un switch ; planifier sauvegardes/mises à jour hors heures ; mettre à jour le pilote.

7. Validation

100 pings consécutifs sans perte, temps < 1–2 ms sur le LAN ; vitesse de liaison 1 Gbit/s ; copie d'un gros fichier au débit attendu ; suivi sur la période où le défaut apparaissait.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.11 — Configuration correcte mais rien ne fonctionne : pile TCP/IP, Winsock, proxy, VPN

Fréquence : rare à occasionnel · Gravité : bloquante pour le poste

1. Symptômes observables

• ping 127.0.0.1 échoue, ou ipconfig correct + ping IP OK mais navigateurs/applis réseau KO.
• Après désinstallation d'un antivirus/VPN, infection, ou « optimiseur » réseau.

2. Causes possibles (classées)

1. Proxy configuré (Paramètres → Réseau et Internet → Proxy) — applis web KO, ping OK.
2. Heure/date du PC fausse → erreurs de certificat HTTPS (« Votre horloge est en avance/retard »).
3. VPN resté connecté / carte virtuelle prioritaire.
4. Catalogue Winsock ou pile TCP/IP corrompu (127.0.0.1 KO).
5. Malware (fichier hosts, proxy imposé).

3. Questions initiales et sécurité

• « Qu'a-t-on installé/désinstallé récemment ? » Les réinitialisations effacent les réglages IP manuels : relever la configuration (ipconfig /all) AVANT.

4. Diagnostic pas à pas

1. ping 127.0.0.1.

   SI échec → pile TCP/IP : étape 5 (correction).

   SINON → étape 2.

2. Proxy : « Utiliser un serveur proxy » activé sans raison ? (netsh winhttp show proxy pour le proxy système).
3. Date/heure et synchronisation (w32tm /query /status).
4. Cartes virtuelles (ncpa.cpl) : VPN, TAP, Hyper-V ; route print : route par défaut via le VPN ?
5. Analyse anti-malware et contrôle du fichier hosts.

5. Test de confirmation

Le symptôme disparaît après désactivation du proxy / correction de l'heure / déconnexion du VPN, ou après la réinitialisation de la pile. Limite : la réinitialisation corrige aussi d'autres choses — noter ce qui a été fait.

6. Correction

Attention netsh int ip reset et netsh winsock reset effacent les adresses IP fixes, DNS et certains réglages réseau ; logiciels VPN/pare-feu tiers éventuellement à réinstaller. Prérequis : ipconfig /all sauvegardé, droits admin, redémarrage possible. Alternative prudente d'abord : désactiver/réactiver la carte, retirer le proxy, mettre à jour le pilote. Windows 10/11 propose aussi Paramètres → Réseau et Internet → Paramètres réseau avancés → Réinitialisation du réseau (réinstalle les cartes, même effet + redémarrage).

C:\> netsh winsock reset
C:\> netsh int ip reset
C:\> ipconfig /flushdns
C:\> shutdown /r /t 0

7. Validation

Ressaisir la configuration fixe éventuelle ; ping 127.0.0.1, passerelle, 8.8.8.8, nom ; navigation HTTPS sans alerte ; VPN qui se connecte/déconnecte correctement.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.12 — Relier deux PC en direct (et dépanner quand ils ne se voient pas)

Fréquence : classique d'examen · Gravité : faible

1. Symptômes observables

• Deux PC reliés par un câble RJ45 : pas de voyant, ou voyant mais ping KO, ou ping OK mais partage inaccessible.

2. Causes possibles (classées)

1. Adresses incohérentes : un PC en DHCP (169.254.x.x/16) et l'autre en statique 192.168.10.x/24 → réseaux différents.
2. Pare-feu (profil Public) bloque ping et partage → P3.9.
3. Câble droit entre deux cartes anciennes (10/100) sans Auto MDI-X → pas de lien ; il faut un croisé (les cartes Gigabit gèrent l'Auto MDI-X).
4. Câble défectueux (F3).
5. Partage non créé / compte sans droit / identifiants (le PC distant exige un compte LOCAL de ce PC avec mot de passe).

3. Questions initiales et sécurité

• But (copier des données ? jouer ? migrer ?) → partage temporaire, droits minimaux, arrêt du partage à la fin. Sauvegarde des données avant une copie massive.

4. Diagnostic pas à pas

1. Voyants des deux cartes.

   SI aucun lien → câble (tester, F3) ; cartes 10/100 anciennes → câble croisé.

   SINON → étape 2.

2. ipconfig sur les deux.

   SI 169.254.x.x d'un côté et 192.168.10.x de l'autre → mettre les deux en statique dans le MÊME réseau.

   SINON (même réseau) → étape 3.

3. ping dans les deux sens.

   SI « Délai d'attente » → pare-feu (profil Public) : P3.9.

   SINON (« Impossible de joindre l'hôte » depuis sa propre IP) → l'autre ne répond pas à l'ARP : adresse mal tapée, carte désactivée.

4. Accès au partage \\192.168.10.1\Agenda (par IP : pas besoin de DNS).

5. Test de confirmation

Avec 192.168.10.1/24 et 192.168.10.2/24, sans passerelle, ping OK dans les deux sens et arp -a montre la MAC de l'autre PC.

6. Correction (procédure de mise en service)

1. Câble RJ45 testé (droit si Auto MDI-X, croisé T568A/T568B pour matériel ancien — → Fiche 3 · RJ45).
2. PC-A : 192.168.10.1, masque 255.255.255.0, passerelle VIDE, DNS vide. PC-B : 192.168.10.2, même masque. (netsh interface ipv4 set address name="Ethernet" static 192.168.10.1 255.255.255.0.)
3. Profil réseau Privé sur les deux (ou règle d'écho ICMP + partage de fichiers).
4. Sur le PC source : clic droit sur le dossier → Propriétés → Partage → Partage avancé → Partager ce dossier → Autorisations (Lecture pour le compte prévu) ; un compte local avec mot de passe sur ce PC.
5. Sur l'autre PC : Explorateur → \\192.168.10.1\Agenda → identifiants PC-A\compte.

7. Validation

Ping dans les deux sens ; ouverture d'un fichier copié (intégrité) ; arrêt du partage temporaire et retour à la configuration DHCP initiale si les PC retournent sur le réseau de l'entreprise.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.13 — Mettre en service un mini-réseau (3 à 20 postes) / deux groupes de postes qui ne communiquent pas

Fréquence : classique d'examen · Gravité : moyenne

1. Symptômes observables

• Création : le client veut relier 5 PC, une imprimante, un NAS et Internet.
• Panne : les postes du premier étage voient le NAS mais pas ceux du rez ; plan d'adressage incohérent (masques ou plages différents).

2. Causes possibles (classées)

1. Plan d'adressage incohérent : deux réseaux IP différents sur le même switch sans routeur (ex. 192.168.1.0/24 et 192.168.2.0/24).
2. Adresses fixes dans l'étendue DHCP, adresse réseau/diffusion attribuée à un hôte.
3. Un hub/switch en cascade éteint ou mal relié (lien inter-switch).
4. Second DHCP (P3.3), VLAN (P3.14).

3. Questions initiales et sécurité

• Nombre de postes actuels et futurs, équipements à adresse fixe (NAS, imprimante, serveur, AP), Wi-Fi invités, distances (100 m max par segment cuivre), emplacement de la box.

4. Diagnostic pas à pas (contrôle d'un plan)

1. Calculer l'adresse réseau de CHAQUE hôte (adresse ET masque, voir 4 A).

   SI deux réseaux différents sans routeur → incohérence : renuméroter dans un seul réseau, ou ajouter un routeur si la séparation est voulue.

   SINON → étape 2.

2. Vérifier chaque adresse fixe : dans le réseau, hors étendue DHCP, ni adresse réseau ni diffusion, pas de doublon.
3. Vérifier passerelle et DNS : même valeur sur tous les postes, passerelle dans le réseau.
4. Vérifier la topologie physique : chaque switch alimenté, liaisons inter-switch actives, pas de boucle.

5. Test de confirmation

Tableau du plan : pour chaque ligne, réseau calculé identique ; un ping croisé entre un poste de chaque groupe réussit après correction.

6. Correction : plan type d'un mini-réseau 192.168.1.0/24

1. Topologie en étoile : box → switch (8 ou 16 ports) → postes, NAS, imprimante ; AP sur le switch.
2. Masque 255.255.255.0 partout, passerelle 192.168.1.1, DNS 192.168.1.1 (ou serveur interne).
3. Choix d'équipement : switch (pas hub) pour multiplier les prises ; routeur/box pour Internet et séparer des réseaux ; AP pour le Wi-Fi (tableau 4 B).
4. Repérage des prises et du brassage (→ Fiche 3 · Installation).
5. Documenter : schéma, plan d'adressage, identifiants d'administration en lieu sûr.

7. Validation (recette)

Pour chaque poste : ipconfig conforme au plan, ping passerelle, ping NAS, ping 8.8.8.8, ping nom ; accès au partage avec le compte prévu ; page de test de l'imprimante ; Wi-Fi : connexion d'un portable et d'un smartphone ; procès-verbal signé.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.14 — Port de switch, VLAN, brassage, boucle

Fréquence : occasionnel (réseaux avec switch administrable) · Gravité : locale (VLAN) à totale (boucle)

1. Symptômes observables

• Le poste fonctionne sur une prise, pas sur une autre : 169.254 ou adresse d'un autre réseau (réseau invités, téléphonie).
• Boucle : tout le réseau s'effondre juste après l'ajout d'un câble, voyants de tous les ports qui clignotent en continu, CPU des postes en hausse, pings perdus partout.

2. Causes possibles (classées)

1. Prise brassée sur un port d'un autre VLAN (ex. VLAN 20 invités au lieu de VLAN 10 bureau) ou sur le mauvais switch.
2. Port désactivé (shutdown) ou bloqué par la sécurité de port (MAC non autorisée).
3. Câble reliant deux prises du même réseau / deux ports du même switch → boucle sans STP.
4. Petit switch de bureau non administrable ajouté qui crée une boucle avec un second câble.

3. Questions initiales et sécurité

• Accès au switch administrable = droits d'administrateur réseau : intervention à demander/escalader ; relever la configuration du port avant modification.

4. Diagnostic pas à pas

1. Brancher un poste connu sur la prise suspecte, et le poste suspect sur une prise connue.

   SI le défaut suit la PRISE → brassage/port/VLAN : étape 2.

   SINON → le défaut suit le POSTE : configuration du poste.

2. Suivre le repérage : prise B12 → panneau de brassage port 12 → port du switch ; voyant du port.
3. Configuration du port sur le switch (interface web) : VLAN d'accès, état, sécurité.

   SI VLAN ≠ VLAN prévu pour les postes → corriger.

   SINON port désactivé / « err-disabled » → réactiver après avoir compris la cause.

4. Boucle : débrancher le dernier câble ajouté (ou débrancher un à un les petits switchs) jusqu'au retour à la normale.

5. Test de confirmation

Le même poste obtient une adresse du bon réseau sur le port corrigé ; pour la boucle, le réseau revient dès le retrait du câble et retombe si on le remet (ne pas répéter inutilement).

6. Correction

• Rebrasser sur un port du bon VLAN ou modifier le VLAN d'accès du port ; mettre à jour l'étiquetage et le cahier de brassage.
• Supprimer la liaison redondante ; activer STP/RSTP si les switchs le permettent (redondance voulue) ; interdire les switchs personnels.

7. Validation

Adresse dans la bonne plage, ping passerelle/serveur ; voyants normaux ; ping continu stable sur plusieurs postes pendant quelques minutes.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.15 — Ouverture de session de domaine impossible

Fréquence : fréquent · Gravité : bloquante pour l'utilisateur

1. Symptômes observables

• « Le nom d'utilisateur ou le mot de passe est incorrect. »
• « Le compte référencé est actuellement verrouillé et vous ne pourrez peut-être pas vous y connecter. » / « Votre compte a été désactivé. Contactez votre administrateur système. » / « Votre mot de passe a expiré et doit être changé. »
• « La relation d'approbation entre cette station de travail et le domaine principal a échoué. »
• « Aucun serveur d'authentification n'est actuellement disponible pour traiter la demande d'ouverture de session. » (DC injoignable)

2. Causes possibles (classées)

1. Utilisateur : Verr. Maj, clavier QWERTY/AZERTY, mauvais compte/domaine (session ouverte en local « .\ » au lieu de « ENTREPRISE\ »).
2. Compte : mot de passe expiré ou changé ailleurs, verrouillé après trop d'essais, désactivé, horaires d'ouverture.
3. Poste : canal sécurisé cassé (relation d'approbation), DNS du poste ne pointe pas vers le DC, heure décalée (Kerberos tolère 5 minutes par défaut).
4. Réseau : poste hors ligne (session en cache possible seulement si déjà ouverte), DC éteint.

3. Questions initiales et sécurité

• Identité de l'utilisateur vérifiée avant toute réinitialisation de mot de passe (procédure de l'entreprise). Pas de communication de mot de passe par écrit/en clair ; mot de passe temporaire + « doit changer à la prochaine ouverture ».
• « Avez-vous changé votre mot de passe récemment ? Sur un autre appareil (smartphone qui réessaie l'ancien → verrouillage) ? »

4. Diagnostic pas à pas

1. Lire le message exact et vérifier la saisie (afficher le mot de passe avec l'œil, Verr. Maj, langue clavier, champ « Se connecter à : ENTREPRISE »).
2. Même compte sur un autre poste / autre compte sur ce poste.

   SI le compte échoue partout → compte : état dans « Utilisateurs et ordinateurs Active Directory » (verrouillé, désactivé, expiré) — action de l'administrateur.

   SINON (seul ce poste échoue) → poste : étape 3.

3. Session admin locale sur le poste : ipconfig /all (DNS = DC ?), nltest /dsgetdc:entreprise.local (DC trouvé ?), heure (w32tm /query /status), Test-ComputerSecureChannel (PowerShell admin).

   SI Test-ComputerSecureChannel = False → relation d'approbation cassée.

   SINON SI DNS = box/8.8.8.8 → DC introuvable (corriger DNS) ; écart d'heure > 5 min → resynchroniser.

5. Test de confirmation

Après déverrouillage / correction du DNS / de l'heure / du canal, la session s'ouvre ; whoami renvoie entreprise\jdupont ; whoami /groups liste les groupes attendus.

6. Correction

• Compte : déverrouiller, réinitialiser avec changement obligatoire, réactiver (droits d'administrateur du domaine, sinon escalade).
• Relation d'approbation : Test-ComputerSecureChannel -Repair -Credential ENTREPRISE\admin ; à défaut, retirer le poste du domaine (groupe de travail temporaire) puis le rejoindre, redémarrer (compte admin LOCAL connu indispensable avant).
• Heure : w32tm /resync (le poste se synchronise sur le DC).
• DNS : DNS du poste = IP du DC (via DHCP de préférence).

7. Validation

Ouverture de session, lecteurs réseau montés, gpupdate /force sans erreur, accès aux ressources ; l'utilisateur change son mot de passe temporaire.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.16 — La jonction d'un poste au domaine échoue

Fréquence : fréquent en installation · Gravité : moyenne

1. Symptômes observables

• sysdm.cpl → Modifier → Domaine « entreprise.local » → « Un contrôleur de domaine Active Directory (AD DC) pour le domaine “entreprise.local” n'a pas pu être contacté. »
• Ou : « Accès refusé » (compte sans droit de jonction), « Le nom d'ordinateur existe déjà ».

2. Causes possibles (classées)

1. DNS du poste = box ou DNS public → l'enregistrement du DC (SRV) est introuvable.
2. DC injoignable (réseau, VLAN, pare-feu).
3. Édition Windows Famille (ne peut pas joindre un domaine : il faut Professionnel/Entreprise/Éducation).
4. Compte utilisé sans droit de jonction, nom d'ordinateur en double.
5. Heure très décalée.

3. Questions initiales et sécurité

• Compte autorisé à joindre des postes ; nom d'ordinateur conforme à la convention ; compte admin local connu (en cas d'échec après redémarrage).

4. Diagnostic pas à pas

1. Édition de Windows (Paramètres → Système → Informations système).

   SI Famille → mise à niveau Pro nécessaire.

   SINON → étape 2.

2. nslookup entreprise.local — attendu : IP du DC.

   SI échec / « Serveur : box » → DNS : corriger vers l'IP du DC.

   SINON → ping du DC, heure, compte utilisé.

5. Test de confirmation

nslookup -type=SRV _ldap._tcp.dc._msdcs.entreprise.local renvoie le DC une fois le bon DNS configuré.

6. Correction

DNS = IP du DC ; puis Paramètres → Système → Informations système → « Domaine ou groupe de travail » (sysdm.cpl → Modifier) → Domaine → identifiants autorisés → redémarrer. PowerShell : Add-Computer -DomainName entreprise.local -Credential ENTREPRISE\admin -Restart.

7. Validation

Message « Bienvenue dans le domaine entreprise.local », redémarrage, ouverture de session avec un compte du domaine, objet ordinateur présent dans AD, gpupdate /force OK.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.17 — « Windows ne peut pas accéder à \\SRV01 » : chemin réseau introuvable (0x80070035 / erreur 53)

Fréquence : très fréquent · Gravité : bloquante pour l'accès aux fichiers

1. Symptômes observables

• Explorateur : « Windows ne peut pas accéder à \\SRV01\Compta … Code d'erreur : 0x80070035. Le chemin d'accès réseau n'a pas été trouvé. »
• net use P: \\SRV01\Compta → « Erreur système 53. Le chemin réseau n'a pas été trouvé. »
• Variante : « Erreur système 67. Nom de réseau introuvable. » (le serveur répond mais le NOM DU PARTAGE n'existe pas).

2. Causes possibles (classées)

1. Nom du serveur non résolu (DNS, NetBIOS désactivé, pas de suffixe) → par IP ça marche.
2. Serveur éteint / injoignable (réseau).
3. Port SMB 445 bloqué : pare-feu du serveur (règle « Partage de fichiers et d'imprimantes »), profil Public sur le client ou le serveur, pare-feu tiers.
4. Service « Serveur » (LanmanServer) arrêté sur l'hôte ; service « Station de travail » arrêté sur le client.
5. Partage supprimé ou renommé (→ erreur 67), faute de frappe.
6. NAS ancien en SMBv1 seulement (désactivé sur Windows 10/11 récents).

3. Questions initiales et sécurité

• « Tous les postes ou un seul ? Le partage a-t-il fonctionné ? Un changement (box, serveur renommé) ? »

4. Diagnostic pas à pas

1. ping SRV01.

   SI « n'a pas pu trouver l'hôte » → essayer ping 192.168.1.10 et \\192.168.1.10\Compta : si l'IP fonctionne → résolution de nom (P3.7).

   SINON (nom résolu) → étape 2.

2. Le serveur répond-il ? (ping ou arp -a)

   SI non → serveur éteint/réseau.

   SINON → étape 3.

3. Test-NetConnection SRV01 -Port 445.

   ComputerName     : SRV01
   RemoteAddress    : 192.168.1.10
   RemotePort       : 445
   InterfaceAlias   : Ethernet
   SourceAddress    : 192.168.1.37
   TcpTestSucceeded : False

   SI False → SMB injoignable : si AUCUN poste n'accède → serveur (service Serveur, pare-feu du serveur) ; si SEUL ce poste échoue → ce poste (profil Public, pare-feu sortant, antivirus).

   SINON (True) → nom du partage : net view \\SRV01 liste les partages ; erreur 67 → partage renommé/supprimé.

5. Test de confirmation

Après correction de la cause, TcpTestSucceeded : True et net use réussit. Erreur 53 ≠ erreur 5 : avec 53, on n'atteint même pas l'étape des droits — ne pas toucher aux permissions.

6. Correction

• Nom : DNS / suffixe (P3.7) ; contournement temporaire par IP.
• Pare-feu : profil Privé/Domaine, règle « Partage de fichiers et d'imprimantes » activée (serveur), pare-feu tiers.
• Services : services.msc → « Serveur » (hôte) et « Station de travail » (client) démarrés, type Automatique.
• Partage : recréer/renommer (P3.19). NAS SMBv1 : mettre à jour le NAS (activer SMB2/3) plutôt que réactiver SMBv1 (faille de sécurité).

7. Validation

Port 445 True, net use P: \\SRV01\Compta /persistent:yes → « La commande s'est terminée correctement. », ouverture d'un fichier, test depuis un second poste.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.18 — « Accès refusé » ou lecture seule : calculer le droit effectif (partage + NTFS)

Fréquence : très fréquent (et très fréquent à l'examen) · Gravité : moyenne ; sécurité des données en jeu

1. Symptômes observables

• « Vous n'avez actuellement pas l'autorisation d'accéder à ce dossier » / « Accès refusé » / « Erreur système 5. L'accès est refusé. »
• L'utilisateur ouvre les fichiers mais « Vous avez besoin d'une autorisation pour effectuer cette action » à l'enregistrement → lecture seule.
• Un stagiaire voit un dossier qu'il ne devrait pas voir (droits trop larges).

2. Causes possibles (classées)

1. Permission de PARTAGE plus restrictive que la NTFS (ex. Tout le monde : Lecture par défaut).
2. Permission NTFS insuffisante pour l'utilisateur et ses groupes.
3. Refus explicite (Refuser) hérité d'un groupe dont l'utilisateur fait partie.
4. Utilisateur ajouté au groupe mais session non rouverte (le jeton d'accès contient les groupes du moment de l'ouverture de session).
5. Connexion au partage avec d'autres identifiants mémorisés (P3.20).
6. Héritage désactivé sur un sous-dossier, fichier ouvert/verrouillé par un autre utilisateur.

3. Questions initiales et sécurité

• « Quel accès est NÉCESSAIRE (lire ? modifier ? supprimer ?) et validé par le responsable des données ? » Moindre privilège : jamais « Tout le monde : Contrôle total » pour « faire fonctionner ». Relever les permissions existantes avant modification.

4. Diagnostic pas à pas : le calcul en 4 temps

1. Lister les groupes de l'utilisateur : whoami /groups (sur sa session) ou net user jdupont /domain (ligne « Appartient aux groupes globaux »).
2. Couche PARTAGE (Propriétés → Partage → Partage avancé → Autorisations) : additionner les autorisations de l'utilisateur ET de tous ses groupes → la plus large l'emporte (cumul), SAUF un « Refuser » qui l'emporte sur tout.
3. Couche NTFS (Propriétés → Sécurité ; « Avancé » → onglet « Accès effectif ») : même règle de cumul + refus prioritaire.
4. Droit effectif à travers le réseau = le PLUS RESTRICTIF des deux résultats. En local (session ouverte sur le serveur lui-même) seule la NTFS s'applique.

5. Test de confirmation

Onglet Sécurité → Avancé → Accès effectif → « Sélectionner un utilisateur » → affichage des droits NTFS (prend en compte les groupes ; ne montre PAS toujours la couche partage → calculer la combinaison). Test pratique : avec le compte de l'utilisateur (ou ses identifiants, avec son accord), créer et modifier un fichier test.

6. Correction

• Bonne pratique : partage = « Utilisateurs authentifiés » ou les groupes concernés en Modifier (ou Contrôle total pour les admins), et le contrôle fin en NTFS ; ou partage aussi précis que la NTFS.
• Accorder au GROUPE (pas à l'individu) : ajouter l'utilisateur au groupe Compta ; retirer un refus inutile (préférer « ne pas autoriser » à « Refuser »).
• L'utilisateur ferme et rouvre sa session (ou klist purge + reconnexion) pour que le nouveau groupe soit pris en compte.
• Commandes : icacls D:\Partages\Compta /grant "ENTREPRISE\Compta:(OI)(CI)M" ; Grant-SmbShareAccess -Name Compta -AccountName "ENTREPRISE\Compta" -AccessRight Change.

7. Validation

L'utilisateur crée, modifie, enregistre un fichier test puis le supprime ; un compte qui ne doit PAS accéder est bien refusé (test négatif) ; documenter la modification (qui, quoi, validé par qui).

8. Réponse d'examen modèle

9. Pièges et variantes

P3.19 — Mettre un dossier en partage et le connecter en lecteur réseau

Fréquence : classique d'examen (procédure) · Gravité : —

1. Symptômes observables

• Demande : « Le service Comptabilité doit partager le dossier D:\Partages\Compta ; les comptables modifient, la direction lit, personne d'autre. »

2. Causes possibles (classées)

1. (Procédure de mise en œuvre — les erreurs fréquentes sont : partage sur un dossier système, droits individuels au lieu de groupes, Tout le monde Contrôle total, oubli du test négatif.)

3. Questions initiales et sécurité

• Qui lit, qui modifie, qui ne doit rien voir ; validation par le responsable ; sauvegarde du dossier prévue ; données personnelles (RGPD).

4. Diagnostic pas à pas (étapes de mise en œuvre)

1. Créer les groupes (domaine : GG_Compta, GG_Direction ; groupe de travail : groupes locaux sur l'hôte + comptes locaux avec mot de passe identiques à ceux des postes ou saisis à la connexion).
2. NTFS : Propriétés → Sécurité → Modifier → ajouter GG_Compta = Modification, GG_Direction = Lecture et exécution ; retirer « Utilisateurs » si hérité (Avancé → Désactiver l'héritage → Convertir les autorisations héritées), garder Administrateurs et Système en Contrôle total.
3. Partage : Partage avancé → Partager ce dossier → nom « Compta » (ajouter « $ » à la fin pour un partage masqué) → Autorisations : Utilisateurs authentifiés = Modifier (la NTFS affine), retirer Tout le monde.
4. Connexion des postes : Explorateur → Ce PC → Connecter un lecteur réseau → P: → \\SRV01\Compta → « Se reconnecter lors de la connexion » ; ou net use P: \\SRV01\Compta /persistent:yes ; en domaine, par GPO.

C:\> net share Compta=D:\Partages\Compta /grant:"Utilisateurs authentifiés",CHANGE
C:\> icacls D:\Partages\Compta /grant "ENTREPRISE\GG_Compta:(OI)(CI)M" "ENTREPRISE\GG_Direction:(OI)(CI)RX"
C:\> net share

Nom partage   Ressource                       Remarque

-------------------------------------------------------------------------------
C$            C:\                             Partage par défaut
IPC$                                          IPC distant
ADMIN$        C:\Windows                      Administration à distance
Compta        D:\Partages\Compta
La commande s'est terminée correctement.

5. Test de confirmation

Test positif (comptable crée/modifie), test lecture (direction ouvre, ne peut pas enregistrer), test négatif (commercial : accès refusé).

6. Correction

Ajuster les groupes, pas les individus ; documenter (chemin UNC, groupes, droits, date, demandeur).

7. Validation

Les trois tests ci-dessus, lecteur P: présent après redémarrage, sauvegarde du dossier incluse dans le plan de sauvegarde.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.20 — Lecteur réseau déconnecté, identifiants mémorisés, erreurs 1219 / 86

Fréquence : fréquent · Gravité : faible

1. Symptômes observables

• Lecteur P: avec croix rouge, « Impossible de rétablir toutes les connexions aux lecteurs réseau » au démarrage.
• « Erreur système 1219. Plusieurs connexions à un serveur ou à une ressource partagée par le même utilisateur, en utilisant plus d'un nom d'utilisateur, ne sont pas autorisées. »
• « Erreur système 86. Le mot de passe réseau spécifié est incorrect. » ; demande d'identifiants en boucle.

2. Causes possibles (classées)

1. Lecteur reconnecté avant que le Wi-Fi/réseau soit prêt (croix rouge mais accès OK au clic).
2. Identifiants mémorisés obsolètes (mot de passe changé) dans le Gestionnaire d'identification.
3. Connexion déjà ouverte au même serveur avec un autre compte (1219).
4. Serveur renommé / changé d'adresse (lecteur mappé par IP).

3. Questions initiales et sécurité

• « Avez-vous changé de mot de passe ? Le lecteur s'ouvre-t-il quand vous cliquez ? » Ne pas enregistrer un compte admin dans le Gestionnaire d'identification d'un utilisateur.

4. Diagnostic pas à pas

1. Cliquer sur le lecteur.

   SI il s'ouvre → simple reconnexion tardive (pas de panne).

   SINON → étape 2.

2. net use : liste des connexions (État : OK / Déconnecté / Non disponible) ; repérer une connexion au même serveur sous un autre nom (IP vs nom).
3. Panneau de configuration → Gestionnaire d'identification → Informations d'identification Windows : entrée pour SRV01 avec un ancien compte/mot de passe ?

5. Test de confirmation

Après suppression des anciennes connexions/identifiants, la connexion avec le bon compte réussit.

6. Correction

C:\> net use * /delete /y
C:\> cmdkey /list
C:\> cmdkey /delete:SRV01
C:\> net use P: \\SRV01\Compta /user:ENTREPRISE\jdupont /persistent:yes

Attention net use * /delete ferme TOUTES les connexions réseau de la session (fichiers ouverts sur le réseau non enregistrés → perte). Prérequis : faire enregistrer et fermer les documents ouverts. Alternative prudente : net use P: /delete pour le seul lecteur concerné.

7. Validation

Fermeture/ouverture de session ou redémarrage : P: reconnecté sans demande d'identifiants, fichiers accessibles.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.21 — Imprimante réseau « Hors connexion » (ou ping OK mais n'imprime pas)

Fréquence : très fréquent · Gravité : moyenne

1. Symptômes observables

• File d'attente : « Imprimante hors connexion », documents « Erreur – Impression » ou en attente ; tous les postes ou un seul.
• Souvent après remplacement de la box, coupure de courant, déménagement de l'imprimante.

2. Causes possibles (classées)

1. Imprimante éteinte, en veille profonde, bourrage/papier/toner (panneau en erreur).
2. Adresse IP de l'imprimante changée (DHCP, nouvelle box) alors que les postes visent l'ancienne dans leur port TCP/IP.
3. Imprimante sur le Wi-Fi déconnectée (changement de clé) / câble.
4. Adresse fixe de l'imprimante dans un ancien réseau (nouvelle box avec un autre réseau).
5. Protocole SNMP de statut qui signale à tort « hors connexion ».
6. Pilote (P3.22).

3. Questions initiales et sécurité

• « Tous les postes ? Depuis quand ? Changement de box ? » Documents confidentiels en file : ne pas les réimprimer sans accord.

4. Diagnostic pas à pas

1. Panneau de l'imprimante : allumée, prête, sans erreur ; imprimer la page de configuration réseau (adresse, masque, passerelle, DHCP/statique).
2. Comparer avec le port des postes : Propriétés de l'imprimante → Ports → « Standard TCP/IP Port » → adresse (PowerShell : Get-PrinterPort).

   SI adresses différentes (port 192.168.1.50, imprimante 192.168.1.137) → adresse changée : correction.

   SINON → étape 3.

3. ping de l'adresse de l'imprimante.

   SI « Impossible de joindre l'hôte de destination » (réponse de sa propre IP) → personne à cette adresse : imprimante absente du réseau (câble, Wi-Fi, autre réseau).

   SINON (ping OK) → Test-NetConnection 192.168.1.50 -Port 9100 (RAW) ; ouvrir http://192.168.1.50 (interface web) ; désactiver « État SNMP activé » dans le port si le statut est faux.

5. Test de confirmation

Page de configuration ≠ adresse du port ; après mise à jour du port, page de test OK. Limite : une imprimante peut ne pas répondre au ping et imprimer quand même (port 9100 ouvert).

6. Correction

• Adresse fixe HORS étendue dans la plage imprimantes (ex. 192.168.1.20) sur le panneau / interface web, ou réservation DHCP sur la box (MAC de l'imprimante → 192.168.1.20).
• Mettre à jour le port TCP/IP de chaque poste (Propriétés de l'imprimante → Ports → Ajouter un port → Standard TCP/IP Port), ou mieux : partager l'imprimante depuis un serveur (\\SRV01\Traceur-A1) → un seul port à maintenir.
• Relancer les documents en attente ou les supprimer avec l'accord des utilisateurs ; mettre à jour le plan d'adressage.

7. Validation

Page de test depuis CHAQUE poste (ou au moins deux), file vide, statut « Prêt », adresse stable après redémarrage de l'imprimante et de la box.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.22 — File d'impression bloquée, spouleur, pilote ou imprimante partagée

Fréquence : fréquent · Gravité : faible à moyenne

1. Symptômes observables

• Un document en « Erreur » en tête de file, les suivants bloqués ; impossible de supprimer (« Suppression… » indéfiniment).
• Connexion à \\PC-ACCUEIL\HP-Accueil : « Windows ne peut pas se connecter à l'imprimante » (ex. code 0x0000011b, 0x00000709), demande d'installation de pilote, accès refusé.
• Service « Spouleur d'impression » arrêté → aucune imprimante visible.

2. Causes possibles (classées)

1. Document corrompu/volumineux bloquant la file.
2. Service Spouleur planté.
3. Pilote absent pour l'architecture du client (x64), pilote incompatible, installation de pilote bloquée sans droits admin (durcissement de sécurité Windows).
4. PC hôte du partage éteint, en veille, pare-feu (profil Public).
5. Permissions de l'imprimante partagée (onglet Sécurité : Imprimer) .

3. Questions initiales et sécurité

• Le vidage de file supprime les travaux de TOUS les utilisateurs : prévenir.

4. Diagnostic pas à pas

1. Ouvrir la file → annuler le document en erreur.

   SI la file repart → document fautif.

   SINON → étape 2.

2. services.msc → Spouleur d'impression : état.

   SI arrêté/bloqué → redémarrage et vidage (correction).

   SINON → étape 3.

3. Imprimante partagée : l'hôte est allumé, ping, accès \\PC-ACCUEIL ; onglet Partage (« Partager cette imprimante ») ; pilote installé pour x64 ; permission « Imprimer » pour le groupe.

5. Test de confirmation

Page de test après redémarrage du spouleur ; l'impression repart.

6. Correction

Attention La suppression du contenu de C:\Windows\System32\spool\PRINTERS efface tous les travaux en attente de tous les utilisateurs. Prérequis : utilisateurs prévenus, service arrêté avant suppression. Alternative prudente : annuler d'abord les documents un par un depuis la file, puis simple redémarrage du service.

C:\> net stop spooler
C:\> del /Q C:\Windows\System32\spool\PRINTERS\*
C:\> net start spooler

• Pilote : installer le pilote du fabricant (bonne architecture) en administrateur sur le client, puis reconnecter l'imprimante partagée ; maintenir hôte et clients à jour (ne pas désactiver les protections de sécurité de l'impression).
• Hôte de partage : alimentation/veille désactivée, profil Privé, ou passer à une imprimante IP directe / serveur d'impression.

7. Validation

Page de test, impression d'un document réel depuis l'application de l'utilisateur, file vide, service Spouleur en démarrage Automatique.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.23 — Le réseau Wi-Fi n'apparaît pas dans la liste

Fréquence : fréquent · Gravité : bloquante pour le client

1. Symptômes observables

• Liste vide, ou les réseaux voisins apparaissent mais pas le SSID attendu ; icône Wi-Fi absente (carte désactivée).

2. Causes possibles (classées)

1. Wi-Fi coupé sur le client : mode avion, touche Fn/interrupteur, carte désactivée.
2. Trop loin / obstacles (béton, métal, ascenseur) → signal trop faible.
3. Client ne gérant pas la bande (2,4 GHz seulement, AP en 5 GHz seul) ou le canal (12/13 non autorisés sur un appareil importé ; canal DFS).
4. SSID masqué (diffusion désactivée).
5. AP éteint, radio désactivée, programmation horaire du Wi-Fi sur la box.
6. Pilote Wi-Fi absent/défaillant (Fiche 2).

3. Questions initiales et sécurité

• « Les autres appareils voient-ils le réseau, ici et ailleurs ? Depuis quand ? »

4. Diagnostic pas à pas

1. Mode avion désactivé, Wi-Fi activé, carte présente (ncpa.cpl).
2. Un autre appareil au même endroit voit-il le SSID ?

   SI oui → problème du client : bande/canal pris en charge (netsh wlan show drivers → « Types de radio pris en charge »), pilote.

   SINON → étape 3.

3. Se rapprocher de l'AP.

   SI le SSID apparaît près de l'AP → couverture : P3.26/P3.27.

   SINON → interface de l'AP : radio activée, SSID diffusé, bande, canal, planification.

5. Test de confirmation

netsh wlan show networks mode=bssid liste le SSID (avec canal et signal) une fois la cause corrigée. Un SSID masqué n'apparaît pas mais se connecte par « Réseau masqué » + nom exact.

6. Correction

Activer la radio ; activer la bande 2,4 GHz (ou SSID identique sur les deux bandes) ; canal 1, 6 ou 11 ; diffuser le SSID (le masquer n'apporte pas de sécurité réelle) ; rapprocher/ajouter un AP ; mettre à jour le pilote.

7. Validation

SSID visible, connexion, adresse IP correcte, navigation, signal relevé.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.24 — « Impossible de se connecter à ce réseau » / clé refusée

Fréquence : très fréquent · Gravité : bloquante pour le client

1. Symptômes observables

• « Impossible de se connecter à ce réseau » ; « La clé de sécurité réseau n'est pas correcte » ; connexion qui échoue après « Vérification de la configuration requise ».
• Souvent après changement de clé, de box, ou de mode de sécurité (passage en WPA3 seul).

2. Causes possibles (classées)

1. Mauvaise clé (majuscules, 0/O, l/1, clavier).
2. Profil enregistré avec l'ancienne clé ou l'ancienne sécurité.
3. Sécurité incompatible : AP en WPA3 seul, client ancien (WPA2 seulement).
4. Filtrage MAC sur l'AP (et MAC aléatoire activée sur le client, qui change d'adresse).
5. Trop de clients / limite atteinte sur l'AP ; signal trop faible pendant l'authentification.
6. Pilote Wi-Fi obsolète.

3. Questions initiales et sécurité

• Obtenir la clé auprès du responsable ; ne pas l'afficher/l'écrire là où elle serait vue. Récupérer une clé enregistrée (netsh wlan show profile name="X" key=clear) seulement sur un poste autorisé.

4. Diagnostic pas à pas

1. Oublier le réseau (Paramètres → Réseau et Internet → Wi-Fi → Gérer les réseaux connus → Oublier ; ou netsh wlan delete profile name="Linea-Pro") puis ressaisir la clé en l'affichant.

   SI ça fonctionne → profil obsolète.

   SINON → étape 2.

2. Un autre appareil se connecte-t-il avec la même clé ?

   SI oui → client : compatibilité WPA3 (netsh wlan show drivers), pilote, filtrage MAC, MAC aléatoire.

   SINON → AP : clé réellement configurée, mode de sécurité, limite de clients, redémarrage.

3. Journal de l'AP (si disponible) : « authentication failed / wrong password » (clé) vs « MAC address not allowed » (filtrage).

5. Test de confirmation

Connexion réussie après la correction ciblée ; netsh wlan show interfaces affiche « État : connecté » et l'authentification attendue.

6. Correction

Ressaisir la clé ; passer l'AP en mode mixte WPA2/WPA3 (transition) si des clients anciens doivent se connecter ; mettre à jour le pilote ; ajouter la MAC au filtrage (ou désactiver l'« adresse matérielle aléatoire » pour ce réseau si le filtrage est imposé) ; augmenter la limite de clients ou ajouter un AP.

7. Validation

Connexion automatique après redémarrage du client, adresse IP correcte, navigation.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.25 — Wi-Fi « Connecté, sans Internet » / portail captif

Fréquence : très fréquent · Gravité : moyenne

1. Symptômes observables

• Icône Wi-Fi avec globe ou « Aucun accès Internet » ; « Connecté, sécurisé » mais pages qui ne s'ouvrent pas ; ou « Action requise » / « Se connecter » (portail).

2. Causes possibles (classées)

1. Portail captif (hôtel, gare, réseau invités) non validé.
2. Pas de bail DHCP (169.254) : DHCP de l'AP/box saturé ou AP en mode pont sans DHCP derrière.
3. DNS (P3.7) ; passerelle (AP en mode routeur derrière la box, double NAT mal configuré).
4. Box sans Internet (P3.8) — alors le filaire est touché aussi.
5. Isolation des clients/réseau invités qui bloque l'accès au LAN (voulu) — confondu avec une panne.

3. Questions initiales et sécurité

• « Le filaire fonctionne-t-il ? Les autres appareils Wi-Fi ? Réseau public/hôtel ? » Sur un portail public, ne pas saisir d'identifiants professionnels ; préférer le VPN de l'entreprise une fois connecté.

4. Diagnostic pas à pas

1. ipconfig (section « Carte réseau sans fil Wi-Fi »).

   SI 169.254.x.x → DHCP : vérifier le serveur DHCP du réseau Wi-Fi (box/AP), nombre de baux (P3.2).

   SINON → étape 2.

2. Ouvrir un site en http simple (ex. http://neverssl.com).

   SI redirection vers une page de connexion → portail captif : s'authentifier / accepter les conditions.

   SINON → étape 3.

3. Ping passerelle → 8.8.8.8 → nom (ordre des tests).

   SI passerelle OK, 8.8.8.8 KO → box/route : P3.8 (si le filaire aussi) ou passerelle distribuée par un AP en mode routeur mal relié.

   SINON (8.8.8.8 OK, nom KO) → DNS : P3.7.

5. Test de confirmation

Le même appareil en filaire (ou un smartphone en Wi-Fi) donne le même résultat → cause commune ; sinon, propre au client ou au Wi-Fi.

6. Correction

Valider le portail ; corriger DHCP/DNS ; mettre le point d'accès en mode pont/AP (le DHCP reste à la box) ; si isolation invités voulue : expliquer, ne pas la supprimer, connecter le portable au SSID professionnel.

7. Validation

Adresse dans la bonne plage, ping passerelle, 8.8.8.8, nom ; navigation HTTPS ; reconnexion automatique (sauf portail, qui redemande périodiquement).

8. Réponse d'examen modèle

9. Pièges et variantes

P3.26 — Wi-Fi lent, déconnexions, débit variable (signal, canal, interférences)

Fréquence : très fréquent · Gravité : moyenne, intermittente

1. Symptômes observables

• Lenteurs dans une pièce, aux heures de pointe ou quand le micro-ondes fonctionne ; déconnexions ; « Signal » faible ; débit de liaison bas (« Réception : 72 Mbits/s » au lieu de plusieurs centaines).

C:\> netsh wlan show interfaces

    Nom                    : Wi-Fi
    Description            : Intel(R) Wi-Fi 6 AX201 160MHz
    Adresse physique       : 5a:1b:3c:7e:22:91
    État                   : connecté
    SSID                   : Linea-Pro
    BSSID                  : f4:ca:e5:44:55:66
    Type de réseau         : Infrastructure
    Type de radio          : 802.11n
    Authentification       : WPA2 - Personnel
    Chiffrement            : CCMP
    Mode de connexion      : Profil
    Bande                  : 2,4 GHz
    Canal                  : 3
    Réception (Mbits/s)    : 72,2
    Transmission (Mbits/s) : 72,2
    Signal                 : 38%
    Profil                 : Linea-Pro

2. Causes possibles (classées)

1. Signal faible : distance, murs porteurs, métal, aquarium, étage ; AP posé au sol, dans une armoire, derrière l'écran.
2. Canal 2,4 GHz encombré ou chevauchant (canal 3 chevauche 1 et 6) ; largeur 40 MHz en 2,4 GHz.
3. Interférences non Wi-Fi : micro-ondes, Bluetooth, babyphone, caméras sans fil.
4. Trop de clients / un client gourmand (sauvegarde, streaming) ; vieux client 802.11b/g qui ralentit la cellule.
5. Client collé à un AP lointain (roaming), répéteur mal placé (P3.27).
6. Économie d'énergie de la carte, pilote.

3. Questions initiales et sécurité

• « Où, quand, combien d'utilisateurs ? En filaire, est-ce rapide ? » → distinguer lenteur Wi-Fi et lenteur Internet.

4. Diagnostic pas à pas

1. Comparer filaire / Wi-Fi au même moment (test de débit).

   SI filaire lent aussi → liaison Internet/saturation (P3.10/P3.8).

   SINON → Wi-Fi : étape 2.

2. Signal à l'endroit du problème (Signal %, ou dBm avec un analyseur : −50 excellent, −67 limite confortable, −75 médiocre, −80 inutilisable).

   SI signal faible (< 50 %, < −70 dBm) → couverture : déplacer/surélever l'AP, AP supplémentaire, 2,4 GHz pour la portée.

   SINON (signal bon mais lent) → étape 3.

3. Réseaux voisins et canaux : netsh wlan show networks mode=bssid (Linux : nmcli dev wifi list) — compter les réseaux par canal.

   SI canal occupé/chevauchant → choisir 1, 6 ou 11 le moins chargé (ou passer en 5 GHz).

   SINON → interférences non Wi-Fi (lenteur corrélée au micro-ondes) ou charge (nb de clients).

5. Test de confirmation

Mesure AVANT/APRÈS au même endroit, même heure, même appareil : signal, débit de liaison, test de débit, ping -t passerelle sans pertes. Limite : un seul test ne suffit pas pour une gêne intermittente.

6. Correction

• Placement : hauteur, centre de la zone, dégagé, loin des masses métalliques et du micro-ondes.
• Canal 1/6/11 en 2,4 GHz (20 MHz) ; 5 GHz pour les clients compatibles (même SSID sur les deux bandes = band steering, ou SSID séparés).
• Second AP câblé (même SSID, même sécurité, canaux différents) plutôt qu'un répéteur ; mesh.
• Désactiver les débits hérités 802.11b ; mettre à jour firmware et pilotes ; QoS si nécessaire.

7. Validation

Signal ≥ 60–70 % (≈ −65 dBm) dans la zone, débit mesuré et noté, plus de déconnexion sur la période critique, retour utilisateur.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.27 — Répéteur : zone blanche persistante ou débit pire qu'avant

Fréquence : fréquent · Gravité : faible à moyenne

1. Symptômes observables

• Répéteur ajouté dans la pièce mal couverte : signal fort affiché près du répéteur mais débit très faible, déconnexions ; clients qui restent sur l'AP principal lointain.

2. Causes possibles (classées)

1. Répéteur placé DANS la zone morte : il reçoit lui-même un signal faible et ne peut répéter que ce peu.
2. Répéteur mono-bande : il reçoit et réémet sur la même radio → débit divisé par deux environ.
3. SSID différent (« Linea-EXT ») : les clients ne basculent pas ; sécurité différente.
4. Canal / interférences.

3. Questions initiales et sécurité

• Possibilité de tirer un câble (AP câblé, meilleure solution) ou CPL ? Budget mesh ?

4. Diagnostic pas à pas

1. Lire le signal reçu PAR le répéteur (voyant de liaison, interface).

   SI faible (voyant orange/rouge, < −70 dBm) → le rapprocher de l'AP : à mi-chemin, là où le signal de l'AP est encore bon (≥ 60–70 %).

   SINON → étape 2.

2. SSID/sécurité : identiques à l'AP pour le roaming ; mêmes clé et mode WPA2/WPA3.
3. Débit utile mesuré près du répéteur vs près de l'AP.

5. Test de confirmation

Mesure dans la zone visée avant/après repositionnement ; le débit s'améliore quand le répéteur reçoit mieux.

6. Correction

Repositionner à mi-distance ; choisir un répéteur bi-bande / mesh ; ou mieux, point d'accès relié par câble (backhaul filaire) en mode AP ; même SSID et même sécurité ; mot de passe d'administration changé.

7. Validation

Signal et débit mesurés dans la zone, déplacement d'un portable entre zones sans coupure, plan de couverture documenté.

8. Réponse d'examen modèle

9. Pièges et variantes

P3.28 — Configurer et sécuriser un point d'accès / une box Wi-Fi

Fréquence : classique d'examen (procédure) · Gravité : sécurité

1. Symptômes observables

• AP neuf, ou audit : SSID par défaut, Wi-Fi ouvert ou WEP/WPA-TKIP, WPS activé, mot de passe admin d'usine, firmware ancien, invités sur le réseau interne.

2. Causes possibles (classées)

1. Configuration d'usine jamais modifiée ; matériel trop ancien pour WPA2-AES/WPA3.

3. Questions initiales et sécurité

• Accès admin autorisé, sauvegarde de la configuration existante, fenêtre de coupure annoncée (les clients devront ressaisir la clé), inventaire des clients anciens.

4. Diagnostic pas à pas (étapes de configuration)

1. Connexion en filaire à l'interface (http://IP de l'AP) ; changer IMMÉDIATEMENT le mot de passe administrateur ; mettre à jour le firmware.
2. Mode : point d'accès/pont (DHCP désactivé) si une box/un serveur fait déjà le DHCP ; adresse IP fixe hors étendue (ex. 192.168.1.2).
3. SSID neutre (ni nom d'entreprise sensible, ni modèle), diffusé ; même SSID sur 2,4 et 5 GHz ou deux SSID explicites.
4. Sécurité : WPA3-Personnel (SAE) ou mixte WPA2/WPA3 ; jamais WEP/TKIP ; clé longue aléatoire ; WPS désactivé.
5. Radio : 2,4 GHz canal 1, 6 ou 11, 20 MHz ; 5 GHz canal 36–48 (ou auto) ; puissance adaptée à la zone.
6. Réseau invités : SSID séparé, isolation des clients, pas d'accès au LAN, éventuellement portail et limite de débit.
7. Placement : central, en hauteur, dégagé.

5. Test de confirmation

Depuis un client : authentification WPA2/WPA3 (netsh wlan show interfaces → « Authentification : WPA3 - Personnel » ou WPA2), adresse IP de la box, Internet ; depuis le réseau invités : Internet OK, ping du NAS KO (isolation confirmée).

6. Correction

Exporter/sauvegarder la configuration finale ; consigner SSID, sécurité, canal, IP d'administration ; identifiants en coffre-fort de mots de passe, pas sur un post-it.

7. Validation

Tous les clients reconnectés ; mesure du signal dans chaque zone ; tentative de connexion avec mauvaise clé refusée ; WPS inactif.

8. Réponse d'examen modèle

9. Pièges et variantes