Dépannage réseau et Internet — dossiers d'intervention écrits (PR24)

Ce que tu sauras faire, par écrit

L'épreuve pratique AMPCR se passe uniquement par écrit (consignes officielles 2026-2027/1, p. 3) : on te remet un dossier — plan du réseau, symptômes, relevés de commandes, état des équipements — et tu dois, sur papier :

1. localiser méthodiquement la panne (un poste ou tous, filaire ou Wi-Fi, local ou Internet) ;
2. formuler des hypothèses et choisir des tests sûrs, non destructifs ;
3. interpréter les résultats (ping, tracert, nslookup, ipconfig, journaux, état des ports) ;
4. proposer une correction autorisée, avec un retour arrière ;
5. confirmer le rétablissement par des tests ;
6. rédiger le compte rendu de l'intervention.

Exigences officielles travaillées dans ce cours

• AP-32 (p. 6) — « Connexions et interventions en cas de panne internet. »
• AP-37 (p. 6) — « Dépannage de problèmes simples d’accès au réseau. »

Ce cours mobilise aussi, sans les traiter entièrement : l'adressage IP et MAC (AP-30, cours PR20), les équipements (AP-31, PR19), le Wi-Fi (AP-33, PR25), les partages et permissions (AP-25 à AP-27, PR23) et les câbles (AP-19, cours PR15).

Compléments pédagogiques (hors liste officielle des pp. 5-6, signalés comme tels) :

• AP-C01 (complément pédagogique) — « Rédiger une réponse écrite de technicien : décrire une intervention étape par étape et justifier chaque choix. »
• AP-C03 (complément pédagogique) — « Protéger les données du client : sauvegarde préalable, confidentialité et autorisation avant tout effacement ou toute réinstallation. »

Lien avec la théorie

Les notions de base sont présentées dans la théorie AMPCR : MC13 Fondamentaux réseau, MC14 Équipements, MC19 DHCP, MC20 DNS, ARP et ICMP, MC22 Internet, NAT et routage, MC24 VLAN, MC25 Wi-Fi, MC26 Sécurité Wi-Fi, MC31 Dépannage réseau méthodique et MC33 Partage de ressources. Ce cours-ci est pratique : dossiers, relevés, procédures et comptes rendus, comme dans une intervention réelle.

Le réseau de référence

La plupart des situations du cours se passent dans ce réseau fictif de PME, « l'atelier » : réseau 192.168.20.0/24, box 192.168.20.1 (passerelle, NAT, pare-feu, adresse publique 203.0.113.45), serveur SRV-01 192.168.20.5 (Linux, logiciel dnsmasq : DHCP avec des baux de 8 jours sur l'étendue 192.168.20.100 à 192.168.20.199, soit 100 adresses, et DNS interne du suffixe atelier.lan, qui relaie les noms Internet vers le DNS du fournisseur 198.51.100.53), NAS 192.168.20.10 (partage \\NAS-01\Compta), imprimante 192.168.20.20, point d'accès alimenté par le switch (Wi-Fi « ATELIER-PRO »), et un Wi-Fi invités « ATELIER-INVITES » (VLAN 30, réseau 10.30.0.0/24) isolé du réseau interne.

Comment travailler ce cours

Lis les sections dans l'ordre, puis étudie les six cas résolus. Fais les 20 exercices corrigés (ici ou dans « S'entraîner », correction après envoi), puis passe le mini-examen noté sur 20 dans l'onglet « Examen blanc ».

Important — le réseau, les relevés, les captures, les adresses MAC et les adresses publiques (plages de documentation RFC 5737) de ce cours sont des supports fictifs construits pour s'entraîner ; la présentation réelle des commandes varie selon la version et la langue du système. Les relevés sont produits et vérifiés par programme à partir du réseau de référence. Aucun exercice n'est une question officielle ni une question déjà posée par le Jury.

1.1 Avant tout test : cerner le problème

Une plainte comme « Internet ne marche plus » ne dit presque rien. Avant de toucher à quoi que ce soit, le technicien établit :

• le symptôme exact : message affiché, ce qui fonctionne encore, ce qui ne fonctionne plus (un site, tous les sites, le partage, l'imprimante) ;
• le périmètre : un poste ou tous ? filaire ou Wi-Fi ? local ou Internet (le NAS répond-il ? et un site ?) ;
• la chronologie : depuis quand, en continu ou par intermittence, à quelle heure ;
• les changements récents : mise à jour, déménagement, nouveau matériel, réinitialisation de la box, intervention d'un prestataire ;
• la topologie : plan du réseau, équipements traversés, adresses prévues.

Le périmètre oriente tout le reste : un seul poste touché → on cherche sur ce poste, son câble, son port, sa configuration ; tous les postes → on cherche l'élément commun (switch, box, serveur DHCP ou DNS, liaison du fournisseur).

1.2 Raisonner par couches

On teste dans l'ordre des couches : physique et liaison, adresse IP et masque, passerelle, IP distante, DNS, service ou application. La première couche qui échoue est celle qu'on examine ; les tests des couches supérieures ne sont pas encore significatifs (un DNS ne peut pas répondre à un poste sans lien).

1.3 Hypothèse, test, preuve

1. Hypothèses : les causes possibles, de la plus probable à la moins probable.
2. Tests non destructifs d'abord : on observe et on lit (voyants, ipconfig /all, ping) avant de modifier quoi que ce soit.
3. Conclusion : on retient la cause prouvée par un test, pas celle qui « tombe en même temps ».

Différencier corrélation et preuve : « la panne a commencé après la mise à jour » est une corrélation, une piste. La preuve, c'est un test qui la confirme : le service s'est arrêté à l'heure de la mise à jour (journal), et la panne disparaît quand il redémarre.

À retenir — à l'écrit, chaque étape se présente ainsi : constat (ce qu'on voit) → hypothèse → test → résultat (valeur relevée) → conclusion ou nouvelle hypothèse. Une conclusion sans test est une supposition.

2.1 Le lien existe-t-il ?

C'est la première question, et elle se règle avant toute configuration IP :

• câble cuivre : fiches RJ45 bien serties et enclenchées, câble ni écrasé ni plié, longueur du canal 100 m au plus (cours PR15) ; fibre : connecteurs propres, bon type, émission/réception non inversées ;
• voyants de lien sur la carte et sur le port du switch (éteint = pas de lien) ;
• port du switch : actif ou désactivé par l'administrateur, prise murale bien brassée sur un port ;
• carte réseau activée dans le système, bon pilote ; Windows affiche « Média déconnecté », Linux NO-CARRIER quand aucun lien n'est détecté ;
• alimentation du switch et du point d'accès ; un point d'accès alimenté par le câble (PoE) s'éteint si le port ou le budget PoE du switch ne suffit pas.

Repères PoE (IEEE 802.3) :

• PoE (802.3af) : 15,4 W garantis au port du switch, 12,95 W disponibles pour l'équipement alimenté.
• PoE+ (802.3at) : 30 W garantis au port du switch, 25,5 W disponibles pour l'équipement alimenté.

À retenir — pas de lien = pas de diagnostic IP. Tant que le voyant est éteint ou que le système affiche « Média déconnecté », on ne modifie ni l'adresse, ni le masque, ni le DNS.

2.2 Vitesse, duplex et erreurs

• Négociation : la carte et le port s'accordent automatiquement sur la vitesse (100 Mb/s, 1 Gb/s…) et le duplex (full : émission et réception simultanées ; half : l'un ou l'autre).
• Désaccord de duplex : si un côté est forcé et l'autre en automatique, le côté automatique ne peut pas connaître le duplex et se replie en half duplex ; le lien fonctionne, mais lentement, avec des erreurs (collisions tardives côté half duplex, erreurs CRC côté full duplex).
• Erreurs CRC : trames reçues abîmées (contrôle d'intégrité faux) ; causes : câble ou fiche défectueux, paire endommagée, longueur excessive, parasites (câble non blindé près d'une source de perturbations, blindage mal raccordé), désaccord de duplex. Un compteur qui augmente est un indice fort.
• Lien à 100 Mb/s au lieu de 1 Gb/s sur une carte gigabit : souvent une paire défectueuse (le gigabit utilise les quatre paires).
• Auto MDI-X : les cartes et switchs actuels adaptent émission et réception ; un câble droit convient presque toujours, y compris entre deux PC.

2.3 Le Wi-Fi, couche radio

En Wi-Fi, la « couche physique » est la radio : SSID visible, signal suffisant, débit, interférences (autres réseaux sur le même canal, micro-ondes en 2,4 GHz, murs épais). Le détail est en section 8.

Piège fréquent — conclure à une panne IP ou DNS alors que le lien est absent ou dégradé. Une adresse 169.254.x.y ou un DNS qui ne répond pas sont des conséquences possibles d'un lien défaillant.

3. Contrôler la configuration IP

Une fois le lien présent, on relève la configuration (ipconfig /all, ip addr, ip route) et on la compare au plan d'adressage (cours PR20) :

• adresse IPv4 dans le réseau prévu (ici 192.168.20.0/24), ni adresse de réseau ni de diffusion ;
• masque / CIDR identique à celui du réseau : un masque faux fait croire au poste que des adresses locales sont distantes (ou l'inverse) ;
• passerelle dans le réseau du poste, égale à l'adresse du routeur ; la table de routage (route print, ip route) doit contenir une route par défaut vers elle ;
• adresse MAC de la bonne carte (Ethernet ou Wi-Fi ?) ;
• même sous-réseau ou non : deux postes ne communiquent directement que s'ils sont dans le même réseau avec le même masque ;
• doublon d'adresse IP : message de conflit, coupures par intermittence, arp -a qui montre une MAC inattendue ; cause fréquente : une adresse fixe placée dans l'étendue DHCP ;
• APIPA 169.254.0.0/16 : le poste est en DHCP mais n'a reçu aucune réponse ; Windows s'attribue une adresse 169.254.x.y/16, sans passerelle, et réessaie régulièrement ;
• DHCP, statique ou réservation : un poste en DHCP reçoit tout du serveur ; une adresse statique est saisie à la main (hors étendue) ; une réservation attribue toujours la même adresse à une MAC, depuis le serveur.

À retenir — l'APIPA dit « aucun bail reçu », pas pourquoi. Les causes possibles sont nombreuses : lien, port, VLAN, serveur arrêté, étendue pleine, serveur qui ignore la carte. C'est un indice, pas une preuve.

4. Diagnostiquer le DHCP

Séquence DORA (détaillée en PR20) : le client diffuse Discover, le serveur répond Offer, le client confirme Request, le serveur valide Acknowledge. Le client renouvelle ensuite son bail avant l'expiration (Request/Ack seulement). Les options transmises comprennent le masque, la passerelle (option 3) et le DNS (option 6).

Pannes typiques :

• absence de bail : APIPA ; on vérifie lien, port, VLAN, puis le serveur ;
• étendue épuisée : toutes les adresses sont prêtées (visiteurs, baux trop longs) ; le journal du serveur indique qu'aucune adresse n'est disponible ;
• mauvais pool : étendue d'un autre réseau, ou qui empiète sur des adresses fixes ;
• serveur inaccessible ou arrêté : aucun Offer ; les postes déjà configurés continuent de fonctionner jusqu'à la fin de leur bail (8 jours ici) — « les autres postes marchent » ne prouve donc pas que le DHCP fonctionne ;
• relais DHCP : le Discover est une diffusion, qui ne traverse pas un routeur ; si le serveur est dans un autre sous-réseau, un agent relais est nécessaire ;
• second serveur DHCP (box personnelle branchée par erreur) : des postes reçoivent un autre réseau, au hasard des renouvellements ;
• mauvaise option : passerelle ou DNS faux distribués à tous les postes.

Tests : ipconfig /all (DHCP activé ? serveur DHCP ? bail obtenu et expirant ?), ipconfig /renew (redemande un bail), journal du serveur.

Important — ipconfig /release coupe la connexion du poste jusqu'au /renew : on ne le lance jamais à distance (on perd la main sur le poste) ni sur un poste de production sans prévenir l'utilisateur. ipconfig /renew seul suffit souvent.

5.1 Connectivité par IP ou résolution de nom ?

Le DNS traduit un nom (www.exemple.be) en adresse (198.51.100.20). Deux tests suffisent à séparer les problèmes :

• ping 198.51.100.20 (par adresse) répond → la connectivité vers Internet fonctionne ;
• ping www.exemple.be (par nom) échoue avec « hôte introuvable » → la résolution de noms est en cause, pas Internet.

À retenir — « ping par IP OK, par nom KO » = problème DNS, pas panne d'Internet. Ne pas confondre absence de résolution et absence d'Internet.

5.2 Interroger le DNS

• Windows : nslookup nom (serveur configuré) ou nslookup nom serveur (serveur choisi).
• Linux : dig nom, dig @serveur nom (paquet dnsutils ou bind-utils, pas toujours installé), resolvectl query nom avec systemd-resolved.

Lire la réponse :

• réponse avec une adresse : le DNS fonctionne pour ce nom ;
• « Non-existent domain » / NXDOMAIN : le serveur répond que le nom n'existe pas (faute de frappe, nom interne demandé à un DNS public) ;
• délai dépassé (timed out) : aucun serveur n'a répondu (DNS configuré faux, arrêté ou injoignable).

5.3 DNS interne et DNS externe

Un DNS interne (ici SRV-01, 192.168.20.5) connaît les noms du réseau de l'entreprise (srv-01.atelier.lan) et relaie les autres questions vers Internet. Un DNS public ou celui du fournisseur (198.51.100.53) ne connaît pas les noms internes. Un poste configuré avec un DNS public navigue normalement mais ne trouve plus les serveurs internes.

5.4 Le cache

Le poste garde en cache les réponses récentes : après une correction, une ancienne réponse peut persister. Windows : ipconfig /displaydns (afficher), ipconfig /flushdns (vider). Linux avec systemd-resolved : resolvectl flush-caches. nslookup interroge directement le serveur sans passer par le cache ni par le fichier hosts : un nslookup correct et un ping par nom faux orientent vers le cache ou le fichier hosts du poste.

6.1 Du plus proche au plus lointain

On teste dans l'ordre : un hôte local (serveur, voisin), la passerelle, puis une destination distante par adresse.

• local OK, passerelle KO : masque, passerelle saisie, doublon d'adresse, VLAN, box arrêtée ;
• passerelle OK, distant KO : au-delà de la passerelle : liaison Internet de la box (synchronisation, connexion au fournisseur), fournisseur, filtrage ;
• tracert (Windows) ou traceroute / tracepath (Linux) montre jusqu'où les paquets vont : le premier saut est la passerelle.

Une ligne * * * au milieu d'un tracert n'est pas une panne si les sauts suivants répondent : certains routeurs ne répondent pas aux sondes. C'est une panne quand plus rien ne répond après un saut.

6.2 Route par défaut, masque et routage

• Route par défaut (0.0.0.0/0) : tout ce qui n'est pas local part vers la passerelle. Sans elle (Linux : aucune ligne default via), le poste répond « Network is unreachable » pour toute adresse extérieure.
• Mauvais masque : la passerelle peut se retrouver hors du réseau calculé ; Windows avertit alors que la passerelle n'est pas dans le même sous-réseau, et le poste ne sort plus.
• Routage inter-sous-réseaux : deux réseaux ne communiquent que par un routeur qui connaît les deux (et des passerelles correctes de chaque côté).
• NAT (notion fonctionnelle) : la box remplace l'adresse privée des postes par son adresse publique (203.0.113.45) pour sortir sur Internet, et fait le chemin inverse pour les réponses. Les adresses privées ne sont jamais routées sur Internet.
• Pare-feu, ACL et filtrage ICMP : un pare-feu (du poste, de la box, du serveur) ou une liste de contrôle d'accès (ACL) peut bloquer un service ou seulement le ping : un ping sans réponse n'est pas une preuve que la machine est éteinte ; on confirme par un autre test (port du service, arp -a, autre machine).

7. Switch et VLAN

• Commutation : le switch apprend sur quel port se trouve chaque adresse MAC (table MAC) et y envoie les trames. Une MAC absente de la table : l'équipement n'a pas émis, ou il n'est pas sur ce switch.
• Ports désactivés : par l'administrateur, ou automatiquement par une protection du port ; le voyant reste éteint.
• VLAN : un switch administrable peut séparer ses ports en réseaux virtuels isolés. Un port placé dans le mauvais VLAN met le poste dans un autre réseau : il reçoit l'adresse d'un autre DHCP (ou aucune → APIPA) et ne voit plus les serveurs.
• Complément : un port access appartient à un seul VLAN (postes) ; un lien trunk transporte plusieurs VLAN entre équipements (switch, point d'accès, routeur).

Piège fréquent — supposer une erreur de VLAN sans indice. On ne l'envisage que si le réseau en utilise (plan, switch administrable) et qu'un relevé le montre : adresse d'un autre réseau, état du port, réorganisation récente.

8.1 Trois problèmes différents

Un poste Wi-Fi « qui ne marche pas » peut avoir trois problèmes distincts, dans cet ordre :

1. radio : le SSID (nom du réseau) est-il visible ? le signal suffit-il ? Un même SSID peut être émis par plusieurs points d'accès, chacun avec son BSSID (adresse MAC de la radio) ;
2. association et authentification : le poste s'associe au point d'accès puis prouve qu'il connaît la clé : WPA2-Personnel (clé partagée, chiffrement AES-CCMP) ou WPA3-Personnel (échange SAE, plus robuste) ; clé incorrecte, profil enregistré avec une ancienne clé, carte qui ne gère pas WPA3 ;
3. adressage : après l'association, le poste demande un bail DHCP comme en filaire ; APIPA ou adresse d'un autre réseau (SSID invités, VLAN) = problème IP.

8.2 Portée, bandes et répéteurs

• 2,4 GHz : porte plus loin, traverse mieux les murs, mais peu de canaux sans chevauchement (1, 6, 11 en pratique) et beaucoup d'interférences (voisins, micro-ondes, Bluetooth).
• 5 GHz : plus de débit et de canaux, mais portée plus courte.
• Répéteur : prolonge la couverture en retransmettant le signal ; il doit lui-même recevoir un bon signal, et un répéteur à une seule radio divise souvent le débit disponible. Un point d'accès supplémentaire raccordé par câble est préférable quand c'est possible.

Ce relevé montre un poste associé et authentifié (WPA2 - Personnel) mais avec un signal de 18 % et 6,5 Mb/s en réception : problème radio (couverture), pas d'adressage.

À retenir — distinguer problème radio (SSID invisible, signal faible, coupures), problème d'authentification (connexion refusée malgré un SSID visible) et problème IP (associé, mais APIPA ou mauvais réseau). La correction n'est pas la même.

9.1 Le réseau répond, la ressource non

Quand le ping du serveur répond, le problème est plus haut : service, nom, chemin, compte ou droits. On suit l'arbre ci-dessous.

• Découverte du réseau : l'onglet Réseau de l'explorateur peut ne pas afficher le serveur (profil réseau « Public », découverte désactivée) sans que l'accès par chemin soit bloqué.
• Chemin UNC : \\serveur\partage (ici \\NAS-01\Compta) ; une faute dans le nom donne « chemin réseau introuvable » (0x80070035) ; \\192.168.20.10\Compta contourne le DNS pour tester.
• Permissions : les droits de partage et les droits NTFS (du dossier) se combinent : depuis le réseau, c'est le plus restrictif qui s'applique (partage en Lecture + NTFS en Modification = lecture seule).
• Compte : en domaine, le compte du domaine ; en groupe de travail, un compte local du serveur ou du NAS ; des identifiants mémorisés périmés (Gestionnaire d'identification) peuvent être refusés sans nouvelle demande.
• Service et pare-feu : le partage de fichiers Windows (SMB) utilise le port TCP 445 ; service arrêté ou port filtré = échec malgré le ping. Test : Test-NetConnection NAS-01 -Port 445 (PowerShell).

9.2 Imprimante réseau

L'imprimante répond au ping mais n'imprime pas : on vérifie la file d'impression (travaux bloqués, « en erreur »), le port utilisé par la file (adresse de l'imprimante à jour ?), le service Spouleur d'impression du poste, puis l'imprimante elle-même (papier, erreurs). Si un seul poste est touché, le problème est sur ce poste ; si tous le sont, sur l'imprimante ou le serveur d'impression.

10. Outils Windows

Commandes de lecture (sans effet sur la configuration) :

• ipconfig /all : adresse, masque, passerelle, DNS, DHCP, bail, MAC ;
• ping : réponse d'une adresse ou d'un nom (ICMP) ;
• tracert -d : chemin jusqu'à une destination ;
• nslookup : réponse d'un serveur DNS ;
• arp -a : correspondances IP ↔ MAC du réseau local ;
• route print : table de routage, route par défaut ;
• netstat -an ou Get-NetTCPConnection (PowerShell) : connexions et ports ouverts ;
• Test-NetConnection hôte -Port n (PowerShell) : ping et test d'un port TCP précis ;
• netsh wlan show interfaces : état de la connexion Wi-Fi.

Commandes de modification (à annoncer à l'utilisateur) :

• ipconfig /renew et ipconfig /release : redemander ou libérer le bail DHCP ;
• ipconfig /flushdns : vider le cache DNS (sans risque).

Lecture ou modification : on commence toujours par lire.

Limites de ping : il teste l'ICMP, pas le service (un site, un partage) ; il peut être filtré ; un ping réussi vers une adresse ne dit rien du nom ni des droits.

11. Outils Linux

• ip addr, ip link : adresses, état de l'interface (UP, NO-CARRIER) ;
• ip route : routes, route par défaut (default via) ;
• ip neigh : voisins IP ↔ MAC (REACHABLE, FAILED) ;
• ping -c 4 : réponse ICMP (4 échos) ;
• traceroute ou tracepath : chemin jusqu'à la destination ;
• dig ou nslookup : réponse DNS ;
• ss -tunap : connexions et ports en écoute ;
• journalctl -u NetworkManager -b : journal du service réseau depuis le démarrage ;
• nmcli device status, nmcli device wifi list : état des interfaces, réseaux Wi-Fi visibles ;
• resolvectl status : serveurs DNS utilisés (systemd-resolved).

Ne pas présumer que tous ces outils sont présents : selon la distribution, dig, traceroute ou nmcli peuvent manquer, et la configuration persistante passe par NetworkManager, Netplan ou un autre outil. Une commande comme ip route add est temporaire (perdue au redémarrage).

Méthode examen — à l'écrit, cite la commande, la valeur relevée et ton interprétation : « ping 192.168.20.1 : 4 reçus sur 4 → la passerelle répond ; ping 198.51.100.20 : 100 % de perte → l'arrêt est au-delà de la box ». Une commande citée seule ne rapporte presque rien.

12.1 La procédure ordonnée

1. État physique : voyants, câble, port, carte activée, Wi-Fi associé.
2. IP et masque : ipconfig /all / ip addr — adresse du bon réseau, pas d'APIPA, bon masque.
3. Passerelle : ping 192.168.20.1 ou arp -a (la passerelle a-t-elle une MAC ?).
4. IP distante : ping 198.51.100.20, tracert pour situer l'arrêt.
5. DNS : nslookup www.exemple.be — bon serveur, réponse correcte.
6. Application ou service : le site, le partage, l'imprimante, le compte, les droits.

À chaque étape : résultat attendu si tout va bien, interprétation sinon, et branche suivante. Exemple : à l'étape 2, une adresse 169.254 envoie vers la branche DHCP ; une adresse d'un autre réseau vers la branche VLAN ou second serveur DHCP.

12.2 Arbre de diagnostic général

Ce relevé Linux arrête la procédure dès l'étape 1 : NO-CARRIER, aucune route. On cherche le câble ou le port, pas l'adresse.

13.1 Symptôme → causes possibles → test discriminant → résultat → action

Un test discriminant est celui qui départage deux hypothèses : son résultat est différent selon la cause. On le choisit avant de réparer.

13.2 Pannes combinées

Une intervention réelle cumule parfois deux causes ; corriger la première ne fait pas disparaître tous les symptômes. On revérifie toute la procédure après chaque correction.

• Câble défectueux + DNS faux : la liaison est lente et les noms ne sont pas résolus ; un cordon neuf rend la vitesse, pas les noms.
• Mauvais masque + mauvaise passerelle : corriger le masque ne suffit pas si la passerelle saisie n'est pas celle du routeur.
• DHCP intermittent : deux serveurs DHCP, ou étendue presque pleine ; la panne « change de poste » selon les renouvellements de bail.
• Réseau local OK mais Internet KO : passerelle, liaison de la box, fournisseur.
• Internet OK mais partage KO : DNS interne, service, chemin, compte ou droits.
• Wi-Fi associé sans IP : DHCP, VLAN du SSID, étendue pleine.
• Lenteur intermittente : duplex, CRC, signal Wi-Fi, saturation ; on mesure au moment du symptôme (heure notée par l'utilisateur).

14. Sécurité des interventions

• Autorisation : on ne modifie pas la configuration d'un réseau de production (box, switch, serveur DHCP ou DNS, NAS) sans l'accord du responsable.
• État initial : on relève et on sauvegarde la configuration avant de la changer (copie du fichier, capture des valeurs).
• Retour arrière : on sait comment revenir à l'état initial si la modification aggrave la situation ; une modification à la fois.
• Impact : prévenir les utilisateurs d'une coupure (redémarrage de la box, ipconfig /release, relance d'un service).
• Pas de scan intrusif non autorisé : un balayage de ports ou d'adresses sur le réseau d'un client est interdit sans accord explicite et peut perturber des équipements.
• Confidentialité des journaux : journaux, captures et configurations contiennent des noms, des adresses et parfois des mots de passe ; ils restent chez le client ou sont transmis par un moyen autorisé, jamais sur un support personnel.

15. Le rapport professionnel

1. Contexte : client, date, demandeur, demande.
2. Symptômes exacts et périmètre (un poste ou tous, filaire ou Wi-Fi, local ou Internet).
3. Schéma ou référence au plan du réseau concerné.
4. Hypothèses envisagées.
5. Tests et sorties : chaque commande avec la valeur relevée.
6. Cause confirmée — ou incertaine, dite comme telle, avec ce qui reste à vérifier.
7. Correction effectuée, avec l'autorisation et l'état initial noté.
8. Tests finaux : passerelle, IP distante, nom, service demandé, idéalement avec l'utilisateur.
9. Prévention : recommandation pour éviter la récidive.
10. Restitution : explication claire au client, sans jargon inutile.

Méthode examen — un rapport se juge sur l'exactitude des valeurs, la logique constat → test → cause → action → validation, et l'honnêteté : « cause non déterminée » vaut mieux qu'une cause inventée.