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

@@ -20,7 +20,7 @@ The distinction that matters most, coming from a monitoring background, is that
 
 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]]
+![IP Fabric dashboard with discovery statistics, vendor mix, and compliance reports](ipfabric_dashboard.en.png#center)
 
 ## How discovery and snapshots work, at a high level
 
@@ -32,7 +32,7 @@ IP Fabric works from two core concepts: discovery and snapshots.
 
 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]]
+![Discovery settings: IP scope, seeds, and advanced options](ipfabric_snap_config.en.png#center)
 
 ## Use cases
 
@@ -42,7 +42,7 @@ This is the use case that started it all for me, and the one referenced directly
 
 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]]
+![Topology diagram of the EVPN/VXLAN lab, generated by IP Fabric](ipfabric_network_diagram.en.png#center)
 
 ### Intent checks
 
@@ -50,7 +50,7 @@ Intent checks are rules you define once, things like "no unused VLANs," "STP roo
 
 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]]
+![Intent check rules and their results, color-coded pass/fail](ipfabric_intent.en.png#center)
 
 ### Path lookup
 
@@ -58,7 +58,7 @@ Given a source, a destination, and optionally a protocol/port, IP Fabric simulat
 
 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]]
+![Path lookup between two lab hosts, showing the hop-by-hop forwarding path](ipfabric_path2path.en.png#center)
 
 ### Snapshot comparison
 
@@ -66,7 +66,7 @@ Because every discovery run is preserved as its own snapshot, IP Fabric can diff
 
 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]]
+![Diff between two snapshots, with added and removed elements highlighted](ipfabric_snapshot_diff.en.png#center)
 
 ### Programmatic access: Python SDK and MCP server
 
@@ -76,4 +76,4 @@ More relevant to the AIOps angle of the blog series: IP Fabric also ships an [MC
 
 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]]
+![An agent querying IP Fabric through its MCP server to compare two snapshots](claude_mcp.en.png#center)

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

@@ -20,7 +20,7 @@ La distinction qui compte le plus, quand on vient du monde du monitoring, c'est
 
 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]]
+![Dashboard IP Fabric avec statistiques de discovery, mix de vendeurs et rapports de conformité](ipfabric_dashboard.fr.png#center)
 
 ## Comment fonctionnent discovery et snapshots, à haut niveau
 
@@ -32,7 +32,7 @@ Un **snapshot**, c'est le résultat d'une exécution de discovery, figé à un i
 
 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]]
+![Paramètres de discovery : scope IP, seeds et réglages avancés](ipfabric_snap_config.fr.png#center)
 
 ## Cas d'usage
 
@@ -42,7 +42,7 @@ C'est le cas d'usage qui a tout déclenché pour moi, et celui référencé dire
 
 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]]
+![Diagramme de topologie du lab EVPN/VXLAN généré par IP Fabric](ipfabric_network_diagram.fr.png#center)
 
 ### Les intent checks
 
@@ -50,7 +50,7 @@ Les intent checks sont des règles qu'on définit une seule fois, du genre « pa
 
 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]]
+![Tableau des règles d'intent checks et de leurs résultats, colorés succès/échec](ipfabric_intent.fr.png#center)
 
 ### Le path lookup
 
@@ -58,7 +58,7 @@ Avec une source, une destination et, en option, un protocole/port, IP Fabric sim
 
 Ç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]]
+![Path lookup entre deux hôtes du lab, avec le chemin de forwarding saut par saut](ipfabric_path2path.fr.png#center)
 
 ### La comparaison de snapshots
 
@@ -66,7 +66,7 @@ Comme chaque exécution de discovery est conservée sous forme de snapshot, IP F
 
 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]]
+![Comparaison de deux snapshots, avec les éléments ajoutés et retirés mis en évidence](ipfabric_snapshot_diff.fr.png#center)
 
 ### L'accès programmatique : SDK Python et serveur MCP
 
@@ -76,4 +76,4 @@ Plus pertinent encore pour l'angle AIOps de la série de blog : IP Fabric propos
 
 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]]
+![Exemple d'agent interrogeant IP Fabric via le serveur MCP pour comparer deux snapshots](claude_mcp.fr.png#center)