Une CMDB (Configuration Management Database) est un référentiel qui recense les éléments de configuration d’un système d’information et modélise les relations qui les lient, servant de source de vérité pour la gestion des incidents, des changements et des risques. Mal entretenue, elle se périme en quelques semaines et ne sert plus à rien.
Tout l’enjeu tient dans la mise à jour. Cet article explique pourquoi la CMDB est un actif stratégique, pourquoi tant de projets échouent, et surtout comment la maintenir fiable dans la durée : périmètre piloté par l’usage, découverte automatique, gouvernance et indicateurs de qualité.
Une CMDB centralise les informations de configuration des composants du SI. Chaque élément de configuration (CI) peut être un serveur, un poste, un logiciel, un service métier, un contrat ou même un utilisateur. La valeur ne vient pas de la simple liste de ces CI, mais de la cartographie de leurs dépendances : quel serveur héberge quelle application, laquelle soutient quel service métier, et ainsi de suite.
Dans le cadre ITIL 4 : comprendre les pratiques essentielles, la CMDB s’inscrit dans un ensemble plus large, le système de gestion des configurations (CMS), lui-même partie du système de gestion des connaissances (SKMS). ITIL 4 a par ailleurs scindé l’ancien processus SACM en deux pratiques distinctes, aux publics différents : ITAM (gestion des actifs, centrée sur le cycle de vie et le coût) et SCM (gestion des configurations de services, centrée sur les CI et leurs relations). La CMDB est l’outil central de cette seconde pratique.
A lire aussi >> Les étapes clés d’un audit infrastructure informatique
Une CMDB fiable irrigue la plupart des processus de la DSI. Ses usages concrets sont nombreux :
L’enjeu est réel, et le marché le confirme : il pesait environ 1,67 milliard de dollars en 2024, avec une croissance annuelle estimée à plus de 15 % (Growth Market Reports, 2025). Pourtant, le même secteur affiche un paradoxe brutal.
Selon une estimation de Gartner relayée en 2025, 75 à 80 % des projets de CMDB n’apporteraient pas la valeur métier attendue. Ce taux d’échec n’est pas dû à l’absence de CMDB, mais à la façon dont elles sont conçues et entretenues. Les causes reviennent toujours :
On définit d’abord à quelles questions la CMDB doit répondre (analyse d’impact d’un changement, rattachement d’une vulnérabilité, support d’un service critique), puis on en déduit le périmètre et la profondeur des CI à gérer. Mieux vaut couvrir parfaitement les services critiques que mal couvrir tout le SI.
La découverte automatique (discovery) recense les CI et leurs attributs en continu, en particulier dans les environnements cloud où l’infrastructure est éphémère. Le service mapping cartographie les dépendances en analysant le trafic et les logs. C’est le seul moyen réaliste de suivre le rythme des changements.
La fédération synchronise la CMDB avec les systèmes tiers (annuaire, gestion de parc, supervision, cloud) pour enrichir les CI. Des règles de réconciliation désignent la source de vérité de chaque attribut et éliminent les doublons, afin que deux outils ne se contredisent pas.
La règle d’or : toute modification du SI passe par la gestion des changements, et toute gestion des changements met à jour la CMDB. C’est ce couplage qui empêche le référentiel de diverger de la réalité entre deux découvertes automatiques.
Chaque type de CI doit avoir un propriétaire responsable de sa qualité. Sans cette gouvernance, la CMDB devient l’affaire de personne. On associe les équipes, on les forme et on intègre la CMDB à leurs gestes quotidiens plutôt que d’en faire un outil isolé.
On ne maintient que ce que l’on mesure. Un tableau de bord de santé suit quelques indicateurs simples et déclenche les corrections. Les principaux :
| Indicateur | Ce qu’il mesure | Cible indicative |
| Complétude | Part des actifs réellement présents dans la CMDB sur le périmètre cible | Proche de 100% |
| Exactitude | Part des CI dont les attributs sont corrects (vérifiée par audit) | Elevée et stable |
| Fraîcheur | Délai depuis la dernière mise à jour ou découverte d’un CI | Quelques jours au plus |
| Couverture des relations | Part des CI dont les dépendances sont renseignées | Suffisante pour l’analyse d’impact |
| Taux d’alimentation automatique | Part des CI alimentés par découverte plutôt que saisie manuelle | À maximiser |
| Doublons et CI orphelins | Anomalies de qualité à corriger | Tendre vers zéro |
Le choix dépend de trois facteurs : la taille du parc, la maturité ITSM et le budget. Le marché francophone est dominé par quelques acteurs, dont deux solutions open source d’origine française.
| Outil | Profil | Points clés |
| ServiceNow | Enterprise, leader mondial | CMDB intégrée au CSDM, Service Mapping, Discovery, suite ITSM complète |
| GLPI | Open source, dominant en France | Inventaire et CMDB, agent de découverte, intégration AD/LDAP ; PME, collectivités, éducation |
| iTop (Combodo) | Open source, français | CMDB et ITSM alignés ITIL, modélisation des CI et de leurs relations |
| Snipe-IT | Open source | Orienté gestion d’actifs (ITAM) plus que relations de configuration |
| i-doit | Open source | CMDB documentaire fondée sur un modèle de relations |
Un repère utile : sur Gartner Peer Insights en 2025, GLPI et ServiceNow obtiennent de bonnes notes, GLPI étant particulièrement apprécié dans les structures au budget contraint disposant d’une équipe technique. Quel que soit l’outil, deux capacités font la différence pour la mise à jour : la découverte automatique et la qualité du service mapping. Un outil qui se résume à un dépôt d’actifs sans automatisation reproduira les échecs décrits plus haut.
Les six leviers précédents adressent les causes structurelles d’échec ; au quotidien, ce sont souvent les mêmes erreurs ponctuelles qui font dérailler un projet de CMDB déjà bien engagé. Voici les six pièges les plus fréquents à surveiller.
L’ITAM gère le cycle de vie et le coût des actifs ; la CMDB modélise les éléments de configuration et leurs relations pour soutenir la gestion des services. ITIL 4 en a d’ailleurs fait deux pratiques distinctes (ITAM et SCM). Elles sont complémentaires : l’une répond à « que possède-t-on ? », l’autre à « qu’est-ce qui dépend de quoi ? ».
En continu pour la partie automatisée (découverte et fédération), et à chaque changement pour la partie pilotée par les processus. Des revues périodiques de qualité complètent le dispositif. Une CMDB qui n’est mise à jour que ponctuellement n’est plus fiable.
En suivant des indicateurs de santé : complétude, exactitude, fraîcheur, couverture des relations et taux d’alimentation automatique. Des audits réguliers confrontent le référentiel à la réalité du terrain.
Non. Le périmètre doit être piloté par les cas d’usage. Une CMDB partielle mais fiable apporte bien plus qu’une CMDB exhaustive et ingérable, qui finit par n’être plus utilisée.
Selon la taille du parc, la maturité ITSM et le budget. GLPI et iTop (open source, français) conviennent aux organisations techniques au budget maîtrisé ; ServiceNow s’adresse aux grands comptes recherchant une plateforme ITSM complète avec découverte et service mapping intégrés.
