Le vrai problème n'est pas de construire
Construire une base est un projet : il a un début, une fin, un enthousiasme. La tenir à jour est une routine, et les routines meurent en silence.
Six mois après la mise en service, deux issues sont possibles, et elles se décident dès les premières semaines.
Les trois mécanismes de fraîcheur
Par ordre d'efficacité décroissante.
La découverte automatique. Ce qui se découvre ne se saisit pas. Un agent qui remonte quotidiennement tient à jour le matériel, le système et les logiciels sans effort humain. Toute information qui peut passer dans cette catégorie doit y passer.
La mise à jour par le processus. La meilleure idée de ce cours, et elle ne coûte rien : la base se met à jour au moment où le travail a lieu. Une intervention qui remplace un disque met à jour la fiche pendant l'intervention, pas plus tard. Un changement qui ajoute une dépendance la déclare dans le changement lui-même.
Ce couplage est ce qui distingue les bases vivantes des bases mortes. Une mise à jour qui demande une tâche séparée n'a lieu que les premières semaines.
La revue périodique. Le filet, pas le mécanisme principal. Une fois par trimestre, sur le périmètre vital uniquement, quelqu'un vérifie que les dépendances déclarées correspondent encore à la réalité.
Mesurer la fraîcheur, pas l'exhaustivité
Un tableau de bord de CMDB qui affiche « 1 240 éléments » ne dit rien. Trois chiffres disent tout.
La part des éléments vérifiés ou découverts dans les trente derniers jours. C'est la santé de la base.
Le nombre d'éléments sans propriétaire. Ce sont les orphelins, et ils se périment en premier.
Le nombre d'éléments dont le statut est incohérent : en service sans inventaire depuis trois mois, ou en stock alors qu'ils répondent sur le réseau.
Cette dernière ligne est la plus utile au quotidien. Elle nomme des écarts précis, à corriger un par un, plutôt qu'un sentiment général de qualité.
Le propriétaire, pas le responsable
Chaque élément saisi à la main porte le nom d'une personne. Pas un service, pas une équipe : une personne.
Ce n'est pas une question de responsabilité au sens de la faute. C'est la réponse à une question pratique : qui appelle-t-on quand cette information paraît fausse ?
Un élément sans propriétaire est un élément que personne ne corrigera, parce que chacun supposera qu'un autre s'en charge.
Ce qui tue une CMDB, par fréquence
La saisie obligatoire sans bénéfice visible. Si remplir dix champs n'aide jamais celui qui les remplit, il cessera, et il aura raison.
Le décalage entre la base et le terrain, découvert une fois : la confiance ne revient pas ensuite, et l'équipe reprend ses vérifications manuelles.
Le départ de la personne qui portait le sujet, quand rien n'est automatisé ni documenté.
L'exhaustivité comme objectif. Viser cent pour cent garantit d'y renoncer. Viser un périmètre restreint et exact, puis l'étendre, garantit d'y arriver.
Le lien avec les incidents, qui rend tout rentable
Le bénéfice devient visible quand la base sert dans le traitement des incidents.
Un ticket lié à un élément donne immédiatement ce qui en dépend, donc l'impact réel, donc la bonne priorité. Un changement lié aux mêmes éléments dit qui prévenir avant l'intervention.
Une base que personne ne consulte pendant un incident n'a aucune raison d'être tenue à jour. Si vous constatez cela, ce n'est pas un problème de rigueur : c'est le signe que la base ne contient pas ce dont l'équipe a besoin.
À retenir
Découvrez plutôt que saisir, et mettez à jour pendant le travail plutôt qu'après. Mesurez la fraîcheur, les orphelins et les incohérences, jamais le nombre d'éléments. Un propriétaire nommé par élément manuel. Et si la base n'est pas consultée pendant les incidents, elle ne contient pas ce qu'il faut.