Add IP Fabric documentation page (FR/EN)

Companion piece to the AIOps blog series, covering discovery/snapshots
and initial use cases (topology, intent checks, path lookup, snapshot
diff, Python SDK/MCP server). Structured as a living document for
future additions.

content/documentation/_index.en.md

@@ -13,4 +13,5 @@ cascade:
 {{< cards >}}
   {{< card link="https://containerlab.dev/install/" title="ContainerLab" subtitle="How to Install ContainerLab" icon="endpoints" >}}
   {{< card link="https://devpod.sh" title="DevPod" subtitle="A simple way to deploy Labs" icon="git" >}}  
+  {{< card link="/en/documentation/ip-fabric/" title="IP Fabric" subtitle="Network discovery and assurance" icon="map" >}}
 {{< /cards >}}

content/documentation/_index.fr.md

@@ -13,4 +13,5 @@ cascade:
 {{< cards >}}
   {{< card link="https://containerlab.dev/install/" title="ContainerLab" subtitle="Comment Installer ContainerLab" icon="endpoints" >}}
   {{< card link="https://devpod.sh" title="DevPod" subtitle="Une manière simple de déployer Lab" icon="git" >}}  
+  {{< card link="/documentation/ip-fabric/" title="IP Fabric" subtitle="Discovery et assurance réseau" icon="map" >}}
 {{< /cards >}}

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

@@ -0,0 +1,79 @@
+---
+title: "IP Fabric"
+date: 2026-07-20T09:00:00+02:00
+cascade:
+  type: docs
+---
+
+<!-- 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.
+
+> [!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/).
+
+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.
+
+[[CAPTURE: IP Fabric dashboard overview]]
+
+## How discovery and snapshots work, at a high level
+
+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.
+
+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.
+
+[[CAPTURE: snapshot list / discovery settings screen]]
+
+## Use cases
+
+### Topology as source of truth
+
+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 is confidently wrong, not cautiously uncertain.
+
+[[CAPTURE: IP Fabric topology diagram of the lab]]
+
+### 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.
+
+This is where 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.
+
+[[CAPTURE: intent check results table, colored pass/fail]]
+
+### 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.
+
+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.
+
+[[CAPTURE: path lookup diagram between two lab hosts]]
+
+### Snapshot comparison
+
+Because every discovery run is preserved as its own snapshot, IP Fabric can diff two of them directly (one from before a change window, one from after, for example) and surface exactly what's different: new or removed devices, VLAN changes, routing table deltas, interface state changes.
+
+This is the practical answer to "what actually changed," which is normally the hardest question to answer after an incident. Instead of reconstructing a timeline from memory or from scattered change tickets, the diff is already sitting there.
+
+[[CAPTURE: snapshot diff view showing added/removed items]]
+
+### 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.
+
+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.
+
+[[CAPTURE: MCP server tool list or example agent query]]

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

@@ -0,0 +1,79 @@
+---
+title: "IP Fabric"
+date: 2026-07-20T09:00:00+02:00
+cascade:
+  type: docs
+---
+
+<!-- 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é.
+
+> [!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/).
+
+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 ».
+
+Cette distinction est précisément ce qui place l'outil dans la couche « topologie comme source de vérité » de la stack AIOps décrite dans la série de blog : un agent qui doit raisonner sur le réseau a besoin de cet état structuré avant d'avoir besoin de métriques.
+
+[[CAPTURE: vue d'ensemble du dashboard IP Fabric]]
+
+## Comment fonctionnent discovery et snapshots, à haut niveau
+
+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.
+
+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.
+
+[[CAPTURE: écran de liste des snapshots / paramètres de discovery]]
+
+## Cas d'usage
+
+### La topologie comme source de vérité
+
+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 se trompe avec assurance, il n'est pas prudemment incertain.
+
+[[CAPTURE: diagramme de topologie IP Fabric du lab]]
+
+### 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.
+
+C'est là qu'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.
+
+[[CAPTURE: tableau de résultats des intent checks, coloré succès/échec]]
+
+### 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.
+
+Ç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.
+
+[[CAPTURE: diagramme de path lookup entre deux hôtes du lab]]
+
+### La comparaison de snapshots
+
+Comme chaque exécution de discovery est conservée sous forme de snapshot, IP Fabric peut comparer directement deux d'entre eux (un avant une fenêtre de changement, un après, par exemple) et faire ressortir précisément ce qui diffère : équipements ajoutés ou retirés, changements de VLAN, écarts dans les tables de routage, changements d'état d'interface.
+
+C'est la réponse concrète à « qu'est-ce qui a vraiment changé », d'ordinaire la question la plus difficile à répondre après un incident. Plutôt que de reconstituer une chronologie de mémoire ou à partir de tickets de changement épars, le diff est déjà là.
+
+[[CAPTURE: vue de diff entre deux snapshots avec éléments ajoutés/retirés]]
+
+### 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.
+
+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.
+
+[[CAPTURE: liste des outils du serveur MCP ou exemple de requête d'un agent]]