Ctrl+Alt+Prod

Ctrl+Alt+Prod : automatisation, infra et bonnes pratiques pour admins et devops

  • NetScaler CVE-2026-88779 : la faille SAML exploitée activement

    NetScaler CVE-2026-88779 : la faille SAML exploitée activement

    CISA a ajouté CVE-2026-88779 à son catalogue KEV le 4 octobre 2026, avec une échéance de remédiation fixée au 7 octobre pour les agences fédérales américaines. La faille touche NetScaler ADC et NetScaler Gateway, affiche un CVSS 4.0 de 8.7, et Citrix confirme des attaques ciblées déjà observées contre des appliances non corrigées. Si tu gères un NetScaler exposé sur Internet, ce n’est pas un correctif à mettre dans le backlog du mois prochain.

    Ce que fait réellement la faille

    C’est un débordement mémoire (CWE-119) qui provoque un déni de service : Citrix indique qu’un déclenchement répété peut rendre le service indisponible, sans impact constaté sur l’intégrité des données. Aucun détail technique d’exploitation n’a été publié par Citrix ni par CISA — seule la conséquence (DoS) est confirmée.

    Qui est concerné : la précondition SAML

    Toutes les appliances NetScaler ne sont pas exposées. Seules celles configurées en authentification SAML sont vulnérables — soit comme Service Provider (SP), soit comme Identity Provider (IdP) — utilisée en combinaison avec un virtual server Gateway ou AAA. Secure Private Access en déploiement hybride utilisant des instances NetScaler est également concerné.

    Pour savoir si tu es exposé, cherche ces deux lignes dans ta configuration running :

    add authentication samlAction
add authentication samlIdPProfile

    Si l’une des deux apparaît et que du SAML tourne derrière un virtual server Gateway ou AAA, tu es dans le périmètre à patcher en priorité.

    Versions affectées et correctifs

    Ligne Versions vulnérables Version corrigée
    NetScaler ADC/Gateway 14.1 avant 14.1-73.41 14.1-73.41
    NetScaler ADC/Gateway 13.1 avant 13.1-64.28 13.1-64.28
    14.1 FIPS avant 14.1-73.41 FIPS 14.1-73.41 FIPS
    13.1 FIPS/NDcPP avant 13.1-37.282 13.1-37.282 FIPS/NDcPP

    Le piège pour qui a déjà patché la semaine dernière

    Citrix avait publié, la semaine précédente, un lot de 8 vulnérabilités NetScaler incluant deux failles critiques déjà exploitées, CVE-2026-88771 et CVE-2026-88772, corrigées en 14.1-73.37 et 13.1-64.23. Si tu as appliqué ce correctif et que tu coches la case SAML ci-dessus, tu dois remonter une deuxième fois vers 14.1-73.41 ou 13.1-64.28 : être sur 73.37/64.23 ne protège pas contre CVE-2026-88779, qui est sortie après.

    Mitigation temporaire si tu ne peux pas patcher immédiatement

    Sur les versions intermédiaires 14.1-73.37 à 73.40 et 13.1-64.23 à 64.27, les signatures Global Deny List réduisent l’exposition si le virtual patching est activé. Vérifie leur présence avec :

    show appfw signatures

    Ce n’est qu’un pansement. Citrix le dit lui-même : la mise à jour reste nécessaire partout où c’est possible, et les signatures ne remplacent pas le correctif sur les versions plus anciennes que 73.37/64.23.

    Pourquoi ne pas se contenter des signatures

    Parce qu’un DoS sur une Gateway exposée, ce n’est pas qu’une question de disponibilité du service — c’est l’accès distant de toute ton organisation qui tombe, potentiellement en pleine journée de production. Entre une fenêtre de maintenance programmée pour la mise à jour et une coupure non planifiée pendant les heures ouvrées, le choix ne devrait pas traîner. Priorise les appliances internet-facing et celles qui portent de l’authentification critique (VPN, SSO) avant les instances internes.

    FAQ

    Mon NetScaler n’utilise pas SAML, suis-je concerné ?

    Non, d’après les informations publiées par Citrix : la précondition d’exploitation est la présence d’une configuration SAML (SP ou IdP) associée à un virtual server Gateway ou AAA. Sans SAML, cette CVE précise ne s’applique pas à ton appliance.

    J’ai déjà patché en 14.1-73.37 la semaine dernière, c’est suffisant ?

    Non si tu utilises SAML : 73.37 corrige CVE-2026-88771 et CVE-2026-88772, pas CVE-2026-88779. Il faut remonter à 14.1-73.41 (ou 13.1-64.28 côté branche 13.1).

    Le DoS peut-il être exploité sans authentification préalable ?

    Citrix et CISA n’ont publié aucun détail technique sur le vecteur d’exploitation précis — seule la conséquence (déni de service) est confirmée publiquement à ce stade.

    Où trouver l’avis officiel complet ?

    Dans l’article de support Citrix CTX697174, qui liste les versions exactes et les instructions de mise à niveau pour chaque branche.

    Ce n’est pas la première fois cette année qu’un boîtier d’accès distant très répandu se retrouve dans le viseur de CISA à quelques semaines d’intervalle — Cisco, Citrix et Fortinet avaient déjà cumulé trois entrées au catalogue KEV mi-septembre, et la faille ScreenConnect CVSS 9.9 début octobre suit le même schéma : un outil d’accès à distance massivement déployé, une fenêtre de correction courte imposée par une exploitation active. Si tu administres plusieurs appliances NetScaler, le réflexe à prendre maintenant : grep ta config pour la précondition SAML sur chacune, planifie l’upgrade en priorité sur les appliances exposées, et ne t’arrête pas à la fenêtre de remédiation fédérale du 7 octobre — elle ne concerne que les agences US, pas le niveau de risque réel pour ton infrastructure.

  • Azure Pipelines : les agents GitHub-hosted passent en GA

    Azure Pipelines : les agents GitHub-hosted passent en GA

    Depuis le 1er octobre 2026, Azure Pipelines propose un second pool d’agents à côté du pool Azure Pipelines classique : GitHub-hosted Agents, facturé à la minute, avec des machines plus costaudes que les agents Microsoft-hosted historiques — jusqu’à 16 cœurs côté Linux et Windows, et de l’Apple Silicon côté macOS. Les SKU macOS sont en disponibilité générale, les SKU Linux et Windows encore en preview publique, d’après l’annonce officielle d’Azure DevOps. Voici ce que ça change concrètement, et surtout combien ça coûte.

    Un second pool, pas un remplacement

    Le pool GitHub-hosted Agents tourne sur la même infrastructure que les runners GitHub Actions, dans les mêmes régions que le pool Microsoft-hosted existant. Chaque job démarre sur une VM fraîche, hébergeant un seul agent, réimagée dès la fin du job — même modèle d’isolation que ce que tu connais déjà sur Azure Pipelines.

    Point important : activer ce pool ne touche à rien de ton côté. Tes pipelines existants restent sur leur pool actuel tant que tu ne changes pas explicitement le champ pool dans ton YAML. Aucune bascule automatique, aucune facturation tant qu’un job n’a pas réellement tourné sur une de ces machines.

    Les tarifs, SKU par SKU

    La facturation se fait à la minute d’exécution, par SKU — pas de ticket forfaitaire, pas de palier. Voici le tableau complet publié par Microsoft :

    OS SKU Tarif/min vCPU RAM SSD Image
    macOS Standard 0,062 $ 3 (arm64, M1) 7 Go 14 Go macos-26-arm64
    macOS XLarge 0,102 $ 5 + 8 cœurs GPU (arm64, M2) 14 Go 14 Go macos-26-arm64-xl
    Linux 8 cœurs 0,022 $ 8 (x64) 32 Go 300 Go ubuntu-24.04-8-core
    Linux 16 cœurs 0,042 $ 16 (x64) 64 Go 600 Go ubuntu-24.04-16-core
    Windows 8 cœurs 0,042 $ 8 (x64) 32 Go 300 Go windows-2025-8-core
    Windows 16 cœurs 0,082 $ 16 (x64) 64 Go 600 Go windows-2025-16-core

    Compare ça à un agent Microsoft-hosted classique (2 vCPU, 7 Go de RAM, 14 Go de disque, gratuit dans la limite de tes jobs parallèles) : le Linux 8 cœurs coûte 1,32 $ pour un job d’une heure. Pour un build qui tourne 20 fois par jour, ça grimpe vite — fais le calcul avant de migrer tes pipelines les plus actifs par réflexe.

    Les images ubuntu-26.04-8-core, ubuntu-26.04-16-core, windows-2025-8-core et windows-2025-16-core sont encore en cours de déploiement et pas disponibles partout. Ubuntu 24.04 et Windows Server 2025 + Visual Studio 2026 le sont, eux, pour toutes les organisations ayant activé le pool.

    Ce qui ne change pas côté facturation

    Cette facturation à la minute est totalement séparée de tes jobs parallèles payants habituels — pas besoin d’en acheter, et ces jobs-là ne consomment pas ton quota existant. En contrepartie, il n’y a aucun palier gratuit : contrairement au pool Microsoft-hosted, tu payes dès la première minute sur GitHub-hosted Agents.

    Activer le pool

    Trois étapes, avec une subtilité à ne pas rater sur le délai :

    1. Va dans Organization settings > Billing (il te faut la permission billing-settings).
    2. Active Enable GitHub-hosted agents et enregistre.
    3. Le provisionnement du pool peut prendre jusqu’à 24 heures — ne t’attends pas à voir le pool disponible instantanément après avoir cliqué.

    Une fois le pool prêt, référence-le dans ton YAML par son nom et le label d’image qui correspond à l’OS et au SKU voulus :

    pool:
  name: GitHub-hosted Agents
  vmImage: ubuntu-24.04-8-core

steps:
  - script: echo "Build sur agent GitHub-hosted 8 cœurs"

    Pour du macOS XLarge par exemple, il suffit de remplacer la valeur par xcode-27-xlarge ; pour du Windows 16 cœurs avec Visual Studio 2026, par windows-2025-vs2026-16-core.

    Surveiller la consommation

    Deux endroits à connaître pour ne pas découvrir la facture en fin de mois : l’onglet Analytics du pool GitHub-hosted Agents, qui filtre les minutes consommées par SKU, projet et pipeline, et Azure Cost Management, qui permet de poser des budgets et des alertes par organisation et par projet. Mets au moins une alerte de budget avant de laisser une équipe entière basculer ses pipelines — le pay-as-you-go n’a pas de garde-fou intégré.

    Faut-il migrer tes pipelines dessus ?

    Pas systématiquement, et certainement pas tout de suite pour tout. Si tes builds actuels tiennent dans les 2 vCPU / 7 Go du pool Microsoft-hosted et restent sous ta limite de jobs parallèles, il n’y a aucune raison de payer à la minute pour la même chose. L’intérêt réel est ailleurs : les builds iOS/macOS qui ont besoin d’Apple Silicon natif plutôt que d’une émulation, les gros monorepos qui saturent 2 vCPU et passent leur temps à attendre l’I/O disque, ou les pipelines de build Docker multi-étapes qui tireraient vraiment parti de 16 cœurs et 600 Go de SSD. Pour ces cas-là, le calcul coût/temps gagné penche vite en faveur du pool GitHub-hosted, même en payant à la minute.

    FAQ

    Le pool GitHub-hosted remplace-t-il les agents Microsoft-hosted classiques ?

    Non. Les deux coexistent. Le pool Azure Pipelines reste gratuit dans la limite de tes jobs parallèles ; GitHub-hosted Agents est une option payante en plus, pas un remplacement forcé.

    Est-ce que j’ai des minutes gratuites avec GitHub-hosted Agents ?

    Aucune. C’est facturé dès la première minute d’exécution, à la différence du pool Microsoft-hosted qui offre un quota mensuel gratuit selon ton plan.

    Les images Ubuntu 26.04 et Windows Server 2025 (nouvelle vague) sont-elles disponibles chez moi ?

    Pas forcément tout de suite : Microsoft les déploie progressivement. Vérifie leur disponibilité dans ton organisation avant de les référencer dans un pipeline critique.

    Comment éviter une facture surprise ?

    Pose un budget et une alerte dans Azure Cost Management dès l’activation du pool, et surveille l’onglet Analytics les premières semaines pour repérer les pipelines qui consomment le plus.

    Si tu gères déjà des pools d’agents self-hosted pour éviter la queue du pool partagé, ça vaut le coup de comparer le coût réel du pay-as-you-go à celui de ta maintenance actuelle — les Managed DevOps Pools visaient déjà à alléger cette charge d’un autre côté. Et si le sujet qui te préoccupe plutôt, c’est la lisibilité de tes résultats de build, la nouvelle page de couverture de code d’Azure Pipelines publiée début octobre va dans le même sens d’amélioration continue du produit. Active le pool sur un seul projet test cette semaine, compare la facture réelle à tes jobs parallèles existants, et tu sauras en un cycle de sprint si la bascule vaut le coup pour le reste de ton organisation.

  • Terraform 1.16 : import dans les modules et destroy = false

    Terraform 1.16 : import dans les modules et destroy = false

    Jusqu’à Terraform 1.15, un bloc import ne pouvait vivre que dans le module racine. Si tu voulais reprendre la main sur un groupe de ressources créé à la main et géré ensuite par un module, tu devais écrire depuis la racine des adresses comme module.network.azurerm_virtual_network.main, et le module lui-même ne savait rien de cette adoption. Terraform 1.16, publié le 26 août 2026 et suivi de la 1.16.1 le 2 septembre, lève cette limite.

    Ce n’est pas la seule nouveauté utile. Voici ce qui change vraiment pour un usage quotidien sur Azure, ce qui mérite d’être testé avant d’y croire, et le seul point de vigilance de la montée de version.

    Les blocs import acceptés dans les modules

    Les notes de version de la 1.16.0 l’annoncent en une ligne (#38352) : les blocs import sont désormais supportés à l’intérieur des modules. Concrètement, un module peut porter lui-même l’adoption de ressources existantes :

    # modules/resource-group/main.tf
resource "azurerm_resource_group" "this" {
  name     = var.name
  location = var.location
}

import {
  to = azurerm_resource_group.this
  id = "/subscriptions/${var.subscription_id}/resourceGroups/${var.name}"
}

    Le même lot corrige un bug gênant : les blocs import respectent maintenant les noms locaux de providers (#38338). Si tu utilises des alias du type azurerm.hub pour cibler un autre abonnement, c’était une source d’erreurs.

    Mon avis : c’est un vrai gain pour les projets de reprise d’existant (landing zone, migration d’un parc fait au portail), mais ne laisse pas de bloc import en dur dans un module partagé entre plusieurs équipes. Chaque appelant hériterait d’une tentative d’import qui n’a de sens que pour toi. Garde ces blocs dans un module d’adoption dédié, ou retire-les une fois l’import fait. Teste aussi le comportement avec un module appelé en count ou for_each sur un terraform plan avant de généraliser.

    lifecycle { destroy = false } : ce que prevent_destroy ne faisait pas

    Nouveauté de la 1.16 (#38784), le bloc lifecycle d’une ressource accepte maintenant destroy = false. La documentation du méta-argument lifecycle le décrit ainsi : la ressource est retirée de l’état sans que l’infrastructure réelle soit détruite.

    resource "azurerm_storage_account" "legacy_logs" {
  name                     = "stlegacylogs001"
  resource_group_name      = azurerm_resource_group.this.name
  location                 = azurerm_resource_group.this.location
  account_tier             = "Standard"
  account_replication_type = "GRS"

  lifecycle {
    destroy = false
  }
}

    La différence avec prevent_destroy est importante. prevent_destroy = true fait échouer le plan dès qu’une destruction est prévue, mais la doc rappelle qu’il ne protège rien si tu supprimes la configuration de la ressource. destroy = false fait autre chose : Terraform « oublie » la ressource au lieu de la supprimer. C’est exactement ce que tu veux quand une ressource passe sous la gestion d’une autre équipe ou d’une autre stack.

    Un bémol : la documentation reste laconique sur les cas limites, en particulier le remplacement forcé (un changement d’attribut qui impose une recréation). Valide le comportement sur ton cas avec un terraform plan en environnement de test avant de compter dessus en production. Pour une ressource que tu ne dois jamais perdre, garde un verrou Azure (CanNotDelete) en plus : c’est la seule protection qui ne dépend pas de l’outil.

    Le bloc store de terraform_data

    Les valeurs éphémères (arrivées en 1.10) ont un défaut assumé : elles ne survivent pas entre le plan et l’apply. Le nouveau bloc store de terraform_data (#38298) permet de les conserver. L’exemple de la documentation de terraform_data :

    ephemeral "random_password" "test" {
  length = 16
}

resource "terraform_data" "test" {
  store {
    input     = ephemeral.random_password.test.result
    sensitive = true
    version   = 1
  }
}

output "password" {
  sensitive = true
  value     = terraform_data.test.store.sensitive_output
}

    L’argument version est la subtilité à retenir : tant que tu ne l’incrémentes pas, une nouvelle valeur d’input ne remplace pas la sortie stockée. Ça t’évite de régénérer un mot de passe à chaque plan.

    Attention au revers : stocker une valeur, c’est l’écrire dans l’état, même marquée sensitive. Les valeurs éphémères ont été créées justement pour ne plus y mettre de secrets. Utilise store seulement quand tu en as vraiment besoin, et seulement avec un backend chiffré et des droits d’accès serrés sur le state (pour un backend azurerm, un compte de stockage avec RBAC Entra et sans clé d’accès partagée).

    Les petites améliorations qui changent le quotidien

    • terraform state show -json et terraform workspace list -json produisent enfin une sortie exploitable par un script, sans parser du texte.
    • terraform graph -format=mermaid sort le graphe de dépendances en Mermaid : tu peux le coller tel quel dans un README GitHub ou un wiki Azure DevOps, qui savent l’afficher.
    • terraform console -scope=module.network évalue tes expressions dans le contexte d’un module. Pratique pour déboguer un locals compliqué sans tout remonter à la racine.
    • contains() sait tester la valeur null, et merge() ne plante plus quand on lui passe des objets null.
    • terraform test liste maintenant les ressources laissées en place quand skip_cleanup est activé.
    • Les namespaces de providers avec underscore sont acceptés (#38894), ce qui débloque certains registres privés.

    Avant de monter de version

    La seule note de mise à niveau concerne les provisioners : bastion_host_key est désormais réellement appliqué (#38318). Si tu utilises encore des provisioners remote-exec ou file via un bastion SSH, vérifie que la clé configurée est la bonne. Jusqu’ici, une valeur fausse passait inaperçue. Après la mise à jour, la connexion échouera.

    Pour le reste, la montée depuis 1.15 se fait sans réécriture. Prends directement le dernier patch (1.16.1 à ce jour) et contrains la version dans tes modules racines :

    terraform {
  required_version = ">= 1.16.1, < 1.17.0"
}

    La 1.17 est déjà en alpha (build 1.17.0-alpha20260827), donc ne t’étonne pas de voir passer de nouvelles fonctions dans les prochains mois. Si tu es en train de te demander s’il faut rester sur Terraform ou passer à OpenTofu, j’ai fait le point dans OpenTofu vs Terraform en 2026.

    FAQ

    Mes configurations 1.15 fonctionnent-elles telles quelles ?

    Oui, à l’exception du cas bastion_host_key décrit plus haut. Fais quand même un terraform plan sur chaque stack après la mise à jour et vérifie qu’il ne propose aucun changement.

    Faut-il retirer un bloc import une fois la ressource importée ?

    Un bloc import dont la cible est déjà dans l’état ne fait plus rien, donc le garder ne casse rien. Le retirer rend le code plus lisible et évite qu’un futur lecteur se demande quelle ressource est encore « en adoption ».

    destroy = false ou bloc removed ?

    Le bloc removed (depuis 1.7) sert quand tu supprimes la ressource de ta configuration. destroy = false se pose sur la ressource elle-même, tant qu’elle est encore déclarée. Pour un transfert ponctuel vers une autre stack, removed reste le plus explicite.

    Ces nouveautés concernent-elles le provider AzureRM ?

    Non, elles sont dans le cœur de Terraform et marchent avec tous les providers. Côté AzureRM, la grosse évolution de l’année reste la version 5.0, dont j’ai détaillé la migration.

    Par où commencer

    Mets à jour Terraform sur ton poste et ton runner CI, lance un plan sur ta stack la plus simple, puis cherche dans ton code les terraform state rm lancés à la main dans des scripts ou des runbooks : ce sont les premiers candidats à remplacer par destroy = false ou un bloc removed, versionnés et relus comme le reste.

  • Entra Backup and Recovery : 7 jours de filet, et après ?

    Entra Backup and Recovery : 7 jours de filet, et après ?

    Vendredi, 17h40. Quelqu’un supprime la mauvaise stratégie d’accès conditionnel en faisant du ménage. Jusqu’au printemps dernier, ta seule option dans Entra ID était de la recréer de mémoire, ou depuis un export que tu espérais à jour. Depuis juin 2026, Microsoft Entra Backup and Recovery est disponible en GA : une sauvegarde quotidienne de ton tenant, automatique, que personne ne peut désactiver.

    C’est une vraie avancée. Mais la rétention est de sept jours, et la liste des propriétés restaurables est plus courte que ce que le nom du produit laisse imaginer. Voici ce que le service couvre vraiment, ce qu’il laisse de côté, et ce que tu dois garder en plus.

    Ce que fait le service

    D’après la documentation Microsoft Learn, le fonctionnement tient en peu de lignes :

    • une sauvegarde par jour, conservée 7 jours (c’était 5 pendant la preview) ;
    • activée d’office, et impossible à désactiver, supprimer ou modifier, même par un Global Administrator ;
    • stockée dans la même zone géographique que ton tenant ;
    • réservée aux tenants workforce avec licences Entra ID P1 ou P2 (les tenants External ID et Azure AD B2C ne sont pas pris en charge).

    Dans le centre d’administration Entra, le menu Backup and recovery te donne quatre écrans : la liste des sauvegardes, les rapports de différences, la restauration (sur tout, sur certains types d’objets ou sur des ID précis) et l’historique des restaurations. Deux rôles dédiés existent : Microsoft Entra Backup Reader pour consulter, Microsoft Entra Backup Administrator pour lancer comparaisons et restaurations.

    Le fait que la sauvegarde soit hors de portée d’un admin compromis compte beaucoup. Un attaquant avec des droits élevés ne peut pas effacer ton point de retour.

    Ce qui est couvert, et ce qui ne l’est pas

    Bien couvert

    Les stratégies d’accès conditionnel et les emplacements nommés sont sauvegardés avec toutes leurs propriétés. C’est le cas d’usage le plus solide du produit. La stratégie des méthodes d’authentification est couverte pour huit méthodes (passkeys FIDO2, Authenticator, TAP, SMS, appel vocal, OTP par e-mail, OATH logiciel tiers, authentification par certificat).

    Utilisateurs, groupes, applications et principaux de service sont couverts aussi, mais sur une liste fermée de propriétés. Côté utilisateurs, par exemple : AccountEnabled, UserPrincipalName, Department, PerUserMfaState, UsageLocation, et une trentaine d’autres. Restaurer un principal de service restaure aussi ses attributions de rôles d’application et les consentements donnés par un admin pour toute l’organisation.

    Pas couvert (vérifié dans la liste officielle)

    La page objets et propriétés supportés est la seule qui compte. En la lisant attentivement, tu remarques ces absences :

    • le manager et le sponsor d’un utilisateur ;
    • les propriétaires de groupes et les règles des groupes dynamiques ;
    • les consentements donnés par un utilisateur (seuls les consentements admin pour toute l’organisation sont couverts) ;
    • les secrets et certificats d’application : passwordCredentials et keyCredentials ne figurent pas dans les propriétés restaurables ;
    • les attributions de rôles Entra : elles n’apparaissent dans aucune catégorie d’objets supportés ;
    • les objets supprimés définitivement (hard delete) : rien ne les recrée ;
    • les modifications sur les objets synchronisés depuis l’AD local : elles apparaissent dans le rapport de différences, mais sont exclues de la restauration (sauf les appartenances aux groupes).

    Les deux points sur les secrets et les rôles changent la lecture du produit. Prends un attaquant qui obtient un accès admin, ajoute un secret sur une app registration bien dotée en permissions et s’attribue un rôle privilégié. Une restauration ne retire ni l’un ni l’autre. Entra Backup and Recovery est un outil contre les erreurs de configuration et les modifications malveillantes de stratégies. Ce n’est pas un outil de remédiation d’incident. Pour ça, il te faut toujours ta procédure de réponse à incident, avec révocation des credentials et revue des rôles.

    La bonne méthode de restauration

    Microsoft le recommande, et c’est du bon sens : lance toujours un rapport de différences avant de restaurer. Tu vois exactement quels attributs et liens ont changé entre la sauvegarde et l’état actuel. Ça a un bénéfice pratique en plus : le premier accès à une sauvegarde déclenche un chargement des données qui prend un temps fixe, même sur un petit tenant. Le rapport de différences fait ce chargement à l’avance, et la restauration qui suit est plus rapide.

    Restreins ensuite le périmètre. Si une seule stratégie d’accès conditionnel a sauté, restaure cet ID-là, pas tout le type d’objet. Une restauration large peut écraser des changements légitimes faits depuis la sauvegarde.

    En environnement hybride, rappelle-toi que les objets dont la source d’autorité est l’AD local ne seront pas restaurés côté cloud. Si ta synchronisation tourne encore avec Entra Connect, l’échéance du 30 septembre sur Entra Connect Sync mérite d’être vérifiée au passage.

    Sept jours ne suffisent pas : garde ta propre copie

    Une modification discrète découverte dix jours plus tard est hors de portée du service. C’est pour ça que Microsoft renvoie lui-même vers ses bonnes pratiques de récupération, qui recommandent de documenter régulièrement l’état de référence via Microsoft Graph.

    Pour les objets les plus sensibles, un export quotidien en JSON suffit. Voici une base avec le SDK Microsoft Graph PowerShell :

    Connect-MgGraph -Scopes "Policy.Read.All"

$stamp = Get-Date -Format "yyyyMMdd"
$dir   = ".\entra-export\$stamp"
New-Item -ItemType Directory -Path $dir -Force | Out-Null

Get-MgIdentityConditionalAccessPolicy -All |
    ConvertTo-Json -Depth 10 |
    Out-File "$dir\conditional-access.json" -Encoding utf8

Get-MgIdentityConditionalAccessNamedLocation -All |
    ConvertTo-Json -Depth 10 |
    Out-File "$dir\named-locations.json" -Encoding utf8

Get-MgPolicyAuthenticationMethodPolicy |
    ConvertTo-Json -Depth 10 |
    Out-File "$dir\auth-methods-policy.json" -Encoding utf8

    En production, fais tourner ce script en mode application (certificat ou identité managée dans Azure Automation, plutôt qu’une connexion interactive), et pousse les fichiers dans un dépôt Git ou un compte de stockage avec immuabilité. Un git diff entre deux jours devient alors ton propre rapport de différences, sans limite de rétention.

    FAQ

    Est-ce que ça demande une licence en plus ?

    Non. Entra ID P1 ou P2 suffit, et le service est actif d’office sur les tenants éligibles.

    Ça remplace Microsoft 365 Backup ?

    Non, ce ne sont pas les mêmes données. Entra Backup and Recovery protège l’annuaire, Microsoft 365 Backup protège les boîtes mail, SharePoint et OneDrive. J’ai détaillé ce que couvre Microsoft 365 Backup dans un article précédent.

    Et mon Active Directory local ?

    Il reste à ta charge, avec ta solution de sauvegarde habituelle. Le service Entra ne touche pas à AD DS.

    Un utilisateur supprimé il y a 15 jours, je le récupère comment ?

    Par la corbeille Entra : les utilisateurs, groupes Microsoft 365, groupes de sécurité cloud, app registrations et principaux de service supprimés en soft delete restent restaurables 30 jours. Backup and Recovery vient en complément, pas à la place.

    À faire cette semaine

    Ouvre le menu Backup and recovery de ton tenant et lance un rapport de différences sur la sauvegarde d’hier, juste pour voir le délai et le rendu. Attribue le rôle Backup Administrator à deux personnes nommément, plutôt que de compter sur les Global Admins. Et mets en place l’export Graph quotidien : c’est lui qui te sauvera le jour où le problème aura plus d’une semaine. Une sauvegarde de l’annuaire s’inscrit dans la même logique que la règle 3-2-1-1-0 : une copie ne suffit jamais.

  • Azure Linux 2.0 sur AKS : migre tes node pools avant le 31 octobre

    Azure Linux 2.0 sur AKS : migre tes node pools avant le 31 octobre

    Le 31 octobre 2026, AKS supprime les images de nœuds Azure Linux 2.0. Si un de tes node pools tourne encore dessus, il ne pourra plus scaler. Rien ne casse le jour J : pas de nœud qui tombe, pas d’alerte rouge. Le problème apparaît le jour où l’autoscaler veut ajouter des nœuds pendant un pic de charge et n’y arrive pas.

    Il te reste un peu plus de trois semaines. Cet article te donne deux requêtes pour repérer les pools concernés, le chemin de migration le moins risqué, et un rappel sur Kubernetes 1.34, qui arrive en fin de vie upstream quatre jours plus tôt, le 27 octobre.

    Ce qui se passe exactement le 31 octobre

    Azure Linux 2.0 n’est plus supporté sur AKS depuis le 30 novembre 2025. Depuis cette date, l’image de nœud est figée sur la release 202512.06.0 : aucun correctif de sécurité n’a été publié depuis bientôt un an. Le 31 octobre 2026, Microsoft retire ces images, et la documentation AKS est claire sur la conséquence : tu ne pourras plus scaler tes node pools. Toute opération qui doit provisionner un nœud neuf à partir de cette image est donc exposée, autoscaler compris.

    Pourquoi des clusters tournent encore dessus ? Parce que l’OS SKU AzureLinux pointait par défaut sur Azure Linux 2.0 pour les versions Kubernetes 1.27 à 1.31. Un cluster créé en 2024 et jamais monté au-delà de 1.31 est presque toujours dans ce cas.

    Le piège du LTS

    Si ton cluster est en support long terme (LTS) sur 1.30 ou 1.31, tu te crois peut-être couvert. Tu ne l’es pas. Microsoft le précise dans le calendrier des versions AKS : Azure Linux 2.0 atteint sa fin de vie pendant la période LTS des versions 1.28 à 1.31. Le LTS prolonge Kubernetes, pas l’OS des nœuds.

    Repérer les node pools concernés

    Sur un cluster

    az aks nodepool list \
  --resource-group rg-prod-aks \
  --cluster-name aks-prod-01 \
  --query "[].{pool:name, k8s:orchestratorVersion, osSku:osSku, image:nodeImageVersion}" \
  -o table

    Un pool avec l’OS SKU AzureLinux (ou l’ancien nom CBLMariner), une version Kubernetes inférieure ou égale à 1.31 et une image encore en 202512.06.0 est quasi certainement en Azure Linux 2.0.

    Sur tout ton parc

    Si tu gères plus de deux ou trois clusters, passe par Azure Resource Graph plutôt que de boucler sur chaque abonnement :

    az graph query -q "
resources
| where type =~ 'microsoft.containerservice/managedclusters'
| mv-expand pool = properties.agentPoolProfiles
| extend osSku = tostring(pool.osSKU), k8s = tostring(pool.orchestratorVersion)
| where osSku in~ ('AzureLinux', 'CBLMariner')
| project cluster = name, resourceGroup, subscriptionId,
          pool = tostring(pool.name), osSku, k8s,
          image = tostring(pool.nodeImageVersion)
| order by k8s asc
" --first 1000 -o table

    Trie par version : les lignes en 1.31 et moins sont ta liste de travail. Les pools Azure Linux en 1.32 ou plus sont déjà sur Azure Linux 3.0, sauf exception que l’image te révélera.

    Deux chemins de migration, un seul bon ordre

    Tu as deux façons de sortir d’Azure Linux 2.0 :

    • Changer l’OS sans toucher à Kubernetes avec az aks nodepool update --os-sku AzureLinux3. Cet OS SKU est supporté de Kubernetes 1.28 à 1.36, donc il fonctionne sur ton cluster actuel. Les nœuds sont réimagés, rien d’autre ne bouge.
    • Monter Kubernetes en 1.32 ou plus avec l’OS SKU AzureLinux, qui bascule alors par défaut sur Azure Linux 3.0.

    Mon conseil : fais la première option maintenant, et l’upgrade Kubernetes après, dans une fenêtre séparée. Un cluster encore en 1.31 doit de toute façon franchir plusieurs versions mineures pour revenir dans le support standard (AKS a mis fin au support de 1.31 le 1er novembre 2025). Changer l’OS et enchaîner trois ou quatre versions Kubernetes dans la même soirée, c’est empiler deux sources de casse sans pouvoir dire laquelle a cassé quoi. Avec trois semaines devant toi, une seule opération maîtrisée vaut mieux qu’un grand saut.

    az aks nodepool update \
  --resource-group rg-prod-aks \
  --cluster-name aks-prod-01 \
  --name userpool1 \
  --os-sku AzureLinux3

    Avant de lancer la commande

    • Vérifie tes PodDisruptionBudgets. La réimage passe par un cordon puis un drain des nœuds. Un PDB avec maxUnavailable: 0 (ou un minAvailable égal au nombre de réplicas) bloque le drain, et l’opération reste coincée.
    • Règle le surge du pool si ce n’est pas déjà fait (az aks nodepool update --max-surge 33%, par exemple) pour accélérer le roulement sans saturer le quota de cœurs de ton abonnement.
    • Passe d’abord sur un pool hors production. Les agents tiers déployés en DaemonSet (EDR, agents de supervision) qui chargent un module noyau ou dépendent de paquets de l’OS sont les premiers à mal réagir à un changement de distribution. Demande à l’éditeur s’il supporte Azure Linux 3.0 avant le jour J.
    • Commence par les pools utilisateurs, puis le pool système une fois que tu as vu le comportement.

    Kubernetes 1.34 : l’autre échéance d’octobre

    Côté upstream, Kubernetes 1.34 est en mode maintenance depuis le 27 août et atteint sa fin de vie le 27 octobre 2026, d’après la page des patch releases. Son dernier patch connu est le 1.34.12, publié le 15 septembre.

    Sur AKS, tu as un peu plus de marge : le calendrier donne une fin de vie de 1.34 à fin novembre 2026. Ce n’est pas une raison pour attendre. Pour un cluster en 1.34, je viserais 1.36 plutôt que 1.37 : la 1.37 arrive tout juste en GA sur AKS ce mois-ci, et laisser passer les premiers patchs ne coûte rien. La 1.36 reste supportée jusqu’en juin 2027. Si tu veux savoir ce que la 1.37 apporte quand même, j’ai détaillé les nouveautés de Kubernetes 1.37 dans un article précédent.

    Pour ne plus découvrir ces échéances par hasard, AKS publie maintenant des notifications de fin de support dans Azure Resource Graph : KubernetesVersionEOLTwoWeeks, KubernetesVersionEOLOneWeek, puis KubernetesVersionOutOfSupport chaque semaine une fois la date passée. Pas besoin d’add-on ni de fenêtre de maintenance pour les recevoir. Branche-les sur une alerte et tu auras deux semaines de préavis.

    FAQ

    Mon cluster est en LTS 1.30, je suis tranquille ?

    Non. Le LTS couvre la version Kubernetes, pas Azure Linux 2.0. Tes nœuds sont concernés par le 31 octobre comme les autres.

    Est-ce que az aks nodepool update --os-sku réimage tous les nœuds d’un coup ?

    Non, AKS procède par vagues, avec cordon et drain, selon le surge configuré sur le pool. C’est justement pour ça que les PDB et le surge comptent.

    Je peux revenir à Azure Linux 2.0 si ça se passe mal ?

    Techniquement oui avant le 31 octobre, tant que la version Kubernetes supporte encore cet OS. Mais revenir sur un système sans correctif depuis onze mois, ce n’est pas un plan B, c’est un pansement. Prévois plutôt un pool de repli en Ubuntu si un composant résiste vraiment.

    Et les pools Ubuntu, ils ont aussi une échéance ?

    Oui, plus lointaine : Ubuntu 20.04 n’est plus supporté sur AKS à partir du 17 mars 2027, et Ubuntu 22.04 à partir du 30 juin 2027. Avec l’OS SKU Ubuntu, la bascule vers 24.04 se fait automatiquement quand tu passes Kubernetes en 1.35 ou plus.

    Où suivre l’annonce officielle ?

    Microsoft suit ce retrait dans l’issue GitHub AKS #4988. Les nouvelles dates éventuelles y apparaissent en premier.

    Ce que tu peux faire aujourd’hui

    Lance la requête Resource Graph ci-dessus. Si elle ne retourne rien, tu as gagné ta journée. Si elle sort des lignes, planifie la migration AzureLinux3 d’un premier pool hors production cette semaine, et garde l’upgrade Kubernetes pour novembre. Profite aussi du passage pour relire tes bonnes pratiques de sécurisation de cluster : un parc qui traînait des nœuds non patchés depuis un an a sûrement d’autres angles morts.

  • Azure Reservations : ce qui change avant le 1er février 2027 (et pourquoi agir maintenant)

    Azure Reservations : ce qui change avant le 1er février 2027 (et pourquoi agir maintenant)

    À partir du 1er février 2027, une réservation Azure achetée après cette date ne pourra plus être échangée si le service correspondant est aussi couvert par un savings plan — Machines Virtuelles, App Service, Azure SQL Database et les services équivalents. Ce n’est pas une rumeur ni une annonce à venir : c’est déjà écrit dans la documentation officielle de facturation Azure. Pour une équipe FinOps, ça change la fenêtre de décision dès maintenant, pas dans quinze mois.

    On avait déjà détaillé FOCUS 1.2 dans Azure Cost Management et posé les bases de la maîtrise des coûts Azure avec Cost Management. Cette fois, il s’agit d’un sujet plus pointu mais tout aussi concret : la politique de resserrement progressif qui touche les réservations Azure, et comment t’y préparer sans attendre la dernière minute.

    Deux échéances, pas une seule

    La première est déjà passée mais continue de produire des effets : depuis le 1er juillet 2026, Microsoft n’accepte plus l’achat ni le renouvellement de certaines réservations de VM dites legacy — les séries Av2, Amv2, Bv1, D, Ds, Dv2, Dsv2, F, Fs, Fsv2, G, Gs, Ls et Lsv2 en engagement d’un an, et Dv3, Dsv3, Ev3 et Esv3 en engagement d’un et trois ans. Les réservations déjà en cours restent valables jusqu’à leur terme, mais aucun renouvellement n’est plus possible pour ces familles. Si tu as encore des VM Dv2 ou Dsv2 en production avec une réservation qui arrive à expiration, c’est le moment d’y regarder de près : Microsoft documente précisément la marche à suivre pour ces réservations retirées.

    La seconde échéance, plus large, arrive le 1er février 2027 : à partir de cette date, une réservation nouvellement achetée pour un service couvert par un savings plan (VM, App Service, SQL Database notamment) ne bénéficiera plus que d’un seul échange possible — contre zéro limite aujourd’hui. Les réservations achetées avant cette date gardent ce droit à un échange final, même après l’échéance. Ce changement est documenté dans la page officielle sur le trade-in des réservations vers un savings plan.

    Pourquoi Microsoft pousse vers les savings plans

    Une réservation classique t’engage sur une famille de VM précise, dans une région précise, pour un ou trois ans. Un savings plan t’engage sur un montant de dépense horaire, valable sur l’ensemble des services de calcul éligibles, dans toutes les régions. Microsoft documente lui-même la logique d’arbitrage dans son guide pour choisir entre savings plan et réservation, avec un ordre de priorité qui a du sens pour n’importe quelle équipe FinOps : d’abord redimensionner les ressources inutilisées ou surdimensionnées, puis échanger les réservations sous-utilisées contre une configuration qui correspond mieux au besoin réel, ensuite transformer les réservations rigides restantes en savings plan flexible, et seulement après ça, acheter de nouveaux engagements.

    Le calcul du troisième échange a une règle précise à connaître avant de s’engager : le nouveau savings plan doit couvrir un engagement total au moins égal à l’engagement restant de la réservation échangée. Concrètement, pour une réservation de trois ans à 100 $/mois échangée après son 18ᵉ paiement, le nouveau savings plan doit représenter un engagement cumulé d’au moins 1 800 $ sur sa durée — pas question de ressortir avec un engagement plus léger que ce qui restait à payer.

    Ce que ça veut dire pour ta stratégie, concrètement

    Si tu gères encore un parc avec des réservations VM sur des familles legacy (Dv2, Dsv2, Fsv2 en tête), la fenêtre pour un dernier renouvellement avant retrait pure et simple est déjà fermée depuis juillet — il ne reste que la modernisation vers une série récente ou la bascule en savings plan. Pour tout le reste de ton portefeuille de réservations, le vrai sujet, c’est le nombre d’échanges restants : jusqu’au 31 janvier 2027, tu peux encore échanger sans limite de quantité (jusqu’à 100 réservations par opération). Après, chaque réservation achetée n’aura droit qu’à un aller simple vers un savings plan.

    Dans les faits, ça pousse clairement vers une chose : arrêter d’acheter des réservations VM par défaut pour tout ce qui n’est pas un socle réellement stable et prévisible sur plusieurs années. Pour une charge qui évolue — montée en charge saisonnière, migration de série de VM prévue, changement de région probable — le savings plan est désormais le choix le plus rationnel, et plus seulement une option de confort. Les réservations gardent leur intérêt pour les workloads franchement figés (un contrôleur de domaine, une base qui ne bougera pas), là où elles offrent la meilleure remise quand elles sont pleinement utilisées.

    FAQ

    Mes réservations déjà achetées cessent-elles de fonctionner le 1er juillet 2026 ou le 1er février 2027 ?

    Non. Les deux échéances concernent les nouveaux achats et renouvellements, pas les réservations déjà en cours : elles continuent de produire leurs remises jusqu’à leur date d’expiration normale.

    Azure VMware Solution est-il concerné par la restriction d’échange de 2027 ?

    Non, les réservations pour des services non couverts par un savings plan, comme Azure VMware Solution, sont explicitement exclues de cette restriction.

    Combien de réservations puis-je échanger en une seule opération ?

    Jusqu’à 100 réservations par achat de savings plan, sans changement annoncé sur cette limite pour l’instant.

    Microsoft va-t-il facturer des frais de résiliation anticipée ?

    Pas à ce jour. Le plafond de résiliation sans frais reste à 50 000 $ sur une fenêtre glissante de 12 mois, et Microsoft s’est engagé à prévenir six mois à l’avance avant d’introduire d’éventuels frais.

    En résumé

    Deux dates, deux logiques : le 1er juillet 2026 a fermé la porte sur plusieurs séries de VM reservations historiques, le 1er février 2027 fermera celle des échanges illimités. Si ton portefeuille de réservations n’a pas été revu depuis le printemps, c’est le bon moment pour le faire — avant que la fenêtre d’échange sans contrainte ne se referme.

  • Nutanix Move 6.3 : migrer de VMware vers AHV sans rupture

    Nutanix Move 6.3 : migrer de VMware vers AHV sans rupture

    Le 29 juillet 2026, Nutanix a sorti la version 6.3 de Move, son outil de migration de machines virtuelles. Passée sans grand bruit dans l’actualité générale, cette mise à jour mérite pourtant un arrêt si tu es encore sur VMware et que tu cherches une porte de sortie crédible après la hausse des licences Broadcom. Elle règle plusieurs blocages très concrets : migration sans copie intermédiaire, conservation du Secure Boot, et surtout une conversion de cluster ESXi vers AHV qui ne demande aucun matériel supplémentaire.

    On avait déjà couvert la question du choix d’hyperviseur après la crise des licences Broadcom et le guide de migration vers Proxmox VE. Nutanix AHV est la troisième option qui revient souvent dans les discussions, mais rarement avec le niveau de détail technique qu’elle mérite. Voyons ce que Move 6.3 change réellement.

    Move 6.3 : ce qui change concrètement

    Nutanix Move est l’outil gratuit qui orchestre la migration de VM depuis une source (VMware ESXi, AHV, AWS EC2, Azure VM, Azure VMware Solution) vers une destination AHV, sur site ou via NC2 (Nutanix Cloud Clusters) chez Azure, GCP, AWS ou OVHcloud. La version 6.3 ajoute trois choses qui comptent vraiment en production.

    La migration zero-copy depuis ESXi

    Jusqu’ici, migrer une VM depuis VMware vers AHV passait systématiquement par une copie complète des disques virtuels, avec le temps et la bande passante que ça suppose pour des volumes de plusieurs téraoctets. Move 6.3 introduit la migration sans copie depuis ESXi vers AHV, à condition de disposer d’un stockage externe compatible — à ce stade, Dell PowerStore et Pure Storage FlashArray sont supportés. Le disque virtuel n’est pas dupliqué : il est simplement reconnu et rattaché côté AHV. Pour une baie de production qui héberge déjà plusieurs centaines de VM, la différence entre une fenêtre de bascule de quelques heures et une de plusieurs jours n’est pas un détail.

    UEFI, Secure Boot et adresses IPv6 : les blocages qui empêchaient d’avancer

    Beaucoup de migrations restaient bloquées non pas sur la théorie, mais sur des détails qui cassaient des VM critiques une fois arrivées côté AHV. Move 6.3 préserve désormais les réglages UEFI et Secure Boot pendant la migration des VM qui les utilisent, corrige des problèmes d’authentification Windows constatés lors des migrations AHV-to-AHV, et gère mieux la conservation des adresses IPv6 et des interfaces réseau. Rien de spectaculaire pris isolément, mais ce sont exactement les points qui font échouer un plan de migration en conditions réelles — un contrôleur de domaine qui perd son Secure Boot, ou un serveur applicatif qui change d’adresse IPv6 au mauvais moment, ça n’a rien d’anecdotique.

    In-Place Cluster Conversion : convertir sans racheter de serveurs

    C’est probablement la fonctionnalité la plus intéressante pour qui gère déjà un cluster VMware en place. L’In-Place Cluster Conversion transforme un cluster ESXi existant en cluster AHV sans matériel supplémentaire : les mêmes serveurs physiques, reconfigurés en place. Comparé à une migration vers Proxmox VE, qui implique de réinstaller l’hyperviseur sur chaque nœud et de reconstruire le cluster PVE depuis zéro, cette approche change la donne pour les environnements où le budget matériel est contraint ou le calendrier serré. Sur le même sujet, Veeam détaille aussi les points de vigilance côté sauvegarde lors d’un passage ESXi vers AHV — à vérifier avant de lancer quoi que ce soit en production.

    À noter que cette conversion reste une opération destructive sur l’hyperviseur : il faut sauvegarder, planifier une fenêtre de maintenance, et prévoir un chemin de retour arrière avant de s’y engager. Move 6.3 ajoute aussi, en parallèle, un aperçu technique d’intégration avec CyberArk pour la gestion des identifiants pendant la migration, ainsi que le support des serveurs de fichiers fédérés et de nouveaux environnements Government Cloud Clusters sur AWS GovCloud pour les cas les plus réglementés.

    Qui devrait s’y intéresser maintenant, qui peut attendre

    Si tu es déjà équipé en Pure Storage FlashArray ou Dell PowerStore et que tu migres des volumes volumineux, la migration zero-copy justifie à elle seule de tester Move 6.3 dès cette version — le gain sur le temps de bascule est direct et mesurable. Si ton cluster ESXi tourne sur du matériel encore sous garantie et que tu veux éviter un second investissement, l’In-Place Cluster Conversion est l’argument qui penche vers AHV plutôt que vers Proxmox, où il faudra reconstruire le cluster.

    En revanche, si tu n’as pas de stockage externe compatible et que tes clusters tournent sur du matériel générique sans contrat de support Nutanix, le calcul est moins évident : AHV reste un écosystème propriétaire avec son propre modèle de licence (Prism Central 7.6 requis pour cette version), alors que Proxmox VE reste open source et gratuit à l’usage. Le choix dépend moins de la technique que de ce que tu es prêt à payer en licence contre ce que tu es prêt à investir en temps d’administration.

    FAQ

    Nutanix Move est-il gratuit ?

    Oui, l’outil Move lui-même est gratuit et téléchargeable comme appliance virtuelle. Ce qui coûte, c’est la plateforme Nutanix de destination (licences AHV/Prism) si tu n’en disposes pas encore.

    Peut-on migrer depuis Hyper-V avec Move 6.3 ?

    Move couvre VMware ESXi, AHV, AWS EC2, Azure VM et Azure VMware Solution comme sources. Hyper-V n’apparaît pas dans la liste des sources supportées pour cette version — si ton parc est sous Hyper-V, Move n’est pas l’outil adapté.

    Faut-il un stockage Pure Storage ou Dell pour utiliser Move ?

    Non, seulement pour bénéficier de la migration zero-copy. Sans ce type de stockage externe compatible, la migration fonctionne toujours, mais avec copie complète des disques, comme sur les versions précédentes.

    Quelle est la différence avec une migration vers Proxmox VE ?

    Côté licence, Proxmox VE reste open source et sans coût de plateforme ; côté matériel, l’In-Place Cluster Conversion de Nutanix évite une reconstruction complète du cluster, ce qui n’est pas le cas pour une migration vers Proxmox.

    En résumé

    Move 6.3 ne révolutionne pas la migration VMware vers AHV, mais il supprime plusieurs frictions réelles : copie de disques, Secure Boot cassé, cluster à reconstruire. Si Nutanix fait déjà partie de ta short-list post-Broadcom, c’est le bon moment pour tester une conversion sur un cluster non critique et mesurer, chez toi, le gain réel sur la fenêtre de bascule.

  • Grafana 13.1 : Git Sync et l’Assistant changent tes dashboards

    Grafana 13.1 : Git Sync et l’Assistant changent tes dashboards

    Grafana 13.1 est sorti cet été, et la fonctionnalité qui mérite vraiment ton attention n’est pas un nouveau type de panel. C’est Git Sync, qui transforme enfin tes dashboards en fichiers versionnés comme n’importe quel autre bout de code d’infra — fini le dashboard de prod modifié en direct sans trace.

    Git Sync : tes dashboards deviennent du code versionné pour de vrai

    Grafana proposait déjà une synchronisation Git basique. La 13.1 comble plusieurs trous pratiques : tu peux désormais importer un fichier JSON de dashboard directement depuis l’interface dans un dossier synchronisé avec Git, sans passer par une ligne de commande. La synchronisation fonctionne aussi au niveau racine du dépôt, sans obliger à passer par un dossier parent conteneur — un détail qui compte si ton dépôt de dashboards est organisé à plat. Les commits peuvent être signés automatiquement, via GPG, SSH ou S/MIME, et marqués « Verified » dans l’historique. Et les fichiers README.md du dépôt s’affichent nativement dans l’interface Grafana, à côté des dashboards qu’ils documentent.

    Si plus d’une personne touche à tes dashboards de production, c’est la fonctionnalité qui élimine une classe entière d’incidents bêtes : le fameux dashboard modifié en direct par quelqu’un sans que personne ne le sache, découvert uniquement quand une alerte ne se déclenche plus comme prévu. Avec Git Sync et des commits signés, chaque changement a un auteur, un historique et un diff — exactement ce qu’on attend d’une infra gérée comme du code.

    Grafana Assistant : huit nouvelles sources de données interrogeables directement

    Sous Grafana Enterprise, l’Assistant est désormais préinstallé nativement, sans passer par un plugin séparé. Sous Grafana OSS, il reste disponible via un plugin à installer à part. Le vrai changement, c’est l’élargissement à huit nouvelles sources de données interrogeables directement depuis l’Assistant : Snowflake, MongoDB, Oracle, Elasticsearch, Dynatrace, Honeycomb, Zabbix et Jira.

    L’intérêt concret : pouvoir poser une question qui croise observabilité et données métier sans changer d’outil — par exemple relier un pic de latence constaté dans tes métriques à un ticket Jira ouvert au même moment, ou croiser une alerte Zabbix avec une requête sur une base Oracle, directement dans l’interface Grafana. Ce n’est pas magique : l’Assistant interroge ce qu’on lui donne accès, et la qualité des réponses dépend toujours de la façon dont les sources sont connectées et nommées.

    Côté dashboards : ce qui change au quotidien

    Au-delà de ces deux chantiers, la 13.1 fait passer en disponibilité générale (GA) une série de fonctionnalités qui traînaient en preview :

    • Variables multi-propriétés : une seule variable peut désormais être mappée à plusieurs valeurs à la fois.
    • Transformation « Time series to table » : convertit une série temporelle en lignes de tableau avec des champs de tendance calculés.
    • Clustering d’annotations : navigation plus lisible quand un dashboard accumule beaucoup d’annotations sur une période.
    • Copier/coller les styles de panneaux : dupliquer la mise en forme d’un panel vers un autre sans tout reconfigurer à la main.
    • Filtres rapides et regroupement (« Filter and Group by ») sans avoir à configurer de variable de template au préalable.
    • Variables à portée de section : une variable peut désormais être limitée à une ligne ou un onglet spécifique du dashboard, plutôt que de s’appliquer partout.

    Prises une par une, ce sont des améliorations mineures. Prises ensemble, elles réduisent le nombre de dashboards qu’il faut reconstruire à la main après un changement de structure — ce qui, sur un parc de dashboards qui grossit depuis des années, finit par représenter un vrai gain de temps.

    Private Data Source Connect : MQTT, GitHub et IBM Db2 ajoutés

    Pour les sources de données hébergées sur site, Private Data Source Connect (PDC) permet d’établir un tunnel sécurisé sans ouvrir de port entrant sur le pare-feu. La 13.1 étend la liste des sources compatibles avec MQTT, GitHub et IBM Db2 — utile si une partie de ton infra d’observabilité reste on-prem pendant que Grafana lui-même tourne dans le cloud.

    FAQ

    La mise à jour depuis Grafana 13.0 casse-t-elle quelque chose ?

    Les notes de version officielles ne signalent pas de changement cassant majeur pour cette mise à jour mineure. Comme pour toute montée de version en production, teste d’abord sur une instance non critique, surtout si tu utilises des dashboards avec des variables ou des transformations personnalisées.

    Git Sync remplace-t-il complètement la sauvegarde de dashboards via API ?

    Non, ce sont deux approches complémentaires. Git Sync gère le versioning et la collaboration sur les définitions de dashboards ; une sauvegarde applicative classique (configuration des datasources, permissions, plugins installés) reste nécessaire pour une reprise après incident complète.

    Le clustering d’annotations change-t-il le comportement existant ?

    C’est une fonctionnalité passée en GA après une période de preview — elle était déjà testable, elle devient maintenant stable et recommandée en production. Si tu l’avais déjà activée en preview, le comportement ne devrait pas changer radicalement.

    Pour commencer

    Pas besoin de tout basculer d’un coup. Le plus simple pour se faire une idée concrète : choisir un seul dossier de dashboards, le synchroniser avec un dépôt Git existant, et observer comment l’équipe s’approprie le flux de commits avant de généraliser. Les détails techniques complets sont dans l’annonce officielle de la version 13.1 et la documentation dédiée à Git Sync. Et si tu veux remettre à plat ta stack d’observabilité dans son ensemble avant d’ajouter une brique de plus, notre tour d’horizon de Grafana 13, Prometheus 3 et OpenTelemetry reste un bon point de départ.

  • Veeam Backup & Replication 13.1 : ce qui change vraiment pour ta sauvegarde

    Veeam Backup & Replication 13.1 : ce qui change vraiment pour ta sauvegarde

    Veeam a sorti la version 13.1 de Backup & Replication le 29 juillet 2026, et ce n’est pas une mise à jour de confort. Deux fonctionnalités sortent clairement du lot pour qui protège une infrastructure Active Directory ou s’inquiète du chiffrement à long terme, et la liste des hyperviseurs supportés s’élargit enfin au-delà du duo VMware/Hyper-V habituel.

    Restaurer une forêt Active Directory : d’un chantier de plusieurs jours à un assistant guidé

    Si tu as déjà dû reconstruire une forêt AD après un ransomware qui a soufflé les contrôleurs de domaine, tu sais à quel point l’exercice est casse-tête : restaurer le premier DC porteur des rôles FSMO, nettoyer les métadonnées des objets orphelins, remettre le DNS d’aplomb, relancer la réplication dans le bon ordre — tout ça à la main, sous pression, un dimanche soir. Veeam 13.1 automatise cette séquence via un assistant qui guide chaque étape de la récupération de forêt, avec en plus une reconstruction des relations d’objets persistants pour Microsoft Entra ID.

    Veeam ne communique pas de chiffre précis sur le temps gagné — ça dépend trop de la taille de la forêt et de l’état des sauvegardes. Le vrai gain, c’est la suppression des étapes manuelles à risque d’erreur, pas une automatisation à zéro intervention : il faut toujours un administrateur AD aux commandes, mais avec un filet sous les pieds.

    Chiffrement post-quantique : anticiper le « harvest now, decrypt later »

    La 13.1 introduit une cryptographie hybride combinant les algorithmes FIPS classiques avec des mécanismes post-quantiques. L’intérêt n’est pas théorique : la menace dite harvest now, decrypt later consiste à voler aujourd’hui des sauvegardes chiffrées pour les déchiffrer plus tard, une fois qu’un ordinateur quantique suffisamment puissant existera. Pour des données qui doivent rester confidentielles dix ou vingt ans — dossiers RH, contrats, secrets industriels — le chiffrement actuel ne suffit déjà plus à garantir la confidentialité sur cette durée. Les algorithmes post-quantiques standardisés par le NIST (FIPS 203, 204 et 205) sont justement conçus pour résister à ce scénario ; les détails techniques sont sur la page du projet NIST Post-Quantum Cryptography.

    Concrètement, cette fonctionnalité ne te sert à rien si tu sauvegardes des logs applicatifs sans valeur dans six mois. Elle devient pertinente si tu archives des données avec une durée de rétention longue et une sensibilité réelle.

    Les nouveaux hyperviseurs supportés

    Jusqu’ici, Veeam Backup & Replication couvrait essentiellement VMware vSphere, Hyper-V et les principaux clouds publics. La 13.1 ajoute un support natif pour :

    • Citrix XenServer
    • XCP-ng (la variante open source de XenServer)
    • Sangfor aSV
    • Platform9
    • VergeOS
    • KubeVirt, avec un backend de sauvegarde standardisé pour les VM tournant nativement sur Kubernetes

    Le support de KubeVirt mérite une mention à part : c’est la première fois que Veeam couvre un hyperviseur pensé pour tourner à l’intérieur d’un cluster Kubernetes plutôt qu’à côté. Pour les équipes qui migrent progressivement des VM legacy vers une plateforme Kubernetes commune, ça évite de maintenir deux outils de sauvegarde en parallèle pendant la transition.

    Application Backup Repository : une cible NFS immuable prête à l’emploi

    Autre ajout notable : l’Application Backup Repository transforme un dépôt durci en cible NFS immuable gérée nativement, sans configuration manuelle du stockage sous-jacent. Couplé à Veeam Snap Scale, pensé pour protéger des bases de données volumineuses — au-delà de 100 To — ça cible clairement les environnements avec de grosses bases transactionnelles plutôt que l’infra PME classique.

    Faut-il migrer maintenant ?

    Pas systématiquement. Si ton infra tourne uniquement sur VMware vSphere ou Hyper-V classique, sans forêt AD critique à restaurer en urgence ni base de données de plusieurs dizaines de téraoctets, rien n’oblige à migrer dans la semaine — autant attendre le prochain patch cumulatif, comme d’habitude avec Veeam. En revanche, si tu protèges une forêt AD sensible, si tu viens de déployer un des hyperviseurs listés ci-dessus, ou si la rétention longue durée de données sensibles fait partie de tes contraintes, la mise à jour vaut largement le détour.

    FAQ

    Faut-il une nouvelle licence pour passer à la VSA (Veeam Software Appliance) ?

    La VSA s’appuie sur le modèle de licence Veeam Universal License (VUL) déjà en place pour les déploiements récents. Si tu es encore sur un ancien modèle de licence par socket ou par instance, vérifie ta compatibilité avant de basculer — c’est le genre de détail qui bloque une migration plus souvent qu’on ne le pense.

    Le chiffrement post-quantique est-il activé par défaut ?

    Non, et ça se comprend : activer un chiffrement hybride FIPS + post-quantique par défaut pour tout le monde aurait un coût de calcul inutile pour l’immense majorité des sauvegardes. C’est une option à activer consciemment sur les jobs qui en ont vraiment besoin.

    Puis-je tester la récupération de forêt AD sans attendre un vrai incident ?

    Oui, et c’est même fortement recommandé : fais un exercice de restauration en labo avec une forêt de test avant d’en avoir besoin en production. Un assistant guidé réduit le risque d’erreur manuelle, mais ne remplace pas la familiarité avec la procédure le jour où ça compte vraiment.

    Pour aller plus loin

    Avant toute mise à jour en production, prends le temps de relire les notes de version officielles de la 13.1 et l’annonce de la Veeam Community pour les correctifs spécifiques à ton environnement. Et si ta stratégie de sauvegarde n’a pas encore de volet immuabilité, ça reste la base avant de s’intéresser au post-quantique — voir notre article sur la règle 3-2-1-1-0 face aux ransomwares, et pour ceux qui sauvegardent déjà vers Azure, le point sur Veeam Data Cloud Vault.

  • Azure : les retraits de services à ne pas manquer en octobre 2026

    Azure : les retraits de services à ne pas manquer en octobre 2026

    Le 1er octobre 2026, trois choses ont cessé de fonctionner sans prévenir grand monde : la prise en charge de Python 3.10 sur Azure Functions, et deux services Cognitive Services entiers, Azure Anomaly Detector et Azure Personalizer. Pas de bandeau rouge dans le portail qui saute aux yeux, pas d’e-mail individuel pour la plupart des abonnements concernés — juste une ligne de plus dans une page de retraits que personne ne consulte avant que ça morde. Si tu gères de l’infra Azure au quotidien, voici ce qui tombe ce mois-ci, pourquoi c’est facile à rater, et comment vérifier en dix minutes si tu es concerné.

    Ce qui a déjà basculé le 1er octobre

    Quatre retraits sont entrés en vigueur le même jour, sans lien entre eux si ce n’est le calendrier :

    • Azure Functions : le runtime Python 3.10 n’est plus supporté. Les fonctions existantes continuent de tourner, mais sans correctif de sécurité ni support Microsoft — ce n’est pas une coupure immédiate, c’est une dette qui s’accumule silencieusement.
    • Azure Cognitive Service — Anomaly Detector : service retiré intégralement. Impossible de créer une nouvelle ressource, et les ressources existantes cessent de répondre.
    • Azure Cognitive Service — Personalizer : même sort. Si tu t’en servais pour un moteur de recommandation, il faut basculer vers un modèle sur mesure ou un service Azure AI Foundry équivalent — il n’existe pas de migration automatique.
    • Azure SQL Database : la génération de calcul Fsv2 n’est plus proposée pour les nouvelles bases ni les mises à l’échelle.

    Rien de tout ça n’empêche ton infra de tourner aujourd’hui. C’est justement le piège : un retrait de service Azure est rarement un arrêt brutal, et c’est pour ça qu’il finit dans la colonne « on verra plus tard » jusqu’à ce qu’un audit de sécurité ou un ticket de support bloqué le remette sur la table.

    Le 13 octobre, le vrai morceau : la fin des comptes de stockage historiques

    C’est le retrait le plus susceptible de te concerner sans que tu le saches. Les comptes de stockage de type Storage (dits « legacy Blob ») et General-Purpose v1 (GPv1) — les tout premiers formats de compte de stockage Azure, antérieurs à 2016 — sont retirés à partir du 13 octobre 2026. Ces comptes n’ont jamais eu accès aux fonctionnalités arrivées depuis : gestion du cycle de vie, niveaux Archive, certaines options de redondance zone-redondante. Si tu en as encore en production, ils tournent probablement depuis longtemps sans que personne n’y touche — ce qui est précisément le profil de ressource qu’on oublie de vérifier.

    La commande la plus rapide pour les repérer sur un abonnement :

    az storage account list \
  --query "[?kind=='Storage' || kind=='BlobStorage'].[name,resourceGroup,kind]" \
  -o table

    Si la commande retourne des lignes, il faut planifier une migration vers un compte StorageV2 avant l’échéance — la documentation officielle de migration détaille la procédure, qui se fait sans interruption de service dans la plupart des cas.

    Et le 31 octobre : AKS Arc sur Windows Server 2022

    Dernier point du mois pour ceux qui exploitent des clusters AKS Azure Arc : le SKU Windows Server 2022 n’est plus supporté à partir du 31 octobre. C’est un périmètre plus restreint — essentiellement les environnements hybrides avec des node pools Windows sur Arc — mais si ça te concerne, c’est une mise à jour de node pool à planifier avant la fin du mois, pas après.

    Comment arrêter de se faire surprendre

    La page officielle des mises à jour Azure liste tout, mais personne ne la lit en continu. La bonne surface à surveiller, c’est Azure Advisor : dans l’onglet Fiabilité, le filtre Service Upgrade and Retirement ne remonte que ce qui touche réellement tes ressources déployées, pas la liste générale de tout ce qui se retire dans le monde. C’est documenté dans le guide Advisor sur les recommandations de retrait, qui couvre aussi les retraits à venir en novembre et décembre si tu veux anticiper plus loin.

    Pour un audit plus poussé à l’échelle de plusieurs abonnements, l’outil open source Azure Retirement Impact Analyzer, publié par Microsoft, croise Azure Resource Graph avec la liste des retraits planifiés pour sortir un rapport exploitable — plus pratique qu’un passage manuel abonnement par abonnement.

    On avait déjà vu ce schéma avec le retrait d’Azure Virtual Desktop (classic) : l’échéance était connue des mois à l’avance, affichée dans Advisor, et pourtant une partie des migrations s’est faite dans les derniers jours. Les retraits d’octobre suivent exactement le même calendrier de visibilité — la seule variable, c’est qui prend le temps de regarder avant la date butoir.

    FAQ

    Mes fonctions Python 3.10 vont-elles s’arrêter net le 1er octobre ?

    Non. Elles continuent de s’exécuter, mais sans support ni correctif de sécurité Microsoft. Le risque n’est pas une panne immédiate, c’est de tourner avec un runtime non maintenu pendant que personne ne s’en soucie — jusqu’au jour où une vulnérabilité touche spécifiquement cette version.

    Comment savoir si j’ai encore des comptes de stockage legacy Blob ou GPv1 ?

    La commande Azure CLI donnée plus haut (az storage account list avec le filtre sur kind) les repère en quelques secondes sur un abonnement donné. Pour plusieurs abonnements d’un coup, passe par Azure Resource Graph ou l’outil Retirement Impact Analyzer cité ci-dessus.

    Est-ce que Microsoft prévient individuellement avant un retrait ?

    En général oui, via Azure Service Health, mais seulement si les bons contacts d’administration sont renseignés sur l’abonnement. Ne compte pas uniquement là-dessus : un abonnement avec un contact technique obsolète ou une boîte mail partagée jamais relevée ne recevra l’alerte que dans les faits, pas dans l’intention.

    Que faire si je ne peux pas migrer à temps ?

    Ça dépend du service, mais la règle générale est qu’il n’y a pas de délai de grâce automatique pour la plupart de ces retraits précis. Pour un cas bloquant (migration complexe, dépendance tierce), ouvrir un ticket de support Azure avant l’échéance reste la seule option — après la date, c’est trop tard pour négocier.

    Prochaine étape

    Aucun de ces retraits n’est une surprise de dernière minute : la liste est publique depuis des mois sur la page Azure Updates. Le seul vrai réflexe à prendre, c’est de caler un rendez-vous récurrent — premier lundi du mois, par exemple — pour repasser Azure Advisor sur tes abonnements. Le prochain lot à surveiller tombe le 10 novembre 2026, avec le retrait du modèle in-process pour Azure Functions et la fin du support .NET 8 LTS sur App Service : autant le mettre dans l’agenda maintenant plutôt que de le découvrir à la dernière semaine d’octobre.