L’inefficacité des référentiels
Les référentiels d’actifs (ou CMDB) utilisés au sein des productions IT sont des éléments critiques du système d’information. Nous observons que sur le terrain, ces référentiels rencontrent un ou plusieurs des défauts suivants :
Ils sont vieillissants ;
Leurs données manquent de fiabilité ;
Ils sont difficiles à utiliser ;
Des informations essentielles sont manquantes.
Nous nous intéressons dans cet article aux problèmes qu’engendrent ces défauts pour l’organisation et proposons des pistes de réflexion pour les résoudre.
Les conséquences de l’inefficacité des référentiels
Ces défauts des référentiels peuvent avoir des impacts aussi bien sur le BUILD que sur le RUN :
Impacts sur le BUILD :
Ralentissement des projets de transformation IT qui ont besoin de données exploitables aussi bien pendant les phases de conception, de construction et de déploiement ;
Nécessité pour les projets soit de prendre à leur compte la fiabilisation de la CMDB, soit de traiter partiellement leur périmètre d'intervention ;
Recours tactique à de multiples sollicitations unitaires des équipes pour obtenir des éléments complémentaires par des extractions manuelles consommatrices en temps.
Impact sur le RUN :
Augmentation de la complexité et du coût du maintien dans le temps du référentiel ;
Baisse de la fiabilité des recensements nécessaires pour divers besoins : auditabilité, refacturation, visibilité et maîtrise quotidienne du SI ;
Constitution par les équipes de référentiels locaux (« shadow CMDB »), moins rigides, qui portent atteinte à la logique Single Source of Truth (SSOT) de la CMDB.
Ces impacts engendrent pour l’organisation des coûts imprévus ainsi que des risques de sécurité importants et très souvent sous-estimés.
La structuration en logique Produit
Une piste pour résoudre ces problèmes est de considérer la CMDB comme un processus IT essentiel et à part entière qui doit :
Être décrit formellement et documenté ;
Être incarné par un garant de son bon fonctionnement.
La CMDB se prête alors particulièrement à une logique Produit, porté par un Product Owner qui :
S'assurera de son évolution fonctionnelle avec une logique d'adoption et d'UX en écoutant les retours des utilisateurs ;
S'assurera de son évolution technologique ;
Animera la gouvernance qui gère son cycle de vie.
Afin que le Product Owner puisse travailler de concert avec les responsables d’applications et les responsables de services IT, il est judicieux :
D’objectiver les responsables de chaque périmètre applicatif sur la fiabilité et l’exhaustivité de leurs données ;
D’amener les responsables de services IT, lors de chaque création ou évolution de service, à se poser la question suivante : « Comment cette évolution peut venir exploiter, enrichir ou compléter la CMDB, au service d’une meilleure visibilité et de la maîtrise du SI ? »
La prise en compte des enjeux de la CMDB dans les projets
Devant ces multiples difficultés, on observe fréquemment au sein des productions IT une attente perpétuelle du projet qui viendra mettre à jour et fiabiliser la CMDB. Il n’y a malheureusement pas de remède miracle, la CMDB doit être vue comme un processus IT qui doit être vivant et continu.
Pour s’assurer de la bonne prise en compte des enjeux de la CMDB, chaque projet doit porter la responsabilité de s'interfacer avec la CMDB pour l'exploiter, la peupler et l’enrichir. On peut garantir ce bon interfaçage par une étape de gating projet où le Product Owner CMDB donnera sa validation.
Améliorer l’utilisabilité de la CMDB
La CMDB contient souvent trop d’informations dont l’utilité n’est pas avérée et qui décourage son peuplement par les équipes. Pour améliorer son utilisabilité, la CMDB devra ne contenir que les informations réellement nécessaires pour limiter l'effort associé à l’action de peuplement. De plus, elle devra être enrichie d’informations clé qui sont trop souvent manquantes :
Rattachement applicatif des actifs IT ;
Interdépendances techniques et applicatives ;
Réglementations et standards applicables (LPM, PCI-DSS…) ;
Clés d'allocation de refacturation pour permettre le bon fléchage budgétaire des actifs vers les différents clients.
La CMDB d’une organisation doit modéliser un enchevêtrement de relations complexes tout en restant simple à utiliser et à peupler.
Contrôler la fiabilité de la CMDB
Afin de contrôler la fiabilité de la CMDB et de rémédier à ses défauts, on peut envisager un plan de contrôle qui permettra de confronter les données de l’ensemble de l’outillage permettant la découverte d’actifs : SCCM, scanners de vulnérabilités, sondes diverses… et remonter un plan d’actions pour traiter les éventuelles incohérences entre ces référentiels.
A ce processus de découverte, doit s’ajouter un processus automatisé et permanent de détection d’items présumés décommissionés. Un traitement humain fréquent (mensuel au moins) doit être mené : sur l’item en soi (suppression / mise à jour) mais aussi sur les processus IT de l’organisation pour que dans un cas de figure similaire futur l’item soit supprimé ou mis à jour avant même d’être détecté par ce processus de dernier ressort.
