DEV Community: Laurent Quastana

Cartographier un SI: mon cheminement d’architecte SI, entre vision métier, vérité infra et pragmatisme open source

Laurent Quastana — Thu, 30 Apr 2026 20:11:41 +0000

Introduction

Je suis architecte SI dans le domaine de la santé, au sein d’un contexte où plusieurs établissements doivent progressivement mieux se coordonner, mutualiser certains services, sécuriser leurs systèmes et préparer les prochaines étapes de convergence numérique.

Quand j’ai commencé ce travail, je venais d’un parcours plus orienté architecture logicielle, intégration et systèmes d’information complexes. J’avais déjà travaillé sur des sujets d’API, d’interopérabilité, d’EAI, de flux et de plateformes techniques. La complexité n’est pas seulement technique, elle est aussi organisationnelle, humaine, historique et réglementaire.

Dans mon secteur, une application n’est jamais juste une application. Elle peut porter un processus de soin, une contrainte réglementaire, une dépendance éditeur, une interface HL7, une base Oracle, un serveur oublié, un flux SFTP, une habilitation Active Directory, une criticité métier, un contrat de maintenance, une exposition réseau, et parfois une connaissance qui n’existe que dans la tête de deux personnes.

Très vite, une évidence s’est imposée : pour piloter un SI , il ne suffit pas d’avoir des serveurs qui tournent et des applications qui répondent. Il faut comprendre le paysage.

Il faut savoir quelles applications existent, à quoi elles servent, qui les utilise, où elles sont hébergées, avec quoi elles communiquent, quels flux les relient, quelles dépendances elles portent, et quels impacts métier peuvent apparaître en cas d’incident.

C’est ce cheminement que je veux partager ici : comment je suis passé d’un besoin assez classique de cartographie applicative à une réflexion plus globale sur la source de vérité, l’infrastructure, NetBox, les flux, les KPI, et finalement la création de mon propre outil open source : it-landscape.

Le point de départ : un SI réel, vivant, mais peu cartographié

Le premier constat était assez simple : la connaissance existait, mais elle était dispersée.

Un peu dans les fichiers Excel.
Un peu dans les schémas Visio ou Draw.io.
Un peu dans vCenter.
Un peu dans les contrats éditeurs.
Un peu dans les procédures d’exploitation.
Un peu dans les tickets.
Un peu dans les réunions.
Et beaucoup dans la tête des équipes.

Ce n’est pas une critique. C’est le fonctionnement naturel de beaucoup de SI historiques. Les équipes font tourner le système, règlent les urgences, déploient les projets, corrigent les flux, gèrent les migrations. La documentation arrive souvent après, quand il reste du temps. Et souvent, il n’en reste pas.

Dans mon contexte, le périmètre était large : plusieurs établissements, plusieurs cultures SI, des applications cliniques, administratives, médico-techniques, logistiques, biomédicales, des flux inter-applicatifs, des hébergements mixtes, des applications locales et des solutions progressivement mutualisées.

Le besoin n’était donc pas de produire un joli schéma. Le besoin était de construire une capacité durable à répondre à des questions simples :

Quelles applications sont utilisées dans tel établissement ?
Quels processus métier sont couverts ?
Quelles applications sont communes à plusieurs sites ?
Quels flux existent entre le DPI, la GAP, le laboratoire, la pharmacie ou l’imagerie ?
Où sont hébergées les applications critiques ?
Quels seraient les impacts si un serveur, une application ou un flux tombait ?
Quels outils pourraient être mutualisés ?
Quels points concentrent le plus de risques ?

Ces questions paraissent simples. Mais sans cartographie structurée, elles demandent souvent plusieurs mails, plusieurs réunions, des exports manuels et beaucoup de recoupements.

Première piste : appliquer une méthode sérieuse de cartographie

Mon premier réflexe a été de chercher un cadre méthodologique solide.

Je ne voulais pas partir directement dans l’outil. Dans ce type de sujet, c’est tentant de commencer par “quel logiciel choisir ?”. Mais le vrai sujet est plutôt : “qu’est-ce qu’on veut représenter, pour qui, et pour décider quoi ?”.

Je me suis donc intéressé aux guides de cartographie du SI, notamment dans une logique inspirée des démarches ANSSI : identifier les enjeux, collecter les informations, structurer les objets, produire des vues, maintenir la cartographie dans le temps.

Cette approche avait beaucoup de sens dans ce contexte. Elle permettait de parler criticité, exposition, dépendances, hébergement, flux, sécurité, continuité d’activité. Elle permettait aussi de sortir d’une vision purement inventaire pour aller vers une vision de gouvernance.

Dans cette logique, j’ai regardé des outils existants, notamment Mercator, qui propose une approche structurée de cartographie et un méta-modèle intéressant.

Sur le papier, c’était cohérent.

Mais sur le terrain, j’ai rencontré une première difficulté : un outil de cartographie détaillée peut être très pertinent pour des architectes, des RSSI ou des équipes techniques, mais il peut être trop dense pour des décideurs qui veulent d’abord comprendre les grands équilibres.

Les DSI, les directions ou les responsables métier n’ont pas toujours besoin de voir immédiatement tous les objets techniques. Ils ont besoin d’une lecture claire :

quels domaines métier ?
quels processus ?
quelles applications ?
quels sujets de convergence ?
quels risques majeurs ?
quelles priorités ?

Le premier enseignement a donc été important : une bonne cartographie n’est pas une cartographie exhaustive. C’est une cartographie adaptée à son public.

Deuxième piste : produire une vision macro lisible

Après cette première étape, j’ai donc changé d’angle.

Au lieu de chercher tout de suite la cartographie parfaite, j’ai commencé par produire une vision macro, plus visuelle, plus simple, plus directement compréhensible.

L’idée était de représenter le SI par grands domaines :

administratif ;
clinique ;
médico-technique ;
logistique ;
support ;
échange de données ;
cybersécurité ;
outils techniques.

Puis, dans chaque domaine, de positionner les applications principales, leur rôle, leur criticité, leur statut, et parfois leur dimension multi-établissement.

Cette approche a eu un vrai effet. Les échanges sont devenus plus simples. Les personnes pouvaient réagir à une vue globale. Elles voyaient immédiatement les trous, les doublons, les dépendances, les applications communes et les différences entre établissements.

Ce type de carte n’était pas une source de vérité technique. Mais elle jouait un rôle essentiel : créer une représentation partagée.

Et dans un projet de cartographie, c’est une étape clé. Avant de maintenir une donnée, il faut que les acteurs comprennent pourquoi elle existe. Avant d’avoir une base propre, il faut créer l’envie de la regarder. Avant de parler modèle, il faut créer un langage commun.

Cette deuxième piste m’a donc permis de réconcilier deux mondes :

le monde stratégique, qui a besoin de lisibilité ;
le monde technique, qui a besoin de précision.

Mais elle avait aussi ses limites.

Un schéma Draw.io, même bien fait, reste difficile à maintenir dans le temps. Il peut devenir très utile en comité, mais il devient vite fragile comme référentiel. Dès que les applications changent, que les flux évoluent, que les hébergements bougent, il faut mettre à jour manuellement. Et si la mise à jour dépend d’une seule personne, la cartographie redevient rapidement obsolète.

Le deuxième enseignement était donc clair : une vue macro est indispensable, mais elle ne suffit pas. Il faut la connecter à une donnée structurée.

Troisième piste : créer un outil simple, orienté lecture applicative

C’est là qu’est née l’idée de it-landscape.

Je ne voulais pas construire un énorme outil d’architecture d’entreprise. Je voulais quelque chose de plus simple, plus léger, plus lisible, capable de répondre à un besoin concret : représenter un SI par établissements, domaines, processus, applications et flux.

Le dépôt it-landscape est donc né comme un MVP Next.js pour cartographier un système d’information: applications, processus métier, serveurs, VLANs, flux applicatifs et impacts d’incident. Le projet propose notamment une vue métier, une vue applicative, une vue réseau, une vue des flux, une simulation d’incident, une administration des référentiels JSON, ainsi qu’un premier socle de sécurité avec authentification, rôles et audit. (GitHub)

L’approche de départ était volontairement pragmatique :

des fichiers JSON comme base simple ;
une interface web lisible ;
des vues par établissement ;
des filtres par domaine, criticité, hébergement, interface ou caractère multi-établissement ;
une logique de trigrammes applicatifs ;
une représentation des flux ;
une première capacité de simulation d’impact.

Pourquoi JSON ? Parce que je voulais quelque chose de simple à comprendre, versionnable, diffable, facile à alimenter, facile à corriger, et qui ne nécessite pas immédiatement une base de données complexe.

Dans un SI, l’objectif n’est pas toujours de faire le plus sophistiqué. Il est souvent plus utile de faire quelque chose que les équipes peuvent comprendre, reprendre, améliorer et maintenir.

it-landscape m’a permis de transformer une carte statique en outil vivant.

Là où un schéma donne une photo, l’outil commence à donner une capacité d’exploration.

On peut filtrer.
On peut chercher.
On peut relier.
On peut préparer des KPI.
On peut commencer à discuter gouvernance.
On peut identifier les applications critiques.
On peut réfléchir aux impacts.

Mais assez vite, une nouvelle question est arrivée.

La fausse bonne idée : tout mettre dans le même outil

Quand on commence à cartographier, on a envie de tout représenter.

Les applications.
Les serveurs.
Les VLANs.
Les IPs.
Les flux.
Les bases de données.
Les certificats.
Les sauvegardes.
Les utilisateurs.
Les habilitations.
Les incidents.
Les contrats.
Les coûts.

Et c’est précisément là que le risque apparaît : transformer un outil lisible en fourre-tout.

Au début, j’ai naturellement intégré quelques objets d’infrastructure dans it-landscape. C’était utile pour comprendre les dépendances applicatives. Mais plus j’avançais, plus je voyais une limite : l’infrastructure a déjà ses propres modèles, ses propres objets, ses propres exigences de qualité.

Un VLAN n’est pas juste une information décorative dans une fiche application.
Une IP doit être unique, historisée, rattachée correctement.
Une VM dépend d’un cluster, d’un host, d’un site, d’interfaces, de tags, parfois de règles d’exploitation.
Un inventaire infra doit pouvoir être automatisé, audité, synchronisé.

Je me suis alors posé une question structurante :

Est-ce que it-landscape doit devenir aussi un référentiel d’infrastructure ?

Ma réponse actuelle est non.

Et cette décision est probablement l’une des plus importantes du projet.

La rencontre avec NetBox : accepter de spécialiser les outils

Pour l’infrastructure, NetBox est beaucoup plus adapté.

NetBox est pensé comme une source de vérité infrastructure et réseau : IPAM, DCIM, VLANs, interfaces, équipements, virtualisation, API REST, extensions. Dans mon article précédent, j’expliquais justement pourquoi je préférais spécialiser les rôles : it-landscape pour les vues applicatives, les flux, les KPI et la lisibilité métier ; NetBox pour l’inventaire infrastructure, les IPs, les VLANs, les clusters, les VMs, les interfaces et les ressources techniques. (DEV Community)

J’ai donc commencé à expérimenter NetBox en interne, avec un déploiement Docker Compose, pour valider rapidement la valeur sans lancer immédiatement un chantier trop lourd.

Ensuite est venue la question de l’alimentation.

Pour la partie VMware, plusieurs pistes existaient :

Option 1 : l’intégration officielle vCenter

Intéressante, mais pas forcément adaptée à mon contexte immédiat, notamment parce que certaines capacités avancées s’adressent plutôt à des offres NetBox Cloud ou Enterprise.

Option 2 : `netbox-sync`

Très intéressante aussi. C’est une approche plus durable pour synchroniser différentes sources vers NetBox, notamment VMware.

Option 3 : RVTools + API NetBox

C’est finalement l’approche que j’ai retenue pour démarrer.

Pourquoi ? Parce que je voulais comprendre le modèle de données avant d’automatiser trop vite.

Je voulais voir comment mapper les datacenters, les clusters, les hosts, les VMs, les interfaces, les VLANs et les IPs. Je voulais contrôler ce que j’importais, éviter de polluer NetBox avec trop d’informations inutiles, et corriger progressivement les erreurs.

Dans mon article précédent, je détaillais cette approche : exporter les données depuis RVTools, puis les pousser dans NetBox via l’API REST avec PowerShell, afin de garder la main sur les champs importés, la correspondance entre datacenters, sites et clusters, la création des VLANs, le rattachement des IPs, les commentaires enrichis et la logique de mise à jour. (DEV Community)

Cette étape a été très formatrice.

Elle m’a confirmé qu’il ne fallait pas opposer cartographie applicative et inventaire infrastructure. Il faut les articuler.

Le modèle cible : deux niveaux, deux outils, une cohérence

Aujourd’hui, ma vision est beaucoup plus claire.

Je ne cherche plus à faire un outil unique qui fait tout. Je cherche à connecter des référentiels spécialisés.

Dans cette logique :

NetBox = vérité infrastructure
it-landscape = lecture applicative et gouvernance SI

NetBox porte les objets techniques :

Sites
Clusters
Hosts
VMs
Interfaces
IPs
VLANs
Ressources techniques

it-landscape porte la lecture SI :

Établissements
Domaines métier
Processus
Applications
Flux inter-applicatifs
KPI
Statuts
Criticités
Dépendances fonctionnelles

À terme, une application dans it-landscape pourrait pointer vers ses ressources NetBox :

Application métier
├── Domaine métier
├── Processus couvert
├── Flux applicatifs
├── Criticité
├── KPI / statut / documentation
└── Ressources infra liées dans NetBox
    ├── VM
    ├── IP
    ├── VLAN
    └── Cluster

C’est cette séparation qui me semble saine.

Elle permet de garder NetBox propre, orienté infrastructure.
Elle permet de garder it-landscape lisible, orienté métier et gouvernance.
Et elle permet de connecter les deux mondes sans les confondre.

Le dépôt it-landscape prévoit déjà cette logique : quand NETBOX_URL et NETBOX_TOKEN sont définis, les endpoints infrastructure et réseau peuvent lire NetBox comme source de vérité, et un script permet de peupler NetBox depuis les JSON locaux pour une démonstration. (GitHub)

Les problèmes rencontrés

1. La donnée existe, mais elle n’est pas fiable partout

Le premier problème n’est pas l’outil. C’est la qualité de donnée.

Une application peut avoir plusieurs noms selon les équipes.
Un serveur peut être connu par son hostname, son alias, son rôle applicatif ou son IP.
Un flux peut être documenté côté EAI, mais pas côté application.
Un hébergement peut être connu globalement, mais pas qualifié précisément.

La cartographie oblige à normaliser.

Il faut des identifiants.
Des conventions de nommage.
Des statuts.
Des niveaux de criticité.
Des propriétaires.
Des règles de mise à jour.

Sans ça, on ne construit pas une source de vérité. On construit un nouvel Excel plus joli.

2. Les publics n’ont pas les mêmes attentes

Un DSI veut une vision synthétique.

Un RSSI veut voir les risques, les expositions, les criticités.

Un ingénieur système veut retrouver une VM, une IP, un VLAN, un cluster.

Un chef de projet veut comprendre les dépendances applicatives.

Un métier veut savoir à quoi sert l’application et qui contacter.

Le piège serait de vouloir répondre à tout le monde avec la même vue.

J’ai appris qu’il fallait accepter plusieurs niveaux de lecture :

macro pour décider ;
applicatif pour comprendre ;
technique pour exploiter ;
sécurité pour prioriser ;
gouvernance pour maintenir.

3. L’exhaustivité peut tuer l’adoption

Au début, on veut tout cartographier.

Mais plus on ajoute de champs, plus on rend la contribution difficile. Et si contribuer devient difficile, la cartographie n’est plus maintenue.

J’ai donc préféré une logique progressive :

cartographier les objets utiles ;
stabiliser les conventions ;
valider avec les équipes ;
automatiser ce qui peut l’être ;
enrichir ensuite.

La cartographie doit produire de la valeur rapidement. Sinon, elle devient un chantier permanent sans usage réel.

4. Le vrai sujet est la gouvernance

Un outil ne maintient pas une cartographie à lui seul.

Il faut savoir :

qui est responsable de la donnée ;
qui valide une modification ;
à quelle fréquence on revoit les informations ;
quels contrôles de cohérence sont faits ;
comment on arbitre les doublons ;
comment on intègre les nouveaux projets.

Dans mon cheminement, la cartographie est progressivement devenue moins un sujet documentaire et plus un sujet de gouvernance SI.

Ce que `it-landscape` apporte aujourd’hui

it-landscape est encore un projet jeune, mais il porte une idée simple : rendre la cartographie SI plus accessible, plus lisible et plus actionnable, notamment dans un contexte où les moyens sont limités mais les enjeux très forts.

Aujourd’hui, l’outil propose notamment :

une vue métier par établissement, domaine, processus et application ;
une vue applicative regroupée par trigramme ;
une vue réseau avec VLANs, réseaux, passerelles et serveurs ;
une vue des flux applicatifs ;
une simulation d’impact en cas d’indisponibilité d’un serveur, d’une application ou d’un flux ;
une administration des référentiels JSON ;
des imports Excel ;
une gestion des habilitations ;
un socle RBAC avec rôles viewer, editor, admin ;
un journal d’audit local des écritures et exports. (GitHub)

Ce n’est pas un outil magique.
Ce n’est pas un remplaçant de NetBox.
Ce n’est pas un EAM complet.
Ce n’est pas une CMDB universelle.

C’est un outil volontairement pragmatique, pensé pour répondre à un besoin concret : donner une lecture claire d’un SI applicatif, de ses flux, de ses dépendances et de ses impacts.

Ce que je retiens de ce cheminement

Le premier enseignement, c’est qu’une cartographie utile n’est pas forcément la plus complète. C’est celle qui aide réellement à décider, exploiter, sécuriser ou transformer.

Le deuxième, c’est qu’il faut séparer les responsabilités des outils. Un outil de gouvernance applicative ne doit pas devenir une CMDB infrastructure. Une source de vérité infrastructure ne doit pas devenir un fourre-tout métier.

Le troisième, c’est que la donnée doit être structurée, mais l’expérience utilisateur doit rester simple. Si la cartographie n’est compréhensible que par celui qui l’a construite, elle ne sert pas assez.

Le quatrième, c’est que le cheminement compte autant que le résultat. Dans mon cas, je suis passé par plusieurs étapes :

Constat terrain
→ besoin de visibilité
→ étude méthodologique
→ première approche structurée
→ difficulté d’adhésion côté décideurs
→ vue macro Draw.io
→ besoin de données maintenables
→ création de it-landscape
→ question de l’infrastructure
→ expérimentation NetBox
→ import RVTools + API
→ séparation claire des responsabilités
→ trajectoire d’intégration entre référentiels

Et finalement, ce cheminement m’a amené à une conviction simple :

La cartographie SI ne doit pas être un document.
Elle doit devenir un système vivant d’aide à la décision.

Pourquoi je publie le repo

J’ai publié it-landscape parce que je pense que beaucoup d’équipes SI, notamment dans les hôpitaux, les collectivités, les structures publiques ou les organisations multi-sites, rencontrent les mêmes problèmes.

On a souvent besoin d’un outil simple pour commencer.
Pas forcément d’une grosse plateforme.
Pas forcément d’un projet à six mois.
Pas forcément d’un référentiel parfait.

Juste un socle pour représenter les applications, les processus, les flux, les dépendances et commencer à produire une vision partagée.

Le projet est open source, sous licence MIT, et disponible sur GitHub. Le dépôt contient également une documentation, une démo guidée, une architecture, une roadmap, des tests, un Dockerfile, un Docker Compose et une première intégration NetBox. (GitHub)

Si le sujet vous parle, vous pouvez :

tester le projet ;
l’adapter à votre contexte ;
proposer des idées ;
ouvrir des issues ;
contribuer ;
ou simplement mettre une étoile au repo pour soutenir la démarche.

L’objectif n’est pas de vendre une solution miracle.
L’objectif est de partager un retour d’expérience et de construire progressivement un outil utile, sobre et compréhensible.

Conclusion

Ce travail de cartographie m’a appris qu’un SI ne se comprend pas depuis un seul angle.

Il faut la vision métier.
Il faut la vision applicative.
Il faut la vision flux.
Il faut la vision infrastructure.
Il faut la vision sécurité.
Et surtout, il faut réussir à faire dialoguer ces visions.

Mon approche actuelle repose donc sur un principe simple :

Ne pas tout fusionner.
Connecter les bons référentiels.
Garder chaque outil dans son rôle.
Faire simple, utile, maintenable.

it-landscape est ma contribution à cette approche : un outil léger pour rendre la cartographie applicative plus lisible, plus vivante et plus proche des besoins de gouvernance SI.

La suite logique sera de renforcer l’intégration avec NetBox, d’améliorer les vues d’impact, de consolider les KPI, et de continuer à rapprocher la cartographie applicative de la réalité opérationnelle du terrain.

Parce qu’au fond, une bonne cartographie n’est pas celle qu’on imprime une fois par an.

C’est celle qu’on utilise quand il faut décider, diagnostiquer, sécuriser, mutualiser ou expliquer.

De RVTools à NetBox : Construire une source de vérité infra sans perdre la cartographie applicative

Laurent Quastana — Tue, 28 Apr 2026 08:08:44 +0000

Introduction

Dans beaucoup d’environnements SI, la documentation d’infrastructure finit par se disperser : un peu dans vCenter, un peu dans des fichiers Excel, un peu dans des schémas, un peu dans la tête des équipes.

C’est encore plus vrai dans un contexte où l’on doit composer avec des applications critiques, des flux inter-applicatifs, des contraintes d’exploitation, des VLANs, des sauvegardes, des dépendances éditeurs et des périmètres parfois historiques.

Dans cette logique, j’ai commencé à structurer une cartographie applicative avec mon outil it-landscape, un tableau de bord léger basé sur JSON pour représenter des domaines, processus et applications d’un établissement de santé. (GitHub)

Mais assez vite, une question s’est posée :

Est-ce que mon outil doit aussi devenir un référentiel d’infrastructure ?

Ma réponse actuelle : non.

Je préfère spécialiser les outils :

it-landscape pour les vues applicatives, les flux, les KPI et la lisibilité métier ;
NetBox pour l’inventaire infrastructure, IPAM, VLANs, clusters, VMs, interfaces et ressources techniques.

NetBox est justement conçu comme une source de vérité réseau et infrastructure, en combinant notamment IPAM, DCIM, API REST et extensions. (netboxlabs.com)

Pourquoi NetBox ?

NetBox n’est pas seulement un inventaire. C’est une base structurée pour documenter et automatiser l’infrastructure.

Dans mon cas, les objets utiles étaient notamment :

les sites ;
les clusters VMware ;
les hôtes ESXi ;
les machines virtuelles ;
les interfaces ;
les adresses IP ;
les VLANs ;
les relations VM → cluster → site ;
les commentaires techniques issus des exports.

L’objectif n’était pas de faire un simple import ponctuel, mais de commencer à bâtir une base propre, réutilisable et exploitable.

Déploiement interne via Docker Compose

Pour démarrer rapidement, j’ai choisi un déploiement interne de NetBox via Docker Compose.

Le dépôt netbox-docker fournit les composants nécessaires pour construire et exécuter NetBox sous forme de conteneurs ; il s’agit d’un projet maintenu par la communauté NetBox. (GitHub)

L’approche Docker Compose est intéressante pour un premier socle interne :

déploiement rapide ;
dépendances maîtrisées ;
PostgreSQL et Redis intégrés ;
possibilité de versionner la configuration ;
facilité de reconstruction en environnement de test.

Dans mon contexte, cela permettait de valider rapidement la valeur de NetBox sans lancer immédiatement un chantier d’industrialisation lourd.

La question de l’inventaire VMware

Une fois NetBox déployé, le vrai sujet devient l’alimentation des données.

Pour la virtualisation VMware, plusieurs options existent.

Option 1 : intégration officielle vCenter

NetBox Labs propose une intégration VMware vCenter permettant de synchroniser des données vCenter vers NetBox, notamment pour réduire la saisie manuelle et la dérive documentaire. (netboxlabs.com)

Cette intégration est intéressante, mais elle s’adresse au périmètre NetBox Cloud / Enterprise avec NetBox Assurance. (netboxlabs.com)

Dans un contexte NetBox Community auto-hébergé, ce n’était donc pas l’option la plus directe pour moi.

Option 2 : netbox-sync

En open source, une alternative intéressante existe : bb-Ricardo/netbox-sync.

Le projet permet de synchroniser des objets depuis différentes sources vers NetBox, notamment VMware vCenter et des inventaires Redfish. (GitHub)

C’est probablement l’une des pistes les plus propres si l’on veut une synchronisation plus durable entre vCenter et NetBox.

Mais dans mon cas, je voulais d’abord comprendre le modèle de données, contrôler les mappings et éviter de pousser trop d’informations trop vite.

Option 3 : RVTools + API NetBox

J’ai donc choisi une approche plus progressive :

exporter les données depuis RVTools, puis les pousser dans NetBox via l’API REST avec PowerShell.

Ce choix m’a permis de garder la main sur :

les champs réellement importés ;
la correspondance entre datacenters, sites et clusters ;
la création des VLANs ;
le rattachement des IPs ;
les commentaires enrichis ;
la logique de mise à jour ;
la correction progressive des erreurs.

Ce que j’ai importé en premier

Je suis parti d’un export RVTools complet, mais je n’ai pas tout importé directement.

Les premiers fichiers réellement utiles ont été :

RVTools_tabvInfo.csv
RVTools_tabvHost.csv
RVTools_tabvCluster.csv
RVTools_tabvNIC.csv
RVTools_tabvDatastore.csv

Le premier socle importé dans NetBox couvre :

les sites ;
les clusters VMware ;
les hosts ESXi ;
les interfaces physiques ESXi ;
les VMs ;
les interfaces VM ;
les VLANs ;
les IPs primaires ;
les datastores en commentaires de cluster.

Le résultat obtenu :

Hosts ESXi créés / MAJ        : X
Interfaces ESXi créées / MAJ  : X
VMs créées / MAJ              : X
Interfaces VM créées / MAJ    : X
VLANs créés / réutilisés      : X
IPs primaires traitées        : X
Templates ignorés             : X
Lignes vides ignorées         : X

À ce stade, NetBox devient déjà utile : on peut rechercher une VM, voir son IP, son VLAN, son cluster, son hôte ESXi d’origine, son OS et ses informations de contexte.

Pourquoi ne pas tout mettre dans NetBox ?

C’est un point important.

NetBox doit rester une source de vérité infrastructure. Il ne doit pas devenir un fourre-tout applicatif.

Par exemple, certaines informations RVTools sont intéressantes pour l’audit, mais pas forcément comme objets natifs NetBox :

snapshots ;
VMware Tools obsolètes ;
ISO montées ;
USB connectés ;
alertes RVTools ;
détails fins des partitions ;
détails des disques VMDK ;
licences ;
multipath ;
HBA.

Ces données peuvent être utiles, mais plutôt sous forme de :

tags ;
commentaires ;
journal entries ;
rapports d’audit ;
custom fields ciblés.

L’objectif est d’éviter de polluer le référentiel.

Articulation avec it-landscape

Mon idée pour la suite est de faire évoluer it-landscape vers un outil plus spécialisé sur la vision applicative.

Je souhaite conserver dans it-landscape :

les vues applicatives ;
les domaines métier ;
les processus ;
les flux inter-applicatifs ;
les KPI ;
les statuts applicatifs ;
les liens vers la documentation ;
les dépendances fonctionnelles.

Et déléguer à NetBox :

les VMs ;
les IPs ;
les VLANs ;
les clusters ;
les hosts ;
les interfaces ;
les ressources techniques ;
les informations d’infrastructure.

L’idée n’est donc pas de remplacer NetBox, mais de s’y connecter.

À terme, une application dans it-landscape pourrait pointer vers les objets NetBox correspondants :

Application métier
  ├── Flux applicatifs
  ├── KPI
  ├── Statut métier
  └── Ressources infra liées dans NetBox
        ├── VM
        ├── IP
        ├── VLAN
        └── Cluster

Cela permet de séparer proprement deux niveaux :

NetBox       = vérité infrastructure
it-landscape = lecture applicative et gouvernance SI

Ce que je retiens

Cette expérimentation confirme plusieurs choses.

D’abord, NetBox prend rapidement de la valeur dès qu’il est alimenté avec un minimum de données propres.

Ensuite, l’API REST est suffisamment simple pour permettre une intégration progressive, sans forcément attendre une solution complète de synchronisation.

Enfin, partir de RVTools est une bonne approche pragmatique pour amorcer le référentiel, surtout lorsque l’on veut comprendre les données avant d’automatiser davantage.

Conclusion

La cartographie ne peut pas être uniquement applicative, ni uniquement technique.

Il faut les deux.

NetBox apporte une base solide pour l’infrastructure.
Un outil comme it-landscape peut rester concentré sur la lecture applicative, les flux, les KPI et la gouvernance.

Le bon équilibre n’est donc pas de tout fusionner, mais de connecter les bons référentiels entre eux.

Pour moi, cette première étape RVTools → PowerShell → API NetBox est surtout une manière pragmatique de poser les fondations :

commencer simple, importer proprement, comprendre le modèle, puis automatiser progressivement.

Revenir aux bases du DevOps avec une stack simple

Laurent Quastana — Fri, 17 Apr 2026 21:58:07 +0000

On parle souvent du DevOps avec beaucoup d’outils et de concepts.

Mais dans la pratique, le besoin de départ est souvent plus simple : préparer des serveurs Linux de façon propre, homogène et reproductible.

C’est l’idée derrière mon projet :

👉 minimal-linux-ops-stack

Je n’ai pas cherché à construire une grosse plateforme. L’objectif est plus modeste : poser une base simple pour automatiser la configuration initiale de serveurs Linux avec Ansible, dans une logique claire et facile à reprendre.

Pourquoi ce projet

Avec le temps, on voit souvent apparaître les mêmes problèmes : des serveurs configurés un peu à la main, des différences entre machines, des ajustements faits dans l’urgence, et au final peu de visibilité sur l’existant.

Au début, ça fonctionne.

Puis on finit par se demander :

ce qui a vraiment été configuré,
si les serveurs sont alignés,
et si on serait capable de reconstruire la même base proprement ailleurs.

C’est précisément à ce niveau qu’une approche DevOps simple apporte déjà de la valeur.

Pour moi, les bases du DevOps, c’est ça

Avant les grosses chaînes d’outils, je retiens surtout quelques principes :

décrire l’infrastructure dans du code,
éviter les actions manuelles répétées,
pouvoir rejouer une configuration proprement,
intégrer un minimum de sécurité dès le départ.

Dit autrement : avoir une base claire, versionnée et répétable.

Ce que contient la stack

Le projet repose sur des briques simples :

Ansible pour décrire la configuration,
Gitea pour stocker le code,
Semaphore UI pour lancer les playbooks,
et une cible Linux de démonstration.

La baseline actuelle couvre des besoins de base mais utiles :

installation de paquets communs,
configuration du fuseau horaire,
création éventuelle d’un utilisateur admin,
hardening SSH,
désactivation du login root direct,
authentification par clé plutôt que par mot de passe.

Ce n’est pas spectaculaire, mais c’est justement le but : faire simple, propre et utile.

Pourquoi ce sujet me parle

Dans mon parcours, j’ai travaillé sur des environnements où la stabilité, la traçabilité et la fiabilité comptent beaucoup, notamment dans le domaine hospitalier.

Ce type de contexte m’a appris qu’on ne manque pas toujours d’outils. On manque souvent surtout de standardisation, de visibilité et de bases propres.

C’est pour ça que j’aime les approches progressives : avant de vouloir tout industrialiser, il y a déjà beaucoup de valeur à poser un socle clair.

Idées d’évolution

La suite logique serait d’aller un peu plus loin, tout en gardant l’esprit simple du projet :

renforcer la sécurité de base,
mieux gérer la dérive dans le temps,
ajouter plus de contrôles automatiques,
intégrer un peu d’observabilité.

L’idée n’est pas de grossir pour grossir, mais d’améliorer la cohérence du socle.

Conclusion

Je vois ce projet comme une base saine, pas comme une plateforme complète.

Une manière simple de :

versionner une configuration,
automatiser une baseline,
réduire les écarts manuels,
et rendre l’exploitation plus lisible.

Ce n’est pas révolutionnaire, mais c’est utile.

Et souvent, c’est déjà une bonne façon de faire du DevOps.

Sécuriser HL7/MLLP avec Stunnel (mTLS)

Laurent Quastana — Mon, 07 Jul 2025 14:37:18 +0000

Vous échangez des flux HL7 en clair entre EAI et DPI ?
Voici comment les sécuriser avec TLS mutuel sans toucher au code source, en 4 commandes et un Docker Compose.

🌍 Contexte

Les messages HL7 sont souvent véhiculés via MLLP (Minimal Lower Layer Protocol)… sans chiffrement.
C’est encore toléré dans certains SIH, mais difficilement défendable en 2025 :

Exposition des données patients (PHI) en clair
Absence d’authentification forte entre systèmes

Alors comment ajouter une couche TLS mutuelle sans casser un lien MLLP existant ?
Réponse : Stunnel + Docker.

🚀 Objectif du projet

Le dépôt mllp-safetunnel fournit un environnement de test pour :

encapsuler HL7/MLLP en TLS (avec authentification mutuelle)
simuler des flux EAI ⇄ DPI via deux conteneurs Docker
tester la réception, les ACKs, et l’interopérabilité

🎯 Sans changer le code du DPI ou de l’EAI.

📦 Contenu du dépôt

Répertoire / fichier	Rôle
`eai/`	Dockerfile + scripts Python simulant l’envoi HL7
`dpi/`	Idem côté DPI (réception + retour)
`stunnel/`	Certificats X.509 de test + script `gen-certs.sh`
`docker-compose.yml`	Orchestration complète
`docs/`	Diagrammes, bonnes pratiques sécurité, cheatsheets HL7

Les conteneurs utilisent deux réseaux internes (net_eai, net_dpi).
Seuls les ports TLS (32100, 32200) sont exposés à l’hôte.

⚙️ Prérequis

Docker ≥ 24.0
Docker Compose v2
OpenSSL (si vous régénérez les certificats)
Ports TCP disponibles : 32100, 32200

🔧 Démarrage rapide

# 1. Cloner le dépôt
git clone https://github.com/votre_org/mllp-safetunnel.git
cd mllp-safetunnel

# 2. (Optionnel) régénérer les certificats
./stunnel/gen-certs.sh

# 3. Lancer l’environnement
docker compose up -d

# 4. Suivre les logs
docker compose logs -f eai

Des messages HL7 (MDM^T02, ADT^A01) sont simulés toutes les 20 secondes, avec accusé de réception (ACK).

📡 Détail des tunnels Stunnel

🔁 EAI → DPI (client TLS)

Étape	Port	Protocole
Envoi MLLP clair	`21010`	TCP
Tunnel TLS sortant	`32100`	TLS mutuel
Redirection vers DPI (clair)	`21010`	TCP interne

🔁 DPI → EAI (retour)

Même logique, avec les ports 22010 (clair) → 32200 (TLS) → 22010 (clair).

🧪 Simulation HL7

Chaque conteneur embarque :

Script	Rôle
`send.sh`	Envoie un fichier HL7, logue le résultat
`send_loop.sh`	Envoi auto toutes les 20 s (actif par défaut)
`listen.sh`	Écoute MLLP, affiche + ACK
`server.log`	Démarrage du service HL7

Exemple de test manuel :

# Depuis EAI vers DPI
docker compose exec eai /app/send.sh
docker compose exec dpi /app/listen.sh

# Depuis DPI vers EAI
docker compose exec dpi /app/send.sh
docker compose exec eai /app/listen.sh

🛠️ Personnalisation

Besoin	À modifier
Certificats de prod	Remplacer les fichiers dans `stunnel/`
Autres ports	Modifier `stunnel.conf` et `docker-compose.yml`
Remplacer simulateurs	Monter vos conteneurs EAI / DPI réels
Logs plus verbeux	Ajouter `debug = 7` dans les confs

🔐 Bonnes pratiques sécurité

TLS mutuel obligatoire (verify = 2)
Limiter l’exposition aux ports 32100 / 32200 uniquement
Automatiser la rotation des certificats (gen-certs.sh)
Surveiller stunnel.log, surtout en cas d’erreurs handshake

📈 Envisager la production

Ce projet est une base pour :

Démonstrateur sécurité avant mise en production
Formation des équipes DevOps santé

Il peut être adapté en k8s, supervisé avec Prometheus, ou branché sur un EAI Mirth/Rhapsody.

🧾 Licence

MIT — libre d’usage et d’adaptation, y compris en contexte hospitalier.

👉 Repo GitHub : github.com/lquastana/mllp-safetunnel
📢 Questions ? Ouvert aux PR / issues / idées !

Mapping a Hospital Information System

Laurent Quastana — Tue, 01 Jul 2025 11:53:43 +0000

1 — About me

I’m a software engineer who spent more than a decade designing application architectures in banking.

Since 2022 I’ve served as transversal architect for several public hospitals (~ 300 apps, 500 data flows). My role: give CIOs and operations a dual view—strategic and hands-on—of their digital ecosystem.

2 — Starting point

No global map – every silo had its own PowerPoint.
No flow matrix – impossible to size cyber-exposure or dependencies.
Sparse documentation on many off-the-shelf products.

Impact: governance suffered from limited visibility, slowing territorial convergence and compliance work (PGSSI-S, HAS 2025).

3 — Method: follow the ANSSI playbook

The French cyber-agency guide “Mapping an Information System in Five Steps” provides the backbone:

establish the stakes,
collect reality,
pick tooling,
produce the views,
keep the map alive.

4 — Micro view: an ANSSI-aligned cartography engine

To capture the nuts-and-bolts layer—processes, applications, assets, flows, criticality—I rely on an open-source engine built around the ANSSI meta-model.

Strengths

multi-user workflow & JSON API
out-of-the-box alignment with EBIOS risk analysis
easy to script exports for DevSecOps pipelines

Trade-offs

substantial first data load (time + people)
information-dense diagrams: perfect for engineers, too detailed for an executive “big picture”

5 — Macro view: a Draw.io schema

To bridge that big-picture gap, I built a Domain → Process → Application diagram (criticality, hosting model, mutualisation). Great for the C-suite—even if it can’t generate KPIs on its own.

6 — Dual tooling & data pipeline

Angle	Tooling choice	Purpose
Granular / operational	ANSSI-aligned cartography engine	Live knowledge base; validates new flows; links to biomedical assets
Macro / indicators	it-lanscape (my OSS repo)	Nightly JSON → static dashboards: process similarity, mutualisation rate, etc.

👉 Give it a try: fork the project on GitHub → https://github.com/lquastana/it-lanscape

DEV Community: Laurent Quastana

Cartographier un SI: mon cheminement d’architecte SI, entre vision métier, vérité infra et pragmatisme open source

Introduction

Le point de départ : un SI réel, vivant, mais peu cartographié

Première piste : appliquer une méthode sérieuse de cartographie

Deuxième piste : produire une vision macro lisible

Troisième piste : créer un outil simple, orienté lecture applicative

La fausse bonne idée : tout mettre dans le même outil

La rencontre avec NetBox : accepter de spécialiser les outils

Option 1 : l’intégration officielle vCenter

Option 2 : netbox-sync

Option 3 : RVTools + API NetBox

Le modèle cible : deux niveaux, deux outils, une cohérence

Les problèmes rencontrés

1. La donnée existe, mais elle n’est pas fiable partout

2. Les publics n’ont pas les mêmes attentes

3. L’exhaustivité peut tuer l’adoption

4. Le vrai sujet est la gouvernance

Ce que it-landscape apporte aujourd’hui

Ce que je retiens de ce cheminement

Pourquoi je publie le repo

Conclusion

De RVTools à NetBox : Construire une source de vérité infra sans perdre la cartographie applicative

Introduction

Pourquoi NetBox ?

Déploiement interne via Docker Compose

La question de l’inventaire VMware

Option 1 : intégration officielle vCenter

Option 2 : netbox-sync

Option 3 : RVTools + API NetBox

Ce que j’ai importé en premier

Pourquoi ne pas tout mettre dans NetBox ?

Articulation avec it-landscape

Ce que je retiens

Conclusion

Revenir aux bases du DevOps avec une stack simple

Pourquoi ce projet

Pour moi, les bases du DevOps, c’est ça

Ce que contient la stack

Pourquoi ce sujet me parle

Idées d’évolution

Conclusion

Sécuriser HL7/MLLP avec Stunnel (mTLS)

🌍 Contexte

🚀 Objectif du projet

📦 Contenu du dépôt

⚙️ Prérequis

🔧 Démarrage rapide

📡 Détail des tunnels Stunnel

🔁 EAI → DPI (client TLS)

🔁 DPI → EAI (retour)

🧪 Simulation HL7

Exemple de test manuel :

🛠️ Personnalisation

🔐 Bonnes pratiques sécurité

📈 Envisager la production

🧾 Licence

Mapping a Hospital Information System

1 — About me

2 — Starting point

3 — Method: follow the ANSSI playbook

4 — Micro view: an ANSSI-aligned cartography engine

5 — Macro view: a Draw.io schema

6 — Dual tooling & data pipeline

Option 2 : `netbox-sync`

Ce que `it-landscape` apporte aujourd’hui