Qu'est-ce qu'une CMDB ?
C’est un fichier, une base où l’on stocke des informations techniques des systèmes d'information comme la liste des serveurs, des bases de données, des différentes applications et progiciels mais également des éléments métiers comme les processus ou les contrats. Dans le lexique d'une CMDB, tous ces éléments sont nommés "Configuration Item" (CI).
💡 Une CMDB correctement renseignée permet une meilleure planification de la stratégie de la DSI, du pilotage et de la gestion de projet associée.
Concrètement, qu’est-ce que ça m’apporte ?
Avant d’entrer dans les détails, voici quelques cas d’usage d’une CMDB:
Réaliser une analyse d'impact : Lorsqu'il est nécessaire de réaliser une opération de mise à jour ou de mise en production d'un lot de serveurs, la CMDB peut permettre d'identifier les applications ou services qui seront impactés et de prévenir les responsables applicatifs associés.
Définir le périmètre d'un test d'intrusion (Pentest) : Un test d'intrusion sera d'autant plus pertinent si l'ensemble des assets IT exposés à une attaque sont bien dans le périmètre d'un test d'intrusion ou d'un audit de vulnérabilité.
Fournir une preuve de la conformité du SI : La CMDB fournit des preuves documentées de la conformité aux processus et régulations nécessaires (ISO27001. SOC2) Cela peut être particulièrement utile lors des audits internes ou externes, ou aux autres processus de gestion, notamment pour les commissaires aux comptes.
Mais encore ?
La mise en place d'une CMDB dans votre organisation offre de nombreux autres avantages :
L'intégration avec l'ITSM : Dans le cadre du bon suivi de l'exploitation du système d'information, être capable de faire le lien entre les incidents et les éléments du système d'information est clé. Le centre de service doit cependant être rigoureux dans la qualification de chaque ticket.
C'est l'une des raisons principales de la présence d'une CMDB intégrée dans les outils d'ITSM (ticketing).
Une vision d'ensemble du SI : Avec les informations détaillées et complètes fournies par une CMDB, les responsables des services informatiques peuvent prendre des décisions mieux éclairées. Que ce soit pour déterminer le cycle de vie d'une application, planifier une mise à niveau, comprendre l'impact d'une interruption ou énumérer les licences pour un audit logiciel, une CMDB aide à la prise de décision efficace.
Je ne crois pas qu’il y ai de bonnes ou de mauvaises CMDB…
❌ Faux! Une bonne CMDB robuste, efficace et opérationnelle se doit de suivre ces 3 commandements:
Elle contient des informations complètes : Une bonne CMDB est un vaste référentiel de données contenant des informations détaillées et à jour sur chaque CI, y compris son état actuel, des données historiques, une documentation associée et des détails sur chaque interaction au sein du système.
Elle conserve des informations sur les relations : Une CMDB ne se contente pas de stocker des informations, mais intègre également la complexité des relations et des interfaces qui font l’ entreprise. Ce mapping des relations peut fournir des informations précieuses pour comprendre l'impact potentiel d'un changement sur les services interdépendants.
Elle prend en charge d'autres processus ITSM : Une CMDB réussie n'est pas autonome ; elle prend en charge d'autres processus ITSM. Cela inclut la gestion des incidents, la gestion des problèmes et la gestion des changements, fournissant les données de base dont ces processus ont besoin pour fonctionner efficacement.
Mais dis-moi Jamy, qui est responsable de son contenu ?
La CMDB sert de point central pour la documentation du SI. Plusieurs métiers de la DSI sont donc impliqués dans son maintien.
Le DSI ou le responsable du SI : Il utilise la CMDB pour obtenir une vue d'ensemble du système d'information, facilitant les décisions stratégiques et opérationnelles. Il l'utilise également pour identifier et gérer les risques (Risk management) associés aux changements dans les services IT.
L'équipe d'exploitation ou support : Cette équipe est la principale intéressée de la gestion des incidents, des problèmes et des changements. Un lien fort existe souvent entre l'outil de ticket et la CMDB pour identifier sur quel élément du SI porte un incident ou un projet de changement. Cette équipe peut également utiliser la CMDB pour faire une analyse d'impact lors d'un changement ou d'une maintenance.
L'architecte : Il est en charge de garantir la précision de la CMDB et de la tenir à jour. Son travail a une influence significative sur tous les processus et décisions qui reposent sur la CMDB.
Ca semble trop beau… pour être vrai ?
Il parait évident qu’une CMDB apporte beaucoup de valeur à ses utilisateurs. Or toutes les entreprises n’ont pas de CMDB, mais pourquoi ?
Le manque d'automatisation : Historiquement, les CMDB étaient remplis manuellement et le sont encore majoritairement aujourd'hui. Certaines solutions proposent de la découverte automatique mais l'effort de construction et maintient d'une CMDB reste très conséquent, notamment dans les DSI qui ne peuvent pas se permettre de dédier un architecte sur le sujet.
La technicité : Sans être un domaine de compétence à part entière, le lexique lié à une CMDB n'est pas simple et les relations entre les différents éléments (les fameux CI) peuvent être complexes. L'accès à l'information n'est pas évident et il est difficile d'imaginer qu'un chef de projet puisse contribuer dans une CMDB. Ajouter un logiciel de gestion - souvent un progiciel ou un logiciel open source - implique aussi de l'entretenir, le maintenir et faire appels à des consultants externes.
Le manque d'agilité : Le processus de documentation d'une CMDB vient en confrontation avec les mécanismes d'auto-documentation utilisés dans la mise en place de méthodes et d'infrastructure Agile. Par exemple l'infrastructure-as-code (IaC) représente en soit une forme de documentation qui sera en doublon avec la CMDB.
Le déploiement continu implique des changements réguliers dans l'architecture d'une application et la CMDB sera en peine pour suivre les modifications.
L’absence de gestion de la vision long terme : Les meilleures pratiques ITIL de gestion des configurations s'appliquent à documenter l'existant mais il y a peu de vision temporelle du système d'information qui permettrait de constituer une roadmap de la DSI ou un schéma directeur du SI (SDSI).
Le battle: CMDB vs …
Il existe bien des alternatives aux CMDB, soit sur d’autres domaines (Finances) soit avec des objectifs plus haut niveau (Architecture d’Entreprise).
🥊 ITAM
La gestion des actifs informatiques (ITAM) et la CMDB sont souvent confondues, mais elles sont distinctes. L'ITAM se concentre sur la gestion des actifs informatiques d'une organisation tout au long de leur cycle de vie d'un point de vue financier. Pendant ce temps, la CMDB se concentre sur l'infrastructure informatique et ses composants associés et leurs relations, fournissant une vue holistique nécessaire à une gestion informatique efficace.
🥊 Enterprise Architecture (EAM)
La gestion des actifs d'entreprise (EAM) est un concept plus large qui englobe tous les actifs d'une organisation entière tout en se concentrant sur la maximisation de la prestation de services et de la durée de vie des actifs. D'autre part, une CMDB est spécifiquement adaptée pour répondre aux besoins d'ITSM, offrant une vue interactive détaillée des actifs de l'infrastructure informatique et de leurs relations dans le contexte d'ITSM.
En conclusion, aujourd’hui j’ai appris
→ La décision de mettre en place une CMDB devrait reposer sur une compréhension solide de ce qu'elle peut offrir et de sa conformité avec les objectifs d'une organisation.
→ Même avec des défis, une CMDB soigneusement mise en œuvre et entretenue peut valoriser l'ITSM en améliorant les décisions, en optimisant les processus et en réduisant les risques.
