Acte 2 — Quand la cartographie devient une source de vérité vivante : it-landscape passe plugin NetBox (découverte réseau + simulation d'impact)

Suite de « Cartographier un SI : mon cheminement d'architecte SI, entre vision métier, vérité infra et pragmatisme open source ».
Dans le premier épisode, on racontait comment on avait fini par séparer deux besoins : une vue macro lisible par un DSI, et une vérité infra outillée. Et comment on avait choisi NetBox comme socle. Voici ce qui s'est passé ensuite — y compris ce qui a planté.

Là où on s'était arrêté

Fin de l'acte 1 : deux mondes côte à côte. D'un côté it-landscape, le petit dashboard maison alimenté par un export JSON nocturne. De l'autre NetBox, qui commençait à devenir la source de vérité de l'infra (IPAM, DCIM, VM via vCenter/RVTools).

Ça marchait. Mais ça avait un défaut qu'on connaît trop bien : deux référentiels à maintenir, et une synchro fragile entre les deux. La carto métier était toujours en léger décalage avec la réalité. Le classique « la doc dit X, la prod fait Y ».

On a alors pris la décision qui structure tout l'acte 2 : arrêter de synchroniser, et brancher la vue métier directement sur la source de vérité.

1. it-landscape n'est plus un outil à part : c'est un plugin NetBox

Le virage le plus important n'a pas été technique, il a été conceptuel : accepter que la cartographie applicative n'a pas besoin de sa propre base. Elle a besoin d'être une vue sur la donnée qui fait déjà foi.

Concrètement, it-landscape est devenu un plugin NetBox natif : domaines métier, processus, applications et flux sont désormais des modèles NetBox à part entière. Et d'un coup, on hérite gratuitement de tout ce que NetBox sait faire :

• permissions par objet (RBAC),
• changelog et journal sur chaque application, chaque flux,
• API REST et recherche globale,
• des panneaux contextuels : sur la fiche d'une VM ou d'un site, on voit directement les applications qui s'y rattachent.

Plus de synchro nocturne. Plus de données décalées. La vue macro (Domaine → Processus → Application) et la vue micro (le serveur, l'IP, le flux) regardent la même donnée, au même instant.

# La bascule tient en une ligne de config NetBox
PLUGINS = ["netbox_it_landscape"]

2. Enrichir le modèle pour qu'il serve vraiment

Une carto qui liste des applications, c'est un inventaire. Une carto qui aide à décider, c'est autre chose. On a donc enrichi le modèle avec ce dont un RSSI et une cellule qualité ont besoin :

• criticité métier par processus,
• DICP (Disponibilité, Intégrité, Confidentialité, Preuve — le langage de la PGSSI‑S),
• zones d'urbanisation (cadre ANSSI), type de processus, type d'hébergement (jusqu'au HDS),
• fournisseur / éditeur rattaché au référentiel constructeurs de NetBox.

3. Automatiser la découverte… et la leçon de pragmatisme

Tant qu'à avoir une source de vérité, autant qu'elle se remplisse toute seule. Objectif : découvrir automatiquement les switches et firewalls en SNMP et les injecter dans NetBox (devices, interfaces, IP, VLAN, stacks).

On a démarré avec la stack « officielle » de découverte (agent + serveur d'ingestion). Et là… le mur. Sur le volume réel d'une découverte réseau (des dizaines de switches, des milliers d'interfaces), le composant de réconciliation partait en boucle de timeouts, créait des doublons, et a même réussi à mettre l'instance à genoux.

Plutôt que de s'acharner, on a fait ce que l'on recommande toujours : revenir à ce qui est fiable.

L'agent de découverte sait produire un dry‑run : un export JSON propre de tout ce qu'il voit, sans rien écrire. On a donc écarté le composant instable et écrit un importeur maison, idempotent, qui lit ce JSON et écrit dans NetBox via l'API, à débit maîtrisé, clé = nom (le sysName réel de l'équipement).

Agent SNMP (dry-run)  →  JSON propre  →  importeur idempotent  →  NetBox
        (ce qu'il voit)                   (ce que l'on contrôle)    (la vérité)

Résultat : la découverte tourne désormais en cron, modélise proprement les stacks, et ne crée aucun doublon. Le tout sans dépendre du composant qui avait fait perdre une journée.

La leçon (très en phase avec l'acte 1) : la bonne solution n'est pas la plus « officielle », c'est celle qui est fiable, lisible et qu'on maîtrise. Un dry‑run + 250 lignes de Python idempotent ont battu une plateforme entière.

4. Passer de la carto qui décrit à la carto qui répond « et si ? »

C'est la fonctionnalité la plus marquante, parce qu'elle change la nature de l'outil : le simulateur d'impact en cascade.

Une cartographie statique répond à « qu'est‑ce qu'on a ? ». On voulait qu'elle réponde à « qu'est‑ce qui tombe si ça tombe ? ».

Le principe : on sélectionne un ou plusieurs composants en panne (une application, un flux, une VM, un équipement, un hébergeur) avec une sévérité (HS, dégradé, latence, intermittent). Le moteur propage l'impact à travers les flux applicatifs (un parcours en largeur, atténué selon la profondeur et le type d'interface : un flux EAI temps réel ne propage pas comme un batch SFTP). Et il sort :

• les applications et processus métier impactés, regroupés par établissement,
• les flux bloqués,
• les causes par application,
• des actions recommandées.

Soudain, la carto ne sert plus seulement à documenter : elle sert à préparer un plan blanc, à arbitrer une fenêtre de maintenance, à expliquer à un métier pourquoi telle dépendance est critique. C'est de la donnée de carto qui devient de l'aide à la décision.

Ce qu'on en retient

• Une seule source de vérité bat deux référentiels synchronisés, toujours. Le coût de la synchro est invisible jusqu'au jour où il vous explose à la figure.
• Brancher la vue métier sur la donnée d'infra réconcilie deux publics (DSI/gouvernance et équipes techniques) sans double saisie.
• Le pragmatisme reste la meilleure architecture : un dry‑run + un importeur maison ont rendu la découverte fiable là où la stack lourde échouait.
• Open source = exigence + transparence. Publier oblige à des migrations propres, des tests, de l'i18n. C'est inconfortable, et c'est exactement pour ça que ça tire la qualité vers le haut.

Essayez‑le

netbox-it-landscape est sur GitHub, sous licence MIT — vues métier/applicative/flux, KPIs, comparaison d'établissements, assistant d'initialisation (bundles SIH et industrie), et le simulateur d'impact en cascade.

👉 github.com/lquastana/netbox-it-landscape — installez‑le sur une instance de test (pip install netbox-it-landscape), adaptez‑le à votre contexte, ouvrez une issue ou une PR. Et si ça vous parle, une ⭐ aide à donner de la visibilité au projet.

La cartographie n'est pas un document qu'on termine. C'est un système vivant qu'on branche à la vérité — et qu'on apprend, petit à petit, à faire répondre aux bonnes questions.