content/documentation/ip-fabric/_index.en.md

@@ -7,16 +7,16 @@ cascade:
 
 <!-- markdownlint-disable MD033 MD034-->
 
-IP Fabric is the network discovery and assurance platform I run on my lab. It's also the tool sitting behind the phrase "topological source of truth" in my [AIOps and Network Observability series](/en/blog/aiops-observabilite-reseau-ia/) — this page is the technical companion to that series, gathering what I learn about the tool as I actually use it, rather than a one-off tutorial.
+IP Fabric is the network discovery and assurance platform I run on my lab. It's also the tool sitting behind the phrase "topological source of truth" in my [AIOps and Network Observability series](/en/blog/aiops-observabilite-reseau-ia/): this page is the technical companion to that series, gathering what I learn about the tool as I actually use it, rather than a one-off tutorial.
 
 > [!NOTE] **Living document**
 > I'm adding to this page as I explore more of IP Fabric myself. Expect new use-case sections to show up over time rather than a finished, all-at-once guide.
 
 ## What IP Fabric is
 
-IP Fabric is a network assurance platform: it connects to your devices, pulls their configuration and operational state through the same CLI/API access you'd use yourself, and rebuilds a structured model of the network from that raw data — topology, routing tables, VLANs, VRFs, ACLs, and more. Official documentation lives at [docs.ipfabric.io](https://docs.ipfabric.io/latest/).
+IP Fabric is a network assurance platform: it connects to your devices, pulls their configuration and operational state through the same CLI/API access you'd use yourself, and rebuilds a structured model of the network from that raw data: topology, routing tables, VLANs, VRFs, ACLs, and more. Official documentation lives at [docs.ipfabric.io](https://docs.ipfabric.io/latest/).
 
-The distinction that matters most, coming from a monitoring background, is that IP Fabric isn't a telemetry tool. It doesn't care about counters, utilization, or time series — that's what a metrics stack is for. What it cares about is **state**: what's configured, what's actually running, and how everything connects. It answers "what is the network, right now" rather than "how busy is the network, right now."
+The distinction that matters most, coming from a monitoring background, is that IP Fabric isn't a telemetry tool. It doesn't care about counters, utilization, or time series: that's what a metrics stack is for. What it cares about is **state**: what's configured, what's actually running, and how everything connects. It answers "what is the network, right now" rather than "how busy is the network, right now."
 
 That distinction is exactly why it slots into the "topology as source of truth" layer of the AIOps stack described in the blog series: an agent that needs to reason about the network needs this structured state before it needs metrics.
 
@@ -28,7 +28,7 @@ IP Fabric works from two core concepts: discovery and snapshots.
 
 **Discovery** is the crawl. IP Fabric seeds itself from a list of reachable devices (or a seed subnet), logs into each one over SSH/API, and walks outward via CDP/LLDP neighbors, routing adjacencies, and other protocol-level breadcrumbs to find the rest of the network. It parses the output the way an engineer would read a `show` command, and turns that into structured, queryable data.
 
-**Snapshots** are the result of a discovery run, frozen at a point in time. Each snapshot is a complete, self-contained picture of the network as it looked when discovery finished — every table, every diagram, every intent check result, all scoped to that snapshot. Nothing is overwritten: past snapshots stay around so you can go back and compare.
+**Snapshots** are the result of a discovery run, frozen at a point in time. Each snapshot is a complete, self-contained picture of the network as it looked when discovery finished: every table, every diagram, every intent check result, all scoped to that snapshot. Nothing is overwritten: past snapshots stay around so you can go back and compare.
 
 That snapshot model is what makes several of the use cases below possible: because history isn't discarded, questions like "what changed since yesterday" have a direct answer instead of requiring you to have thought ahead and set up your own diffing.
 
@@ -40,13 +40,13 @@ That snapshot model is what makes several of the use cases below possible: becau
 
 This is the use case that started it all for me, and the one referenced directly in the blog series. IP Fabric builds a topology diagram and a set of relational tables (devices, interfaces, neighbors, VLANs, VRFs) from live discovery, not from a manually maintained spreadsheet or a Visio diagram someone forgot to update.
 
-For my EVPN/VXLAN lab, that means I have an always-current answer to "what's connected to what" without trusting my own memory or an out-of-date diagram. This is the layer an AI agent would need to query first, before anything else, if it's going to reason correctly about the network — which is the whole point of the "blind agent" problem from the blog series: an agent working off stale topology data answers with confidence even when it's wrong.
+For my EVPN/VXLAN lab, that means I have an always-current answer to "what's connected to what" without trusting my own memory or an out-of-date diagram. This is the layer an AI agent would need to query first, before anything else, if it's going to reason correctly about the network: that's the whole point of the "blind agent" problem from the blog series, an agent working off stale topology data answers with confidence even when it's wrong.
 
 ![Topology diagram of the EVPN/VXLAN lab, generated by IP Fabric](ipfabric_network_diagram.en.png#center)
 
 ### Intent checks
 
-Intent checks are rules you define once, things like "no unused VLANs," "STP root should be on the core switches," "every access port should have BPDU guard" — and IP Fabric evaluates them against every snapshot going forward. Failures show up as color-coded checks you can drill into, all the way down to the specific device and interface that broke the rule.
+Intent checks are rules you define once, things like "no unused VLANs," "STP root should be on the core switches," "every access port should have BPDU guard," and IP Fabric evaluates them against every snapshot going forward. Failures show up as color-coded checks you can drill into, all the way down to the specific device and interface that broke the rule.
 
 Here, IP Fabric moves from "descriptive" (what's out there) to "normative" (is what's out there correct). It's a natural fit for the standardization principle I keep coming back to in the blog series: intent checks are a way to enforce naming and configuration consistency automatically, instead of relying on a human to notice drift.
 
@@ -54,7 +54,7 @@ Here, IP Fabric moves from "descriptive" (what's out there) to "normative" (is w
 
 ### Path lookup
 
-Given a source, a destination, and optionally a protocol/port, IP Fabric simulates the forwarding path across the whole discovered network, hop by hop, including the specific routing/switching decision at each device — without sending a single test packet. It's a computed answer, from the collected state, not a live trace.
+Given a source, a destination, and optionally a protocol/port, IP Fabric simulates the forwarding path across the whole discovered network, hop by hop, including the specific routing/switching decision at each device, without sending a single test packet. It's a computed answer, from the collected state, not a live trace.
 
 This turns "why can't this host reach that host" from a multi-device, multi-`show`-command investigation into a single query. It also validates security posture: a path lookup will tell you if an ACL or firewall rule blocks traffic somewhere along the way.
 
@@ -70,9 +70,9 @@ That's the practical answer to "what actually changed," normally the hardest que
 
 ### Programmatic access: Python SDK and MCP server
 
-Everything IP Fabric exposes through its UI is also reachable through its REST API, and there's an official [Python SDK (ipfabric)](https://docs.ipfabric.io/latest/integrations/python-sdk/) that wraps it into a more ergonomic client — pulling tables as pandas dataframes, running intent checks, triggering discovery, all from a script.
+Everything IP Fabric exposes through its UI is also reachable through its REST API, and there's an official [Python SDK (ipfabric)](https://docs.ipfabric.io/latest/integrations/python-sdk/) that wraps it into a more ergonomic client: pulling tables as pandas dataframes, running intent checks, triggering discovery, all from a script.
 
-More relevant to the AIOps angle of the blog series: IP Fabric also ships an [MCP server](https://docs.ipfabric.io/latest/integrations/mcp-server/), which exposes the platform's data directly as tools an LLM agent can call. That's a fairly direct answer to the "making the network visible to an agent" problem the last article in the series is going to tackle — instead of me hand-rolling a wrapper around the API, IP Fabric already speaks the protocol an agent needs.
+More relevant to the AIOps angle of the blog series: IP Fabric also ships an [MCP server](https://docs.ipfabric.io/latest/integrations/mcp-server/), which exposes the platform's data directly as tools an LLM agent can call. That's a fairly direct answer to the "making the network visible to an agent" problem the last article in the series is going to tackle, instead of me hand-rolling a wrapper around the API: IP Fabric already speaks the protocol an agent needs.
 
 I haven't wired this up on my lab yet; that's future work, and future sections here.
 

content/documentation/ip-fabric/_index.fr.md

@@ -7,14 +7,14 @@ cascade:
 
 <!-- markdownlint-disable MD033 MD034-->
 
-IP Fabric est la plateforme de discovery et d'assurance réseau que je fais tourner sur mon lab. C'est aussi l'outil qui se cache derrière l'expression « source de vérité topologique » dans ma [série AIOps et observabilité réseau](/blog/aiops-observabilite-reseau-ia/) — cette page en est le complément technique : j'y consigne ce que j'apprends de l'outil au fil de son usage réel, plutôt qu'un tutoriel figé.
+IP Fabric est la plateforme de discovery et d'assurance réseau que je fais tourner sur mon lab. C'est aussi l'outil qui se cache derrière l'expression « source de vérité topologique » dans ma [série AIOps et observabilité réseau](/blog/aiops-observabilite-reseau-ia/) : cette page en est le complément technique : j'y consigne ce que j'apprends de l'outil au fil de son usage réel, plutôt qu'un tutoriel figé.
 
 > [!NOTE] **Document vivant**
 > Cette page s'enrichit au fur et à mesure que j'explore IP Fabric. Attendez-vous à voir de nouvelles sections de cas d'usage apparaître avec le temps, pas un guide bouclé d'un seul coup.
 
 ## Ce qu'est IP Fabric
 
-IP Fabric est une plateforme d'assurance réseau : elle se connecte à vos équipements, en récupère la configuration et l'état opérationnel via les mêmes accès CLI/API que vous utiliseriez vous-même, et reconstruit à partir de ces données brutes un modèle structuré du réseau — topologie, tables de routage, VLANs, VRFs, ACLs, et plus encore. La documentation officielle se trouve sur [docs.ipfabric.io](https://docs.ipfabric.io/latest/).
+IP Fabric est une plateforme d'assurance réseau : elle se connecte à vos équipements, en récupère la configuration et l'état opérationnel via les mêmes accès CLI/API que vous utiliseriez vous-même, et reconstruit à partir de ces données brutes un modèle structuré du réseau : topologie, tables de routage, VLANs, VRFs, ACLs, et plus encore. La documentation officielle se trouve sur [docs.ipfabric.io](https://docs.ipfabric.io/latest/).
 
 La distinction qui compte le plus, quand on vient du monde du monitoring, c'est qu'IP Fabric n'est pas un outil de télémétrie. Les compteurs, l'utilisation, les séries temporelles, ça ne le concerne pas : c'est le rôle d'une stack de métriques. Ce qui l'intéresse, c'est l'**état** : ce qui est configuré, ce qui tourne réellement, et comment tout ça est connecté. Il répond à « qu'est-ce que le réseau, là, maintenant » plutôt qu'à « à quel point le réseau est-il chargé, là, maintenant ».
 
@@ -28,7 +28,7 @@ IP Fabric repose sur deux notions centrales : la discovery et les snapshots.
 
 La **discovery**, c'est l'exploration. IP Fabric part d'une liste d'équipements joignables (ou d'un sous-réseau de départ), se connecte à chacun via SSH/API, et remonte le fil via les voisinages CDP/LLDP, les adjacences de routage et d'autres indices au niveau protocole pour découvrir le reste du réseau. L'outil parse la sortie un peu comme le ferait un ingénieur en lisant une commande `show`, et transforme ça en données structurées et interrogeables.
 
-Un **snapshot**, c'est le résultat d'une exécution de discovery, figé à un instant donné. Chaque snapshot est une photo complète et autonome du réseau tel qu'il était à la fin de cette discovery — toutes les tables, tous les diagrammes, tous les résultats d'intent checks, circonscrits à ce snapshot précis. Rien n'est écrasé : les anciens snapshots restent disponibles, ce qui permet de revenir en arrière et de comparer.
+Un **snapshot**, c'est le résultat d'une exécution de discovery, figé à un instant donné. Chaque snapshot est une photo complète et autonome du réseau tel qu'il était à la fin de cette discovery : toutes les tables, tous les diagrammes, tous les résultats d'intent checks, circonscrits à ce snapshot précis. Rien n'est écrasé : les anciens snapshots restent disponibles, ce qui permet de revenir en arrière et de comparer.
 
 C'est ce modèle de snapshots qui rend possibles plusieurs des cas d'usage ci-dessous : comme l'historique n'est jamais jeté, une question du type « qu'est-ce qui a changé depuis hier » a une réponse directe, sans qu'il ait fallu anticiper et bricoler son propre système de diff.
 
@@ -40,13 +40,13 @@ C'est ce modèle de snapshots qui rend possibles plusieurs des cas d'usage ci-de
 
 C'est le cas d'usage qui a tout déclenché pour moi, et celui référencé directement dans la série de blog. IP Fabric construit un diagramme de topologie et un ensemble de tables relationnelles (équipements, interfaces, voisins, VLANs, VRFs) à partir de la discovery en direct, pas depuis un tableur maintenu à la main ou un schéma Visio que personne n'a pensé à mettre à jour.
 
-Sur mon lab EVPN/VXLAN, ça veut dire que j'ai une réponse toujours à jour à la question « qu'est-ce qui est connecté à quoi », sans avoir à me fier à ma mémoire ou à un schéma périmé. C'est la couche qu'un agent IA devrait interroger en premier, avant tout le reste, s'il doit raisonner correctement sur le réseau — c'est tout l'enjeu du problème de « l'agent aveugle » évoqué dans la série de blog : un agent qui travaille sur une topologie obsolète répond avec assurance, même quand il se trompe.
+Sur mon lab EVPN/VXLAN, ça veut dire que j'ai une réponse toujours à jour à la question « qu'est-ce qui est connecté à quoi », sans avoir à me fier à ma mémoire ou à un schéma périmé. C'est la couche qu'un agent IA devrait interroger en premier, avant tout le reste, s'il doit raisonner correctement sur le réseau : c'est tout l'enjeu du problème de « l'agent aveugle » évoqué dans la série de blog, un agent qui travaille sur une topologie obsolète répond avec assurance, même quand il se trompe.
 
 ![Diagramme de topologie du lab EVPN/VXLAN généré par IP Fabric](ipfabric_network_diagram.fr.png#center)
 
 ### Les intent checks
 
-Les intent checks sont des règles qu'on définit une seule fois, du genre « pas de VLAN inutilisé », « la racine STP doit être sur les switches core », « chaque port d'accès doit avoir BPDU guard activé » — et IP Fabric les évalue automatiquement sur chaque nouveau snapshot. Les échecs remontent sous forme de vérifications colorées, avec possibilité de descendre jusqu'à l'équipement et l'interface précise qui enfreint la règle.
+Les intent checks sont des règles qu'on définit une seule fois, du genre « pas de VLAN inutilisé », « la racine STP doit être sur les switches core », « chaque port d'accès doit avoir BPDU guard activé », et IP Fabric les évalue automatiquement sur chaque nouveau snapshot. Les échecs remontent sous forme de vérifications colorées, avec possibilité de descendre jusqu'à l'équipement et l'interface précise qui enfreint la règle.
 
 Ici, IP Fabric bascule du « descriptif » (ce qui existe) au « normatif » (ce qui existe est-il correct). Ça rejoint naturellement le principe de standardisation que je répète souvent dans la série de blog : les intent checks permettent d'imposer la cohérence de nommage et de configuration automatiquement, plutôt que de compter sur un humain pour repérer une dérive.
 
@@ -54,7 +54,7 @@ Ici, IP Fabric bascule du « descriptif » (ce qui existe) au « normatif » (ce
 
 ### Le path lookup
 
-Avec une source, une destination et, en option, un protocole/port, IP Fabric simule le chemin de forwarding à travers tout le réseau découvert, saut par saut, en incluant la décision précise de routage/commutation prise à chaque équipement — sans envoyer le moindre paquet de test. C'est une réponse calculée à partir de l'état collecté, pas une trace en direct.
+Avec une source, une destination et, en option, un protocole/port, IP Fabric simule le chemin de forwarding à travers tout le réseau découvert, saut par saut, en incluant la décision précise de routage/commutation prise à chaque équipement, sans envoyer le moindre paquet de test. C'est une réponse calculée à partir de l'état collecté, pas une trace en direct.
 
 Ça transforme un « pourquoi cet hôte ne peut-il pas joindre cet autre hôte » (normalement une investigation multi-équipements et multi-commandes `show`) en une seule requête. Ça permet aussi de vérifier la posture de sécurité : un path lookup indique si une ACL ou une règle de pare-feu bloque le trafic quelque part sur le chemin.
 
@@ -70,9 +70,9 @@ Comme chaque exécution de discovery est conservée sous forme de snapshot, IP F
 
 ### L'accès programmatique : SDK Python et serveur MCP
 
-Tout ce qu'IP Fabric expose via son interface est aussi accessible via son API REST, et il existe un [SDK Python officiel (ipfabric)](https://docs.ipfabric.io/latest/integrations/python-sdk/) qui l'enveloppe dans un client plus ergonomique — récupérer des tables sous forme de dataframes pandas, lancer des intent checks, déclencher une discovery, le tout depuis un script.
+Tout ce qu'IP Fabric expose via son interface est aussi accessible via son API REST, et il existe un [SDK Python officiel (ipfabric)](https://docs.ipfabric.io/latest/integrations/python-sdk/) qui l'enveloppe dans un client plus ergonomique : récupérer des tables sous forme de dataframes pandas, lancer des intent checks, déclencher une discovery, le tout depuis un script.
 
-Plus pertinent encore pour l'angle AIOps de la série de blog : IP Fabric propose aussi un [serveur MCP](https://docs.ipfabric.io/latest/integrations/mcp-server/), qui expose directement les données de la plateforme comme des outils qu'un agent LLM peut appeler. C'est une réponse assez directe au problème de « rendre le réseau visible à un agent » que le dernier article de la série doit aborder — au lieu de coder moi-même un wrapper autour de l'API, IP Fabric parle déjà le protocole dont un agent a besoin.
+Plus pertinent encore pour l'angle AIOps de la série de blog : IP Fabric propose aussi un [serveur MCP](https://docs.ipfabric.io/latest/integrations/mcp-server/), qui expose directement les données de la plateforme comme des outils qu'un agent LLM peut appeler. C'est une réponse assez directe au problème de « rendre le réseau visible à un agent » que le dernier article de la série doit aborder, au lieu de coder moi-même un wrapper autour de l'API : IP Fabric parle déjà le protocole dont un agent a besoin.
 
 Je n'ai pas encore branché ça sur mon lab ; c'est un chantier à venir, et de futures sections ici.