Plan de basculement migration ServiceNow : données, intégrations, risques
Un plan de basculement pratique pour la migration ServiceNow réduit les risques, protège la continuité du service et soutient une modernisation ITSM sereine.
Read more →CMDB cloud · AWS · Azure · Google Cloud
CMDB cloud automatisée et cartographie des dépendances pour vos environnements Kubernetes
Votre parc Kubernetes et cloud change chaque jour, et une CMDB tenue à la main est périmée dès le déploiement suivant. SMC Consulting met en place une CMDB cloud alimentée par une cartographie automatique : une découverte open source cartographie vos clusters sur AWS, Azure ou Google Cloud, un graphe montre ce qui dépend de quoi, et la CMDB HaloITSM reste à jour sans saisie manuelle.
180implémentations ITSM
40+migrations ITSM
25+ans en gestion des services IT
Ils nous font confiance sur leurs projets ITSM
Pourquoi le cloud met en échec la CMDB manuelle
Dans un parc Kubernetes, les pods sont remplacés à chaque déploiement, les nœuds montent et descendent en charge, et les répartiteurs de charge et les enregistrements DNS suivent. Une CMDB remplie à la main décrit la plateforme du mois dernier : les éléments de configuration (CI) sont périmés, les relations manquent, et l'analyse d'impact sur laquelle comptent vos équipes incidents et changements donne la mauvaise réponse.
Une CMDB cloud doit être alimentée par le cloud lui-même. La cartographie des dépendances lit vos comptes et vos clusters, enregistre chaque ressource comme un CI et garde les liens entre elles, du pod à son namespace, à son cluster et aux nœuds sur lesquels il tourne. Quand un élément tombe, vous voyez les services qui reposent dessus ; quand un changement est prévu, vous voyez ce qu'il touche.
Pour la CMDB elle-même, le modèle de données et la pratique ITIL qui la sous-tend, voir la CMDB dans HaloITSM. Cette page couvre la partie cloud et Kubernetes.
La CMDB cloud est une partie de la gestion des services informatiques (ITSM) : les données de configuration sur lesquelles reposent incidents et changements. Vous migrez des charges vers le cloud ? Notre gestion de projets d'infrastructure IT garde la CMDB alignée sur la migration.
Le résultat est une CMDB automatique pour la partie cloud : les CI et leurs dépendances sont recalculés à chaque passage, sans saisie manuelle.
Ce qu'une CMDB cloud automatisée vous apporte
Une CMDB conforme à ce qui tourne
Les CI et leurs relations sont écrits par la découverte, pas saisis : les nouvelles ressources apparaissent, celles supprimées disparaissent, à chaque synchronisation.
L'analyse d'impact pour changements et incidents
Agents et responsables des changements voient les services derrière un nœud ou un namespace avant d'agir, dans HaloITSM.
Des preuves d'actifs pour NIS2
Un inventaire des actifs cloud avec leurs dépendances, prêt quand un auditeur ou une autorité le demande.
Moins de travail manuel
Personne ne met à jour les fiches CI après chaque déploiement ; l'équipe revoit les exceptions au lieu de saisir des données.
Voyez-la tourner sur votre propre compte cloud
Une démo en direct sur l'un de vos clusters : nous lançons la découverte, montrons le graphe et les CI qu'il crée dans HaloITSM.
Ce qui est découvert : des clusters aux pods
La découverte s'appuie sur Cartography, un projet open source hébergé par la Cloud Native Computing Foundation (CNCF). Il lit vos comptes cloud et vos clusters avec un accès en lecture seule et enregistre ce qu'il trouve.
Clusters Kubernetes
Clusters EKS, AKS et GKE, avec leur version, leur région et le compte ou l'abonnement auquel ils appartiennent.
Nœuds et pools de nœuds
Les machines sur lesquelles tourne chaque cluster : un nœud en panne montre les workloads qu'il porte.
Namespaces, pods et workloads
Namespaces, pods, services, déploiements et ingress, lus via le kubeconfig du cluster.
Machines virtuelles
Les instances de calcul hors Kubernetes, dans le même graphe que les clusters.
Réseaux
VPC et réseaux virtuels : vous voyez quelles ressources partagent une même frontière réseau.
Répartiteurs de charge et DNS
Les points d'entrée de vos services, reliés à ce qui se trouve derrière eux.
AWS, Azure et Google Cloud : une méthode, trois clouds
- AWS : clusters EKS et leurs nœuds, machines virtuelles EC2, VPC, répartiteurs de charge et enregistrements DNS.
- Microsoft Azure : clusters AKS, machines virtuelles et réseaux.
- Google Cloud : clusters GKE, instances de calcul et réseaux.
- À l'intérieur de chaque cluster : le module Kubernetes de Cartography lit n'importe quel cluster via son kubeconfig (namespaces, pods, services, nœuds, workloads, ingress) ; l'intérieur d'un cluster AKS ou GKE est donc cartographié comme EKS.
Nous faisons tourner ce dispositif sur AWS pour nous-mêmes. Sur Azure et Google Cloud, les mêmes modules font partie du code de Cartography ; nous validons le périmètre sur votre compte pendant la démo en direct.
Voir le graphe des dépendances : Neo4j et HaloITSM
Un graphe sur lequel on clique
Neo4j, une base de données graphe, contient tout le parc. Cliquez sur un cluster, un nœud ou un répartiteur de charge et vous voyez tout ce qui en dépend, sans lire un seul tableau.
Les relations dans la CMDB HaloITSM
Le connecteur écrit les CI et leurs relations (pod → namespace → cluster → nœuds) dans HaloITSM, là où agents et responsables des changements travaillent déjà.
Des alertes sur le bon CI
Votre outil de supervision (Zabbix, Prometheus…) ouvre un ticket HaloITSM relié au CI concerné, avec ses journaux.
Comment ça marche en 4 étapes : découvrir, cartographier, synchroniser, agir
Quatre étapes, exécutées selon un planning. Le premier passage a lieu pendant la démo en direct, sur un cluster de votre choix.
Découvrir
Cartography analyse le compte cloud : clusters Kubernetes (EKS, AKS, GKE), nœuds, VPC, namespaces, pods, machines virtuelles, répartiteurs de charge et enregistrements DNS.
Cartographier
Les données vont dans Neo4j, une base de données graphe. Vous voyez tout le parc sous forme de graphe et cliquez sur n'importe quel élément pour voir ce qui en dépend.
Synchroniser
Un connecteur écrit les CI et leurs relations dans la CMDB HaloITSM et les garde à jour : les nouvelles ressources apparaissent, celles supprimées disparaissent.
Agir
Les alertes de votre outil de supervision (Zabbix, Prometheus…) ouvrent des tickets HaloITSM reliés au CI, avec les journaux. Une alerte courte qui se résout d'elle-même ferme son ticket ; seuls les vrais problèmes restent ouverts.
Nous l'utilisons nous-mêmes
- Notre propre parc AWS : le dispositif tourne sur notre infrastructure depuis le 1er septembre 2026.
- Environ 295 CI de notre CMDB HaloITSM viennent de la découverte, avec leurs relations, pas d'une saisie manuelle.
- Synchronisée quatre fois par jour : nouveaux pods, nœuds et services apparaissent sans que personne ne touche la CMDB.
- Des alertes qui deviennent des tickets sur le bon CI : les alertes courtes qui se résolvent d'elles-mêmes se ferment seules.
Pour qui
Les équipes plateforme et cloud sur Kubernetes
Qui veulent que le service desk voie le même parc qu'elles exploitent, sans tenir un second inventaire.
Les DSI qui utilisent HaloITSM
Dont la CMDB couvre portables et serveurs mais s'arrête là où commence le cloud.
Les organisations qui se préparent à NIS2
Qui doivent montrer quels actifs cloud soutiennent quels services, et qui en est responsable.
Fonctionne avec Lansweeper et NetBox
Le cloud et Kubernetes sont une source parmi d'autres. Les équipements de votre réseau viennent de Lansweeper, qui alimente HaloITSM via l'intégration HaloITSM et Lansweeper ; les données de datacenter et d'adressage IP peuvent venir de NetBox (DCIM et IPAM). Chaque source rejoint la même CMDB de la même façon, avec une source de référence par classe de CI. Notre service de gestion de parc informatique les réunit.
CMDB cloud et cartographie des dépendances : questions fréquentes
Qu'est-ce que la cartographie des dépendances dans une CMDB ?
La cartographie des dépendances enregistre comment les éléments de configuration dépendent les uns des autres : quels pods tournent dans quel namespace, sur quel cluster et quels nœuds, derrière quel répartiteur de charge. Avec ces relations dans la CMDB, un incident montre les services touchés et un changement montre ce qu'il impacte.
Une CMDB peut-elle se mettre à jour toute seule depuis Kubernetes ?
Oui, quand une découverte l'alimente. Cartography lit les clusters et les comptes cloud selon un planning, et le connecteur écrit le résultat dans la CMDB HaloITSM : les nouvelles ressources sont ajoutées, celles supprimées sont retirées. L'équipe revoit les exceptions au lieu de saisir des données.
Qu'est-ce que Cartography et combien coûte-t-il ?
Cartography est un projet open source hébergé par la CNCF qui cartographie les ressources cloud et Kubernetes dans un graphe. Le logiciel est gratuit. Le coût porte sur la mise en place et l'exploitation de la découverte, que nous cadrons avec vous.
Pourquoi une base de données graphe comme Neo4j pour une CMDB ?
Une base de données graphe stocke les relations comme des données à part entière, exactement ce dont la cartographie des dépendances a besoin : demander ce qui dépend d'un nœud est une seule requête, pas une suite de jointures. Neo4j contient le graphe découvert ; HaloITSM reste la CMDB dans laquelle travaillent vos agents et vos responsables des changements.
Est-ce que cela fonctionne sur Azure AKS et Google GKE, pas seulement AWS ?
Oui. Cartography a des modules pour Azure (clusters AKS, machines virtuelles et réseaux) et Google Cloud (clusters GKE, instances de calcul et réseaux), et son module Kubernetes lit n'importe quel cluster via son kubeconfig. Nous faisons tourner le dispositif sur AWS pour nous-mêmes et validons le périmètre sur votre compte pendant la démo.
Les alertes de supervision peuvent-elles créer des tickets HaloITSM automatiquement ?
Oui. Votre outil de supervision (Zabbix, Prometheus…) envoie ses alertes à HaloITSM, qui ouvre un ticket relié au CI concerné, journaux joints. Une alerte courte qui se résout d'elle-même ferme son propre ticket : seuls les vrais problèmes restent ouverts. Voir l'automatisation et l'orchestration ITSM.
Cartographiez votre cloud dans HaloITSM
Réservez une démo en direct sur votre propre compte cloud : nous lançons la découverte sur un cluster de votre choix et montrons les CI et les relations qu'elle crée.
Articles récents
SMC Consulting, partenaire Lansweeper pour une base IT plus fiable
SMC Consulting rejoint l’écosystème Lansweeper. Connectez la découverte d’actifs à HaloITSM, ServiceNow et Freshservice pour une CMDB complète et toujours à jour.
Read more →
CSRD & IT : mesurer l'empreinte carbone des actifs IT sans outils lourds
Découvrez comment Green ITAM aide à mesurer l'empreinte carbone de vos actifs IT, à améliorer la conformité CSRD IT et à soutenir un reporting de durabilité crédible.
Read more →