Infogérance · 25/09/2025
Tenir une CMDB vivante plutôt qu'un tableur mort
Tout inventaire d'infrastructure meurt de la même façon : il est constitué avec soin pendant un projet, puis il cesse d'être mis à jour dès que le projet s'achève. Six mois plus tard, plus personne ne s'y fie, et l'on recommence ailleurs. La seule parade connue consiste à ne pas le tenir à la main.
Un inventaire n'a de valeur que par sa fraîcheur. Une base de configuration exhaustive à quatre-vingt-dix-huit pour cent mais datée de dix-huit mois est moins utile qu'une base couvrant soixante pour cent du parc et vérifiée chaque nuit, parce que la première donne une fausse assurance alors que la seconde annonce ses trous.
Le seul indicateur qui compte
La mesure à afficher est la part des éléments dont la dernière découverte automatique remonte à moins de sept jours. Cet indicateur remplace avantageusement les compteurs de complétude, parce qu'il ne peut pas être atteint à la main. Il tombe dès que la découverte cesse de fonctionner, il tombe dès qu'un segment réseau devient inaccessible, et il tombe dès qu'un pan du parc échappe aux outils, ce qui est exactement ce qu'on veut voir.
En dessous de quatre-vingt-dix pour cent, l'inventaire cesse d'être opposable dans une discussion contractuelle ou dans une revue de sécurité. Au-dessus, il devient une référence, y compris pour vérifier le périmètre facturé par un prestataire, sujet que nous abordons dans notre décorticage d'un SLA d'infogérance ligne à ligne.
Réconcilier plusieurs sources plutôt qu'en interroger une
Aucune source unique ne voit tout. L'annuaire connaît les machines qui s'y authentifient et ignore les équipements réseau. L'hyperviseur connaît les machines virtuelles et ignore le matériel physique isolé. Le service d'attribution d'adresses voit ce qui demande une adresse et ignore ce qui est configuré en statique. Les tables des commutateurs voient tout ce qui se branche mais ne savent pas nommer. L'outil de sauvegarde sait ce qu'il protège, et surtout ce qu'il ne protège pas.
La méthode consiste donc à collecter ces sources séparément, puis à les réconcilier sur une clé stable, en conservant l'origine de chaque attribut. Les écarts entre sources sont le produit le plus utile de l'exercice : une machine vue par le commutateur et inconnue de l'annuaire mérite une visite, une machine sauvegardée mais absente de l'inventaire aussi.
| Source | Ce qu'elle voit | Son angle mort |
|---|---|---|
| Annuaire | Postes et serveurs joints au domaine | Équipements réseau, systèmes isolés |
| Hyperviseur | Machines virtuelles et hôtes | Matériel physique hors grappe |
| Tables des commutateurs | Tout ce qui se branche | Identité et rôle des machines |
| Outil de sauvegarde | Le périmètre protégé | Ce qui n'a jamais été déclaré |
Les relations valent plus que les attributs
Un inventaire qui liste des machines aide peu. Un inventaire qui décrit ce qui dépend de quoi change la conduite des incidents et des projets. Quatre relations suffisent pour l'essentiel : quelle application s'appuie sur quel serveur, quel serveur s'appuie sur quel stockage et quel hyperviseur, quel service dépend de quel lien réseau, et quelle application dépend de quelle autre.
Ces relations décident notamment de l'ordre de redémarrage après un arrêt général, qui reste la première cause de dépassement des délais de reprise annoncés. Elles alimentent aussi directement le chiffrage des objectifs de reprise, décrit dans notre analyse consacrée à la définition de RPO et RTO avec les métiers.
Le cycle de vie, du bon de commande à la benne
Un élément de configuration existe avant d'être branché et continue d'exister après avoir été débranché. Six états suffisent : commandé, réceptionné, en service, en réserve, retiré, détruit. L'état retiré est celui qu'on saute le plus souvent, et c'est celui qui coûte : un serveur débranché mais toujours facturé au contrat, une licence toujours payée, une règle de pare-feu toujours ouverte vers une adresse recyclée.
Ce dernier cas rejoint la segmentation du réseau, où une adresse libérée puis réattribuée à un autre usage ouvre silencieusement un accès. Nous décrivons cette mécanique dans notre note sur la segmentation d'un réseau de PME, où l'inventaire est le préalable à toute politique de filtrage tenable.
À quoi cela sert vraiment
Quatre usages justifient l'effort, et aucun n'est théorique. La sécurité, parce qu'on ne protège pas ce qu'on ne connaît pas, et parce que les obligations issues de la directive européenne sur la cybersécurité supposent une maîtrise démontrable du périmètre, comme nous l'expliquons dans notre note sur ce que NIS2 fait retomber sur les prestataires. La sauvegarde, parce que l'écart entre le parc et le périmètre protégé est la première cause de mauvaise surprise. Le contrat, parce que la facturation d'un prestataire se vérifie ligne à ligne, y compris ses engagements de délai, sujet traité dans nos repères sur les garanties de temps d'intervention et de rétablissement. Et la sortie, parce qu'aucune migration ne s'engage sans savoir ce qu'on déplace, comme nous le montrons à propos de la clause de réversibilité.
Le détail qui coûte cher
Attribuez un propriétaire métier à chaque application, avec un nom de personne et non un nom de service. C'est la seule information qu'aucune découverte automatique ne produira jamais, et c'est celle qu'on cherche en pleine nuit quand il faut décider d'arrêter ou non un système. Elle se met à jour une fois par trimestre, en quinze minutes.