La directive NIS2 remet la cartographie des actifs au centre des priorités des DSI. Mais la question posée en interne dépasse rapidement le simple inventaire : que doit-on réellement enregistrer sur un actif, à quoi ces données doivent-elles être reliées, et comment les exploiter au-delà d’un exercice de conformité ponctuel ?
🔥 Nous recommandons Bitdefender
Après avoir analysé et testé de nombreuses solutions, Bitdefender s’impose comme le choix numéro 1 grâce à sa défense proactive, sa discrétion et son absence d'impact sur les performances. Il protège efficacement vos appareils contre les virus, ransomwares et liens suspects tout en préservant l'autonomie et la rapidité de votre machine.
Sécuriser mes appareils avec BitdefenderLa réponse ne se trouve pas dans un tableur d’inventaire technique, mais dans la manière dont une CMDB s’intègre aux processus ITSM : gestion des incidents, gestion des changements, gestion des services métiers. C’est cette articulation qui donne à la cartographie des actifs sa valeur opérationnelle, avec ou sans obligation réglementaire.
Inventaire, CMDB et ITSM : trois niveaux à ne pas confondre
Un inventaire d’actifs recense ce qui existe : serveurs, postes de travail, licences, équipements réseau. Il répond à la question « qu’est-ce que nous possédons ? ». C’est une base nécessaire, mais elle reste statique et déconnectée des usages métiers.
Une CMDB (Configuration Management Database) va plus loin : elle structure ces actifs en Configuration Items (CI) et documente leurs attributs et leurs relations. Elle répond à la question « comment ces éléments s’articulent-ils entre eux ? ». Mais une CMDB isolée, consultée ponctuellement, reste un référentiel documentaire parmi d’autres.
Le troisième niveau, décisif, est celui d’une CMDB intégrée à l’ITSM : les CI et leurs relations ne sont plus une base à consulter, ils deviennent une donnée exploitée en temps réel par les processus d’incidents, de changements et de gestion des services. C’est précisément le rôle d’une solution ITSM en France et en Belgique : centraliser dans un même outil les CI, les services métiers, les incidents et les changements, pour que chaque processus s’appuie sur la même base de données à jour plutôt que sur des référentiels dispersés. C’est cette troisième couche qui transforme la cartographie des actifs NIS2 en outil opérationnel plutôt qu’en livrable d’audit figé dans le temps.
Quel modèle de données CMDB faut-il réellement conserver ?
L’erreur classique dans les projets CMDB est de vouloir documenter un nombre de champs trop important dès le départ, ce qui ralentit l’adoption et complique la maintenance. Un modèle de données CMDB pragmatique repose sur quatre catégories, plus importantes par leur articulation que par leur exhaustivité individuelle.
La première catégorie identifie le CI lui-même : nature de l’actif, environnement, statut de cycle de vie. La deuxième documente la gouvernance : propriétaire métier et propriétaire technique, seuls responsables capables d’arbitrer en cas d’incident ou de valider un changement. La troisième qualifie la criticité, c’est-à-dire l’impact réel sur l’activité si le CI devient indisponible — une notion qui se déduit du rattachement à un service métier, pas de la seule donnée technique. La quatrième, souvent la plus négligée, documente les relations : dépendances applicatives, infrastructurelles et fournisseurs.
Les relations entre CI sont plus importantes que la multiplication des champs
Un CI sans relation documentée reste une fiche isolée. C’est le graphe de relations qui permet de répondre aux questions opérationnelles concrètes : quels services sont affectés si ce serveur tombe, quelles applications dépendent de cette base de données, quel fournisseur est impliqué dans cette chaîne.
La chaîne de dépendances la plus utile en contexte ITSM suit un enchaînement descendant : service métier, puis application, puis infrastructure technique, puis fournisseur ou prestataire externe. Cette chaîne permet de répondre à une question que la conformité NIS2 pose directement : si un composant technique est compromis ou indisponible, quel est l’impact réel sur l’activité ? Sans cette chaîne documentée, l’analyse d’impact repose sur la mémoire des équipes techniques plutôt que sur une donnée structurée et interrogeable.
Ce que la CMDB change lors d’un incident
Prenons un cas concret. Une base de données partagée subit un incident de performance. Sans cartographie des dépendances, l’équipe support découvre au fil des tickets remontés que trois applications distinctes en dépendent. Avec une CMDB correctement structurée, la relation entre la base de données, les applications qui la consomment et le service métier client qu’elles alimentent est déjà documentée. L’équipe d’astreinte identifie immédiatement le périmètre affecté et sa criticité, et peut prioriser la remédiation en fonction de l’impact métier réel plutôt que de la seule nature technique de l’incident.
Sans cette information, la qualification d’un incident repose sur l’expérience individuelle du technicien qui le traite. Avec une CMDB reliée aux services métiers, la priorité peut être calculée à partir d’une donnée structurée : quel service métier est rattaché au CI en panne, quelle est sa criticité déclarée, quels autres CI en dépendent en cascade. Cette approche réduit la part de jugement individuel dans la priorisation et accélère la communication vers les parties prenantes métier concernées — un point que NIS2 valorise directement à travers ses exigences de notification rapide.
Ce que la CMDB change lors d’un changement
Prenons un second cas. Une équipe infrastructure planifie la migration d’un composant réseau partagé par plusieurs environnements applicatifs. Sans cartographie des dépendances, l’évaluation d’impact repose sur la connaissance individuelle de l’équipe porteuse du changement, avec le risque d’oublier une application secondaire mais critique pour un service métier donné.
Une CMDB dont les relations sont maintenues à jour permet de répondre à cette question de façon systématique plutôt qu’au cas par cas. Le comité de changement (CAB) peut s’appuyer sur une cartographie des dépendances réelle pour évaluer un risque, plutôt que sur les seules déclarations de l’équipe technique porteuse du changement. C’est un apport direct à la gestion des risques attendue par NIS2, appliqué non pas comme un exercice réglementaire isolé, mais comme une pratique ITSM courante.
Comment éviter une CMDB obsolète six mois après son lancement
La fraîcheur des données est ce qui distingue une CMDB opérationnelle d’un inventaire figé au moment de sa création. La méthode la plus durable ne consiste pas à créer un processus de mise à jour dédié, rarement suivi dans la durée, mais à rattacher la mise à jour de la CMDB aux workflows ITSM déjà en place.
Un processus de gestion des changements bien conçu inclut la mise à jour des CI concernés comme condition de clôture du changement. Un processus de gestion des incidents peut signaler automatiquement un écart entre l’état déclaré d’un CI et son état constaté. Un processus d’onboarding ou de décommissionnement d’un actif déclenche la création ou l’archivage de la fiche correspondante. C’est cette intégration aux processus existants, plus qu’un audit ponctuel, qui garantit dans la durée la qualité et la fraîcheur des données exploitées dans les analyses de risque NIS2.
Automatiser la collecte sans automatiser la gouvernance
L’automatisation de la découverte des actifs (discovery) est utile pour peupler rapidement les attributs techniques d’une CMDB : présence d’un serveur, version d’un logiciel, adresse réseau. Elle est en revanche incapable de renseigner les données de gouvernance : propriétaire métier, criticité réelle, rattachement à un service.
C’est un point souvent sous-estimé dans les projets CMDB : la découverte technique automatisée réduit la charge de saisie, mais elle ne remplace pas la gouvernance de la donnée. Un outil de discovery peut détecter qu’un serveur existe ; seule une décision humaine documentée peut établir qu’il supporte un service métier critique et qui en est responsable. Confondre les deux conduit à des CMDB techniquement à jour mais inutilisables pour l’analyse de risque ou d’impact.
Comment industrialiser cette approche dans une plateforme ITSM
Sur le plan opérationnel, une plateforme comme HaloITSM permet de centraliser les CI et leurs relations dans un référentiel unique, directement connecté aux modules de gestion des incidents, des problèmes et des changements. Les relations entre service métier, application, infrastructure et fournisseur y sont visibles depuis le ticket lui-même, sans consultation d’un outil séparé, ce qui réduit le délai entre la détection d’un incident et la qualification de son impact réel.
Pour une organisation qui structure sa cartographie des actifs dans une logique NIS2 tout en s’appuyant sur ses pratiques ITSM existantes, mettre en place une CMDB avec HaloITSM permet de démarrer sur un modèle de données volontairement resserré — CI, propriétaires, criticité, relations — puis de l’enrichir progressivement au rythme des besoins réels, plutôt que de viser d’emblée une exhaustivité qui freine l’adoption.
Quels KPI permettent de mesurer la fiabilité de la CMDB ?
La fiabilité d’une CMDB ne se mesure pas par le nombre de CI enregistrés, mais par sa capacité à être exploitée sans friction lors d’un incident ou d’un changement. Quelques indicateurs permettent de suivre cette fiabilité dans le temps plutôt que de la supposer.
La part des CI critiques disposant d’un propriétaire métier renseigné indique si la gouvernance suit réellement le rythme des ajouts techniques. La part des CI reliés à au moins un service métier mesure si la CMDB reste exploitable pour une analyse d’impact, ou si elle redevient un simple inventaire déconnecté. Le délai écoulé depuis la dernière vérification d’un CI critique donne une mesure directe de la fraîcheur de la donnée, plus parlante qu’un pourcentage global de complétude. Le taux de changements pour lesquels une analyse d’impact basée sur la CMDB a été documentée avant validation permet de vérifier que l’outil est réellement utilisé par le CAB, et non contourné. Enfin, l’écart entre les actifs détectés par un outil de discovery et ceux effectivement déclarés dans la CMDB révèle la partie du parc encore hors du champ de gouvernance.
Suivis régulièrement, ces indicateurs évitent l’écueil le plus fréquent : une CMDB perçue comme fiable parce qu’elle est volumineuse, alors qu’elle ne l’est plus dès qu’on cherche à l’exploiter dans l’urgence d’un incident.
Conclusion
Pour NIS2, l’enjeu n’est pas de posséder la CMDB la plus exhaustive possible, mais de disposer d’un modèle de données suffisamment fiable et relationnel pour être exploité dans les processus ITSM lorsque survient un incident, un changement ou une analyse de risque.
