Fiabiliser une CMDB : brancher plutôt que saisir

Posez la question à une équipe qui dispose d’une CMDB : « combien de tablettes avons-nous en stock ? »

Si la réponse consiste à appeler quelqu’un plutôt qu’à ouvrir l’outil, le diagnostic est fait. Ce n’est pas rare, et ce n’est pas un cas isolé : beaucoup de CMDB alimentées manuellement finissent avec la moitié de leurs fiches inchangées depuis des années. Numéros de série absents, affectations périmées, statuts fantaisistes.

L’alimentation automatique depuis un MDM change complètement la donne. Voici comment s’y prendre, et surtout ce que la documentation ne dit pas.

Le problème n’est jamais l’outil

C’est le premier réflexe à écarter. Une CMDB obsolète n’est presque jamais un problème de logiciel, et encore moins un manque de sérieux des équipes.

C’est une fatalité arithmétique. Une donnée saisie à la main se périme, sauf si quelqu’un a la charge explicite de la maintenir. Mettre à jour une fiche quand on remet une tablette à un agent ne rapporte rien à celui qui le fait et lui coûte trente secondes. Multipliez par le nombre de mouvements dans l’année, et le résultat est écrit d’avance.

Pendant ce temps, d’autres outils connaissent le parc en temps réel : un MDM pour les mobiles et tablettes, une solution de découverte par agent pour les postes de travail. Ces outils servent à administrer le parc au quotidien, donc leur information est vraie par construction, sans effort dédié.

D’où le renversement qui doit structurer le chantier : la CMDB n’a pas à concurrencer cette information. Elle doit la refléter, et se concentrer sur ce que le MDM ne saura jamais - l’organisation propriétaire, les contrats, la criticité métier, l’histoire de la machine.

Le principe qui en découle : flux quotidien, unidirectionnel, du MDM vers la CMDB, avec verrouillage partiel.

Ce qu’iTop sait déjà faire

Bonne nouvelle, largement sous-estimée : iTop embarque nativement un mécanisme de synchronisation de données. On lui décrit la classe cible, la clé de réconciliation, le comportement champ par champ et une politique de cycle de vie. Il se charge du reste - créer, mettre à jour, réconcilier avec l’existant, et verrouiller les champs pilotés, qui deviennent non modifiables à la main.

Le développement se réduit donc à un collecteur : un script qui interroge l’API du MDM, produit un fichier, et le transmet à iTop par un appel HTTP vers son point d’entrée d’import. Un seul fichier Python, sans aucune dépendance externe, exécuté par une tâche planifiée quotidienne.

Le volume de code n’est pas le sujet, et il ne doit pas faire peur : la difficulté ne vient jamais du script, elle vient de la compréhension de l’API en face.

Pas d’usine à gaz, pas de licence supplémentaire. Ça mérite d’être dit, parce que la crainte du chantier lourd est souvent ce qui empêche de commencer.

Trois décisions qui comptent plus que le code

La clé de réconciliation

C’est la décision structurante : sur quel attribut raccorder un équipement du flux à une fiche existante ? Le numéro de série s’impose - stable, unique, il survit à un reformatage.

Sauf qu’une clé parfaite côté MDM ne sert à rien si les fiches existantes ne la portent pas. Elle réconcilierait zéro fiche et créerait un doublon de tout le parc. Le taux de remplissage du numéro de série côté CMDB est donc le chiffre à vérifier avant de concevoir quoi que ce soit.

Méfiez-vous aussi des champs qui semblent faire l’affaire. Un champ « nom de l’appareil » peut contenir un nom de machine Windows sur certains postes et un numéro de série sur d’autres, selon l’historique d’enrôlement. Le prendre pour clé serait un désastre. Le vrai numéro de série existe souvent, mais n’est pas toujours renvoyé par défaut par l’API - il faut le demander explicitement.

Le verrouillage partiel

Un MDM connaît le matériel. Il ne connaît ni le propriétaire, ni les contrats, ni la criticité. Configurer le mapping revient donc à répartir la souveraineté champ par champ : le MDM pilote le technique, l’humain garde le reste.

C’est un choix de gouvernance déguisé en configuration technique, et il se paie cash quand on le rate. Cas typique : la synchro écrase un champ de description dans lequel les agents notaient le suivi des postes - « récupéré le 24/04, remis à X le 28/04 ». Chaque nuit, leur travail disparaît.

La bonne correction ne consiste pas à leur demander d’arrêter. Elle consiste à leur donner un autre endroit : des attributs dédiés pour les données du MDM, un journal horodaté et signé pour la chronologie humaine, et la description laissée libre, hors périmètre de synchronisation.

Le principe vaut bien au-delà de ce chantier : quand une automatisation entre en conflit avec une pratique humaine, ce n’est pas la pratique qu’il faut corriger, c’est l’endroit où elle s’exprime.

La règle de gestion

C’est le point le plus contre-intuitif, et celui qu’on découvre toujours trop tard.

Une politique de cycle de vie prévoit typiquement qu’un équipement disparu du flux bascule en obsolète. Sauf qu’un équipement ne disparaît du flux que si quelqu’un le supprime du MDM. Une tablette morte au fond d’un tiroir, mais toujours enrôlée, continue de remonter indéfiniment. L’automatisme ne se déclenche donc jamais.

Une CMDB ne peut pas être plus fraîche que sa source, et la source dépend d’un geste humain.

La réponse tient dans une règle explicite, qui n’existe généralement nulle part avant qu’on ait à l’écrire : équipement désinscrit du MDM égale récupéré et réutilisable, passage en stock ; équipement supprimé du MDM égale sorti définitivement du parc, passage en obsolète. Le geste de suppression devient le déclencheur unique et sans ambiguïté de la mise au rebut.

Les bénéfices auxquels on ne s’attend pas

Au-delà de la fraîcheur des données, brancher un MDM ouvre deux portes.

La date de dernière connexion, ou de dernier scan, révèle les équipements dormants. Ce sont les vrais candidats à la sortie du parc, et cette information n’existait nulle part auparavant.

Surtout, la confrontation des deux systèmes met en évidence ce qui échappe aux deux. Des postes bien réels, utilisés par des collaborateurs, mais absents du MDM. Ce n’est pas un problème de CMDB : c’est un trou dans la couverture de l’inventaire, que rien d’autre n’aurait révélé.

Ce que personne ne vous dit

Aucun de ces obstacles n’est bloquant. Tous coûtent du temps.

Chaque API a sa propre logique d’authentification, et rien ne se devine : ça se découvre au premier appel réel. Une protection anti-robot peut bloquer le collecteur, la signature par défaut d’une bibliothèque HTTP étant souvent identifiée comme du trafic automatisé. La pagination ne suit pas toujours la documentation - mieux vaut suivre le lien « page suivante » tel que l’API le renvoie, sans imposer de taille de page. Et une API peut renvoyer beaucoup trop : demander le système d’exploitation d’un poste peut retourner la liste complète des services Windows, pour trois valeurs utiles.

Le piège le plus vicieux tient à une logique qu’on oublie facilement : un champ obligatoire mais marqué comme non piloté par la synchro reste vide, y compris à la création. L’objet ne peut alors pas être créé, et c’est toute une fournée qui échoue d’un coup. Vérifiez systématiquement que tous les champs obligatoires de la classe cible sont bien alimentés par le flux.

Ce qui amène un réflexe à prendre dès le premier jour : activer la notification par courriel des résultats de synchronisation. iTop peut envoyer après chaque passage un récapitulatif listant les créations, les mises à jour et surtout les erreurs. Sans ça, un flux qui échoue partiellement continue de tourner chaque nuit sans que personne ne s’en aperçoive - ce qui est pire qu’une CMDB obsolète, puisqu’on la croit à jour.

Dernier point, et il est salutaire : les doublons de l’existant remontent à la surface. La synchronisation refuse de trancher quand un numéro de série correspond à plusieurs fiches. Ces conflits, invisibles jusque-là, révèlent de vrais doublons historiques qu’il faut arbitrer un par un.

Pour résumer

Raisonnez en jours de travail effectif plutôt qu’en semaines de calendrier. Un premier flux s’étale volontiers sur quelques semaines quand on l’avance entre deux tâches de RUN, mais le temps réellement passé est bien moindre - et il se concentre pour l’essentiel sur deux postes : la découverte de l’API et le nettoyage de l’existant. Ce nettoyage préalable est incontournable et systématiquement sous-estimé. Et l’automatisation ne dispense pas d’un dispositif d’audit : il faut continuer à mesurer ce que le flux couvre, et surtout ce qu’il ne couvre pas.

Mais l’enseignement principal est ailleurs. Le livrable d’un tel chantier n’est pas le script - c’est la règle.

« À partir de quand une tablette est-elle définitivement sortie du parc ? » n’a souvent jamais reçu de réponse formelle avant qu’il faille l’apprendre à un programme. Automatiser oblige à expliciter des règles de gestion qu’on croyait partagées et qui n’existaient nulle part. C’est probablement le bénéfice le plus durable de l’opération, et celui dont on parle le moins.