INGÉNIERIE RÉSEAU
Concevoir des architectures réseau segmentées et performantes. Diagnostiquer et résoudre les problèmes de connectivité de façon systématique.
Définition et contexte
L’ingénierie réseau, c’est concevoir et diagnostiquer les réseaux qui font fonctionner une organisation. Ce n’est pas juste « brancher des câbles » : c’est comprendre comment les données circulent, identifier les goulots, sécuriser les flux.
Il y a deux facettes : la conception (design d’architecture) et le troubleshooting (diagnostiquer et fixer). J’ai pratiqué les deux.
En entreprise, les bonnes infras réseau sont invisibles : elles marchent, point. Mais quand ça casse, tout s’arrête. C’est pour ça que les gens qui savent vraiment faire ça est très appréciés.
Aujourd’hui, avec le cloud, la virtualisation, les VPN, le réseau c’est devenu beaucoup plus complexe. Y’a pas juste du switch/routeur physique : y’a du VLAN, du overlay, du SDN. Faut comprendre les couches.
Éléments de preuve : Trois anecdotes
L’incident du device malveillant (Zenconnect)
Chez Zenconnect, un client signale une chute de débit internet inexplicable. Support classique aurait dit « c’est le FAI », fermeture du ticket.
Moi, j’ai attaqué le problème réseau proprement : Wireshark pour capturer le trafic, analyse des trames, logs Cisco pour comprendre ce qui circule sur quel VLAN.
En creusant, j’ai remarqué du trafic chiffré lourd sortant du site sur un VLAN spécifique. Les logs Cisco montraient des credentials légitimes utilisés de façon anormale.
Après investigation : un device physique avait été branché dans la salle admin – une boîte d’écoute passive du réseau qui s’était connectée au réseau et extrayait les données.
Résultat : Je n’ai pas juste résolu le débit qui baisse, j’ai identifié une faille de sécurité majeure. Le client a sécurisé les ports, changé les credentials, mis en place une politique d’accès physique. [Lire la réalisation complète : Zenconnect]
Le design des VLANs au projet ESIEA
Au projet réseau virtualisé, on devait segmenter l’infra complètement. 4 VLANs (direction, production, serveurs, guest) avec des règles de communication strictes.
Pas juste « créer les VLANs », mais concevoir la segmentation intelligemment. Qui parle à qui ? Quels protocoles ? Quel impact sur la production ?
On a utilisé pfSense comme firewall avec des ACLs (Access Control Lists) strictes : minimiser les flux autorisés, bloquer tout le reste par défaut (principe du moindre privilège).
Le challenge : tester que ça marchait vraiment. Créer des VMs test, vérifier que les clients de production pouvaient accéder aux serveurs mais pas les données du VLAN direction.
Résultat : Une architecture segmentée qui isolait vraiment, pas juste théoriquement. [Lire la réalisation complète : Réseau virtualisé]
Le debugging du routage (Projet ESIEA)
Même projet. Une communication critique ne passait pas entre deux VLANs. Un client du VLAN production ne pouvait pas parler aux serveurs.
Au lieu de juste crier « c’est cassé ! », j’ai diagnostiqué méthodiquement : vérifier les routes sur pfSense, checker les ACLs ligne par ligne, tracer le trafic avec des pings progressifs.
Le problème : une route par défaut mal configurée qui créait un blackhole (les paquets partaient mais ne revenaient pas).
Résultat : Une fois corrigée, tout a communiqué. Mais surtout, j’ai appris que connaître la théorie réseau, c’est bien. Savoir diagnostiquer quand ça casse, c’est mieux. [Lire la réalisation complète : Réseau virtualisé]
Mon autocritique : Où j’en suis vraiment
Je me considère à un niveau confirmé sur cette compétence. Je peux concevoir une segmentation réseau basique, je peux diagnostiquer des problèmes de routage/firewall, je maîtrise les concepts (VLAN, ACL, NAT, VPN).
Ma marge de progression : Je suis bon sur du réseau classique (switch/routeur, VLAN, firewall). Je suis moins bon sur du réseau cloud (SDN, overlay networks, Kubernetes networking). C’est un monde différent qui demande du temps.
Contextualisation : L’ingénierie réseau ne fonctionne pas pareil en toute situation. En startup ou lab ? Tu peux expérimenter. En prod critiques ? Un changement réseau c’est une opération qui se prépare des mois.
Vitesse d’acquisition : J’ai acquis ça en le pratiquant sur le terrain (Zenconnect). Beaucoup de théorie école, mais vraiment maîtriser c’est quand tu fais ça en prod avec des clients qui dépendent de toi.
Mon conseil : Avec ce que je sais maintenant, je dirais : avant de concevoir une architecture réseau, comprends le traffic réel du client. Pas juste « ils ont 100 users, donc un /24 suffira ». Comprends leurs patterns, leurs pics, leurs criticités.
Mon évolution : Où je veux aller
À moyen terme, je veux monter en abstraction. Passer de « je configure un switch » à « je conçois une architecture réseau pour 1000 users réparties sur 5 sites ». Je vise aussi de l’expertise sur du cloud networking (AWS, Azure).
Réalisations rattachées :
- Zenconnect (incident device, 50 clients)
- Réseau virtualisé (VLANs, routing)