CMDB
Pourquoi 80 % des projets de CMDB échouent (et comment éviter ça)
Les CMDB sont l'un des chantiers ITSM les plus ratés. Voici les quatre causes principales d'échec et les arbitrages concrets qui font la différence.
Photo : panumas nikhomkhai sur Pexels
Toutes les DSI ou presque ont entendu parler de la CMDB. Beaucoup en ont commencé une. Très peu ont réussi à en faire un outil opérationnel qui sert vraiment leurs équipes.
Les chiffres officiels n'existent pas, mais l'estimation des praticiens converge autour de 70 à 80 % de projets qui n'atteignent jamais leurs objectifs initiaux. La cause n'est presque jamais technique. Elle est méthodologique, et toujours la même.
On cartographie trop, et trop vite
L'erreur fondatrice est presque toujours là. On lance le projet avec l'ambition de tout cartographier en six mois : serveurs, applications, postes de travail, périphériques, contrats, licences, parfois jusqu'aux prises électriques.
Six mois plus tard, on a effectivement entré beaucoup de données. Mais la majorité est obsolète, mal renseignée, ou jamais utilisée. Personne ne fait confiance à la base, donc personne ne s'en sert. Personne ne s'en servant, plus personne ne la met à jour. La spirale est lancée.
Le bon réflexe : commencer par un périmètre minimal, défini par les services métier critiques. Quels sont les 5 à 10 services dont une panne déclenche un appel direct du COMEX ? On cartographie ces services-là, leurs applications, leur infrastructure de support. Le reste viendra ensuite, par extension naturelle, quand le besoin sera prouvé.
On confond CMDB et inventaire
Beaucoup de DSI assimilent CMDB et inventaire technique. C'est une confusion conceptuelle qui se paie cher.
Un inventaire répond à la question : "qu'est-ce que j'ai ?" Une CMDB répond à la question : "comment ça marche, et qu'est-ce qui dépend de quoi ?"
L'inventaire est utile à la finance et au pilotage de la dette technique. La CMDB est utile à l'exploitation, à la gestion des incidents, à la gestion du changement. Les deux ne servent pas les mêmes usages, n'ont pas le même modèle, et ne demandent pas le même niveau d'effort.
Construire une CMDB en partant des données d'un outil d'inventaire produit une base technique sans valeur opérationnelle. C'est la déception garantie au bout de 12 mois.
On néglige la gouvernance dès le départ
Une CMDB n'est pas un projet, c'est un processus.
Une fois la base initiale construite, encore faut-il qu'elle reste à jour.
Si la mise à jour repose sur des saisies manuelles, elle ne tiendra pas. Les équipes opérationnelles ont d'autres priorités. Au bout de quelques mois, les informations divergent du réel, et la base perd sa valeur.
La règle d'or : la mise à jour doit être automatique partout où elle peut l'être, et formalisée dans les processus opérationnels là où elle ne peut pas être automatique. Un changement validé doit déclencher une mise à jour CMDB, par construction, pas par bonne volonté.
Concrètement, cela veut dire qu'avant même de poser le premier CI dans la base, on doit avoir cartographié les sources de vérité (Active Directory, outil de monitoring, outil d'inventaire, contrats), défini les flux d'alimentation automatique, et identifié les zones grises qui demanderont une saisie humaine.
On ne définit pas les usages cibles avant de construire
C'est l'erreur la plus invisible, et la plus structurante. On construit une CMDB sans avoir défini précisément à quoi elle servira.
Les usages typiques sont nombreux : aide à la résolution d'incidents, évaluation d'impact de changements, conformité réglementaire, analyse de capacité, pilotage des contrats. Chacun de ces usages exige un modèle différent, des attributs différents, des relations différentes.
Construire une CMDB universelle, qui répond à tous les usages, est impossible. La base devient soit pauvre (on ne renseigne que le minimum commun), soit ingérable (on cumule toutes les exigences). Les deux échouent.
Le bon réflexe : choisir 2 ou 3 usages prioritaires, construire la base pour les servir vraiment, et étendre ensuite. C'est moins ambitieux sur le papier. C'est ce qui fait la différence entre un projet réussi et un projet de plus.
Le pattern qui fonctionne
Si on devait résumer ce qui distingue les CMDB qui réussissent, ce serait quatre points.
Un périmètre initial étroit, défini par les services métier critiques. Un modèle simple, aligné sur 2 ou 3 usages cibles concrets. Une alimentation automatique partout où elle est possible. Une gouvernance formalisée dès le départ, avec des responsables nommés.
Le reste est secondaire. Le choix de l'outil compte moins que la rigueur de la démarche. Une CMDB construite avec discipline sur un outil moyen vaut mieux qu'une CMDB construite n'importe comment sur le meilleur outil du marché.
Pour conclure
Les CMDB ratées ne sont pas une fatalité. Elles sont le résultat d'erreurs méthodologiques répétées, dont la principale est l'excès d'ambition initial.
Si vous êtes en train de relancer un projet CMDB après un premier échec, prenez le temps d'analyser pourquoi le premier n'a pas tenu. Si vous lancez votre premier projet, regardez du côté de ceux qui ont déjà raté avant vous. Les leçons sont là.