Intro Story

Quand j’ai commencé ma carrière dans les réseaux, je pensais que tout tournait autour du CLI.
Je pouvais configurer un routeur Cisco les yeux fermés :
ligne après ligne, interface par interface.

Le CLI, c’était pour moi :

• la preuve de compétence,

• la maîtrise du réseau,

• la zone de confort de l’ingénieur.

Mais un jour, tout a changé.

Je travaillais sur une infrastructure où :

• les clients se multipliaient,

• les services évoluaient,

• les configurations devenaient énormes,

• la pression pour réduire les erreurs grandissait.

Et là, j’ai compris que tapper des configs à la main ne me permettrait jamais de tenir le rythme.

C’est à ce moment-là que j’ai découvert deux concepts qui ont littéralement transformé ma manière de travailler :

🟦 YANG – comment le réseau doit être décrit

🟨 YAML – comment on applique l’automatisation

Ces deux langages m’ont projeté dans une nouvelle dimension :
celle où un réseau n’est plus “une suite de commandes”, mais une structure de données vivante, modélisée, contrôlable, automatisable.

C’est ce passage du “réseau artisanal” au “réseau moderne” que je vais te transmettre dans cet article.

Un article pensé pour :

• les débutants qui veulent comprendre,

• les ingénieurs qui veulent monter en puissance,

• les entreprises qui veulent automatiser,

• les curieux qui veulent entrer dans l’univers NetDevOps.

Un article dans le style LS2EC :
clair, accessible, puissant, inspiré par mon vécu et par la réalité du terrain.

⭐2 — YANG expliqué simplement

Quand tu entends parler de YANG pour la première fois, ça peut sembler abstrait.
On te parle de :

• modules,

• containers,

• feuilles,

• arbres,

• schémas,

• modèles open,

• modèles natifs…

Et honnêtement, on a l’impression que c’est un langage inventé pour compliquer la vie des ingénieurs réseau.

En réalité, YANG simplifie tout.

🟦 Qu’est-ce que YANG, simplement ?

Voici la définition LS2EC, claire et sans jargon inutile :

YANG est un langage qui décrit la structure des données d’un équipement réseau (interfaces, BGP, tunnels, ACL, etc.) sous forme d’un arbre lisible par des humains et manipulable par des machines.

En d’autres termes :
YANG donne une forme claire à la configuration.

Contrairement au CLI qui est un langage… pour humains,
YANG est un langage pour humains et pour programmes.

🌳 La vision la plus simple : YANG = l’arbre de votre réseau

Imagine un arbre généalogique, mais pour un routeur.

Un équipement réseau, selon YANG, est composé comme ceci :

Avec YANG, tout est :

• logique,

• structuré,

• hiérarchisé,

• prévisible,

• standardisé.

Fini les configs illisibles de 400 lignes où tout est mélangé.

Avec YANG :
tu lis le réseau comme un fichier JSON ou XML.

🧱 Les briques fondamentales de YANG (simplifiées)

Tu m’as donné les définitions, mais je vais les reformuler dans un style clair :

🔹 container

Une boîte logique qui regroupe des données.
Exemple : interfaces

🔹 list

Une liste d’éléments similaires.
Exemple : plusieurs interfaces, plusieurs voisins BGP.

🔹 leaf

Une valeur simple.
Exemple : description, mtu, remote-as.

🔹 leaf-list

Une liste de valeurs simples.
Exemple : plusieurs DNS servers.

🔹 type

Le type de donnée : string, boolean, uint32, ip-address…

🔹 choice / case

Permet de dire : “tu dois choisir une seule branche parmi plusieurs”.

🔹 grouping / uses

Comme des “fonctions réutilisables” en programmation.

👉 C’est propre. C’est organisé. C’est modulaire.

🧠 Pourquoi les ingénieurs modernes aiment YANG ?

Parce que :

✔ 1. C’est lisible

Tu peux comprendre une structure sans CLI.

✔ 2. C’est standardisé

OpenConfig, IETF → même logique pour toutes les marques.

✔ 3. C’est validable

Si un paramètre n’est pas conforme au modèle → rejeté automatiquement.
Moins d’erreurs humaines.

✔ 4. C’est interopérable

API, NETCONF, RESTCONF, automation → tout repose sur YANG.

✔ 5. C’est parfait pour l’automatisation

Les outils (Ansible, Pyang, YDK, NSO, Terraform) parlent YANG.

🧩 Résumé LS2EC ultra simple

YANG décrit la structure des données.
YAML décrit ce qu’on veut faire avec ces données.

 

⭐3 — YANG Tree Modeling Expliqué

L’une des plus grandes forces de YANG, c’est sa structure en arbre.

Pourquoi un arbre ?
Parce qu’un équipement réseau, ce n’est pas une liste plate de commandes.
C’est une hiérarchie naturelle de données, comme :

• Interfaces

• Protocoles

• Services

• États

• Statuts

• Routes

• Voisins

YANG représente cette réalité exactement comme un développeur représenterait une application : en arbre.

1. Exemple simple : un routeur vu comme un arbre YANG

Voici comment un équipement peut être décrit :

Là où le CLI mélange des configurations…
YANG organise tout de manière logique et prédictible.

🧱 2. Les éléments de YANG dans cet arbre

Avec cet arbre, on retrouve :

✔ container

Regroupe des éléments.

Ex :
interfaces, routing, bgp, ipv4

✔ list

Plusieurs éléments similaires.

Ex :
interface[name=...], neighbors

✔ leaf

Une valeur simple.

Ex :
description, router-id, remote-as

✔ leaf-list

Liste de valeurs répétées.

Ex :
dns-servers

✔ choice / case

Permet de dire : “tu dois choisir une seule option” (ex : un type d’adresse ou une méthode de login).

✔ grouping / uses

Permet de réutiliser des blocs dans plusieurs modules, comme un ‘template’.

🧠 3. Pourquoi la modélisation en arbre change tout

Parce qu’un arbre :

✔ met fin aux configurations incohérentes

Les données suivent une structure définie → impossible d’ajouter un paramètre au mauvais endroit.

✔ permet à un programme de comprendre la configuration

Un script Python, un playbook Ansible, une API RESTCONF :
→ tous lisent l’arbre comme un dictionnaire JSON.

✔ transforme la config en données

Le réseau n’est plus un texte…
→ c’est une data structure.

✔ permet d’automatiser proprement

On ne “pousse” plus du texte.
On met à jour un champ dans un schéma.

🧩 4. Exemple simplifié : configuration BGP en YANG

Voici comment un voisin BGP est représenté en YANG (version simplifiée LS2EC) :

Tu vois ?
C’est clair, logique, structuré.

🔥 5. Ce que YANG apporte à la cybersécurité et au réseau moderne

• standardisation → moins d’erreurs

• validation automatique → moins de risques

• prévisibilité → meilleure compliance

• lisibilité → meilleure auditabilité

• intégration et automatisation → moins de coûts opérationnels

C’est l’équivalent réseau de passer :
d’un fichier Word désordonné → à un tableur Excel structuré.

⭐4 — Les modèles YANG : Open vs Native (IETF, OpenConfig, Cisco) et pourquoi ça change tout

Lorsque tu commences à travailler avec YANG, tu réalises rapidement qu’il existe deux grandes familles de modèles :

• les modèles OPEN (standards)

• les modèles NATIFS (propriétaires)

Ces deux logiques coexistent, et chacune a un rôle essentiel dans l’automatisation réseau.

Pour que ce soit limpide, on va les traiter à la manière LS2EC :
simple, clair, concret, avec des exemples réels.

🟦 1. Les modèles OPEN YANG

👉 Créés pour standardiser la configuration réseau entre fournisseurs.

Ces modèles sont développés par :

• l’IETF (Internet Engineering Task Force)

• OpenConfig (consortium d’opérateurs comme Google, Facebook, AT&T…)

• l’UIT ou d’autres organismes

• parfois les communautés open source

✔ Objectif

Avoir une configuration identique chez tous les constructeurs.

Un seul modèle → plusieurs plateformes compatibles.

🌍 1.1. Exemples de modèles OPEN

📌 IETF YANG Models

Ils définissent des standards pour :

• interfaces (ietf-interfaces)

• routing (ietf-routing)

• BGP (ietf-bgp)

• OSPF, ISIS

• QoS

• VRF

• telemetry

Exemple :
ietf-interfaces → le même modèle fonctionne sur Cisco, Juniper, Huawei, Nokia.

📌 OpenConfig Models

Créés par des géants du cloud pour imposer une standardisation réelle.

Ils vont plus loin que l’IETF dans :

• cohérence multivendor

• simplification

• abstraction des spécificités constructeurs

• normalisation de la télémétrie et du streaming

OpenConfig, c’est la volonté de dire :

« Peu importe le fournisseur : voici comment vous devez représenter vos données. »

 

🟩 2. Les modèles NATIFS

👉 Créés par les constructeurs pour leurs plateformes spécifiques.

Cisco, Juniper, Huawei, Nokia…
tous créent leurs propres modèles NATIFS.

Pourquoi ?
Parce que chaque plateforme a :

• des fonctionnalités uniques

• des mécanismes propres

• des configurations non standardisées

• des technologies propriétaires

Par exemple :

• Cisco IOS-XR, IOS-XE, NX-OS → leurs propres modèles natifs

• Juniper Junos → modèles natifs Juniper

• Huawei VRP → modèles natifs Huawei

🧠 2.1. Pourquoi garder des modèles natifs ?

Parce que certaines commandes ou fonctionnalités :

• n’existent pas dans les standards

• ou différencient réellement une plateforme

Ex :
Le segment routing sur XR n’est pas décrit de la même manière que chez Juniper.

🟦 3. Les deux types de modèles travaillent ENSEMBLE

Et c’est là que tout devient intéressant.

Un même équipement peut offrir :

✔ un modèle OPEN

pour des tâches génériques (interfaces, routing, BGP).

✔ un modèle NATIF

pour des fonctionnalités avancées ou propres à la plateforme.

Ce n’est jamais l’un ou l’autre.
C’est un combo.

🧩 4. Exemple concret LS2EC : configuration BGP sur Cisco IOS XR

🔹 Modèle OPEN

openconfig-bgp (Google, Facebook, AT&T)

🔹 Modèle IETF

ietf-bgp

🔹 Modèle NATIF Cisco

Cisco-IOS-XR-ipv4-bgp-cfg

→ trois façons de représenter BGP, sur le même équipement !

Pourquoi ?
Parce que :

• l’open config = standardisation multivendor

• l’IETF = consensus industriel

• le natif = fonctionnalités XR avancées

🚀 5. L’ingénieur moderne doit comprendre les 3

Voici pourquoi :

✔ IETF

→ pour suivre les standards du marché
→ pour automatiser largement sans dépendre d’un fournisseur

✔ OpenConfig

→ pour multivendor
→ pour cloud, opérateurs, infrastructures hybrides

✔ Native

→ pour exploiter toutes les capacités réelles d’un équipement

🎯 Résumé LS2EC

Modèles OPEN = standardiser
Modèles NATIFS = optimiser

Les deux sont nécessaires.
Un ingénieur moderne doit jongler avec les deux.

 

⭐5 — Comment YANG interagit avec NETCONF & RESTCONF

Si YANG décrit la structure des données réseau…

Il faut bien un moyen de transporter ces données,
de les lire,
de les modifier,
de les valider,
et de les appliquer sur un équipement.

C’est exactement le rôle de deux protocoles modernes :

• NETCONF

• RESTCONF

Ce sont eux qui permettent le passage :

du modèle → à la configuration réelle
du schéma → à l’état opérationnel
de la théorie → à l’automatisation

 

🟦 1. NETCONF — Le protocole historique des réseaux automatisés

NETCONF (Network Configuration Protocol)
est le protocole standard IETF pour gérer des configurations via YANG.

Il fonctionne principalement sur :

• SSH

• RPC (Remote Procedure Calls)

• XML (principal format d’encodage)

C’est un protocole robuste, structuré, conçu pour éviter les erreurs.

🧠 1.1. Pourquoi NETCONF est considéré comme “sécurisé et fiable” ?

Parce qu’il offre :

✔ Validation automatique

Si la configuration ne correspond pas au modèle YANG → rejetée.

✔ Transactions atomiques

Si une partie de la config échoue → TOUTE la config est annulée.
Pas de demi-configurations dangereuses.

✔ Locking système

On peut verrouiller la datastore pendant la modification → éviter les conflits.

✔ Gestion claire des datastores

• running

• candidate

• startup

C’est un niveau de fiabilité que le CLI n’offrira jamais.

🧠 1.2. Exemple concret LS2EC : opération NETCONF

Voici la logique en pseudo-code :

En clair :

“Applique ce bloc de configuration YANG au routeur, et valide-le de manière atomique.”

 

🟦 2. RESTCONF — Le petit frère moderne basé sur HTTP/JSON

RESTCONF est plus récent.
Plus léger.
Plus orienté API.
Plus adapté au monde Cloud / DevOps.

Au lieu de XML sur SSH…
RESTCONF utilise :

• HTTP(S)

• JSON

• des URL RESTful

• une logique similaire aux APIs web modernes

•  

🧠 2.1. Exemple RESTCONF (simple et puissant)

Voici une requête RESTCONF typique :

ou pour pousser une config :

C’est simple. Moderne. Accessible même aux développeurs.

🟦 3. NETCONF vs RESTCONF — Comment choisir ?

Les deux reposent entièrement sur… YANG.

YANG est le cerveau.
NETCONF/RESTCONF sont les bras.

🌐 4. Cisco, Juniper, Nokia, Huawei : tous ont adopté YANG + NETCONF/RESTCONF

Cisco

IOS XR, IOS XE, NX-OS → support complet YANG / NETCONF / RESTCONF.

Juniper

Modèles YANG + Junos API.

Nokia

SR OS → YANG + NETCONF.

Huawei

VRP → YANG + NETCONF.

C’est devenu un standard mondial.

🧩 5. Pourquoi comprendre ce trio change la carrière d’un ingénieur réseau ?

Parce que :

• YANG → structure les données

• NETCONF → applique les configurations de manière fiable

• RESTCONF → permet l’automatisation moderne (DevOps style)

• JSON → devient le langage universel du réseau

• APIs → remplacent progressivement les CLIs

Un ingénieur qui maîtrise YANG + NETCONF + RESTCONF :
→ peut automatiser n’importe quel réseau.

C’est une compétence rare.
Précieuse.
Mieux rémunérée.
Et universelle.

⭐6 — Exemples concrets et faciles à comprendre (Cisco XR, Cisco XE, Juniper)

Nous allons voir comment YANG est utilisé réellement dans des plateformes modernes.
Tu vas comprendre, en quelques exemples, pourquoi ce modèle est devenu incontournable.

🟦 1. Exemple Cisco IOS XR — Configurer une interface via YANG

Le modèle YANG standard IETF pour les interfaces est :

ietf-interfaces

Voici comment on configure une interface via NETCONF en utilisant ce modèle :

📌 Extrait XML NETCONF (simplifié LS2EC)

👉 NETCONF envoie cette configuration au routeur.
👉 Le routeur valide les données selon le modèle YANG.
👉 Si tout est conforme → configuration appliquée.
👉 Sinon → rejet automatique.

🟦 2. Exemple Cisco IOS XE — RESTCONF + JSON

IOS XE (souvent utilisé dans l’enterprise networking) est plus “API-friendly”.

Voici la même interface configurée en RESTCONF + JSON :

→ C’est lisible.
→ C’est propre.
→ C’est automatisable via Python, Ansible, Terraform.

🟦 3. Exemple Cisco IOS XR — Configurer BGP via OpenConfig

OpenConfig est populaire car il standardise la configuration.

Un voisin BGP OpenConfig ressemble à ceci :

On a ici :

• lisibilité totale,

• structure cohérente,

• abstraction du fournisseur.

🟦 4. Exemple Juniper Junos — YANG + NETCONF

Juniper est l’un des pionniers du NETCONF.
Voici l’ajout d’une description d’interface via YANG + NETCONF :

→ Structure comparable à Cisco.
→ Même logique.
→ Même standards IETF.

La magie de YANG :
on écrit la même structure sur plusieurs fournisseurs.

🧠 Pourquoi ces exemples sont importants ?

Parce qu’ils montrent trois vérités :

✔ 1. Tous les constructeurs convergent vers YANG

C’est devenu une langue universelle.

✔ 2. L’automatisation repose toujours sur YANG

Peu importe l’outil : NETCONF, RESTCONF, Ansible, YDK, Terraform, NSO…

✔ 3. Les configs modernes ressemblent plus à du JSON qu’à du CLI

Et c’est ça la clé pour amener les ingénieurs réseau vers le DevOps.

⭐7 — YAML expliqué avec pédagogie

Pour comprendre YAML, il faut commencer par une vérité simple :

YAML n’est pas un langage de programmation.
YAML est un langage de description.

Il décrit des données,
des états,
des intentions,
mais ne “fait” rien tout seul.

Et c’est justement ce qui en fait un outil puissant pour l’automatisation :

• lisible

• simple

• structuré

• non intimidant

• proche de la manière dont les humains pensent

Les ingénieurs réseau qui ont peur de Python…
généralement aiment YAML, car il est beaucoup plus naturel.

🟨 1. Qu’est-ce que YAML, simplement ?

Voici la définition LS2EC :

YAML est un format de données lisible par l’humain, utilisé pour décrire des configurations, des variables, des intentions et des actions dans des outils d’automatisation comme Ansible.

YAML veut dire :

YAML Ain’t Markup Language
(car ce n’est pas du XML)

🟨 2. Pourquoi YAML est si populaire en automation ?

✔ lisible

On peut le comprendre en le regardant.

✔ hiérarchique (comme YANG)

Il utilise l’indentation pour représenter la structure.

✔ simple

Pas d’accolades, pas de point-virgule, pas de parenthèses.

✔ parfait pour décrire un état

Ex : “Je veux que l’interface soit up.”

✔ utilisé partout :

• Ansible

• Kubernetes

• Docker

• CI/CD

• Cloud

• Terraform (dans certains contextes)

• Cisco NSO

• SaltStack

Le monde de l’infrastructure parle YAML.

🟨 3. Exemple ultra-simple LS2EC

Voici une configuration YAML :

Tu vois ?

Pas de syntaxe compliquée.
Pas de balises XML.
Juste… un format propre qui ressemble à la manière dont on pense.

🟨 4. Les règles fondamentales du YAML

Pour vraiment comprendre YAML, il faut retenir 3 règles d’or :

1️⃣ L’indentation fait tout

Chaque niveau se fait avec des espaces (pas de tabulations).

2️⃣ YAML n’est pas sensible à la case

Donc Name et name peuvent être différents selon les outils.

3️⃣ Il respecte une structure logique

• dictionnaires

• listes

• valeurs simples

Exemple d’une liste YAML :

Exemple d’un dictionnaire :

🟨 5. Quand YAML devient magique : quand il décrit un “état désiré”

Les outils modernes (comme Ansible) utilisent YAML pour dire :

“Voilà le résultat que je veux obtenir.”

Pas besoin d’écrire comment.
Juste quoi.

Exemple :

Ça veut dire :
“Je veux que cette interface soit activée.”
Peu importe la plateforme, le fournisseur, la commande CLI…

YAML décrit l’état final.
L’automatisation se charge du reste.

🎯 Résumé LS2EC :

YANG structure les données.
YAML décrit l’intention.
L’automatisation fait le lien entre les deux.

 

⭐8 — YAML + Ansible + Automatisation réseau

Aujourd’hui, lorsqu’on parle d’automatisation réseau, un nom revient systématiquement :

🔥 Ansible

Pourquoi Ansible est devenu un incontournable ?

Parce que :

• il est simple,

• il utilise YAML,

• il ne nécessite pas d’agent sur les équipements,

• il parle directement à NETCONF, RESTCONF ou SSH,

• il est multivendor (Cisco, Juniper, Arista, Huawei…)

• il permet de décrire l’état désiré sans écrire une seule ligne de code Python.

Et surtout…

Un ingénieur qui maîtrise Ansible + YAML peut automatiser 80 % de son réseau sans devenir développeur.

C’est exactement la philosophie LS2EC : démystifier, rendre accessible, faire monter en compétence.

🟨 1. Comment fonctionne Ansible ?

Ansible utilise :

• des inventaires → liste des équipements

• des modules → actions à exécuter

• des playbooks YAML → la recette de ce que tu veux faire

Là où YANG structure les données…
Ansible utilise ces structures et les transforme en actions.

🟨 2. Structure d’un playbook YAML Ansible (ultra lisible)

Voici un exemple simple de playbook :

tasks:
– name: Configurer GigabitEthernet1
ios_config:
lines:
– description Interface LS2EC
– ip address 10.0.0.1 255.255.255.0
parents: interface GigabitEthernet1

➡️ On est passé d’un CLI manuel…
à une configuration déclarée proprement en YAML.

🟨 3. Et avec NETCONF ?

Ansible peut utiliser des modules NETCONF pour appliquer des configurations basées sur des modèles YANG.

Exemple (simplifié LS2EC) :

tasks:
– name: Config interface
netconf_config:
xml: |
<config>
<interfaces xmlns=« urn:ietf:params:xml:ns:yang:ietf-interfaces »>
<interface>
<name>GigabitEthernet0/0/0/0</name>
<description>Interface LS2EC</description>
<enabled>true</enabled>
</interface>
</interfaces>
</config>

Ici :

• YANG → structure des données

• XML → format transporté

• NETCONF → protocole d’application

• Ansible → automation orchestrée en YAML

C’est exactement la transition que vivent les ingénieurs réseau modernes.

🟨 4. Exemple encore plus moderne : RESTCONF + JSON + YAML

Ansible peut aussi envoyer des configurations RESTCONF sous forme JSON, tout en utilisant YAML au niveau du playbook :

tasks:
– name: Set description
uri:
url: « https://router/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1 »
method: PATCH
headers:
Content-Type: « application/merge-patch+json »
body_format: json
body:
description: « Interface LS2EC »
validate_certs: no

Encore un exemple où YAML (intention) pilote JSON (données) via RESTCONF (API).

🧠 Pourquoi c’est puissant pour un ingénieur réseau ?

✔ YAML te permet d’écrire ce que tu veux faire

(“Je veux que cette interface ait telle IP.”)

✔ YANG te garantit que c’est valide

(“Cette IP doit respecter les contraintes du modèle.”)

✔ NETCONF/RESTCONF appliquent la configuration

(de manière fiable et atomique)

✔ Ansible te permet d’automatiser des dizaines d’équipements

(en un seul playbook)

Ce combo est imbattable.

🎯 Résumé LS2EC

YANG → structure
YAML → intention
Ansible → orchestration
NETCONF/RESTCONF → application

C’est le workflow moderne de l’ingénieur réseau.

⭐9 — YAML dans l’automatisation Cisco (IOS XE, IOS XR, NX-OS)

Comment YAML devient la langue de pilotage des équipements Cisco modernes

Cisco a été longtemps associé au CLI traditionnel :
interface gi0/0, router bgp 65001, ip route…

Mais Cisco a basculé massivement vers l’automatisation déclarative :

• modèles YANG (IETF, OpenConfig, natifs Cisco)

• NETCONF

• RESTCONF

• gRPC

• YDK

• NSO

• Terraform provider

• et bien sûr, YAML via Ansible

Aujourd’hui, YAML est présent dans presque toutes les solutions Cisco modernes.

🟦 1. YAML + Ansible + Cisco IOS XE

✔ Idéal pour l’enterprise networking
✔ Support complet NETCONF / RESTCONF
✔ Beaucoup de modules Ansible natifs

Voici un exemple d’un playbook YAML pour configurer une interface :

tasks:
– name: Set interface description
cisco.ios.ios_interface:
name: GigabitEthernet1
description: « Interface LS2EC »
enabled: true

YAML → intention
Module Ansible → abstraction
IOS XE → application via NETCONF/RESTCONF

🟦 2. YAML + NETCONF sur Cisco IOS XR

IOS XR est la plateforme la plus “programmable” de Cisco.
Elle a été pensée dès le début pour :

• YANG

• NETCONF

• MDR (Model Driven Telemetry)

• programmabilité massive

Un playbook YAML Ansible pilotant XR via NETCONF :

tasks:
– name: Configure BGP AS
netconf_config:
xml: |
<config>
<bgp xmlns=« http://openconfig.net/yang/bgp »>
<global>
<config>
<as>65001</as>
</config>
</global>
</bgp>
</config>

➡ YANG OpenConfig
➡ YAML Ansible
➡ NETCONF XR

Cisco XR adore YANG.
Cisco XR adore NETCONF.
Cisco XR adore OpenConfig.
C’est la plateforme la plus moderne de Cisco en matière d’automatisation.

🟦 3. YAML + Cisco NSO (Network Services Orchestrator)

NSO est un orchestrateur multivendor très avancé.
Il utilise :

• YANG comme langage principal

• YAML pour les playbooks

• REST + NETCONF + CLI drivers pour gérer les équipements

Exemple YAML NSO :

Ici :

• YAML décrit le service

• YANG modélise ce service

• NSO génère automatiquement la configuration CLI/NETCONF/RESTCONF

C’est de la magie.
Mais de la magie… structurée.

🟦 4. YAML dans la télémétrie Cisco (MDR / gNMI / OpenConfig)

Cisco XR & XE utilisent YAML pour décrire :

• les flux télémétriques

• les capteurs

• les subscriptions

• les collectors

• la fréquence des échantillons

Exemple pour activer un sensor path OpenConfig :

Encore une fois :
YAML → déclaration
OpenConfig YANG → structure
gNMI → transport

Cette combinaison est la base de la télémetrie moderne.

🧠 Pourquoi YAML est devenu indispensable chez Cisco ?

Parce que YAML est :

✔ lisible

Même pour un débutant.

✔ universel

Serveurs, containers, équipements réseau → tout le monde l’utilise.

✔ parfait pour décrire des intentions

“Je veux X”
Plutôt que “Tape telle commande”.

✔ compatible avec l’écosystème Ansible

Qui domine l’automation réseau.

✔ cohérent avec les modèles YANG

Il suffit de déclarer des valeurs selon le schéma YANG.

🎯 Résumé LS2EC :

YANG est la structure.
YAML est la façon dont l’humain exprime ce qu’il veut faire.
Cisco offre les deux, et l’automatisation devient naturelle.

 

⭐10 — YANG vs YAML : la comparaison claire, simple et pratique

Avant d’aller plus loin, il faut comprendre une chose essentielle :
YANG et YAML n’ont pas du tout le même rôle, mais ils travaillent ensemble dans l’automatisation réseau.

Tu peux retenir cette phrase :

YANG structure les données du réseau.
YAML décrit ce que tu veux faire avec ces données.

On développe maintenant.

🟦 1. Qu’est-ce que YANG ?

👉 Le modèle. La structure. Le cerveau.
Il décrit formellement comment les données réseau doivent être organisées.

YANG :

• représente les interfaces, les voisins BGP, les routes, la télémétrie

• impose des règles (types, contraintes, formats valides)

• garantit la cohérence des données

• sert de schéma aux API NETCONF/RESTCONF

• est utilisé par Cisco, Juniper, Nokia, Huawei, OpenConfig, IETF…

Exemple YANG d’une interface (simplifié en style LS2EC) :

C’est un schéma, comme une base de données réseau.

🟨 2. Qu’est-ce que YAML ?

👉 Le langage de description. L’intention. L’humain qui parle.

YAML :

• sert à écrire des playbooks Ansible

• décrit des variables, des paramètres, des états désirés

• est utilisé pour déclarer ce que tu veux changer, vérifier ou automatiser

• configure : Cisco, Juniper, Arista, Linux, Kubernetes, Docker…

Exemple YAML d’une interface :

Facile à lire.
Facile à écrire.
Facile à comprendre.

🧠 La vraie différence LS2EC

Voici la comparaison la plus simple :

🧩 3. Comment ils travaillent ensemble ?

Un scénario LS2EC classique :

1️⃣ L’équipement expose son schéma YANG
→ Interfaces, BGP, OSPF, Telemetry, QoS…

2️⃣ Ansible lit ou pousse les configurations grâce à NETCONF/RESTCONF
→ En s’appuyant sur YANG pour savoir ce qui est valide.

3️⃣ L’ingénieur écrit un playbook YAML pour automatiser l’action
→ Configure 20 interfaces identiques
→ Ajoute 15 voisins BGP
→ Active la télémétrie OpenConfig

4️⃣ Ansible traduit YAML → JSON/XML → NETCONF/RESTCONF → YANG
→ L’automatisation s’exécute en toute sécurité.

YAML est ton intention.
YANG est la réalité machine derrière.

🧠 Résumé LS2EC en une punchline

YANG = comment le réseau est structuré.
YAML = comment tu demandes au réseau de changer.

C’est exactement ce qui permet aujourd’hui à un ingénieur réseau d’automatiser sans devenir développeur.

⭐11 — Quand utiliser YANG et quand utiliser YAML ?

Beaucoup d’ingénieurs sont perdus entre les deux.
Ce tableau et cette explication vont devenir un référentiel pour eux.

🟦 1. Quand utiliser YANG ?

👉 Quand tu veux comprendre comment un équipement représente ses données.
👉 Quand tu écris de l’automatisation avancée (NETCONF/RESTCONF).
👉 Quand tu veux valider une config avant de l’envoyer.

Tu utilises YANG pour :

• analyser la structure des données réseau

• savoir “où” placer un paramètre

• comprendre les contraintes (types, formats, regex, must…)

• générer des schémas JSON/XML valides

• travailler en environnement multivendor (OpenConfig)

• bâtir des API réseau

• intégrer la télémétrie (OpenConfig gNMI)

• écrire des outils réseau avancés (Python + YDK, NSO…)

YANG est utilisé :

• par les constructeurs

• par les orchestrateurs

• par les API

• par les frameworks d’automatisation avancés

C’est le squelette du réseau.

🟨 2. Quand utiliser YAML ?

👉 Quand tu veux décrire ce que tu veux que le réseau fasse.
👉 Quand tu écris une automatisation Ansible.
👉 Quand tu veux rendre l’automatisation accessible, lisible, humaine.

Tu utilises YAML pour :

• rédiger des playbooks Ansible

• définir des variables de configuration

• documenter des intentions

• orchestrer des tasks (multi-équipements)

• configurer Cisco, Juniper, Arista… sans toucher à Python

• automatiser les opérations quotidiennes

• gérer des inventaires d’hôtes

• décrire des workflows

YAML est utilisé :

• par les ingénieurs réseau

• par les DevOps

• par les SRE

• par Kubernetes, Docker, GitLab CI, Terraform (branchée), Ansible…

C’est la langue naturelle de l’automatisation.

🧩 3. Le tableau décisionnel LS2EC : YANG vs YAML

Voici un tableau qui va devenir un classique dans ton site :

🧠 4. La meilleure analogie LS2EC pour tes lecteurs

Imagine l’automatisation comme la construction d’un bâtiment.

🧱 YANG = l’architecture, le plan officiel, la structure.

Il dit :

• où sont les pièces,

• quelles sont les règles,

• quelles briques tu peux utiliser,

• comment tout doit s’assembler.

🧰 YAML = la liste des instructions pour l’équipe de construction.

Il dit :

• ce que tu veux faire,

• dans quel ordre,

• avec quelles valeurs.

Les deux sont indispensables.
Mais ils n’ont pas le même rôle.

🎯 Résumé LS2EC

YANG → comment le réseau doit être structuré.
YAML → comment on pilote le réseau.

Comprendre quand utiliser l’un ou l’autre,
c’est ça qui fait passer un ingénieur réseau du niveau intermédiaire → au niveau expert.

⭐12 — Tableau comparatif complet YANG vs YAML

Voici un tableau enrichi, clair, synthétique, mais précis, qui répond aux besoins des ingénieurs réseau, DevOps, et étudiants.

📊 Tableau comparatif YANG vs YAML

🎯 Résumé du tableau en une phrase LS2EC :

YANG est la grammaire du réseau.
YAML est la manière dont tu écris la phrase.

L’un garantit que la phrase a un sens.
L’autre permet de la rédiger facilement.

 Conclusion inspirante

Si tu lis cet article jusqu’ici, alors tu sais déjà une chose :
l’automatisation réseau n’est pas une affaire de magie ni de génie.

C’est une affaire de structure (YANG),
d’intention (YAML),
et d’exécution (Ansible, NETCONF, RESTCONF).

Pendant longtemps, beaucoup ont cru que l’automatisation réseau était réservée :

• aux grandes entreprises,

• aux ingénieurs “full DevOps”,

• aux experts en Python,

• ou à une élite technique inatteignable.

Moi-même, Claude, j’ai commencé comme toi :
dans le CLI, ligne par ligne, commande après commande.
Je répétais les mêmes tâches, encore et encore.
Et je pensais que l’automatisation était quelque chose de “trop loin”,
“trop complexe”,
“pas pour nous”.

Puis un jour, tout s’est aligné :

• le besoin d’aller plus vite,

• le besoin de réduire les erreurs,

• le besoin de comprendre les plateformes modernes,

• le besoin d’évoluer en tant qu’ingénieur.

Et j’ai compris une chose essentielle :

L’automatisation n’est pas une montagne.
C’est un chemin.

Un chemin composé de petites briques simples :

• comprendre YANG

• comprendre YAML

• comprendre comment les deux se parlent

• comprendre NETCONF, RESTCONF

• envoyer une première configuration

• écrire un premier playbook

• automatiser une première tâche

• puis une deuxième

• puis 50 appareils d’un coup

Ce chemin, je le partage aujourd’hui avec LS2EC.
Parce que c’est ma mission : démystifier.
Rendre simple ce que d’autres rendent compliqué.
Montrer qu’un ingénieur réseau peut évoluer, progresser et grandir.
Avec pédagogie.
Avec simplicité.
Avec honnêteté.

YANG et YAML ne sont pas là pour te remplacer.
Ils sont là pour te libérer.
Te libérer du répétitif.
Te libérer de la pression.
Te libérer des erreurs humaines.
Te libérer pour que tu puisses te concentrer sur ce qui compte :
comprendre, concevoir, bâtir.

Le réseau moderne a besoin de toi.
De ton intelligence.
De ta vision.
De ta capacité à t’adapter.
De ta résilience.

Et si tu veux commencer ton chemin dans l’automatisation,
tu viens déjà de faire le premier pas.

Bienvenue dans le futur du réseau.
Et surtout… ne doute jamais de ta capacité à maîtriser tout ça.
Tu peux le faire.
Tu vas le faire.
Et LS2EC t’accompagnera jusqu’au bout.