Avant d’automatiser un réseau, il faut savoir ce qu’on a vraiment en production. C’est l’étape que tout le monde veut sauter, et c’est là que les projets NetDevOps déraillent : on écrit des playbooks avant d’avoir une source de vérité fiable, et on se retrouve à automatiser la propagation de ses propres erreurs.
Le NetDevOps applique les réflexes du développement logiciel à l’exploitation réseau. L’ordre dans lequel on pose les briques compte autant que les briques elles-mêmes : une Source of Truth, puis Git, puis des pipelines. Pris à l’envers, on versionne du bruit et on déploie des configs fausses plus vite qu’avant.
La Source of Truth, d’abord
Sans base centralisée, l’inventaire dérive en quelques semaines. Un VLAN renommé à la main pendant une astreinte, une interface ajoutée et jamais documentée, un préfixe posé sur un coin de tableur. Au bout d’un trimestre, plus personne ne sait quel document fait foi, et le premier script d’automatisation hérite de ce flou.
Une Source of Truth règle le problème à la racine : on modélise l’intention une seule fois (sites, devices, IPAM, rôles, VRF) dans une base qui fait autorité, et tout le reste génère sa config à partir de là. Plus de copier-coller entre un tableur, un fichier de variables et la mémoire de l’astreinte de garde : une seule donnée, consultable par l’humain comme par un pipeline.
Deux outils se partagent le terrain. NetBox a fondé la catégorie et reste la référence pour décrire un réseau proprement ; il décrit, il n’agit pas. Nautobot repart du même modèle et colle l’automatisation à la donnée, avec des Jobs Python qui tournent dans la SoT elle-même. Pour un premier inventaire propre, NetBox suffit. Quand on sait déjà qu’on ira loin dans l’automatisation, Nautobot épargne un détour. J’ai comparé ces deux approches, plus celle d’Infrahub, sur un même petit lab, jusqu’à migrer l’infra de l’une vers l’autre (article à venir).
Git, pour versionner l’intention
La SoT en place, Git devient le journal de ce qu’on veut, pas de ce qui est branché. Templates de config, variables, définitions de schéma : tout vit dans un dépôt, avec un historique et une revue avant merge. Git rend un changement réseau relisable comme du code : qui a touché à quoi, pourquoi, et ce que ça risque de casser. Un changement de VRF ou un nouveau préfixe se discute en pull request, à froid, avant d’atteindre le moindre équipement. Le jour où un déploiement tourne mal, l’historique dit quel commit a introduit la régression, et un revert le défait proprement.
Les pipelines, pour fermer la boucle
Reste à transformer l’intention en config, et la config en déploiement. À chaque changement poussé, le pipeline enchaîne quelques étapes : il valide la donnée (le schéma tient-il la route, les références existent-elles ?), rend les configs depuis la SoT, les teste, puis déploie. Les tests de pré-déploiement, les NRFU, attrapent l’erreur avant la prod, pas le lendemain au standup.
La chaîne complète prend son sens là : la SoT dit l’état voulu, Git l’arbitre, le pipeline le matérialise.
Le piège classique
La tentation, quand on découvre Ansible ou Python, c’est d’écrire tout de suite le script qui configure les équipements. Ça marche sur trois devices en démo, et ça s’effondre à l’échelle parce que la donnée n’a pas de maison. Le réflexe qui paie est l’inverse : modéliser d’abord, scripter ensuite. Le code devient alors un simple traducteur entre la SoT et l’équipement, au lieu d’être l’endroit où vit la vérité.
À retenir
Trois briques, un ordre qui ne se négocie pas. La Source of Truth d’abord, sinon tout le reste automatise du flou. Git pour traiter le réseau comme du code. Les pipelines pour relier l’intention à l’équipement. Avant la première ligne de script, on décide où vit la vérité du réseau.
Pour aller plus loin
- La RFC 9315, le cadre de référence de l’Intent-Based Networking : la formalisation de ce que « déclarer l’intention » veut dire.
- L’article NetBox, la Source of Truth d’origine : du modèle à l’API, pour voir une SoT en pratique sur un lab réel.