Les bases de la CMDB : pourquoi la qualité des données compte

Définir ce qui mérite une fiche de configuration

Une CMDB n’est pas un entrepôt où l’on copie toutes les données disponibles. Elle décrit les éléments et les relations nécessaires à des processus identifiés. Un serveur peut être important pour comprendre l’hébergement d’une application ; une relation de dépendance peut aider à évaluer un changement. Commencez par les questions auxquelles les équipes veulent répondre : qui exploite ce service, quels composants le soutiennent et quels utilisateurs peuvent être touchés ? Cette approche définit un périmètre utile et évite une accumulation de fiches dont personne ne garantit l’exactitude.

Distinguer actif, CI, service et relation

Un actif concerne notamment la gestion économique ou le cycle de possession d’un élément. Un CI représente un élément de configuration suivi pour l’exploitation et les processus de service. Les deux notions peuvent être liées sans être interchangeables. Un service exprime une capacité fournie à des utilisateurs, tandis qu’une relation décrit un lien entre éléments. Par exemple, un serveur peut héberger une application qui dépend d’une base. Si ces notions sont mélangées dans une seule classe ou dans du texte libre, les recherches et les analyses d’impact deviennent rapidement ambiguës.

Choisir un modèle simple mais extensible

Utilisez des classes adaptées aux objets suivis et privilégiez les attributs réellement nécessaires. Définissez un nom, un environnement, un propriétaire et les identifiants utiles au rapprochement. Ne créez pas une nouvelle classe pour chaque équipe ou chaque variation de nom : une multiplication inutile complique les imports et les rapports. Les modèles recommandés par la plateforme et les principes de CSDM peuvent servir de référence, mais leur adoption doit être liée aux processus visés. Documentez le sens des champs pour que deux équipes n’utilisent pas le même attribut avec des interprétations différentes.

Identifier un élément avant de le mettre à jour

L’identification cherche à savoir si la donnée entrante correspond à un CI déjà présent. Un nom d’hôte seul peut être insuffisant : les noms peuvent changer ou être réutilisés. Définissez les identifiants adaptés à chaque classe et vérifiez leur stabilité. Les règles doivent gérer les valeurs absentes et les sources incomplètes sans créer automatiquement un doublon. Dans ServiceNow, l’IRE fournit un cadre pour appliquer ces règles. L’utilisation correcte des mécanismes de la plateforme est préférable à des scripts qui insèrent librement des fiches sans respecter l’identification commune.

Réconcilier les sources et leurs responsabilités

Après identification, la réconciliation détermine quelles sources peuvent actualiser quels attributs. Un outil de découverte peut être pertinent pour la version du système d’exploitation, tandis qu’un référentiel métier peut être la référence du propriétaire. Laisser chaque source écraser toutes les valeurs produit des changements permanents et difficiles à expliquer. Définissez l’autorité par attribut et prenez en compte la fraîcheur des données. Une mise à jour manuelle doit elle aussi avoir un cadre. La réconciliation ne signifie pas que toutes les sources deviennent identiques ; elle organise leur contribution au même enregistrement.

Exemple : intégrer un inventaire et un compte cloud

Un serveur existe dans un inventaire interne et dans les données du fournisseur cloud. L’inventaire apporte l’équipe responsable ; l’API cloud apporte un identifiant technique et l’état courant. Le traitement rapproche les deux sources avec une clé fiable et applique les règles d’autorité. S’il manque l’identifiant, l’enregistrement est mis en attente ou signalé pour analyse plutôt que fusionné au hasard. Un journal conserve les décisions et les rejets. Cette démarche réduit les doublons tout en permettant d’expliquer pourquoi une valeur a changé et d’où elle provient.

Gérer les relations et le cycle de vie

Les relations doivent avoir un sens et une direction connus. Héberge, dépend de et appartient à ne décrivent pas la même chose. Vérifiez les liens essentiels avec les responsables des services. Prévoyez aussi la fin de vie des éléments : une ressource disparue d’une collecte ne doit pas forcément être supprimée immédiatement, car une indisponibilité temporaire est possible. Définissez des états et des délais adaptés. Conserver une fiche obsolète comme active fausse l’analyse d’impact ; la supprimer trop tôt peut faire perdre un historique utile aux incidents et aux changements.

Organiser la gouvernance avec des responsabilités concrètes

Désignez les propriétaires des classes, les responsables des sources et les personnes chargées de traiter les anomalies. Une gouvernance ne se résume pas à un document : il faut une file de corrections, des délais et une procédure d’escalade. Les équipes doivent savoir qui valide une fusion de doublons ou une modification de modèle. Limitez les droits d’écriture et conservez des traces exploitables. Une donnée critique sans propriétaire est rarement entretenue durablement. Commencez avec un petit groupe de classes dont les responsables peuvent réellement suivre la qualité et étendez ensuite la méthode.

Mesurer qualité et utilité séparément

La complétude mesure les champs renseignés ; la correction évalue leur conformité ; l’actualité indique si les informations sont encore valables. Aucun indicateur ne suffit seul : un champ rempli avec une valeur inconnue peut améliorer artificiellement la complétude. Contrôlez les doublons, les relations incohérentes et l’ancienneté des dernières données fiables. Vérifiez aussi l’usage dans des cas concrets. Si le support peut retrouver le propriétaire d’un service mais pas sa base critique, l’amélioration attendue n’est pas complète, même si un tableau de bord affiche beaucoup de vert.

Déployer la CMDB autour d’un résultat métier

Choisissez un premier objectif, par exemple fiabiliser l’affectation des incidents d’une application ou préparer ses changements. Définissez les CI, relations et attributs nécessaires, intégrez les sources puis testez la qualité avec ce parcours. Tuplify Studio peut développer les intégrations, validations et tableaux de suivi qui soutiennent cette gouvernance. Évitez de lancer toutes les sources simultanément sans mécanisme de correction. Une CMDB progresse par itérations de données et d’usage : chaque extension doit apporter une information exploitable et un responsable capable d’en maintenir la fiabilité.

Atelier : corriger un doublon sans perdre son historique

Prenez deux fiches susceptibles de représenter la même ressource. Comparez les identifiants fiables, les sources, les dates et les relations avant toute fusion. Déterminez si le nom a été réutilisé ou si un équipement a réellement été remplacé : une ressemblance ne suffit pas. Vérifiez les incidents, changements et relations associés afin de conserver les liens utiles. Réalisez l’opération selon les mécanismes et procédures de votre plateforme, dans un périmètre validé. Corrigez ensuite la cause d’entrée du doublon, sinon le prochain import le recréera. La correction durable concerne donc à la fois les fiches existantes, les règles d’identification et la responsabilité de la source qui alimente la CMDB.

Questions fréquentes : complétude et référentiel unique

Faut-il remplir tous les champs ? Les attributs requis dépendent des usages. Un champ systématiquement rempli avec inconnu ne rend pas les données plus fiables.

La CMDB doit-elle remplacer tous les outils ? Elle peut agréger un contexte de configuration sans devenir la source de chaque détail opérationnel ou financier. Définissez les référentiels et leurs responsabilités.

Peut-on mesurer la qualité avec un score unique ? Un score aide à suivre une tendance, mais peut masquer des lacunes sur un service critique. Examinez classes, attributs, relations, fraîcheur et utilité dans les processus. La gouvernance doit permettre d’identifier les problèmes précis et leurs propriétaires, pas seulement de produire une note globale rassurante.