Le référentiel

Automatiser suppose de savoir ce qui est vrai.

L'inventaire existe souvent en quatre exemplaires qui se contredisent. Tant que ce désaccord subsiste, chaque automatisation construite au-dessus hérite de l'erreur. Notre premier travail est donc toujours le même : produire un enregistrement, et un seul, par équipement — et le rendre digne de confiance.

enregistrements bruts — redondants, partiels, contradictoires → Réconciliation → System of Record → Actions automatiques / CMDB & ITAM — Des outils raccordés, une donnée réconciliée, et les actions qui se déclenchent dessus. Le MCP intervient à deux endroits : en amont pour enrichir la donnée avec des sources que l'inventaire technique ne couvre pas, et en aval pour permettre à l'IA d'analyser le référentiel et de déclencher les actions correspondantes.

La chaîne

Quatre opérations, dans cet ordre.

01

Collecter

Agents, scans réseau actifs et passifs, découverte du cloud, du SaaS, de l'OT/IoT et des environnements historiques — y compris les équipements intermittents ou dissimulés. Sur les périmètres industriels et connectés, la télémétrie MQTT complète la collecte. À cela s'ajoutent vos sources existantes, raccordées par connecteurs : Entra ID, AWS, Jamf, ServiceNow, Chrome Enterprise, ainsi que vos outils de vulnérabilité — Tenable, Rapid7, Qualys.

02

Réconcilier

Un même équipement vu par cinq sources ne doit produire qu'un seul enregistrement. La normalisation et la réconciliation éliminent les doublons et comblent les lacunes, jusqu'à obtenir un jeu de données cohérent. C'est l'opération la plus ingrate du projet, et celle qui détermine tout le reste.

03

Enrichir

L'enregistrement technique reçoit son contexte : propriétaire, coût, garantie, contrat, criticité métier, et les dépendances amont et aval qui disent ce qui tombe si l'équipement tombe. C'est ce contexte qui permet à une automatisation d'évaluer un impact avant d'agir.

04

Faire autorité

Le référentiel devient la source unique, revalidée en continu, partagée par l'IT et par la sécurité. À partir de ce point, une action automatique cesse d'être un pari.

Nous nous appuyons sur la gamme System of Record de la plateforme — moteur de découverte, inventaire des actifs et des équipements, relations contextuelles et gestion du parc logiciel. Le raccordement de vos sources existantes et le paramétrage des règles de réconciliation constituent l'essentiel de nos missions de cadrage.

Sur le terrain

Deux cas rencontrés.

Les deux exemples ci-dessous portent sur la partie la plus ingrate du sujet : obtenir une donnée juste sur des équipements que personne n'inventorie spontanément, et savoir ce qui manque encore au référentiel.

I

Découvrir un réseau mondial sans saturer les liaisons

Le contexte

Un parc réparti sur des dizaines de sites dans le monde, avec des liaisons WAN étroites vers certaines implantations. Un balayage lancé depuis le siège aurait saturé les liens et rendu des résultats partiels — donc un inventaire faux, ce qui est pire qu'un inventaire absent.

Ce que nous avons mis en place

Des postes relais équipés d'un agent sur chaque zone, qui exécutent la découverte localement et ne remontent que le résultat consolidé. La charge de balayage reste sur le réseau local ; seul l'inventaire traverse le WAN. La découverte combine le balayage IP et l'interrogation SNMPv3 avec authentification et chiffrement — condition posée par la sécurité pour autoriser l'interrogation des équipements. Les caractéristiques des éléments réseau sont extraites par OID, ce qui permet de récupérer modèle, version de firmware, ports et état sans dépendre d'un connecteur propriétaire par constructeur.

Le résultat

Une découverte mondiale exécutée dans la fenêtre de nuit propre à chaque région, sans dégrader les liaisons, et des équipements réseau enfin présents dans le référentiel au même titre que les postes et les serveurs.

II

Confronter la CMDB à l'IPAM pour savoir ce qui manque

Le contexte

Une CMDB correctement alimentée par la découverte, mais sans aucun moyen de mesurer ce qui lui échappait. Une adresse absente de l'inventaire peut être une machine non gérée, un équipement oublié, ou simplement une plage que personne n'a déclarée — et rien ne permettait de faire la différence.

Ce que nous avons mis en place

L'intégration des données de l'outil d'IPAM dans la CMDB, puis un rapprochement systématique entre ce que l'IPAM déclare et ce que la découverte constate. Trois familles d'écarts sont remontées : les adresses actives inconnues du référentiel, les éléments dont la localisation déclarée ne correspond pas à celle observée, et les plages IP utilisées mais jamais déclarées.

Le résultat

Une liste d'écarts exploitable, plutôt qu'un sentiment diffus d'incomplétude. Chaque adresse inconnue devient une question à trancher, et le taux de couverture du référentiel devient un indicateur mesurable, suivi dans le temps.

En aval

Deux conséquences qui se renforcent l'une l'autre.

I

Des actions qui partent seules, et qui portent juste

Correctifs priorisés par l'exposition réelle et la criticité métier plutôt que par un calendrier. Remédiation des dérives de configuration avant qu'elles ne produisent un incident. Ouverture, qualification et routage automatiques des tickets. Décisions d'accès conditionnel fondées sur l'état vérifié de l'équipement. L'automatisation préventive n'est possible que parce que la donnée dit vrai au moment où la règle s'évalue — sinon elle ne fait qu'appliquer une erreur plus vite.

II

Une CMDB qui ne se dégrade pas, et des actifs enfin maîtrisés

Les éléments de configuration sont réconciliés en continu depuis la découverte, avec un historique de changement par CI qui rend la dérive visible et traçable. Sur cette base, la gestion des actifs devient réellement exploitable : droits acquis rapprochés des installations et de l'usage constaté, cycle de vie du matériel et du logiciel, préparation aux audits éditeurs. Une CMDB tenue à la main meurt en dix-huit mois ; une CMDB alimentée par la découverte survit à ses auteurs.

Deux garanties

La conformité cesse de dépendre de la bonne volonté des flux.

Une CMDB alimentée par les seuls processus de service management ne connaît que ce qui a fait l'objet d'un ticket. Tout le reste — les machines remplacées sans demande, les configurations modifiées en urgence, les équipements arrivés par une autre porte — lui échappe silencieusement. Un référentiel qui reconstate en continu supprime cette dépendance, et rend au passage la gestion des équipements enfin pilotable.

System of Record → CMDB conforme en continu + ITAM — gestion des équipements — Ce que garantit un référentiel fiable, en aval. En haut, le chemin habituel : les flux service management sont censés tenir la CMDB à jour, mais ils ne l'actualisent que lorsqu'un ticket passe — et seulement sur ce que le ticket décrit. Au centre, le référentiel affirme l'état constaté en continu. À droite, les deux garanties qui en découlent, et la boucle qui ramène ce qui est constaté vers les décisions d'achat.