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

Position recommandée

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.

Besoin, cas d’usage et périmètre de la recommandation

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.

Critères de décision et options possibles

Pour Graph, Reports API ou Data Warehouse, je commence par trois résultats concrets: comparer les trois plans de données, sélectionner la source par cas d’usage et construire des contrôles de qualité et de fraîcheur. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Operational → Report → Warehouse → Semantic. Chaque composant a un propriétaire clair, un état vérifiable et une méthode de retour arrière; cette répartition évite qu’une seconde politique masque le résultat de la première.

Le pilote contrôle notamment source adaptée au cas, pagination/job complet et fraîcheur affichée. La généralisation ne commence qu’après une période stable et après vérification des exceptions propres aux populations visées.

La recommandation devient mesurable lorsqu’elle relie le besoin à une cible vérifiable. Les résultats attendus sont comparer les trois plans de données, sélectionner la source par cas d’usage et construire des contrôles de qualité et de fraîcheur. Les responsabilités se répartissent ainsi: Operational: Graph resources pour état/action. Report: exportJobs produit un fichier de rapport. Warehouse: OData consolide un modèle analytique. Semantic: Power BI documente clés, mesures et fraîcheur. Cette répartition permet d’attribuer chaque écart au bon propriétaire et d’éviter qu’un second profil, une ancienne autorité ou une exception silencieuse ne produise un résultat apparemment correct mais impossible à exploiter dans la durée.

Les écarts « Chiffres différents », « Export reste inProgress », « CSV colonnes manquantes » et « Warehouse relations vides » servent de tests de décision. Pour chacun, la preuve indiquée dans la matrice doit permettre de choisir entre correction, exception temporaire et retour arrière. Le pilote surveille également les points suivants: exportJobs reste beta à revalider, ne pas joindre par nom, ne pas masquer Unknown et ne pas utiliser Graph REST comme bulk sans analyse. La valeur cible, le mode de distribution, les contrôles et la sortie de secours sont ainsi évalués ensemble.

Architecture cible et répartition des responsabilités

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, gouvernance et préparation

La préparation de Graph, Reports API ou Data Warehouse couvre question métier et niveau de fraîcheur, catalogue local data/Graph consulté, permissions minimales, volumes estimés, clés et relations documentées. Le propriétaire de chaque composant et la population pilote sont définis avant la création de la configuration.

L’état initial est mesuré avec contrat de données, endpoint/version/reportName, heure extraction/snapshot, permissions. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• 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

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.

Configuration recommandée et déploiement par étapes

La méthode retenue pour Graph, Reports API ou Data Warehouse se déploie par les étapes « Définir le contrat », « Comparer un échantillon », « Construire le pipeline », « Publier avec transparence ». Chaque passage produit un résultat vérifiable avant l’ouverture du suivant.

Paramètres, commandes et automatisation

Les commandes et valeurs de cette section servent à vérifier contrat de données, endpoint/version/reportName, heure extraction/snapshot, permissions. Chaque exemple précise l’état attendu et les éléments à comparer dans le service.

Le contexte d’exécution, les permissions et les effets sur Operational, Report, Warehouse, Semantic doivent rester explicites lorsque la configuration est automatisée.

# Collecte de diagnostic
$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, indicateurs et critères GO / NO-GO

La décision repose sur source adaptée au cas, pagination/job complet, fraîcheur affichée et schéma contrôlé. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

• 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

Exploitation, journaux et contrôle continu

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

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour Graph, Reports API ou Data Warehouse apparaissent notamment sous la forme Chiffres différents, Export reste inProgress, CSV colonnes manquantes, Warehouse relations vides. La preuve associée indique s’il faut corriger la configuration ou conserver une exception documentée.

Coût de maintien des exceptions

Une exception à Graph, Reports API ou Data Warehouse crée une charge récurrente: elle doit être identifiée, surveillée et réévaluée jusqu’à sa suppression. Sans propriétaire ni date de revue, cette charge finit par devenir une configuration parallèle difficile à tester.

Rollback, gestion du changement et points de vigilance

Le rollback de Graph, Reports API ou Data Warehouse restaure explicitement l’affectation, la valeur ou l’autorité précédente. Les actions et points de vigilance ci-dessous précisent ce qui doit être contrôlé après ce retour.