Une CMDB imparfaite vaut-elle mieux que pas de CMDB

À 8 h 40, une application de prise de commandes ralentit. Le support voit des alertes contradictoires et le métier réclame un rétablissement immédiat. Personne ne sait cependant si le service dépend encore d’un ancien serveur d’authentification, quel contrat couvre le composant défaillant ni qui peut autoriser un changement. Cette scène est illustrative, mais le dilemme est courant : faut-il attendre une CMDB exacte avant de s’en servir ? La mauvaise réponse oppose perfection et absence. La vraie question est de savoir quelles décisions la CMDB doit sécuriser maintenant, avec quel niveau de confiance explicite.

Une CMDB n’est pas un inventaire décoratif

Une base de gestion des configurations n’a de valeur que si elle relie des objets utiles à l’action : services métier, applications, infrastructures, fournisseurs, contrats, responsables, dépendances et changements. Accumuler des milliers d’éléments techniques sans rapport avec une décision produit une illusion de maîtrise. Le DSI doit partir des situations où l’incertitude coûte cher : incident, mise en production, vulnérabilité, renouvellement ou migration. Pour chacune, il faut identifier les informations minimales nécessaires. Lors d’un incident, connaître le propriétaire du service, ses dépendances critiques et le fournisseur mobilisable importe davantage que documenter chaque paramètre d’un équipement. Une CMDB imparfaite devient utile lorsqu’elle réduit une incertitude précise, pas lorsqu’elle prétend représenter exhaustivement le système d’information.

Le danger n’est pas seulement la donnée fausse

Une donnée obsolète peut désigner le mauvais interlocuteur ou masquer une dépendance. Mais l’absence de référentiel impose de reconstruire les mêmes relations à chaque incident, dans l’urgence, à partir de fichiers locaux, de souvenirs et de conversations dispersées. Le compromis ne consiste donc pas à accepter n’importe quelle qualité, mais à distinguer ce qui est vérifié, probable, déclaré ou inconnu. Un champ « propriétaire » ancien ne doit pas être présenté comme certain. Une dépendance découverte pendant un incident doit pouvoir être ajoutée rapidement, puis contrôlée. La transparence sur la confiance transforme l’imperfection en information gouvernable. À l’inverse, une CMDB affichée comme fiable alors qu’elle ne l’est pas augmente le risque : les équipes cessent de vérifier précisément quand l’enjeu exige une preuve.

Commencer par un périmètre qui oblige à décider

La démarche peut débuter par quelques services critiques, choisis avec les métiers, les opérations et le RSSI. Première étape : nommer pour chacun un responsable métier et un responsable technique. Deuxième étape : relier les applications, composants structurants, prestataires et contrats dont l’absence empêcherait le service de fonctionner ou de se rétablir. Troisième étape : tester ces relations sur une panne simulée, une vulnérabilité ou un changement urgent. Quatrième étape : corriger les écarts et attribuer chaque donnée à une source et à un propriétaire. Enfin, intégrer la mise à jour aux processus qui modifient réellement le SI : changement, mise en production, achat, renouvellement, décommissionnement. Cette progression évite le programme interminable de « nettoyage préalable » qui repousse indéfiniment l’usage.

Organiser la qualité comme une responsabilité

La qualité ne doit pas reposer sur une campagne annuelle menée par une équipe centrale. Chaque classe d’information exige une règle simple : qui crée, qui valide, à quel événement elle est révisée et comment une anomalie est traitée. Les équipes techniques peuvent confirmer les composants ; les responsables applicatifs, les dépendances fonctionnelles ; les achats, les contrats ; le RSSI, la criticité de sécurité selon la méthode retenue. L’automatisation peut rapprocher découverte, annuaires et déploiements, mais elle ne décide pas seule qu’un actif est utile à un processus métier. Le dirigeant doit aussi arbitrer les conflits de source. Si un outil voit un serveur que le catalogue déclare retiré, l’écart devient une tâche à résoudre, non une écriture silencieuse qui efface le doute.

Mesurer l’aide à la décision, pas le volume

Le nombre d’éléments enregistrés est un indicateur trompeur : il récompense le remplissage, pas la fiabilité. Un tableau de bord opérationnel peut suivre la part des services prioritaires disposant d’un propriétaire confirmé, la couverture de leurs dépendances critiques, l’âge des validations, le délai de correction des incohérences et la proportion de changements ayant mis à jour les relations concernées. Il peut aussi observer, après incident, combien de dépendances importantes ont été découvertes trop tard et quelles informations ont réellement accéléré le diagnostic. Ces indicateurs doivent rendre visibles les zones aveugles et orienter l’effort. Le progrès n’est pas d’ajouter des lignes : il est de réduire les décisions prises sans responsable, sans dépendance connue ou sans preuve récente.

Refuser les deux erreurs symétriques

La première erreur est le grand projet exhaustif : modèle complexe, collecte massive, gouvernance théorique, puis faible usage faute de bénéfice immédiat. La seconde est le référentiel sans discipline, alimenté librement, jamais contrôlé et néanmoins présenté comme une source de vérité. Il faut éviter de confondre outil et gouvernance. Changer de plateforme ne corrigera ni l’absence de propriétaire ni le contournement des processus. Enfin, sanctionner les équipes qui signalent des erreurs serait contre-productif : une anomalie découverte améliore le référentiel si son traitement est suivi. Dans l’esprit de « Révolution Numérique ! », la technologie doit être reliée aux arbitrages, aux risques et aux responsabilités ; la CMDB n’échappe pas à cette exigence.

L’arbitrage du DSI : utile, bornée et explicite

Oui, une CMDB imparfaite vaut mieux que pas de CMDB, mais sous conditions. Son périmètre doit être annoncé, son niveau de confiance visible, ses usages prioritaires définis et ses lacunes traitées comme un risque à réduire. Le DSI peut autoriser son emploi pour préparer un incident ou analyser un changement, tout en imposant une vérification complémentaire pour une décision irréversible ou fortement exposée. Il doit fixer un seuil d’utilité : si le référentiel n’aide aucune décision, sa maintenance doit être repensée ; s’il influence une décision, sa provenance et sa fraîcheur doivent être contrôlables. L’objectif n’est pas une photographie parfaite du SI. C’est un dispositif vivant qui permet de savoir ce que l’on connaît, ce que l’on ignore, qui doit répondre et quelle preuve obtenir avant d’agir.

Pour approfondir

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Consulter la référence

Consulter la référence

#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique