Cartographier les applications — TopoMap
TopoMap construit automatiquement la carte de dépendances de chaque application à partir des données déjà présentes dans InfraRiver — sans sonde réseau, sans dessin à la main. Elle se tient à jour d'elle-même et répond à la question de tout changement : « si j'arrête ce serveur, qu'est-ce qui tombe ? »
Page : Analyse → TopoMap (/topomap/).
D'où vient la carte
| Couche | Apporte | Source |
|---|---|---|
| Déclarée | Les serveurs qui composent chaque application | Applications et équipes déclarées dans InfraRiver |
| Observée | Les liens qui parle à qui (depends_on) |
Connexions réseau établies, collectées par InfraRiver Collector sur les serveurs Linux |
Une dépendance n'est retenue que si l'autre extrémité est un serveur connu de l'inventaire et effectivement en écoute sur le port concerné : aucun lien n'est deviné.
Serveurs Windows
Les connexions ne sont aujourd'hui observées que sur Linux. Un serveur Windows apparaît dans la carte via son rattachement déclaré à l'application, sans liens observés.
Lire une carte
Choisissez une application (et, sur un grand parc, une équipe) : la carte affiche ses serveurs et leurs dépendances.
| Élément | Sens |
|---|---|
| Couleur du nœud | État de risque : sain, élevé, critique (selon les vulnérabilités) |
| Bordure en pointillés — hors périmètre déclaré | Serveur non déclaré dans l'application, mais auquel elle se connecte (base partagée, cache commun…) |
| Nœud grisé — accès restreint | Serveur privé que vous n'avez pas le droit de voir : nom et IP seulement |
Les serveurs hors périmètre sont limités aux voisins directs de l'application : c'est précisément là que se cachent les dépendances que la documentation manuelle oublie.
Aller plus loin dans le détail, niveau par niveau
La carte reste lisible parce qu'un nœud n'affiche que son nom et son état. Le reste se découvre à la demande :
| Geste | Effet |
|---|---|
| Survol | Info-bulle avec un résumé (IP, DNS, criticités, environnement, vulnérabilités ouvertes) ; la carte ne bouge pas |
| Clic | Détail complet dans le panneau de droite |
| Double-clic sur un serveur | Les informations sortent en sous-nœuds autour de lui : responsable, zone DNS, criticité sécurité, site, base de données installée, serveur web installé, application, et pour une instance cloud son namespace (voir ci-dessous) |
| Double-clic sur un sous-nœud | Il se développe à son tour : les autres serveurs d'un responsable, d'un site ou d'une application ; pour un namespace cloud, les services managés qui le composent (bases, caches, buckets, registres, fonctions, clusters) avec version et fin de support |
| Double-clic sur un nœud déjà développé | Il se referme |
Un seul nœud reste développé à la fois : développer un autre referme le précédent. Cochez garder plusieurs nœuds ouverts au-dessus de la carte pour en comparer plusieurs.
Ce que vos droits limitent :
- un nœud grisé ne se développe pas ;
- l'info-bulle d'un serveur que vous ne pouvez pas voir se limite à son nom et son IP ;
- les vulnérabilités ouvertes n'apparaissent que si vous avez le droit de les consulter.
Au-delà de 10 serveurs sous un même sous-nœud, un nœud « … +N autres » le signale.
La « base de données installée » et le « serveur web installé » sont les logiciels réellement présents sur le serveur (inventaire des logiciels).
Une base managée dans le cloud est une dépendance, pas un logiciel installé : elle apparaît sous le namespace cloud du serveur (connecteurs Amazon Web Services et Microsoft Azure, visibles avec le droit de lecture des connecteurs).
Le rayon d'impact
Cliquer un serveur ouvre son panneau : criticité, risque, équipes, applications, et dépendants directs. L'onglet d'impact calcule tous les serveurs qui dépendent de celui-ci, directement ou par ricochet, sur tout le parc — y compris dans d'autres applications que celle affichée :
- Serveurs impactés — la liste complète ;
- Applications touchées — le nombre et la liste des applications concernées.
C'est la réponse à poser avant toute fenêtre de patch ou toute intervention.
Si l'IA locale est activée, une narration résume l'impact en une phrase lisible par un non-technicien (« patcher ce serveur interromprait potentiellement 3 applications… »). Elle habille le calcul, elle ne le fait pas.
Un impact n'est jamais sous-estimé
Le nombre d'applications touchées est toujours exact, même si certaines vous sont masquées. Les serveurs que vous n'avez pas le droit de voir apparaissent grisés dans la liste, jamais retirés.
Serveurs orphelins
Serveurs orphelins (/topomap/orphans) liste les serveurs rattachés à aucune
application : ils n'apparaissent dans aucune carte, et aucun responsable applicatif
n'est prévenu de leurs patchs.
Pour chacun, Rattacher l'associe à une application. Si l'IA est activée, une suggestion de rattachement est proposée à partir de ses dépendances et de son nommage — toujours à valider par un humain.
Droits
| Permission | Permet |
|---|---|
topomap.read |
Voir les cartes des applications qui vous sont accessibles ; les serveurs privés y sont grisés |
topomap.read_full |
Voir en clair tous les serveurs des applications accessibles — pour la gestion d'incident transverse |
topomap.manage |
Rattacher des serveurs orphelins à une application |
Les dépendances restent toujours visibles, même vers un serveur grisé : masquer un lien fausserait la carte.