Fix wording in IP Fabric documentation

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

@@ -40,7 +40,7 @@ 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 is confidently wrong, not cautiously uncertain.
+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.
 
 ![Topology diagram of the EVPN/VXLAN lab, generated by IP Fabric](ipfabric_network_diagram.en.png#center)
 
@@ -48,7 +48,7 @@ For my EVPN/VXLAN lab, that means I have an always-current answer to "what's con
 
 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.
+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.
 
 ![Intent check rules and their results, color-coded pass/fail](ipfabric_intent.en.png#center)
 
@@ -64,7 +64,7 @@ This turns "why can't this host reach that host" from a multi-device, multi-`sho
 
 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.
+That's the practical answer to "what actually changed," 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.
 
 ![Diff between two snapshots, with added and removed elements highlighted](ipfabric_snapshot_diff.en.png#center)
 

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

@@ -40,7 +40,7 @@ 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 se trompe avec assurance, il n'est pas prudemment incertain.
+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)
 
@@ -48,7 +48,7 @@ Sur mon lab EVPN/VXLAN, ça veut dire que j'ai une réponse toujours à jour à
 
 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.
+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.
 
 ![Tableau des règles d'intent checks et de leurs résultats, colorés succès/échec](ipfabric_intent.fr.png#center)
 
@@ -64,7 +64,7 @@ Avec une source, une destination et, en option, un protocole/port, IP Fabric sim
 
 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à.
+Ça donne une 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à.
 
 ![Comparaison de deux snapshots, avec les éléments ajoutés et retirés mis en évidence](ipfabric_snapshot_diff.fr.png#center)