La CMDB n'est pas une base de données, c'est une discipline

On me pose souvent la question, en réunion de cadrage, avec un agenda et une deadline : « Combien de temps pour monter notre CMDB ? » Et à chaque fois, je réponds par une autre question, qui jette un froid : « Combien de temps pour la tenir ? » Parce qu'une CMDB, ça ne se monte pas. Ça se tient. Le jour où on a compris ça, on a réglé la moitié du problème.

J'ai vu des CMDB magnifiques. Vraiment. Des modèles de données ciselés, des centaines de types d'éléments de configuration, des relations dans tous les sens, livrés par un intégrateur sérieux, validés en comité, applaudis en steering. Six mois plus tard, la même CMDB était devenue un cimetière : des serveurs décommissionnés toujours « actifs », des applications rattachées à des machines qui n'existaient plus, et — symptôme imparable — un tableur Excel parallèle que tout le monde utilisait vraiment pour savoir qui appeler en cas d'incident.

Pourquoi les CMDB meurent

Elles meurent toujours pour les mêmes raisons, et aucune n'est technique :

• Personne ne la consomme. Une CMDB qui ne sert à aucun processus se périme à la vitesse du SI — c'est-à-dire très vite. Si votre gestion d'incident, de changement ou votre analyse d'impact ne s'appuient pas dessus, elle est déjà morte, elle ne le sait juste pas encore.
• On l'a modélisée trop fin. Vouloir tout décrire, jusqu'à la barrette mémoire, c'est se condamner à une maintenance impossible. La précision a un coût, et ce coût se paie tous les jours.
• On l'alimente à la main. Toute donnée saisie manuellement est fausse le lendemain. Sans découverte automatisée et sans réconciliation, vous ne tenez pas une CMDB, vous entretenez une fiction.
• Personne n'en est propriétaire. Pas de data owner, pas de cycle de vie, pas de gouvernance : la donnée dérive, et la confiance s'effondre. Et une CMDB en laquelle personne n'a confiance, c'est pire que pas de CMDB.

Une CMDB fausse est pire qu'une absence de CMDB : elle vous fait prendre de mauvaises décisions avec assurance.

Commencer par l'usage, jamais par le modèle

La plus grosse erreur, c'est de démarrer par un atelier de modélisation de trois mois. On finit avec un schéma somptueux que personne n'utilise. Je fais l'inverse : je pars de l'usage.

Quelles décisions voulez-vous que la CMDB éclaire ? « Si ce serveur tombe, quels services métier sont touchés ? » « Ce changement, sur quoi va-t-il impacter ? » « Cet incident, quelle application, quel responsable ? » Trois cas d'usage concrets suffisent à dicter le modèle juste : ni trop fin, ni trop grossier. Le modèle découle de l'usage, jamais l'inverse.

La donnée doit venir toute seule

Une CMDB qui tient, c'est une CMDB qui s'alimente automatiquement : découverte du parc, cartographie des dépendances applicatives, réconciliation des sources (inventaire, cloud, virtualisation, conteneurs) selon des règles de priorité claires. L'humain ne saisit plus : il arbitre les exceptions et garantit la qualité. C'est un changement de posture radical — et c'est le seul qui fonctionne.

Ajoutez à cela un vrai cycle de vie : un élément de configuration naît, vit, est modifié, puis est décommissionné — et la CMDB doit refléter ces étapes sans intervention manuelle. Le décommissionnement, en particulier, est le grand oublié : c'est lui qui transforme une CMDB en cimetière quand on le néglige.

Ce que ça donne avec une bonne plateforme

Tout ce que je viens de décrire — modèle commun, réconciliation, modélisation de services, alimentation automatique, consommation par les processus — c'est exactement ce que fait BMC Helix CMDB. Un modèle de données normalisé (le Common Data Model), un moteur de réconciliation qui arbitre les sources, une cartographie de services alimentée par la découverte automatisée, et une CMDB réellement consommée par l'ITSM et l'AIOps de la même plateforme. Bref : une CMDB qui n'a aucune raison de redevenir un cimetière, parce qu'elle vit au cœur des opérations au lieu d'être un référentiel posé à côté.