Chapitre 920 minIntermédiaire
Les tâches types de la phase 2
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- ajouter un VLAN, une règle de pare-feu ou un partage ;
- modifier le DHCP et le DNS ;
- sauvegarder, restaurer et superviser un élément ;
- écrire un script et rendre compte d'un incident.
Les tâches types de la phase 2 de l'E6 SISR sont les évolutions qu'une commission peut demander en une heure sur une infrastructure : un VLAN, un changement DHCP ou DNS, une règle de pare-feu, un partage, de la répartition de charge, une sauvegarde, une supervision, un script, un incident à résoudre. Pour chacune, ce chapitre donne la méthode, un exemple complet sur l'infrastructure de Ravelle Conseil, les tests et les pièges.
L'exemple utilise l'infrastructure décrite au chapitre 4 : pare-feu pfSense PF-SIEGE, passerelle .254 de chaque VLAN ; commutateur Cisco SW-CORE ; VLAN 10 utilisateurs (10.10.10.0/24), VLAN 20 serveurs (10.10.20.0/24), VLAN 30 administration (10.10.30.0/24) ; contrôleurs de domaine SRV-AD1 (.10) et SRV-AD2 (.11) pour AD DS, DNS et DHCP en basculement ; domaine ravelle.lan. Adapte les noms à ton infrastructure : la méthode reste la même.
Ajouter un VLAN et le router
La demande type. Créer un nouveau périmètre : visiteurs, téléphonie, caméras, un nouveau service.
La méthode. Commutateur (VLAN, ports d'accès, trunk), puis pare-feu ou routeur (sous-interface ou interface VLAN, adresse de passerelle), puis adressage (DHCP), puis filtrage, puis tests.
L'exemple. Le VLAN 40 INVITES, 10.10.40.0/24, sur les ports Fa0/13 à Fa0/16.
Sur le commutateur :
SW-CORE# configure terminal
SW-CORE(config)# vlan 40
SW-CORE(config-vlan)# name INVITES
SW-CORE(config-vlan)# exit
SW-CORE(config)# interface range fa0/13 - 16
SW-CORE(config-if-range)# switchport mode access
SW-CORE(config-if-range)# switchport access vlan 40
SW-CORE(config-if-range)# spanning-tree portfast
SW-CORE(config-if-range)# exit
SW-CORE(config)# interface gi0/1
SW-CORE(config-if)# switchport trunk allowed vlan add 40
SW-CORE(config-if)# end
SW-CORE# show vlan brief
SW-CORE# show interfaces trunk
SW-CORE# copy running-config startup-config
Sur pfSense :
- Interfaces > Assignments > VLANs : ajoute le VLAN 40 sur l'interface parente du trunk (par exemple
igb1), descriptionINVITES. - Interfaces > Assignments : ajoute la nouvelle interface
igb1.40, active-la, renomme-laINVITES, adresse IPv4 statique10.10.40.254/24. - L'adressage et le filtrage suivent dans les tâches DHCP et DNS et pare-feu.
Les tests. show interfaces trunk liste 10, 20, 30 et 40 sur Gi0/1 ; un poste branché sur Fa0/13 avec une adresse fixe 10.10.40.10 joint 10.10.40.254 ; un poste du VLAN 10 travaille toujours.
Les pièges. Oublier add sur le trunk et couper tous les autres VLAN. Oublier copy running-config startup-config. Sur pfSense, une nouvelle interface n'a aucune règle : tout y est bloqué par défaut, ce qui est sain mais surprend au premier test.
Modifier le DHCP et le DNS
La demande type. Une nouvelle étendue, une réservation pour une imprimante, un enregistrement DNS pour un nouveau service, un alias.
La méthode. Sur le serveur DHCP : étendue ou réservation, options (passerelle, DNS), réplication vers le partenaire de basculement. Sur le DNS : enregistrement A et, si besoin, PTR ou CNAME. Puis renouvellement du bail et résolution depuis un poste.
L'exemple 1 : l'étendue des invités. pfSense ne peut pas être à la fois serveur et relais DHCP. Comme il relaie déjà le DHCP des autres VLAN vers les serveurs Windows, l'étendue des invités va sur ces serveurs, en PowerShell sur SRV-AD1 :
Add-DhcpServerv4Scope -Name "Invites" -StartRange 10.10.40.50 -EndRange 10.10.40.200 `
-SubnetMask 255.255.255.0 -LeaseDuration 0.04:00:00 -State Active
# Passerelle et DNS : le pare-feu. -Force saute la vérification du serveur DNS,
# qui n'est pas un serveur Windows.
Set-DhcpServerv4OptionValue -ScopeId 10.10.40.0 -Router 10.10.40.254 -DnsServer 10.10.40.254 -Force
# L'étendue rejoint la relation de basculement existante entre SRV-AD1 et SRV-AD2
Get-DhcpServerv4Failover | Select-Object Name, PartnerServer, ScopeId
Add-DhcpServerv4FailoverScope -Name "SRV-AD1-SRV-AD2" -ScopeId 10.10.40.0
Puis sur pfSense, Services > DHCP Relay : ajoute l'interface INVITES aux interfaces relayées (les serveurs de destination 10.10.20.10 et 10.10.20.11 y sont déjà).
L'exemple 2 : la nouvelle imprimante de la comptabilité. Une réservation et un nom DNS :
Add-DhcpServerv4Reservation -ScopeId 10.10.10.0 -IPAddress 10.10.10.20 `
-ClientId "00-15-5D-0A-14-02" -Name "IMP-COMPTA" -Description "Imprimante comptabilité"
# Le basculement ne réplique pas tout seul les modifications : on réplique l'étendue
Invoke-DhcpServerv4FailoverReplication -ScopeId 10.10.10.0
Add-DnsServerResourceRecordA -ZoneName "ravelle.lan" -Name "imp-compta" -IPv4Address 10.10.10.20 -CreatePtr
Les tests. Sur un poste invité : ipconfig /release puis ipconfig /renew, et ipconfig /all montre une adresse entre .50 et .200, la passerelle et le DNS 10.10.40.254. Sur SRV-AD2 : Get-DhcpServerv4Reservation -ScopeId 10.10.10.0 montre la réservation répliquée. Depuis un poste du VLAN 10 : Resolve-DnsName imp-compta.ravelle.lan renvoie 10.10.10.20, et Resolve-DnsName 10.10.10.20 renvoie le nom (enregistrement PTR).
Les pièges. Oublier la réplication du basculement : le jour où SRV-AD1 tombe, l'imprimante change d'adresse. -CreatePtr échoue si la zone inverse 10.10.10.in-addr.arpa n'existe pas. Avec BIND sous Linux, oublier d'incrémenter le numéro de série de la zone : les serveurs secondaires ne se mettent pas à jour. Vérifie toujours avec named-checkzone avant rndc reload.
Ajouter une règle de pare-feu
La demande type. Autoriser un flux précis, en bloquer un autre, isoler un périmètre.
La méthode. Écris le flux en une ligne (source, destination, protocole, port, sens), choisis l'interface d'entrée, place la règle au bon rang, journalise les blocages, teste le flux autorisé et le flux interdit.
Trois principes de pfSense à connaître par cœur : une règle s'applique sur l'interface par laquelle le trafic entre dans le pare-feu ; les règles sont lues de haut en bas et la première qui correspond s'applique ; sur une interface sans règle de passage, tout est bloqué.
L'exemple 1 : isoler les invités. Règles de l'interface INVITES, dans cet ordre :
| Rang | Action | Protocole | Source | Destination | Port | Rôle |
|---|---|---|---|---|---|---|
| 1 | Autoriser | TCP/UDP | INVITES net | INVITES address | 53 | Résolution DNS par le pare-feu |
| 2 | Bloquer, journaliser | Tout | INVITES net | Alias RESEAUX_PRIVES (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) | Tout | Rien d'interne |
| 3 | Bloquer, journaliser | Tout | INVITES net | This Firewall (self) | Tout | Pas d'accès à l'administration du pare-feu, même par son adresse publique |
| 4 | Autoriser | TCP | INVITES net | Tout | Alias WEB (80, 443) | Internet en HTTP et HTTPS |
La règle 3 couvre un oubli classique : l'adresse WAN du pare-feu n'est pas une adresse privée, la règle 2 ne la bloque pas, et la règle 4 laisserait un invité ouvrir l'interface d'administration en HTTPS.
L'exemple 2 : l'intranet en HTTPS seulement depuis les postes. Sur l'interface du VLAN 10, la règle « autoriser TCP de VLAN10 net vers SRV-LB (10.10.20.30) port 443 » se place avant la règle qui bloque VLAN10 net vers VLAN20 net, et après celle qui autorise les flux vers les contrôleurs de domaine (DNS, Kerberos, LDAP, SMB). Placée après le blocage, elle ne s'appliquerait jamais.
Les tests. Le flux autorisé et le flux interdit, depuis un poste de chaque côté :
Test-NetConnection -ComputerName srv-lb.ravelle.lan -Port 443 # TcpTestSucceeded : True
Test-NetConnection -ComputerName srv-lb.ravelle.lan -Port 80 # TcpTestSucceeded : False
Test-NetConnection -ComputerName 10.10.20.40 -Port 22 # False : SRV-BAK reste fermé
Puis Status > System Logs > Firewall : le blocage apparaît, avec la règle qui l'a produit.
Les pièges. Une règle sur la mauvaise interface (la règle d'un flux du VLAN 10 vers les serveurs va sur l'interface du VLAN 10, pas sur celle des serveurs). Un ordre qui rend une règle inutile. Les états : une connexion déjà établie peut survivre à une nouvelle règle de blocage, réinitialise les états (Diagnostics > States) avant de tester.
Installer un partage avec des droits par groupe
La demande type. Un nouveau dossier partagé réservé à un service.
La méthode. La règle AGDLP : les comptes (A) dans un groupe global (G) qui représente le métier, ce groupe dans un groupe de domaine local (DL) qui porte la permission (P). Droits NTFS précis, partage, puis mappage du lecteur par GPO.
L'exemple. Le partage Direction sur SRV-FIC :
New-ADGroup -Name "GG_Direction" -GroupScope Global -Path "OU=Groupes,DC=ravelle,DC=lan"
New-ADGroup -Name "DL_Direction_M" -GroupScope DomainLocal -Path "OU=Groupes,DC=ravelle,DC=lan"
Add-ADGroupMember -Identity "GG_Direction" -Members "h.garnier", "k.morel", "s.benali"
Add-ADGroupMember -Identity "DL_Direction_M" -Members "GG_Direction"
# Sur SRV-FIC
New-Item -Path "D:\Partages\Direction" -ItemType Directory
# Héritage coupé ; SID plutôt que noms de groupes, qui changent avec la langue de Windows :
# *S-1-5-32-544 = Administrateurs, *S-1-5-18 = Système
icacls "D:\Partages\Direction" /inheritance:r `
/grant "*S-1-5-32-544:(OI)(CI)F" "*S-1-5-18:(OI)(CI)F" "RAVELLE\DL_Direction_M:(OI)(CI)M"
New-SmbShare -Name "Direction" -Path "D:\Partages\Direction" `
-ChangeAccess "RAVELLE\DL_Direction_M" -FullAccess "RAVELLE\Admins du domaine" `
-FolderEnumerationMode AccessBased
Le lecteur R: se mappe par une préférence de GPO (Configuration utilisateur > Préférences > Paramètres Windows > Mappages de lecteurs) avec un ciblage sur le groupe GG_Direction.
Les tests. Avec un compte directeur : ouvrir \\SRV-FIC\Direction, créer et supprimer un fichier. Avec un compte de la comptabilité : le partage n'apparaît pas dans \\SRV-FIC (énumération basée sur l'accès), et le chemin direct renvoie « accès refusé ». Sur le serveur : Get-SmbShareAccess Direction et icacls D:\Partages\Direction.
Les pièges. Tester avec une session ouverte avant l'ajout au groupe : le ticket Kerberos ne contient pas encore le nouveau groupe. Déconnecte et reconnecte l'utilisateur, ou lance klist purge. Le nom « Admins du domaine » est celui d'un Windows Server en français : sur un serveur en anglais, c'est « Domain Admins ».
Ajouter un serveur à la répartition de charge
La demande type. Ajouter un serveur, changer l'algorithme, ajouter un contrôle de santé, retirer un serveur pour maintenance sans coupure.
La méthode. Préparer le nouveau serveur à l'identique, l'ajouter au groupe du répartiteur, vérifier la configuration avant de recharger, prouver la répartition et la tolérance de panne.
L'exemple. Le groupe de l'intranet dans /etc/haproxy/haproxy.cfg sur SRV-LB, après ajout de WEB3 (10.10.20.33) :
frontend intranet
bind 10.10.20.30:443 ssl crt /etc/haproxy/certs/intranet.pem
default_backend web_intranet
backend web_intranet
balance roundrobin
option httpchk GET /sante
server web1 10.10.20.31:80 check
server web2 10.10.20.32:80 check
server web3 10.10.20.33:80 check
option httpchk GET /sante interroge régulièrement la page /sante de chaque serveur : un serveur qui ne répond pas 200 est retiré du groupe jusqu'à son retour.
haproxy -c -f /etc/haproxy/haproxy.cfg # « Configuration file is valid »
systemctl reload haproxy # rechargement sans couper les connexions
echo "show servers state" | socat stdio /run/haproxy/admin.sock
Les tests. Ajoute sur chaque serveur web une page de test qui affiche son nom, puis appelle-la six fois de suite : les réponses alternent entre web1, web2 et web3. Arrête Nginx sur WEB3 (systemctl stop nginx) : après quelques secondes, HAProxy le marque hors service et l'intranet répond toujours.
Les pièges. Recharger sans haproxy -c et casser le service pour tout le monde. Oublier d'autoriser le contrôle de santé dans le pare-feu local du nouveau serveur. Et la question qui viendra à la recette : HAProxy est lui-même un point unique de panne (la réponse est au chapitre 10).
Sauvegarder et restaurer
La demande type. Sauvegarder un nouveau dossier ou un nouveau serveur, changer la rétention, prouver une restauration.
La méthode. Quoi sauvegarder, où, à quelle fréquence, combien de temps (rétention), chiffré ou non ; une première sauvegarde manuelle ; la planification ; un test de restauration, sans lequel une sauvegarde n'est qu'une hypothèse. La règle 3-2-1 sert d'argument : 3 copies, sur 2 supports différents, dont 1 hors site.
L'exemple. Le dossier /srv/partages/paie de SRV-FIC, sauvegardé avec BorgBackup sur SRV-BAK :
Une seule fois, sur SRV-FIC, avec un accès SSH par clé vers le compte backup de SRV-BAK :
borg init --encryption=repokey backup@srv-bak:/srv/borg/paie
borg key export backup@srv-bak:/srv/borg/paie /root/cle-depot-paie.txt # copie à ranger hors du serveur
Le script /usr/local/sbin/sauvegarde-paie.sh :
#!/bin/bash
set -euo pipefail
export BORG_REPO='backup@srv-bak:/srv/borg/paie'
export BORG_PASSCOMMAND='cat /root/.borg-paie' # fichier lisible par root seul (chmod 600)
borg create --stats --compression zstd ::paie-{now:%Y-%m-%d_%H%M} /srv/partages/paie
borg prune --keep-daily 7 --keep-weekly 4 # la rétention demandée
borg compact # Borg 1.2 et plus : libère l'espace des archives supprimées
La planification par cron, dans /etc/cron.d/sauvegarde-paie :
# Chaque nuit à 1 h 30, journal dans syslog
30 1 * * * root /usr/local/sbin/sauvegarde-paie.sh 2>&1 | logger -t sauvegarde-paie
Les tests. borg list backup@srv-bak:/srv/borg/paie montre l'archive. Pour la restauration, supprime un fichier de test, puis :
cd /tmp && borg extract backup@srv-bak:/srv/borg/paie::paie-2026-04-12_0130 srv/partages/paie/bulletins/test.pdf
sha256sum /tmp/srv/partages/paie/bulletins/test.pdf # compare avec l'empreinte notée avant suppression
Borg enregistre les chemins sans la barre oblique initiale : extract restaure dans le dossier courant, d'où le cd /tmp qui évite d'écraser l'original.
Les pièges. Une sauvegarde jamais restaurée. Le mot de passe ou la clé du dépôt rangés seulement sur le serveur sauvegardé : s'il brûle, la sauvegarde est illisible. rsync --delete présenté comme une sauvegarde : c'est un miroir, une suppression accidentelle se propage à la copie la nuit suivante.
Superviser un nouvel élément
La demande type. Superviser un nouveau serveur ou service, ajouter un seuil, être alerté.
La méthode. Agent sur l'hôte, hôte et modèle dans le serveur de supervision, déclencheur avec un seuil adapté à la criticité, action de notification vers les bonnes personnes, puis un test qui provoque vraiment l'alerte.
L'exemple. Superviser WEB3 avec Zabbix 7.0. Sur WEB3 :
apt install zabbix-agent2 # depuis le dépôt officiel de Zabbix
Dans le fichier /etc/zabbix/zabbix_agent2.conf, règle ces trois paramètres :
Server=10.10.30.20
ServerActive=10.10.30.20
Hostname=WEB3
Puis redémarre l'agent et active-le au démarrage :
systemctl restart zabbix-agent2
systemctl enable zabbix-agent2
Dans l'interface de Zabbix :
- Data collection > Hosts > Create host : nom
WEB3(identique au paramètreHostnamede l'agent), groupeServeurs web, interface agent 10.10.20.33 port 10050, modèleLinux by Zabbix agent. - Le modèle fournit déjà un déclencheur sur l'espace disque. Pour un seuil à 85 % sur
/, ajoute sur l'hôte la macro{$VFS.FS.PUSED.MAX.WARN:"/"}avec la valeur 85. - Alerts > Actions > Trigger actions : une action existe déjà pour le groupe
Serveurs websi ta réalisation en a une ; sinon, crée-la (condition sur le groupe d'hôtes et la gravité, opération « envoyer un message » au groupe d'utilisateurs du service informatique par courriel).
Les tests. Depuis le serveur Zabbix, zabbix_get -s 10.10.20.33 -k agent.ping renvoie 1. L'icône de disponibilité ZBX de l'hôte passe au vert. Pour l'alerte, remplis le disque au-delà du seuil puis libère-le :
fallocate -l 5G /var/tmp/test-alerte.img # ajuste la taille pour dépasser 85 %
rm /var/tmp/test-alerte.img # après réception de l'alerte
Le problème apparaît dans Monitoring > Problems, le courriel arrive, puis le courriel de résolution.
Les pièges. Le port 10050 bloqué entre le VLAN 30 et le VLAN 20 : ajoute la règle sur l'interface d'administration du pare-feu. Avec ServerActive, l'agent ouvre aussi des connexions TCP 10051 du VLAN 20 vers ZABBIX : règle sur l'interface du VLAN 20, ou retire ServerActive si tu n'utilises que des vérifications passives. Un nom d'hôte différent entre l'agent et l'interface, qui casse les vérifications actives. Une alerte jamais testée. Des alertes trop nombreuses que plus personne ne lit : la grille parle d'alertes « adaptées à la criticité du service ».
Écrire un script d'administration
La demande type. Automatiser une tâche répétitive : créer des comptes, vérifier des services, sauvegarder des configurations, produire un rapport.
La méthode. Lire l'entrée, valider chaque élément, agir, gérer les erreurs sans tout arrêter, journaliser ; tester d'abord à blanc (-WhatIf en PowerShell), puis en vrai sur un jeu réduit.
L'exemple. Créer les comptes des saisonniers à partir de saisonniers.csv (colonnes Prenom;Nom;FinContrat) :
# creer-saisonniers.ps1
param([string]$Fichier = "C:\Scripts\saisonniers.csv")
$mdp = Read-Host "Mot de passe initial" -AsSecureString
$journal = "C:\Scripts\saisonniers-$(Get-Date -Format yyyyMMdd-HHmm).log"
Import-Csv -Path $Fichier -Delimiter ';' -Encoding UTF8 | ForEach-Object {
# p.nom, sans accent ni espace
$login = ($_.Prenom.Substring(0,1) + '.' + $_.Nom).ToLower() -replace '\s', ''
$login = $login.Normalize([Text.NormalizationForm]::FormD) -replace '\p{Mn}', ''
if (Get-ADUser -Filter "SamAccountName -eq '$login'") {
Add-Content $journal "AVERTISSEMENT $login existe déjà, ignoré"
return # passe à la ligne suivante du fichier
}
try {
New-ADUser -Name "$($_.Prenom) $($_.Nom)" -GivenName $_.Prenom -Surname $_.Nom `
-SamAccountName $login -UserPrincipalName "$login@ravelle.lan" `
-Path "OU=Saisonniers,OU=Utilisateurs,DC=ravelle,DC=lan" `
-AccountPassword $mdp -ChangePasswordAtLogon $true -Enabled $true `
-AccountExpirationDate ([datetime]::ParseExact($_.FinContrat, 'dd/MM/yyyy', $null))
Add-ADGroupMember -Identity "GG_Saisonniers" -Members $login
Add-Content $journal "OK $login créé"
} catch {
Add-Content $journal "ERREUR $login : $($_.Exception.Message)"
}
}
Get-Content $journal
Les tests. Lance le script sur un fichier de deux lignes, vérifie les comptes (Get-ADUser -Filter * -SearchBase "OU=Saisonniers,OU=Utilisateurs,DC=ravelle,DC=lan" -Properties AccountExpirationDate), puis relance-le : aucun doublon, deux avertissements au journal. Teste un nom avec accent (« Éloïse Février » donne e.fevrier).
Les pièges. Le mot de passe en clair dans le CSV ou dans le script. Un return confondu avec un arrêt du script : dans ForEach-Object, il passe seulement à l'élément suivant. Un fichier enregistré par un tableur dans un autre encodage, qui abîme les accents : vérifie l'encodage de l'export. Un script que tu ne sais pas modifier en direct : la commission te demandera d'ajouter une colonne ou un groupe.
Résoudre un incident et en rendre compte
La demande type. « Depuis ce matin, X ne fonctionne plus » : diagnostiquer, corriger, rédiger le rapport d'incident. La commission a parfois provoqué la panne avant ton passage.
La méthode. Qualifier (qui est touché, depuis quand, quel impact, quelle urgence), reproduire, diagnostiquer par couches, corriger, vérifier, empêcher que ça recommence, rendre compte.
L'exemple. « Les postes du VLAN 10 n'obtiennent plus d'adresse depuis ce matin. »
- Qualifier. Tous les postes du VLAN 10 ou un seul ? Ceux qui avaient déjà un bail fonctionnent encore jusqu'à son expiration ; les nouveaux reçoivent une adresse en 169.254.x.x (adressage automatique privé, signe qu'aucun serveur DHCP n'a répondu). Impact : élevé, toute arrivée ou tout redémarrage est bloqué.
- Couche 2.
show vlan brief: les ports des postes sont bien dans le VLAN 10 ;show interfaces trunk: le VLAN 10 passe vers le pare-feu. - Couche 3. Un poste en adresse fixe temporaire 10.10.10.99 joint 10.10.10.254 : la passerelle fonctionne.
- Le relais. Services > DHCP Relay sur pfSense : le service est-il actif, le VLAN 10 est-il dans les interfaces relayées, les serveurs de destination sont-ils les bons ?
- Le serveur.
Get-DhcpServerv4Scopesur SRV-AD1 et SRV-AD2 : étendue active ?Get-DhcpServerv4ScopeStatistics: étendue pleine ? - La preuve. Une capture Wireshark ou
tcpdump -ni igb1.10 port 67 or port 68sur le pare-feu (Diagnostics > Packet Capture) montre les requêtes DISCOVER sans OFFER en retour.
Suppose que l'étape 4 révèle que le VLAN 10 a été retiré des interfaces relayées. Tu le remets, tu renouvelles le bail d'un poste, tu vérifies trois postes.
Le rapport d'incident.
| Rubrique | Contenu |
|---|---|
| Détection | 8 h 40, appel de l'accueil : deux postes redémarrés sans réseau |
| Impact | Tous les postes du VLAN 10 qui demandent un bail, soit les postes redémarrés depuis 7 h 50 |
| Diagnostic | Ports et trunk corrects ; passerelle joignable ; capture : requêtes DHCP du VLAN 10 non relayées |
| Cause | L'interface du VLAN 10 ne figurait plus dans la liste des interfaces relayées par pfSense, après une modification de la veille |
| Correction | Interface réajoutée au relais à 9 h 05 ; trois postes testés, baux obtenus de SRV-AD1 |
| Prévention | Toute modification du pare-feu passe par un export de config.xml et une ligne dans le journal des changements de GLPI ; un élément Zabbix surveille le nombre de baux distribués |
Les pièges. Corriger sans comprendre (redémarrer le pare-feu « pour voir »). Oublier la prévention : c'est elle qui fait passer de l'incident au problème, et la grille parle de « mesures correctives proposées ou mises en œuvre ».