Ce guide explique comment déployer et utiliser Azure Update Manager pour automatiser la gestion des patchs de vos machines virtuelles Windows et Linux sur Azure. Il s'adresse aux administrateurs infrastructure et équipes DevOps qui veulent remplacer Windows Update for Business ou WSUS par une solution cloud-native centralisée, auditée et compatible multi-OS.

Azure Update Manager est le service natif Microsoft pour planifier, déployer et auditer les mises à jour de sécurité sur les VMs Azure, les serveurs hybrides (Azure Arc) et les machines on-premise connectées — sans déployer de serveur WSUS ni d'agent SCCM. En 2026, 78 % des vulnérabilités exploitées en production concernent des patchs disponibles depuis plus de 30 jours selon le rapport CISA KEV : la fenêtre de remédiation se réduit, et les outils de gestion manuelle de patchs ne suffisent plus. Ce guide détaille l'architecture d'Azure Update Manager, la configuration des maintenance windows, la création de politiques de mise à jour centralisées, l'intégration avec Microsoft Defender for Cloud, et la génération de rapports d'audit conformité.

À retenir

  • Remplacement natif de WSUS : Azure Update Manager gère les patchs Windows et Linux directement depuis le portail Azure ou via API — aucun serveur WSUS à déployer, maintenir ou mettre à jour.
  • Support Linux complet : Ubuntu, Red Hat Enterprise Linux, CentOS, SUSE, Debian et Oracle Linux sont supportés — la gestion des patchs est unifiée pour les flottes hétérogènes.
  • Maintenance Windows précises : définissez des fenêtres de maintenance par groupe de VMs avec durée, récurrence, et classification de patchs (Security, Critical, UpdateRollup) — sans toucher les heures de production.
  • Intégration Azure Policy : assignez des politiques de mise à jour à l'échelle d'un abonnement ou d'un groupe de ressources — chaque nouvelle VM hérite automatiquement de la politique.
  • Audit et conformité : Azure Update Manager génère des rapports de conformité de patching intégrés à Azure Policy Compliance et exportables vers Log Analytics pour rétention longue durée.

Qu'est-ce qu'Azure Update Manager et pourquoi l'adopter en 2026 ?

Azure Update Manager est le successeur d'Azure Automation Update Management (déprécié en 2024) et la solution de gestion de patchs native Azure. Contrairement à son prédécesseur qui nécessitait un compte Azure Automation et un espace de travail Log Analytics dédiés, Update Manager est un service standalone intégré directement dans Azure Resource Manager — configuration plus simple, coût réduit, et intégration native avec Azure Policy et Microsoft Defender for Cloud.

Le service gère trois types de ressources : les VMs Azure (Windows et Linux), les serveurs hybrides enregistrés via Azure Arc (serveurs physiques ou virtuels on-premise ou chez d'autres cloud providers), et les Scale Sets (VMSS). Cette unification est particulièrement précieuse pour les organisations en mode hybride — une seule console pour patcher 200 VMs Azure et 50 serveurs physiques datacentre.

Fonctionnalité Azure Update Manager WSUS classique Azure Automation (ancien)
Infrastructure à déployer Aucune Serveur WSUS dédié Compte Automation + Log Analytics
Support Linux Oui (natif) Non Oui (agent)
Serveurs hybrides (Arc) Oui Non Oui (avec agent OMS)
Azure Policy intégration Native Non Partielle
Rapports conformité Azure Policy Compliance WSUS Reports Log Analytics
Coût Gratuit pour VMs Azure Licences Windows Server Frais Automation + Log Analytics

Prérequis et activation d'Azure Update Manager

Azure Update Manager ne nécessite pas de déploiement d'infrastructure spécifique pour les VMs Azure. Les prérequis sont minimes : l'extension VM Azure Guest Agent doit être installée et active sur chaque VM (c'est le cas par défaut pour toutes les VMs créées depuis le portail Azure depuis 2020), et la VM doit avoir un accès Internet sortant ou un accès aux endpoints Microsoft Update via un point de terminaison privé Azure.

Pour les VMs Windows, Azure Update Manager communique directement avec Windows Update Service sur la VM. Pour Linux, il utilise le gestionnaire de paquets natif de la distribution (apt pour Ubuntu/Debian, yum/dnf pour RHEL/CentOS/Oracle Linux, zypper pour SUSE). Aucun agent supplémentaire à installer sur les VMs Azure — c'est une différence majeure avec les solutions tierces (Chef, Ansible, Puppet) qui nécessitent un agent sur chaque machine.

Pour les serveurs hybrides (on-premise ou multi-cloud), installez l'agent Azure Connected Machine (Azure Arc) qui enregistre le serveur dans Azure Resource Manager. Une fois Arc actif, le serveur apparaît dans Azure Update Manager exactement comme une VM Azure native. La documentation officielle Microsoft Azure Update Manager détaille les prérequis réseau complets selon le type de VM.

Configurer une maintenance window : bonnes pratiques

Les Maintenance Configurations (ex-Maintenance Windows) définissent quand les patchs sont installés et sur quelles machines. Elles sont configurables dans le portail Azure (Update Manager → Maintenance Configurations → Create) ou via Bicep/ARM/Terraform.

Paramètres clés d'une maintenance configuration bien pensée :

Durée : prévoyez au moins 2h pour les patchs Windows (les KB de sécurité incluent souvent des composants qui nécessitent plusieurs redémarrages successifs) et 30 à 60 min pour Linux. Une durée trop courte interrompt l'installation en cours et laisse la VM dans un état partiel — le statut Azure Update Manager affiche alors "Failed" avec un message de timeout.

Récurrence : mensuelle pour les environnements de production (alignée sur le Patch Tuesday Microsoft), hebdomadaire pour les environnements de développement et de staging, à la demande pour les patchs d'urgence (0-day actifs). Évitez les récurrences quotidiennes sur les machines de production — les redémarrages fréquents non planifiés perturbent les équipes applicatives.

Classification des patchs : limitez aux classifications "Security" et "Critical" en production pour réduire le risque d'instabilité. Les patchs de type "Feature Pack" ou "Service Pack" doivent être testés en staging avant production. Sur Linux, limitez aux patchs de type Security via le filtrage de classification disponible depuis Update Manager 2025.

Pre/Post scripts : Azure Update Manager supporte l'exécution de scripts avant et après les patchs. Utilisez-les pour notifier une solution de monitoring (Datadog, Dynatrace) de la fenêtre de maintenance, ou pour activer/désactiver des équilibreurs de charge qui retirent temporairement la VM du pool de load balancing avant redémarrage.

Comment déployer des patchs d'urgence hors maintenance window ?

Les 0-day actifs (comme Log4Shell, PrintNightmare ou les vulnérabilités Exchange exploitées massivement) exigent un patching d'urgence sans attendre la prochaine maintenance window. Azure Update Manager propose deux mécanismes pour les patchs hors cycle :

One-time update : depuis le portail Azure ou via la commande CLI az maintenance assignment create --resource-type Microsoft.Compute/virtualMachines, déclenchez une installation de patchs immédiate sur une VM ou un groupe de VMs. L'opération est journalisée dans l'Activity Log Azure avec l'identité de l'initiateur — piste d'audit complète pour la conformité.

Hotpatch (Windows Server 2022 Datacenter Azure Edition) : Microsoft propose le Hotpatching pour certaines versions de Windows Server — les patchs de sécurité s'installent sans redémarrage toutes les 2 mois sur 3. Cette fonctionnalité réduit drastiquement le nombre de redémarrages annuels (de 12 à 4) pour les VMs Windows Server 2022 Azure Edition. Elle est disponible directement dans Azure Update Manager via la configuration "Hotpatch".

Retour terrain : Lors de la publication de CVE-2025-21334 (vulnérabilité RCE critique Windows Server Hyper-V, CVSS 9.8, exploitée activement selon CISA KEV), un client avec 180 VMs Azure a pu déclencher le patching d'urgence sur toutes les VMs via Azure Update Manager en moins de 45 minutes. Sans Update Manager, la même opération via GPO et WSUS aurait pris 6 à 8 heures et nécessité l'intervention manuelle des administrateurs. La centralisation Azure a réduit la fenêtre d'exposition de 8h à 45 min.

Intégration avec Azure Policy pour l'enforcement à l'échelle

Azure Policy permet d'assigner des politiques de configuration à l'échelle d'un abonnement, d'un groupe de gestion, ou d'un groupe de ressources. En combinaison avec Azure Update Manager, cela signifie que chaque nouvelle VM créée dans le périmètre hérite automatiquement de la politique de mise à jour — sans action manuelle de l'administrateur.

La policy intégrée "Configure periodic checking for missing system updates on azure virtual machines" (ID : 59efceea-0c96-497e-a4a1-4eb2290d7f10) active automatiquement l'évaluation périodique des patchs manquants toutes les 24h sur les nouvelles VMs. Assignez-la au niveau du groupe de gestion racine pour couvrir tous les abonnements de votre tenant.

Les effets de conformité Azure Policy s'affichent dans le tableau de bord Compliance : une VM sans maintenance configuration ou avec des patchs critiques manquants apparaît "Non-Compliant". Ce tableau est exportable via Log Analytics pour les rapports d'audit mensuels exigés par les certifications ISO 27001, NIS 2 ou PCI DSS. Notre service RSSI externalisé intègre ce reporting dans les KPIs de sécurité opérationnelle mensuels.

Intégration avec Microsoft Defender for Cloud

Microsoft Defender for Cloud (anciennement Azure Security Center) s'intègre nativement avec Azure Update Manager pour les recommandations de sécurité. Dans l'onglet Recommendations de Defender for Cloud, la recommandation "Machines should have vulnerability findings resolved" liste les VMs avec des patchs de sécurité critiques ou élevés non installés depuis plus de 30 jours.

Cette intégration permet de prioriser les patchs selon le score CVSS et la présence de la vulnérabilité dans le catalogue CISA KEV (Known Exploited Vulnerabilities) : une CVE avec CVSS 9.8 et présente dans KEV est signalée en rouge avec la recommandation d'appliquer le patch dans les 24h — conformément aux directives CISA SSVC. La base CISA KEV est un référentiel incontournable pour prioriser les patchs critiques en 2026.

Defender for Cloud transmet également les alertes de patching dans les tickets Azure Monitor Action Groups — configurez un Action Group qui envoie une notification Slack ou Teams quand une VM critique reste non patchée au-delà du SLA défini (ex. 72h pour les CVE CVSS >= 9.0 exploitées activement).

Gestion des mises à jour Linux : apt, yum et zypper

La gestion des patchs Linux via Azure Update Manager est fonctionnellement équivalente à celle de Windows, mais avec quelques spécificités à connaître. Pour Ubuntu et Debian, Update Manager utilise apt-get en arrière-plan. Pour RHEL, CentOS et Oracle Linux, il utilise yum ou dnf selon la version. Pour SUSE, il utilise zypper.

La classification des patchs Linux correspond aux niveaux de priorité des dépôts de distribution : Security (patchs de sécurité officiels du mainteneur), Critical (patchs critiques hors cycle normal), Other (mises à jour fonctionnelles et features). En production, limitez aux classifications Security pour minimiser les risques de régressions liées aux mises à jour fonctionnelles non testées.

Attention aux VMs Linux avec des noyaux compilés custom ou des modules kernel tiers (pilotes NVidia, solutions de stockage SAN) : les mises à jour de noyau peuvent invalider ces modules et rendre la VM non-bootable. Testez systématiquement les mises à jour de noyau en staging avant production, et configurez les maintenance windows Linux pour exclure les paquets de noyau (kernel*) sur les VMs avec des dépendances custom.

Rapports de conformité et audit de patching

Azure Update Manager génère des rapports de conformité de patching accessibles via le portail Azure (Update Manager → Reports), via Log Analytics, et via l'API REST Azure Resource Graph. Chaque VM affiche son statut de patch (Compliant, Non-Compliant, Pending Reboot, Assessment Not Run) et le détail des patchs manquants avec leur classification et leur date de disponibilité.

Pour une rétention des rapports supérieure à 90 jours (exigée par PCI DSS et ISO 27001), configurez l'export des données Update Manager vers un espace de travail Log Analytics. La table PatchAssessmentResources dans Log Analytics contient l'historique complet des évaluations et des déploiements de patchs. Des requêtes KQL pré-construites permettent de générer des rapports mensuels de conformité formatés pour les audits.

Exemple de requête KQL pour identifier les VMs avec des patchs critiques manquants depuis plus de 30 jours :

PatchAssessmentResources
| where type == "microsoft.compute/virtualmachines/patchassessmentresults/softwarepatches"
| where properties.patchClassification in ("Critical", "Security")
| where properties.publishedDate < ago(30d)
| where properties.rebootBehavior != "NeverReboots"
| summarize count() by tostring(properties.vmId)
| where count_ > 0

Automatisation avec Bicep, Terraform et Azure CLI

La configuration d'Azure Update Manager est entièrement automatisable via l'API Azure Resource Manager. Pour les équipes pratiquant l'Infrastructure as Code, Bicep et Terraform disposent de ressources dédiées :

En Bicep, la ressource Microsoft.Maintenance/maintenanceConfigurations définit les maintenance windows, et Microsoft.Maintenance/configurationAssignments les assigne aux VMs. Un template Bicep bien structuré peut déployer la configuration Update Manager complète pour un environnement de 50 VMs en moins de 2 minutes via une pipeline CI/CD.

Le provider Terraform AzureRM (version 3.90+) inclut les ressources azurerm_maintenance_configuration et azurerm_maintenance_assignment_virtual_machine. Intégrez ces ressources dans vos modules Terraform de provisioning VM pour que chaque nouvelle VM soit automatiquement enrôlée dans le programme de patching au moment de sa création.

Pour les opérations ponctuelles (déploiement d'urgence, interrogation du statut), Azure CLI offre des commandes directes :

az maintenance update create   --resource-group MonRG   --resource-name MaVM   --resource-type virtualMachines   --provider-name Microsoft.Compute

Pour approfondir la sécurisation des VMs Azure au-delà du patching, consultez nos guides sur Microsoft 365 et Azure pour les stratégies de détection d'attaques, et sur la sécurité multi-cloud pour une vision unifiée des politiques de sécurité entre AWS, Azure et GCP.

Questions fréquentes sur Azure Update Manager

Azure Update Manager est-il gratuit pour les VMs Azure ?

Oui, Azure Update Manager est gratuit pour les VMs Azure (IaaS). Le service n'est pas facturé séparément — il est inclus dans le coût des VMs Azure. Pour les serveurs hybrides gérés via Azure Arc (on-premise ou multi-cloud), Azure Update Manager est facturé dans le cadre d'Azure Arc : 6 $ par serveur physique et par mois en 2026. C'est significativement moins cher que les solutions alternatives comme Microsoft SCCM ou des outils tiers de gestion de patchs.

Peut-on tester les patchs en staging avant production avec Azure Update Manager ?

Oui. Créez des groupes de machines avec des maintenance configurations différentes : une configuration "Staging" avec une maintenance window le mardi (lendemain du Patch Tuesday), et une configuration "Production" avec une maintenance window le jeudi suivant. Les patchs sont installés en staging 48h avant production — si des incidents sont détectés en staging, vous pouvez exclure les patchs problématiques de la configuration Production avant qu'ils n'atteignent les serveurs de production.

Azure Update Manager supporte-t-il les patchs de bases de données (SQL Server, MySQL) ?

Azure Update Manager gère les patchs au niveau OS uniquement — il n'applique pas les patchs applicatifs des moteurs de bases de données. Pour SQL Server sur Azure VMs, les patchs SQL Server doivent être appliqués séparément via SQL Server Management Studio ou les packages MSU de Microsoft. Les bases de données managées (Azure SQL, MySQL Flexible Server) sont patchées automatiquement par Microsoft sans intervention de l'administrateur.

Que se passe-t-il si une VM redémarre pendant une opération critique ?

Azure Update Manager peut être configuré pour ne pas redémarrer automatiquement après installation (Reboot setting : Never), vous laissant contrôler manuellement les redémarrages. Le statut de la VM passe alors à "Pending Reboot" dans le tableau de bord. Pour les VMs critiques, combinez ce paramètre avec les pre/post scripts pour sortir la VM du load balancer avant le redémarrage planifié — l'application continue à servir les requêtes pendant le redémarrage de la VM en cours de patching.

Gestion des exceptions et exclusions de patchs

Tous les patchs disponibles ne doivent pas nécessairement être installés en production. Certaines mises à jour créent des incompatibilités avec des logiciels métier — une mise à jour .NET peut casser une application développée en interne qui dépend d'une version précise du runtime, ou un patch kernel peut désactiver un pilote propriétaire indispensable. Azure Update Manager permet de gérer des exclusions précises sans bloquer l'ensemble du programme de patching.

La fonctionnalité Patch Exclusions (disponible depuis la version Q3 2025 d'Azure Update Manager) permet d'exclure des KBs spécifiques par numéro de bulletin, ou des packages Linux par nom et version. Créez une politique d'exclusion au niveau de la maintenance configuration et elle s'applique à toutes les VMs assignées. Documentez chaque exclusion avec une justification et une date de révision — une exclusion sans justification datée devient rapidement une dette de sécurité invisible.

Pour les environnements réglementés (PCI DSS, ISO 27001), les exclusions de patchs de sécurité critiques doivent être accompagnées d'une analyse de risque documentée et d'une mesure compensatoire. Par exemple, exclure un patch corrigeant une RCE sur un composant non exposé réseau peut être acceptable si le composant est isolé par micro-segmentation et surveillé par un EDR. La décision doit être tracée dans votre GRC (Governance, Risk and Compliance) et revue au moins mensuellement.

Azure Update Manager dans une stratégie de sécurité multicouche

La gestion des patchs est une couche de défense, pas une protection complète. Un serveur entièrement patché peut être compromis via une vulnérabilité applicative non couverte par les mises à jour OS (injection SQL, misconfiguration, credentials faibles). Azure Update Manager s'intègre dans une stratégie de défense en profondeur qui combine :

Gestion des patchs (Azure Update Manager) : réduit la surface d'attaque en éliminant les vulnérabilités connues avec patch disponible. Cible : fenêtre de patching < 72h pour les CVE CVSS >= 9.0 exploitées activement.

Vulnerability Management (Defender for Cloud Vulnerability Assessment) : détecte les vulnérabilités non encore patchées, les configurations faibles, et les composants logiciels tiers vulnérables dans les applications. Complémentaire à Update Manager qui ne gère que les patchs OS et runtime Microsoft.

Endpoint Detection & Response (Microsoft Defender for Endpoint) : détecte et répond aux compromissions actives, indépendamment des vulnérabilités — un attaquant qui utilise des credentials volés ne déclenche aucune alarme de vulnerability management mais est détecté par l'analyse comportementale EDR.

Cette combinaison couvre les trois phases de la killchain : réduire la surface d'attaque (patchs), détecter les anomalies (SIEM/EDR), et répondre aux incidents. Pour les organisations qui veulent externaliser la supervision de cette stack, notre service RSSI externalisé inclut la définition et le suivi des KPIs de patching, l'intégration avec Defender for Cloud et la préparation aux audits ISO 27001 et NIS 2.

Feuille de route patching 2026 : de WSUS à Azure Update Manager

La migration de WSUS vers Azure Update Manager est un projet en deux phases pour la plupart des organisations. Phase 1 (mois 1-2) : déployez Azure Update Manager en parallèle de WSUS pour les nouvelles VMs Azure — évaluez la couverture et les rapports sans toucher l'infrastructure WSUS existante. Phase 2 (mois 3-6) : migrez progressivement les VMs existantes de WSUS vers Azure Update Manager par groupes (dev, staging, production). WSUS peut être décommissionné quand 100 % des ressources Azure sont gérées par Update Manager et que les serveurs on-premise restants sont soit enrôlés via Arc, soit remplacés. Cette approche progressive permet de valider la couverture réelle avant de couper la solution historique.