Introduction

La CMDB (Configuration Management Data Base), est un outil qui permet de cartographier l’ensemble du système d’information en indiquant l’état de ces composants d’un point de vue technique et fourniture de service (cycle de vie, modèle, versions, configurations, etc.) et les dépendances entre ceux-ci.

Ces composants sont modélisés sous forme de CI (Configuration Item, ou élément de configuration), instanciés à partir de classes de CI (Service métier, applications, serveurs, etc.), et reliés entre eux via des relations (application hébergée sur un serveur, poste de travail détenu par un utilisateur, etc.)

Jusqu’au milieu des années 2010, la CMDB est utilisée dans de nombreuses organisations dans une optique d’inventaire du SI et de support des principaux processus ITIL (gestion des incidents, traitement des requêtes, gestion des problèmes et gestion des changements), avec une plus-value limitée à la filière SI. Depuis, de plus en plus d’organisations commencent à exploiter son potentiel pour répondre à d’autres enjeux, tels que la remédiation aux risques cyber, la gestion des vulnérabilités et de l’obsolescence, la facturation des services SI, la rationalisation des portefeuilles applicatifs, etc.

Enfin, un tel outil fait intervenir de nombreux acteurs, répartis sur différents niveaux de la filière informatique : direction, métiers, architecture, applications, infrastructures. L’un des premiers défis consiste à faire converger toutes ces parties prenantes vers une cible, et les garder mobilisées ensuite pour maintenir la qualité de la CMDB. En effet, une CMDB non maintenue tombe en désuétude, et les utilisateurs l’abandonnent pour travailler sur des référentiels parallèles et parcellaires.

Une enquête du Gartner de 2020 indique que 32 % des organisations utilisant la CMDB interrogées rencontrent des problèmes quant à la qualité des données et leur complétude.

Quelles sont donc les étapes à suivre et les écueils à éviter afin de sécuriser la mise en place de cet outil et d’en maximiser la plus-value dans le temps ?

Notre approche pour une implémentation réussie d’une CMDB

1.    Analyse et cadrage

Besoins et cas d’usage

Tout d’abord, se poser la question sur la pertinence d’une CMDB et ce qu’elle peut apporter. Est-elle nécessaire au regard de la variété du parc informatique ? Y a-t-il des processus ITIL suffisamment matures ? Apportera-t-elle de la plus-value au regard du niveau de la qualité de service délivrée et des outils existants (IT asset management, monitoring, etc.) ?

Ensuite, commencer par se poser des questions sur ce que l’on attend de la CMDB avant de déterminer ce que l’on compte y enregistrer. Pour cela, une approche par cas d’usage est recommandée. Les décrire sous forme de tableaux de bord, de métriques permet de rendre l’exercice concret et pragmatique.

Exemples :

• Cartographie des serveurs, applications hébergées et métiers utilisateurs pour analyser les impacts de changements sur les serveurs et communiquer aux bons métiers,
• La répartition des composants applicatifs par date de fin de support pour planifier les remédiations à l’obsolescence.

Viser des cas d’usage proches des métiers et de la direction, afin de mettre en visibilité le programme et mobiliser le bon niveau de sponsorship.

Gouvernance

Ensuite, il s’agit de définir la gouvernance pour sécuriser la phase projet et accompagner la phase de run :

• Les processus opérationnels permettant l’actualisation de la CMDB (la gestion des changements est indispensable)
• Les modalités de reporting et de communication des résultats auprès des parties prenantes et des sponsors.
• Les rôles clé :
  • Des sponsors en mesure de mobiliser les équipes et les ressources, de suivre les résultats et d’arbitrer
  • Des responsables de cas d’usage, en charge de la définition (en phase projet), du maintien des besoins autour de la CMDB (en phase de run) et de fixer les objectifs et les priorités
  • Un responsable de la CMDB, garant de la cohérence sa modélisation, de son implémentation et des règles de gestion en lien avec les cas d’usage
  • Des data owners (généralement les product owners, les équipes de delivery, etc.), en charge de la mise à jour des informations liées à leurs CI
  • Un responsable de la qualité de données, en charge du pilotage de la qualité des données en collaboration avec les responsables de cas d’usage, du responsable de la CMDB et des data owners.

Instances dédiées

La mise en place à minima de deux instances :

[Mensuel] Le comité de pilotage de la qualité CMDB pour principalement :

• Définir les objectifs des KPI de qualité et d’exhaustivité des données
• Présenter les KPI et leur évolution par asset
• Définir le plan d’actions pour assurer l’évolution des KPI

[Trimestriel] Le comité de revue pour principalement :

• Assurer une relecture fréquentielle critique des processus/procédures de gestion de cycle de vie des assets et les procédures connexes (développement, exploitation, mise à jour et décommissionnement des actifs etc.)
• Assurer la mise à jour et l’évolution des procédures/processus
• Présenter les résultats des contrôles de qualité et d’exhaustivité des données

Cartographie et évaluation des sources de données

Enfin, recenser toutes les sources de données, le contenu de ces sources, leur qualité, ainsi que la maturité des pratiques autour de ces sources. Exemples : référentiels applicatifs, outils d’asset management, référentiels immobiliers, etc.

2.    Définir la cible

Modèle de données

Sur la base des cas d’usage, définir le modèle de donnée en déterminant les classes de CI, les CI ainsi que les attributs et les relations requis. Faire ensuite un tri dans les CI (notamment dans le cas d’une CMDB existante) en s’assurant que toutes les classes de CI en cible répondent à un certain nombre de critères :

• Répondent-ils à un cas d’usage ?
• Sont-ils couverts par un processus de gestion des changements (essentiel pour assurer le maintien des données) ?
• Ont-ils un propriétaire responsable de leur mise à jour ?

Exemple de modèle de donnée haut niveau d’une CMDB

Sélection de la solution CMDB

La majeure partie des solutions ITSM embarquent un module CMDB. Sur le plan fonctionnel, ces solutions offrent les mêmes possibilités. Pour effectuer un choix au bon niveau, il convient de prendre en compte d’autres critères.

Exemples :

• Stratégie de l’entreprise. Par exemple : dans le cadre d’une migration massive vers le cloud, privilégier une solution qui a montré sa capacité à s’interfacer avec les outils des fournisseurs cloud,
• Stratégie ITSM sans CMDB, privilégier une solution ayant fait ses preuves dans l’intégration avec l’outil déployé.

3.    Construire la trajectoire

Une fois le modèle de données défini, la gouvernance déterminée et le choix de la solution cadré, Il s’agit de définir et de planifier les étapes permettant de mettre en service la CMBD.

Peuplement de la CMDB

Il n’est pas recommandé de viser une CMDB comme une unique source, privilégier plutôt une fédération de référentiels, avec les liens de dépendance entre composants provenant de différents référentiels pour répondre aux cas d’usage (poste de travail dans l’asset management et sa localisation à partir de référentiel immobilier pour organiser une intervention sur site).

Chaque équipe fournisseur de données utilise des outils adaptés que la CMDB ne pourra pas remplacer (exemples : gestion des assets pour les postes de travail, l’annuaire d’entreprise pour la gestion des comptes, référentiel immobiliser pour les sites, etc.).

Il est recommandé de privilégier les actualisations automatiques autant que faire se peut. En effet, les opérations manuelles sont sources d’erreurs, cela conduit à la longue à la dégradation de la qualité de la CMDB et amener les utilisateurs à y renoncer et reconstruire des référentiels en parallèle.

Les cas d’usage et leur priorisation d’une part, et l’évaluation de la maturité et de la qualité des sources de données d’autre part permettent de prioriser les périmètres à intégrer dans la CMDB et les classes de CI à peupler.

Prévoir à minima de raccorder la CMDB :

• Au référentiel RH ou à l’annuaire d’entreprise pour collecter la liste des utilisateurs et leur organisation ;
• A l’annuaire d’entreprise ;
• Au référentiel immobilier pour collecter la liste des localisations (utilisateurs, datacenters, etc.) ;
• Aux outils d’asset management pour collecter les actifs adressés (postes de travail, composants applicatifs, etc.).

Pour les chargements manuels, prévoir des processus de chargement en masse, à base de templates de collecte et de paramétrage dans la CMDB de procédures de chargement. Bien évidemment, le collecte doit être suivi d’un travail de vérification et de fiabilisation des données avant chargement. Il est préférable de ne rien avoir dans la CMDB que d’avoir des données fausses.

Afin d’automatiser la mise à jour, d’autres solutions peuvent être envisagées :

• Outils de découvertes, inclus dans l’outil ITSM ou tiers, en veillant au bon paramétrage des données à remonter dans la CMDB et au traitement des conflits.

En notant que si les outils de découverte permettent d’automatiser la mise à jour de données techniques (adresse IP, modèle hardware, version de l’OS), elles ne permettent pas d’automatiser la saisie des données « administratives » (métiers utilisateurs, direction propriétaire, groupe support, etc.) ;

• Outils d’orchestration et d’automatisation, permettant de mettre à jour automatiquement la CMDB en parallèle du provisionning d’environnement dans une chaîne DevOps.

Vision des différents niveaux d’automatisation et exemples d’outils

Embarquement des parties prenantes et conduite du changement

Sur la base de la priorisation des classes de CI, identifier les acteurs qui endosseront les différents rôles définis dans la gouvernance sur leurs périmètres organisationnels ou techniques respectifs.

Définir ensuite les actions d’embarquement de ces acteurs :

• Communication sur les enjeux, bénéfices et attendus de leur implication dans la démarche
• Formation à l’utilisation de la CMDB
• Attribution des accès

4.    Phase de run : Maintien de la CMDB

Actualisation des données au fil de l’eau

De manière globale, il convient de minimiser les accès et les modifications directes dans la CMDB. La meilleure pratique étant d’asservir ces modifications au processus de changement, afin de systématiser la mise à jour (tâche incluse dans le changement) et d’en assurer la traçabilité.

Le rôle de responsable de qualité des données est primordial. Il mesure la qualité des données, identifie les défaillances, et revoit avec les data owners comment traiter ces erreurs à la source (et non dans la CMDB), tout en s’appuyant sur les responsables de cas d’usage pour prioriser les actions, et sur le propriétaire de la CMDB pour assurer la cohérence avec les standards et les bonnes pratiques.

Maintenir la mobilisation des data owners et des équipes opérationnelles. Disons-le clairement, maintenir une CMDB n’est pas l’activité la plus attrayante dans le quotidien d’un informaticien. Il est nécessaire de rappeler le sens, les objectifs (accélérer le traitement des incidents, facturer les services, parer aux risques de cybersécurité, etc.), tout comme il est important de communiquer sur les succès (traitement de tant d’applications obsolètes, décommissionnement de tant de serveurs orphelins avec les économies et la baisse de l’empreinte énergétique induites, etc.)

Audits réguliers

Réaliser des audits réguliers, en utilisant les outils de « health check » de plus en plus répandus dans les CMDB, en complétant avec des questions simples pour identifier les zones à remédier : date de dernier changement sur le CI (y a-t-il des tickets de changement associés ? Doit-il encore figurer dans la CMDB), date de dernière utilisation du CI (a-t-il vocation à demeurer dans la CMDB ?)

Conclusion

En conclusion, la CMDB est davantage qu’un socle pour les processus ITIL, elle constitue un outil essentiel au pilotage de la filière SI au sens large : performance opérationnelle, économique, et aussi environnementale. Ainsi, bien implémentée et bien maintenue, son association à un outil tiers de réalisation de bilans énergétique et environnementale constitue un précieux accélérateur pour définir et piloter des plans d’action visant à réduire l’empreinte.

Enfin, les capacités d’interfaçage avec de nombreux outils automatiques ouvrent de nombreuses pistes d’exploration en lien avec l’intelligence artificielle générative. De nombreux cas d’usage peuvent être expérimentés pour automatiser davantage sa maintenance d’une part, mais également pour tirer plus de valeur, en prenant en considération bien évidemment les contraintes de sécurité.