Tableau de mesures attendu : les valeurs de tension mesurées doivent être comprises dans une tolérance de ±2% par rapport au réglage de l'alimentation (5V, 9V, 12V). Les résistances mesurées doivent être comprises dans la tolérance indiquée par le code couleur (généralement ±5% pour un 4ème anneau doré).

Calcul attendu pour le point 5 : si le montage utilise une résistance de 220Ω alimentée en 9V, l'intensité théorique attendue est I = U/R = 9/220 ≈ 0.041 A (41 mA). L'écart entre la résistance calculée (R = U mesuré / I mesuré) et la résistance affichée directement par le multimètre doit rester inférieur à 5%.

Sources d'erreur à mentionner : résistance interne du multimètre en mode ampèremètre, tolérance propre des résistances, qualité des contacts sur breadboard, dérive de l'alimentation labo si non régulée.

Exemple de jeu de données type (à adapter aux fiches réellement distribuées) : 5 modèles de serveurs avec puissances nominales de 350W, 450W, 550W, 650W et 800W. Pour 2 unités de chaque (10 serveurs) : puissance totale = 2 × (350+450+550+650+800) = 2 × 2800 = 5600 W = 5.6 kW.

Conversion en kVA : S = P / cos φ = 5.6 / 0.95 ≈ 5.89 kVA.

Comparaison avec le PDU (3.68 kVA) : un seul PDU de 3.68 kVA est insuffisant. Il faut au minimum 2 PDU (5.89 / 3.68 ≈ 1.6, arrondi à 2 pour la capacité, ce qui apporte par ailleurs une redondance bienvenue).

Avec marge de sécurité de 20% : charge à couvrir = 5.89 × 1.2 ≈ 7.07 kVA, ce qui confirme la nécessité de 2 PDU et invite à vérifier leur répartition de charge équilibrée entre les deux.

Méthode de calcul de la capacité triphasée disponible : P = U × I × √3 × cos φ = 400 × 63 × 1.732 × 0.95 ≈ 41.4 kVA disponibles sur l'arrivée du site.

Exemple de répartition (à adapter au jeu de données fourni) : si chaque baie nécessite environ 6 kVA après marge de sécurité (cohérent avec le TP2), 3 baies représentent environ 18 kVA — largement compatible avec les 41.4 kVA disponibles, laissant une marge confortable pour une extension future.

Fiche de dimensionnement attendue : tableau avec une ligne par baie (puissance active, puissance apparente, PDU nécessaires), une ligne de total, et une conclusion explicite sur la compatibilité avec l'arrivée électrique du site et la marge restante pour une croissance future.

Exemple de conversion décimal → binaire (156) : 156÷2=78 reste 0 ; 78÷2=39 reste 0 ; 39÷2=19 reste 1 ; 19÷2=9 reste 1 ; 9÷2=4 reste 1 ; 4÷2=2 reste 0 ; 2÷2=1 reste 0 ; 1÷2=0 reste 1. En lisant les restes de bas en haut : 10011100.

Vérification : 10011100 = 128+16+8+4 = 156. ✓

Exemple de conversion décimal → hexadécimal (500) : 500÷16=31 reste 4 ; 31÷16=1 reste 15(F) ; 1÷16=0 reste 1. En lisant de bas en haut : 0x1F4.

Exemple d'addition binaire (1011 + 0110) : en colonnes de droite à gauche avec report : 1+0=1 ; 1+1=10 (écrire 0, retenue 1) ; 0+1+1(retenue)=10 (écrire 0, retenue 1) ; 1+0+1(retenue)=10 (écrire 0, retenue 1) → résultat 10001 (=17 en décimal, vérification : 11+6=17 ✓).

Exemple complet — adresse 192.168.1.10 / 24 :

Conversion en binaire : 192=11000000, 168=10101000, 1=00000001, 10=00001010.
Masque /24 = 11111111.11111111.11111111.00000000 = 255.255.255.0.

Adresse réseau (ET logique adresse/masque) : 192.168.1.0.
Adresse de broadcast : 192.168.1.255.
Nombre d'adresses utilisables : 2^8 - 2 = 254 adresses (256 possibles, moins l'adresse réseau et l'adresse de broadcast).

Exemple avec masque /28 : 2^4 - 2 = 14 adresses utilisables seulement, ce qui illustre concrètement l'impact direct du choix de masque sur la taille du sous-réseau — point essentiel pour le module DHCP plus tard dans la formation.

Exemple — décomposition de #1A5FA8 : 1A (hex) = 26 (décimal), 5F (hex) = 95 (décimal), A8 (hex) = 168 (décimal). Couleur RGB(26, 95, 168) — un bleu profond utilisé notamment dans les chartes graphiques techniques.

Exemple — reconstruction depuis RGB(212, 175, 55) : 212 → D4 (hex), 175 → AF (hex), 55 → 37 (hex). Code final : #D4AF37 (un doré).

Exemple de fonction à simplifier : F = A.B + A.NOT(B) + NOT(A).B

Par l'algèbre de Boole : A.B + A.NOT(B) = A.(B+NOT(B)) = A.1 = A. Donc F = A + NOT(A).B. Par distributivité : A + NOT(A).B = (A+NOT(A)).(A+B) = 1.(A+B) = A + B.

Par tableau de Karnaugh (2 variables A, B) : les 3 cases à 1 (AB=11, AB=10, AB=01) forment un groupement qui se lit directement comme A + B — résultat identique, validant la méthode des deux côtés.

Point pédagogique à souligner : le tableau de Karnaugh devient nettement plus rapide que l'algèbre de Boole dès que le nombre de variables augmente (3 ou 4 variables) — c'est pour cette raison qu'il est privilégié en pratique industrielle.

Table de vérité : H=0,S=0 → FA=1 (pas d'heure de pointe, pas de véhicule sur B, A reste vert par défaut) ; H=0,S=1 → FA=0 (pas d'heure de pointe MAIS véhicule détecté sur B, on cède le passage) ; H=1,S=0 → FA=1 ; H=1,S=1 → FA=1 (priorité absolue à A en heure de pointe, même avec véhicule sur B).

Fonction simplifiée : FA = H + NOT(S), soit littéralement "le feu A est vert si on est en heure de pointe, ou si aucun véhicule n'est détecté sur B".

Schéma logique : une porte OR avec en entrée H directement et NOT(S) (donc un inverseur NOT en amont sur le signal S), sortie FA.

Réalisation physique : 1 inverseur (74LS04) pour générer NOT(S), 1 porte OR (74LS32) pour combiner H et NOT(S). Câblage simple à 2 circuits intégrés, validé par test des 4 combinaisons d'interrupteurs et observation de la LED de sortie.

Grille de validation attendue : les 4 combinaisons testées doivent donner exactement les résultats de la table de vérité du TP2 (FA=1,0,1,1 pour H,S = 00,01,10,11). Tout écart doit être expliqué par un défaut de câblage ou de composant, jamais par une erreur de logique si la simplification du TP2 a été correctement validée.

Pannes les plus fréquentes à anticiper : inversion d'une broche d'alimentation sur le circuit intégré (Vcc/GND), résistance de protection LED absente ou mal calibrée, mauvais contact sur breadboard.

Programme attendu pour le point 3 (bouton → LED) : dans la fonction loop(), lire l'état de la broche du bouton avec digitalRead(), puis utiliser une structure if (etatBouton == HIGH) { digitalWrite(ledPin, HIGH); } else { digitalWrite(ledPin, LOW); }.

Programme attendu pour le point 5 (capteur → LED automatique) : lire la valeur du capteur avec analogRead() (variable entre 0 et 1023), puis comparer à un seuil (par exemple 400) avec if (valeurCapteur < 400) { digitalWrite(ledPin, HIGH); }.

Point d'attention pour la correction : vérifier que chaque binôme a bien identifié le sens de variation du capteur (valeur qui diminue ou augmente selon l'obscurité, ce qui dépend du montage en pont diviseur de tension utilisé).

Justification attendue pour le point 1 : une broche Arduino délivre typiquement un courant maximal de 20-40 mA, insuffisant pour la plupart des moteurs DC qui nécessitent plusieurs centaines de mA. Le relais permet de commander, avec un faible courant de pilotage, un circuit de puissance totalement séparé électriquement.

Programme attendu pour le point 4 : structure similaire au TP1 (lecture capteur + condition + action), mais avec digitalWrite() sur la broche du relais plutôt que sur une LED — démonstration que la même logique de programmation s'applique à n'importe quel actionneur.

Grille de validation de la spécification : la liste des entrées/sorties doit être complète et sans ambiguïté (chaque capteur et actionneur a un rôle clairement défini), les conditions de transition doivent couvrir tous les cas (y compris les cas d'échec), et le schéma de câblage doit être cohérent avec les broches Arduino réellement disponibles.

Erreur fréquente à corriger : oublier de spécifier le comportement en cas d'échec ou de timeout (par exemple, que se passe-t-il si la séquence du digicode n'est jamais complétée ?). C'est l'occasion de rappeler que la table de vérité de S3 doit couvrir TOUTES les combinaisons possibles, pas seulement le cas de succès.

Critère 1 — Conformité fonctionnelle (40%) : le système répond-il à l'intégralité du cahier des charges, y compris les cas d'échec ?

Critère 2 — Qualité du câblage et de l'intégration (20%) : montage propre, connexions fiables, pas de faux contact en cours de démonstration.

Critère 3 — Qualité du code (20%) : code lisible, commenté, structuré (pas de répétition inutile, noms de variables clairs).

Critère 4 — Documentation et présentation orale (20%) : capacité à expliquer clairement les choix techniques et les difficultés rencontrées.

Grille de vérification du remontage : le poste doit démarrer sans bip d'erreur (ou avec le bip de séquence normale selon la carte mère), le BIOS/UEFI doit afficher la quantité de RAM correcte et le modèle de CPU attendu, le stockage doit être détecté.

Pannes fréquentes à anticiper et leur diagnostic : absence de démarrage = vérifier le branchement de l'alimentation principale et du connecteur CPU sur la carte mère ; RAM non détectée = vérifier le bon enclenchement des barrettes dans les slots DIMM ; bip répétitif au démarrage = généralement un problème de RAM mal insérée (code constructeur à vérifier sur la documentation de la carte mère).

Points de vérification de compatibilité attendus : le socket du CPU doit correspondre exactement à celui de la carte mère, le type et la fréquence de RAM doivent être supportés par la carte mère (vérifiable dans sa documentation), le connecteur d'alimentation CPU (souvent 4 ou 8 broches) doit être présent sur l'alimentation fournie.

Calcul attendu de puissance estimée : sommer les consommations typiques (CPU ~65-95W, carte mère et périphériques ~30-50W, stockage ~5-10W par disque) et vérifier que le total reste inférieur à 70-80% de la puissance nominale de l'alimentation, conformément à la marge de sécurité vue en S1.

Point de vigilance critique à valider avant toute manipulation : demander à chaque binôme de confirmer explicitement, avant toute commande destructrice, l'identifiant exact du disque de test (ex : /dev/sdb et non /dev/sda qui contiendrait potentiellement le système). C'est l'erreur la plus dangereuse possible à ce stade de la formation.

Résultat attendu après formatage : chaque partition doit apparaître montée avec le système de fichiers demandé (vérifiable avec la commande mount ou lsblk -f), et l'espace total des 3 partitions doit correspondre à la taille du disque moins un léger surcoût lié aux métadonnées de chaque système de fichiers.

Commande dd attendue (exemple) : dd if=/dev/sdb of=/mnt/externe/image_disque.img bs=4M status=progress — l'option bs=4M accélère le transfert par rapport au bloc par défaut, et status=progress permet de suivre l'avancement, point important à souligner pour des images de grande taille.

Validation de la restauration : après restauration, comparer la somme de contrôle (md5sum ou sha256sum) du disque restauré avec celle de l'image source — une correspondance exacte valide la restauration bit à bit.

Point pédagogique central de cette semaine : insister sur le fait qu'une image disque n'est utile que si elle a été testée en restauration au moins une fois — une sauvegarde jamais restaurée n'est pas une sauvegarde fiable, c'est une simple supposition.

Points de vérification du partitionnement : la partition racine (/) doit avoir un espace suffisant pour le système et les applications (généralement 20 Go minimum pour un usage de formation), la partition swap est recommandée même avec une quantité de RAM confortable, pour la gestion de la mise en veille et des pics de charge.

Vérification réseau attendue : après installation, la commande de diagnostic réseau appropriée à la distribution doit montrer une interface active avec une adresse IP cohérente avec le réseau de la salle.

Note méthodologique : les noms exacts des commandes de gestion de paquets (apt, dnf, pacman selon la distribution) doivent être adaptés par le formateur à la distribution effectivement utilisée en cours.

Exemple de permission à décoder : rwxr-xr-- se lit comme propriétaire=lecture/écriture/exécution (rwx=7 en octal), groupe=lecture/exécution (r-x=5), autres=lecture seule (r--=4), soit chmod 754 — lien direct et explicite avec la conversion octale vue en S2.

Exemple d'enchaînement de commandes attendu : une commande combinant recherche de fichiers, filtrage de contenu et redirection vers un fichier de résultat, en expliquant le rôle de chaque pipe successif.

Structure attendue du fichier unitaire personnalisé : une section [Unit] décrivant le service, une section [Service] précisant la commande à exécuter et le type de service, une section [Install] précisant le niveau de démarrage automatique souhaité.

Méthode de diagnostic attendue pour l'exercice de panne provoquée : consulter le statut du service pour voir le code d'erreur, puis consulter les journaux détaillés du service pour identifier le message d'erreur précis, qui doit pointer directement vers la cause du dysfonctionnement introduit.

Vérification attendue pour le dossier partagé : le propriétaire du groupe doit avoir les droits de lecture/écriture, les autres utilisateurs aucun droit — test pratique en se connectant avec un compte hors groupe pour confirmer le refus d'accès.

Schéma attendu en restitution : un tableau ou diagramme simple croisant utilisateurs, groupes d'appartenance, et droits effectifs sur chaque dossier créé pendant le TP.

Structure attendue du script de sauvegarde : shebang en première ligne, variable définissant le dossier source et le dossier de destination, vérification conditionnelle de l'existence du dossier source, commande de compression avec horodatage dans le nom du fichier généré, message de confirmation ou d'erreur en sortie.

Point de vigilance pour la planification cron : vérifier que le script a les droits d'exécution nécessaires et que les chemins utilisés dans le script sont absolus (cron n'exécute pas dans le même contexte de répertoire qu'une session interactive).

Structure attendue du script de surveillance : récupération de la valeur courante (pourcentage disque, charge CPU, utilisation mémoire) via les commandes système appropriées, comparaison avec un seuil défini en variable, écriture d'une ligne d'alerte horodatée dans un fichier journal dédié si le seuil est dépassé.

Point pédagogique central : insister sur le fait que cette approche de supervision basique par script est un point de départ pédagogique — en environnement de production réel, des outils dédiés de supervision (à choisir selon ce qui est maintenu et pertinent au moment de l'enseignement) offrent des fonctionnalités bien plus complètes (historisation, tableaux de bord, alertes multi-canaux).

Vérification de l'installation IIS : ouvrir un navigateur sur la même machine et accéder à http://localhost — la page d'accueil IIS doit s'afficher, confirmant que le rôle est actif et que le service écoute sur le port 80.

Commandes PowerShell attendues : Get-Service pour lister les services, Stop-Service et Start-Service (ou Restart-Service) avec le nom du service IIS pour le redémarrer. Souligner la cohérence avec la logique de gestion de service vue en S9 sous Linux (systemctl) — même concept, syntaxe différente.

Point pédagogique central : insister sur la cohérence de la logique entre Linux et Windows — gestion de services, scripts d'automatisation, redirection de sortie — pour que les apprenants voient les deux systèmes comme deux implémentations du même modèle conceptuel, pas comme deux mondes incompatibles.

Structure attendue du script PowerShell : même logique que le script shell de S10 (variable, condition, action, message), simplement avec la syntaxe PowerShell (cmdlets, paramètres nommés, gestion d'erreur avec try/catch basique).

Vérification des permissions NTFS attendue : utiliser l'onglet Sécurité des propriétés d'un dossier pour afficher les permissions effectives d'un compte donné — la "permission effective" prend en compte les héritages et les appartenances aux groupes, pas uniquement les permissions explicites visibles en premier niveau.

Trace attendue dans les journaux Sécurité : les tentatives d'accès refusé génèrent un événement d'ID spécifique (à identifier sur la version utilisée) dans le journal Sécurité — cet exercice ancre l'importance des journaux pour le diagnostic et l'audit de sécurité.

Problèmes types suggérés pour l'exercice de diagnostic : permission NTFS manquante pour un groupe (observable avec Get-Acl) ; partage réseau avec permission de partage plus restrictive que la permission NTFS (la permission effective est toujours la plus restrictive des deux) ; service mal configuré avec dépendance non satisfaite (visible dans les journaux Système).

Vérification post-installation de l'hyperviseur : l'interface web doit être accessible depuis un poste client via l'adresse IP configurée pendant l'installation, sur le port par défaut. Le nœud doit apparaître comme opérationnel dans le tableau de bord.

Vérification de la restauration depuis snapshot : le fichier supprimé doit être de nouveau présent après restauration — c'est la démonstration concrète que le snapshot a bien capturé l'état antérieur à la suppression. Insister sur la différence avec une sauvegarde externe : si l'hyperviseur lui-même est en panne, le snapshot devient inaccessible.

Résultat attendu du surengagement : avec un surengagement léger (10-20% au-delà de la RAM physique), l'hyperviseur utilise la mémoire ballooning ou le swap pour gérer la demande — les VMs fonctionnent mais avec une dégradation de performance mesurable. Avec un surengagement excessif, le risque de crash des VMs augmente fortement.

Vérification du clone : les deux instances doivent avoir des identifiants différents (IP si DHCP, hostname si reconfigurés) — un clone non reconfigurés peut créer des conflits réseau, point important à souligner.

Résultats attendus du test de bascule : le délai de détection de la panne d'un nœud est typiquement de quelques secondes à quelques minutes selon la configuration du cluster (heartbeat timeout). La VM doit redémarrer automatiquement sur le nœud survivant, avec un RTO effectif correspondant à ce délai de détection + le temps de démarrage de la VM.

Point pédagogique sur le RPO : en cas de panne sans stockage partagé, les données non sauvegardées depuis la dernière snapshot ou sauvegarde sont perdues — le RPO est donc directement lié à la fréquence des sauvegardes, pas à la configuration HA seule.

Plan de sauvegarde attendu : le document doit préciser explicitement le RPO (quelle est la perte de données maximale si une restauration est nécessaire, en fonction de la fréquence des sauvegardes), le RTO (combien de temps prend la restauration complète, mesuré pendant le TP), et la durée totale de rétention des sauvegardes.

Point de vigilance critique : avant de désactiver l'authentification par mot de passe, toujours vérifier que la connexion par clé fonctionne depuis une session ouverte distincte — si la clé est mal configurée et qu'on ferme la session active, on se bloque hors du serveur. C'est l'erreur la plus fréquente et la plus coûteuse à ce stade.

Résultat attendu de l'audit : une liste claire distinguant les services nécessaires (à conserver), les services utiles mais non critiques (à évaluer), et les services inutiles (à désactiver) selon le rôle attendu du serveur.

Tableau de comparaison attendu : SSH Linux ↔ RDP/WinRM Windows (accès distant sécurisé), iptables/nftables Linux ↔ Pare-feu Windows Defender (filtrage réseau), apt/dnf Linux ↔ Windows Update (mises à jour), journalctl Linux ↔ Observateur d'événements Windows (journaux) — la logique est identique dans les deux cas.

Critère 1 — Conformité fonctionnelle (35%) : tous les éléments du cahier des charges sont déployés et opérationnels.

Critère 2 — Sécurité (25%) : durcissement effectivement appliqué, pare-feu correctement configuré, aucun service inutile ouvert.

Critère 3 — Continuité de service (20%) : sauvegardes automatisées opérationnelles, restauration testée et documentée, RPO/RTO réalistes.

Critère 4 — Documentation et présentation (20%) : document clair et complet, démonstration maîtrisée en soutenance, capacité à expliquer les choix techniques.

Questions types pour évaluer la compréhension réelle : "Si ce serveur était attaqué ce soir et votre SSH était compromis, quelle serait votre première action ?" ; "Votre sauvegarde quotidienne plante silencieusement depuis 3 jours — comment le détectez-vous ?" ; "Votre VM Linux consomme soudainement 100% CPU — comment diagnostiquez-vous ?"

Critère discriminant entre la mémorisation et la compréhension : un apprenant qui comprend peut répondre à une situation inédite en raisonnant à partir des principes. Un apprenant qui a mémorisé ne peut répondre qu'aux situations déjà vues exactement telles quelles.

Exemple de découpage en sous-réseaux (/24 divisé en 4 sous-réseaux /26) :
Sous-réseau 1 : 192.168.10.0/26 (hôtes .1 à .62, broadcast .63)
Sous-réseau 2 : 192.168.10.64/26 (hôtes .65 à .126, broadcast .127)
Sous-réseau 3 : 192.168.10.128/26 (hôtes .129 à .190, broadcast .191)
Sous-réseau 4 : 192.168.10.192/26 (hôtes .193 à .254, broadcast .255)

Méthode de diagnostic par couche attendue : couche 1 (câble/connecteur physique), couche 2 (table ARP, adresse MAC), couche 3 (ping, adresse IP, masque, passerelle), couche 4 (netstat/ss, port ouvert ou non).

Schéma attendu : le chemin d'un paquet HTTP doit montrer les 4 couches actives en pratique (Application HTTP → Transport TCP → Réseau IP → Liaison Ethernet), avec les adresses et ports correspondants à chaque couche, et la transformation en signal physique au niveau du câble.

Résultat attendu de la segmentation : les machines du VLAN 10 peuvent se pinger entre elles, mais un ping depuis une machine VLAN 10 vers une machine VLAN 20 doit échouer — la segmentation VLAN isole correctement les groupes au niveau couche 2.

Erreur fréquente : port trunk non configuré correctement entre les deux switches (oublier d'autoriser les VLANs sur le trunk) — se traduit par une machine qui peut joindre les machines du même VLAN sur le même switch, mais pas celles du même VLAN sur le switch distant.

Point pédagogique clé : la segmentation VLAN sur l'hyperviseur reproduit exactement les mêmes principes que la segmentation physique sur un switch réel — les VMs "voient" leur réseau de la même manière qu'une machine physique voit son VLAN. C'est la démonstration concrète que la virtualisation des ressources réseau (S13) suit exactement les mêmes règles que le réseau physique.

Configuration inter-VLAN attendue : le routeur dispose d'une sous-interface par VLAN (avec le tag 802.1Q correspondant et une adresse IP dans chaque sous-réseau VLAN), le port trunk du switch connecté au routeur autorise tous les VLANs. Les machines de chaque VLAN ont comme passerelle l'adresse IP de la sous-interface correspondante du routeur.

Point fondamental à ancrer : sur un réseau à routeurs multiples, l'adresse IP source et destination d'un paquet ne changent jamais tout au long du trajet — seules les adresses MAC de la trame Ethernet changent à chaque saut (elles identifient la liaison locale, pas le chemin global). C'est la différence conceptuelle centrale entre la couche 2 (adressage local) et la couche 3 (adressage global).

Vérification du relais DHCP : un client dans VLAN 20 doit recevoir une adresse du pool VLAN 20 configuré sur le serveur DHCP, même si le serveur DHCP est physiquement dans VLAN 10 — le relais transmet le Discover au-delà de la frontière VLAN.

Erreur fréquente : oublier de configurer la passerelle (option routers) dans le pool DHCP — le client reçoit une adresse mais ne peut pas communiquer au-delà de son sous-réseau.

Champs DHCP à identifier dans Wireshark : CHADDR = adresse MAC du client, yiaddr = adresse IP proposée/attribuée, siaddr = adresse IP du serveur, option 3 = passerelle, option 6 = serveurs DNS, option 51 = durée du bail.

Vérification de la résolution fonctionnelle : depuis une VM cliente configurée avec le serveur DNS de la formation, une requête sur un nom de la zone interne doit retourner l'adresse correcte, et une requête sur un nom Internet (ex : un site web public) doit également être résolue via le forwarder.

Préparation pour Active Directory : la zone interne doit être configurée pour accepter les mises à jour dynamiques, ce qui permettra au contrôleur de domaine (S22) d'enregistrer automatiquement ses enregistrements SRV lors de l'installation.

Point pédagogique central de cette semaine : à l'issue de ce TP, l'infrastructure complète est en place — VLAN segmentés (S18), routage inter-VLAN (S19), distribution d'adresses automatique avec passerelle et DNS distribués par DHCP (S20), résolution de noms locale et externe opérationnelle (S21). C'est sur cette infrastructure que sera installé Active Directory en S22.

Vérification des enregistrements SRV : dans la zone DNS du domaine, vérifier l'existence des enregistrements _ldap._tcp, _kerberos._tcp et _kpasswd._tcp dans le sous-dossier _tcp — leur présence confirme que le DC s'est correctement enregistré et que les clients pourront le localiser.

Erreur fréquente : le DNS du serveur Windows pointe vers un serveur externe au lieu de lui-même (ou du DNS de S21) — l'installation du DC échoue ou les SRV ne sont pas créés dans la bonne zone.

Point pédagogique sur la délégation : la délégation de contrôle dans AD permet d'appliquer le principe du moindre privilège (S15) à l'échelle de l'annuaire — un helpdesk peut réinitialiser des mots de passe sans être administrateur du domaine, réduisant la surface d'exposition en cas de compromission du compte helpdesk.

Comportement attendu pour la GPO de lecteur réseau : un utilisateur de l'OU Technique voit le lecteur réseau mappé automatiquement à sa connexion sur n'importe quel poste joint au domaine. Un utilisateur d'une autre OU ne voit pas ce lecteur — le filtre de sécurité ou la portée de l'OU garantit l'isolation.

Interprétation du rapport gpresult : le rapport liste les GPO appliquées (avec leur OU d'origine) et les GPO refusées (avec la raison du refus) — c'est l'outil de diagnostic de première intention pour tout problème de GPO non appliquée.

Méthode de diagnostic attendue : 1) vérifier si la GPO est liée à la bonne OU (console GPMC), 2) vérifier le filtre de sécurité (le groupe de l'utilisateur doit avoir les droits "Lire" et "Appliquer"), 3) forcer l'actualisation des GPO sur le poste client, 4) relancer gpresult pour confirmer.

Vérification de la résolution DNS : depuis un poste client sur le même réseau, résoudre le nom du site via le DNS de S21 — la réponse doit retourner l'adresse IP du serveur web. Sans cette étape, le navigateur ne peut pas trouver le serveur par son nom.

Erreur fréquente pour les Virtual Hosts : oublier de créer un enregistrement DNS distinct pour chaque Virtual Host — les deux noms de domaine doivent résoudre vers la même IP du serveur, mais chacun doit avoir son propre enregistrement A dans la zone DNS.

Codes d'erreur et leur cause : 403 Forbidden = les permissions sur le répertoire ou le fichier empêchent le serveur web de le lire (vérifier les permissions UNIX, lien S8) ; 502 Bad Gateway = le service applicatif backend (PHP-FPM ou équivalent) n'est pas actif ou n'écoute pas sur le bon socket ; certificat expiré = recréer le certificat auto-signé ou en prolonger la durée de validité.

Exemple de requête JOIN attendue : si la base contient une table "utilisateurs" et une table "commandes" liées par une clé étrangère, la requête SELECT u.nom, c.produit FROM utilisateurs u INNER JOIN commandes c ON u.id = c.utilisateur_id retourne les couples utilisateur/commande — démontrer que les données de deux tables peuvent être combinées sans duplication.

Vérification de la restauration : comparer le nombre de lignes dans chaque table avant et après restauration — ils doivent être identiques.

Script de sauvegarde attendu : appel à l'outil de dump du SGBD avec les identifiants de connexion, redirection de la sortie vers un fichier horodaté, nettoyage des fichiers plus anciens que 7 jours — même structure que le script de sauvegarde de S10 appliquée ici aux données SQL.

Structure attendue du rapport d'audit : pour chaque vulnérabilité — système concerné, description du problème, niveau de criticité, impact potentiel, recommandation corrective précise. Un rapport d'audit sans recommandation concrète est inutile.

Vulnérabilités types à retrouver dans l'infrastructure de la formation : port SSH sur le port par défaut non changé si oublié en S15, mises à jour manquantes sur une VM non touchée depuis plusieurs semaines, compte administrateur local avec mot de passe faible sur un poste non joint au domaine, serveur BDD (S25) dont le port est accessible depuis l'extérieur du réseau interne.

Critère 1 — Complétude de l'architecture (25%) : tous les composants sont présents, fonctionnels et documentés — de la couche physique (S6) jusqu'aux services applicatifs (S24-S25).

Critère 2 — Cohérence et intégration (25%) : les composants s'articulent logiquement — le DNS (S21) alimente l'AD (S22), les VLANs (S18) sont alignés avec les GPO (S23), les sauvegardes (S14) couvrent toutes les VMs critiques.

Critère 3 — Sécurité appliquée (25%) : les principes de S15 et S26 sont réellement implémentés, pas juste cités — le rapport d'audit prouve la vérification effective.

Critère 4 — Capacité de recul (25%) : l'apprenant identifie avec précision ce qui fonctionne, ce qui manque, et ce qu'il ferait différemment avec plus de temps ou de ressources.

Questions types discriminantes : "Si votre contrôleur de domaine unique tombe en panne à 8h un lundi matin, que se passe-t-il pour les 50 utilisateurs qui arrivent au bureau ?" ; "Votre serveur web sert maintenant des données personnelles — quelles sont les trois premières mesures de sécurité que vous ajouteriez ?" ; "Un collègue vous dit que le ping ne répond plus entre deux VMs — par où commencez-vous ?"

Ce que cette soutenance valide : pas la mémorisation de commandes — ça, c'est accessible à tout le monde avec un moteur de recherche. Ce qu'elle valide, c'est la capacité à raisonner sur un système complexe, à identifier la couche concernée, à proposer une méthode de diagnostic structurée, et à prendre des décisions justifiées en conditions d'incertitude.