Presque tous les chantiers de sécurité butent au même endroit. Prioriser des vulnérabilités suppose de savoir où elles sont. Détecter suppose de savoir ce qui est normal sur quelle machine. Restaurer suppose de savoir quoi restaurer.
L’inventaire n’est pas un préalable administratif. C’est la condition de tout le reste.
Pourquoi il n’existe jamais
Parce qu’il ne produit rien de visible. Un inventaire ne bloque aucune attaque, n’apparaît sur aucun tableau de bord et ne se démontre pas en comité. Il est donc systématiquement repoussé derrière des chantiers plus démonstratifs.
Et parce qu’il est perçu comme une tâche infinie. Sur un parc réel, la première extraction révèle toujours plus de machines que prévu, dont une partie que personne ne revendique.
Ce qu’il doit contenir — et rien de plus
Un inventaire exhaustif ne se maintient pas. Un inventaire minimal se maintient. Six champs suffisent :
- Identifiant et nom.
- Fonction : à quoi sert cette machine, en une phrase.
- Propriétaire métier : une personne, pas un service.
- Criticité : trois niveaux suffisent.
- Exposition : Internet, interne, segment cloisonné.
- Données traitées : y a-t-il des données personnelles ou sensibles.
Les deux derniers champs rendent possible une priorisation contextuelle. Le troisième débloque les décisions.
Les sources à croiser
Aucune source unique ne donne l’image complète. Le croisement en donne une utilisable :
- L’annuaire et les systèmes de gestion de parc.
- Les baux d’adresses réseau.
- Les journaux DNS — une machine qui résout des noms existe.
- La console d’administration des protections de postes.
- Les factures d’hébergement et d’abonnements, qui révèlent les environnements non déclarés.
L’écart entre ces sources est en soi une information : une machine présente dans le réseau et absente de la console de protection est un problème identifié.
La méthode qui aboutit
Ne commencez pas par tout. Prenez le périmètre le plus critique et faites-le complètement. Un inventaire fiable sur 15 % du parc vaut mieux qu’une liste incertaine sur 100 %.
Attribuez un propriétaire avant de documenter le reste. Sans propriétaire, personne ne validera l’information ni ne signalera un changement.
Automatisez ce qui peut l’être, et gardez en manuel les seuls champs qui ne se déduisent pas : criticité, propriétaire, données traitées.
Branchez l’inventaire sur un processus existant. Une mise en service qui ne passe pas par l’inventaire produira un actif fantôme dès le premier mois.
Le test de qualité
Prenez cinq machines au hasard. Pour chacune : quelqu’un peut-il dire en trente secondes à quoi elle sert, qui en est responsable et si on peut l’éteindre ?
Si la réponse est non sur deux d’entre elles, votre gestion des vulnérabilités, votre détection et votre plan de reprise reposent sur du sable.
Ce que demandent les référentiels
La mesure 5.9 d’ISO/IEC 27002:2022 impose un inventaire des informations et actifs associés, avec des propriétaires identifiés. La mesure 5.12 traite de leur classification.
C’est l’un des premiers éléments qu’un auditeur demande, parce qu’il conditionne la crédibilité de tout le système de management.
Le piège de l’outil
Le réflexe habituel consiste à acheter une solution de découverte automatique. Elle produit en quelques jours une liste de plusieurs milliers d’entrées, et le projet s’arrête là — parce qu’une liste n’est pas un inventaire.
La découverte automatique répond à une seule question : qu’est-ce qui est connecté ? Elle ne répond à aucune des trois qui rendent l’inventaire utile — à quoi cela sert, qui en est responsable, et quelle serait la conséquence de son indisponibilité ou de sa compromission. Ces informations ne se découvrent pas, elles se déclarent.
L’outil reste utile, mais à sa place : il sert à confronter le déclaratif au réel, et l’écart entre les deux est en lui-même un résultat exploitable. Un actif découvert qu’aucun responsable ne revendique est soit un oubli, soit un système que plus personne n’administre — les deux méritent une décision.
Les actifs qu’on n’inventorie jamais
Les inventaires se concentrent sur les serveurs et les postes, c’est-à-dire sur ce que l’informatique gère directement. Cinq catégories échappent presque systématiquement au périmètre, et ce sont souvent celles qui posent problème :
- Les services souscrits en ligne par les directions métier. Outils de gestion de projet, de signature, de messagerie collaborative, souscrits par carte bancaire sans passer par l’informatique. Ils hébergent des données réelles et ne figurent nulle part.
- Les noms de domaine et les certificats. Répartis entre plusieurs bureaux d’enregistrement, parfois au nom personnel d’un ancien salarié. Une expiration non anticipée provoque une interruption complète et immédiate.
- Les comptes d’hébergement en nuage. Un environnement ouvert pour une expérimentation, jamais fermé, contenant des données de production copiées « pour tester ».
- Les accès accordés à des tiers. Connexions de prestataires, interconnexions avec des partenaires, transferts automatisés de fichiers. Ils constituent des points d’entrée à part entière.
- Les données elles-mêmes. Un inventaire limité aux machines ne dit pas où se trouvent les informations sensibles — or c’est cette question que posent le RGPD, l’analyse de risque et l’assureur.
Maintenir, le vrai sujet
Constituer un inventaire est un projet de quelques semaines. Le maintenir est un problème permanent, et c’est là que tout se joue : un inventaire à dix-huit mois est réputé faux par tout le monde, donc plus personne ne l’utilise, donc plus personne ne le met à jour.
Deux principes évitent cette spirale.
La mise à jour est un effet de bord, pas une tâche. Un inventaire alimenté par une revue annuelle dédiée se dégrade. Un inventaire alimenté par les processus qui créent et suppriment les actifs — commande, mise en service, sortie de parc, clôture de projet — reste à jour sans effort supplémentaire. Le travail porte donc sur ces processus, pas sur l’inventaire.
Il doit servir à quelque chose au quotidien. Un référentiel consulté uniquement lors des audits n’est pas corrigé quand il se trompe. Un référentiel utilisé pour ouvrir un ticket, planifier une intervention ou déclencher une astreinte est corrigé immédiatement par celui que l’erreur bloque. C’est le seul mécanisme de qualité qui fonctionne durablement.
Sources
- ISO/IEC 27002:2022, mesures 5.9 et 5.12
- ANSSI — Guide d’hygiène informatique
- Directive (UE) 2022/2555 (NIS 2), article 21
Aller plus loin
L’état des lieux de votre inventaire fait partie de l’audit 360. Voir aussi pourquoi la détection en dépend.