Connecter son DCIM à sa CMDB (ServiceNow, Jira, BMC...)

L'interconnexion entre votre DCIM (qui représente la réalité physique) et votre CMDB (qui cartographie la logique de service) est aujourd'hui le meilleur moyen d'obtenir une source unique de vérité (SSoT) fiable.

‍

Ensemble, faisons le point sur les enjeux, l'architecture et les étapes de cette intégration devenue indispensable. Nous avions déjà détaillé les liens entre le DCIM et l'Asset Management, notamment pour comprendre comment ils viennent enrichir votre CMDB.

‍

1. Pourquoi l'intégration DCIM + CMDB est-elle devenue vitale ?

On le sait bien, le fossé historique entre l'IT et le facility management génère des coûts cachés et de sérieux risques d'exploitation. Réconcilier ces deux mondes permet de résoudre trois problèmes majeurs :

‍

• L’asset fantôme et l'énergie perdue : On estime qu'environ 15 à 25 % des serveurs en datacenter sont des « zombies ». Ils sont allumés et consomment de l'énergie, mais ne font tourner aucune charge utile. Sans lien entre le DCIM et la CMDB, vous payez de l'électricité et de la maintenance pour du vide.
• Le data drift : Dès qu'un technicien déplace un câble ou un serveur sans mettre à jour manuellement la CMDB, votre base documentaire devient obsolète. Une remontée automatique du terrain via le DCIM garantit l'intégrité de vos données.
• Le mur énergétique : Avec l'arrivée de l'IA et de la (très) haute densité, la marge d'erreur sur la puissance disponible s'est réduite à néant. Il est crucial de savoir en temps réel si un rack peut supporter un nouveau serveur d'un point de vue électrique et thermique, et ce, avant même de passer commande.

‍

2. Architecture des flux de données

Plutôt que de chercher à définir un outil maître et un outil esclave, l'architecture moderne repose sur la fédération de données.

‍

Chaque système reste la référence sur son domaine d'expertise, mais les deux s'enrichissent mutuellement en continu grâce à une synchronisation bidirectionnelle. Pour éviter les conflits de données, il faut respecter la répartition naturelle des rôles.

‍

‍

Le périmètre de la CMDB (la logique et le service)

C'est le cœur de la gouvernance ITSM. La CMDB détient la vérité sur :

‍

• L'identité financière et contractuelle : Statut de la garantie, centre de coûts, date d'achat, propriétaire métier.
• Cartographie applicative : Quel serveur héberge quelle base de données, qui elle-même fait tourner telle application critique.
• Cycle de vie ITSM : Les statuts logiques de l'équipement (en stock, en test, en production…).

‍

Le périmètre du DCIM (le physique et l'environnement)

Le DCIM est l'œil du datacenter. Il se moque de savoir si un serveur fait tourner la paye ou le site web de l'entreprise, mais il sait exactement :

‍

• Dans quelle salle, quelle travée, quelle baie et à quelle hauteur exacte (en U) se trouve l'équipement.
• Consommation électrique en temps réel (watts), température, hygrométrie, poids de la baie.
• Les chemins de câbles d'alimentation et les interconnexions cuivre/fibre.

‍

La synchronisation

C'est ici que l'intégration prend tout son sens. Certaines données exigent que les deux systèmes communiquent :

‍

• Le statut opérationnel : Si un serveur est débranché physiquement, la CMDB doit le passer en « indisponible ». À l'inverse, si la CMDB passe un serveur en « maintenance planifiée », le DCIM doit cesser d'alerter si la consommation électrique de ce serveur chute.
• L'identification réseau : Le nom d'hôte, l'adresse IP de management et l'adresse MAC sont souvent découverts par le réseau, enregistrés dans la CMDB, puis poussés vers le DCIM pour faciliter le repérage visuel sur le terrain.
• Création d’asset : Le cycle est souvent initié par l'ERP ou l'outil d'ITAM lors de la commande. L'actif est créé avec un statut « en commande » ou « en stock » dans la CMDB, puis poussé vers le DCIM en tant qu'équipement « planifié ». Le DCIM confirmera ensuite son installation physique.

‍

3. Automatisation du cycle de vie

Connecter vos outils permet de transformer des processus manuels en automated lifecycle management → exemple de scénario de provisioning zéro erreur :

‍

• Demande : L'utilisateur demande le déploiement d'un nouveau cluster physique via BMC ou ServiceNow.
• Simulation : La CMDB interroge le DCIM via API pour trouver où placer 5 serveurs de 700W avec une redondance complète.
• Réservation : Le DCIM permet d'identifier les racks optimaux en croisant le poids, le froid et l'électricité disponibles, et d’en réserver l'espace en U.
• Installation : Le technicien installe le matériel et valide l'emplacement exact (le bon U) en scannant le code-barres ou l'asset tag via une application liée au DCIM. La détection de la nouvelle consommation sur les PDUs intelligents vient ensuite comme une validation secondaire confirmant que l'équipement est bien alimenté. (voir notre article dédié aux PDU)
• Clôture : Cette double validation (scan physique + électricité) permet au DCIM de confirmer l'installation réelle à la CMDB, qui bascule automatiquement l'actif en statut « production ».

‍

4. Analyse d'impact et gestion du risque

C’est ici que la valeur métier se perçoit le mieux. En fusionnant les topologies physiques et logiques, vous obtenez une cartographie complète de vos dépendances, de la prise électrique jusqu'au service utilisateur.

‍

• Propagation de panne : Si une source électrique tombe, le système croise les données de câblage du DCIM avec les clusters applicatifs de la CMDB. Vous savez instantanément si un serveur critique tourne en mode survie sur une seule alimentation.
• Détection des SPOF (points de défaillance uniques) : Le système alerte si deux nodes d'un même cluster sont branchés physiquement sur le même switch ou le même PDU.

‍

5. Focus énergie et RSE

Avec les nouvelles directives environnementales, le reporting énergétique ne peut plus se contenter d'estimations.

‍

• Consommation IT granulaire et empreinte carbone : Le DCIM remonte la consommation IT réelle de chaque équipement via les PDUs intelligents. En appliquant le PUE global du site à cette consommation exacte, il devient possible de calculer l'empreinte énergétique et la quote-part carbone par client, département ou application.
• Refacturation : En IT partagée, vous pouvez facturer les départements sur la base de la consommation réelle mesurée (et non plus sur la capacité théorique des alimentations de l'équipement).

‍

6. Guide de mise en œuvre : 4 étapes clés

1. Normalisation des données : Chaque outil ou intervenant a sa propre façon de saisir le nom d'un équipement. Pour un seul et même serveur :

‍

• lTAM (achat) : « HP DL380G10 »
• CMDB : « DL380 Gen 10 »
• DCIM : « HPE ProLiant DL380 Gen10 »

Lors de la synchronisation, le système risque de créer des doublons. Avant de connecter les outils, il est impératif de nettoyer les bases et de définir un dictionnaire matériel commun (Hardware Model Normalization).

‍

2. Mapping des attributs : Définissez précisément quel outil est la source de vérité absolue pour chaque champ. Par exemple, la CMDB est maître pour le centre de coûts et le propriétaire, le DCIM est maître pour la topologie et les métriques électriques.

‍

3. Connectivité : Utilisez les API REST pour les vérifications ponctuelles et privilégiez les webhooks pour les notifications de changement d'état en temps réel.

‍

Configurez un middleware capable de gérer les conflits (exemple : si la CMDB dit « en maintenance » mais que le DCIM lit une consommation de 500W, il faut lever une exception plutôt que d'écraser la donnée aveuglément).

‍

4. Acculturation et Processus : L'intégration technique ne fonctionne que si l'outil devient le langage commun qui brise les silos. Mettez en place de nouveaux processus de change management impliquant les équipes IT et Facilities.

‍

‍

Sources :

Anthesis - Zombie Servers: Hunting Down The Lost Capital

Schneider Electric - How 6 AI Attributes Change Data Center Design

The Green Grid - PUE: A Comprehensive Examination of the Metric