Automatiser le réseau : ce qui compte avant les outils

Quand une équipe décide d’automatiser son réseau, la première question est presque toujours « quel outil choisir ? ». Ansible ou Terraform, Nautobot ou NetBox, tel orchestrateur ou tel autre. La question est légitime, mais elle vient trop tôt, et cet article explique pourquoi. Il montre d’abord que les difficultés d’exploitation viennent de la manière d’opérer et non des outils, puis à quoi ressemble concrètement un réseau automatisé, pourquoi tant de projets déçoivent alors qu’ils disposent de bons outils, quelles questions il faut avoir réglées pour que le choix de l’outil devienne simple, et enfin pourquoi ce choix porte sur des fonctions plutôt que sur des outils.

Le problème vient de la manière d’opérer, pas des outils

Tant qu’un réseau compte quelques dizaines d’équipements, l’exploitation manuelle semble suffire. Elle suffit d’ailleurs souvent, grâce à deux ou trois personnes qui connaissent tout par cœur. Puis les infrastructures deviennent plus distribuées, plus dynamiques, plus imbriquées avec le cloud et la sécurité, et les mêmes symptômes apparaissent partout : des configurations qui divergent d’un site à l’autre sans que personne ne sache pourquoi, un changement simple qui prend des jours parce qu’il touche cinquante équipements, une documentation qui décrit le réseau tel qu’il était il y a deux ans, un savoir critique qui tient dans deux têtes.

Ces symptômes s’entretiennent les uns les autres. Un réseau hétérogène et mal documenté rend chaque changement risqué. Le risque nourrit la prudence, la prudence bloque l’investissement qui réduirait justement la fragilité, et la fragilité s’installe. On finit par gérer le réseau comme une vieille maison : on ne touche à rien, de peur que tout s’écroule.

Aucun de ces symptômes ne vient d’un outil manquant, et aucun ne disparaît parce qu’on en achète un. Ils viennent de la manière d’opérer : à la main, de mémoire, sans référence commune. C’est cette manière d’opérer que l’automatisation change. Avant de parler d’outils, il faut donc décrire ce qu’elle devient.

À quoi ressemble un réseau automatisé

Un réseau automatisé n’est pas un réseau sur lequel tournent des scripts. C’est un réseau opéré selon quatre principes, dont chacun répond à l’un des symptômes ci-dessus.

• L’état voulu est décrit à un seul endroit. Le réseau (sites, équipements, adressage, services) est décrit de manière structurée dans une Source of Intent, parfois appelée source de vérité. Cette description fait référence, et le réseau s’y conforme, pas l’inverse. C’est la réponse à la documentation périmée : la description n’est plus un document rangé à côté du réseau, c’est ce qui le pilote.
• Chaque changement est traité comme du code. Il est écrit, versionné, relu par un pair, testé, puis appliqué. On sait qui a changé quoi, quand et pourquoi, et on peut revenir en arrière. C’est la réponse au savoir qui tient dans deux têtes : il est dans le dépôt, pas dans les personnes. Le développement logiciel travaille ainsi depuis vingt ans, et cette façon de faire a fait ses preuves.
• Un changement donne le même résultat partout. Sur un équipement comme sur cinq cents, la même opération produit le même état, et le retour arrière est un geste prévu, pas une opération de sauvetage. C’est la réponse au changement simple qui prend des jours.
• L’écart entre le voulu et le réel est mesuré en continu. L’état réel du réseau est comparé à l’état voulu, les écarts remontent avant de devenir des incidents, et ils déclenchent une action plutôt qu’un rapport. C’est la réponse aux configurations qui divergent sans que personne ne le sache.

On pourrait d’ailleurs se demander à quoi sert cette détection d’écarts dans une approche pilotée par l’intention : puisque la configuration est régénérée depuis l’état voulu, le prochain déploiement n’écraserait-il pas de toute façon les déviations ? L’objection est excellente, et la réponse tient en deux points. D’abord, la confiance repose sur la transparence : une automatisation doit annoncer ce qu’elle s’apprête à faire et rendre compte de ce qu’elle a réellement modifié. Écraser en silence un changement fait à la main, sans même avoir signalé la déviation, contredirait ce principe. Ensuite, tout n’est pas toujours repoussé : pour gagner en rapidité, certaines plateformes ne régénèrent et ne déploient que les configurations touchées par un changement dans la Source of Intent. Une déviation sur un équipement que rien ne vient modifier peut alors survivre longtemps, si personne ne la mesure.

Aucun de ces principes ne nomme un outil. Un projet peut les respecter avec des outils modestes, et les trahir avec la plateforme la plus chère du marché. C’est précisément ce qui se passe dans la plupart des projets qui déçoivent : l’outil est en place, les principes ne le sont pas.

Pourquoi les projets déçoivent malgré de bons outils

Trois situations typiques, composées à partir de ce qu’on observe sur le terrain, illustrent ce décalage. Dans chacune, l’outil est le bon et l’un des principes manque.

Le réseau qu’on croyait connaître. Une entreprise multisite est convaincue que ses configurations sont homogènes, puisqu’elles ont toutes été déployées à partir du même modèle. Le premier audit automatisé, en lecture seule, montre que chaque site a dérivé à sa manière au fil des interventions d’urgence. Personne n’avait tort, personne n’avait de vue d’ensemble. L’outil d’audit n’a rien inventé : il a rendu visible un réseau que personne ne connaissait vraiment, et sur lequel on s’apprêtait pourtant à construire.

$ netops audit edge-lyon-01 --diff
--- intended
+++ running
- ntp server 10.0.10.1
+ ntp server 192.168.1.50
- snmp-server community netops-ro RO
+ snmp-server community public RO
  interface GigabitEthernet0/1
-   description uplink-core-01
+   description TEMP-FIX
✗ 3 écarts avec la Source of Intent

Le script que personne n’ose relancer. Un ingénieur a écrit, il y a trois ans, un script qui provisionne les sites. Il fonctionne, mais il n’a ni tests ni documentation, il suppose un état de départ précis, et son auteur est le seul à savoir dans quel ordre lancer ses étapes. Le jour où il change d’équipe, le script devient un risque au lieu d’un actif. L’outil était le bon ; l’automatisation n’avait simplement jamais été traitée comme du code.

L’outil acheté avant la donnée. Une source de vérité a été déployée, l’outil est en place, et il est vide. Ou pire, il a été rempli une fois puis plus jamais mis à jour, parce que personne n’était responsable de la donnée et qu’aucun processus ne l’alimentait. L’outil était le bon là aussi ; personne n’avait décidé qui posséderait l’état voulu ni comment il serait maintenu.

Dans les trois cas, ni l’outil ni la compétence des équipes ne sont en cause. Ce qui manque se situe en amont : connaître le réseau avant de l’outiller, traiter l’automatisation comme du code, décider qui possède la donnée. Ce sont des questions, pas des produits, et elles se règlent avant le choix de l’outil.

Les questions à régler avant de choisir un outil

Voici ces questions, dans l’ordre où elles se posent. Y répondre ne demande rien d’autre que du temps de compréhension et de conception, et c’est précisément ce temps que les projets pressés sautent pour aller directement à l’outil.

1. À quoi ressemble le réseau aujourd’hui, et à quoi doit-il ressembler ? Le point de départ est un inventaire à jour et les configurations réelles, pas la documentation. Mais il ne s’agit pas d’automatiser le réseau tel quel, car l’automatisation supporte mal les exceptions. Automatiser un cas d’usage a un coût de développement et de maintenance quasi fixe : le travail est le même pour un équipement ou pour des centaines. L’effort n’est donc rentable que s’il s’applique à un large périmètre. Or chaque exception, chaque pattern divergent, ajoute un cas particulier à gérer. À mesure qu’ils s’accumulent, la logique d’automatisation perd en lisibilité et en robustesse, la facture s’alourdit, et le retour sur investissement s’effondre. L’automatisation est donc l’occasion de simplifier le réseau, en ramenant les exceptions vers le standard avant de les encoder. Dans un réseau existant, on ne repart pas de zéro : on choisit un premier périmètre réduit et bien délimité, on commence par les segments les plus homogènes, et on réserve le « tout automatisé dès le départ » aux nouvelles infrastructures. Un petit périmètre limite l’impact d’une erreur, laisse à l’équipe le temps d’apprendre, et finance l’extension par ses premiers résultats.
2. Où vit l’état voulu, et qui en est responsable ? Le piège le plus courant consiste à laisser chaque outil porter sa propre description du réseau : des variables dans un playbook, un tableur pour l’adressage, un ticket pour les VLAN. Aucune de ces descriptions ne fait référence, et elles finissent par se contredire. L’état voulu doit vivre à un seul endroit, dans un modèle qui décrit le réseau et ses relations avec l’IPAM, le cloud, la sécurité et l’ITSM. Ce modèle a besoin d’un propriétaire et d’un processus qui l’alimente, car la qualité de la donnée est presque toujours sous-estimée au départ, et une source de vérité sans responsable se vide en six mois. C’est ce modèle qui décidera ensuite de l’outil : on cherche celui qui le sert, pas l’inverse.
3. Comment l’automatisation sera-t-elle construite, et qui pourra s’en servir ? Une automatisation se construit comme un logiciel, parce qu’elle en a les risques : à l’échelle, une erreur ne touche pas un équipement mais des centaines. Cela impose quelques pratiques, dont chacune évite un accident précis. Le code vit dans un dépôt versionné, pour qu’on sache ce qui a changé et qu’on puisse revenir en arrière. Chaque modification est relue par un pair, pour qu’une erreur de logique soit vue par deux personnes plutôt qu’une. Des tests automatisés vérifient la donnée et les workflows avant la production, parce que ce qui n’a pas été testé avant sera testé par la production. Un mode de simulation montre ce que l’exécution changerait sans rien appliquer, pour que l’opérateur valide en connaissance de cause. Une documentation permet à d’autres que les auteurs de s’en servir, sans quoi l’automatisation n’est qu’un nouveau point de fragilité. Reste à encadrer son usage par une gouvernance simple : quelles opérations sont éligibles à l’automatisation et lesquelles gardent une validation humaine, qui peut déclencher quoi sur quel périmètre, et quelle trace on garde de chaque exécution.
4. Qui la porte, et comment saura-t-on qu’elle a réussi ? Une automatisation réussie tient sur trois piliers, les personnes, les processus et la technologie, et la technologie est le dernier. Les personnes d’abord, parce que les ingénieurs réseau doivent comprendre ce que l’on construit, y être formés et surtout en être les auteurs plutôt que les spectateurs : une automatisation subie est une automatisation contournée. Les processus ensuite, parce que chaque automatisation doit répondre à un besoin métier identifié et être mesurable. Il faut décider avant de commencer ce que l’on mesurera, par exemple le délai de mise en production d’un changement, le taux de changements réussis, la dérive des configurations ou le temps de résolution des incidents, plutôt que de le découvrir après.
5. Qu’est-ce qu’on achète, et qu’est-ce qu’on construit ? C’est la seule question où l’outil apparaît enfin, et à ce stade elle est presque facile. La règle est d’acheter quand on peut et de construire quand on doit. Les briques génériques, orchestration, pipelines, stockage de la donnée, observabilité, existent sur étagère et n’ont pas à être réinventées. La couche propre à votre réseau, en revanche, modèle de données, templates, workflows, règles de validation, ne s’achète pas : c’est elle qu’il faut construire. Dans les deux cas, privilégier les standards, les APIs et les outils open source évite qu’une plateforme n’enferme et permet de remplacer chaque brique sans tout refaire. Les outils changent ; le modèle de données et les pratiques restent.

Choisir des fonctions, pas des outils

Une fois ces questions réglées, le réflexe revient : « donc, Nautobot ou NetBox ? ». Il mérite encore un temps d’arrêt, parce que la bonne question n’est toujours pas quel outil, mais quelles fonctions. Une chaîne d’automatisation n’est pas un outil. C’est un ensemble de fonctions qui se passent la donnée les unes aux autres, et chaque produit du marché en couvre une ou plusieurs, rarement toutes.

Le Network Automation Forum a formalisé cette lecture dans son NAF Framework, un modèle de référence indépendant des éditeurs qui décompose l’automatisation du réseau en six blocs fonctionnels :

• Intent : décrire et stocker l’état voulu du réseau. C’est la Source of Intent de cet article.
• Collector : aller chercher l’état réel sur les équipements.
• Observability : conserver cet état réel, le traiter et faire remonter ce qui s’écarte de l’intention.
• Orchestrator : coordonner l’exécution des tâches, sur un événement, un planning ou une demande.
• Executor : appliquer les changements sur l’infrastructure.
• Presentation : offrir aux utilisateurs une interface pour interagir avec l’ensemble.

La boucle dessinée plus haut dans cet article en est une version condensée. Le cadre ne dit pas quel produit placer derrière chaque bloc. Il dit ce que chaque bloc doit savoir faire, et précise qu’un bloc peut être servi par plusieurs composants, ou plusieurs blocs par un seul. C’est exactement ce qui change la conversation. Au lieu de comparer des outils entre eux, on dresse la liste des fonctions dont on a besoin, on note celles que l’on a déjà, souvent plus qu’on ne le croit, puis on cherche, fonction par fonction, ce qui remplit le mieux chacune d’elles. Un outil qui couvre trois blocs n’est pas forcément meilleur qu’un outil qui n’en couvre qu’un seul très bien, et l’inverse non plus : cela dépend des fonctions qui vous manquent.

Ce vocabulaire a un autre mérite : il fait apparaître les trous. Beaucoup de projets ont un Executor, des playbooks, et rien d’autre : ni Intent, ni Collector, ni Observability. Ils ont un outil ; il leur manque des fonctions. Les trois situations décrites plus haut se relisent de la même façon. Le réseau qu’on croyait connaître n’avait ni Collector ni Observability. Le script que personne n’ose relancer était un Executor sans Orchestrator pour enchaîner ses étapes et sans Presentation pour que d’autres que son auteur s’en servent. L’outil acheté avant la donnée était un bloc Intent sans processus pour l’alimenter.

Le bon outil est celui qui sert un modèle, une équipe et un processus déjà en place, et qui remplit une fonction nommée avant lui. Réglez ces questions d’abord ; le choix de l’outil devient alors presque évident.

Lectures recommandées : Designing Network Automation at Scale de Christian Adell, Modern Network Observability de David Flores, Christian Adell et Josh VanDeraa, et le NAF Framework du Network Automation Forum.