Update documentation for clarity and consistency

Remove emojis and em dash separators Simplify introductory sentences Standardize section headings
2026-07-19 15:09:56 +02:00
parent 0edec585a7
commit 2d8830960b
22 changed files with 485 additions and 553 deletions
--- a/réseau/vxlan_automation/_index.en.md
+++ b/réseau/vxlan_automation/_index.en.md
@@ -6,11 +6,11 @@ cascade:
  type: docs
 ---

-## Introduction 📚
+## Introduction

 In this article, we're going to explore how to automate the deployment of a VXLAN infrastructure by relying on **Netbox** as our single source of truth (*Source of Truth*) and its **"Render Config"** feature.

-The main idea behind this project is to simplify network configuration management by limiting the use of external orchestration tools, which can sometimes make inventory management more complex. We're going to show how Netbox can automatically generate the configurations for our network devices from Jinja2 templates, provided we respect one fundamental principle: **standardizing our infrastructure.** 💡
+The main idea behind this project is to simplify network configuration management by limiting the use of external orchestration tools, which can sometimes make inventory management more complex. We're going to show how Netbox can automatically generate the configurations for our network devices from Jinja2 templates, provided we respect one fundamental principle: **standardizing our infrastructure.**

 To illustrate this approach, we'll use the example of a fictional site, **"Paris"**, designed according to clear and precise standardization rules. This standardization will allow us to:

@@ -18,17 +18,17 @@ To illustrate this approach, we'll use the example of a fictional site, **"Paris
 2. **Generate** the network device configurations based on the information centralized in Netbox.
 3. **Validate** the proper operation of this automated infrastructure using a **NetLab** lab environment running on ContainerLab.

-Through this concrete example, we'll highlight the fact that standardization isn't a constraint, but rather the **essential foundation** for successful automation and simplified, efficient network management.
+Through this concrete example, we'll show that standardization isn't a constraint, but the foundation for successful automation and simpler, more efficient network management.

 > [!NOTE] **CookBook**
 > All of the actions explained in this article are described [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates).  
 > This article will **not** provide a step-by-step guide, but will provide links to the Cookbook, which does.

-## The Concept of the Standardized Site ⚙️
+## The concept of the standardized site

 Effective automation of a network infrastructure relies on a solid foundation of standardization. To illustrate this principle, we've defined a **standard site** model, characterized by a precise structure and precise connectivity rules. Our "Paris" site will be a concrete instance of this standardized model.

-### Typical Structure of a Standard Site 🏢
+### Typical structure of a standard site

 A standard site is defined by the following elements:

@@ -36,7 +36,7 @@ A standard site is defined by the following elements:
 * **One to Five Single-Story Buildings:** Each building is dedicated to hosting a single customer (although the same customers can be spread across multiple buildings).  
 Each standard building is equipped with an access switch for local connectivity and a single leaf for connecting to the fabric.

-### Standard Leaf Connectivity 🔗
+### Standard leaf connectivity

 In a standard site, the connection of leaf devices to the spines follows these rules:

@@ -50,7 +50,7 @@ In a standard site, the connection of leaf devices to the spines follows these r
 > For the purposes of this **Proof of Concept**, we opted for a simplified architecture without advanced redundancy at the leaf-spine connection level.  
 > The main goal is to demonstrate automation based on this standardized structure.

-### IP Addressing Plan for the "Paris" Site 🌐
+### IP addressing plan for the "Paris" site

 For our "Paris" site, we'll use the following Netbox prefix containers, which fit into our overall addressing strategy:

@@ -70,13 +70,13 @@ For our "Paris" site, we'll use the following Netbox prefix containers, which fi

 These "Container" type prefixes are specific to the "Paris" site and will be used by our automation scripts to assign IP addresses to the various devices and customers at this site, in accordance with the standard structure we've defined.

-## The "Paris" Site: An Instance of Our Standardized Model 📍
+## The "Paris" site: an instance of our standardized model

 Our "Paris" site strictly follows the structure and rules defined in our standard site model. It will therefore include a server room with the two spines and can host up to five single-story buildings, each equipped with a leaf and an access switch, connected according to the established conventions. The IP addressing for "Paris" will come from the standard prefix containers we've defined.

 This standardization is the key that will allow us to automate the creation and configuration of our "Paris" site infrastructure using the scripts we're about to present.

-## Test Environment
+## Test environment

 The POC will run on ContainerLab, so it's necessary to refer to [this article](../../documentation/devpod) to easily reproduce the installation and the tools.

@@ -89,11 +89,11 @@ We'll be using:

 For more details, [here's the installation documentation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md)

-## Scripting: Automation in Action! ⚙️
+## Scripting: automation in action

 Now we get to the heart of the matter: how we use scripts to automate the creation of our VXLAN fabric by relying on Netbox. We'll look at two main scripts that do most of the heavy lifting!

-### Step 1: Preparing Netbox with `import.py` 🛠️
+### Step 1: preparing Netbox with `import.py`

 Before we build our network, we need to prepare our "Source of Truth," Netbox. The [`import.py`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox) script is here for that! It will inject into Netbox the basic information for our "Paris" site and the models for our devices.

@@ -122,19 +122,19 @@ Make sure to replace `http://localhost:8080` with your Netbox address and `YOUR_
 > [!TIP]
 > Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox)

-### Step 2: Building the VXLAN Fabric with `Create_Fabric/main.py` 🚀
+### Step 2: building the VXLAN fabric with `Create_Fabric/main.py`

 Now that Netbox is ready, we move on to building our network with the `Create_Fabric/main.py` script. This script will create all the devices, connect them, and assign them IP addresses, all while following our standardized model for the "Paris" site.

 **The Script's Steps:**

-1. **Ready Check? ✅** The script starts by checking whether everything it needs already exists in Netbox (device roles, IP roles, device types). We don't want to start building on unstable foundations!
-2. **Choosing the Site: "Paris" Of Course! 🇫🇷** The script asks us which site we're working on. We select "Paris," our standard site. Its short name "PA" will be used as the base for naming our devices.
-3. **Bringing Out the Spines (x2) 💪** The script creates our two spines in Netbox, using the correct model and the "spine" role. They're named `padc_sp1_00` and `padc_sp2_00`.
-4. **Leaf/Access Pairs per Building 🏢➡️** For each building in "Paris" (up to 5), the script creates a Netbox "location" and installs a leaf there (e.g. `pa01_lf1_00`) and an access switch (e.g. `pa01_sw1_00`).
-5. **Automatic Cabling 🧶** The script virtually connects the devices in Netbox following our rules: `Eth1` of the leaf to `Eth*n*` of Spine 1, `Eth2` of the leaf to `Eth*n*` of Spine 2, and `Eth3` of the leaf to `Eth1` of the access switch. No more getting tangled up with cables!
-6. **IP Distribution 🗺️** The script draws from the "Paris" IP address blocks and automatically assigns IPs to interfaces (/31s for the links between devices and /32s for loopbacks).
-7. **ASN Assignment 🏷️** Finally, the script assigns an AS number to each spine and each leaf for BGP routing. These numbers are stored in a special "ASN" field in Netbox.
+1. **Ready check.** The script starts by checking whether everything it needs already exists in Netbox (device roles, IP roles, device types). We don't want to start building on unstable foundations.
+2. **Choosing the site: "Paris" of course.** The script asks us which site we're working on. We select "Paris," our standard site. Its short name "PA" will be used as the base for naming our devices.
+3. **Bringing out the spines (x2).** The script creates our two spines in Netbox, using the correct model and the "spine" role. They're named `padc_sp1_00` and `padc_sp2_00`.
+4. **Leaf/access pairs per building.** For each building in "Paris" (up to 5), the script creates a Netbox "location" and installs a leaf there (e.g. `pa01_lf1_00`) and an access switch (e.g. `pa01_sw1_00`).
+5. **Automatic cabling.** The script virtually connects the devices in Netbox following our rules: `Eth1` of the leaf to `Eth*n*` of Spine 1, `Eth2` of the leaf to `Eth*n*` of Spine 2, and `Eth3` of the leaf to `Eth1` of the access switch. No more getting tangled up with cables.
+6. **IP distribution.** The script draws from the "Paris" IP address blocks and automatically assigns IPs to interfaces (/31s for the links between devices and /32s for loopbacks).
+7. **ASN assignment.** Finally, the script assigns an AS number to each spine and each leaf for BGP routing. These numbers are stored in a special "ASN" field in Netbox.

 ```bash
 uv run Create_Fabric/main.py
@@ -150,7 +150,7 @@ Existing Sites:
 Choose site number or 'new': 1
 ```

-**The Result? 🎉** By running this script, we end up with our entire "Paris" VXLAN infrastructure created and connected in Netbox, ready to be configured!
+**The result?** By running this script, we end up with our entire "Paris" VXLAN infrastructure created and connected in Netbox, ready to be configured.

 > [!NOTE] Netbox Plugin
 > The configuration can easily be visualized with the help of the plugin: [netbox_topology_views](https://github.com/netbox-community/netbox-topology-views)
@@ -160,13 +160,13 @@ Choose site number or 'new': 1
 > [!TIP]
 > Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-create-fabric)

-### Step 3: Configuring Our Customers with `Create_Fabric/add_customers.py` 🧑‍💻
+### Step 3: configuring our customers with `Create_Fabric/add_customers.py`

-At this point, the fabric is functional, but no customer is configured yet. What does that mean? 🤔 It means that the *underlay* – the foundation of our network – is configured in Netbox, and it's possible to generate a configuration to deploy BGP and configure the ASes. However, the access switches and leafs aren't ready yet to host users or customer services. There's no information in Netbox that allows for that yet.
+At this point, the fabric is functional, but no customer is configured yet. What does that mean? It means that the *underlay* – the foundation of our network – is configured in Netbox, and it's possible to generate a configuration to deploy BGP and configure the ASes. However, the access switches and leafs aren't ready yet to host users or customer services. There's no information in Netbox that allows for that yet.

-In our standardized approach, each building is designed to host **one** "customer." A customer could be, for example, a specific team within the company or an external contractor. Each customer will be assigned a VLAN (and, in our VXLAN fabric, a corresponding VNI). 🏢➡️🧑‍💻
+In our standardized approach, each building is designed to host **one** "customer." A customer could be, for example, a specific team within the company or an external contractor. Each customer will be assigned a VLAN (and, in our VXLAN fabric, a corresponding VNI).

-To perform this customer configuration, we use a dedicated script: **Create_Fabric/add_customers.py**. It will guide us step by step, asking for the VLAN and VNI to assign, as well as the building or buildings where our customers are based. 📋 Here's an example of it running:
+To perform this customer configuration, we use a dedicated script: **Create_Fabric/add_customers.py**. It will guide us step by step, asking for the VLAN and VNI to assign, as well as the building or buildings where our customers are based. Here's an example of it running:

 ```bash
 ❯ uv run Create_Fabric/add_customers.py
@@ -198,7 +198,7 @@ Available Locations:
 Select locations (comma-separated indices): 1,3
 ```

-Once this information is provided, the script takes care of automating several actions in Netbox ✨:
+Once this information is provided, the script takes care of automating several actions in Netbox:

 * Creation of the tenant (representing the customer).
 * Assignment of buildings (locations) to the tenant.
@@ -206,22 +206,22 @@ Once this information is provided, the script takes care of automating several a
 * Logical configuration of the associated VXLAN/VLAN elements.
 * Assignment of specific interfaces on the access devices for this customer.

-Once Netbox is properly populated with all this customer data 📊, it then becomes possible to extract the final, ready-to-use network configuration from it. ⚙️
+Once Netbox is properly populated with all this customer data, it then becomes possible to extract the final, ready-to-use network configuration from it.

-## The Magic of Templates: Netbox and Jinja2 Take the Stage ✨
+## Generating configs with Netbox and Jinja2 templates

 Now that we have our network inventory all set up in Netbox, how do we tell our devices how to configure themselves? That's where **Render Config** and **Jinja2 templates** come in!

 > [!TIP] Templates
 > The templates used are available [here](https://github.com/darnodo/projet-vxlan-automation/tree/dev/templates).

-### Jinja Templates: Our Configuration Recipes 📝
+### Jinja templates: our configuration recipes

-1. **What Are Render Configs, Anyway? 🤔** Imagine Netbox as a chef who has all the ingredients (our devices, their interfaces, their IPs, etc.). Render Configs are its way of turning these ingredients into prepared dishes, meaning configuration files for our network devices.
+1. **What are Render Configs, anyway?** Imagine Netbox as a chef who has all the ingredients (our devices, their interfaces, their IPs, etc.). Render Configs are its way of turning these ingredients into prepared dishes, meaning configuration files for our network devices.

-2. **Jinja2: Our Recipe Language 🗣️** To write these configuration "recipes," Netbox uses a super powerful engine called Jinja2. It's a bit like a simple programming language that lets us create dynamic configuration templates. We can put "holes" (variables) in them that get filled in with the information from our devices in Netbox.
+2. **Jinja2: our recipe language.** To write these configuration "recipes," Netbox uses a powerful engine called Jinja2, a bit like a simple programming language that lets us create dynamic configuration templates. We can put "holes" (variables) in them that get filled in with the information from our devices in Netbox.

-3. **A Quick Look at a Recipe 📜** Let's take an example of a Jinja2 template for one of our leafs:
+3. **A quick look at a recipe.** Let's take an example of a Jinja2 template for one of our leafs:

    ```jinja
    hostname {{ device.name }}
@@ -242,7 +242,7 @@ Now that we have our network inventory all set up in Netbox, how do we tell our

    See those things between double curly braces `{{ ... }}`? Those are our variables! For example, `{{ device.name }}` will be replaced with the name of our leaf, and `{{ interface.name }}` with the name of each interface. We can even add conditions (`{% if ... %}`) and loops (`{% for ... %}`) to adapt the configuration.

-4. **How Netbox Prepares the Dish 🍳** When we ask Netbox to generate the configuration for a device (say, our `pa01_lf1_00`), here's what happens:
+4. **How Netbox prepares the dish.** When we ask Netbox to generate the configuration for a device (say, our `pa01_lf1_00`), here's what happens:

    * It looks up all the information about this leaf: its name, its interfaces, its IPs, its connections, its ASN, etc.
    * It takes the Jinja2 template that we've associated with the "leaf" role.
@@ -252,11 +252,11 @@ Now that we have our network inventory all set up in Netbox, how do we tell our
 > [!TIP]
 > Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates)

-### From Netbox to the Lab: Looking and Doing It by Hand for Now 🖥️➡️💻
+### From Netbox to the lab: doing it by hand for now

 Now that we know how Netbox generates the configurations, let's see how we use them in our Containerlab lab.

-1. **Taking a Look at the Configuration in Netbox 👀** To view the configuration generated by Netbox for a device, it's simple:
+1. **Taking a look at the configuration in Netbox.** To view the configuration generated by Netbox for a device, it's simple:

    * In the Netbox interface, go to **Devices**.
    * Click on the device you're interested in (for example, one of our leafs).
@@ -264,27 +264,27 @@ Now that we know how Netbox generates the configurations, let's see how we use t

    ![PA01 Leaf Configuration](<Render Config.en.png>)

-2. **The Human Touch in Containerlab 🖐️** For now, we don't have a script that automatically pushes these configurations to our devices in Containerlab. So we're going to do it the old-fashioned way (but that's fine for a demo!):
+2. **The human touch in Containerlab.** For now, we don't have a script that automatically pushes these configurations to our devices in Containerlab. So we're going to do it the old-fashioned way (fine for a demo):

    * We connect to each cEOS device in our lab via SSH (for example, using the Containerlab VSCode extension as we saw in the [cookbook](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-deploy-configuration)).
    * We copy the configuration we viewed in Netbox (the **Render Config** tab).
    * And we paste it into the cEOS device's command-line interface (in configuration mode, of course!).

-3. **What's Next? Future Perspectives 🚀** Of course, this copy-paste step isn't the pinnacle of automation! But it's a first step toward seeing how Netbox can be our central brain. In the future, we could imagine tools like Ansible or NAPALM connecting to Netbox, retrieving these generated configurations, and automatically applying them to our devices. That's a path for future adventures in automation! 😉
+3. **What's next?** This copy-paste step isn't the pinnacle of automation, but it's a first step toward seeing how Netbox can be our central brain. Down the line, tools like Ansible or NAPALM could connect to Netbox, retrieve these generated configurations, and apply them to our devices automatically.

-## Validating Communication ✅
+## Validating communication

-### Ping ⚽
+### Ping

 In the cookbook, we chose to configure 2 customers each in 2 different buildings, which lets us run a **ping**. As a reminder:

-1. 🟠 Orange:
+1. Orange:
    * Subnet: 10.0.0.0/24
    * Hosts:
      * PA1: 10.0.0.10
      * PA3: 10.0.0.20

-2. 🟣 Purple
+2. Purple
    * Subnet: 10.0.1.0/24
    * Hosts:
      * PA2: 10.0.1.10
@@ -305,7 +305,7 @@ PING 10.0.0.20 (10.0.0.20): 56 data bytes
 ...
 ```

-### Packet Capture
+### Packet capture

 To go further, it's also possible to use Wireshark, which is available by default in the devcontainer, with the help of Edgeshark.  
 For more information, I'll point you to the article on [My First Lab](../../netlab/first_lab/#utiliser-edgeshark-)
@@ -316,11 +316,9 @@ And then, via VSCode, it's possible to launch Wireshark directly:

 ![Capture Wireshark](wireshark_eth2_leaf1.en.png)

-## Conclusion ✨
+## Conclusion

-To sum up our journey, we've seen how Netbox becomes our best ally 🥇 for automating the VXLAN network.  
-The key is to start from **a standardized foundation** 📐 — that's what allows Netbox to generate our configurations almost entirely on its own, thanks to Jinja2 templates.
+Netbox turns out to be a solid ally for automating the VXLAN network.
+The key is starting from a standardized foundation: that's what lets Netbox generate our configurations almost entirely on its own, using Jinja2 templates.

-Even though, for now, we're still doing a bit of copy-pasting 🖐️, the potential is huge! Having all our information centralized in Netbox is the first step toward truly simplifying our network management and opening the door to full automation. Standardization isn't a constraint, but a springboard toward greater efficiency. ✅
-
-This is only the beginning! Think about what comes next: automatically deploying these configs, managing more complex networks... Automation is here, accessible, ready to save you precious time. 🚀💪
+We're still copying and pasting the last step by hand, but centralizing all our information in Netbox is the first move toward simplifying network management and opening the door to full automation. Next up: deploying these configs automatically and handling more complex networks.
--- a/réseau/vxlan_automation/_index.fr.md
+++ b/réseau/vxlan_automation/_index.fr.md
@@ -6,7 +6,7 @@ cascade:
  type: docs
 ---

-## Introduction 📚
+## Introduction

 Dans cet article, nous allons explorer comment automatiser le déploiement d'une infrastructure VXLAN en nous appuyant sur **Netbox** comme source unique de vérité (*Source of Truth*) et sa fonctionnalité de **"Render Config"**.

@@ -18,17 +18,17 @@ Pour illustrer cette approche, nous allons prendre l'exemple d'un site fictif, *
 2. **Générer** les configurations des équipements réseau en se basant sur les informations centralisées dans Netbox.
 3. **Valider** le bon fonctionnement de cette infrastructure automatisée à l'aide d'un environnement de laboratoire **NetLab** sous ContainerLab.

-À travers cet exemple concret, nous mettrons en lumière que la standardisation n'est pas une contrainte, mais plutôt le **socle indispensable** pour une automatisation réussie et une gestion réseau simplifiée et efficace.
+À travers cet exemple concret, nous montrerons que la standardisation n'est pas une contrainte, mais le socle d'une automatisation réussie et d'une gestion réseau simplifiée et efficace.

 > [!NOTE] **CookBook**
 > L'ensemble des actions expliquées dans cet article sont décrites [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates).  
 > Cette article **ne** nous fournira **pas** un guide étape par étape, mais fournira les liens vers le Cookbook qui lui, le fourni.

-## Le Concept du Site Standardisé ⚙️
+## Le concept du site standardisé

 L'automatisation efficace d'une infrastructure réseau repose sur une base solide de standardisation. Pour illustrer ce principe, nous avons défini un modèle de **site standard**, caractérisé par une structure et des règles de connectivité précises. Notre site "Paris" sera une instance concrète de ce modèle standardisé.

-### Structure Type d'un Site Standard 🏢
+### Structure type d'un site standard

 Un site standard est défini par les éléments suivants :

@@ -36,7 +36,7 @@ Un site standard est défini par les éléments suivants :
 * **Un à Cinq Bâtiments Plain-Pied :** Chaque bâtiment est dédié à l'hébergement d'un seul client (bien que les mêmes clients puissent être répartis sur plusieurs bâtiments).  
 Chaque bâtiment standard est équipé d'un switch d'accès pour la connectivité locale et d'un unique leaf pour la connexion à la fabric.

-### Connectivité Standard des Leafs 🔗
+### Connectivité standard des leafs

 Dans un site standard, la connexion des équipements leaf aux spines suit les règles suivantes :

@@ -50,7 +50,7 @@ Dans un site standard, la connexion des équipements leaf aux spines suit les r
 > Pour les besoins de ce **Proof of Concept**, nous avons opté pour une architecture simplifiée sans redondance avancée au niveau des connexions leaf-spine.  
 > L'objectif principal est de démontrer l'automatisation basée sur cette structure standardisée.

-### Plan d'Adressage IP pour le Site "Paris" 🌐
+### Plan d'adressage IP pour le site "Paris"

 Pour notre site "Paris", nous allons utiliser les conteneurs de préfixes Netbox suivants, qui s'inscrivent dans notre stratégie d'adressage globale :

@@ -70,15 +70,15 @@ Pour notre site "Paris", nous allons utiliser les conteneurs de préfixes Netbox

 Ces préfixes de type "Conteneur" sont spécifiques au site de "Paris" et seront utilisés par nos scripts d'automatisation pour attribuer les adresses IP aux différents équipements et clients de ce site, en respectant la structure standard que nous avons définie.

-## Le Site "Paris" : Une Instance de Notre Modèle Standardisé 📍
+## Le site "Paris" : une instance de notre modèle standardisé

 Notre site "Paris" suit scrupuleusement la structure et les règles définies dans notre modèle de site standard. Il comprendra donc une salle serveur avec les deux spines et pourra accueillir jusqu'à cinq bâtiments plain-pied, chacun équipé d'un leaf et d'un switch d'accès, connectés selon les conventions établies. L'adressage IP de "Paris" sera issu des conteneurs de préfixes standard que nous avons définis.

 Cette standardisation est la clé qui nous permettra d'automatiser la création et la configuration de l'infrastructure de notre site "Paris" à l'aide des scripts que nous allons présenter ensuite.

-## Environment de test
+## Environnement de test

-Le POC se jouera sur ContainerLab, il est donc nécessaire de se reférencer à [cette article](../../documentation/devpod) afin de facilement reproduire l'installation et les outils.
+Le POC se joue sur ContainerLab, il est donc nécessaire de se référer à [cet article](../../documentation/devpod) pour reproduire facilement l'installation et les outils.

 Nous utiliserons :

@@ -87,29 +87,29 @@ Nous utiliserons :
 * Netbox
  * Plugin : netbox_topology_views

-Pour plus de détails, [voici la documentationation d'installation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md)
+Pour plus de détails, [voici la documentation d'installation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md)

-## Scripting : L'Automatisation en Action ! ⚙️
+## Scripting : l'automatisation en action

 Maintenant, on entre dans le vif du sujet : comment on utilise des scripts pour automatiser la création de notre fabric VXLAN en s'appuyant sur Netbox. On va voir deux scripts principaux qui font le gros du boulot !

-### Étape 1 : On Prépare Netbox avec `import.py` 🛠️
+### Étape 1 : on prépare Netbox avec `import.py`

 Avant de construire notre réseau, il faut préparer notre "Source of Truth", Netbox. Le script [`import.py`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox) est là pour ça ! Il va injecter dans Netbox les infos de base de notre site "Paris" et les modèles de nos équipements.

-**Les Ingrédients du Script :**
+**Les ingrédients du script :**

 * **[`Devices/devices_model.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/Devices/devices_model.yml) :** La carte d'identité de nos équipements (spines, leafs, access cEOS) avec leurs caractéristiques (nombre d'interfaces, types, etc.).
 * **[`IPAM/subnet.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/IPAM/subnets.yml) :** Les infos de notre site "Paris" (région Europe, ville Paris) et les plans de nos blocs d'adresses IP (pour l'underlay, les loopbacks et nos clients).

-**Ce Que Fait le Script :**
+**Ce que fait le script :**

 * Il lit le fichier `devices_model.yml` et crée les modèles d'équipements correspondants dans Netbox. C'est comme enregistrer les types de matériel qu'on va utiliser.
 * Il lit le fichier `IPAM/subnet.yml` et crée :
  * La région "Europe" et le site "Paris".
  * Les blocs d'adresses IP qu'on va utiliser pour notre réseau à Paris (nos "préfixes conteneurs").

-**Comment on Lance la Machine :**
+**Comment on lance la machine :**

 On ouvre notre terminal et on tape la commande :

@@ -122,19 +122,19 @@ Remplace bien `http://localhost:8080` par l'adresse de ton Netbox et `YOUR_TOKEN
 > [!TIP]
 > Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox)

-### Étape 2 : On Monte la Fabric VXLAN avec `Create_Fabric/main.py` 🚀
+### Étape 2 : on monte la fabric VXLAN avec `Create_Fabric/main.py`

 Maintenant que Netbox est prêt, on passe à la construction de notre réseau avec le script `Create_Fabric/main.py`. Ce script va créer tous les équipements, les connecter et leur attribuer des adresses IP, le tout en suivant notre modèle standardisé pour le site "Paris".

-**Les Étapes du Script :**
+**Les étapes du script :**

-1. **Vérification des Prêts ? ✅** Le script commence par vérifier si tout ce dont il a besoin existe dans Netbox (les rôles des équipements, les rôles IP, les types d'équipements). On ne veut pas commencer à construire sur des bases instables !
-2. **Choix du Terrain : "Paris" Évidemment ! 🇫🇷** Le script nous demande sur quel site on travaille. On sélectionne "Paris", notre site standard. Son petit nom "PA" va servir de base pour nommer nos équipements.
-3. **On Sort les Spines (x2) 💪** Le script crée nos deux spines dans Netbox, en utilisant le bon modèle et le rôle "spine". Ils sont baptisés `padc_sp1_00` et `padc_sp2_00`.
-4. **Les Paires Leaf/Access par Bâtiment 🏢➡️** Pour chaque bâtiment de "Paris" (jusqu'à 5), le script crée une "location" Netbox et y installe un leaf (par exemple `pa01_lf1_00`) et un switch d'accès (par exemple `pa01_sw1_00`).
-5. **Câblage Automatique 🧶** Le script connecte virtuellement les équipements dans Netbox en suivant nos règles : `Eth1` du leaf vers `Eth*n*` du Spine 1, `Eth2` du leaf vers `Eth*n*` du Spine 2, et `Eth3` du leaf vers `Eth1` de l'access switch. Plus besoin de s'embrouiller avec les câbles !
-6. **Distribution des IPs 🗺️** Le script pioche dans les blocs d'adresses IP de "Paris" et attribue automatiquement les IPs aux interfaces (des /31 pour les liens entre les équipements et des /32 pour les loopbacks).
-7. **Attribution des ASNs 🏷️** Pour finir, le script donne un numéro d'AS à chaque spine et à chaque leaf pour le routage BGP. Ces numéros sont enregistrés dans un champ spécial "ASN" dans Netbox.
+1. **Vérification préalable.** Le script commence par vérifier si tout ce dont il a besoin existe dans Netbox (les rôles des équipements, les rôles IP, les types d'équipements). On ne veut pas commencer à construire sur des bases instables.
+2. **Choix du site : "Paris" évidemment.** Le script nous demande sur quel site on travaille. On sélectionne "Paris", notre site standard. Son petit nom "PA" va servir de base pour nommer nos équipements.
+3. **On sort les spines (x2).** Le script crée nos deux spines dans Netbox, en utilisant le bon modèle et le rôle "spine". Ils sont baptisés `padc_sp1_00` et `padc_sp2_00`.
+4. **Les paires leaf/access par bâtiment.** Pour chaque bâtiment de "Paris" (jusqu'à 5), le script crée une "location" Netbox et y installe un leaf (par exemple `pa01_lf1_00`) et un switch d'accès (par exemple `pa01_sw1_00`).
+5. **Câblage automatique.** Le script connecte virtuellement les équipements dans Netbox en suivant nos règles : `Eth1` du leaf vers `Eth*n*` du Spine 1, `Eth2` du leaf vers `Eth*n*` du Spine 2, et `Eth3` du leaf vers `Eth1` de l'access switch. Plus besoin de s'embrouiller avec les câbles.
+6. **Distribution des IPs.** Le script pioche dans les blocs d'adresses IP de "Paris" et attribue automatiquement les IPs aux interfaces (des /31 pour les liens entre les équipements et des /32 pour les loopbacks).
+7. **Attribution des ASNs.** Pour finir, le script donne un numéro d'AS à chaque spine et à chaque leaf pour le routage BGP. Ces numéros sont enregistrés dans un champ spécial "ASN" dans Netbox.

 ```bash
 uv run Create_Fabric/main.py
@@ -150,7 +150,7 @@ Existing Sites:
 Choose site number or 'new': 1
 ```

-**Le Résultat ? 🎉** En lançant ce script, on se retrouve avec toute notre infrastructure VXLAN de "Paris" créée et connectée dans Netbox, prête à être configurée !
+**Le résultat ?** En lançant ce script, on se retrouve avec toute notre infrastructure VXLAN de "Paris" créée et connectée dans Netbox, prête à être configurée.

 > [!NOTE] Netbox Plugin
 > La configuration est facilement visualisable avec l'aide du plugin : [netbox_topology_views](https://github.com/netbox-community/netbox-topology-views)
@@ -160,13 +160,13 @@ Choose site number or 'new': 1
 > [!TIP]
 > Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-create-fabric)

-### Étape 3 : On configure nos clients avec `Create_Fabric/add_customers.py` 🧑‍💻
+### Étape 3 : on configure nos clients avec `Create_Fabric/add_customers.py`

-À ce niveau, la fabric est fonctionnelle, mais aucun client n'est configuré. Qu'est-ce que cela signifie ? 🤔 Cela veut dire que l'*underlay* – la base de notre réseau – est configuré sur Netbox, et qu'il est possible de générer une configuration pour déployer le BGP et configurer les AS. Cependant, les switches d'accès et les leafs ne sont pas encore prêts à accueillir des utilisateurs ou des services clients. Aucune information dans Netbox ne nous le permet encore.
+À ce niveau, la fabric est fonctionnelle, mais aucun client n'est configuré. Qu'est-ce que cela signifie ? Cela veut dire que l'*underlay* – la base de notre réseau – est configuré sur Netbox, et qu'il est possible de générer une configuration pour déployer le BGP et configurer les AS. Cependant, les switches d'accès et les leafs ne sont pas encore prêts à accueillir des utilisateurs ou des services clients. Aucune information dans Netbox ne nous le permet encore.

-Dans notre approche standardisée, chaque bâtiment est conçu pour accueillir **un** "client". Un client peut être, par exemple, une équipe spécifique au sein de l'entreprise ou un prestataire externe. À chaque client, nous attribuerons un VLAN (et dans notre fabric VXLAN, un VNI correspondant). 🏢➡️🧑‍💻
+Dans notre approche standardisée, chaque bâtiment est conçu pour accueillir **un** "client". Un client peut être, par exemple, une équipe spécifique au sein de l'entreprise ou un prestataire externe. À chaque client, nous attribuerons un VLAN (et dans notre fabric VXLAN, un VNI correspondant).

-Pour réaliser cette configuration client, nous utilisons un script dédié : **Create_Fabric/add_customers.py**. Celui-ci va nous guider pas à pas en nous demandant le VLAN et le VNI à attribuer, ainsi que le ou les bâtiments où sont basés nos clients. 📋 Voici un exemple de son exécution :
+Pour réaliser cette configuration client, nous utilisons un script dédié : **Create_Fabric/add_customers.py**. Celui-ci va nous guider pas à pas en nous demandant le VLAN et le VNI à attribuer, ainsi que le ou les bâtiments où sont basés nos clients. Voici un exemple de son exécution :

 ```bash
 ❯ uv run Create_Fabric/add_customers.py
@@ -198,7 +198,7 @@ Available Locations:
 Select locations (comma-separated indices): 1,3
 ```

-Une fois ces informations fournies, le script se charge d'automatiser plusieurs actions dans Netbox ✨ :
+Une fois ces informations fournies, le script se charge d'automatiser plusieurs actions dans Netbox :

 * La création du tenant (représentant le client).
 * L'attribution des bâtiments (locations) au tenant.
@@ -206,22 +206,22 @@ Une fois ces informations fournies, le script se charge d'automatiser plusieurs
 * La configuration logique des éléments VXLAN/VLAN associés.
 * L'attribution des interfaces spécifiques sur les équipements d'accès pour ce client.

-Une fois Netbox correctement renseigné avec toutes ces données clients 📊, il devient alors possible d'en extraire la configuration réseau finale prête à l'emploi. ⚙️
+Une fois Netbox correctement renseigné avec toutes ces données clients, il devient alors possible d'en extraire la configuration réseau finale prête à l'emploi.

-## La Magie des Templates : Netbox et Jinja2 Entrent en Scène ✨
+## Générer les configurations avec Netbox et Jinja2

 Maintenant qu'on a notre inventaire réseau au top dans Netbox, comment on dit à nos équipements comment se configurer ? C'est là qu'interviennent les **Render Config** et les **templates Jinja2** !

 > [!TIP] Templates
 > Les templates utilisés sont présents [ici](https://github.com/darnodo/projet-vxlan-automation/tree/dev/templates).

-### Les Templates Jinja : Nos Recettes de Configuration 📝
+### Les templates Jinja : nos recettes de configuration

-1. **Les Render Config, Késako ? 🤔** Imagine Netbox comme un chef cuisinier qui a tous les ingrédients (nos équipements, leurs interfaces, leurs IPs, etc.). Les Render Config, c'est sa manière de transformer ces ingrédients en plats préparés, c'est-à-dire des fichiers de configuration pour nos équipements réseau.
+1. **Les Render Config, késako ?** Imagine Netbox comme un chef cuisinier qui a tous les ingrédients (nos équipements, leurs interfaces, leurs IPs, etc.). Les Render Config, c'est sa manière de transformer ces ingrédients en plats préparés, c'est-à-dire des fichiers de configuration pour nos équipements réseau.

-2. **Jinja2 : Notre Langage de Recettes 🗣️** Pour écrire ces "recettes" de configuration, Netbox utilise un moteur super puissant appelé Jinja2. C'est un peu comme un langage de programmation simple qui nous permet de créer des modèles de configuration dynamiques. On peut y mettre des "trous" (des variables) qui seront remplis par les informations de nos équipements dans Netbox.
+2. **Jinja2 : notre langage de recettes.** Pour écrire ces "recettes" de configuration, Netbox utilise un moteur puissant appelé Jinja2, un peu comme un langage de programmation simple qui nous permet de créer des modèles de configuration dynamiques. On peut y mettre des "trous" (des variables) qui seront remplis par les informations de nos équipements dans Netbox.

-3. **Un Petit Coup d'Œil à une Recette 📜** Prenons un exemple de template Jinja2 pour un de nos leafs :
+3. **Un petit coup d'œil à une recette.** Prenons un exemple de template Jinja2 pour un de nos leafs :

    ```jinja
    hostname {{ device.name }}
@@ -242,7 +242,7 @@ Maintenant qu'on a notre inventaire réseau au top dans Netbox, comment on dit

    Vous voyez les trucs entre doubles accolades `{{ ... }}` ? Ce sont nos variables ! Par exemple, `{{ device.name }}` sera remplacé par le nom de notre leaf, et `{{ interface.name }}` par le nom de chaque interface. On peut même faire des conditions (`{% if ... %}`) et des boucles (`{% for ... %}`) pour adapter la configuration.

-4. **Comment Netbox Prépare le Plat 🍳** Quand on demande à Netbox de générer la configuration pour un équipement (disons, notre `pa01_lf1_00`), voici ce qu'il se passe :
+4. **Comment Netbox prépare le plat.** Quand on demande à Netbox de générer la configuration pour un équipement (disons, notre `pa01_lf1_00`), voici ce qu'il se passe :

    * Il va chercher toutes les infos sur ce leaf : son nom, ses interfaces, ses IPs, ses connexions, son ASN, etc.
    * Il prend le template Jinja2 qu'on a associé au rôle "leaf".
@@ -252,11 +252,11 @@ Maintenant qu'on a notre inventaire réseau au top dans Netbox, comment on dit
 > [!TIP]
 > Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates)

-### De Netbox au Lab : On Regarde et On Fait à la Main pour l'Instant 🖥️➡️💻
+### De Netbox au lab : on fait à la main pour l'instant

 Maintenant qu'on sait comment Netbox génère les configurations, voyons comment on les utilise dans notre lab Containerlab.

-1. **On Jette un Œil à la Configuration dans Netbox 👀** Pour voir la configuration générée par Netbox pour un équipement, c'est simple :
+1. **On jette un œil à la configuration dans Netbox.** Pour voir la configuration générée par Netbox pour un équipement, c'est simple :

    * Dans l'interface de Netbox, on va dans **Devices**.
    * On clique sur l'équipement qui nous intéresse (par exemple, un de nos leafs).
@@ -264,27 +264,27 @@ Maintenant qu'on sait comment Netbox génère les configurations, voyons comment

    ![PA01 Leaf Configuration](<Render Config.png>)

-2. **La Touche Humaine dans Containerlab 🖐️** Pour l'instant, on n'a pas de script qui envoie automatiquement ces configurations à nos équipements dans Containerlab. Donc, on va faire à l'ancienne (mais c'est pour la démo !) :
+2. **La touche humaine dans Containerlab.** Pour l'instant, on n'a pas de script qui envoie automatiquement ces configurations à nos équipements dans Containerlab. Donc, on va faire à l'ancienne (mais c'est bien suffisant pour la démo) :

    * On se connecte à chaque équipement cEOS de notre lab via SSH (par exemple, en utilisant l'extension VSCode Containerlab comme on l'a vu dans le [cookbook](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-deploy-configuration)).
    * On copie la configuration qu'on a visualisée dans Netbox (l'onglet **Render Config**).
    * Et on la colle dans l'interface de ligne de commande de l'équipement cEOS (en mode configuration, bien sûr !).

-3. **Et Après ? Les Perspectives d'Évolution 🚀** Bien sûr, cette étape de copier-coller, c'est pas le top de l'automatisation ! Mais c'est une première étape pour voir comment Netbox peut être notre cerveau central. Dans le futur, on pourrait imaginer des outils comme Ansible ou NAPALM qui se connecteraient à Netbox, récupéreraient ces configurations générées et les appliqueraient automatiquement à nos équipements. C'est une piste pour de prochaines aventures dans l'automatisation ! 😉
+3. **Et après ?** Cette étape de copier-coller n'est pas le sommet de l'automatisation, mais c'est une première étape pour voir comment Netbox peut devenir notre cerveau central. Plus tard, des outils comme Ansible ou NAPALM pourraient se connecter à Netbox, récupérer ces configurations générées et les appliquer automatiquement à nos équipements.

-## Validation de la communication ✅
+## Validation de la communication

-### Ping ⚽
+### Ping

-Dans le cookbook, nous avons fait le choix de configurer 2 clients chacun dans 2 batiments différent, ce qui nous permet de réalisé un **ping**, pour rappel :  
+Dans le cookbook, nous avons fait le choix de configurer 2 clients chacun dans 2 bâtiments différents, ce qui nous permet de réaliser un **ping**, pour rappel :

-1. 🟠 Orange:
-    * Sous Réseau: 10.0.0.0/24
-    * Hosts:
-      * PA1: 10.0.0.10
-      * PA3: 10.0.0.20
+1. Orange :
+    * Sous-réseau : 10.0.0.0/24
+    * Hosts :
+      * PA1 : 10.0.0.10
+      * PA3 : 10.0.0.20

-2. 🟣 Purple
+2. Purple
    * Sous Réseau: 10.0.1.0/24
    * Hosts:
      * PA2: 10.0.1.10
@@ -316,11 +316,9 @@ Et ensuite, via VSCode, il est possible de lancer wireshark directement :

 ![Capture Wireshark](wireshark_eth2_leaf1.png)

-## Conclusion ✨
+## Conclusion

-Pour résumer notre parcours, on a vu comment Netbox devient notre super allié 🥇 pour automatiser le réseau VXLAN.  
-La clé, c'est de partir d'**une base standardisée** 📐, c'est ce qui permet à Netbox de générer nos configurations presque tout seul grâce aux templates Jinja2.
+Netbox devient un allié solide pour automatiser le réseau VXLAN.
+La clé, c'est de partir d'une base standardisée : c'est ce qui permet à Netbox de générer nos configurations presque tout seul grâce aux templates Jinja2.

-Même si, pour l'instant, on fait encore un peu de copier-coller 🖐️, le potentiel est immense ! Avoir toutes nos infos centralisées dans Netbox, c'est la première étape pour vraiment simplifier la gestion de notre réseau et ouvrir la porte à une automatisation complète. La standardisation n'est pas une contrainte, mais le tremplin vers plus d'efficacité. ✅
-
-Ce n'est que le début ! Pensez à la suite : déployer ces configs automatiquement, gérer des réseaux plus complexes... L'automatisation est là, accessible, prête à vous faire gagner un temps précieux. 🚀💪
+On fait encore un peu de copier-coller sur la dernière étape, mais centraliser toutes nos infos dans Netbox est la première étape pour simplifier la gestion de notre réseau et ouvrir la porte à une automatisation complète. La suite : déployer ces configurations automatiquement et gérer des réseaux plus complexes.
--- a/content/netlab/first_lab/_index.en.md
+++ b/content/netlab/first_lab/_index.en.md
@@ -8,11 +8,11 @@ cascade:
  type: docs
 ---

-## Introduction 📚
+## Introduction

-In this article, we're going to explore how to set up our very first Containerlab netlab using **DevPod**.  
-We'll focus on using a cloud provider, in this case **AWS**, to host our project.  
-Why the **Cloud**? Because network labs can consume a huge amount of resources, and we need to be able to deploy, stop, and destroy them quickly, both for performance and cost efficiency. 💡💰
+In this article, we're going to set up our very first Containerlab netlab using **DevPod**.
+We'll use a cloud provider, in this case **AWS**, to host our project.
+Why the cloud? Because network labs can consume a huge amount of resources, and we need to deploy, stop, and destroy them quickly, both for performance and cost.

 We'll achieve this by combining:

@@ -20,20 +20,17 @@ We'll achieve this by combining:
 - **DevContainer**
 - **Containerlab**

-In addition, we'll use a simple topology that you can find on my [GitHub repository](https://github.com/darnodo/VXLAN-EVPN). Our main goal is to deploy this lab on AWS with DevPod.  
-Let's get to it! 🚀😊
+We'll use a simple topology that you can find on my [GitHub repository](https://github.com/darnodo/VXLAN-EVPN). Our goal is to deploy this lab on AWS with DevPod.

-## Prerequisites 🔧
+## Prerequisites

-Before starting, a few important steps need to be taken:
+Before starting, a few things need to be in place:

-1. **AWS Environment Authorization**:  
-   Make sure DevPod is authorized to access your AWS environment. For a detailed guide on configuring DevPod with AWS, check out my article on this [topic](../../documentation/devpod/). 🔑
+1. AWS environment authorization: make sure DevPod is authorized to access your AWS environment. For a detailed guide on configuring DevPod with AWS, check out my article on this [topic](../../documentation/devpod/).

-2. **Containerlab Topology**:  
-   We need a topology file that Containerlab can understand. In our case, we'll create a simple VXLAN topology. 🗺️
+2. Containerlab topology: we need a topology file that Containerlab can understand. In our case, we'll create a simple VXLAN topology.

-## Containerlab Topology 🔄
+## Containerlab topology

 Our lab will simulate a VXLAN topology consisting of:

@@ -82,7 +79,7 @@ topology:
    - endpoints: ["leaf2:eth2", "host2:eth1"]
 ```

-### Breaking Down the Topology 🧐
+### Breaking down the topology

 1. **Name and Structure**:
   - `name: vxlan-evpn-irb` – This is the name of the lab.
@@ -108,18 +105,17 @@ topology:
     - `leaf1:eth2` ↔ `host1:eth1`
     - `leaf2:eth2` ↔ `host2:eth1`

-This topology represents a typical spine-leaf architecture, common in datacenters to enable Layer 2 and Layer 3 connectivity with VXLAN EVPN configurations. 🔗💻
+This topology is a typical spine-leaf architecture, common in datacenters to enable Layer 2 and Layer 3 connectivity with VXLAN EVPN configurations.

-## Deploying the Lab 🛠️
+## Deploying the lab

 We'll deploy the lab with **DevPod** in two ways:

-### 1. Using the Repository 📥
+### 1. Using the repository

-1. **Validate the AWS Provider Configuration**:  
-   Make sure your AWS provider is properly configured. More details [here](../../documentation/devpod/). ✅
+1. Validate the AWS provider configuration: make sure your AWS provider is properly configured. More details [here](../../documentation/devpod/).

-2. **Create a Workspace**:  
+2. Create a workspace:
   - Go to the **Workspace** tab and click **Create Workspace**.
   - Specify the **Workspace source**: use the [GitHub repository](https://github.com/darnodo/VXLAN-EVPN).
   - Select **AWS** as the provider.
@@ -128,40 +124,33 @@ We'll deploy the lab with **DevPod** in two ways:

   ![DevPod Configuration](devpod_configuration.en.png#center)

-### 2. Using a Local Folder 🗂️
+### 2. Using a local folder

-If you prefer to use your local repository:
-
- The only difference is in the **Workspace source**.
- Simply point it to your local repository.
+If you prefer to use your local repository, the only difference is in the **Workspace source**: simply point it to your local repository.

   ![DevPod Configuration - Local](devpod_configuration_local.en.png#center)

-## Starting the Lab 🎬
+## Starting the lab

-> [!WARNING] cEOS Images  
-> The lab uses **cEOS image v4.32.0.1F**.  
-> To download this image, head over to the [Arista download page](https://www.arista.com/en/support/software-download). ⚠️
+> [!WARNING] cEOS images
+> The lab uses **cEOS image v4.32.0.1F**.
+> To download this image, head over to the [Arista download page](https://www.arista.com/en/support/software-download).

-1. **Import the cEOS Image**:  
-   Save the cEOS image into your `network_images` folder by dragging and dropping it into VSCode.  
-   Import the image using the following command:
+1. Import the cEOS image: save the cEOS image into your `network_images` folder by dragging and dropping it into VSCode. Import the image using the following command:

   ```bash
   docker import network_images/cEOS64-lab-4.32.0.1F.tar.xz ceos:4.32.0.1F
   ```

-2. **Deploy the Lab**:  
-   Deploy the lab using Containerlab:
+2. Deploy the lab using Containerlab:

   ```bash
   sudo containerlab deploy -t lab_vxlan.yml
   ```

-   Follow the CLI instructions to configure your devices. For detailed configuration steps, check out [this guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration). 🔧🖥️
+   Follow the CLI instructions to configure your devices. For detailed configuration steps, check out [this guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration).

-3. **Visualize the Architecture**:  
-   Check the deployed topology using Containerlab's graphical view:
+3. Visualize the architecture: check the deployed topology using Containerlab's graphical view.

   ```bash
   containerlab graph -t lab_vxlan.yml
@@ -171,13 +160,13 @@ If you prefer to use your local repository:

   ![Graph View](Graph_view.en.png#center)

-## Using EdgeShark 🦈
+## Using EdgeShark

-EdgeShark is a web tool that lets you capture packets from your lab environment. It forwards lab captures to Wireshark running locally. 📡🔍
+EdgeShark is a web tool that lets you capture packets from your lab environment. It forwards lab captures to Wireshark running locally.

 For more information, check out the [EdgeShark getting started guide](https://edgeshark.siemens.io/#/getting-started?id=optional-capture-plugin).

-### Configuring EdgeShark in the DevContainer 🐳
+### Configuring EdgeShark in the DevContainer

 In the **DevContainer** configuration, the following `postCreateCommand` was added:

@@ -185,9 +174,9 @@ In the **DevContainer** configuration, the following `postCreateCommand` was add
 sudo mkdir -p /opt/edgeshark && sudo curl -sL https://github.com/siemens/edgeshark/raw/main/deployments/wget/docker-compose.yaml -o /opt/edgeshark/docker-compose.yaml
 ```

-This command downloads a Docker Compose file to make it easier to use EdgeShark. 🚀
+This command downloads a Docker Compose file to make it easier to use EdgeShark.

-### Launching EdgeShark ⚡
+### Launching EdgeShark

 To start EdgeShark, run:

@@ -198,22 +187,13 @@ DOCKER_DEFAULT_PLATFORM= docker compose up -d

 Access EdgeShark via [localhost:5001](http://localhost:5001).

- **EdgeShark View**:  
+- EdgeShark view:
  ![EdgeShark View](edgeshark.en.png#center)

- **Integration with Wireshark**:  
-  By clicking the Wireshark icon in EdgeShark, you can launch Wireshark locally.  
-  ![EdgeShark Interface](edgeshark_interface.en.png#center)  
+- Integration with Wireshark: clicking the Wireshark icon in EdgeShark launches Wireshark locally.
+  ![EdgeShark Interface](edgeshark_interface.en.png#center)
  ![EdgeShark and Wireshark](edge_wireshark.en.png#center)

-## Conclusion 🎉
+## Conclusion

-In this article, we walked through the steps to deploy a VXLAN EVPN lab using Containerlab, DevPod, and AWS. We covered the following key points:
-
- **Setting up the prerequisites** for AWS and Containerlab. 🔑
- **Creating a detailed topology file** for a spine-leaf architecture. 🗺️
- **Deploying the lab** using both a GitHub repository and a local folder. 📥🗂️
- **Starting the lab** with Docker and Containerlab. 🚀🐳
- **Using EdgeShark** to capture packets and integrate Wireshark for in-depth analysis. 🦈🔍
-
-By following these steps, you'll be able to easily deploy and manage a scalable network lab environment in the cloud. Happy networking, and enjoy your lab adventures! 😄🎊
+That covers the full setup: prerequisites, the VXLAN topology, deploying the lab with DevPod on AWS, and capturing traffic with EdgeShark and Wireshark. From here you have a working spine-leaf lab you can tear down and redeploy whenever you need it.
--- a/content/netlab/first_lab/_index.fr.md
+++ b/content/netlab/first_lab/_index.fr.md
@@ -8,11 +8,11 @@ cascade:
  type: docs
 ---

-## Introduction 📚
+## Introduction

-Dans cet article, nous allons explorer comment installer notre tout premier netlab Containerlab en utilisant **DevPod**.  
-Nous nous concentrerons sur l'utilisation d'un fournisseur cloud, en l'occurrence **AWS**, pour héberger notre projet.  
-Pourquoi le **Cloud** ? Parce que les labs réseau peuvent consommer énormément de ressources, et nous avons besoin de pouvoir les déployer, les arrêter et les détruire rapidement, tant pour la performance que pour l'efficacité financière. 💡💰
+Dans cet article, nous allons installer notre tout premier netlab Containerlab en utilisant **DevPod**.
+Nous utiliserons un fournisseur cloud, en l'occurrence **AWS**, pour héberger notre projet.
+Pourquoi le cloud ? Parce que les labs réseau peuvent consommer énormément de ressources, et nous avons besoin de pouvoir les déployer, les arrêter et les détruire rapidement, tant pour la performance que pour le coût.

 Nous y parviendrons en combinant :

@@ -20,20 +20,17 @@ Nous y parviendrons en combinant :
 - **DevContainer**
 - **Containerlab**

-De plus, nous utiliserons une topologie simple que vous pouvez retrouver sur mon [dépôt GitHub](https://github.com/darnodo/VXLAN-EVPN). Notre objectif principal est de déployer ce lab sur AWS avec DevPod.  
-Allons-y, c'est parti ! 🚀😊
+Nous utiliserons une topologie simple que vous pouvez retrouver sur mon [dépôt GitHub](https://github.com/darnodo/VXLAN-EVPN). Notre objectif est de déployer ce lab sur AWS avec DevPod.

-## Prérequis 🔧
+## Prérequis

-Avant de commencer, quelques étapes importantes sont à réaliser :
+Avant de commencer, quelques éléments doivent être en place :

-1. **Autorisation de l'environnement AWS** :  
-   Assurez-vous que DevPod est autorisé à accéder à votre environnement AWS. Pour un guide détaillé sur la configuration de DevPod avec AWS, consultez mon article sur ce [sujet](../../documentation/devpod/). 🔑
+1. Autorisation de l'environnement AWS : assurez-vous que DevPod est autorisé à accéder à votre environnement AWS. Pour un guide détaillé sur la configuration de DevPod avec AWS, consultez mon article sur ce [sujet](../../documentation/devpod/).

-2. **Topologie Containerlab** :  
-   Nous avons besoin d'un fichier de topologie compréhensible par Containerlab. Dans notre cas, nous créons une topologie VXLAN simple. 🗺️
+2. Topologie Containerlab : nous avons besoin d'un fichier de topologie compréhensible par Containerlab. Dans notre cas, nous créons une topologie VXLAN simple.

-## Topologie Containerlab 🔄
+## Topologie Containerlab

 Notre lab simulera une topologie VXLAN comprenant :

@@ -82,7 +79,7 @@ topology:
    - endpoints: ["leaf2:eth2", "host2:eth1"]
 ```

-### Décryptage de la Topologie 🧐
+### Décryptage de la topologie

 1. **Nom et Structure** :
   - `name: vxlan-evpn-irb` – C'est le nom du lab.
@@ -108,18 +105,17 @@ topology:
     - `leaf1:eth2` ↔ `host1:eth1`
     - `leaf2:eth2` ↔ `host2:eth1`

-Cette topologie représente une architecture spine-leaf typique, courante dans les datacenters pour permettre une connectivité en couche 2 et en couche 3 avec des configurations VXLAN EVPN. 🔗💻
+Cette topologie est une architecture spine-leaf typique, courante dans les datacenters pour permettre une connectivité en couche 2 et en couche 3 avec des configurations VXLAN EVPN.

-## Déployer le Lab 🛠️
+## Déployer le lab

 Nous allons déployer le lab avec **DevPod** de deux manières :

-### 1. En Utilisant le Dépôt 📥
+### 1. En utilisant le dépôt

-1. **Valider la configuration du fournisseur AWS** :  
-   Assurez-vous que votre fournisseur AWS est correctement configuré. Plus de détails [ici](../../documentation/devpod/). ✅
+1. Valider la configuration du fournisseur AWS : assurez-vous que votre fournisseur AWS est correctement configuré. Plus de détails [ici](../../documentation/devpod/).

-2. **Créer un Workspace** :  
+2. Créer un workspace :
   - Rendez-vous dans l'onglet **Workspace** et cliquez sur **Create Workspace**.
   - Indiquez la **source du Workspace** : utilisez le [dépôt GitHub](https://github.com/darnodo/VXLAN-EVPN).
   - Sélectionnez **AWS** comme fournisseur.
@@ -128,40 +124,33 @@ Nous allons déployer le lab avec **DevPod** de deux manières :

   ![Configuration DevPod](devpod_configuration.fr.png#center)

-### 2. En Utilisant un Dossier Local 🗂️
+### 2. En utilisant un dossier local

-Si vous préférez utiliser votre dépôt local :
-
- La seule différence se trouve dans la **source du Workspace**.
- Il vous suffit de le pointer vers votre dépôt local.
+Si vous préférez utiliser votre dépôt local, la seule différence se trouve dans la **source du Workspace** : il suffit de le pointer vers votre dépôt local.

   ![Configuration DevPod - Local](devpod_configuration_local.fr.png#center)

-## Démarrer le Lab 🎬
+## Démarrer le lab

-> [!WARNING] Images cEOS  
-> Le lab utilise l'**image cEOS v4.32.0.1F**.  
-> Pour télécharger cette image, rendez-vous sur la [page de téléchargement Arista](https://www.arista.com/en/support/software-download). ⚠️
+> [!WARNING] Images cEOS
+> Le lab utilise l'**image cEOS v4.32.0.1F**.
+> Pour télécharger cette image, rendez-vous sur la [page de téléchargement Arista](https://www.arista.com/en/support/software-download).

-1. **Importer l'image cEOS** :  
-   Enregistrez l'image cEOS dans votre dossier `network_images` en la glissant-déposant dans VSCode.  
-   Importez l'image en utilisant la commande suivante :
+1. Importer l'image cEOS : enregistrez l'image cEOS dans votre dossier `network_images` en la glissant-déposant dans VSCode. Importez l'image en utilisant la commande suivante :

   ```bash
   docker import network_images/cEOS64-lab-4.32.0.1F.tar.xz ceos:4.32.0.1F
   ```

-2. **Déployer le Lab** :  
-   Déployez le lab en utilisant Containerlab :
+2. Déployer le lab en utilisant Containerlab :

   ```bash
   sudo containerlab deploy -t lab_vxlan.yml
   ```

-   Suivez les instructions du CLI pour configurer vos périphériques. Pour des étapes de configuration détaillées, consultez [ce guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration). 🔧🖥️
+   Suivez les instructions du CLI pour configurer vos périphériques. Pour des étapes de configuration détaillées, consultez [ce guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration).

-3. **Visualiser l'Architecture** :  
-   Vérifiez la topologie déployée grâce à la vue graphique de Containerlab :
+3. Visualiser l'architecture : vérifiez la topologie déployée grâce à la vue graphique de Containerlab.

   ```bash
   containerlab graph -t lab_vxlan.yml
@@ -171,13 +160,13 @@ Si vous préférez utiliser votre dépôt local :

   ![Vue Graphique](Graph_view.fr.png#center)

-## Utiliser EdgeShark 🦈
+## Utiliser EdgeShark

-EdgeShark est un outil web qui permet de capturer des paquets depuis votre environnement de lab. Il redirige les captures du lab vers Wireshark exécuté localement. 📡🔍
+EdgeShark est un outil web qui permet de capturer des paquets depuis votre environnement de lab. Il redirige les captures du lab vers Wireshark exécuté localement.

 Pour plus d'informations, consultez le [guide de démarrage d'EdgeShark](https://edgeshark.siemens.io/#/getting-started?id=optional-capture-plugin).

-### Configuration d'EdgeShark dans le DevContainer 🐳
+### Configuration d'EdgeShark dans le DevContainer

 Dans la configuration du **DevContainer**, la commande `postCreateCommand` suivante a été ajoutée :

@@ -185,9 +174,9 @@ Dans la configuration du **DevContainer**, la commande `postCreateCommand` suiva
 sudo mkdir -p /opt/edgeshark && sudo curl -sL https://github.com/siemens/edgeshark/raw/main/deployments/wget/docker-compose.yaml -o /opt/edgeshark/docker-compose.yaml
 ```

-Cette commande télécharge un fichier Docker Compose pour faciliter l'utilisation d'EdgeShark. 🚀
+Cette commande télécharge un fichier Docker Compose pour faciliter l'utilisation d'EdgeShark.

-### Lancer EdgeShark ⚡
+### Lancer EdgeShark

 Pour démarrer EdgeShark, exécutez :

@@ -198,22 +187,13 @@ DOCKER_DEFAULT_PLATFORM= docker compose up -d

 Accédez à EdgeShark via [localhost:5001](http://localhost:5001).

- **Vue d'EdgeShark** :  
+- Vue d'EdgeShark :
  ![Vue d'EdgeShark](edgeshark.fr.png#center)

- **Intégration avec Wireshark** :  
-  En cliquant sur l'icône Wireshark dans EdgeShark, vous pouvez lancer Wireshark localement.  
-  ![Interface EdgeShark](edgeshark_interface.fr.png#center)  
+- Intégration avec Wireshark : cliquer sur l'icône Wireshark dans EdgeShark lance Wireshark localement.
+  ![Interface EdgeShark](edgeshark_interface.fr.png#center)
  ![EdgeShark et Wireshark](edge_wireshark.fr.png#center)

-## Conclusion 🎉
+## Conclusion

-Dans cet article, nous avons parcouru les étapes pour déployer un lab VXLAN EVPN en utilisant Containerlab, DevPod et AWS. Nous avons abordé les points clés suivants :
-
- **Mise en place des prérequis** pour AWS et Containerlab. 🔑
- **Création d'un fichier de topologie détaillé** pour une architecture spine-leaf. 🗺️
- **Déploiement du lab** en utilisant à la fois un dépôt GitHub et un dossier local. 📥🗂️
- **Démarrage du lab** avec Docker et Containerlab. 🚀🐳
- **Utilisation d'EdgeShark** pour capturer des paquets et intégrer Wireshark pour une analyse approfondie. 🦈🔍
-
-En suivant ces étapes, vous pourrez déployer et gérer facilement un environnement de lab réseau évolutif dans le cloud. Bon networking et profitez bien de vos aventures en lab ! 😄🎊
+Voilà pour l'ensemble de la mise en place : prérequis, topologie VXLAN, déploiement du lab avec DevPod sur AWS, et capture de trafic avec EdgeShark et Wireshark. Vous disposez maintenant d'un lab spine-leaf fonctionnel, que vous pouvez détruire et redéployer selon vos besoins.
--- a/content/netlab/netlab.en.md
+++ b/content/netlab/netlab.en.md
@@ -7,7 +7,7 @@ cascade:

 ## Introduction

-📡 In a world where computer networks play an ever-growing role in our daily lives, understanding the principles and logic that drive them is becoming increasingly essential.
+Computer networks are everywhere in daily life now, and understanding how they work matters more than it used to.

 Virtual network labs (also known as "NetLab" or "Virtual Network Lab") are an ideal approach to teaching these concepts, allowing us to simulate complex network environments and experiment risk-free.

@@ -15,21 +15,21 @@ I want to share with you how my "NetLabs" work, which will regularly be linked t

 As part of NetLab, these will mainly be deployed using the ContainerLab tool. For more complex architectures, we'll use GNS3.

-## What is ContainerLab? 🛠️
+## What is ContainerLab?

-ContainerLab is a powerful open-source tool that enables the creation of complete virtual network labs. With it, you can simulate a multitude of complex network architectures, with equipment such as routers, switches, servers, and other network devices.
+ContainerLab is an open-source tool for building complete virtual network labs. With it, you can simulate complex network architectures, with equipment such as routers, switches, servers, and other network devices.

 This platform offers great flexibility in designing exercises, making it possible to cover various topics such as learning network protocols, security, or device configuration. Users can therefore focus on analyzing and solving problems without worrying about the underlying technical details.

 Installing ContainerLab won't be covered here, but all the information is available on the official website [here](https://containerlab.dev/install/).

-## What is GNS3? 💻
+## What is GNS3?

 GNS3, or Graphical Network Simulator-3, is open-source software mainly used for the **simulation** and **emulation** of computer networks. It allows network engineers, students, and professionals to design, test, and troubleshoot complex networks in a virtual environment before deploying them in the real world. GNS3 is particularly appreciated for its ability to integrate various network hardware and software, such as Cisco routers and switches, as well as virtual machines, to create realistic network topologies.

 As before, installing GNS3 won't be covered here; for more information, the documentation is available [here](https://docs.gns3.com/docs/).

-## GNS3 vs ContainerLab ⚔️
+## GNS3 vs ContainerLab

 GNS3 and ContainerLab are two powerful tools for network simulation and emulation, but they differ in their approach, features, and main use cases. Here's a quick comparison between the two:

@@ -37,31 +37,31 @@ GNS3 and ContainerLab are two powerful tools for network simulation and emulatio

 **Advantages:**

-1. **Intuitive Graphical Interface:** GNS3 offers a user-friendly graphical interface that lets users drag and drop components to build network topologies.
-2. **Multivendor Support:** It supports a wide range of network hardware and software, including Cisco routers and switches, as well as virtual machines.
-3. **Flexibility:** GNS3 can be used on Windows, macOS, and Linux, and it integrates well with other tools like Wireshark for traffic analysis.
-4. **Active Community:** A large community of users and developers provides extensive support and a wealth of online resources.
+1. Intuitive graphical interface: GNS3 offers a user-friendly graphical interface that lets users drag and drop components to build network topologies.
+2. Multivendor support: it supports a wide range of network hardware and software, including Cisco routers and switches, as well as virtual machines.
+3. Flexibility: GNS3 can be used on Windows, macOS, and Linux, and it integrates well with other tools like Wireshark for traffic analysis.
+4. Active community: a large community of users and developers provides support and online resources.

 **Drawbacks:**

-1. **System Resources:** GNS3 can be resource-intensive, especially when emulating complex devices or large topologies.
-2. **Configuration Complexity:** Initial setup can be complex, especially for new users.
+1. System resources: GNS3 can be resource-intensive, especially when emulating complex devices or large topologies.
+2. Configuration complexity: initial setup can be complex, especially for new users.

 ### ContainerLab

 **Advantages:**

-1. **Lightweight and Performant:** ContainerLab uses containers to emulate network devices, making it lighter and more performant than VM-based solutions.
-2. **Automation and DevOps:** It integrates well with DevOps and automation tools like Ansible, making automated deployment and network management easier.
-3. **Simplified Configuration:** Topologies are defined via YAML files, making configuration simpler and scriptable.
-4. **Support for Modern Technologies:** It supports modern technologies like Docker and Kubernetes, offering greater flexibility for cloud-native environments.
+1. Lightweight and performant: ContainerLab uses containers to emulate network devices, making it lighter and faster than VM-based solutions.
+2. Automation and DevOps: it integrates well with DevOps and automation tools like Ansible, making automated deployment and network management easier.
+3. Simplified configuration: topologies are defined via YAML files, making configuration simpler and scriptable.
+4. Support for modern technologies: it supports Docker and Kubernetes, offering more flexibility for cloud-native environments.

 **Drawbacks:**

-1. **Less Multivendor Support:** While ContainerLab supports several types of network containers, it may not have the same level of multivendor support as GNS3.
-2. **Learning Curve:** For those unfamiliar with containerization concepts, the learning curve can be steeper.
+1. Less multivendor support: while ContainerLab supports several types of network containers, it may not match GNS3's level of multivendor support.
+2. Learning curve: for those unfamiliar with containerization concepts, the learning curve can be steeper.

-## Conclusion 📊
+## Conclusion

 **GNS3** is ideal for those looking for an intuitive graphical interface and broad device support, particularly useful for students and traditional network engineers. **ContainerLab**, on the other hand, is better suited to modern environments and DevOps practices, offering a lightweight and scriptable solution for network simulation.

--- a/content/netlab/netlab.fr.md
+++ b/content/netlab/netlab.fr.md
@@ -7,7 +7,7 @@ cascade:

 ## Introduction

-📡 Dans un monde où les réseaux informatiques jouent un rôle croissant dans notre vie quotidienne, la compréhension des principes et de la logique qui les animent devient de plus en plus essentielle.
+Les réseaux informatiques sont partout dans notre vie quotidienne, et comprendre les principes qui les font fonctionner compte plus qu'avant.

 Les laboratoires réseau virtuels (en anglais "NetLab" ou "Virtual Network Lab") constituent une approche idéale pour enseigner ces concepts, nous permettant de simuler des environnements réseaux complexes et d'expérimenter sans risques.

@@ -15,21 +15,21 @@ Je souhaite partager avec vous le fonctionnement de mes "NetLabs", qui seront r

 Dans le cadre des NetLab, ceux-ci seront principalement déployés via l'outil ContainerLab. Pour les architectures plus complexes, nous utiliserons GNS3.

-## Qu'est-ce que ContainerLab ? 🛠️
+## Qu'est-ce que ContainerLab ?

-ContainerLab est un outil open-source puissant qui permet la création de laboratoires réseau virtuels complets. Grâce à son utilisation, on peut simuler une multitude d'architectures réseaux complexes, avec des équipements tels que les routeurs, commutateurs, serveurs et autres appareils réseau.
+ContainerLab est un outil open-source qui permet de créer des laboratoires réseau virtuels complets. On peut simuler des architectures réseaux complexes, avec des équipements tels que les routeurs, commutateurs, serveurs et autres appareils réseau.

 Cette plateforme offre une grande flexibilité dans la conception des exercices, permettant l'abordage de différents sujets tels que l'apprentissage de protocoles réseau, de sécurité ou encore de configurations d'équipements. Les utilisateurs peuvent ainsi se concentrer sur l'analyse et la résolution de problèmes sans s'inquiéter des détails techniques sous-jacents.

 L'installation de ContainerLab ne sera pas présentée ici, mais toutes les informations sont présentes sur le site officiel [ici](https://containerlab.dev/install/).

-## Qu'est-ce que GNS3 ? 💻
+## Qu'est-ce que GNS3 ?

 GNS3, ou Graphical Network Simulator-3, est un logiciel open-source utilisé principalement pour la **simulation** et l'**émulation** de réseaux informatiques. Il permet aux ingénieurs réseaux, aux étudiants et aux professionnels de concevoir, tester et dépanner des réseaux complexes dans un environnement virtuel avant de les déployer dans le monde réel. GNS3 est particulièrement apprécié pour sa capacité à intégrer divers matériels et logiciels réseau, tels que les routeurs et commutateurs Cisco, ainsi que des machines virtuelles pour créer des topologies réseau réalistes.

 Comme précédemment, l'installation de GNS3 ne sera pas évoquée, pour plus d'information, la documentation est présente [ici](https://docs.gns3.com/docs/).

-## GNS3 vs ContainerLab ⚔️
+## GNS3 vs ContainerLab

 GNS3 et ContainerLab sont deux outils puissants pour la simulation et l'émulation de réseaux, mais ils diffèrent dans leur approche, leurs fonctionnalités et leurs cas d'utilisation principaux. Voici un rapide comparatif entre les deux :

@@ -37,31 +37,31 @@ GNS3 et ContainerLab sont deux outils puissants pour la simulation et l'émulati

 **Avantages :**

-1. **Interface Graphique Intuitive :** GNS3 offre une interface graphique conviviale permet aux utilisateurs de glisser-déposer des composants pour créer des topologies réseau.
-2. **Support Multivendor :** Il supporte une large gamme de matériels et logiciels réseau, y compris les routeurs et commutateurs Cisco, ainsi que des machines virtuelles.
-3. **Flexibilité :** GNS3 peut être utilisé sur Windows, macOS et Linux, et il intègre bien d'autres outils comme Wireshark pour l'analyse de trafic.
-4. **Communauté Active :** Une grande communauté d'utilisateurs et de développeurs offre un vaste support et une multitude de ressources en ligne.
+1. Interface graphique intuitive : GNS3 offre une interface graphique conviviale qui permet aux utilisateurs de glisser-déposer des composants pour créer des topologies réseau.
+2. Support multivendor : il supporte une large gamme de matériels et logiciels réseau, y compris les routeurs et commutateurs Cisco, ainsi que des machines virtuelles.
+3. Flexibilité : GNS3 peut être utilisé sur Windows, macOS et Linux, et il s'intègre bien avec d'autres outils comme Wireshark pour l'analyse de trafic.
+4. Communauté active : une grande communauté d'utilisateurs et de développeurs offre du support et des ressources en ligne.

 **Inconvénients :**

-1. **Ressources Systèmes :** GNS3 peut être gourmand en ressources, surtout lorsqu'il émule des dispositifs complexes ou de grandes topologies.
-2. **Complexité de Configuration :** La configuration initiale peut être complexe, surtout pour les nouveaux utilisateurs.
+1. Ressources systèmes : GNS3 peut être gourmand en ressources, surtout lorsqu'il émule des dispositifs complexes ou de grandes topologies.
+2. Complexité de configuration : la configuration initiale peut être complexe, surtout pour les nouveaux utilisateurs.

 ### ContainerLab

 **Avantages :**

-1. **Légèreté et Performance :** ContainerLab utilise des conteneurs pour émuler les dispositifs réseau, ce qui le rend plus léger et performant que les solutions basées sur des machines virtuelles.
-2. **Automatisation et DevOps :** Il s'intègre bien avec les outils DevOps et d'automatisation comme Ansible, facilitant ainsi le déploiement automatisé et la gestion de réseaux.
-3. **Configuration Simplifiée :** Les topologies sont définies via des fichiers YAML, rendant la configuration plus simple et scriptable.
-4. **Support de Technologies Modernes :** Il supporte des technologies modernes comme Docker et Kubernetes, offrant ainsi une plus grande flexibilité pour les environnements cloud-native.
+1. Légèreté et performance : ContainerLab utilise des conteneurs pour émuler les dispositifs réseau, ce qui le rend plus léger et plus rapide que les solutions basées sur des machines virtuelles.
+2. Automatisation et DevOps : il s'intègre bien avec les outils DevOps et d'automatisation comme Ansible, ce qui facilite le déploiement automatisé et la gestion de réseaux.
+3. Configuration simplifiée : les topologies sont définies via des fichiers YAML, ce qui rend la configuration plus simple et scriptable.
+4. Support de technologies modernes : il supporte Docker et Kubernetes, offrant plus de flexibilité pour les environnements cloud-native.

 **Inconvénients :**

-1. **Moins de Support Multivendor :** Bien que ContainerLab supporte plusieurs types de conteneurs réseau, il peut ne pas avoir le même niveau de support multivendor que GNS3.
-2. **Courbe d'Apprentissage :** Pour ceux qui ne sont pas familiers avec les concepts de conteneurisation, la courbe d'apprentissage peut être plus raide.
+1. Moins de support multivendor : bien que ContainerLab supporte plusieurs types de conteneurs réseau, il n'a pas toujours le même niveau de support multivendor que GNS3.
+2. Courbe d'apprentissage : pour ceux qui ne sont pas familiers avec les concepts de conteneurisation, la courbe d'apprentissage peut être plus raide.

-## Conclusion 📊
+## Conclusion

 **GNS3** est idéal pour ceux qui recherchent une interface graphique intuitive et un large support de dispositifs réseau, particulièrement utile pour les étudiants et les ingénieurs réseau traditionnels. **ContainerLab**, en revanche, est plus adapté aux environnements modernes et aux pratiques DevOps, offrant une solution légère et scriptable pour la simulation de réseaux.

--- a/content/netlab/sécurité/stepca.en.md
+++ b/content/netlab/sécurité/stepca.en.md
@@ -6,45 +6,38 @@ cascade:
  type: docs
 ---

-## 🔗 Sources
+## Sources

- [📖 Official Documentation](https://smallstep.com/docs/tutorials/)
- [🛠️ Step-CA as a systemd Service](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/)
- [🔐 Certificate Management with OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/)
+- [Official documentation](https://smallstep.com/docs/tutorials/)
+- [Step-CA as a systemd service](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/)
+- [Certificate management with OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/)

-## 🤖 About Step-CA
+## About Step-CA

-Step-CA is a clever toolset developed by Smallstep, a company specializing in secure identity management and certificate automation. 🚀  
-Its mission? To simplify setting up and managing your own certificate authorities (CAs) with ease and security!
+Step-CA is a toolset developed by Smallstep, a company specializing in secure identity management and certificate automation.
+Its mission is to simplify setting up and managing your own certificate authorities (CAs).

-### Key Features
+### Key features

-1. **Certificate Authority Management** 🔑  
-   Easily configure and manage your own CAs. Create root and intermediate CAs, issue certificates, and handle revocations like a pro.
+1. Certificate authority management: easily configure and manage your own CAs. Create root and intermediate CAs, issue certificates, and handle revocations.

-2. **Secure Key Management** 🛡️  
-   Follows best practices for securely storing and managing keys, ensuring your cryptographic keys stay protected from unauthorized access.
+2. Secure key management: follows best practices for securely storing and managing keys, so your cryptographic keys stay protected from unauthorized access.

-3. **Automation and Scalability** ⚙️  
-   Ideal for small to large-scale deployments. Take advantage of APIs and integrations that automate certificate issuance, renewal, and revocation for a smooth lifecycle.
+3. Automation and scalability: works for small to large-scale deployments. APIs and integrations automate certificate issuance, renewal, and revocation across the lifecycle.

-4. **Enhanced Security** 🔒  
-   Through the use of modern cryptographic algorithms and protocols, Step-CA supports industry-standard X.509 certificates, providing robust encryption and digital signatures.
+4. Modern cryptography: Step-CA supports industry-standard X.509 certificates using modern cryptographic algorithms and protocols for encryption and digital signatures.

-5. **Infrastructure Integration** 🌐  
-   Integrates seamlessly with your existing tools and systems. Supports various authentication methods such as username/password, MFA, and external identity providers.
+5. Infrastructure integration: integrates with your existing tools and systems, and supports various authentication methods such as username/password, MFA, and external identity providers.

-6. **Auditability and Compliance** 📜  
-   With comprehensive logging and auditing capabilities, you can track certificate activity and meet compliance requirements with ease.
+6. Auditability and compliance: comprehensive logging and auditing let you track certificate activity and meet compliance requirements.

-7. **Developer-Friendly APIs** 👩‍💻👨‍💻  
-   APIs and SDKs designed for developers make it easy to integrate certificate management into your applications and custom workflows.
+7. Developer-friendly APIs: APIs and SDKs designed for developers make it easy to integrate certificate management into your applications and custom workflows.

-**In short:** Step-CA by Smallstep is designed to make certificate authority management both fun and hassle-free. Thanks to its secure, scalable, and user-friendly features, you can easily manage your certificates' lifecycle while protecting your infrastructure!
+Step-CA by Smallstep is built to make certificate authority management straightforward: you manage your certificates' lifecycle while keeping your infrastructure protected.

-## 🚀 Installation
+## Installation

-### 🔧 Binary Installation
+### Binary installation

 #### 1. Step CLI

@@ -60,7 +53,7 @@ wget https://dl.step.sm/gh-release/certificates/docs-ca-install/v0.24.1/step-ca_
 sudo dpkg -i step-ca_0.24.1_amd64.deb
 ```

-#### 3. Creating a Dedicated User
+#### 3. Creating a dedicated user

 ```bash
 adduser adminCA
@@ -81,8 +74,8 @@ What would you like to name the CA's first provisioner?
 Choose a password for your CA keys and the first provisioner.
 ✔ [leave empty and we will generate one] : 

-Generating root certificate... done! 🎉  
-Generating intermediate certificate... done! 🎊
+Generating root certificate... done!
+Generating intermediate certificate... done!

 ✔ Root certificate: /home/adminCA/.step/certs/root_ca.crt  
 ✔ Root private key: /home/adminCA/.step/secrets/root_ca_key  
@@ -95,7 +88,7 @@ Generating intermediate certificate... done! 🎊

 Your PKI is ready to go. To generate certificates for individual services, see `step help ca`.

-💌 **FEEDBACK**  
+**Feedback:**
 The step utility is not instrumented for usage statistics. It does not contact a central server. Your feedback is, however, extremely valuable! Please consider writing to feedback@smallstep.com, joining GitHub Discussions, or joining us on Discord at [https://u.step.sm/discord](https://u.step.sm/discord).
 ```

@@ -111,10 +104,10 @@ step-ca .step/config/ca.json
 $ step ca provisioner add acme --type ACME
 ✔ CA Configuration: /home/adminCA/.step/config/ca.json

-Success! Your `step-ca` configuration has been updated. To pick up the new configuration, send a SIGHUP (kill -1 <pid>) or restart the step-ca process. 🎉
+Success! Your `step-ca` configuration has been updated. To pick up the new configuration, send a SIGHUP (kill -1 <pid>) or restart the step-ca process.
 ```

-#### Running Step-CA as a systemd Service
+#### Running Step-CA as a systemd service

 Create a file:

@@ -155,7 +148,7 @@ systemctl daemon-reload
 systemctl start step-ca.service
 ```

-### 🐳 Docker Installation
+### Docker installation

 ```bash
 docker run -it -v step:/home/step \
@@ -167,11 +160,11 @@ docker run -it -v step:/home/step \
    smallstep/step-ca
 ```

-## 🔑 Accessing the CA from Another Client
+## Accessing the CA from another client

-> [!NOTE] Adjust the port based on your installation:  
+> [!NOTE] Adjust the port based on your installation:
 >
-> - **Binary:** port **443**  
+> - **Binary:** port **443**
 > - **Docker:** port **9000**

 Install the Step CLI:
@@ -226,7 +219,7 @@ step certificate install $(step path)/certs/root_ca.crt

 ---

-### 📝 Obtaining a Certificate
+### Obtaining a certificate

 ```bash
 admin@User:~$ step ca certificate nas.lab.loc srv.crt srv.key
--- a/content/netlab/sécurité/stepca.fr.md
+++ b/content/netlab/sécurité/stepca.fr.md
@@ -6,45 +6,38 @@ cascade:
  type: docs
 ---

-## 🔗 Sources
+## Sources

- [📖 Documentation Officielle](https://smallstep.com/docs/tutorials/)
- [🛠️ Step-CA en tant que Service systemd](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/)
- [🔐 Gestion des Certificats avec OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/)
+- [Documentation officielle](https://smallstep.com/docs/tutorials/)
+- [Step-CA en tant que service systemd](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/)
+- [Gestion des certificats avec OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/)

-## 🤖 À propos de Step-CA
+## À propos de Step-CA

-Step-CA est un ensemble d'outils astucieux développé par Smallstep, une entreprise spécialisée dans la gestion sécurisée des identités et l'automatisation des certificats. 🚀  
-Sa mission ? Simplifier la mise en place et la gestion de vos propres autorités de certification (AC) avec facilité et sécurité !
+Step-CA est un ensemble d'outils développé par Smallstep, une entreprise spécialisée dans la gestion sécurisée des identités et l'automatisation des certificats.
+Sa mission est de simplifier la mise en place et la gestion de vos propres autorités de certification (AC).

 ### Principales fonctionnalités

-1. **Gestion des Autorités de Certification** 🔑  
-   Configurez et gérez facilement vos propres AC. Créez des AC racines et intermédiaires, délivrez des certificats et gérez les révocations comme un pro.
+1. Gestion des autorités de certification : configurez et gérez facilement vos propres AC. Créez des AC racines et intermédiaires, délivrez des certificats et gérez les révocations.

-2. **Gestion Sécurisée des Clés** 🛡️  
-   Respecte les bonnes pratiques pour le stockage et la gestion sécurisés des clés, garantissant que vos clés cryptographiques restent protégées contre les accès non autorisés.
+2. Gestion sécurisée des clés : respecte les bonnes pratiques pour le stockage et la gestion des clés, afin que vos clés cryptographiques restent protégées contre les accès non autorisés.

-3. **Automatisation et Scalabilité** ⚙️  
-   Idéal pour les déploiements de petite à grande envergure. Profitez des API et intégrations qui automatisent la délivrance, le renouvellement et la révocation des certificats pour un cycle de vie sans accrocs.
+3. Automatisation et scalabilité : adapté aux déploiements de petite à grande envergure. Les API et intégrations automatisent la délivrance, le renouvellement et la révocation des certificats tout au long du cycle de vie.

-4. **Sécurité Renforcée** 🔒  
-   Grâce à l'utilisation d'algorithmes et de protocoles cryptographiques modernes, Step-CA prend en charge les certificats X.509 conformes aux normes de l'industrie, offrant un chiffrement robuste et des signatures numériques.
+4. Cryptographie moderne : Step-CA prend en charge les certificats X.509 conformes aux normes de l'industrie, avec des algorithmes et protocoles cryptographiques modernes pour le chiffrement et les signatures numériques.

-5. **Intégration avec l'Infrastructure** 🌐  
-   S'intègre parfaitement avec vos outils et systèmes existants. Prend en charge diverses méthodes d'authentification telles que nom d'utilisateur/mot de passe, MFA et fournisseurs d'identité externes.
+5. Intégration avec l'infrastructure : s'intègre avec vos outils et systèmes existants, et prend en charge diverses méthodes d'authentification telles que nom d'utilisateur/mot de passe, MFA et fournisseurs d'identité externes.

-6. **Auditabilité et Conformité** 📜  
-   Avec des capacités complètes de journalisation et d'audit, vous pouvez suivre les activités des certificats et satisfaire aux exigences de conformité en toute simplicité.
+6. Auditabilité et conformité : la journalisation et l'audit complets permettent de suivre les activités des certificats et de répondre aux exigences de conformité.

-7. **API Conviviales pour les Développeurs** 👩‍💻👨‍💻  
-   Des API et SDK conçus pour les développeurs facilitent l'intégration de la gestion des certificats dans vos applications et flux de travail personnalisés.
+7. API conviviales pour les développeurs : des API et SDK conçus pour les développeurs facilitent l'intégration de la gestion des certificats dans vos applications et flux de travail personnalisés.

-**En résumé :** Step-CA de Smallstep est conçu pour rendre la gestion des autorités de certification à la fois ludique et sans tracas. Grâce à ses fonctionnalités sécurisées, scalables et conviviales, vous pouvez gérer facilement le cycle de vie de vos certificats tout en protégeant votre infrastructure !
+Step-CA de Smallstep est conçu pour rendre la gestion des autorités de certification simple : vous gérez le cycle de vie de vos certificats tout en protégeant votre infrastructure.

-## 🚀 Installation
+## Installation

-### 🔧 Installation Binaire
+### Installation binaire

 #### 1. Step CLI

@@ -60,7 +53,7 @@ wget https://dl.step.sm/gh-release/certificates/docs-ca-install/v0.24.1/step-ca_
 sudo dpkg -i step-ca_0.24.1_amd64.deb
 ```

-#### 3. Création d'un Utilisateur Spécifique
+#### 3. Création d'un utilisateur dédié

 ```bash
 adduser adminCA
@@ -81,8 +74,8 @@ Quel nom souhaitez-vous donner au premier provisionneur de l'AC ?
 Choisissez un mot de passe pour vos clés AC et le premier provisionneur.
 ✔ [laissez vide et nous en générerons un] : 

-Génération du certificat racine... fait ! 🎉  
-Génération du certificat intermédiaire... fait ! 🎊
+Génération du certificat racine... fait !
+Génération du certificat intermédiaire... fait !

 ✔ Certificat racine : /home/adminCA/.step/certs/root_ca.crt  
 ✔ Clé privée racine : /home/adminCA/.step/secrets/root_ca_key  
@@ -95,7 +88,7 @@ Génération du certificat intermédiaire... fait ! 🎊

 Votre PKI est prête ! Pour générer des certificats pour des services individuels, consultez `step help ca`.

-💌 **RETROACTION**  
+**Retours :**
 L'utilitaire step n'est pas instrumenté pour les statistiques d'utilisation. Il ne contacte pas un serveur central. Toutefois, vos retours sont très précieux ! N'hésitez pas à nous écrire à feedback@smallstep.com, rejoindre les Discussions GitHub ou nous rejoindre sur Discord à [https://u.step.sm/discord](https://u.step.sm/discord).
 ```

@@ -111,10 +104,10 @@ step-ca .step/config/ca.json
 $ step ca provisioner add acme --type ACME
 ✔ Configuration de l'AC : /home/adminCA/.step/config/ca.json

-Succès ! La configuration de votre `step-ca` a été mise à jour. Pour prendre en compte la nouvelle configuration, envoyez un SIGHUP (kill -1 <pid>) ou redémarrez le processus step-ca. 🎉
+Succès ! La configuration de votre `step-ca` a été mise à jour. Pour prendre en compte la nouvelle configuration, envoyez un SIGHUP (kill -1 <pid>) ou redémarrez le processus step-ca.
 ```

-#### Exécuter Step-CA en tant que Service systemd
+#### Exécuter Step-CA en tant que service systemd

 Créez un fichier :

@@ -155,7 +148,7 @@ systemctl daemon-reload
 systemctl start step-ca.service
 ```

-### 🐳 Installation avec Docker
+### Installation avec Docker

 ```bash
 docker run -it -v step:/home/step \
@@ -167,11 +160,11 @@ docker run -it -v step:/home/step \
    smallstep/step-ca
 ```

-## 🔑 Accès à l'AC avec un Autre Client
+## Accès à l'AC avec un autre client

-> [!NOTE] Adaptez le port en fonction de votre installation :  
+> [!NOTE] Adaptez le port en fonction de votre installation :
 >
-> - **Binaire :** port **443**  
+> - **Binaire :** port **443**
 > - **Docker :** port **9000**

 Installez le Step CLI :
@@ -226,7 +219,7 @@ step certificate install $(step path)/certs/root_ca.crt

 ---

-### 📝 Obtenir un Certificat
+### Obtenir un certificat

 ```bash
 admin@User:~$ step ca certificate nas.lab.loc srv.crt srv.key