L’objectif de cet article est double : esquisser les grandes tendances NetDevOps observées en 2025 et montrer comment ces pratiques donnent corps à l’Intent‑Based Networking (IBN) défini par la RFC 9315. Aujourd’hui, pas de démonstration ni de recommandation sur une solution en particulier. L’idée est plutôt de donner au lecteur un fil rouge pour comprendre le « pourquoi » et le « comment » sans entrer dans les entrailles de la mise en place du NetDevOps. D’autres articles viendront mettre le focus sur une technologie ou une autre, avec des yeux d’experts qui travaillent dans le domaine pour de nombreux clients, sur des infrastructures qui vont du réseau universitaire aux plus gros datacenters d’Europe.
Les équipes réseau que nous accompagnons, avec l’équipe NXO NANO, ne considèrent plus l’automatisation comme un laboratoire. Les templates de configuration vivent désormais dans Git, enrichis par une source de vérité cohérente et validée ; chaque push déclenche une batterie de tests. Un sondage EMA paru début 2025 indique que les organisations prévoient d’augmenter d’environ 50 % leur taux d’automatisation réseau d’ici la fin de l’année – preuve que cette démarche est désormais perçue comme aussi stratégique que la haute disponibilité applicative1.
Publiée fin 2022, la RFC 9315 a posé le vocabulaire qui manquait. L’intent y est défini comme l’objectif déclaré du réseau, indépendamment de la façon d’y parvenir. Deux fonctions l’encadrent : fulfilment (la réalisation), et assurance (le contrôle continu). Tout tourne autour de deux boucles : l’externe, où le besoin métier fait évoluer l’intent, et l’interne, où la plateforme compare en permanence l’état réel à l’état voulu et agit en conséquence2.
C’est cette boucle interne qui monopolise aujourd’hui la majorité des efforts. Le cycle s’ouvre sur la validation de l’intent, archivé dans un référentiel unique ; vient ensuite l’orchestration idempotente (c’est‑à‑dire capable d’appliquer plusieurs fois le même changement sans effets de bord) ; enfin la supervision au sens large – monitoring, télémétrie et observabilité – alimente un moteur de corrélation. Celui‑ci compare les mesures à des seuils métiers (SLA, règles de sécurité, capacités…) et déclenche soit une correction automatique (mise à jour ou rollback sécurisé), soit un rapport à l’équipe, et possiblement les deux. Les tests NRFU – standardisés ou adaptés au contexte de l’entreprise – complètent la détection de dérive avant qu’un incident n’apparaisse. D’après les retours publiés par plusieurs opérateurs, on observe déjà une baisse marquée du MTTR et du nombre de dérives de configuration lorsque cette boucle tourne sans intervention humaine3.
À noter que même si l’on considère souvent la validation de l’intent comme l’ouverture du cycle, certaines organisations démarrent l’approche NetDevOps par le monitoring ou l’observabilité ou encore par des tests de conformité sur l’existant. Nous aurons l’occasion d’y revenir dans de futurs articles.
La littérature converge : pour réussir l’IBN, il vaut mieux bâtir une plateforme NetDevOps que multiplier les scripts. Le Market Guide 2025 de Gartner4 détaille pourquoi les entreprises doivent « industrialiser » leur automatisation via des plateformes ; l’étude EMA « From Scripts to Platforms »5 arrive aux mêmes conclusions : orchestration bout‑en‑bout, gestion de cycle de vie, visibilité native.
Voici une interprétation opérationnelle de la RFC 9315.
Le schéma ne prétend pas figer la norme. Il illustre simplement la façon dont nous la mettons en pratique sur le terrain.
Humain → Plateforme
Les équipes formalisent l’intent : design, codification, relecture croisée, contrôles de sécurité et de conformité, tests.
Lorsque tout est validé, l’étape du déploiement sert de point de bascule : le changement quitte l’espace collaboratif pour entrer dans l’exécution automatisée.
Plateforme ↔ Réseau
La plateforme s’appuie sur sa source de vérité, récupère le contenu versionné, déchiffre les secrets, orchestre le déploiement sur les équipements, puis collecte les métriques et le retour des équipements. Le module d’analyse et de corrélation compare l’état réel à l’intent et, en cas d’écart, relance automatiquement la correction ou alimente la boucle externe d’un rapport contextualisé.
Cette représentation met donc l’accent sur :
- La frontière claire entre la validation humaine et l’exécution autonome.
- La chaîne de confiance : référentiel unique, gestion des secrets, pipeline idempotent.
- La fermeture de boucle : la collecte des métriques et du retour des équipements nourrit un moteur d’analyse qui ramène le réseau dans l’état souhaité ou renvoie des informations à l’équipe.
Libre à chaque organisation d’adapter l’ordre des étapes, de remplacer un composant par un autre ou de séparer davantage les rôles. L’essentiel est de conserver les deux boucles et le lien qu’elles entretiennent.
Les obstacles restent avant tout humains. D’abord convaincre des équipes rompues au CLI d’adopter un modèle déclaratif ; ensuite établir la gouvernance – qui valide un intent ? qui peut valider ou suspendre la remédiation ? – ; enfin sécuriser la chaîne IaC, du commit signé au coffre‑fort de secrets. Les indicateurs qui font mouche sont concrets : réduction du nombre de dérives, diminution mesurable du MTTR.
Deux trajectoires prennent forme pour la suite. La première consiste à étendre la boucle interne : du datacenter aux campus, et jusqu’aux équipements spécialisés – load-balancers, firewalls, réseaux IoT… La seconde trajectoire s’appuie sur l’IA pour accélérer diagnostic, détection et remédiation. Gartner anticipe qu’en 2027 un quart des configurations initiales seront suggérées par l’IA, contre moins de 3 % aujourd’hui6. Cisco illustre déjà cette tendance dans Crosswork7 tandis que certains forment des partenariats stratégiques pour prendre le virage de l’intelligence artificielle8 et – clin d’œil maison – l’assistant ingénieur réseau de l’équipe NANO chez NXO, s’entraîne à diagnostiquer des pannes, parfois complexes, requêtant directement les équipements et les outils habituellement utilisés par les équipes réseaux et en s’appuyant sur la documentation interne de l’entreprise9. On ne parle pas de remplacer les équipes réseau par des robots sans âmes, mais d’assister, de guider, et de libérer du temps pour que les équipes puissent se concentrer davantage à des questions d’architecture et d’innovation.
En définitive, le NetDevOps n’est pas un catalogue d’outils : c’est la mécanique qui donne corps à l’Intent‑Based Networking. La feuille de route reste pragmatique : choisir un périmètre réduit, mesurer les gains, itérer – la boucle interne toujours en ligne de mire. Le vocabulaire existe, les retours de terrain abondent ; à chaque organisation de décider quelle portion de réseau franchira la première marche.
Glossaire
| Terme | Définition synthétique |
| Intent | Expression déclarative du résultat attendu par l’entreprise : « ce que » le réseau doit livrer, sans décrire « comment » l’obtenir. |
| Intent Fulfilment | Ensemble des opérations qui traduisent l’intent en configurations applicables aux équipements. |
| Intent Assurance | Boucle de contrôle continue qui vérifie que l’état réel reste conforme à l’intent et déclenche, le cas échéant, des actions correctives. |
| RFC 9315 | Document IETF (oct. 2022) définissant vocabulaire, rôles et boucles de contrôle de l’Intent-Based Networking. |
| Boucle externe (outer loop) | Cycle dont les acteurs sont humains : design, codification, revue, sécurité, conformité, tests ; débouche sur un déploiement. |
| Boucle interne (inner loop) | Cycle automatique piloté par la plateforme : déploiement, collecte des métriques, analyse et remédiation pour ramener le réseau vers l’intent. |
| Source de vérité (Source of Truth / SoT) | Référentiel unique et validé (inventaire, topologie, variables) servant de socle à l’automatisation. |
| Git | Système de gestion de versions ; héberge templates, playbooks et manifestes décrivant l’intent. |
| Coffre fort numérique (Secrets Vault) | Coffre-fort chiffré stockant clés, mots de passe, tokens, certificats ; évite de laisser des secrets en clair dans Git. |
| Moteur d’automatisation (Automation Engine) | Orchestrateur (Ansible, Salt, Framework NANO, etc.) exécutant les configurations de façon idempotente. |
| Idempotence | Propriété d’une opération qui peut être appliquée plusieurs fois sans modifier le résultat au-delà de la première exécution. |
| Monitoring / Télémétrie | Collecte continue de métriques, événements et logs, nécessaire à l’Intent Assurance. |
| NRFU (Network Ready for Use) | Batteries de tests (unitaires + intégration) validant qu’un réseau est prêt à entrer en production. |
| MTTR | Mean Time To Repair / to Restore : durées moyennes de résolution ou de retour à un état nominal. |
| IaC (Infrastructure as Code) | Principe consistant à décrire l’infrastructure via du code versionné, testé et déployé par pipeline. |
| Closed-loop Automation | Système capable de détecter une dérive et de déclencher automatiquement une action corrective, sans intervention humaine. |
| NetDevOps | Application des pratiques DevOps (CI/CD, IaC, tests, observabilité) au réseau ; socle opérationnel de l’Intent Based Networking. |