Microsoft AZ-204: Solutions basées sur les événements et la messagerie Azure — Guide d'étude

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Developer Associate AZ-204 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Le portefeuille de services d’événements et de messagerie d’Azure couvre quatre services complémentaires : Event Grid pour la gestion réactive des événements, Event Hubs pour l’ingestion de flux à haut débit, Service Bus pour la messagerie d’entreprise et la coordination de workflows, et Notification Hubs pour les notifications push mobiles. La maîtrise de ces services exige de connaître les abstractions de base de chacun, leurs sémantiques de livraison et de nouvelle tentative, leurs modèles de mise à l’échelle, et de savoir quand en préférer un par rapport à un autre dans des schémas applicatifs typiques tels que le pub/sub, le traitement des commandes, l’ingestion de télémétrie et les notifications aux appareils ou aux utilisateurs.

Event Grid : Rubriques, Abonnements, Schéma, Filtrage et Mise en file de lettres mortes

Event Grid est une fabric pub/sub entièrement gérée, basée sur un modèle push, pour les événements discrets. Les éditeurs (publishers) envoient des événements à une rubrique (topic) ; les abonnés (subscribers) enregistrent des abonnements d’événements sur une rubrique et reçoivent les événements correspondants sur des gestionnaires (handlers) pris en charge tels que les webhooks HTTPS, Azure Functions, Logic Apps, Service Bus, Storage Queues et Event Hubs. Event Grid définit deux modèles d’éditeurs. Les rubriques système sont des ressources de rubrique gérées par Azure qui représentent des services Azure de première partie publiant des événements au sein de votre abonnement ou groupe de ressources (par exemple, la création d’un blob dans Storage, la rotation d’un secret Key Vault ou des événements Resource Manager). Les rubriques personnalisées sont des points de terminaison de rubrique créés par l’utilisateur vers lesquels vos applications publient, permettant des modèles événementiels à travers vos propres services et domaines. Les rubriques système ne nécessitent aucun code côté éditeur et simplifient la connexion des ressources Azure à des gestionnaires réactifs ; les rubriques personnalisées vous donnent un contrôle total sur les contrats et le cycle de vie des événements.

Les événements Event Grid peuvent utiliser le schéma natif Event Grid ou la spécification CloudEvents v1.0. Avec le schéma Event Grid, chaque événement inclut id (identifiant unique), eventType (l’action), subject (chemin hiérarchique qui prend en charge le filtrage), eventTime (UTC), data (charge utile), dataVersion, metadataVersion et topic. CloudEvents fournit un ensemble d’attributs standardisé tel que id, source, type, time, subject et data. Choisir CloudEvents facilite l’interopérabilité entre les plateformes ; le schéma Event Grid maintient la parité avec les événements provenant d’Azure et permet un filtrage riche sur le subject.

Les abonnements d’événements définissent le routage, les options de livraison et les filtres. Les filtres de base incluent l’inclusion par type d’événement et le préfixe/suffixe du sujet (subjectBeginsWith, subjectEndsWith), qui sont efficaces pour les noms de ressources hiérarchiques. Les filtres avancés effectuent une correspondance sur les champs de l’événement de niveau supérieur ou dans les données (par exemple, comparaisons de plages numériques, contenance de chaîne insensible à la casse, égalité booléenne et contenance de tableau). Vous pouvez combiner des filtres pour un contrôle précis de la distribution (fan-out), minimisant ainsi le travail en aval et la sortie de données (egress).

La livraison est de type push avec une sémantique “au moins une fois” (at-least-once). Event Grid effectue des nouvelles tentatives avec un backoff exponentiel. Vous pouvez configurer le nombre maximal de tentatives et la durée de vie de l’événement (time-to-live) ; lorsque la livraison échoue définitivement ou que l’événement expire, Event Grid peut placer l’événement dans une file de lettres mortes (dead-letter) dans un conteneur Blob Storage que vous désignez sur l’abonnement. La mise en file de lettres mortes préserve les charges utiles et les métadonnées pour l’audit ou le retraitement ; utilisez un processus distinct pour réhydrater et rejouer les événements si nécessaire. Les points de terminaison Webhook participent à une poignée de main (handshake) de validation pour prouver leur propriété, et pour les réseaux contraints, vous pouvez préférer des points de terminaison Azure gérés (Functions, Service Bus, Storage Queue) qui n’ont pas besoin d’être exposés publiquement et peuvent utiliser une autorisation basée sur Azure AD.

Event Hubs : Partitions, Groupes de consommateurs, Débit, Capture et Consommation fiable

Event Hubs ingère des flux de télémétrie et de journaux à haut volume avec une faible latence. Les données sont ajoutées à des partitions, qui sont des journaux de commit (commit logs) indépendants et ordonnés. Les partitions sont choisies au moment de la création pour paralléliser le débit ; les producteurs attribuent une clé de partition pour préserver l’ordre par clé, et le service distribue les clés dans les partitions par hachage. Plusieurs lecteurs peuvent traiter les partitions en parallèle ; au sein d’une partition, l’ordre est garanti.

Les groupes de consommateurs fournissent des vues indépendantes du flux, permettant à différentes applications de traitement de maintenir leurs propres positions sans interférer les unes avec les autres (par exemple, un détecteur d’anomalies en temps réel et un pipeline d’archivage). La mise à l’échelle horizontale des lecteurs nécessite l’équilibrage de la possession des partitions ; l’EventProcessorClient du SDK coordonne l’attribution et le rééquilibrage des partitions entre les instances.

Les unités de débit (Throughput Units ou TU) du niveau Standard définissent la capacité : chaque TU donne droit à des quotas de bande passante en entrée (ingress) et en sortie (egress). La fonctionnalité Auto-inflate peut augmenter automatiquement le nombre de TU pour répondre aux pics de charge. Le niveau Premium utilise des unités de traitement (Processing Units) avec un calcul dédié et une latence prévisible. Surveillez les métriques de limitation (throttling) pour valider le provisionnement. Event Hubs prend en charge le protocole Kafka sur le même point de terminaison, simplifiant la migration « lift-and-shift » des clients Kafka sans avoir à gérer de brokers.

Les producteurs peuvent utiliser AMQP ou HTTPS. AMQP (y compris AMQP-over-WebSockets sur le port 443) fournit des connexions multiplexées et persistantes ainsi qu’un traitement par lots efficace, et est recommandé à la fois pour l’envoi et la réception. HTTPS convient pour des envois simples ou sporadiques mais n’est pas pris en charge pour la réception ; le long-polling n’est pas disponible, et vous sacrifiez l’efficacité et le contrôle de flux. Dans les réseaux d’entreprise restreints, AMQP-over-WebSockets préserve les performances tout en passant par les proxys sortants habituels.

La gestion des points de contrôle (checkpointing) et des décalages (offsets) est essentielle pour la justesse du traitement. Chaque événement possède un numéro de séquence et un décalage (offset) par partition. Les récepteurs progressent dans le flux et, après avoir traité un lot avec succès, ils enregistrent leur position via un point de contrôle dans un stockage durable — généralement un conteneur Azure Blob Storage via l’EventProcessorClient. En cas de redémarrage ou de basculement (failover), le processeur reprend à partir du dernier point de contrôle, réalisant un traitement « au moins une fois » (at-least-once) avec des gestionnaires idempotents. Sans points de contrôle, les consommateurs démarrent à partir d’une position par défaut (la plus récente ou la plus ancienne) et risquent de retraiter ou d’ignorer des événements.

La fonctionnalité Capture assure un archivage côté serveur en écrivant automatiquement des fichiers Avro par lots et en ajout seul (append-only) dans Azure Blob Storage ou Azure Data Lake Storage Gen2, selon une fenêtre temporelle ou de taille configurable. Cela élimine le besoin de créer des processus de traitement par lots personnalisés pour l’analytique sur le chemin froid (cold-path), permettant aux outils en aval (Spark, Synapse) de consommer des segments de flux immuables avec une sémantique « exactement une fois » (exactly-once) par rapport au pipeline de capture.

Service Bus et Queue Storage : Commandes, Workflows, Sessions et Gestion des Messages Empoisonnés

Service Bus est un broker de messages de classe entreprise pour les commandes, les workflows et les scénarios d’intégration qui nécessitent des garanties de remise riches. Les files d’attente (Queues) implémentent une messagerie point à point ; un consommateur concurrent reçoit chaque message. Les rubriques (Topics) avec abonnements permettent le modèle pub/sub : les éditeurs envoient à une rubrique, et des abonnements indépendants reçoivent des copies basées sur des règles. Les règles d’abonnement peuvent être des filtres SQL, des filtres de corrélation ou des filtres booléens vrais qui calculent l’inclusion par message et peuvent ajouter ou modifier les propriétés du message via des actions.

Les sessions fournissent un traitement ordonné et exclusif pour les messages associés. Attribuez un SessionId aux messages qui vont ensemble (par exemple, toutes les étapes de la Commande 123). Un récepteur accepte le verrou de session et traite les messages dans leur ordre d’arrivée pour cette session, en maintenant un état de session optionnel, puis libère la session pour permettre au consommateur suivant d’en prendre possession. C’est le modèle privilégié pour le FIFO à grande échelle. Sans sessions, l’ordre n’est pas garanti entre les consommateurs concurrents.

Service Bus prend en charge les modes PeekLock et ReceiveAndDelete. PeekLock est le mode par défaut pour la fiabilité : un consommateur verrouille un message pour la durée du verrouillage, le traite, puis le finalise avec Complete. Si le traitement échoue, le consommateur peut utiliser Abandon (le rendant à nouveau disponible), Defer (reporter sa récupération ultérieure par numéro de séquence), ou Dead-letter (le déplacer vers la sous-file d’attente de lettres mortes de l’entité avec un motif et une description de l’erreur). ReceiveAndDelete sacrifie la fiabilité au profit du débit en supprimant le message immédiatement après sa réception.

Des propriétés clés contrôlent le cycle de vie. La durée de vie (Time to Live, TTL) peut être définie par défaut au niveau de l’entité et remplacée par message ; les messages expirés sont placés dans la file d’attente de lettres mortes ou supprimés selon la configuration. La durée de verrouillage contrôle combien de temps un message reste verrouillé pour le traitement ; le SDK peut renouveler automatiquement les verrous pour les tâches longues dans les limites maximales. Le nombre maximal de remises est configuré par file d’attente ou abonnement ; après ce nombre de tentatives de remise (Abandon ou perte de verrou), le message est automatiquement déplacé vers la file d’attente de lettres mortes (DLQ). Les opérateurs vident la DLQ pour des diagnostics ou pour un retraitement avec une logique corrective.

Azure Queue Storage est un service de file d’attente plus simple, massivement évolutif, avec une interface REST, idéal pour le découplage de base, le fan-out élevé et les charges de travail sensibles aux coûts. Il fournit une remise « au moins une fois », un délai de visibilité pour masquer les messages pendant le traitement, et une TTL par message (par défaut 7 jours, configurable, y compris pour ne jamais expirer). La taille des messages individuels est limitée, et des fonctionnalités telles que les sessions, les transactions, les garanties d’ordre, la détection des doublons, les sous-files d’attente de lettres mortes et les filtres avancés ne sont pas disponibles. Choisissez Queue Storage pour des tâches d’arrière-plan simples et un très haut débit à faible coût. Choisissez Service Bus lorsque vous avez besoin d’un routage sophistiqué (rubriques/abonnements), du FIFO via les sessions, de la remise planifiée, du report, de transactions entre entités, de fenêtres de détection des doublons, de la prise en charge d’AMQP, ou lorsque la fiabilité et la gouvernance de l’intégration sont importantes. Un modèle courant consiste à centraliser (fan-in) des événements légers via Event Grid ou Queue Storage et à coordonner les commandes critiques pour l’entreprise et les transitions d’état sur Service Bus.

Notification Hubs : Routage Push et Gestion des Identifiants de Plateforme

Notification Hubs est un moteur de notifications push multiplateforme qui gère les enregistrements d’appareils à grande échelle et route des notifications ciblées vers Apple (APNs), Android (FCM), Windows (WNS) et d’autres plateformes. Les applications enregistrent les appareils en utilisant des balises et des expressions de balises, permettant une sélection d’audience précise (par exemple, user:42 AND region:emea OR topic:promotions). Les modèles (templates) vous permettent d’envoyer une seule charge utile (payload) localisée que les moteurs de rendu spécifiques à la plateforme développent, réduisant ainsi la logique serveur et permettant une personnalisation par appareil avec un minimum de ramifications dans le backend. Le modèle d’Installation simplifie la gestion du cycle de vie des appareils en encapsulant le handle de la plateforme, les balises et les modèles dans une ressource unique par appareil.

La gestion des identifiants de plateforme est essentielle pour une livraison fiable. Pour APNs, téléchargez des identifiants basés sur des certificats ou des jetons (avec Key ID, Team ID et jeton .p8) et choisissez des points de terminaison de bac à sable (sandbox) ou de production par hub ou par espace de noms pour séparer les environnements. Pour FCM, configurez les identifiants de serveur appropriés (pour HTTP v1, utilisez un compte de service Google avec des étendues OAuth2). Pour WNS, enregistrez l’application pour obtenir le Package SID et le secret client. Les identifiants sont renouvelés périodiquement ; planifiez le renouvellement et surveillez les canaux de retour (feedback) pour les handles d’appareil non valides. Notification Hubs utilise des SAS (signatures d’accès partagé) pour l’authentification au niveau du hub depuis votre serveur d’application, tandis que les rôles Azure AD protègent les opérations de gestion. Utilisez des conventions de balisage pour partitionner les applications multi-locataires et limitez les envois avec des notifications push planifiées ou par lots pour respecter les quotas de la plateforme.

Scénario de Problème Pratique

Starbucks déploie une expérience de commande mobile mondiale qui doit notifier les clients lorsque les commandes sont prêtes, traiter de manière fiable les étapes du flux de travail des baristas et analyser la télémétrie des équipements pour une maintenance proactive.

1. Connecter le cycle de vie des commandes piloté par les événements avec Event Grid

• Créez une rubrique Event Grid personnalisée OrderEvents et publiez des événements de domaine discrets tels que OrderPlaced, PaymentAuthorized et OrderReady. Utilisez des chemins de sujet comme /stores/{storeId}/orders/{orderId} pour permettre le filtrage par préfixe par magasin. Configurez des abonnements : un vers une rubrique Service Bus pour le traitement du flux de travail et un vers une Azure Function pour un enrichissement léger. Event Grid est choisi pour sa diffusion (fan-out) à faible latence, sa normalisation de schéma (CloudEvents) et son filtrage efficace qui évite les invocations en aval inutiles.

2. Coordonner le flux de travail des baristas avec les rubriques et sessions Service Bus

• Définissez une rubrique Service Bus Orders avec des abonnements par étape de traitement (Preparation, Handoff), chacun avec des filtres de corrélation ou SQL sur eventType. Publiez les commandes sous forme de messages avec SessionId = {orderId} pour garantir un traitement FIFO par commande. Les consommateurs utilisent PeekLock avec renouvellement automatique du verrouillage et Complete en cas de succès ; en cas d’échec transitoire, Abandon déclenche une nouvelle tentative ; en cas d’échec persistant ou de messages empoisonnés, le nombre maximal de livraisons (Max delivery count) les déplace vers la file d’attente de lettres mortes (DLQ) pour une inspection ultérieure. Un TTL sur les messages spécifiques à une étape empêche le travail obsolète après la fermeture du magasin. Service Bus est choisi pour la gestion de commandes ordonnée et fiable, ses mécanismes de règlement avancés et son modèle de publication/abonnement basé sur des règles.

3. Ingérer et archiver la télémétrie des équipements avec Event Hubs

• Provisionnez un Event Hub Telemetry avec suffisamment de partitions pour paralléliser par deviceId et activez l’augmentation automatique des unités de débit (auto-inflate TUs) pour absorber les pics. Les passerelles des appareils envoient les données via AMQP-over-WebSockets pour traverser efficacement les proxys d’entreprise. Utilisez le EventProcessorClient avec la création de points de contrôle (checkpointing) sur Blob Storage pour exécuter la détection d’anomalies et les alertes en temps quasi réel. Activez la fonction Capture vers ADLS Gen2 pour des archives Avro immuables prenant en charge les analyses hors ligne dans Synapse. Event Hubs est choisi pour son ingestion soutenue à haut débit avec des décalages (offsets) durables et une exportation facile vers le chemin froid (cold-path).

4. Cibler les notifications push avec Notification Hubs

• Enregistrez les appareils mobiles en utilisant le modèle d’Installation, en balisant chacun avec user:{userId}, store:{storeId}, et des balises de plateforme. Téléchargez les identifiants de jeton APNs pour iOS et le compte de service FCM pour Android ; séparez les hubs de développement et de production pour isoler les identifiants et les retours. Lorsque les événements OrderReady arrivent, l’Azure Function envoie une seule notification de modèle à Notification Hubs adressée aux balises user:{userId} AND store:{storeId}. Notification Hubs est choisi pour son routage agnostique de la plateforme, ses expressions de balises et sa gestion centralisée des identifiants à l’échelle mondiale.

5. Assurer l’observabilité et la résilience

• Configurez la mise en file d’attente de lettres mortes (dead-lettering) d’Event Grid vers un conteneur Blob pour conserver les événements non livrables pour l’audit et la relecture. Surveillez les DLQ de Service Bus et exposez un flux de travail pour les opérateurs afin de trier et de remettre en file d’attente les messages corrigés. Suivez le retard des consommateurs (consumer lag) d’Event Hubs via les métriques pour valider la création de points de contrôle et augmenter le nombre de processeurs (scale out) lorsque le backlog augmente. Cette combinaison offre une durabilité de bout en bout : une livraison au moins une fois (at-least-once) avec des chemins de relecture pour les conditions exceptionnelles, tout en gardant le chemin nominal (happy path) rapide et rentable.

Cette architecture sépare nettement les responsabilités : Event Grid pilote l’orchestration réactive, Service Bus garantit la correction et l’ordonnancement du flux de travail, Event Hubs gère la télémétrie continue à grande échelle, et Notification Hubs délivre des notifications client précises et spécifiques à la plateforme avec une complexité minimale du backend.

← Gestion des API Azure · Tous les domaines · Mise en cache →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →