Sur Free-Work comme sur France Travail, un poste d'ingénieur réseau build demande presque toujours des HLD et des LLD, Cisco, Fortinet, Juniper ou Arista, BGP et OSPF, et souvent Ansible et Python. Les titres changent (ingénieur build réseaux et sécurité, ingénieur intégration réseau, ingénieur réseaux build et migration), le métier reste le même : poser une infrastructure qui n'existe pas encore, ou en remplacer une sans que les utilisateurs le remarquent.
Un CV d'exploitation peut ressembler à un CV de build. La différence s'entend vite en entretien. Le profil build parle de matrice de câblage, de version logicielle choisie, de scénarios de panne mesurés en maquette, d'heure limite pour revenir en arrière. Le profil run parle d'incidents. Les deux sont utiles, mais un projet confié à quelqu'un qui n'a jamais écrit de procédure de bascule finit souvent en coupure le lundi matin.
La dernière migration menée sert de fil : combien d'équipements, quelle fenêtre, ce qui a été testé avant, et si le retour arrière a servi. Un candidat expérimenté raconte aussi ce qu'il a remis à l'équipe d'exploitation. Le PDF déroule l'entretien en 30 questions, avec un cas de remplacement de cœur de réseau.
Les livrables et outils d'un ingénieur réseau build
HLD et LLD
Le HLD fixe l'architecture cible et ses raisons : topologie, redondance, protocoles, zones de sécurité. Le LLD la décline équipement par équipement, jusqu'au port, à l'adresse IP et à la version logicielle. Un bon LLD permet à un autre ingénieur d'installer sans poser de question.
Maquette et laboratoire virtuel
Avant de déployer, on valide la conception sur du matériel prêté ou dans un laboratoire virtuel comme Cisco Modeling Labs, EVE-NG, GNS3 ou containerlab. On y teste les pannes et on y répète la bascule. Le virtuel ne reproduit ni les performances ni les fonctions liées au matériel.
Procédure de bascule (MOP)
Le document suivi pendant la nuit de migration : étapes numérotées, configuration à appliquer, contrôle après chaque étape, critères de décision et retour arrière écrit. C'est le livrable qui distingue le plus vite un profil build d'un profil run.
Vérifications avant et après
Une capture de l'état du réseau avant le changement (voisins, routes, tables ARP et MAC, interfaces), comparée à l'état après. Des scripts Python ou le framework pyATS de Cisco automatisent la comparaison, complétée par des tests applicatifs menés avec les métiers.
Ansible et templates Jinja2
Pour produire des dizaines de configurations identiques sans erreur de saisie : un modèle commun, un fichier de variables par équipement, une génération automatique. Ansible pousse ensuite les configurations et sait afficher la différence avant de l'appliquer.
Provisioning zero-touch
Cisco PnP ou ZTP chez Juniper et Arista : l'équipement neuf, branché sur site, récupère seul sa configuration à partir de son numéro de série. Utile sur un déploiement multisite sans informaticien local, à condition que l'inventaire soit juste.
Cahier de recette
La liste des tests qui prouvent que l'infrastructure répond au HLD : fonctionnel, redondance, performance, sécurité, supervision. Chaque test a un résultat attendu, un résultat obtenu et une preuve. La signature du client ouvre le passage en exploitation.
Dossier d'exploitation et supervision
Ce que reçoit l'équipe de run : schémas et LLD tels que construits, procédures courantes, inventaire et contrats de support, équipements supervisés et alertes testées, sauvegardes de configuration en place.
Le build réseau se pratique surtout en mode projet, souvent par des ingénieurs d'ESN ou d'intégrateurs placés chez le client le temps d'une migration ou d'un déploiement, parfois dans une équipe projet interne d'une DSI qui garde la main sur son architecture. Le périmètre va d'un seul site à un programme qui compte plusieurs centaines d'équipements, avec du LAN, du WAN, du Wi-Fi, des pare-feu ou de l'équilibrage de charge selon les annonces. Les certifications constructeur (CCNP, JNCIP, NSE de Fortinet) attestent la maîtrise des produits. La rigueur de méthode se voit dans les documents produits et dans le récit d'une bascule réelle.
Ce qu'un ingénieur build réseau doit maîtriser
- Conception détaillée et plan d'adressage
- Maquettage et tests de panne
- Procédure de bascule et retour arrière
- Routage et commutation en cohabitation
- Industrialisation des configurations
- Recette et passage en exploitation
Questions de conception et de bascule pour un ingénieur réseau build
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Vous remplacez le cœur de réseau d'un site de 1 200 postes pendant une fenêtre de quatre heures, la nuit. Comment découpez-vous la bascule, et à quel moment décidez-vous de revenir en arrière ?
Une bonne réponseUne bascule en étapes courtes, chacune suivie d'un contrôle : voisins OSPF ou BGP montés, nombre de routes et d'entrées ARP comparé à la capture faite avant, ports attendus actifs, flux applicatifs testés avec une liste préparée avec les métiers. Une heure limite est fixée à l'avance, souvent au milieu de la fenêtre, au-delà de laquelle on revient en arrière si un critère n'est pas rempli. L'ancien cœur reste câblé et configuré jusqu'à la validation, ce qui rend le retour arrière rapide.
Signal d'alerte« On bascule tout d'un coup et on corrige au fil de l'eau. » Aucun critère d'arrêt écrit, ou un retour arrière qui suppose de reconfigurer l'ancien matériel déjà démonté.
Question 2 · junior à confirmé
Qu'est-ce qui doit figurer dans un LLD pour qu'un autre ingénieur installe les équipements sans vous appeler ?
Une bonne réponseLa matrice de câblage port à port avec les optiques, le nommage, l'adressage IP et les VLAN par interface, la version logicielle cible, les paramètres de routage (aires OSPF, numéros d'AS, filtres), les réglages de redondance, l'AAA, la supervision (SNMP, syslog, NTP) et l'emplacement en baie avec les alimentations. Le candidat distingue le HLD, qui porte les choix d'architecture et leurs raisons, du LLD, qui se lit équipement par équipement.
Signal d'alerteUn schéma Visio et la mention « configuration standard ». Ou un LLD qui ne dit rien du câblage, laissé au technicien sur place.
Question 3 · confirmé
Le client refuse de financer une maquette physique. Comment validez-vous quand même votre conception avant le déploiement ?
Une bonne réponseUn laboratoire virtuel avec les images des constructeurs (Cisco Modeling Labs, EVE-NG, GNS3 ou containerlab) pour le plan de contrôle : routage, redondance, scénarios de panne, procédure de bascule répétée. Le candidat cite ses limites : le matériel réel (ASIC, optiques, PoE, QoS matérielle) et les performances ne se reproduisent pas. Il compense par un prêt de matériel du constructeur ou du distributeur, ou par un site pilote déployé en premier et observé avant la suite.
Signal d'alerte« Pas besoin, la configuration est classique. » Ou un laboratoire virtuel présenté comme une preuve de performance.
Question 4 · senior
Pendant la migration, l'ancien et le nouveau cœur cohabitent trois semaines. Comment déplacez-vous les VLAN et la passerelle des serveurs de l'un à l'autre sans coupure longue ?
Une bonne réponseUne interconnexion entre les deux cœurs en agrégat 802.1Q, avec la racine spanning tree fixée pour qu'elle ne change pas de côté au moment où l'on branche. La passerelle reste sur l'ancien cœur, puis migre VLAN par VLAN en jouant sur les priorités HSRP ou VRRP. Le candidat sait que HSRP et VRRP ne se parlent pas : entre deux constructeurs, il prévoit une coupure courte par VLAN, un ARP gratuit et des caches ARP à surveiller sur les serveurs et les pare-feu.
Signal d'alerteBasculer tous les VLAN en même temps, ou relier les deux cœurs sans regarder qui devient racine spanning tree.
Question 5 · confirmé
Vous devez configurer 150 commutateurs d'accès identiques pour un déploiement sur plusieurs sites. Comment produisez-vous et poussez-vous les configurations ?
Une bonne réponseUn template Jinja2 commun et un fichier de variables par équipement (nom, adresse de gestion, VLAN, ports particuliers), une génération par Ansible ou par script, et la relecture d'un échantillon avant de lancer le reste. Pour la mise en service, soit un pré-staging en atelier, soit un provisioning zero-touch (Cisco PnP, ZTP chez Juniper ou Arista) qui associe le numéro de série à la bonne configuration. Un contrôle de conformité suit la pose.
Signal d'alerteUne configuration modèle copiée dans un éditeur de texte, où l'on change le nom et l'adresse à la main 150 fois.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Ingénieur réseau build : les questions fréquentes
Quelle différence entre un ingénieur réseau build et un ingénieur réseau run ?
Le build construit : conception détaillée, commande et installation, maquette, bascule, recette. Le run exploite ce qui existe : incidents, changements courants, supervision, mises à jour. Les deux partagent le même socle technique, routage, commutation, sécurité. Un ingénieur build doit savoir écrire pour les autres, car ses documents servent à l'installation puis à l'exploitation. Beaucoup de profils ont fait les deux ; la part de chacun sur les trois dernières missions le précise.
Quels livrables sont attendus pendant l'entretien ?
Un extrait anonymisé de LLD, une procédure de bascule ou un cahier de recette. La plupart des candidats ne peuvent pas montrer de documents clients, mais ils peuvent en décrire la structure. Le plan d'un MOP se dessine au tableau : les étapes, les contrôles, le point de non-retour. Un profil qui a réellement écrit ces documents le fait sans hésiter, et on voit tout de suite si le retour arrière y figure.
Faut-il un test technique pour un ingénieur réseau build ?
Un exercice sur papier marche bien pour ce poste. À partir d'un petit HLD, deux cœurs et trois sites par exemple, la personne rédige le LLD d'un équipement ou la procédure de bascule d'un site. Un QCM sur les protocoles dit peu de chose sur la méthode. Une demi-heure sur un document à produire montre l'ordre de pensée, le soin du détail et la place donnée au retour arrière.
Un ingénieur build doit-il savoir automatiser ?
Beaucoup d'annonces citent maintenant Ansible et Python, surtout pour les déploiements multisites. Le niveau attendu reste celui de l'industrialisation : templates, fichiers de variables, génération et envoi des configurations, vérifications avant et après. Si le poste demande une chaîne d'intégration continue complète ou une source de vérité à construire, le poste relève plutôt d'un ingénieur NetDevOps, qui a sa propre fiche.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
