CMDB — Définition IT

La CMDB (Configuration Management Database, ou base de données de gestion des configurations) est le référentiel central qui décrit les composants du système d'information et, surtout, les relations qui les lient. Serveurs, applications, bases de données, équipements réseau, licences : chaque élément y est enregistré sous forme de Configuration Item (CI), avec ses attributs et ses dépendances.

Sa valeur ne tient pas à l'inventaire — beaucoup d'outils savent lister des actifs — mais au graphe de dépendances. Savoir qu'un serveur existe est utile ; savoir que son arrêt coupera la paie de 3 000 collaborateurs est décisif.

Formalisée par le référentiel ITIL, la CMDB est le socle des processus de gestion des services informatiques (ITSM).

Ce que contient une CMDB

Quatre briques structurent le modèle de données :

• •Les Configuration Items (CI): : toute entité gérée du SI — matériel, logiciel, service, contrat, voire documentation.
• •Les attributs: : les propriétés de chaque CI (version, propriétaire, criticité, environnement, date de mise en service).
• •Les relations: : le cœur du dispositif. « Dépend de », « héberge », « est utilisé par », « se connecte à ».
• •L'historique: : la trace des changements dans le temps, indispensable pour comprendre une régression.

Le modèle de données — ou méta-modèle — détermine la valeur de l'ensemble. Trop fin, il devient impossible à maintenir ; trop grossier, il ne répond à aucune question utile.

À quoi sert concrètement une CMDB

Quatre usages justifient l'investissement.

L'analyse d'impact. Avant un changement, savoir ce qui sera affecté. C'est l'usage le plus rentable : il transforme une décision au doigt mouillé en décision documentée.

La résolution d'incidents. Quand un service tombe, remonter la chaîne de dépendances pour identifier la cause racine au lieu de sonder chaque équipe.

La gestion des changements. Instruire les demandes avec une vision des risques réels, et non des risques supposés.

La conformité et l'audit. Prouver que l'on sait ce que l'on exploite : une exigence désormais explicite dans NIS2 et DORA.

CMDB, ITAM, EAM : qui fait quoi

Les trois disciplines partagent la donnée d'inventaire mais répondent à des questions différentes :

• •La CMDB répond à « comment ça marche ? » — dépendances, configuration, impact. Angle opérationnel.
• •L'ITAM répond à « combien ça coûte ? » — contrats, licences, cycle de vie financier. Angle économique.
• •L'EAM répond à « où va-t-on ? » — architecture cible, capacités métier, trajectoire. Angle stratégique.

Ces angles se complètent. Les cloisonner dans trois outils qui ne se parlent pas est l'une des causes les plus fréquentes d'échec.

Les quatre écueils classiques

Les projets CMDB ont mauvaise réputation, et pour de bonnes raisons.

L'exhaustivité comme objectif. Vouloir tout modéliser avant de produire la moindre valeur. Ces projets s'enlisent avant la première livraison. La bonne approche part d'un service critique et s'étend par cercles concentriques.

L'alimentation manuelle. Une CMDB tenue à la main est fausse en quelques semaines. Sans découverte automatique, la donnée se périme plus vite qu'elle n'est saisie.

L'absence de propriétaire. Sans responsable désigné par domaine, personne ne corrige les écarts et la confiance s'effrite. Une CMDB dans laquelle les équipes ne croient plus est un actif mort.

Le modèle de données figé. Le SI évolue ; un méta-modèle conçu une fois pour toutes devient un carcan.

Comment mettre en place une CMDB qui tient

Une démarche qui fonctionne suit quatre temps :

1. Cadrer par les usages. Partir des questions auxquelles la CMDB doit répondre, et non des données disponibles. Deux ou trois cas d'usage prioritaires suffisent à définir le périmètre.
2. Automatiser la découverte. Agents, connecteurs, SSO, scan réseau, API cloud : la donnée doit se collecter seule.
3. Réconcilier les sources. Dédoublonner et arbitrer les conflits entre sources, avec une règle de priorité explicite par type de donnée.
4. Gouverner dans la durée. Propriétaires nommés, indicateurs de fraîcheur, revue périodique des écarts.

Faut-il encore une CMDB en 2026 ?

La question se pose légitimement. Le modèle classique — un référentiel exhaustif alimenté par un projet centralisé — a été conçu pour des SI stables, majoritairement internes. Il résiste mal au SaaS, au cloud élastique et au Shadow IT, où les actifs apparaissent et disparaissent sans passer par la DSI.

Ce qui reste indispensable, c'est la connaissance des dépendances. Ce qui a changé, c'est la manière de l'obtenir : par la découverte continue plutôt que par la déclaration, et en plaçant l'application — et non le serveur — au centre du modèle.

L'approche Kabeen

Kabeen part de l'usage réel : les applications sont découvertes automatiquement, leurs flux de données et leurs dépendances sont reconstruits en continu, et chaque application porte ses coûts, ses contrats et ses usages.

Vous obtenez la valeur qu'on attend d'une CMDB — analyse d'impact, dépendances, gouvernance — sans le projet de dix-huit mois ni la maintenance manuelle qui le suit. Découvrez notre approche de la cartographie du portefeuille applicatif.