Project Oxygen & Ideo-LabIDEO LAB Dashboard 2026

đŸ›Ąïž IngĂ©nieur RĂ©seau & SĂ©curitĂ©

Un mĂ©tier “fondation” : concevoir, sĂ©curiser et opĂ©rer les rĂ©seaux (LAN/WAN/DC/Cloud). Objectif final : disponibilitĂ©, performance, sĂ©curitĂ©, traçabilitĂ©.

Domaines : switching/routing, firewalls, VPN/ZTNA, IDS/IPS, DDoS, DNS/IPAM, observabilité, NetDevOps, conformité.

1.1

Fondamentaux & rîle dans l’entreprise

Pourquoi ce métier est critique : stabilité, performance, Zero Trust, gouvernance, gestion du risque.

Missions KPI Risk
1.2

Architecture RĂ©seau

LAN/WAN/DC, segmentation, VLAN/VRF, redondance, QoS, patterns (DMZ, Leaf-Spine, Hub&Spoke).

VLAN/VRF OSPF/BGP HA
1.3

Switching & Routing (expert)

STP/LACP/ECMP, OSPF, BGP edge, NAT, MTU/MSS, diag L2→L7, asymĂ©tries stateful.

L2/L3 BGP Troubleshooting
2.1

Sécurité Réseau (socle)

Firewall L3/L7, IDS/IPS/NDR, micro-seg, WAF/LB, logs/SIEM, hardening & hygiene.

FW IDS/IPS Zero Trust
2.2

VPN / ZTNA / IAM

IPsec/SSL, SASE, bastion, PAM, MFA, certificats/PKI, posture device, RBAC/ABAC.

IPsec SASE PAM
2.3

Incident Response & Forensic

DDoS, compromission, beaconing, exfiltration, captures PCAP, containment, RCA & playbooks.

SIEM IR DDoS
2.4

RĂ©seau Cloud (AWS/Azure/GCP)

VPC/VNet, subnets/routes, SG/NSG, peering, TGW, PrivateLink, LB/WAF, Flow Logs.

VPC TGW PrivateLink
3.1

Ops, Monitoring & SRE réseau

SNMP/NetFlow, synthetic tests, SLO/SLA, capacity planning, runbooks, astreinte, MTTR.

NetFlow SLO NMS
3.2

NetDevOps & Automatisation

IaC, GitOps, Ansible/Terraform, NetBox, tests (Batfish), CI/CD réseau, rollback.

Ansible Terraform GitOps
3.3

Compliance & Gouvernance

ISO 27001 / NIS2 / PCI-DSS / RGPD : contrĂŽles, preuves, logs, change mgmt, audits.

ISO27001 NIS2 RGPD
4.0

Toolbox & Cheatsheet

Commandes diag, captures, filtres Wireshark, check DNS/TLS, firewall Linux, bonnes pratiques.

tcpdump Wireshark nmap
4.1

Parcours & Interviews

Junior→Senior→Architecte : compĂ©tences, labs, certifications, questions d’entretien, “senior mindset”.

Certifs Labs Interview
1.1 Fondamentaux — Pourquoi l’ingĂ©nieur rĂ©seau & sĂ©curitĂ© est indispensable
Ce que l’entreprise attend (concret)
  • DisponibilitĂ© : le service reste accessible malgrĂ© pannes liens/Ă©quipements (HA + tests).
  • Performance : latence, jitter, perte, congestion ; QoS pour voix/visio/temps rĂ©el.
  • SĂ©curitĂ© : rĂ©duire la surface exposĂ©e, empĂȘcher l’intrusion, limiter l’impact (segmentation).
  • TraçabilitĂ© : logs centralisĂ©s (FW/VPN/DNS/LB/WAF) → enquĂȘte, audit, RCA.
  • PrĂ©visibilitĂ© : change mgmt, rollback, doc vivante, standards.
Les facettes du métier
FacetteExemplesImpact
ArchitectureLAN/WAN/DC, DMZ, interco, cloud hybride.Stabilité long-terme.
OpsNMS, diag incident, maintenance, patching.MTTR bas.
SecurityFW/WAF/IDS, ZTNA, hardening, SIEM.Risque ↓
AutomationAnsible/Terraform, SoT, CI/CD, tests policies.Erreurs ↓
IncidentDDoS, containment, forensic, post-mortem.RĂ©silience ↑
Le bon modĂšle mental : “gĂ©rer des flux”

Un ingĂ©nieur rĂ©seau & sĂ©curitĂ© ne gĂšre pas “des boĂźtes” : il gĂšre des flux. Tout (VLAN, routes, ACL, VPN, WAF) sert Ă  rĂ©pondre Ă  : qui parle Ă  qui, comment, et avec quel niveau de confiance.

RĂšgle d’or : 1) Segmenter (blast radius) 2) ContrĂŽler (policy explicite) 3) Observer (logs/metrics) 4) Automatiser (rĂ©duire l’humain) 5) Tester (avant-prod, rollback)
Livrables “pro”
  • SchĂ©mas L2/L3, plan IP, VRF/VLAN plan, matrice de flux, rĂšgles FW documentĂ©es.
  • Runbooks (incident & changements), standards de nommage, procĂ©dures d’exploitation.
  • Tableau des dĂ©pendances : DNS/LB/WAF/Proxy/EDR/SIEM.
KPI réseau qui comptent vraiment
KPIDĂ©finitionPourquoi
AvailabilityUptime + redondance effective.Continuité business.
Latency/JitterRTT & variance.UX, temps réel.
Packet lossPertes / retransmissions.Signal de congestion.
MTTRTemps moyen de résolution.Outillage/process.
Change failure rate% changes qui cassent.Maturité opérationnelle.
Security postureSurface exposĂ©e, rĂšgles “laxistes”.Risque rĂ©el.
Incidents “signature” frĂ©quents
  • DNS (split-horizon, cache incohĂ©rent, latence rĂ©solution).
  • MTU/MSS (PMTU blackhole, surtout IPsec/VPN).
  • AsymĂ©trie (FW stateful qui drop les retours).
  • Boucle L2 (ARP storm, MAC flapping).
  • Certificats (expiry, chain cassĂ©e, SNI).
Heuristique “diag rapide”
Quand c’est “bizarre”, pense dans cet ordre : DNS → MTU/MSS → asymĂ©trie → stateful FW/NAT → LB → WAF → appli
Responsabilités selon contexte
  • PME : polyvalence (LAN/WiFi/VPN/FW + support).
  • ETI : segmentation, DC, SD-WAN, supervision, PRA.
  • Grand compte : multi-sites, SOC/SIEM, compliance, cloud hybride, fournisseurs.
Échelle de maturitĂ© (L1→L5)
  • L1 : exĂ©cute configs, dĂ©pannage “au feeling”.
  • L2 : diag structurĂ©, lit logs/metrics.
  • L3 : design + HA + sĂ©curitĂ©, comprend bout-en-bout.
  • L4 : standardise, automatise, gouverne, maĂźtrise le risque.
  • L5 : pilote stratĂ©gie (Zero Trust, cloud, budget, roadmap).
RĂ©flexe senior en incident
ÉtapeQuestionAction
1Impact ?Scope, priorisation.
2RĂ©seau ou appli ?Tests RTT/trace/HTTP.
3Change récent ?Rollback si doute.
4Preuves ?PCAP + logs FW/LB/WAF/DNS.
5Prévention ?RCA + actions correctives.
Zero Trust (version opérationnelle)

Zero Trust = identitĂ© + posture + segmentation + logs. On ne “fait pas confiance” au LAN : on vĂ©rifie en continu.

Zero Trust (pratique) : - Identity first (SSO/MFA) - Least privilege (RBAC/ABAC + JIT) - Segmentation (zones + micro-seg) - Continuous verification (logs/SIEM) - Automation (policy as code)
Mini schéma (placeholder)
[User+Device] -> [ZTNA/SASE] -> [Policy Engine] -> [App Segment] | | | | MFA posture check logs microseg
Anti-patterns (trĂšs courants)
  • Any/Any “temporaire” qui devient permanent.
  • Pas d’IPAM : conflits, diag impossible, dette technique.
  • Pas de logs : pas de preuve, pas de RCA, pas d’audit.
  • Prod-first : changements non testĂ©s, sans rollback.
  • VLAN = sĂ©curitĂ© : sans policy L3/FW, la segmentation est fragile.
Red flags sécurité
SignalRisqueFix
Admin exposé InternetCompromission.Bastion + MFA + allowlist.
RDP/SSH ouvertsBruteforce/scan.ZTNA/VPN + policy stricte.
Logs non centralisésInvestigation faible.SIEM + retention.
Certs non gérésPanne brutale.Rotation + alert expiry.
À retenir : Sans logs, tu ne sĂ©curises pas — tu espĂšres.
1.2 Architecture — LAN/WAN/DC : segmentation, redondance, QoS, patterns
Topologies réalistes
  • Campus : Access / Distribution / Core (ou collapsed core).
  • Datacenter : Leaf-Spine, ECMP, overlays (VXLAN/EVPN si besoin).
  • WAN : SD-WAN / MPLS / multi-ISP, BGP edge.
  • DMZ : chaĂźne front (WAF/LB/Reverse) + segmentation stricte.
Ce qui rend un design “pro”
PrincipeConcretPourquoi
BlocsZones + interfaces clairesOps & audit.
RedondanceActif-actif quand possiblePas de SPOF.
ObservabilitéFlow logs + syslogDiag rapide.
StandardsNommage, IP plan, SoTÉvolutif.
SchĂ©ma placeholder — DC Leaf/Spine
[Leaf-1]---\ [Leaf-2]----(Spine-1)====(Spine-2)----[Leaf-3] [Leaf-4]---/ ECMP

Avec ECMP, plusieurs chemins sont actifs en parallĂšle (plus performant que la redondance purement passive).

Livrables attendus
  • Plan IP, VLAN/VRF plan, route tables, points de coupure.
  • Carto dĂ©pendances : DNS/LB/WAF/Proxy/EDR.
  • Matrice de flux : base pour FW / audits / troubleshooting.
Segmentation : du VLAN Ă  la micro-seg
  • VLAN : segmentation L2 (broadcast domains) — utile mais pas suffisant en sĂ©curitĂ©.
  • VRF : isolation L3 (tables de routage sĂ©parĂ©es) — propre, “multi-tenant”.
  • FW inter-zones : la vraie politique (autoriser explicitement les flux).
  • Micro-seg : isolation par workload/identity (blast radius minimal).
Matrice de flux (exemple)
SourceDestinationPortJustif
AppDB5432/TCPAccĂšs applicatif strict.
Admin VPNMgmt22/443Via bastion/PAM.
UsersWeb443/TCPFront via WAF/LB.
Zones (pattern simple & robuste)
INTERNET | [WAF/LB] -> ZONE: DMZ (Front) | [FW ] -> ZONE: APP | [FW ] -> ZONE: DATA (DB/Storage) | [FW ] -> ZONE: MGMT (Bastion/SIEM/Admin)

But : isoler fonctions, tracer, limiter mouvement latéral.

Haute disponibilité : design + tests
  • Liens redondĂ©s (dual uplinks), LACP, chemins diversifiĂ©s.
  • Routage (ECMP, OSPF cost, BGP policies).
  • FW cluster (sync state) + bascule maĂźtrisĂ©e.
  • DNS/LB health checks, multi-AZ/site, GSLB si besoin.
Checklist “fire drill”
TestActionAttendu
UplinkCut lien #1Service up, dégradé acceptable.
FWFailoverSessions critiques ok.
BGPWithdraw routeRe-route rapide.
DNShealth-check KOSwitch vers endpoint sain.
HA = Design + Tests + ObservabilitĂ©. Sans tests rĂ©guliers, c’est juste un dessin.
PiĂšge courant

Avoir de la redondance matĂ©rielle mais un seul point logique (ex: une seule route, une seule policy, un seul DNS, un seul bastion) → SPOF “logiciel”.

QoS : quand c’est indispensable
  • VoIP/Visio (jitter/loss), liens WAN congestionnĂ©s, temps rĂ©el.
  • Shaping/policing, classes, DSCP, priorisation maĂźtrisĂ©e.
  • DC : microbursts, queues, bufferbloat (Ă  surveiller).
Signaux de saturation
  • RTT qui monte avec le dĂ©bit, pertes, retransmissions TCP.
  • “Lent” cĂŽtĂ© user alors que CPU/RAM serveurs OK → suspect rĂ©seau.
Aide-mémoire
Latence = dĂ©lai (ms) Jitter = variance latence Loss = pertes (%) Throughput = dĂ©bit utile Voix robotisĂ©e → jitter/loss (QoS + congestion)
1.3 Switching & Routing — L2/L3/BGP : maütriser le “flow”
L2 : stabilitĂ© (sinon tempĂȘte)
  • STP/RSTP/MST : Ă©viter boucles → sinon broadcast storm.
  • LACP : agrĂ©gation + rĂ©silience.
  • DHCP Snooping / DAI : anti rogue DHCP + ARP spoofing.
  • Port-security : limiter MAC, sĂ©curiser accĂšs.
MAC flapping

SymptĂŽme : pertes alĂ©atoires + CPU switch haut → boucle / trunk mismatch / mauvais patch.

Mini diag L2
1) root STP (qui est root ?) 2) trunks (allowed/native VLAN ? mismatch ?) 3) MAC table (flapping ?) 4) isoler (couper par Ă©tapes)
OSPF : convergence & hygiĂšne
  • Areas (scalabilitĂ©), cost (contrĂŽle chemins), ECMP.
  • Redistribution : attention boucles (tags/policies).
  • PiĂšges : MTU/auth mismatch → adjacences instables.
Tracer un flux (méthode)
Source → GW → Core → FW → LB/WAF → App Pour chaque hop : - route table (next-hop) - ACL/FW policy (allow ?) - NAT (translation ?) - MTU/MSS (fragmentation ?)
Asymétrie + stateful FW
Cas classique : - Aller passe par FW-A - Retour passe par FW-B → FW drop (state absent) Fix : - symĂ©triser routage - ou cluster/state sync correctement
BGP : edge internet / inter-sites
  • ContrĂŽle annonces (prefix-lists), policies (route-maps).
  • Influencer trafic : local-pref, MED, communities, prepends.
  • HygiĂšne moderne : filtrage strict, max-prefix, monitoring.
ObjetRĂŽle
Prefix-listFiltrer ce qui entre/sort.
Route-mapAppliquer policy (set attr.).
AS-PATHInfluencer trafic entrant.
Incident type : route leak
Route trop large annoncĂ©e → blackhole / dĂ©tours / saturation. Fix : - filters stricts - max-prefix - alerting BGP
Approche L1→L7 (table)
CoucheTestExemples
L1link/errorsCRC, duplex, optics.
L2VLAN/STPtrunks, loops.
L3routestrace, ECMP.
L4TCP/UDPNAT/state.
L7HTTP/TLScert, SNI.
Symptîmes → causes
  • Timeout TCP : FW drop, asymĂ©trie, ACL, MTU.
  • TLS fail : cert expiry, chain, ciphers, SNI.
  • Lent via VPN : MSS/MTU, DNS split, hairpin.
  • AlĂ©atoire : flapping, saturation, NAT table pleine.
MĂ©thode pro : Reproduire → Mesurer → Isoler → Capturer → Corriger + RCA
2.1 SĂ©curitĂ© RĂ©seau — Firewall/WAF, IDS/IPS, logs/SIEM, hardening
Firewall : ce qui fait la différence
  • Policies courtes & justifiĂ©es (ticket, owner, date, expiration si temporaire).
  • Stateful : attention au routage asymĂ©trique (sinon drop).
  • NAT : SNAT/DNAT, tables saturables, logs utiles.
  • L7 : App-ID, URL filtering, TLS termination/inspection (selon contexte).
  • Logging : “deny” essentiel, “allow” ciblĂ© → SIEM.
HygiĂšne de ruleset
RùgleÉtatAction
Any → AnyInterditRemplacer par matrice de flux.
TemporaireExpirableTTL + revue.
LegacyÀ auditerUsage rĂ©el via logs.
ChaĂźne front (pattern)
Internet -> (DDoS) -> WAF -> Load Balancer -> Reverse Proxy -> App \-> logs -> SIEM
“Moins mais mieux” : 20 rĂšgles propres > 200 rĂšgles incomprĂ©hensibles.
DĂ©tection : IDS/IPS, NDR, SIEM
SolutionRĂŽleLimites
IDSDĂ©tecte (signatures/anomalies).Bruit (faux positifs).
IPSBloque inline.Risque de blocage légitime.
NDRAnalyse comportement réseau.Chiffrement réduit visibilité.
SIEMCorrÚle logs multi-sources.Dépend qualité logs.
Signaux réseau utiles
  • DNS anormal (tunneling, NXDOMAIN massifs).
  • Beaconing rĂ©gulier (C2), destinations rares.
  • Scan interne (ports sĂ©quentiels), lateral movement.
  • Volumes sortants anormaux (exfiltration).
NetFlow/sFlow : le “radar”
NetFlow = qui parle à qui + volumes + temps. Utile pour : - cartographier dépendances - détecter exfiltration - comprendre saturation / DDoS

La qualitĂ© de l’IR dĂ©pend de la qualitĂ© des logs (centralisation + horodatage NTP).

Zero Trust : mise en Ɠuvre
  • Identity (SSO/MFA), device identity/certificats.
  • Least privilege (RBAC/ABAC, JIT, break-glass).
  • Segmentation (zones + micro-seg), pas de LAN “plat”.
  • Posture (EDR, patch, chiffrement, conformitĂ© device).
  • Continuous verification (logs/SIEM, anomalies).
Accùs admin “audit-friendly”
ÉtapeContrîleBut
1ZTNA/VPN + MFAAuth forte
2BastionPoint de contrĂŽle
3PAM / JITAccĂšs temporaire
4Session recordingAudit
ZTNA en 1 phrase

On n’ouvre pas le rĂ©seau : on ouvre l’application Ă  l’utilisateur, aprĂšs vĂ©rification identitĂ© + posture, avec logs.

Remote user -> ZTNA -> App (no direct network access) \-> policy engine + logs
Hardening (le “boring” qui sauve tout)
  • Management plane isolĂ© (VRF/VLAN mgmt), ACL strictes, pas d’admin public.
  • AAA (RADIUS/TACACS+), comptes nominatifs, MFA.
  • SNMPv3, SSH only, TLS moderne, NTP obligatoire.
  • Backups configs + versioning (diff, rollback).
  • Patch policy + priorisation CVE exposĂ©es.
Configuration drift
Drift = Ă©quipement hors “golden config”. Cause : hotfix, urgence, erreur humaine. Fix : IaC + audits auto + diff + approbation.

Automatiser + peer review = réduction massive des incidents de change.

2.2 VPN / ZTNA / IAM — IPsec, SSL, SASE, bastion, PKI, posture
AccĂšs distant : les grands patterns
TypeUsageNotes
SSL VPNRemote users.Simple, policy stricte.
IPsec S2SInterco sites/partenaires.Stable, attention MTU/routes.
ZTNAAccĂšs appli.Surface rĂ©seau ↓
BastionAdmin mgmt.Audit + contrĂŽle.
SASE (vue simple)
  • Security + rĂ©seau “as-a-service” : ZTNA, proxy, FW, CASB, policies globales.
  • IdĂ©al pour workforce distribuĂ©e.
Pattern bastion
User (MFA) -> VPN/ZTNA -> Bastion -> Target (SSH/RDP) \-> logs + session recording

TrÚs apprécié en compliance : preuves + contrÎle central.

PKI : cycle de vie
  • Émission (CA), distribution, rotation, rĂ©vocation.
  • Alertes expiry (30/15/7 jours), automatisation (ACME si possible).
  • Stockage clĂ©s : secrets manager / HSM selon criticitĂ©.
Mini check “panne TLS/VPN”
1) NTP (heure correcte ?) 2) expiry cert ? 3) chain (intermediate) ? 4) SNI/ciphers ? 5) rollback / renouveler
Posture device (moderne)
  • OS patchĂ©, disque chiffrĂ©, EDR actif, device compliant.
  • AccĂšs conditionnel : posture KO → accĂšs rĂ©duit / quarantine.
  • RĂ©duit fortement l’impact du vol de credentials.
RBAC vs ABAC

RBAC : par rÎle. ABAC : par attribut (pays, device, heure, conformité).

Le piùge : VPN full-tunnel “trop large”
Un user compromis sur VPN “full LAN” → scan interne + lateral movement. Fix : - ZTNA par application - ou segmentation stricte + FW inter-zones
PiÚges techniques fréquents
  • MTU/MSS : trĂšs frĂ©quent en IPsec (MSS clamping).
  • DNS split : rĂ©solutions incohĂ©rentes interne/externe.
  • Overlap RFC1918 : partenaires avec mĂȘmes IP (NAT ou redesign).
  • AsymĂ©trie : multiples liens + stateful FW.
Cas “ça marche en 4G mais pas au bureau”
HypothÚses : - proxy / inspection TLS entreprise - DNS différent - firewall sortant restrictif - MTU sur le chemin
2.3 Incident Response — DDoS, compromission, forensic, playbooks
DDoS : types & mitigations
TypeExemplesMitigation
VolumétriqueUDP floodsScrubbing/Anycast/ISP.
ProtocolSYN floodFW tuning, SYN cookies.
L7HTTP floodsWAF, rate-limit, caching.
Priorité

ProtĂ©ger le service d’abord (mitigation), analyser ensuite (preuves), durcir enfin (post-mortem).

Plan “ordre utile”
1) Activer protections amont (CDN/WAF/Anycast) 2) Rate-limit / challenges / blocklists temporaires 3) Ajuster caching (si possible) 4) ISP scrubbing si volumétrique 5) RCA + mesures permanentes
Compromission : patterns réseau
  • Lateral movement : scans internes, SMB/RDP/SSH multi-hĂŽtes.
  • Beaconing : petits paquets rĂ©guliers vers IP rares.
  • Exfiltration : volume sortant anormal, heures atypiques.
  • DNS tunneling : requĂȘtes longues, NXDOMAIN Ă©levĂ©s.
Containment (intelligent)
  • Isoler scope (quarantine VLAN/micro-seg) plutĂŽt que “couper tout”.
  • Rotation creds / revoke tokens / forcer MFA reset.
  • PrĂ©server preuves avant remĂ©diation.
Piùge : “tout couper”
Tout couper = business KO + preuves perdues. Mieux : - isoler le scope - capturer logs/pcap - maintenir critique si possible
Forensic réseau : savoir faire
  • Captures PCAP ciblĂ©es (5-tuple + timeframe).
  • CorrĂ©lation : FW + DNS + proxy + LB/WAF + EDR.
  • Timeline : qui, quand, comment, oĂč.
tcpdump -i eth0 -w incident.pcap 'host 10.0.0.10 and port 443' tcpdump -nn -tttt -r incident.pcap
Chiffrement : ce qui reste visible
  • Sans dĂ©chiffrement TLS : SNI, IPs, volumes, timings.
  • Les mĂ©tadonnĂ©es suffisent souvent (beaconing/exfiltration).
  • TLS inspection : puissant mais Ă  cadrer (privacy/compat).
Bon réflexe : - logs centralisés - NTP fiable - retention (7j/30j selon criticité)
Playbooks (trĂšs utiles)
IncidentAction immédiateAprÚs
DDoSWAF/rate-limit + amontDurcir + RCA
Creds volésReset + revokeConditional access
RansomwareIsoler segmentsRestore + hardening
Post-mortem (structure)
- Résumé impact - Timeline - Cause racine - Ce qui a marché / pas marché - Actions correctives (tech + process) - Owner + date + validation
2.4 RĂ©seau Cloud — VPC/VNet, SG/NSG, peering, TGW, PrivateLink, Flow Logs
Concepts universels
  • VPC/VNet : rĂ©seau isolĂ© + subnets + routes.
  • SG/NSG : firewall stateful au plus prĂšs des workloads.
  • NACL : stateless au niveau subnet (utile mais piĂ©geux).
  • LB : L4/L7 + health checks + TLS termination.
Erreur classique
“Ça ne marche pas” : 1) Route table 2) SG/NSG 3) NACL 4) DNS 5) LB health-check
Connectivité : patterns
  • Peering : simple mais non transitive.
  • Hub&Spoke (TGW/VWAN) : transitive, scalable.
  • PrivateLink : services exposĂ©s en privĂ©.
  • VPN/DirectConnect : hybride stable.
Schéma placeholder
[On-Prem]---VPN/DC---[Hub/TGW]---[Spoke-App] \---[Spoke-Data] \---[Spoke-Tools]
Security : “private by default”
  • Workloads en subnets privĂ©s.
  • Inbound via LB/WAF uniquement.
  • Egress contrĂŽlĂ© (NAT + proxy si besoin).
  • Flow Logs + WAF/LB logs → SIEM.
Design recommandé : - public : LB/WAF - private : app/workloads - isolated : data - mgmt : bastion/logging/CI
Diag “cloud” (checklist)
1) routes (RT) 2) SG/NSG 3) NACL 4) DNS / resolvers 5) Flow logs (drops) 6) LB health-checks
Astuce

En cloud, la panne est souvent un “mauvais contrîle” (policy) plutît qu’un cñble. Le senior sait lire : route + security policy + logs.

3.1 Ops & SRE — observabilitĂ©, SLO, runbooks, capacity planning
Ce qu’on monitor vraiment
  • DisponibilitĂ© (up/down) + erreurs (CRC, drops), saturation (bps/pps).
  • QualitĂ© (RTT/jitter/perte) via synthetic tests.
  • Flux (NetFlow) pour dĂ©pendances & anomalies.
  • Logs (FW/VPN/DNS/LB/WAF) centralisĂ©s vers SIEM.
Alert fatigue
Bonnes pratiques : - thresholds adaptés - corrélation - maintenance windows - runbooks + ownership

Une alerte doit dĂ©clencher une action, sinon c’est du bruit.

SLO/SLA (penser service)
  • SLA = promesse contractuelle ; SLO = objectif interne.
  • Error budget : si trop d’incidents → gel des changements non essentiels.
  • Mesurer la “qualitĂ© rĂ©seau” comme un produit.
Capacity planning
  • Trend trafic, pics saisonniers, marge de sĂ©curitĂ©.
  • Roadmap upgrades : 10G→40G→100G, backbone, peering.
Runbook (format simple)
Incident: "latence haute vers app X" - RTT/perte (synthetic) - saturation lien (bps/pps) - drops FW / NAT table - LB health-check - capture tcpdump si besoin
Change management : indispensable
  • Plan + peer review + fenĂȘtre + rollback.
  • Diff de config, versioning, approvals.
  • Post-checks (smoke tests) systĂ©matiques.
Rollback ready
Le vrai senior : - sait revenir en arriĂšre en 2 minutes - a la config prĂ©cĂ©dente prĂȘte
3.2 NetDevOps — IaC, SoT, CI/CD rĂ©seau, tests, rollback
Pourquoi automatiser ?
  • RĂ©duire erreurs humaines, standardiser, accĂ©lĂ©rer.
  • DĂ©tecter drift, gĂ©nĂ©rer diffs, rollback fiable.
  • Industrialiser les audits (policy as code).
IdĂ©es “portfolio” utiles
  • GĂ©nĂ©rer rĂšgles FW depuis matrice de flux (source-of-truth).
  • Tester reachability/policies en lab avant prod.
  • Scanner “any-any” + ports exposĂ©s + rĂšgles non utilisĂ©es.
PiĂšge
Automatiser sans tests/approval/rollback = automatiser des pannes plus rapides.
Tooling typique
BesoinOutilsNotes
Config mgmtAnsible / NornirTemplates + push contrÎlé.
IaC cloudTerraformRĂ©seau cloud reproductible.
SoTNetBoxIPAM + inventory.
TestsBatfish / pytestReachability & policy checks.
CI/CDGitHub/GitLab CILint + tests + approval.
Golden config (exemple)
- ssh only (no telnet) - snmpv3 only - syslog -> SIEM - ntp mandatory - AAA + comptes nominatifs - mgmt plane isolé
Pipeline CI/CD (simple)
git push -> lint -> simulate (lab) -> policy tests -> approval -> deploy -> post-checks -> tag release
Post-checks essentiels
  • Routes attendues prĂ©sentes.
  • Interfaces up, erreurs stables.
  • Smoke tests HTTP/TLS.
  • Flow/logs toujours envoyĂ©s.
3.3 Compliance — ISO27001, NIS2, PCI-DSS, RGPD : contrîles & preuves
Ce que les audits veulent voir
  • ContrĂŽle d’accĂšs : MFA, comptes nominatifs, revues rĂ©guliĂšres.
  • TraçabilitĂ© : logs centralisĂ©s, retention, intĂ©gritĂ©.
  • Segmentation : DMZ, zones, isolement data & mgmt.
  • Change mgmt : tickets, approvals, rollback, post-checks.
  • Patching : politique + preuves.
Exemples d’evidence
ContrĂŽlePreuveSource
MFALogs IdP + policiesSSO/IdP
SegmentationMatrice flux + rulesetFW
LoggingDashboards + retentionSIEM
PiĂšge compliance
Compliance ≠ sĂ©curitĂ© rĂ©elle, mais sans compliance la sĂ©curitĂ© devient non dĂ©montrable. Le mĂ©tier = sĂ©curitĂ© + preuve.

Transformer les contrÎles en automatisation (audit-as-code) est un gros levier de maturité.

4.0 Toolbox — commandes diag, captures, DNS/TLS, firewall Linux
Commandes diag (essentielles)
# Ping/trace ping -c 3 8.8.8.8 traceroute -n 1.1.1.1 mtr -rw 1.1.1.1 # DNS dig +short example.com dig @1.1.1.1 example.com # TCP/TLS nc -vz host 443 curl -vk https://example.com openssl s_client -connect example.com:443 -servername example.com # Capture tcpdump -i eth0 -w cap.pcap 'host 10.0.0.10 and port 443'
Recon (réseau autorisé)
nmap -sS -sV -p 1-1000 10.0.0.0/24
Firewall Linux
# iptables iptables -L -n -v iptables -S # nftables nft list ruleset # sockets ss -lntup
Wireshark (filtres)
ip.addr == 10.0.0.10 tcp.port == 443 dns http.response.code >= 400 tls.handshake.type == 1

Remplace/complĂšte par tes filtres “maison” (problĂšmes frĂ©quents).

4.1 Parcours & Interviews — progression, certifs, labs, Q/A
Progression naturelle
  • Junior : VLAN, routage simple, diag, tickets, WiFi.
  • ConfirmĂ© : OSPF/BGP basics, FW policies, VPN, monitoring.
  • Senior : design HA/seg, cloud net, lead incident, automation.
  • Architecte : standards, vendors, stratĂ©gie Zero Trust, roadmap.
Compétences qui font la différence
  • Expliquer clairement (schĂ©mas + justification).
  • Automation + change mgmt rigoureux.
  • Culture sĂ©curitĂ© (pas “juste rĂ©seau”).
  • Incidents : calme, mĂ©thode, preuves, RCA.
Certifs (selon orientation)
OrientationCertifsObjectif
RĂ©seauCCNA/CCNP (ou Ă©quivalents)Routing/switching solide.
SécuritéSecurity+ / vendor FWSocle sécu.
CloudCloud networking certsVPC/VNet patterns.
OpsSRE/monitoring (selon)Exploit & fiabilité.
Conseil
Les certifs aident, mais la crédibilité vient des labs + incidents + design.
Labs recommandés
  • GNS3 / EVE-NG : topologies, OSPF/BGP, HA.
  • containerlab : labs rapides + tests.
  • pfSense/OPNsense : FW/VPN/policies.
  • Cloud sandbox : VPC/TGW/Flow logs.
Mini défis (portfolio)
  • DMZ + WAF + LB + app + DB + logs centralisĂ©s.
  • Simuler un DDoS L7 & appliquer rate-limit/caching.
  • GĂ©nĂ©rer rĂšgles FW depuis une matrice de flux.
  • CI/CD rĂ©seau : lint + tests + deploy + post-checks.
Questions fréquentes
  • Explique un incident MTU/MSS et comment tu le prouves.
  • Comment Ă©viter l’asymĂ©trie avec un FW stateful ?
  • Diff SG vs NACL (cloud) ?
  • Comment tu conçois une segmentation pragmatique ?
  • Comment tu sĂ©curises l’admin (bastion/PAM/MFA/logs) ?
RĂ©ponse attendue (style senior)
- mesurer impact & scope - vérifier changements récents - reproduire & isoler (bypass/alt route) - capturer preuves (pcap + logs) - corriger + RCA + prévention