Intune : choisir entre Microsoft Graph, Reports API et Data Warehouse

Résumé

Les ressources Graph opérationnelles décrivent l’état courant et permettent parfois l’action. La Reports export API génère des jeux proches de rapports Intune. Le Data Warehouse expose un modèle OData orienté tendances et Power BI avec une cadence différente.

Je recommande Graph pour l’automatisation ciblée, Reports API pour reproduire un rapport exportable et Data Warehouse pour un modèle analytique stable. Une extraction massive ne doit pas boucler aveuglément sur managedDevices.

Chaque tableau affiche source, date d’extraction, filtre, clé de jointure et limites. Les écarts de cadence et de population sont expliqués avant toute décision.

Les ressources Graph opérationnelles décrivent l’état courant et permettent parfois l’action. La Reports export API génère des jeux proches de rapports Intune. Le Data Warehouse expose un modèle OData orienté tendances et Power BI avec une cadence différente.

Contexte, objectif et périmètre

Deux chiffres Intune différents peuvent être exacts s’ils ne portent pas sur le même horodatage, la même définition ou la même source. Le portail peut lui-même consommer une infrastructure de rapport distincte des ressources Graph classiques.

Le choix technique a un impact sur permissions, performance, stabilité de schéma et conservation. Je conçois d’abord le contrat de données, puis l’outil.

Je traite « Graph, Reports API ou Data Warehouse » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

La configuration recommandée n’est pas une valeur universelle. Elle constitue un point de départ argumenté, à rapprocher des licences, des contraintes réseau, des responsabilités de support et de la maturité opérationnelle. Lorsque plusieurs méthodes existent, je privilégie celle qui réduit les autorités concurrentes et rend le résultat le plus facilement vérifiable.

Le passage en production suit une progression explicite : validation technique isolée, pilote métier, extension contrôlée puis généralisation. Chaque vague dispose de critères GO et NO-GO, d’une durée d’observation et d’un propriétaire capable d’arrêter ou de revenir en arrière sans attendre une décision improvisée.

• Objectif : comparer les trois plans de données
• Objectif : sélectionner la source par cas d’usage
• Objectif : construire des contrôles de qualité et de fraîcheur
• Périmètre : Intune device/app/configuration reporting
• Périmètre : Graph v1.0/beta, exportJobs et Data Warehouse OData
• Périmètre : Power BI et automatisation

Architecture et fonctionnement général

Graph expose des ressources comme managedDevices ou detectedApps, avec permissions et pagination propres. Le schéma reflète l’objet de service, pas nécessairement les colonnes d’un écran.

La Reports API utilise actuellement l’endpoint beta deviceManagement/reports/exportJobs pour de nombreux rapports. Le job est asynchrone : création, polling borné, téléchargement puis validation du fichier.

Le Data Warehouse fournit des collections OData et des relations pour l’analyse. Son snapshot et ses dimensions facilitent les tendances, mais il n’est pas le bon outil pour confirmer une action effectuée il y a quelques secondes.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

• question métier et niveau de fraîcheur
• catalogue local data/Graph consulté
• permissions minimales
• volumes estimés
• clés et relations documentées
• stockage sécurisé des exports
• propriétaire du modèle Power BI

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

Graph opérationnel

Graph convient à la lecture d’un objet et aux automatisations qui agissent ensuite. Je sélectionne les propriétés nécessaires, filtre côté serveur quand supporté et suis nextLink jusqu’au bout.

Une relation comme detectedApps peut nécessiter des appels supplémentaires et augmenter fortement le volume. Je mesure le coût avant de généraliser au tenant.

Le schéma beta n’est pas un contrat stable. Si une propriété n’existe qu’en beta, je documente le risque et un comportement en cas de disparition.

Reports export API

exportJobs demande un reportName, des colonnes et filtres spécifiques. Je vérifie la liste officielle des rapports et propriétés plutôt que de recopier le payload observé dans le navigateur.

Le job répond de façon asynchrone. Je borne le polling, respecte le statut, télécharge l’archive depuis l’URL temporaire puis contrôle format, taille, lignes et colonnes.

Un HTTP 200 lors de la création ne signifie pas que l’export est prêt ni complet. Le journal conserve jobId, état final, nombre de lignes et hash du fichier sans données personnelles.

Data Warehouse et modèle sémantique

Le Warehouse sépare faits et dimensions avec des clés techniques. Je joins sur les relations prévues, pas sur displayName. Les énumérations sont centralisées dans des tables de correspondance Unknown-safe.

Power BI stocke ses paramètres d’URL et son credential dans le service, pas dans le PBIX diffusé. Les rôles de workspace et la sécurité de ligne sont testés avec des comptes représentatifs.

Le modèle expose âge des données, couverture et taux d’objets sans correspondance. Un dashboard vert basé sur un refresh échoué est plus dangereux qu’une erreur visible.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

# Exemple pédagogique non testé — niveau 1
$ErrorActionPreference = 'Stop'
try {
  $body = @{ reportName='Devices'; format='csv'; select=@('DeviceName','OSVersion','LastContact') } | ConvertTo-Json
  $job = Invoke-MgGraphRequest -Method POST -Uri 'https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs' -Body $body -ContentType 'application/json'
  [pscustomobject]@{ JobId=$job.id; Status=$job.status; ExpirationDateTime=$job.expirationDateTime }
}
catch { Write-Error "Création de l’export impossible : $($_.Exception.Message)"; exit 1 }

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

• source adaptée au cas
• pagination/job complet
• fraîcheur affichée
• schéma contrôlé
• jointures testées
• écarts expliqués
• données protégées

Journaux, diagnostic et constitution des preuves

Je journalise source, endpoint, version, filtre, extraction UTC, lignes et schéma. Je compare le nombre attendu à la sortie et bloque la publication en cas de chute anormale.

Les exports peuvent contenir UPN, noms de postes et identifiants. Ils sont chiffrés, conservés pour la durée nécessaire et non joints à un ticket générique.

• contrat de données
• endpoint/version/reportName
• heure extraction/snapshot
• permissions
• nombre pages/jobs/lignes
• schéma reçu
• clés de jointure
• fraîcheur affichée

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : désactiver refresh
• Rollback : restaurer dataset/PBIX précédent
• Rollback : supprimer exports temporaires
• Rollback : révoquer permission non nécessaire
• Vigilance : exportJobs reste beta à revalider
• Vigilance : ne pas joindre par nom
• Vigilance : ne pas masquer Unknown
• Vigilance : ne pas utiliser Graph REST comme bulk sans analyse