Une CMDB n’est presque jamais fausse parce que l’outil est mauvais. Elle l’est parce que personne n’est chargé de la confronter au terrain, à intervalle fixe, avec des règles écrites. Ce texte décrit le travail qui manque : le rapprochement.
Qu’est-ce qu’une CMDB, et pourquoi la vôtre est-elle fausse ?
Dans ITIL, le référentiel de gestion des services informatiques (ITSM), la CMDB sert la pratique de gestion de la configuration des services. Elle devient fausse dès qu’un changement passe sans la traverser : un équipement remplacé en urgence, une adresse réattribuée, un serveur décommissionné sans ticket.
Le catalogue de mesures SP 800-53 (révision 5) du National Institute of Standards and Technology en fait une exigence. Sa mesure CM-8(1) demande de « mettre à jour l’inventaire des composants du système dans le cadre des installations et retraits de composants et des mises à jour du système » (traduit de l’anglais).
La cause n’est pas technique. ServiceNow, GLPI, iTop ou Jira Service Management savent tous stocker des éléments et leurs liens. Ce qu’aucun outil ne fait seul, c’est décider qu’un enregistrement est faux, lequel des deux est juste et qui corrige. Ce travail a besoin d’un responsable et de règles. Sans eux, la CMDB dérive, comme une cartographie du SI qui n’est pas produite par l’exploitation.
Que contient une CMDB, concrètement ?
Des éléments de configuration (en anglais configuration items, ou CI), rangés par classes : équipements physiques, machines virtuelles, logiciels, liens réseau, services rendus. Chaque élément porte des attributs : identifiant, emplacement, propriétaire, statut dans son cycle de vie (commandé, en production, retiré).
Il porte surtout des relations. Un service s’appuie sur une application, qui tourne sur des machines virtuelles, hébergées sur des serveurs, raccordés à des commutateurs. C’est cette chaîne de dépendances qui répond à « qu’est-ce qui est touché ? » pendant un incident. La découverte trouve les éléments et une partie des liens techniques. Les liens vers les services rendus sont déclarés par une personne, et aucune source automatique ne les confirme.
CMDB, inventaire, gestion des actifs : quelle différence ?
Les trois décrivent souvent les mêmes éléments, mais pas les mêmes attributs. L’inventaire liste ce qui existe. La gestion des actifs (ITAM) suit chaque bien de l’achat à la mise au rebut, pour en maîtriser les coûts et les risques. La CMDB décrit ce qui sert à rendre un service et ce qui en dépend. D’où la règle d’une source qui fait foi par attribut, détaillée plus bas.
Que faut-il rapprocher, et avec quoi ?
Il faut rapprocher trois versions de l’existant, qui ne disent jamais exactement la même chose.
| Version | D’où elle vient | Ce qu’elle sait | Ce qu’elle ignore |
|---|---|---|---|
| Déclarée | CMDB, source de vérité réseau, achats, contrats | Ce qui devrait exister, à qui, pour quel service | Ce qui a changé sans être déclaré |
| Découverte | Scans, agents d’inventaire, interrogation des équipements | Ce qui répond, avec sa configuration réelle | Le propriétaire, le service, ce qui est éteint |
| Supervisée | Outil de supervision, collecte de métriques | Ce qui est surveillé et dans quel état | Ce qui n’a jamais été ajouté à la supervision |
Chaque écart entre deux versions est une information. Un équipement découvert mais absent de la CMDB signale un changement non déclaré. Un élément déclaré mais jamais découvert est éteint ou hors de portée du scan. Un élément déclaré mais non supervisé est un angle mort pour l’astreinte.
Sur quelles clés rapprocher deux enregistrements ?
On rapproche sur des identifiants stables, dans un ordre de confiance fixé à l’avance.
| Clé | Stabilité | Piège courant |
|---|---|---|
| Numéro de série | Forte, liée au matériel | Absent sur les machines virtuelles, mal saisi à la réception, celui du châssis confondu avec celui d’un module |
| Identifiant d’actif (étiquette interne) | Forte si l’étiquetage est discipliné | Étiquette jamais posée ou réutilisée après une mise au rebut |
| Nom d’hôte | Moyenne | Conventions qui changent, doublons entre environnements, nom court contre nom complet |
| Adresse IP ou MAC | Faible | Réattribution, cartes remplacées, plusieurs interfaces par équipement |
La règle pratique : une correspondance sur une clé forte suffit ; une correspondance sur une clé faible seule ne suffit jamais. Deux clés moyennes concordantes peuvent suffire, si vous l’avez écrit. Tout le reste part dans la file des cas ambigus.
Quelle source fait foi pour chaque attribut ?
Chaque attribut a une seule source qui fait foi, et elle n’est pas la même pour tous. C’est la décision qui évite les allers-retours entre outils qui s’écrasent mutuellement.
| Attribut | Source qui fait foi |
|---|---|
| Existence et configuration réelle | Découverte |
| Emplacement physique, baie, position | Source de vérité réseau ou outil de gestion du datacenter |
| Adressage prévu, réseaux virtuels, préfixes | Source de vérité réseau |
| Propriétaire, service rendu, criticité | CMDB, renseignée par une personne |
| Contrat, garantie, fin de support | Achats ou gestion des contrats |
| État de surveillance | Supervision |
Écrivez ce tableau pour votre parc : il dit, pour chaque écart, quelle valeur l’emporte et où corriger.
Comment traiter les écarts sans tout réécrire à la main ?
On traite les écarts en entonnoir : des règles déterministes d’abord, un examen des cas ambigus ensuite, une validation humaine avant toute écriture.
- Règles déterministes. Correspondance sur une clé forte et attribut dont la source fait foi : la correction est proposée automatiquement. Un script applique ces règles de façon incrémentale, sur ce qui a changé depuis le dernier passage.
- Cas ambigus. Clés contradictoires, nom proche mais numéro de série différent, élément découvert sans propriétaire. Ces cas demandent de croiser des indices : tickets récents, historique de changements, emplacement. C’est là qu’un traitement assisté fait gagner du temps, sur un résidu et non sur tout le parc.
- Validation humaine. Rien n’est écrit dans la CMDB sans qu’une personne responsable de la classe concernée l’ait accepté. Chaque correction garde sa trace : source, règle appliquée, auteur de la validation.
C’est la logique que nous appliquons au modèle de données, détaillée dans le guide sur l’automatisation en entonnoir.
Comment savoir si la CMDB est juste ?
On le sait en mesurant deux choses distinctes, la fraîcheur et la justesse, par classe d’éléments plutôt que globalement.
- Fraîcheur : âge de la dernière confirmation de chaque élément par une source automatique. Suivez-en la médiane.
- Taux de rapprochement : part des éléments découverts qui correspondent à un élément déclaré.
- Taux d’écart : part des éléments rapprochés dont au moins un attribut diffère de sa source qui fait foi.
- Couverture de supervision : part des éléments déclarés en production qui sont supervisés.
- Âge des écarts ouverts : délai entre la détection d’un écart et sa résolution.
- Vérification terrain : sur un échantillon tiré au hasard, part des fiches exactes après contrôle physique ou à distance.
La dernière mesure est la seule qui ne dépend pas des outils eux-mêmes. Faites-la à intervalle régulier, même sur un petit échantillon.
CMDB ou NetBox : laquelle est la source de vérité ?
Les deux, sur des attributs différents. NetBox se présente comme la source de vérité de l’infrastructure réseau : il définit l’état voulu des composants et n’interroge pas les équipements lui-même.
La CMDB de l’outil de tickets relie les éléments aux services, aux incidents et aux changements. Une organisation qui exploite les deux doit décider lequel fait foi pour chaque attribut, et synchroniser dans un seul sens. Deux outils qui font foi sur le même attribut produisent des écarts que personne ne sait trancher.
Que change une CMDB juste pour les incidents et les changements ?
Elle raccourcit le diagnostic et rend l’analyse d’impact des changements crédible. Pendant un incident, la question est toujours la même : qu’est-ce qui est touché, qu’est-ce qui en dépend, qui doit intervenir. Si la CMDB y répond juste, le diagnostic se mesure en minutes ; sinon, il se reconstitue au téléphone. C’est souvent la plus longue étape d’un temps de rétablissement mesuré honnêtement.
Pour les changements, l’analyse d’impact n’a de valeur que si les relations sont à jour. Un changement validé sur une CMDB fausse est un changement validé à l’aveugle. À l’inverse, chaque changement clos est l’occasion de confirmer les éléments touchés.
Par où commencer ?
Par une classe d’éléments critique, pas par tout le parc. Écrivez les questions auxquelles la CMDB doit répondre sans appel téléphonique. Écrivez les clés de rapprochement de cette classe et sa table des sources qui font foi. Nommez un responsable. Lancez un rapprochement, traitez les écarts et mesurez le taux d’écart. Recommencez à intervalle fixe, puis étendez à la classe suivante.
Questions fréquentes
Qu’est-ce qu’une CMDB, en une phrase ?
Une base de données de gestion des configurations (en anglais configuration management database) : elle recense les éléments de configuration (équipements, logiciels, services, liens), leurs attributs et leurs relations, pour que les incidents et les changements s’appuient sur une description partagée de l’existant.
Une découverte automatique suffit-elle à tenir la CMDB à jour ?
Non. La découverte dit ce qui répond sur le réseau, pas ce qui devrait exister, à qui cela appartient ni quel service en dépend. Elle est une source parmi d’autres. Sans rapprochement avec le déclaré, elle ajoute des fiches sans corriger les fausses.
Quel est le lien entre la CMDB et ITIL ?
ITIL, le référentiel de gestion des services informatiques (ITSM), décrit une pratique de gestion de la configuration des services. Son but : fournir une information exacte et fiable sur la configuration des services et des éléments qui les soutiennent, relations comprises. La CMDB est la base qui porte cette information. ITIL dit ce qu’elle doit permettre, pas comment la garder juste.
Quelle part d’écarts est acceptable ?
Il n’existe pas de seuil universel. Mesurez le taux d’écart par classe d’éléments, fixez un objectif pour les classes critiques et suivez sa tendance. Un taux stable ou en baisse vaut mieux qu’un chiffre bas mesuré une seule fois.
Qui doit être responsable de la CMDB ?
Une personne nommée par classe d’éléments, avec du temps prévu pour traiter les écarts. Un responsable de l’outil qui n’a ni l’autorité ni le temps de corriger les données ne suffit pas.
Sources
- National Institute of Standards and Technology, SP 800-53 révision 5, mesure CM-8(1) (inventaire des composants)
- PeopleCert, ITIL 4 Practitioner : Service Configuration Management (objet de la pratique)
- PeopleCert, ITIL 4 Practitioner : IT Asset Management (cycle de vie des actifs)
- ANSSI, guide « Cartographie du système d’information » (2018)
- NetBox, présentation du projet sur GitHub (source de vérité, état voulu)