Inventory matériel et logiciel : automatiser le rapport mensuel pour la direction

Un inventaire manuel, c'est une dette de sécurité silencieuse

Un parc de 60 endpoints géré à la main dans un fichier Excel produit en moyenne trois catégories d'erreurs : des machines oubliées (shadow IT), des logiciels non recensés (et donc non patchés), et des licences fantômes consommant du budget. Pour une PME romande de 40 à 80 personnes, la surface d'attaque non visible représente régulièrement 15 à 25 % du parc réel — un chiffre que confirment les audits terrain. La NCSC classe d'ailleurs l'absence d'inventaire à jour parmi les manquements les plus fréquents observés lors des incidents déclarés par les PME suisses.

Automatiser l'inventaire ne signifie pas acheter un outil de plus : cela signifie définir une architecture de collecte, choisir les sources autoritatives, et produire un rapport que la direction peut lire en cinq minutes sans avoir à interpréter des données brutes.

Socle conceptuel : sources de vérité et canaux de collecte

Les sources autoritatives selon le type d'endpoint

Un inventaire fiable repose sur deux principes : la source autoritnatives unique par plateforme, et la corrélation automatique entre sources. En environnement mixte :

• macOS : Apple Business Manager (ABM) fournit la vérité sur l'appartenance organisationnelle et le numéro de série. Le MDM (profil DEP/ADE) remonte les attributs hardware — modèle, RAM, stockage, version macOS — toutes les 8 à 24 heures selon la fréquence de check-in configurée.
• Windows : Windows Autopilot + Intune (ou équivalent MDM) remonte le numéro de série, le BIOS, la version de l'OS (ex. Windows 11 23H2), le statut BitLocker et la liste des applications Win32 installées via la politique d'inventaire MSI/MSIX.
• Android (mobile et tablettes) : Android Enterprise en mode Work Profile ou Fully Managed Device remonte les attributs de l'appareil via l'API Android Management. Le numéro IMEI, la version du firmware et les apps du profil professionnel sont visibles dans la console MDM.
• Linux et IoT : un agent léger comme FleetDM (protocole osquery) collecte les paquets installés, les ports ouverts et les hashes de fichiers critiques. La fréquence de collecte est configurable par requête SQL osquery — typiquement 15 minutes pour les éléments de sécurité, 24 heures pour l'inventaire logiciel stable.

Corrélation et dédoublonnage

Le numéro de série est la clé primaire universelle : il relie la fiche ABM, l'enregistrement MDM et l'entrée CMDB. Sur Windows, le champ SerialNumber WMI (Win32_BIOS) remplit le même rôle. Toute solution d'agrégation (CMDB, ITSM, même un script Python + SQLite) doit utiliser ce champ comme identifiant unique — jamais le nom de machine, qui change lors d'un reprovisioning.

Architecture d'un pipeline d'inventaire automatisé

Collecte : push ou pull ?

Les MDM modernes fonctionnent en push APNS/FCM pour déclencher un check-in, puis en pull HTTPS pour récupérer le rapport MDM. La latence réelle entre une modification hardware et sa visibilité dans la console varie :

• macOS avec MDM Declarative Device Management (DDM, disponible depuis macOS 13) : mise à jour quasi-temps réel sur les attributs déclarés.
• Windows Intune : cycle de synchronisation par défaut toutes les 8 heures ; forçable via notification push ou script PowerShell Start-Process -FilePath "deviceenroller.exe" -ArgumentList "/o /c /d".
• Android Enterprise : check-in toutes les 24 heures par défaut, configurable à 1 heure pour les parcs à haute rotation.

Agrégation et normalisation

L'API REST de votre MDM expose les données en JSON ou XML. Un script d'agrégation (Python, PowerShell ou un connecteur natif selon l'outil) interroge l'API toutes les nuits entre 01h00 et 03h00, normalise les champs (nom de champ, encodage, fuseau horaire UTC+1/UTC+2 selon DST), et alimente une base de données centrale — PostgreSQL ou même une feuille Google Sheets via l'API Sheets si le parc est inférieur à 50 machines. Pour les parcs de 50 à 150 endpoints, une CMDB légère (ex. Snipe-IT, auto-hébergé sur un VPS en Suisse pour la conformité nLPD) est plus robuste.

Rapport mensuel : contenu minimal pour la direction

La direction n'a pas besoin de 400 lignes de CSV. Un rapport d'une page A4 (ou un dashboard PDF exporté) doit contenir :

1. Nombre total d'endpoints actifs par plateforme (macOS / Windows / Android / Linux), avec delta mois précédent.
2. Taux de conformité OS : pourcentage d'appareils sur la version N ou N-1 supportée. Exemple : macOS 14 Sonoma et 13 Ventura = conformes ; macOS 12 et antérieur = non conformes.
3. Logiciels non autorisés : applications détectées hors liste blanche (politique CIS ou interne), avec nombre de machines concernées.
4. Licences actives vs. achetées : delta par application clé (suite bureautique, antivirus, VPN).
5. Machines sans check-in depuis > 30 jours : indicateur de machines hors service ou dérobées — à croiser avec le registre RH pour les départs.
6. Alertes de sécurité actives : CVE critiques (CVSS ≥ 9.0) affectant des logiciels inventoriés, non patchés.

Ce format s'aligne sur les exigences de reporting recommandées par le CIS Controls v8 (Control 1 : Inventory of Enterprise Assets, Control 2 : Inventory of Software Assets) et constitue une base documentaire solide pour un audit ISO 27001 (contrôle A.8.1).

Obligations légales et réglementaires en Suisse

nLPD et registre des activités de traitement

Depuis le 01.09.2023, la nLPD impose aux entreprises qui traitent des données personnelles à grande échelle de tenir un registre des activités de traitement (art. 12 nLPD). L'inventaire logiciel fait partie des données à documenter : chaque application traitant des données personnelles (CRM, RH, comptabilité) doit y figurer avec sa version, son éditeur et sa localisation de stockage. Un inventaire automatisé sert donc de base de données vivante pour maintenir ce registre sans effort manuel supplémentaire.

Implications pour les entreprises régulées

Les entreprises soumises à la FINMA (banques, assurances, gestionnaires de fortune) doivent répondre à la Circulaire FINMA 2023/1 sur les risques opérationnels et de résilience, qui exige une cartographie à jour des systèmes critiques. Un inventaire automatisé avec historique versionné (git-like ou snapshot mensuel) répond directement à cette exigence de traçabilité. Le délai de reconstitution après incident doit être inférieur à 24 heures pour les systèmes de niveau 1 — impossible sans inventaire temps réel.

Cas pratique : fiduciaire vaudoise, 55 endpoints

Contexte

Fiduciaire de 42 collaborateurs à Lausanne, parc de 55 endpoints : 28 MacBook Pro (macOS 14 Sonoma), 18 PC Windows 11 23H2, 9 iPhones en MDM. Avant le projet, l'inventaire était tenu dans un fichier Excel mis à jour deux fois par an lors des audits internes. Lors d'un incident de ransomware (Q3 2023), l'IT a mis 11 heures à déterminer quels postes étaient concernés par une version vulnérable d'un plugin PDF.

Architecture déployée

1. Enrollment MDM : migration de tous les Mac vers ABM + MDM (profil ADE). Les Windows ont été enrôlés via Autopilot avec profil Intune existant. Les iPhones en Android Enterprise — pardon, en Apple MDM — déjà enrôlés, synchronisation activée.
2. Script d'agrégation : un script Python (80 lignes) tourne chaque nuit à 02h00 sur un mini-serveur Ubuntu hébergé en Suisse. Il interroge l'API REST MDM, récupère les champs serial_number, os_version, last_check_in, installed_apps et les écrit dans une base PostgreSQL.
3. Normalisation : une table de référence liste les applications autorisées (whitelist de 47 apps) et les versions minimales acceptables. Une requête SQL génère automatiquement la liste des écarts.
4. Rapport PDF : un template Jinja2 + WeasyPrint génère un PDF de 2 pages le 1er de chaque mois à 06h00, envoyé par mail au DSI et à la direction. Temps de lecture estimé : 4 minutes.

Résultats après 3 mois

• Temps de génération du rapport : de 3,5 heures manuelles à 0 minute humaine.
• Découverte de 7 logiciels non autorisés (3 outils de prise en main à distance personnels, 2 clients BitTorrent, 2 apps de cloud storage non approuvées) — aucun n'était référencé dans l'ancien Excel.
• 4 machines sans check-in depuis > 45 jours identifiées : 2 correspondaient à des départs non signalés au DSI, 1 à un appareil prêté et oublié, 1 à un Mac en réparation non référencé.
• Économie de licences : 3 licences Adobe Acrobat Pro payées pour des comptes inactifs depuis > 6 mois, résiliation = économie de 3 × CHF 240/an = CHF 720/an.
• Lors d'un test de réponse à incident simulé (tabletop exercise, novembre 2024), le temps d'identification des postes affectés par une vulnérabilité hypothétique est passé de 11 heures à 18 minutes.

Coût du projet

Développement du script et configuration : 2 jours de travail DSI interne. Coût infrastructure : VPS Ubuntu 2 vCPU / 4 Go RAM hébergé en Suisse ≈ CHF 25/mois. Aucune licence logicielle supplémentaire. ROI atteint dès le premier mois grâce aux licences récupérées.

Récapitulatif opérationnel

SynGuard propose un connecteur natif qui implémente l'essentiel de cette architecture pour les PME romandes sans ressources de développement internes. Voici les étapes à suivre indépendamment de l'outil choisi :

1. Identifier les sources autoritatives par plateforme (ABM pour macOS, Autopilot/Intune pour Windows, console MDM pour Android) et désigner une CMDB centrale — même légère.
2. Enrôler 100 % du parc dans le MDM avant toute chose : un endpoint hors MDM est invisible. Viser zéro exception, y compris les machines de direction.
3. Définir la liste blanche logicielle (applications autorisées + versions minimales) en collaboration avec les métiers. La mettre à jour trimestriellement.
4. Automatiser la collecte nocturne via l'API REST du MDM. Stocker l'historique : conserver au minimum 13 mois de snapshots pour permettre les comparaisons year-over-year et répondre aux exigences de traçabilité nLPD.
5. Définir le contenu du rapport direction : 6 indicateurs maximum, un code couleur vert/orange/rouge, aucune donnée brute. Valider le format avec la direction avant de l'automatiser.
6. Planifier une revue manuelle trimestrielle : l'automatisation détecte les écarts, mais un œil humain valide les exceptions légitimes (machine de test, appareil de remplacement temporaire).
7. Aligner l'inventaire logiciel sur le registre des activités de traitement requis par l'art. 12 nLPD : toute app traitant des données personnelles doit y figurer avec sa version et sa localisation de données.
8. Tester le processus de réponse à incident : simuler une CVE critique et mesurer le temps nécessaire pour identifier les endpoints exposés. Objectif : moins de 30 minutes pour un parc de 150 endpoints.
9. Croiser mensuellement les départs RH avec la liste des machines sans check-in : c'est le contrôle le plus simple et le plus efficace contre le vol ou la perte silencieuse d'actifs.
10. Documenter et versionner les scripts dans un dépôt git interne : un script non documenté devient du shadow IT à la première absence de son auteur.

Sources

• Centre national pour la cybersécurité (NCSC) — Recommandations pour la gestion des actifs et la réponse aux incidents pour les PME suisses.
• Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nouvelle LPD en vigueur depuis le 01.09.2023, notamment art. 12 sur le registre des activités de traitement.
• CIS Controls v8 — Center for Internet Security — Controls 1 et 2 : Inventory of Enterprise Assets et Inventory of Software Assets, référence de base pour l'audit d'un parc endpoints.
• ISO/IEC 27001 — iso.org — Norme de management de la sécurité de l'information, contrôle A.8.1 sur la gestion des actifs informationnels.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Guidance sur les obligations de documentation et de traçabilité dans le cadre de la nLPD.