L’automatisation réseau configure vos switches pendant que vous dormez

Ansible a passé le cap des 11 ans en février 2026, Nornir 3.5 est sorti en mars 2026 avec le support natif de l’inventaire dynamique, et Netmiko dépasse désormais les 4 200 étoiles GitHub avec plus de 150 plateformes réseau supportées. Pourtant, la majorité des équipes réseau continue de copier-coller des blocs de configuration dans des sessions SSH ouvertes une par une. Ce qui était acceptable pour trois switches devient une usine à erreurs silencieuses dès le dixième VLAN à propager. L’automatisation réseau n’est plus un luxe de cloud provider — c’est la différence entre une panne diagnostiquée en 30 secondes et une nuit blanche à reconstituer manuellement l’état de 47 équipements.

Le coût caché du « je le fais à la main, c’est plus rapide »

La configuration manuelle a un argument : la première fois, elle est effectivement plus rapide. Ouvrir une session SSH, taper conf t, coller un bloc de lignes, wr mem. Trois minutes par switch pour un changement de VLAN. Multipliez par 20 switches dans un campus, ajoutez la vérification show run sur chacun pour confirmer que la ligne est bien passée, et votre « petit changement » a consommé une heure et demie d’attention continue — sans aucune trace de ce qui a été fait, par qui, ni à quelle heure.

Le vrai coût n’est pas le temps passé. Il est dans ce qui n’est pas fait :

• Aucun rollback automatique. Si le changement casse le trunk vers le cœur de réseau, vous restaurez la configuration de sauvegarde à la main, équipement par équipement, en espérant que la dernière copie date d’hier et pas du trimestre dernier.
• Aucune détection de dérive. Six mois plus tard, le switch 17 a une ligne spanning-tree portfast qui manque parce qu’un collègue l’a oubliée lors d’une intervention d’urgence à 3 h du matin. Vous ne le saurez qu’au prochain incident.
• Aucune reproductibilité. Le stagiaire qui a configuré le switch 12 est parti en mai. Personne ne sait pourquoi le route-map de redistribution OSPF utilise le numéro d’access-list 142 plutôt que 101 comme les 19 autres.

Kirk Byers, le créateur de Netmiko, résume le problème en une phrase dans la documentation du projet : « Network automation to screen-scraping devices is primarily concerned with gathering output from show commands and with making configuration changes. Netmiko aims to abstract away low-level state control. » En clair : le SSH interactif, c’est du screen scraping humain. L’automatisation remplace l’œil et les doigts par un état déclaré.

Les trois piliers de l’automatisation réseau en 2026

Trois outils couvrent aujourd’hui l’intégralité du spectre, du script ponctuel à la gestion de parc complète en GitOps.

Ansible — l’idempotence sans agent

Ansible reste le point d’entrée le plus accessible. Pas d’agent à installer sur les équipements : tout passe par SSH. La syntaxe YAML est lisible même par un junior qui n’a jamais fait de Python, et le principe d’idempotence garantit qu’un playbook exécuté deux fois ne modifie rien la seconde fois si la configuration est déjà conforme.

- name: Déployer les VLANs sur tous les switches d’accès
  hosts: access_switches
  gather_facts: false
  tasks:
    - name: Créer les VLANs
      cisco.ios.ios_vlans:
        config:
          - name: bureaux
            vlan_id: 100
            state: active
          - name: iot
            vlan_id: 200
            state: active
          - name: invite
            vlan_id: 300
            state: active

Ce playbook de 11 lignes remplace 60 lignes de configuration tapées manuellement sur chaque switch. Exécutez-le via AWX ou Ansible Semaphore (l’alternative open source à Ansible Tower, maintenue activement en 2026), et vous obtenez un historique d’exécution, des logs horodatés et un diff automatique de ce qui a changé sur chaque équipement.

Forces. Agentless, courbe d’apprentissage douce, écosystème mature (cisco.ios, arista.eos, junipernetworks.junos, community.network). Les collections Ansible pour le réseau couvrent désormais plus de 60 plateformes.

Limites. Le modèle push séquentiel d’Ansible devient lent au-delà de 50 équipements — chaque switch est traité l’un après l’autre. Le paramètre serial parallélise par lots, mais le cœur de l’exécution reste monothreadé. Pour un parc de 200 switches, une tâche qui prend 3 minutes par équipement cumule 600 minutes sans parallélisation native.

Nornir — le framework Python natif, multi-threadé par défaut

Nornir prend le contre-pied total d’Ansible. Pas de DSL, pas de YAML : vous écrivez du Python. L’inventaire vit dans un fichier YAML ou dans NetBox, le multi-threading est natif via concurrent.futures, et le framework ne fait que l’orchestration — c’est vous qui décidez ce que chaque task exécute.

from nornir import InitNornir
from nornir_netmiko.tasks import netmiko_send_config
from nornir.core.task import Task, Result

def deploy_snmp(task: Task) -> Result:
    commands = [
        "snmp-server community ETT4YEB RO",
        "snmp-server location DC-Paris",
        "snmp-server contact [email protected]",
    ]
    return task.run(
        task=netmiko_send_config,
        config_commands=commands,
    )

nr = InitNornir(config_file="nornir.yaml")
result = nr.run(task=deploy_snmp)
print(result["switch-core-01"].result)   # inspecter un switch
print(result.failed)                     # True si au moins un échec

La force de Nornir, c’est son modèle de concurrence. Sur 200 switches, Nornir exécute la tâche en parallèle sur un pool de threads (typiquement 20 à 50 connexions simultanées). Le même déploiement SNMP qui prend 600 minutes en série tombe à 15-30 minutes. Et comme tout est du Python standard, vous pouvez intégrer un appel API NetBox pour récupérer dynamiquement l’inventaire, pousser les résultats dans Prometheus, ou chaîner des tâches conditionnelles (if "Junos" in task.host.platform).

Nornir 3.5 (mars 2026) apporte le support natif de l’inventaire dynamique : votre fichier hosts.yaml peut désormais référencer un plugin qui interroge NetBox, Nautobot ou une API REST au moment de l’exécution, sans prégénération manuelle.

Netmiko et NAPALM — la connectivité universelle

Sous le capot de Nornir, c’est souvent Netmiko qui travaille. La bibliothèque de Kirk Byers est devenue le standard de facto pour le SSH multi-constructeur en Python : 150+ plateformes, de Cisco IOS/NX-OS/XR à MikroTik RouterOS, en passant par Huawei, Palo Alto PAN-OS et Fortinet FortiOS.

from netmiko import ConnectHandler

device = {
    "device_type": "cisco_ios",
    "host": "10.0.1.1",
    "username": "admin",
    "password": "vault:secret",
}
with ConnectHandler(**device) as conn:
    output = conn.send_command("show ip ospf neighbor")
    print(output)  # structuré, parsable

NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) ajoute une couche d’abstraction au-dessus : une API unifiée pour récupérer les faits (get_facts), les interfaces (get_interfaces), les voisins BGP (get_bgp_neighbors), ou encore appliquer une configuration avec rollback automatique (load_merge_candidate + commit_config). Plutôt que de parser du texte brut ligne à ligne, vous récupérez un dictionnaire Python :

from napalm import get_network_driver

driver = get_network_driver("ios")
with driver("10.0.1.1", "admin", "secret") as device:
    bgp = device.get_bgp_neighbors()
    for peer, data in bgp["global"]["peers"].items():
        print(f"Peer {peer}: {data['up']}")  # True/False

GitOps réseau — la config vit dans Git, le réseau suit

Le chaînon manquant entre un playbook Ansible exécuté à la main et une véritable automatisation, c’est GitOps. Le principe est identique à celui qui gouverne Kubernetes depuis 2017 : la source de vérité est un dépôt Git contenant la configuration désirée, et un operator (ou un pipeline CI/CD) se charge de rapprocher l’état réel de l’état déclaré.

Concrètement, pour un réseau d’entreprise :

1. Toute modification passe par une pull request. Un ingénieur ouvre une PR modifiant le fichier vlans.yml ou le playbook deploy_qos.yml. La PR déclenche un dry-run Ansible ou une simulation Nornir (mode check) qui valide la syntaxe et estime l’impact.
2. Le merge déclenche le déploiement. Un pipeline GitHub Actions ou GitLab CI exécute le playbook contre les équipements de production, enregistre le diff dans les logs du job, et notifie le canal Slack #network-changes.
3. Un job périodique détecte la dérive. Toutes les heures (ou toutes les nuits), le même playbook tourne en mode check : si une ligne a été modifiée manuellement sur un switch (un interface shutdown de débogage oublié, par exemple), le pipeline alerte et propose de corriger automatiquement.

Ansible AWX (le upstream open source d’Ansible Automation Platform) et Semaphore intègrent nativement des webhooks Git et des schedules de job. Nornir se couple à n’importe quel orchestrateur CI/CD puisqu’il suffit d’exécuter un script Python.

Le bénéfice immédiat est l’auditabilité : chaque modification du réseau a un auteur, une date, un diff et une approbation. La conformité ISO 27001 ou SOC 2 qui exigeait jusqu’ici des exports manuels de show run trimestriels devient une requête Git.

Quelle stack pour quel parc ?

Verdict

Si vous gérez moins de 5 équipements, la CLI manuelle reste rationnelle — le surcoût de mise en place d’Ansible (inventaire, playbook, pipeline) n’est pas amorti. Mais dès que vous franchissez ce seuil, l’automatisation n’est plus une option : chaque heure passée à copier-coller des VLANs est une heure non passée à sécuriser le plan de contrôle ou à auditer le control plane policing.

Commencez par Ansible le lundi. En une journée, vous avez un playbook qui déploie vos VLANs sur tous vos switches et un job cron qui vérifie la conformité chaque nuit. La migration vers Nornir viendra naturellement quand le temps d’exécution du playbook dépassera votre fenêtre de maintenance — généralement autour de 50 équipements en série.

Si votre équipe maîtrise déjà Python, sautez directement sur Nornir + Netmiko + NetBox. Le gain en parallélisme et la flexibilité du scripting natif justifient l’investissement initial dès 20 équipements.

Ne tardez pas. Chaque trimestre passé sans Git pour vos configurations réseau est un trimestre où vous ne pouvez pas répondre à la question « qui a changé quoi, quand, et pourquoi » — la seule question qui compte pendant un incident de production.

Références

• Ansible Network Automation — Documentation officielle, Red Hat, consulté en mai 2026
• Nornir 3.5.0 Release Notes, Nornir Community, mars 2026
• Netmiko — Multi-vendor SSH Library, Kirk Byers, GitHub, 4 200+ étoiles en mai 2026
• NAPALM — Network Automation and Programmability Abstraction Layer, NAPALM Community, GitHub
• Ansible Semaphore — Open Source Ansible UI, Ansible Semaphore Community, 2026
• Ansible AWX — Upstream for Ansible Automation Platform, Red Hat / Ansible Community, 2026
• GitOps for Network Automation — Cisco DevNet, Cisco, 2026