Glossaire
CMDB
Une CMDB (Configuration Management Database) est une base de données centralisée qui répertorie l'ensemble des actifs informatiques d'une organisation et leurs relations. Elle est au cœur de la cartographie SI et de la gouvernance ITSM.
Définition de la CMDB
CMDB est l'acronyme de Configuration Management Database, en français base de données de gestion de configuration. C'est un référentiel centralisé qui décrit l'ensemble des éléments de configuration (CI, pour Configuration Items) d'un système d'information et les relations entre ces éléments.
Le concept est issu du référentiel ITIL (Information Technology Infrastructure Library), publié pour la première fois dans les années 1980 par l'agence britannique CCTA, puis repris par AXELOS. ITIL définit la CMDB comme la composante centrale du processus de gestion de la configuration (Service Asset and Configuration Management), un des processus de la phase Service Transition.
Que contient une CMDB ?
Une CMDB répertorie des éléments de configuration, qui peuvent être des actifs physiques ou logiques. Les actifs physiques incluent serveurs, postes de travail, équipements réseau, capteurs IoT. Les actifs logiques incluent applications, services métiers, bases de données, machines virtuelles, conteneurs, namespaces Kubernetes.
À chaque CI sont associés des attributs : identifiant unique, nom, type, propriétaire, environnement (production, qualification, développement), criticité, statut (en service, en maintenance, retiré), version, date d'acquisition, contrat de support associé.
La valeur ajoutée d'une CMDB ne réside pas seulement dans la liste des actifs, mais dans la modélisation des relations entre eux : quelle application tourne sur quel serveur, quel service métier dépend de quelle application, quel flux de données circule entre quels composants. Ces relations sont ce qui rend possible une analyse d'impact lors d'un incident ou d'un changement.
Quelle différence entre une CMDB et un inventaire ?
La confusion entre CMDB et inventaire est fréquente. La distinction tient à la profondeur de modélisation et à la finalité.
Un inventaire est une liste plate d'actifs : combien de serveurs avez-vous, dans quels datacenters, sous quelle version de système d'exploitation. C'est utile pour la gestion budgétaire, le suivi des contrats de support ou la conformité licence. Mais un inventaire ne dit rien sur comment ces actifs interagissent.
Une CMDB ajoute les relations : ce serveur héberge ces trois applications, qui sont consommées par ce service RH, lui-même critique pour le processus paie. Cette modélisation rend la CMDB exploitable pour l'analyse d'impact, la gestion du changement, la planification de la continuité d'activité et la conformité réglementaire (notamment NIS2 et ISO 27001).
Pourquoi les CMDB historiques échouent souvent
L'idée d'une CMDB exhaustive et à jour séduit depuis trente ans, mais le taux d'échec des projets CMDB reste élevé. Les causes sont structurelles.
Première cause : la maintenance manuelle. Une CMDB alimentée à la main par les équipes opérationnelles dérive rapidement vers l'obsolescence. Les changements d'infrastructure quotidiens (provisioning cloud, déploiements CI/CD, mises à jour) saturent toute capacité humaine de saisie.
Deuxième cause : le périmètre trop large. Vouloir inventorier tous les actifs jusqu'au moindre câble réseau noie l'information utile et démobilise les équipes. Les CMDB modernes adoptent une approche de fédération : récupérer dynamiquement les CI depuis les outils de source (CMDB applicative depuis le monitoring, CMDB infrastructure depuis l'IaC, CMDB applicative depuis le code source).
Troisième cause : l'absence d'usage métier clair. Une CMDB qui ne sert qu'à elle-même n'est jamais maintenue. Lier la CMDB à des cas d'usage concrets — analyse d'impact d'incident, simulation de changement, audit de conformité — est ce qui justifie son entretien.
CMDB et cartographie SI : la nouvelle génération
Depuis les années 2020, la notion de CMDB tend à fusionner avec celle de cartographie applicative dynamique. Les plateformes modernes ne demandent plus aux équipes d'alimenter manuellement une base : elles se branchent sur les sources de vérité existantes (CMDB héritées, monitoring type Datadog ou Prometheus, IaC type Terraform, configurations cloud type AWS Config) et reconstruisent en continu la cartographie applicative.
C'est cette approche que NIS2 et ISO 27001 valorisent désormais : la conformité ne demande plus une CMDB exhaustive figée, mais une cartographie vivante capable de prouver à tout moment l'état du SI, ses dépendances critiques et son exposition aux risques.
Questions fréquentes
ITIL est-il obligatoire pour avoir une CMDB ?
Non, ITIL est un référentiel de bonnes pratiques, pas une norme. Vous pouvez exploiter une CMDB sans formaliser tout un cadre ITIL. En pratique, beaucoup d'organisations adoptent les concepts (CI, relations, processus de changement) sans la lourdeur administrative complète.
Quelle est la différence entre une CMDB et un référentiel d'architecture ?
Une CMDB est centrée sur les éléments de configuration et leur exploitation opérationnelle. Un référentiel d'architecture (souvent appelé EA, Enterprise Architecture) inclut la vision métier, les capacités fonctionnelles et la trajectoire d'évolution. Une plateforme moderne fait souvent les deux à partir d'un noyau de données unique.
Combien coûte la mise en place d'une CMDB ?
Très variable selon l'approche. Les CMDB traditionnelles avec saisie manuelle exigent souvent plusieurs ETP à temps plein et un projet de 12 à 24 mois. Les approches modernes par fédération de sources (Uncia, par exemple) atteignent un premier état exploitable en quelques semaines, sans équipe dédiée.