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

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 :

1. cartographier les objets utiles ;
2. stabiliser les conventions ;
3. valider avec les équipes ;
4. automatiser ce qui peut l’être ;
5. 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.