Le véritable enjeu d’une CMDB ITSM n’est pas sa création, mais sa capacité à rester fiable dans le temps. Cela suppose de maintenir des Configuration Items (CI) correctement identifiés, réconciliés et contextualisés pour être réellement utilisés dans les incidents, les problèmes et les changements.
L’automatisation apporte une réponse à ce problème, à condition de ne pas confondre découverte des actifs, synchronisation des données et gouvernance de la CMDB.
Sommaire
Une CMDB remplie n’est pas nécessairement une CMDB fiable
Le volume de CI constitue un mauvais indicateur de maturité.
Une CMDB peut contenir plusieurs milliers d’éléments et rester difficilement exploitable si les informations sont anciennes, dupliquées ou dépourvues de contexte. À l’inverse, un périmètre plus restreint mais correctement gouverné peut apporter davantage de valeur aux équipes opérationnelles.
Prenons un serveur enregistré comme CI. Sa fiche indique son système d’exploitation, son adresse IP, les applications associées et le service qu’il supporte. Quelques mois plus tard, le serveur existe toujours mais sa configuration a changé.
Le CI est présent. La CMDB semble complète. Pourtant, l’information n’est plus nécessairement fiable.
La qualité doit donc être évaluée selon plusieurs dimensions :
- exactitude : les informations correspondent-elles à l’environnement réel ?
- fraîcheur : quand ont-elles été vérifiées ou mises à jour ?
- unicité : un même actif existe-t-il sous plusieurs CI ?
- complétude utile : les attributs nécessaires aux processus ITSM sont-ils renseignés ?
- contexte : le CI est-il correctement relié à un utilisateur, une application ou un service ?
La question n’est finalement pas « combien de CI avons-nous ? », mais plutôt : pouvons-nous utiliser ces données avec confiance lorsqu’un incident ou un changement survient ?
Automatiser la collecte sans transformer la CMDB en entrepôt de données
La saisie manuelle reste pertinente pour certaines informations : criticité d’un service, propriétaire métier, règles de support ou relations organisationnelles, par exemple.
Elle atteint en revanche rapidement ses limites lorsqu’il faut maintenir des milliers d’informations techniques qui évoluent en permanence.
L’Asset Discovery permet d’automatiser une partie de cette collecte. Une solution de découverte peut identifier les équipements présents dans l’environnement et récupérer différentes caractéristiques techniques : OS, logiciels installés, informations réseau, machines virtuelles ou ressources cloud.
Une intégration HaloITSM et Lansweeper permet ensuite de faire circuler les informations pertinentes issues de la découverte vers l’environnement ITSM.
Mais la logique ne devrait jamais être :
actif découvert → CI automatiquement créé.
Une architecture plus robuste suit plutôt cette chaîne :
Découverte → qualification → normalisation → réconciliation → synchronisation → exploitation dans l’ITSM.
Cette étape intermédiaire est essentielle. Sans règles de sélection et de rapprochement, l’automatisation risque surtout d’augmenter le volume de données à contrôler.
Tous les actifs découverts n’ont pas leur place dans la CMDB
Une solution d’Asset Discovery peut identifier un très grand nombre d’objets techniques. Cela ne signifie pas que chacun doit devenir un CI.
La CMDB n’a pas vocation à reproduire l’intégralité de l’inventaire.
Son périmètre doit dépendre des usages ITSM auxquels elle répond. Avant d’importer une catégorie d’actifs, il est donc préférable de déterminer pourquoi l’information doit être présente dans la CMDB et quel processus va l’utiliser.
Par exemple :
- pour l’Incident Management, identifier rapidement l’équipement ou le composant concerné et son contexte peut accélérer le diagnostic ;
- pour le Problem Management, rapprocher plusieurs incidents de CI présentant des caractéristiques communes peut aider à identifier des tendances ;
- pour le Change Management, connaître les dépendances entre composants, applications et services facilite l’analyse d’impact ;
- pour l’IT Asset Management, les informations liées au cycle de vie, à l’utilisation et au statut de l’actif deviennent particulièrement importantes.
Le bon niveau de granularité n’est donc pas celui qui permet d’importer le plus d’informations. C’est celui qui fournit suffisamment de contexte aux processus qui en ont besoin.
Le principal risque de l’automatisation : multiplier les versions d’un même actif
Un poste de travail peut être simultanément connu par une solution de découverte, Microsoft Intune, Entra ID, un outil de sécurité et la plateforme ITSM.
Ces différentes sources peuvent contenir des informations complémentaires, mais aussi contradictoires.
Si chaque système est autorisé à créer ou modifier librement les CI, l’automatisation peut produire exactement l’effet inverse de celui recherché : doublons, attributs écrasés et perte de confiance dans la CMDB.
La réconciliation devient donc une composante centrale du modèle.
Il faut notamment définir :
- les attributs permettant d’identifier de manière fiable un actif existant ;
- les règles appliquées lorsqu’un identifiant change ;
- la source de référence pour chaque type de donnée ;
- le comportement à adopter lorsqu’une information est absente ou contradictoire ;
- les conditions dans lesquelles un nouveau CI peut être créé.
La réconciliation ne consiste pas simplement à supprimer les doublons après leur apparition. Elle doit empêcher leur création autant que possible.
La “source de vérité” unique est souvent un mauvais objectif
Dans les environnements IT modernes, vouloir désigner un seul système comme source de vérité pour l’ensemble des attributs d’un CI est rarement réaliste.
La gouvernance doit parfois être définie attribut par attribut plutôt que système par système.
Pour chaque donnée importante, trois questions doivent être tranchées :
- Qui crée l’information ?
- Quelle source est autorisée à la mettre à jour ?
- Que se passe-t-il lorsque deux sources ne sont pas d’accord ?
C’est ce modèle d’autorité qui empêche une synchronisation automatique d’écraser une donnée validée par une information techniquement plus récente mais fonctionnellement moins pertinente.
Pour le Change Management, la relation entre CI vaut souvent plus que le CI lui-même
Connaître la configuration d’un serveur est utile. Comprendre ce qui dépend de ce serveur l’est davantage lorsqu’un changement doit être réalisé.
Un composant technique peut supporter une application, elle-même indispensable à un service utilisé par plusieurs équipes. Une intervention apparemment limitée à un serveur peut donc avoir un impact beaucoup plus large.
La valeur de la CMDB vient alors de la capacité à représenter les relations pertinentes :
Infrastructure → application → service → utilisateurs ou activités métier.
Ces relations permettent de replacer le changement dans son contexte et d’améliorer l’analyse d’impact.
L’Asset Discovery peut contribuer à identifier une partie de ces dépendances techniques. Il ne remplace cependant pas la modélisation du contexte de service et des relations qui ne peuvent pas être découvertes automatiquement.
Une CMDB mature combine donc données techniques automatisées et contexte ITSM gouverné.
Avant d’activer la synchronisation, cinq décisions doivent être prises
Le connecteur technique n’est généralement pas la partie la plus complexe du projet. Les décisions qui déterminent ce qu’il doit faire sont beaucoup plus importantes.
Avant une synchronisation à grande échelle, cinq règles devraient être explicites :
- Périmètre — quels actifs doivent devenir des CI et lesquels doivent rester dans l’inventaire ?
- Mapping — quelles informations de la source alimentent quels attributs de la CMDB ?
- Réconciliation — comment reconnaître un CI existant plutôt que d’en créer un nouveau ?
- Autorité — quelle source est autorisée à créer ou modifier chaque information ?
- Cycle de vie — que devient un CI lorsque l’actif n’est plus découvert, est remplacé ou sort du parc ?
Le dernier point est particulièrement important. La disparition d’un équipement d’un scan ne signifie pas nécessairement qu’il doit être immédiatement supprimé de la CMDB. Son statut, son historique et les tickets auxquels il est associé peuvent rester nécessaires.
L’automatisation doit donc respecter le cycle de vie de l’information, et pas uniquement refléter le dernier état détecté.
Mesurer la qualité de la CMDB plutôt que compter les CI
Une CMDB ITSM doit finalement être évaluée sur sa capacité à soutenir les processus de Service Management.
Le nombre total de CI apporte peu d’informations sur cette capacité.
Des indicateurs plus pertinents peuvent être suivis :
- taux de CI comportant les attributs obligatoires ;
- pourcentage de CI sans propriétaire ou sans service associé ;
- taux de doublons détectés ;
- ancienneté moyenne des données critiques ;
- volume d’erreurs de synchronisation ;
- proportion de CI correctement réconciliés ;
- taux d’incidents ou de changements effectivement associés à un CI.
Les indicateurs d’usage sont particulièrement importants. Si les agents du Service Desk ne consultent pas les données ou si les équipes Change continuent de reconstruire manuellement leur analyse d’impact, une CMDB techniquement complète n’atteint pas son objectif opérationnel.
Une bonne automatisation doit réduire la maintenance de la CMDB, pas déplacer le problème
Automatiser l’alimentation d’une CMDB répond à une difficulté réelle : maintenir manuellement des données techniques dans un système d’information en évolution permanente devient rapidement impossible à grande échelle.
Mais l’automatisation ne doit pas être évaluée au volume de données qu’elle réussit à faire entrer dans l’ITSM.
Une approche robuste consiste à automatiser la découverte et les mises à jour qui peuvent l’être, tout en conservant des règles strictes concernant le périmètre, le mapping, la réconciliation, les relations et le cycle de vie des CI.
L’objectif n’est donc pas de construire la CMDB la plus exhaustive possible, mais celle dans laquelle les équipes IT peuvent avoir confiance.
Lorsqu’un incident survient ou qu’un changement doit être préparé, les utilisateurs de la CMDB ne devraient pas avoir à se demander si l’information est encore correcte. C’est précisément à ce moment que la qualité des données cesse d’être un sujet de documentation pour devenir un enjeu opérationnel ITSM.
