Microsoft Graph : synchroniser avec delta queries et change notifications

L’essentiel

Delta query est un modèle pull : le client parcourt les pages initiales, conserve @odata.deltaLink puis demande uniquement les changements. Les suppressions apparaissent selon la ressource et doivent être appliquées au store local.

Change notifications est un modèle push via webhook, Event Hubs ou Event Grid. Une subscription a une durée, doit être renouvelée et peut produire des lifecycle notifications telles que reauthorizationRequired, subscriptionRemoved ou missed.

La notification n’est pas une transaction exactly-once. Je valide authenticité et clientState, réponds rapidement, déduplique, puis utilise delta pour rattraper tout manque.

Delta query est un modèle pull : le client parcourt les pages initiales, conserve @odata.deltaLink puis demande uniquement les changements. Les suppressions apparaissent selon la ressource et doivent être appliquées au store local.

Pourquoi cette technologie existe

Le premier appel delta retourne des pages et finalement un deltaLink opaque. Je suis nextLink puis stocke deltaLink avec la partition, la version de schéma et l’heure.

Un token delta peut expirer ou devenir invalide. Le client accepte alors un resync complet contrôlé plutôt que d’ignorer définitivement les changements.

Je commence par nommer le propriétaire de la décision, la population concernée et la preuve attendue. Cette étape paraît administrative, mais elle évite qu’un réglage technique soit utilisé pour compenser une responsabilité non définie entre identité, sécurité, support et gestion du poste.

La console cloud représente une intention et un état remonté. Je la compare toujours au résultat local, à l’identité réellement utilisée et à l’heure du dernier traitement. Une valeur verte, une affectation ou un HTTP 200 ne suffit pas à prouver tout le parcours.

Pour expliquer « Delta queries et notifications Graph », je commence par le besoin auquel la technologie répond, puis je sépare le plan de contrôle, le transport, les composants locaux, les états persistés et les données de résultat. Cette lecture évite d’attribuer au portail une décision prise par Windows ou à l’agent une limitation du service cloud.

Je distingue les interfaces supportées des détails internes observables. Les journaux, tâches et clés de registre aident à comprendre le fonctionnement, mais ils ne deviennent pas automatiquement des contrats stables sur lesquels bâtir une automatisation durable.

Enfin, je relie la théorie au cycle réel : déclenchement, traitement, résultat, nouvelle évaluation et comportement en cas de dérive. L’objectif est de comprendre ce qui se passe, pas seulement de reproduire une configuration.

Je qualifie la nature de chaque état : intention envoyée, valeur effective, inventaire, conformité, télémétrie ou simple cache d’affichage. Ces données n’ont ni la même fraîcheur ni la même autorité. Un résultat cohérent suppose de connaître qui produit l’information, à quel moment, dans quel contexte et selon quel mécanisme elle revient au service.

Je replace aussi la technologie dans son environnement. Les identités, certificats, licences, services réseau, versions clientes et autres outils de gestion peuvent modifier son comportement sans appartenir directement à son moteur. Cette frontière permet de distinguer une limitation intrinsèque d’une dépendance absente ou d’un conflit d’architecture.

Quand une observation terrain complète la documentation, je la présente comme un indice et non comme une garantie de support. Les noms de tâches, fichiers, événements ou rythmes internes peuvent changer. Je m’appuie sur eux pour expliquer et diagnostiquer, tandis que les décisions de conception reposent sur les interfaces et comportements officiellement documentés.

• À comprendre : comprendre l’architecture et ses limites
• À comprendre : mettre en œuvre un pilote observable
• À comprendre : construire une exploitation avec critères GO/NO-GO
• Périmètre étudié : Microsoft Graph, Delta query, Change notifications
• Périmètre étudié : postes Windows et services Microsoft documentés
• Périmètre étudié : pilote représentatif avant généralisation

Architecture, composants et flux de données

Le premier appel delta retourne des pages et finalement un deltaLink opaque. Je suis nextLink puis stocke deltaLink avec la partition, la version de schéma et l’heure.

Un token delta peut expirer ou devenir invalide. Le client accepte alors un resync complet contrôlé plutôt que d’ignorer définitivement les changements.

Une subscription définit resource, changeType, notificationUrl ou canal, expiration et éventuellement lifecycleNotificationUrl. Les durées maximales varient par ressource.

Prérequis, compatibilité et limites de support

Je sépare les prérequis nécessaires à l’existence de la fonction de ceux qui ne concernent qu’un scénario d’administration. La présence d’une option dans une console ne prouve ni la prise en charge de la version cliente, ni l’éligibilité de la licence.

Les builds, éditions, rôles, dépendances réseau et contextes d’exécution doivent être confirmés avant d’interpréter un comportement. Les éléments internes observés mais non documentés comme interfaces publiques sont explicitement traités comme tels.

• ressource supportant delta/notifications
• permissions minimales
• endpoint HTTPS public ou Event Hubs/Grid
• stockage chiffré des cursors
• queue et déduplication
• rotation clientState/credentials
• runbook resync

Cycle de fonctionnement, étape par étape

Cette séquence décrit ce que font les différents composants, depuis le déclenchement jusqu’au résultat. Elle sert de modèle mental : selon le scénario, certaines étapes peuvent être asynchrones ou exécutées dans un autre contexte.

Je distingue l’action demandée, son transport, son traitement local et son accusé de résultat. Cette distinction explique pourquoi deux écrans peuvent afficher temporairement des états différents sans qu’il y ait nécessairement une panne.

Fonctionnement détaillé et frontières de responsabilité

Le premier appel delta retourne des pages et finalement un deltaLink opaque. Je suis nextLink puis stocke deltaLink avec la partition, la version de schéma et l’heure.

Un token delta peut expirer ou devenir invalide. Le client accepte alors un resync complet contrôlé plutôt que d’ignorer définitivement les changements.

Une subscription définit resource, changeType, notificationUrl ou canal, expiration et éventuellement lifecycleNotificationUrl. Les durées maximales varient par ressource.

• ressource supportant delta/notifications
• permissions minimales
• endpoint HTTPS public ou Event Hubs/Grid
• stockage chiffré des cursors

Mise en œuvre, exploitation et cas limites

Le webhook répond au validationToken lors de la création puis vérifie clientState et jetons/signatures requis. Il accuse réception rapidement et traite ensuite dans une queue.

Les notifications peuvent être dupliquées, retardées ou manquées. L’idempotence utilise ressource, changeType, séquence/heure et état courant, jamais l’hypothèse exactly-once.

Lors de missed ou subscriptionRemoved, je renouvelle/récrée et lance un delta ou resync pour la fenêtre. Le monitoring alerte avant expiration et sur la profondeur de queue.

• Tester missed/subscriptionRemoved
• Renouveler avant expiration
• Comparer store à un full sync témoin

Méthode de validation à l’échelle du parc

Pour delta queries et notifications graph, je constitue un échantillon qui couvre au minimum deux modèles matériels, plusieurs profils utilisateur, un site réseau contraint et les exceptions métier connues. Un résultat homogène sur des machines de laboratoire identiques ne démontre pas la robustesse de la configuration.

Je mesure la couverture, le taux de succès, le délai de convergence, le nombre d’exceptions, les incidents et le temps de retour à l’état connu. Les seuils sont définis avant le pilote afin de ne pas les adapter après coup pour justifier une généralisation.

Les cas négatifs font partie de la recette : appareil hors ligne, identité non éligible, permission absente, version non supportée, conflit volontaire et rollback. Le système doit échouer de manière visible et sûre, sans exposer de secret ni créer une dérive silencieuse.

La généralisation suit des anneaux dont la composition reste stable pendant l’observation. Chaque vague dispose d’un propriétaire, d’une fenêtre, d’une consigne support et d’un point d’arrêt. Je n’ouvre la vague suivante qu’après la clôture des écarts de la précédente.

Interfaces d’observation, commandes et exemples

Les commandes illustrent les objets et états décrits dans l’article. Les exemples de diagnostic restent non testés, en niveau 1 et sans modification volontaire. Ils servent à comprendre les données disponibles, pas à industrialiser une collecte.

Une automatisation durable doit employer une API ou une interface officiellement supportée. Une clé de registre, un fichier ou une tâche interne peut évoluer avec Windows, l’agent ou le service.

# Exemple pédagogique non testé — niveau 1
$ErrorActionPreference = 'Stop'
try {
 $uri='https://graph.microsoft.com/v1.0/users/delta?$select=id,displayName,userPrincipalName'
 do {
   $page=Invoke-MgGraphRequest -Method GET -Uri $uri
   $page.value | Select-Object id,displayName,userPrincipalName
   $uri=$page.'@odata.nextLink'
   if(-not $uri){$deltaLink=$page.'@odata.deltaLink'}
 } while($uri)
 [pscustomobject]@{DeltaLinkReceived=[bool]$deltaLink}
}
catch { Write-Error "Delta Graph impossible : $($_.Exception.Message)"; exit 1 }

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

Le diagnostic de « Delta queries et notifications Graph » relie l’heure de la demande, l’identité, l’objet cloud, le poste et le résultat final. Je conserve les identifiants de corrélation utiles, mais je masque UPN, DeviceId, TenantId, noms internes, secrets, certificats privés et contenus métiers avant tout partage.

Je différencie absence de configuration, non-applicabilité, attente, erreur transitoire, refus d’autorisation et échec du composant local. Ces états n’appellent pas la même correction. Répéter une synchronisation ne transforme pas une politique non applicable en politique valide.

La collecte initiale reste en lecture seule. Une remédiation réelle doit être écrite au minimum au niveau 2, proposer une simulation, borner sa cible et restaurer l’état précédent. Pour une opération tenant-wide, privilégiée ou critique, les niveaux 3 ou 4 et une approbation formelle sont nécessaires.

• Effectuer sync delta initial.
• Conserver nextLink/deltaLink atomiquement.
• Créer subscription et valider endpoint.
• Tester duplicate et out-of-order.
• Tester missed/subscriptionRemoved
• Renouveler avant expiration
• Comparer store à un full sync témoin

Validation du modèle et cas d’usage

Je vérifie le modèle sur un appareil représentatif en reliant la configuration du service, l’état reçu, le traitement local et la donnée remontée. L’objectif n’est pas de certifier la production, mais de confirmer que l’explication décrit bien le comportement observé.

Un cas d’usage est retenu lorsque la technologie répond au besoin sans ajouter une autorité concurrente, une dépendance non maîtrisée ou un niveau d’opacité incompatible avec l’exploitation.

• Effectuer sync delta initial.
• Conserver nextLink/deltaLink atomiquement.
• Créer subscription et valider endpoint.
• Tester duplicate et out-of-order.
• Tester missed/subscriptionRemoved
• Renouveler avant expiration
• Comparer store à un full sync témoin

Limites, modes de panne et lecture des erreurs

Cette matrice relie les limites du modèle aux symptômes observables. Elle ne transforme pas une technologie en article de dépannage : elle montre où le fonctionnement normal peut diverger et quelles preuves permettent de comprendre cette divergence.

Une erreur isolée doit être replacée dans sa phase et son contexte. Je privilégie les résultats documentés du service et du client avant les détails d’implémentation susceptibles de changer.

Adoption progressive, réversibilité et vigilance

Pour introduire la technologie, je commence par un scénario borné, des appareils pilotes et des critères d’observation définis. L’adoption progresse uniquement si les dépendances, la supervision et les responsabilités de support sont comprises.

Le retour arrière dépend souvent de la propriété de la ressource et du cycle de synchronisation. Je le teste avant généralisation et je ne déduis jamais la réversibilité de la seule disparition d’un profil dans le portail.

• Réversibilité : désactiver consumer
• Réversibilité : supprimer subscription
• Réversibilité : restaurer dernier snapshot du store
• Réversibilité : relancer full sync sans écraser avant validation
• Limite ou vigilance : deltaLink est opaque et sensible
• Limite ou vigilance : durées varient par ressource
• Limite ou vigilance : ne pas traiter lourdement dans webhook
• Limite ou vigilance : beta uniquement avec dérogation