Intune Application Inventory et Properties Catalog : construire un inventaire exploitable

L’essentiel

Properties Catalog définit les catégories et propriétés matérielles ou système qu’Intune doit collecter sur les postes Windows. Les résultats apparaissent dans Device Inventory et reposent sur le Microsoft Device Inventory Agent.

Application Inventory enrichit la visibilité logicielle par rapport à l’ancien rapport Discovered apps. Je conserve néanmoins la distinction entre application détectée, application gérée et application réellement utilisée.

Device Query interroge un poste à la demande; l’inventaire collecte périodiquement pour le parc; les rapports et le Data Warehouse répondent à d’autres horizons. Les combiner sans expliquer leur fraîcheur produit des chiffres contradictoires.

Properties Catalog définit les catégories et propriétés matérielles ou système qu’Intune doit collecter sur les postes Windows. Les résultats apparaissent dans Device Inventory et reposent sur le Microsoft Device Inventory Agent.

Pourquoi cette technologie existe

L’ancien inventaire applicatif Intune était souvent jugé trop lent ou trop pauvre pour les décisions opérationnelles. La plateforme de données Intune apporte des propriétés plus détaillées et une collecte configurable.

Collecter tout ce qui est disponible n’est pas une stratégie. Chaque catégorie augmente le volume, la surface de données et les questions de confidentialité. Je pars des cas d’usage: sécurité, renouvellement matériel, support, compatibilité ou licence.

Application Inventory et Properties Catalog s’appuie sur la chaîne Policy → Agent → Platform → Use. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont licence/capacité Intune confirmée, appareil corporate Intune-managed ou co-managed supporté, Entra joined ou hybrid joined, rôle Policy and Profile Manager pour configurer. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Aucun onglet Device Inventory, Profil reçu, aucune donnée et Valeurs anciennes. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. Policy ouvre la séquence: Properties Catalog sélectionne les données autorisées. Agent prend ensuite le relais: Device Inventory Agent collecte localement. Le traitement se poursuit avec Platform, où Intune reçoit, normalise et conserve les observations. Enfin, Use ferme la boucle: Device Inventory, Query, rapports et API. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Aucun onglet Device Inventory » conduit d’abord à vérifier Tenant et type de device, car la cause possible est Éligibilité, licence ou rollout. Pour « Profil reçu, aucune donnée », la preuve utile devient Logs agent. Les cas « Valeurs anciennes » et « Intune et ConfigMgr diffèrent » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont Application Inventory et Properties Catalog expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions licence/capacité Intune confirmée, appareil corporate Intune-managed ou co-managed supporté, Entra joined ou hybrid joined, rôle Policy and Profile Manager pour configurer doivent être réunies en même temps. La validation porte ensuite sur couverture pilote mesurée, fraîcheur connue, valeurs locales concordantes et données minimisées. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

La policy est affectée aux groupes de postes. Au prochain check-in, Windows reçoit la sélection et l’agent collecte les catégories demandées. La première remontée peut demander jusqu’à la fenêtre documentée par Microsoft; elle n’est pas instantanée.

Certaines propriétés minimales sont automatiquement ajoutées pour identifier le poste et structurer les données. La suppression d’une policy arrête la collecte mais les dernières données peuvent rester visibles pendant une durée documentée, actuellement jusqu’à 28 jours.

L’agent écrit ses journaux sous C:\Program Files\Microsoft Device Inventory Agent\Logs. Une absence de résultat doit être séparée en non-éligibilité, policy non reçue, collecte locale, upload ou affichage.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose licence/capacité Intune confirmée, appareil corporate Intune-managed ou co-managed supporté, Entra joined ou hybrid joined, rôle Policy and Profile Manager pour configurer, objectif et base légale de collecte définis. Ces conditions permettent de distinguer une limite de Application Inventory et Properties Catalog d’un scénario simplement non éligible.

• licence/capacité Intune confirmée
• appareil corporate Intune-managed ou co-managed supporté
• Entra joined ou hybrid joined
• rôle Policy and Profile Manager pour configurer
• objectif et base légale de collecte définis
• groupes pilotes stables
• durée de conservation comprise

Cycle de fonctionnement, étape par étape

Le cycle de Application Inventory et Properties Catalog traverse Policy → Agent → Platform → Use. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Application Inventory et Properties Catalog, les étapes « Définir les décisions attendues », « Créer un catalogue pilote », « Contrôler la chaîne locale », « Qualifier la qualité » séparent l’intention, son transport, son traitement et le résultat final.

Inventaire applicatif : ce que signifie une ligne

Une ligne d’application décrit une observation sur un appareil, pas nécessairement une application distribuée par Intune. Je relie nom, éditeur, version et emplacement avant de dédupliquer les variantes.

Les applications non gérées peuvent être visibles selon propriété et type de device. La présence n’établit ni l’usage ni la conformité de licence. Un produit portable, un composant utilisateur ou une mise à jour peut échapper au modèle attendu.

Je conserve l’identifiant technique et la date de dernière observation. Regrouper uniquement par DisplayName fusionne parfois plusieurs produits; séparer strictement chaque chaîne peut au contraire gonfler le catalogue.

Properties Catalog et minimisation

Je sélectionne les catégories nécessaires plutôt que tout activer. BIOS et TPM servent à la préparation firmware; batterie et disque au renouvellement; chiffrement à la sécurité; réseau au support. Chaque usage possède un accès RBAC et une durée.

Certaines catégories ne peuvent être arrêtées qu’en retirant toutes leurs propriétés. Je documente cette granularité avant de promettre une suppression immédiate d’une donnée isolée.

Les informations du client peuvent être altérées par un administrateur local. Pour une décision de sécurité, je croise l’inventaire avec conformité, attestation ou Defender au lieu de lui attribuer une confiance qu’il n’a pas.

Fraîcheur, co-management et sources concurrentes

Device Inventory Intune et Resource Explorer Configuration Manager peuvent coexister sur un appareil tenant attach. Je nomme toujours la source dans le rapport et je n’aligne pas les lignes sur le seul nom du poste.

Une valeur vide peut signifier propriété non demandée, collecte non terminée, donnée non applicable ou échec. Le tableau de bord doit distinguer ces états au lieu de les convertir tous en Inconnu.

Pour une décision urgente sur un poste, Device Query est plus adapté. Pour une tendance de parc, l’inventaire et les exports sont adaptés. Pour un modèle historique, je vérifie les capacités du Data Warehouse ou du reporting export.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles profil et propriétés, affectation effective, version/éligibilité du poste, logs Device Inventory Agent. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Application Inventory et Properties Catalog, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  [pscustomobject]@{
    ComputerName = $env:COMPUTERNAME
    BiosVersion  = (Get-CimInstance Win32_BIOS).SMBIOSBIOSVersion
    MemoryGB     = [math]::Round((Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory / 1GB, 1)
    TpmReady     = (Get-Tpm).TpmReady
  }
  Get-ChildItem -LiteralPath 'C:\Program Files\Microsoft Device Inventory Agent\Logs' -ErrorAction SilentlyContinue |
    Select-Object Name, Length, LastWriteTime
}
catch { Write-Error "Contrôle inventaire impossible : $($_.Exception.Message)"; exit 1 }

Observabilité : où lire l’état réel

Je collecte profil, affectation, dernier check-in, journaux agent et heure de dernière donnée affichée. Une capture de la console seule ne localise pas la rupture.

Les logs Device Inventory Agent peuvent être collectés avec l’action de diagnostic Intune. Je minimise les données avant transfert et je respecte les règles internes de conservation.

• profil et propriétés
• affectation effective
• version/éligibilité du poste
• logs Device Inventory Agent
• heure de collecte
• heure d’affichage
• comparaison locale
• taux de couverture

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque couverture pilote mesurée, fraîcheur connue, valeurs locales concordantes et données minimisées. Ces contrôles relient la configuration du service au résultat réellement observé.

• couverture pilote mesurée
• fraîcheur connue
• valeurs locales concordantes
• données minimisées
• RBAC vérifié
• cas vide distingués
• rapport indique source et date

Limites, modes de panne et lecture des erreurs

Les écarts connus de Application Inventory et Properties Catalog incluent Aucun onglet Device Inventory, Profil reçu, aucune donnée, Valeurs anciennes, Intune et ConfigMgr diffèrent. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Application Inventory et Properties Catalog commence sur le périmètre postes Windows corporate Intune ou co-managed éligibles, inventaire matériel, système et applicatif, consultation par poste et exploitation agrégée. Les limites et actions de réversibilité ci-dessous cadrent la progression.