Les offres cherchent un ingénieur réseau qui code, ou un développeur Python qui connaît le réseau. Les offres citent Nautobot ou NetBox comme source de vérité, Python avec Netmiko, NAPALM ou Nornir, Ansible, Jinja2, NETCONF et Git, sur du Cisco, du Juniper, de l'Arista ou du Fortinet. L'entretien d'un ingénieur NetDevOps commence par le nombre d'équipements que son automatisation gérait et ce qu'elle avait le droit de modifier en production.
Beaucoup de CV décrivent des scripts Python qui se connectent en SSH et envoient des commandes. C'est un début. Le poste demande des données de référence fiables, des configurations générées et comparées à l'existant, des tests avant et après chaque changement, et un retour arrière prévu. L'écart s'entend vite quand la personne raconte un changement qui a mal tourné.
À partir d'une demande courante, comme l'ajout d'un VLAN sur 200 commutateurs, la personne décrit la chaîne de bout en bout : où la donnée est saisie, comment la configuration est produite, qui la relit, comment elle est poussée et vérifiée. Le PDF contient 30 questions sur six axes et un cas de 20 minutes.
Les outils d'automatisation réseau d'un ingénieur NetDevOps
NetBox et Nautobot
Deux sources de vérité réseau open source. On y décrit les sites, les équipements, les interfaces, les VLAN, les préfixes et les adresses IP. Nautobot est né d'un fork de NetBox et y ajoute des jobs et des applications en Python. L'automatisation génère les configurations à partir de ces données : reste à savoir qui les saisit et comment elles restent justes.
Python : Netmiko, NAPALM, Nornir
Netmiko envoie des commandes en SSH à des équipements de nombreux constructeurs. NAPALM donne une interface commune pour lire l'état d'un équipement et remplacer ou fusionner une configuration, avec comparaison avant envoi. Nornir est un cadre Python qui exécute ces tâches en parallèle sur un inventaire. Un bon candidat sait lequel il utilise pour quoi.
Ansible pour le réseau
Ansible pilote les équipements avec des collections par constructeur (cisco.ios, arista.eos, junipernetworks.junos, fortinet.fortios) et des modules de ressources qui décrivent l'état voulu d'une interface ou d'un VLAN. On le choisit souvent quand l'équipe réseau code peu en Python. Le mode check et le diff permettent de prévoir un changement avant de l'appliquer.
NETCONF, RESTCONF et gNMI
Les API des équipements, fondées sur des modèles de données YANG, natifs ou OpenConfig. NETCONF gère une configuration candidate, sa validation et le commit confirmé, qui revient en arrière seul si la confirmation n'arrive pas. gNMI sert aussi à la télémétrie en flux, plus fine que le SNMP. Leur pratique sépare un profil NetDevOps d'un auteur de scripts SSH.
Jinja2 et génération des configurations
Les configurations sortent de templates Jinja2 alimentés par la source de vérité. Bien découpés, quelques fichiers couvrent des centaines d'équipements. Mal conçus, ils deviennent illisibles et pleins d'exceptions. Le candidat doit comparer la configuration générée à celle en place avant tout envoi.
Tests : Batfish, pyATS, containerlab
Batfish analyse des fichiers de configuration sans toucher au réseau et répond à des questions comme : ce flux passe-t-il, ces sessions BGP montent-elles ? pyATS, l'outil de test de Cisco, compare l'état du réseau avant et après un changement. Containerlab monte des laboratoires d'équipements virtuels (Nokia SR Linux, Arista cEOS, Cisco XRd, Juniper cRPD) qu'une CI lance en une commande.
Git et CI/CD réseau
Chaque changement passe par une merge request : modification des données ou des templates, génération, tests, revue par un pair, puis déploiement par la CI (GitLab CI, GitHub Actions, Jenkins) et vérification. Le dépôt garde l'historique de qui a changé quoi, ce que les audits demandent.
Terraform pour le réseau
Terraform gère les réseaux des clouds (VPC, VNet, routes, règles de pare-feu) et une partie des équipements par des providers constructeur, comme ceux de Fortinet ou de Palo Alto Networks. Son état doit refléter la réalité : une règle ajoutée à la main sur le pare-feu crée une dérive qu'il faut détecter.
Télémétrie et état du réseau
Les flux gNMI ou les relevés SNMP alimentent Prometheus et Grafana, ou des outils comme Suzieq qui collectent l'état du réseau et permettent de l'interroger. Ils servent à vérifier un changement et à déclencher des actions automatiques sur événement.
L'ingénieur NetDevOps est le plus souvent rattaché à l'équipe réseau, avec un pied dans les pratiques DevOps et les outils de la plateforme. Selon le poste, il construit l'outillage (source de vérité, pipelines, bibliothèques Python) pour une équipe de réseau classique, ou il exploite lui-même le réseau avec ces outils. Les certifications Cisco CCNP ou Juniper JNCIP attestent le socle réseau. Cisco a aussi une filière dédiée à l'automatisation : les certifications DevNet s'appellent CCNA, CCNP et CCIE Automation depuis février 2026. L'expérience se vérifie par un changement réel décrit de bout en bout, avec ses tests et son retour arrière.
Ce qu'un ingénieur NetDevOps doit savoir faire
- Fondamentaux réseau : routage, BGP, VLAN, VXLAN
- Source de vérité et qualité des données
- Python et Ansible pour le réseau
- API des équipements : NETCONF, gNMI, YANG
- Tests et CI des changements réseau
- Déploiement par vagues et retour arrière
Les questions d'entretien d'un ingénieur NetDevOps, réponses attendues comprises
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é
Votre automatisation génère les configurations à partir de NetBox, mais un quart des sites y sont décrits de façon fausse. Que faites-vous avant de pousser quoi que ce soit ?
Une bonne réponseIl compare d'abord NetBox à la réalité : collecte de l'état des équipements (interfaces, VLAN, adresses) et rapport des écarts. Il décide site par site quelle source fait foi, corrige les données par un import contrôlé et ne génère de configuration que pour les sites validés. Il ajoute des contrôles de saisie (champs obligatoires, validations personnalisées) et une comparaison régulière avec le réseau.
Signal d'alertePousser les configurations générées et laisser le réseau s'aligner sur des données fausses, ou importer tel quel l'état du réseau dans NetBox, erreurs comprises.
Question 2 · confirmé
Vous devez lire l'état BGP de 400 routeurs de trois constructeurs et produire un rapport. Quels outils Python utilisez-vous, et comment ?
Une bonne réponseNornir pour l'inventaire, alimenté par NetBox ou Nautobot, et l'exécution en parallèle. NAPALM pour lire l'état BGP par une fonction commune aux constructeurs (get_bgp_neighbors), ou Netmiko avec un parseur (TextFSM, Genie) quand le getter n'existe pas. Il gère les erreurs équipement par équipement, limite le nombre de connexions simultanées et produit un résultat structuré.
Signal d'alerteUne boucle de connexions SSH l'une après l'autre, qui découpe du texte avec des expressions régulières écrites pour un seul constructeur.
Question 3 · senior
Avec NETCONF, comment appliquez-vous un changement sur un routeur distant sans risquer de perdre la main dessus ?
Une bonne réponseIl écrit dans la configuration candidate, la valide, puis lance un commit confirmé avec un délai : si la confirmation n'arrive pas parce que le changement a coupé l'accès, l'équipement revient seul à la configuration précédente. Il vérifie que l'équipement annonce les capacités candidate et confirmed-commit, verrouille la configuration pendant l'opération et connaît l'équivalent en ligne de commande (commit confirmed sur Junos et IOS XR).
Signal d'alerteUn envoi direct dans la configuration courante, en comptant sur l'accès console pour corriger si la connexion tombe.
Question 4 · confirmé
Décrivez le pipeline d'une merge request qui modifie un template de configuration réseau.
Une bonne réponseContrôle de syntaxe et linter, rendu des configurations pour les équipements concernés, différence avec la configuration en place jointe à la merge request, analyse Batfish (accessibilité, sessions BGP, règles de filtrage) ou déploiement dans un laboratoire containerlab avec tests de connectivité, puis revue par un pair. Le déploiement en production est une étape séparée, lancée dans une fenêtre approuvée.
Signal d'alerteUn pipeline qui pousse la configuration en production à chaque fusion, sans différence affichée ni test.
Question 5 · confirmé
Vous devez déployer un changement sur 300 commutateurs. Comment organisez-vous le déploiement ?
Une bonne réponsePar vagues : un site pilote, puis des lots de taille croissante, avec une vérification automatique après chaque lot et un arrêt si un critère n'est pas rempli. Un parallélisme limité, une fenêtre de changement adaptée, un retour arrière prêt (configuration précédente sauvegardée, commit confirmé ou rollback de l'équipement) et un rapport par équipement à la fin.
Signal d'alerteUn envoi simultané aux 300 équipements, ou un retour arrière qui consiste à se connecter un par un à la main.
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
Automatisation réseau : questions fréquentes
Quelle différence entre un ingénieur NetDevOps et un ingénieur réseau cloud ?
L'ingénieur réseau cloud conçoit et exploite le réseau dans AWS, Azure ou Google Cloud : routage entre VPC, interconnexion avec le datacenter, DNS privé, pare-feu cloud. L'ingénieur NetDevOps construit la façon dont le réseau est modifié : source de vérité, génération des configurations, tests et déploiement automatisé, sur des équipements physiques comme sur le cloud. Les deux postes se recoupent souvent, et beaucoup d'offres demandent un peu des deux.
Ingénieur réseau qui code ou développeur qui connaît le réseau : quel profil convient ?
Cela dépend de ce que l'automatisation touchera. Pour des changements sur un réseau de production, le socle réseau compte en premier : un développeur qui ne comprend pas une route-map BGP peut couper un site. Pour construire un outillage durable, comme des jobs Nautobot, des bibliothèques Python ou une CI, un profil développeur avec des bases réseau solides convient. Dans les deux cas, l'entretien insiste sur le côté le plus faible du profil.
Quelles certifications regarder sur un CV NetDevOps ?
Les certifications constructeur, comme Cisco CCNP ou Juniper JNCIP, prouvent le socle réseau. La filière automatisation de Cisco (CCNA, CCNP et CCIE Automation, ex-DevNet) et les certifications Ansible de Red Hat montrent un intérêt pour l'outillage. Aucune ne prouve qu'une automatisation a tourné en production. Un dépôt Git personnel ou une contribution à un projet comme NetBox, Nautobot ou Nornir en dit souvent davantage.
Quel test technique est donné à un ingénieur NetDevOps ?
Un exercice d'une heure fonctionne bien : un petit jeu de données (sites, équipements, VLAN), un template Jinja2 à compléter et un script Nornir ou un playbook Ansible qui génère les configurations et affiche les différences avec l'existant. La personne commente son travail à voix haute. La personne explique ensuite comment elle testerait et déploierait ce changement sur 300 équipements en production.
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.
