Ctrl+Alt+Prod

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

  • Azure DevOps MCP Server : connecte tes assistants IA à tes projets

    Azure DevOps MCP Server : connecte tes assistants IA à tes projets

    Depuis cet été, Azure DevOps ne se contente plus d’orchestrer tes pipelines : il peut aussi répondre directement à tes assistants IA. Le Azure DevOps MCP Server, passé en disponibilité générale le 5 août 2026 pour la version distante puis peu après pour la version locale, donne à des outils comme GitHub Copilot, Visual Studio ou Claude un accès sécurisé à tes work items, tes pull requests, tes builds et ta documentation — sans que tu aies à copier-coller des identifiants d’espace de travail ou à écrire toi-même l’intégration. Si tu géres une organisation Azure DevOps et que tu commences à intégrer des assistants IA dans ton flux de travail quotidien, c’est le genre de brique qui t’évite de réinventer la roue à chaque nouvel outil.

    Dans cet article, tu vas voir ce qu’est concrètement ce serveur MCP, la différence entre la version distante et la version locale, comment l’activer selon ton client IA, et surtout comment il s’intègre dans un modèle de sécurité basé sur Entra ID plutôt que sur des tokens qui traînent dans des fichiers de config.

    Le Model Context Protocol, en deux mots

    Le Model Context Protocol (MCP) est un protocole ouvert qui standardise la façon dont un modèle de langage accède à des outils et des données externes. Concrètement, un serveur MCP expose un ensemble d’actions (lire un work item, lister des pull requests, lancer une recherche dans un dépôt) que n’importe quel client compatible — VS Code avec GitHub Copilot, Claude Desktop, Cursor, etc. — peut appeler de façon structurée, plutôt que de deviner la réponse à partir de son entraînement.

    Pour toi, ça change la nature de la question que tu poses à ton assistant. Au lieu de lui décrire à la main l’état de ton sprint, tu peux littéralement lui demander « récupère les work items de mon sprint en cours, puis identifie ceux qui sont à risque de retard » et obtenir une réponse construite sur tes données réelles, pas sur des suppositions.

    Serveur distant ou serveur local : lequel choisir ?

    Azure DevOps propose deux façons de brancher le MCP Server, et le choix dépend surtout de ton client IA et de la structure de ton organisation.

    Le serveur distant (recommandé par défaut)

    Le serveur distant est un point de terminaison hébergé par Microsoft (transport HTTP en streaming), donc tu n’installes ni n’héberges rien toi-même — Microsoft gère les mises à jour. Il fonctionne nativement avec Visual Studio Code + GitHub Copilot, Visual Studio, Microsoft Foundry, Microsoft Copilot Studio, GitHub Copilot CLI et l’app GitHub Copilot. La configuration tient en quelques lignes dans ton fichier `mcp.json` :

    {
  "servers": {
    "azure-devops": {
      "url": "https://mcp.dev.azure.com/{organisation}",
      "type": "http"
    }
  }
}

    Point d’attention : le serveur distant s’authentifie via Microsoft Entra ID, ce qui suppose que ton organisation Azure DevOps soit adossée à un tenant Entra. Si tu es encore sur une organisation « compte Microsoft » (MSA) sans tenant Entra, ce mode n’est tout simplement pas disponible pour toi.

    Le serveur local

    Certains clients ne supportent pas encore l’enregistrement OAuth dynamique Entra requis par le flux d’authentification du serveur distant — c’est le cas de Claude Desktop, Claude Code, Cursor ou Codex au moment de la rédaction. Pour ces outils, Azure DevOps fournit un serveur MCP local qui tourne sur ta machine et couvre les mêmes catégories d’outils : work items, builds, recherche, dépôts et wiki. C’est un peu plus de friction à l’installation, mais ça te permet d’utiliser le même écosystème d’outils avec l’assistant de ton choix, en attendant que le support OAuth dynamique s’étende.

    Ce que le serveur expose concrètement

    Une fois connecté, ton assistant IA a accès à un ensemble d’outils qui couvrent la majorité de ce que tu ferais manuellement dans le portail Azure DevOps ou en ligne de commande avec l’extension Azure CLI :

    • Consultation et mise à jour de work items (bugs, tâches, user stories)
    • Lecture et gestion des pull requests
    • Statut et déclenchement des builds/pipelines
    • Plans de test
    • Recherche dans le code et la documentation du projet (dont le wiki)

    L’usage typique que Microsoft met en avant, c’est de rester dans ton éditeur ou ton interface de chat IA pour gérer des pull requests et des work items sans changer de contexte — un gain de temps réel si tu passes ta journée à jongler entre ton IDE et le portail web.

    Sécurité : le vrai apport par rapport à un PAT dans un script

    Ce qui rend ce serveur intéressant du point de vue admin/sécurité, ce n’est pas seulement le confort pour les développeurs — c’est le modèle d’authentification. Le serveur distant s’appuie sur Entra ID plutôt que sur des Personal Access Tokens à longue durée de vie stockés dans des fichiers de configuration ou des variables d’environnement. Ça rejoint une tendance de fond côté Azure DevOps cette année : le passage des connexions de service par PAT vers l’authentification par identité de charge de travail (workload identity federation), qu’on a déjà couverte en détail sur l’article sur les service connections fédérées. Le MCP Server suit la même logique : moins de secrets statiques à faire tourner, plus de contrôle centralisé via ton tenant.

    Ceci dit, un assistant IA avec accès à tes work items et tes dépôts reste une surface d’attaque à prendre au sérieux si un prompt malveillant venait à circuler (via un ticket externe, par exemple). Microsoft documente d’ailleurs les bonnes pratiques de sécurité MCP dans sa note de blog sécurité dédiée — à lire avant de brancher ce type d’outil sur une organisation critique, et à mettre en regard des principes qu’on avait évoqués pour sécuriser les identités d’agents IA dans Entra ID.

    Comment démarrer

    Si ton client est déjà supporté nativement (VS Code + Copilot, Visual Studio, Foundry, Copilot Studio), la mise en route se limite à ajouter la configuration `mcp.json` pointant vers `https://mcp.dev.azure.com/{ton-organisation}` et à t’authentifier une première fois via Entra. Si tu utilises un client encore en attente de support OAuth dynamique (Claude Desktop/Code, Cursor, Codex), passe par le serveur local documenté sur la page officielle Microsoft Learn — l’installation prend quelques minutes et te donne accès aux mêmes catégories d’outils.

    Dans les deux cas, commence par un projet non critique le temps de vérifier quels outils tu veux réellement exposer à ton assistant : Foundry, par exemple, te permet de sélectionner un sous-ensemble d’outils plutôt que d’ouvrir l’intégralité de la surface d’API — un réflexe de moindre privilège à appliquer systématiquement.

    FAQ

    Le MCP Server Azure DevOps est-il payant ?

    Non, le serveur lui-même est gratuit. La tarification standard d’Azure DevOps s’applique à ton organisation et aux accès aux données ; selon la plateforme IA que tu utilises, des coûts séparés peuvent s’appliquer côté assistant.

    Puis-je l’utiliser avec une organisation basée sur un compte Microsoft (MSA) plutôt qu’un tenant Entra ?

    Pas avec le serveur distant, qui exige un tenant Entra ID. C’est une des raisons qui peuvent te pousser à migrer ton organisation vers un tenant Entra si ce n’est pas déjà fait.

    Est-ce que ça remplace l’API REST Azure DevOps classique ?

    Non, ça vient en complément. L’API REST reste la brique de base ; le MCP Server ajoute une couche standardisée pensée spécifiquement pour les clients IA agentiques, avec une gestion de contexte et de permissions adaptée à cet usage.

    Pour aller plus loin

    Le MCP Server est un bon indicateur de la direction que prend Azure DevOps : brancher l’IA directement sur les données de ton organisation, avec Entra ID comme socle de confiance plutôt que des secrets épars. Si tu pilotes des pipelines CI/CD et que tu commences à peine à explorer les assistants IA agentiques, c’est probablement l’un des points d’entrée les plus simples à tester cette semaine — sur un projet non critique, avec un sous-ensemble d’outils restreint pour commencer.

  • Sécuriser les identités d’agents IA dans Entra ID : Conditional Access et Lifecycle Workflows

    Sécuriser les identités d’agents IA dans Entra ID : Conditional Access et Lifecycle Workflows

    Tes équipes déploient de plus en plus d’agents IA — agents Copilot, agents personnalisés construits sur Foundry, automatisations agentiques diverses. Et depuis cette année, Microsoft ne les traite plus comme de simples comptes de service génériques : ils ont leur propre statut d’identité dans Entra ID, avec des contrôles de sécurité dédiés. Si tu gères l’identité et les accès dans ton organisation, voici ce qui a changé concrètement, et comment t’en servir pour garder la main sur ces nouveaux comptes.

    Les agents IA ont désormais leur propre compte dans Entra ID

    Un agent IA qui agit pour ton compte — qui lit des données, déclenche des actions, appelle des API — a besoin d’une identité au même titre qu’un utilisateur ou qu’un compte de service. Microsoft formalise ça sous la notion d’« identité d’agent » (agent identity) dans Entra ID : un objet distinct, qui peut être ciblé, gouverné et sécurisé avec les mêmes outils que ceux que tu utilises déjà pour les comptes humains — mais avec quelques mécanismes spécifiques, pensés pour le cycle de vie particulier de ces agents.

    Conditional Access s’étend aux comptes d’agents

    Passée en disponibilité générale en juin 2026, l’extension des protections Conditional Access aux comptes d’agents te permet désormais de :

    • cibler précisément les comptes d’agents, en incluant ou excluant des agents individuels, ou en les regroupant dynamiquement via des attributs de sécurité personnalisés (custom security attributes) ;
    • te protéger contre une activité d’agent à risque, en appliquant des politiques Conditional Access basées sur un score d’Agent Risk, sur le même principe que le risque de connexion pour les utilisateurs ;
    • exiger des appareils conformes pour les agents qui tournent sur des points de terminaison managés, y compris Windows 365 pour les agents, garantissant que les agents ne s’exécutent que depuis des environnements conformes à tes exigences ;
    • appliquer des filtres de plateforme d’appareil et de conditions réseau aux agents, sur la base de l’état de l’appareil et des emplacements réseau de confiance.

    Concrètement, ça veut dire que tu peux désormais écrire une politique Conditional Access du type « tout compte d’agent taggé Team=Finance via attribut de sécurité personnalisé doit s’exécuter depuis un appareil conforme et se voit bloqué si son score de risque dépasse un certain seuil » — exactement le type de granularité que tu appliques déjà à tes comptes utilisateurs à privilèges. La documentation officielle détaille la configuration complète via le centre d’administration Entra ou Microsoft Graph.

    Qui est responsable de l’agent ? Le sponsor et les Lifecycle Workflows

    Un compte orphelin, sans humain responsable, est un vrai risque d’audit — c’était déjà vrai pour les comptes de service classiques, ça l’est encore plus pour des agents autonomes. Depuis mai 2026, Entra ID Governance permet de gérer le cycle de vie du sponsor d’une identité d’agent directement via les Lifecycle Workflows :

    • chaque identité d’agent doit être rattachée à un sponsor humain, responsable de son accès et de son cycle de vie ;
    • si ce sponsor quitte l’organisation, le parrainage de l’agent est automatiquement transféré à son manager, sans intervention manuelle ;
    • les workflows incluent des tâches de notification aux co-sponsors et aux managers en cas de changement imminent de sponsor.

    Résultat : tu ne te retrouves jamais avec un agent qui continue d’accéder à des ressources sensibles alors que la personne qui en était responsable a quitté l’entreprise depuis six mois. Le détail de la mise en place est documenté dans le guide « Agent identity sponsor tasks in Lifecycle Workflows ».

    Mise en pratique : par où commencer

    • Fais l’inventaire des identités d’agents déjà présentes dans ton tenant (centre d’administration Entra ou requêtes Microsoft Graph).
    • Définis des attributs de sécurité personnalisés pour classer tes agents par équipe, criticité ou niveau de risque acceptable — c’est ce qui te permettra de les cibler finement en Conditional Access.
    • Crée une politique Conditional Access dédiée aux comptes d’agents, distincte de celle de tes utilisateurs, avec des exigences adaptées (conformité d’appareil, score de risque).
    • Mets en place un Lifecycle Workflow de gestion de sponsor, pour garantir qu’aucun agent ne se retrouve durablement sans responsable humain identifié.

    FAQ

    Un agent IA a-t-il vraiment besoin d’un compte Entra ID séparé ?

    Dès qu’un agent agit de façon autonome — au-delà d’un simple appel API ponctuel avec les droits de l’utilisateur qui l’invoque — le traiter comme une identité à part entière permet de lui appliquer une gouvernance et une traçabilité propres, plutôt que de le confondre avec un compte de service générique ou avec les droits d’un utilisateur humain.

    Est-ce que ça s’applique uniquement aux agents personnalisés, ou aussi à Copilot ?

    Le modèle d’identité d’agent d’Entra ID est pensé comme un socle commun, que l’agent provienne de Copilot Studio, de Foundry, ou d’un développement interne. Vérifie toujours la documentation spécifique au produit agent que tu utilises, les modalités d’activation peuvent varier.

    Que se passe-t-il si un agent n’a plus aucun sponsor identifiable ?

    C’est précisément ce que le mécanisme de transfert automatique vers le manager du sponsor est censé éviter. En dernier recours, configure une politique d’alerte ou de désactivation automatique pour les agents qui resteraient sans sponsor valide au-delà d’un délai que tu définis.

    Cette extension de Conditional Access vient compléter le changement d’enforcement que l’on avait couvert dans notre article sur Conditional Access et le changement d’enforcement de juin 2026 — les deux s’appuient sur la même mécanique de politiques, appliquée cette fois à une nouvelle catégorie d’identités. Et si tes agents tournent sur des appareils managés, ça vaut aussi le coup de relire notre article sur le bundling Intune dans M365 E3/E5, pour t’assurer que la conformité d’appareil exigée par ces nouvelles politiques est bien couverte par ta licence actuelle.

  • OpenTofu vs Terraform en 2026 : faut-il vraiment migrer ?

    OpenTofu vs Terraform en 2026 : faut-il vraiment migrer ?

    Depuis que HashiCorp a fait basculer Terraform sous licence BSL fin 2023, puis a été racheté par IBM début 2025, la question revient régulièrement en équipe infra : est-ce qu’on migre vers OpenTofu, le fork open source ? Trois ans après le fork, le projet a mûri, gagné des fonctionnalités que Terraform n’a pas, et l’adoption progresse — mais pas de façon uniforme. Voici où en sont vraiment les choses en 2026, sans survendre, pour t’aider à trancher sereinement.

    Pourquoi ce fork existe (rappel rapide)

    La licence Business Source License (BSL) 1.1 adoptée par HashiCorp restreint l’usage commercial de Terraform pour tout produit qui viendrait concurrencer directement les offres HashiCorp (Terraform Cloud, Terraform Enterprise). En réaction, la Linux Foundation a lancé OpenTofu, un fork sous licence réellement open source (Mozilla Public License 2.0), porté par une communauté incluant des poids lourds comme Gruntwork, Spacelift, Scalr, Harness ou env0. Le code source complet est disponible sur le dépôt GitHub officiel du projet. Le rachat de HashiCorp par IBM début 2025 a accéléré le mouvement : plusieurs plateformes majeures, dont GitLab, ont depuis fait d’OpenTofu leur moteur recommandé par défaut pour éliminer toute dépendance à un éditeur propriétaire unique.

    Où en est l’adoption, vraiment, en 2026 ?

    C’est là qu’il faut être honnête plutôt que de reprendre les chiffres les plus flatteurs. Il existe en réalité trois niveaux de lecture bien différents :

    • Sur des plateformes qui ont fait le choix éditorial de pousser OpenTofu par défaut, comme le montre l’analyse de Scalr, la bascule est massive : environ 63 % des exécutions compatibles Terraform tournent désormais sous OpenTofu sur leur plateforme, et jusqu’à 72 % des nouveaux espaces de travail créés.
    • À l’échelle du marché global, les études indépendantes (CodeOxi, avril 2026) situent l’adoption d’OpenTofu autour de 12 % — un chiffre bien plus modeste.
    • Et surtout, le nombre d’organisations ayant réellement terminé une migration complète reste faible, de l’ordre de 5 % selon une étude Firefly.

    Autrement dit : beaucoup d’équipes testent, certaines plateformes poussent fort dans cette direction, mais la migration effective en production reste encore minoritaire. Ce n’est pas une raison pour l’ignorer — c’est une raison de l’évaluer avec les bons critères plutôt que par effet de mode.

    Les vrais avantages techniques d’OpenTofu aujourd’hui

    Indépendamment du débat de licence, OpenTofu a ajouté plusieurs fonctionnalités concrètes que Terraform n’a pas (ou pas encore) :

    • Chiffrement natif de l’état (depuis la v1.7) : le fichier .tfstate peut être chiffré nativement, sans dépendre d’un backend spécifique déjà chiffré côté stockage.
    • Itération de providers avec for_each : tu peux désormais configurer plusieurs instances d’un même provider dynamiquement, utile pour du multi-région ou multi-compte géré en boucle.
    • Le flag -exclude sur plan/apply, pour exclure précisément certaines ressources d’une exécution — le complément logique du -target déjà existant.
    • Support des registres OCI pour distribuer modules et providers, ce qui te permet de réutiliser l’infrastructure de registre de conteneurs que tu as probablement déjà (Azure Container Registry, par exemple).
    • Verrouillage d’état S3 natif, sans dépendance à une table DynamoDB séparée — une simplification bienvenue si ton backend est S3-compatible.

    Exemple de bloc de chiffrement d’état, une fonctionnalité qui n’existe pas nativement côté Terraform :

    terraform {
  encryption {
    key_provider "pbkdf2" "monkey" {
      passphrase = var.state_encryption_passphrase
    }
    method "aes_gcm" "monmethode" {
      keys = key_provider.pbkdf2.monkey
    }
    state {
      method = method.aes_gcm.monmethode
    }
  }
}

    Et côté Azure ? La compatibilité avec les Azure Verified Modules

    Si tu déploies sur Azure, tu utilises probablement déjà (ou tu devrais) les Azure Verified Modules (AVM), les modules IaC officiels maintenus par Microsoft pour Bicep et Terraform. Ces modules sont testés et « vérifiés » spécifiquement pour Terraform — pas explicitement pour OpenTofu. Dans la pratique, grâce à la compatibilité de syntaxe HCL et de format d’état, la très grande majorité des modules AVM Terraform fonctionnent tels quels sous OpenTofu. Mais comme ce n’est pas une garantie officielle de Microsoft, teste systématiquement en environnement non-critique avant de généraliser, surtout sur les modules qui utilisent des fonctionnalités provider récentes.

    Faut-il migrer ? Une grille de décision simple

    • Tu es en infrastructure auto-hébergée, sensible aux coûts de licence, et tu veux éliminer toute dépendance à un éditeur unique : OpenTofu a du sens.
    • Tu utilises fortement Terraform Cloud/Enterprise ou l’intégration HCP : le bénéfice immédiat est plus faible, sauf si tu prévois justement de t’en détacher.
    • Tu débutes un nouveau projet : c’est le moment le plus simple pour trancher, sans dette de migration à gérer.

    Bonne nouvelle technique : la migration reste globalement peu douloureuse. Le format d’état est compatible, la syntaxe HCL ne change pas, et le binaire tofu se comporte comme un remplacement quasi direct de terraform dans la plupart des pipelines CI/CD.

    FAQ

    OpenTofu est-il 100 % compatible avec mes fichiers Terraform existants ?

    Dans l’immense majorité des cas, oui — la syntaxe HCL et le format d’état sont compatibles. Les divergences apparaissent surtout sur les fonctionnalités ajoutées après le fork (chiffrement d’état, registres OCI), qui n’ont pas d’équivalent côté Terraform.

    Puis-je utiliser des providers Terraform officiels avec OpenTofu ?

    Oui, OpenTofu reste compatible avec le protocole de providers Terraform : tu continues à utiliser les providers du registre public sans modification.

    Terraform va-t-il disparaître ?

    Rien ne l’indique. Terraform reste largement utilisé et activement développé par HashiCorp/IBM. La question n’est pas « lequel va survivre » mais « lequel correspond le mieux à tes contraintes de licence et à ton besoin d’indépendance vis-à-vis d’un éditeur ».

    Si le choix de l’outil IaC en général te travaille encore, notre comparatif Terraform ou Bicep en 2026 complète bien cette réflexion côté Azure, et notre guide de migration vers AzureRM 5.0 reste valable que tu restes sur Terraform ou que tu passes à OpenTofu, puisque le provider ne change pas.

  • Ingress-NGINX en fin de vie : ton plan de migration vers la Gateway API

    Ingress-NGINX en fin de vie : ton plan de migration vers la Gateway API

    Si tu gères un cluster Kubernetes en production, il y a de fortes chances que tu utilises encore ingress-nginx pour exposer tes services. Sauf que ce projet, qui équipait historiquement une large majorité des clusters, ne reçoit plus aucun correctif depuis mars 2026 — ni bugfix, ni patch de sécurité. Dans cet article, tu vas comprendre pourquoi ce retrait a eu lieu, ce que Kubernetes propose comme remplaçant officiel (la Gateway API), et comment migrer sans tout casser en prod — avec un cas particulier si tu es sur AKS.

    Pourquoi Ingress-NGINX tire sa révérence

    Le SIG Network de Kubernetes et le comité de réponse aux incidents de sécurité ont annoncé la retraite du projet ingress-nginx fin 2025, avec une fin de maintenance actée en mars 2026. Deux raisons principales ont motivé cette décision :

    • Un risque de sécurité structurel : le mécanisme de « snippets » qui permet d’injecter de la configuration NGINX brute via des annotations a été à l’origine de plusieurs CVE critiques, car il ouvre la porte à de l’injection de configuration depuis des ressources Ingress non fiables.
    • Un projet sous-staffé : malgré des millions de déploiements dans le monde, la maintenance reposait sur une ou deux personnes bénévoles, un rythme intenable face à la charge de sécurité d’un composant aussi exposé.

    Concrètement, depuis mars 2026 : plus de nouvelles releases, plus de correctifs de bugs, et surtout plus de patch en cas de nouvelle faille découverte. Si tu tournes encore dessus, chaque jour qui passe sans plan de migration augmente ton exposition.

    La Gateway API, le successeur « officiel »

    La communauté Kubernetes pousse depuis plusieurs années la Gateway API comme évolution naturelle d’Ingress — certains parlent d’« Ingress 2.0 ». Contrairement à l’API Ingress, pensée comme un objet unique et assez rigide, la Gateway API sépare clairement les responsabilités :

    • le GatewayClass, fourni par le vendeur d’infrastructure (le contrôleur) ;
    • le Gateway, géré par l’équipe plateforme/infra (les points d’entrée réseau) ;
    • les HTTPRoute / GRPCRoute / TCPRoute, gérés par les équipes applicatives (le routage vers leurs services).

    Cette séparation évite justement le problème des snippets : plus besoin d’injecter du texte de config libre, chaque équipe agit dans son périmètre avec des ressources typées. Côté maturité, le canal « standard » de la Gateway API n’a plus connu de changement cassant depuis deux ans, et TCPRoute/UDPRoute ont atteint la disponibilité générale récemment (dernière version stable v1.6.x début septembre 2026), ce qui en fait un socle solide au-delà du simple HTTP/HTTPS.

    Et si tu es sur Azure Kubernetes Service (AKS) ?

    Microsoft aligne AKS sur cette bascule upstream. Si tu utilises le module complémentaire de routage applicatif (application routing add-on) avec NGINX, tu bénéficies de correctifs de sécurité critiques jusqu’en novembre 2026 — mais aucune migration n’est imposée dans l’urgence aujourd’hui. Selon ta configuration actuelle, la documentation officielle AKS recommande un chemin de migration parmi trois :

    • basculer vers l’implémentation Gateway API du module de routage applicatif ;
    • migrer vers Application Gateway for Containers, qui prend en charge à la fois Ingress et Gateway API en natif ;
    • ou, si tu as des besoins avancés (limites de taille de requête, scripts Lua, rate limiting), passer par l’add-on de service mesh Istio avec Gateway API.

    Exemple concret : convertir un Ingress en Gateway API

    Voici la même route exposée d’abord en Ingress classique, puis en Gateway API :

    <!-- Ingress classique -->
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mon-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: monapp.exemple.fr
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mon-app-svc
            port:
              number: 80

    # Équivalent en Gateway API
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: mon-app
spec:
  parentRefs:
  - name: gateway-principale
  hostnames:
  - "monapp.exemple.fr"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: mon-app-svc
      port: 80

    Le Gateway (le point d’entrée réseau lui-même, avec ses listeners et son TLS) est créé une seule fois par l’équipe plateforme, et chaque équipe applicative ne gère plus que ses HTTPRoute.

    Comment migrer sans tout casser

    Une migration Ingress → Gateway API se prépare, elle ne s’improvise pas un vendredi après-midi :

    • Fais l’inventaire de toutes tes ressources Ingress actuelles (annotations comprises — c’est souvent là que se cachent les comportements spécifiques à migrer).
    • Utilise ingress2gateway, l’outil officiel du projet Kubernetes SIG Network qui génère automatiquement les Gateway et HTTPRoute équivalents à partir de tes Ingress existants (support NGINX, Istio, GKE et plusieurs autres contrôleurs).
    • Teste en environnement de staging avant toute bascule en prod, en particulier les comportements liés aux annotations spécifiques à ton contrôleur actuel qui n’ont pas toujours d’équivalent direct.
    • Bascule progressivement, service par service si possible, avec un plan de rollback clair (garder les Ingress en parallèle le temps de valider chaque route).

    FAQ

    Dois-je migrer dans l’urgence ?

    Non, mais tu dois planifier. Si tu es sur AKS avec le module NGINX, tu as un filet de sécurité jusqu’à fin novembre 2026. Au-delà, plus aucun correctif ne sera publié pour ingress-nginx lui-même.

    Qu’est-ce qui casse concrètement si je ne fais rien ?

    Rien ne casse du jour au lendemain — mais toute nouvelle CVE découverte sur ingress-nginx restera non corrigée, ce qui devient vite un point bloquant en audit de sécurité ou en conformité.

    La Gateway API fonctionne-t-elle avec Helm et ArgoCD ?

    Oui, les ressources Gateway et HTTPRoute sont des CRD Kubernetes standard : elles se déploient et se versionnent exactement comme n’importe quelle autre ressource, via Helm, Kustomize ou GitOps (ArgoCD/Flux).

    La bascule vers la Gateway API n’est pas qu’une contrainte de fin de vie à subir : c’est aussi l’occasion de clarifier qui possède quoi entre équipe plateforme et équipes applicatives. Si tu tournes encore sur une version ancienne de Kubernetes, c’est aussi le bon moment pour vérifier ta compatibilité — jette un œil à notre article sur les nouveautés de Kubernetes 1.37. Et si la sécurité de ton cluster en général mérite un tour de vérification, notre guide complet pour sécuriser un cluster Kubernetes reste une bonne base.

  • FinOps pour Kubernetes : attribue tes coûts par namespace avec AKS Cost Analysis

    FinOps pour Kubernetes : attribue tes coûts par namespace avec AKS Cost Analysis

    Un cluster AKS partagé entre cinq équipes, une seule ligne de facturation sur ta note Azure, et personne ne sait qui consomme quoi. Tu reconnais la situation ? C’est le problème numéro un du FinOps appliqué à Kubernetes : la granularité de facturation d’Azure s’arrête au groupe de ressources, alors que la vraie consommation se joue au niveau du pod et du namespace.

    Depuis 2026, Azure propose une réponse native à ce problème avec l’add-on AKS Cost Analysis, construit directement sur le projet open source OpenCost. Dans cet article, tu vas voir comment l’activer, comment lire les données qu’il produit, et comment t’en servir pour bâtir un vrai showback ou chargeback entre équipes.

    Pourquoi Cost Management seul ne suffit pas sur Kubernetes

    Microsoft Cost Management fait très bien son travail au niveau des ressources Azure — VM, disques, load balancers, IP publiques. Le problème, c’est qu’un cluster AKS mutualise ces ressources entre des dizaines d’applications qui n’ont pas le même profil de consommation. Un cluster avec un seul workload, tu peux t’en sortir en lisant directement le coût du groupe de ressources. Dès que plusieurs équipes partagent le même cluster, tu as besoin d’une couche supplémentaire capable de répartir ce coût par namespace, par label, ou par déploiement.

    C’est exactement le rôle de l’add-on de cost analysis : il capture la consommation réelle (CPU, mémoire, stockage, réseau) au niveau du pod, puis réconcilie ces données avec ta facture Azure pour obtenir un coût précis et vérifiable — pas une simple estimation proportionnelle au nombre de pods.

    Activer AKS Cost Analysis

    L’add-on nécessite un cluster en tier Standard ou Premium (pas disponible sur le tier Free). Sur un cluster existant :

    az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-cost-analysis

    Ou dès la création :

    az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --enable-managed-identity \
  --generate-ssh-keys \
  --tier standard \
  --enable-cost-analysis

    Compte entre 8 et 24 heures avant que les premières données remontent dans le portail. Si tu gères plusieurs clusters dans le même abonnement, il faut activer l’add-on sur chacun individuellement — l’agrégation multi-cluster ne se fait qu’au niveau de la vue Cost Management, pas au niveau de la collecte.

    Lire les données : les trois vues Kubernetes de Cost Management

    Une fois l’add-on actif, trois nouvelles vues apparaissent dans Cost Management > Cost analysis :

    • Kubernetes clusters — coût agrégé par cluster, pour une vue macro rapide
    • Kubernetes namespaces — coût agrégé par namespace, tous clusters confondus dans l’abonnement : c’est la vue à utiliser pour du chargeback par équipe si chaque équipe a son namespace
    • Kubernetes assets — coût détaillé par ressource individuelle au sein du cluster

    Ces vues nécessitent un contrat Enterprise Agreement ou Microsoft Customer Agreement — les autres types d’abonnement Azure n’y ont pas accès pour l’instant. Détail important pour la lecture des chiffres : les coûts se répartissent en quatre catégories bien distinctes.

    Type de charge Signification
    Idle charges Capacité disponible mais non utilisée par aucun workload — ton indicateur numéro un de sur-provisionnement
    System charges Capacité réservée par AKS sur chaque nœud pour kubelet et le runtime — incompressible
    Service charges Uptime SLA, Microsoft Defender for Containers, et autres services activés sur le cluster
    Unallocated charges Coûts qui n’ont pas pu être rattachés à un namespace précis

    Un taux d’idle charges élevé est en général le signal le plus actionnable : ça veut dire que tu payes pour de la capacité réservée que personne n’utilise, et que revoir tes requests/limits ou activer le cluster autoscaler te fera économiser plus vite qu’en négociant une remise.

    Aller plus loin : chargeback par équipe avec les tags de node pool

    Pour un vrai modèle de chargeback (facturation interne, pas juste de la visibilité), combine la vue namespace avec des tags posés sur tes node pools à la création :

    az aks nodepool add \
  --resource-group $RESOURCE_GROUP \
  --cluster-name $CLUSTER_NAME \
  --name teamdata \
  --labels team=data cost-center=CC-4471 \
  --node-count 3

    Ces labels remontent dans les rapports personnalisés Cost Management et te permettent de générer un rapport par centre de coût, même quand plusieurs équipes partagent physiquement les mêmes nœuds. Pour la théorie complète du modèle de répartition (showback vs chargeback, gestion des coûts partagés), la documentation officielle Microsoft détaille l’ensemble du sujet : View Kubernetes costs sur Microsoft Learn.

    Le socle open source : OpenCost

    L’add-on AKS Cost Analysis n’est pas une invention propriétaire de Microsoft — il s’appuie sur OpenCost, un projet incubé par la Cloud Native Computing Foundation devenu le standard de facto pour l’allocation de coûts Kubernetes. L’avantage : si tu es multicloud ou si tu gères aussi des clusters hors Azure, la même logique d’allocation (par namespace, deployment, label) s’applique avec les mêmes concepts, ce qui évite de réapprendre un modèle différent par fournisseur.

    Optimiser une fois que tu vois enfin les coûts

    Une fois la visibilité en place, les leviers d’optimisation classiques deviennent enfin actionnables avec des chiffres précis à l’appui : réduire les requests/limits surdimensionnés repérés par un fort taux d’idle charges, activer le cluster autoscaler plutôt que sur-provisionner en prévention, basculer les node pools non critiques vers des VM Spot, et migrer de Container Insights vers Prometheus managé pour réduire la facture Log Analytics. Le guide officiel des bonnes pratiques de coût AKS détaille l’ensemble de ces leviers : Best practices for cost optimization in AKS.

    FAQ

    L’add-on AKS Cost Analysis a-t-il un coût supplémentaire ?

    Non, l’add-on lui-même est gratuit. Tu payes uniquement les ressources normales de ton cluster ; ce que tu gagnes, c’est la granularité de lecture, pas un coût additionnel.

    Ça fonctionne sur un cluster multi-tenant avec des centaines de namespaces ?

    Oui, c’est justement le cas d’usage principal. Plus tu as de namespaces et d’équipes partageant un cluster, plus la valeur de l’outil augmente par rapport à une lecture au niveau du groupe de ressources.

    Que faire si mon abonnement n’est pas Enterprise Agreement ou Microsoft Customer Agreement ?

    Les vues Kubernetes de Cost Management ne seront pas disponibles pour l’instant. Tu peux dans ce cas déployer OpenCost directement en self-hosted sur ton cluster via Helm, sans dépendre du type de contrat Azure.

    Est-ce compatible avec les workloads Kubernetes 1.37 ?

    Oui, aucune contrainte de version côté Kubernetes. Si tu as prévu une montée de version prochainement, vérifie d’abord notre article sur les nouveautés de Kubernetes 1.37 pour anticiper d’éventuels impacts sur tes node pools.

    En résumé

    Le FinOps sur Kubernetes bute presque toujours sur le même mur : une facture globale, aucune granularité. AKS Cost Analysis lève ce mur en quelques heures d’activation, sans agent tiers à maintenir. Si le sujet FinOps t’intéresse plus largement, notre article sur la maîtrise des coûts Azure avec Cost Management complète bien celui-ci côté vision globale de l’abonnement. Prochaine étape logique : active l’add-on sur ton cluster le moins visible côté coûts, et regarde ce que la vue namespace te révèle après 24 heures.

  • OpenTelemetry eBPF Instrumentation (OBI) : l’observabilité zero-code passe en production

    OpenTelemetry eBPF Instrumentation (OBI) : l’observabilité zero-code passe en production

    Tu as déjà vécu ça : un service qui plante en prod, zéro trace, zéro métrique, parce que personne n’a eu le temps d’ajouter le SDK OpenTelemetry avant la mise en prod. L’instrumentation manuelle, c’est la première victime des deadlines. En 2026, un projet change la donne : OpenTelemetry eBPF Instrumentation (OBI) capture traces et métriques directement dans le noyau Linux, sans toucher une ligne de code applicatif.

    Dans cet article, tu vas voir comment OBI fonctionne, comment le déployer en quelques minutes sur une stack existante, et comment Azure propose son propre équivalent côté réseau avec Advanced Container Networking Services. De quoi décider si ça vaut le coup de l’ajouter à ta stack d’observabilité dès maintenant.

    Le problème que l’instrumentation manuelle ne résout jamais complètement

    Même avec les meilleurs SDK OpenTelemetry, l’instrumentation manuelle a trois angles morts récurrents : les services legacy que personne n’ose toucher, les dépendances tierces dont tu ne contrôles pas le code, et le délai entre le déploiement d’un nouveau service et le moment où quelqu’un pense à l’instrumenter. Résultat, ta couverture d’observabilité ressemble à un gruyère — complète là où ça compte le moins, trouée là où un incident finit par arriver.

    C’est exactement le vide que l’approche eBPF comble : une visibilité automatique, appliquée au niveau du noyau, qui ne dépend d’aucune modification de code.

    eBPF et OBI : comment ça marche concrètement

    eBPF (extended Berkeley Packet Filter) permet d’exécuter du code sandboxé directement dans le noyau Linux, sans module noyau custom ni redémarrage. Appliqué à l’observabilité, ça veut dire intercepter les appels système et le trafic réseau d’un processus pour en déduire son comportement applicatif — sans jamais charger le moindre agent dans le processus lui-même.

    De Grafana Beyla à OpenTelemetry eBPF Instrumentation

    Le projet a démarré comme Grafana Beyla, avant d’être donné à la fondation OpenTelemetry et rebaptisé OBI. Cette bascule sous gouvernance CNCF/OpenTelemetry est ce qui a permis l’adoption large qu’on observe depuis le début d’année : les données produites respectent nativement le format OpenTelemetry (OTLP), donc elles s’intègrent directement à n’importe quel backend déjà en place — Grafana, Datadog, Azure Monitor, peu importe.

    Ce qu’OBI capture réellement

    Concrètement, OBI donne accès sans instrumentation à :

    • Des traces distribuées, avec propagation de contexte à travers les appels HTTP et gRPC entre services
    • Les métriques RED (Rate, Errors, Duration) par service et par endpoint
    • Le support d’un nombre croissant de protocoles applicatifs — HTTP, gRPC, et l’expansion 2026 prévoit MQTT, AMQP, NATS, Redis pub/sub et MongoDB

    Déployer OBI en pratique

    Le déploiement le plus simple reste un conteneur sidecar ou un DaemonSet Kubernetes qui s’attache aux processus ciblés via leur cgroup ou leur port d’écoute. Exemple minimal en environnement Kubernetes :

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: obi-instrumentation
  namespace: observability
spec:
  selector:
    matchLabels:
      app: obi
  template:
    metadata:
      labels:
        app: obi
    spec:
      hostPID: true
      containers:
        - name: obi
          image: otel/ebpf-instrument:latest
          securityContext:
            privileged: true
          env:
            - name: OTEL_EXPORTER_OTLP_ENDPOINT
              value: "http://otel-collector.observability:4317"
            - name: OTEL_EBPF_OPEN_PORT
              value: "8080"

    Pas de redéploiement applicatif, pas de sidecar dans chaque pod métier : un seul DaemonSet observe tout le nœud. C’est cette simplicité opérationnelle qui explique l’engouement — tu factures le coût d’adoption une seule fois, pour tout le cluster.

    Le pendant réseau côté Azure : Advanced Container Networking Services

    Si OBI couvre la couche applicative, Microsoft a poussé une approche eBPF équivalente côté réseau pour AKS avec Advanced Container Networking Services (ACNS). Basé sur le data plane Cilium et l’intégration Hubble, ACNS capture la latence DNS, les flux pod-à-pod, les drops de policy réseau et les métriques HTTP au niveau 7 — le tout remonté nativement vers Azure Monitor managed Prometheus et Azure Managed Grafana.

    Si ton budget ne justifie pas l’offre payante ACNS, l’alternative open source de Microsoft, Retina, couvre l’essentiel avec les mêmes fondations eBPF, en self-managed et gratuite — un bon point de départ avant d’envisager la version gérée.

    Offre Coût Gestion Cas d’usage
    ACNS Service Azure payant Entièrement managé Observabilité réseau entreprise, dashboards Grafana avancés
    Network Observability (Azure Monitor) Inclus avec Prometheus managé Managé Monitoring basique niveau nœud/cluster
    Retina OSS Gratuit, open source Self-managed Debug avancé, captures de paquets, multicloud

    Où en est OBI en septembre 2026

    Le projet vise une release stable 1.0 avec quatre priorités affichées pour l’année : la stabilisation du format de configuration avec schémas JSON documentés, l’expansion vers de nouveaux protocoles (dont les SDK cloud AWS, Google Cloud et Azure), une couverture .NET élargie (.NET 8+ ainsi que les frameworks legacy .NET 4.x), et surtout une intégration hybride fluide avec l’instrumentation manuelle existante — pour que tu puisses garder tes SDK OpenTelemetry là où tu en as déjà, et ajouter OBI en complément plutôt qu’en remplacement. Retrouve le détail complet sur la page officielle des objectifs 2026 d’OBI et la documentation OpenTelemetry zero-code.

    Faut-il l’adopter maintenant ?

    Si tu gères déjà une stack Grafana/Prometheus/OpenTelemetry — voir notre tour d’horizon de la stack d’observabilité 2026 — ajouter OBI en complément ne coûte quasiment rien : tu gagnes une couverture de base sur tous les services, y compris ceux que personne n’a instrumentés. En revanche, si ta stack est encore jeune, mieux vaut d’abord poser les fondations OTLP/collector avant d’ajouter une couche eBPF par-dessus, pour éviter d’empiler la complexité.

    La documentation officielle de Grafana Beyla, le moteur historique derrière OBI, reste une excellente ressource pour comprendre les options de configuration fines : Grafana Beyla documentation.

    FAQ

    OBI remplace-t-il complètement l’instrumentation manuelle ?

    Non, et ce n’est pas l’objectif du projet. OBI donne une visibilité de base immédiate ; l’instrumentation manuelle reste utile pour capturer des données métier spécifiques (un identifiant de commande, un montant de panier) que le noyau ne peut pas déduire du trafic réseau.

    Est-ce que ça fonctionne sur Windows ?

    Non, eBPF est une technologie noyau Linux. Pour des workloads Windows, il faut rester sur l’instrumentation SDK classique ou les agents Azure Monitor Application Insights.

    Quel est l’impact en performance ?

    Le surcoût est généralement de l’ordre de quelques pourcents de CPU par nœud, comparable aux sidecars de service mesh classiques — largement compensé par le gain de couverture obtenu sans effort d’instrumentation.

    Est-ce compatible avec Kubernetes 1.37 ?

    Oui, aucune contrainte de version particulière côté Kubernetes lui-même. Si tu viens de migrer, jette un œil à notre article sur les nouveautés de Kubernetes 1.37 pour vérifier qu’aucun changement ne touche tes DaemonSets privilégiés.

    En résumé

    OBI marque un vrai changement de philosophie pour l’observabilité : au lieu de courir après la couverture d’instrumentation service par service, tu pars d’une visibilité complète par défaut, et tu affines ensuite là où c’est utile. Teste-le sur un cluster non critique cette semaine, avec le DaemonSet ci-dessus — tu seras fixé en une heure sur ce qu’il t’apporte réellement.

  • VMware vers Proxmox VE : le guide de migration pas à pas en 2026

    VMware vers Proxmox VE : le guide de migration pas à pas en 2026

    Tu as fait tes calculs après la hausse des licences Broadcom (voir notre article sur VMware, Hyper-V ou Azure Local : comment décider) et tu as choisi Proxmox VE. Bonne nouvelle : la décision est la partie difficile. La migration technique, elle, suit un chemin bien balisé — à condition de connaître les pièges avant de t’y engager plutôt qu’en plein milieu d’un weekend de bascule.

    Ce guide te donne la checklist de préparation, les deux méthodes de migration officielles, et ce qu’il ne faut surtout pas oublier après le transfert.

    Proxmox VE en bref : ce que tu gagnes (et ce que tu perds)

    Proxmox VE reste open source et gratuit à l’usage — aucune licence n’est requise pour faire tourner l’hyperviseur en production. Ce que tu payes, c’est le support et l’accès au dépôt Enterprise (mises à jour testées en profondeur avant diffusion) :

    • Community — 120 €/an par socket CPU, accès au dépôt Enterprise, support communautaire uniquement (forum)
    • Basic — 370 €/an par socket CPU, 3 tickets/an, réponse sous 1 jour ouvré
    • Standard — 550 €/an par socket CPU, 10 tickets/an, réponse sous 4h, support 24/7
    • Premium — 1 100 €/an par socket CPU, tickets illimités, réponse sous 2h, support 24/7

    Toutes les fonctionnalités de Proxmox VE sont identiques quel que soit le niveau choisi — seul le support technique varie. Même au niveau Standard, l’écart avec une licence VMware post-Broadcom reste massif. Le détail des tarifs est sur la page pricing officielle de Proxmox.

    Ce que tu perds en changeant d’écosystème : l’intégration native avec vCenter/NSX si tu es dessus, et l’écosystème de plugins tiers construit spécifiquement pour VMware — à vérifier au cas par cas selon tes outils de supervision, sauvegarde et automatisation actuels.

    Avant de migrer : la checklist de préparation

    La documentation officielle Proxmox est claire sur les points qui bloquent une migration propre si tu ne les anticipes pas :

    • Retire les outils invités spécifiques à VMware (VMware Tools) avant la migration — c’est plus difficile à faire proprement une fois la VM basculée.
    • Documente ta configuration réseau, en particulier les IP statiques : les cartes réseau sont recréées côté Proxmox et devront être reconfigurées.
    • Vérifie les disques chiffrés : un disque chiffré via une Storage Policy VMware ne peut pas être importé tel quel. Le vTPM n’est pas non plus repris automatiquement — à traiter avant la bascule si tu en dépends.
    • Éteins les VM sources avant l’import pour garantir la cohérence des données.
    • Note que les snapshots ralentissent significativement l’import — supprime les snapshots inutiles sur les VM VMware avant de lancer la migration.

    La migration pas à pas

    Méthode 1 — Import automatisé (recommandée)

    Depuis Proxmox VE, l’import direct depuis un hôte ESXi (versions 6.5 à 8.0) est intégré à l’interface web : tu ajoutes ton serveur ESXi comme source, Proxmox liste les VM disponibles, et l’import mappe automatiquement la majorité de la configuration (CPU, RAM, disques). Il existe aussi un mode d’import « à chaud » qui permet de démarrer la VM pendant que le transfert des disques se termine en arrière-plan, au prix d’une performance disque réduite le temps du transfert.

    Pour les migrations en masse, limite-toi à 4 disques de VM importés en parallèle maximum — au-delà, tu risques de saturer les connexions API de l’hôte ESXi source.

    Méthode 2 — Import manuel

    Si l’import automatisé n’est pas adapté à ton cas (version ESXi non supportée, contraintes réseau, etc.), plusieurs alternatives existent :

    • Restauration depuis backup — si ta solution de sauvegarde actuelle a un connecteur Proxmox
    • Clonage disque à disque avec un outil comme Clonezilla
    • Import OVF via l’interface graphique ou en ligne de commande
    • Import direct du disque avec la commande qm importdisk :
    # Convertit et importe un disque VMDK vers le stockage Proxmox
qm importdisk <ID_VM> /chemin/vers/disque.vmdk <nom_stockage>

# Puis attache le disque importé à la VM depuis l'interface
# (Matériel > Ajouter > Disque dur > sélectionner le disque non utilisé)

    La documentation officielle détaille chaque méthode avec ses cas d’usage précis sur le wiki Proxmox — Migrate to Proxmox VE et le wiki dédié à la migration de serveurs.

    Après la migration : ce qu’il ne faut pas oublier

    • Installe les pilotes VirtIO — indispensable sur les VM Windows pour de bonnes performances disque et réseau, et parfois nécessaire pour que la VM démarre correctement après conversion.
    • Reconfigure les interfaces réseau avec les IP statiques documentées avant la migration.
    • Ajuste le mode BIOS/UEFI pour qu’il corresponde à l’environnement source : SeaBIOS pour le mode legacy, OVMF pour l’UEFI — un mauvais choix ici empêche simplement la VM de démarrer.

    Et pour la sauvegarde, une fois sur Proxmox ?

    Proxmox Backup Server (PBS) est le complément naturel — sauvegardes incrémentales dédupliquées, chiffrement côté client, et intégration directe avec Proxmox VE. Quel que soit l’outil choisi, garde en tête les principes qu’on détaille dans notre article sur la règle 3-2-1-1-0 face aux ransomwares : une nouvelle plateforme de virtualisation ne dispense jamais d’une vraie stratégie de sauvegarde immuable et testée.

    FAQ

    Combien de temps dure une migration VMware vers Proxmox ?

    Ça dépend surtout du volume de données à transférer et de ta bande passante de stockage, pas du nombre de VM. Prévois un test sur un sous-ensemble non critique avant de planifier une fenêtre de bascule pour la production.

    Est-ce que je peux migrer sans interruption de service ?

    L’import « à chaud » de Proxmox permet de redémarrer la VM rapidement pendant que le disque continue de se copier en arrière-plan, avec une pénalité de performance temporaire. Pour un zéro-downtime strict, une réplication applicative reste plus fiable qu’un import d’hyperviseur.

    Proxmox gère-t-il le vMotion ou équivalent ?

    Oui, la migration à chaud entre nœuds d’un même cluster Proxmox existe nativement et fonctionne de façon comparable à vMotion, à condition d’avoir du stockage partagé ou répliqué entre les nœuds.

    En bref

    Une migration VMware vers Proxmox réussie tient surtout à la préparation : nettoyer les outils invités, documenter le réseau, traiter les cas particuliers (chiffrement, snapshots) avant de lancer l’import plutôt qu’en pleine bascule. Commence par un import test sur une VM non critique, valide ta checklist post-migration, puis passe à l’échelle progressivement plutôt que de basculer tout ton cluster en une seule fenêtre.

  • Microsoft 365 Backup : ce qu’il couvre vraiment (et ce qu’il oublie) en 2026

    Microsoft 365 Backup : ce qu’il couvre vraiment (et ce qu’il oublie) en 2026

    Depuis que Microsoft 365 Backup est disponible, beaucoup d’admins cochent la case « sauvegarde » dans leur audit de conformité et passent au sujet suivant. Le problème, c’est que cette case ne veut pas dire ce que tu crois. Microsoft 365 Backup protège une partie de ton tenant, à un prix précis, avec des limites de performance bien réelles — et il laisse de côté des pans entiers de ce que tes utilisateurs produisent chaque jour, Teams et Copilot en tête.

    Dans cet article, tu vas voir concrètement ce que couvre l’outil, combien il coûte réellement (avec le détail du calcul), ce qu’il ne sauvegarde pas, et comment construire une vraie stratégie de résilience autour de ces angles morts plutôt que de découvrir le trou le jour où tu en as besoin.

    Microsoft 365 Backup, concrètement

    Microsoft 365 Backup est un service de sauvegarde géré par Microsoft, intégré à l’infrastructure Azure, qui crée des points de restauration pour une partie de ton contenu M365. Contrairement aux stratégies de rétention (conformité, eDiscovery), il vise une vraie restauration opérationnelle : « je veux récupérer ce site SharePoint tel qu’il était il y a trois jours ».

    Ce qu’il protège

    • OneDrive — comptes utilisateurs, y compris la corbeille de premier niveau
    • SharePoint — sites complets
    • Exchange Online — boîtes aux lettres actives et leurs archives en ligne

    Le RPO (Recovery Point Objective) est configurable, avec des intervalles disponibles jusqu’à 10 minutes. Pour l’activer, il te faut un abonnement Azure lié (facturation à la consommation), le rôle Administrateur SharePoint ou Administrateur général — ou le rôle dédié « Microsoft 365 Backup Administrator » qui couvre les trois services d’un coup. Le détail des rôles et de la mise en place est sur la documentation officielle Microsoft Learn.

    Combien ça coûte vraiment

    Le modèle est à la consommation : 0,15 $/Go/mois de contenu protégé. Mais « contenu protégé » inclut plus que ce qu’on imagine spontanément — c’est là que les surprises de facturation arrivent.

    Sont comptabilisés :

    • Le contenu actif (sites SharePoint, comptes OneDrive, boîtes aux lettres actives)
    • La corbeille de second niveau SharePoint/OneDrive
    • Les éléments supprimés et versionnés dans les boîtes protégées
    • Les archives en ligne Exchange

    Exemple donné par Microsoft : un site de 1 Go + 0,5 Go de corbeille second niveau + 1 Go de boîte + 1 Go d’archive = 3,5 Go facturés, pas 1 Go. Bonne nouvelle : la fréquence des points de restauration n’a aucun impact sur le coût, et les coûts Azure sous-jacents sont inclus dans le tarif — pas de facture Azure séparée à surveiller.

    Pour estimer ta facture avant d’activer quoi que ce soit, Microsoft fournit un calculateur Excel et une méthode de collecte via PowerShell :

    #  Tailles SharePoint / OneDrive en direct
Get-SPOSite

# Corbeille de second niveau
Get-PnPRecycleBinItem -SecondStage

# Archives en ligne Exchange
Get-MailboxStatistics -Identity "utilisateur@tondomaine.com" -Archive

    Le détail complet du modèle de facturation, avec le lien vers le calculateur, est sur la page pricing officielle.

    Ce que Microsoft 365 Backup ne sauvegarde pas

    C’est le point qui mérite vraiment ton attention avant de considérer le sujet comme réglé.

    Teams et l’historique Copilot

    Les conversations Teams sont stockées dans Exchange à des fins de conformité, mais leur restauration native dans l’interface Teams elle-même reste immature. Pire : à ce jour, il n’existe pas de solution mature pour restaurer l’historique des échanges avec Copilot — si un utilisateur supprime ou perd ses conversations Copilot, elles ne reviennent pas.

    Power Platform

    Pas de sauvegarde continue pour Power Apps, Power Automate ou Power BI. Les organisations peuvent exporter manuellement leurs solutions, mais ça ne remplace pas un vrai modèle de sauvegarde automatisé — c’est une opération ponctuelle, facile à oublier.

    Planner, et la configuration en général

    Les tâches Planner font partie des éléments souvent oubliés dans les audits. Plus largement, tout ce qui est configuration plutôt que contenu — règles de flux de courrier, politiques d’accès conditionnel, paramètres de conformité — n’est généralement pas couvert. Si ta configuration dérive ou qu’une règle est supprimée par erreur, Microsoft 365 Backup ne t’aide pas.

    La limite qu’on oublie : la vitesse de restauration

    Même sur le périmètre couvert, le débit de restauration a un plafond concret : environ 1 à 3 To/heure. Ça semble confortable jusqu’à ce que tu fasses le calcul sur un tenant de taille réelle : pour restaurer 300 To de données, il faut plus de 100 heures. Sur un vrai incident (ransomware, corruption massive), ce chiffre doit rentrer dans ton calcul de RTO (Recovery Time Objective) — pas juste dans ton RPO.

    Comment combler ces angles morts

    Microsoft 365 Backup n’est pas mauvais — il fait bien ce qu’il fait. Le problème, c’est de croire qu’il couvre tout. Une stratégie réaliste en 2026 :

    • Garde la logique 3-2-1-1-0 pour ton PRA global (voir notre article sur la règle 3-2-1-1-0 face aux ransomwares) — M365 Backup peut être une des copies, pas la seule stratégie.
    • Documente ta configuration séparément : exporte régulièrement tes politiques de flux de courrier, tes règles d’accès conditionnel et tes paramètres de conformité en dehors de M365 Backup — un script PowerShell planifié suffit pour la plupart des cas.
    • Évalue une solution tierce pour Teams/Power Platform si ces workloads sont critiques chez toi — le marché des outils spécialisés a mûri sur ce créneau précisément parce que Microsoft ne le couvre pas encore bien.
    • Teste une vraie restauration à l’échelle, pas juste un fichier isolé — c’est le seul moyen de savoir si ton RTO réel tient face au débit de 1-3 To/heure sur TON volume de données.

    FAQ

    Microsoft 365 Backup remplace-t-il un antivirus/EDR ?

    Non, ce sont deux couches différentes. Le backup te permet de revenir en arrière après un incident (ransomware, suppression accidentelle) ; l’EDR sert à détecter et bloquer l’attaque en amont. Les deux sont complémentaires, pas substituables.

    Est-ce que je peux désactiver M365 Backup sur un site pour réduire la facture ?

    Oui, tu ne payes que pour le contenu activement protégé. Si tu retires un site ou une boîte de la protection, le coût se fige à la taille du dernier instantané, puis les données supprimées expirent selon ta fenêtre de rétention et cessent d’être facturées.

    Les conversations Copilot seront-elles un jour sauvegardées nativement ?

    Rien d’annoncé officiellement à ce stade. C’est un point à surveiller si Copilot devient central dans tes usages métier — en attendant, ne compte pas dessus dans ton plan de continuité.

    En bref

    Microsoft 365 Backup coche une vraie case, mais ce n’est qu’une case parmi plusieurs. Avant ta prochaine revue de PRA, vérifie précisément ce qui est protégé chez toi, calcule ton RTO réel avec le débit annoncé, et documente ce qui reste hors périmètre — Teams, Copilot, Power Platform, configuration. C’est ce triage, pas l’activation du service, qui fait la différence le jour où tu en as vraiment besoin.

  • Azure Virtual Desktop (classic) : migre avant le retrait du 30 septembre 2026

    Azure Virtual Desktop (classic) : migre avant le retrait du 30 septembre 2026

    Si ton organisation utilise encore Azure Virtual Desktop (classic), la date à cocher dans ton calendrier est le 30 septembre 2026. Passé ce délai, Microsoft arrête le support de ce modèle de service — celui qui existait avant l’intégration ARM d’Azure Virtual Desktop. Il te reste deux semaines pour migrer proprement ; voici ce qui change, pourquoi c’est important, et comment t’y prendre selon la taille de ton déploiement.

    Pourquoi AVD (classic) disparaît

    Azure Virtual Desktop (classic) — parfois appelé RDmi — est l’ancien modèle de service de bureau virtuel de Microsoft, antérieur à l’intégration native avec Azure Resource Manager. Depuis le 30 septembre 2023, il n’est déjà plus possible d’y créer de nouveaux tenants : seuls les déploiements existants continuaient d’être gérés et supportés. Cette période de transition de trois ans se termine officiellement le 30 septembre 2026, date à laquelle Microsoft retire définitivement le support d’AVD (classic).

    La version actuelle d’Azure Virtual Desktop, elle, s’appuie entièrement sur Azure Resource Manager : tes host pools, groupes d’applications et workspaces deviennent des ressources Azure à part entière, gérables via le portail, Bicep/Terraform ou Azure RBAC — plutôt que via les cmdlets RDInfra propriétaires d’origine.

    Ce que tu perds si tu ne migres pas à temps

    Une fois la date de retrait passée, Microsoft ne garantit plus le support des ressources AVD (classic) restantes. Concrètement : plus d’assistance technique dédiée, plus de correctifs, et un risque de disruption de service pour tes utilisateurs si un composant sous-jacent évolue. Ce n’est pas une bascule automatique côté Microsoft — c’est à toi de migrer avant l’échéance.

    Une exception existe : si ton environnement dépasse 500 groupes d’applications ou couvre plusieurs tenants, tu peux demander une exemption via un ticket de support Azure (type de problème « Tenant creation exemption request »). Ça ne dispense pas de migrer à terme, ça donne juste un délai supplémentaire pour les cas les plus complexes.

    Les deux chemins de migration

    Migration automatique (le cas le plus courant)

    Microsoft fournit un module PowerShell dédié qui recrée automatiquement tes objets de service (tenants, host pools, groupes d’applications) côté ARM. Grandes lignes du processus :

    # Preparer les modules necessaires
Install-Module -Name Microsoft.RDInfra.RDPowershell -RequiredVersion 1.0.3414.0 -Force
Install-Module -Name Az.DesktopVirtualization -Force
Install-Module -Name Az.Resources -Force

# Se connecter aux deux environnements
Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"
Connect-AzAccount

# Lancer la migration via le module de migration dedie
Start-RdsOnboarding -TenantGroupName "<nom-tenant-group>"

    Attention à deux limites documentées par Microsoft : la migration automatique ne fonctionne que pour des ressources créées dans la géographie US, et elle échoue au-delà de 500 groupes d’applications (c’est justement l’un des cas qui justifie une demande d’exemption). Le détail complet de la procédure est dans la documentation officielle de migration automatique.

    Migration manuelle

    Si ton environnement sort du cadre de l’outil automatique (géographie hors US, structure trop complexe, ou tu veux en profiter pour repartir sur une architecture plus propre), la migration manuelle consiste à recréer tes host pools et groupes d’applications directement dans le portail Azure ou en infrastructure as code, puis à rebasculer tes utilisateurs. C’est plus de travail, mais ça te donne l’occasion de nettoyer une architecture historique et d’appliquer les bonnes pratiques actuelles — y compris via une landing zone dédiée, comme on en parlait dans notre article sur les Azure Verified Modules pour tes landing zones.

    Profites-en pour vérifier tes licences

    La bascule est aussi un bon moment pour revoir ton modèle de licensing AVD/Windows 365, surtout si tu as des utilisateurs qui basculent entre bureau virtuel classique et Cloud PC. Les évolutions récentes du bundling M365 E3/E5 changent la donne sur ce terrain — on en détaille les implications dans notre article sur Microsoft Intune et le bundling M365 en 2026.

    Et le client Remote Desktop classique dans tout ça ?

    Ne confonds pas deux échéances distinctes : le retrait d’AVD (classic) côté service, dont on parle ici, et la fin de support du client Remote Desktop pour Windows, déjà effective depuis le 27 mars 2026. Ce client historique a été remplacé par Windows App, l’application unifiée de Microsoft pour se connecter à AVD, Windows 365, Microsoft Dev Box et les postes RDP classiques. Si tes utilisateurs sont encore sur l’ancien client, c’est une deuxième bascule à planifier en parallèle.

    FAQ

    Que se passe-t-il concrètement le 1er octobre 2026 si je n’ai pas migré ?

    Tes ressources AVD (classic) restent en place mais ne sont plus supportées par Microsoft. Aucun correctif, aucune assistance technique dédiée, et un risque réel de disruption si un composant sous-jacent (agent, broker) évolue sans compatibilité assurée avec l’ancien modèle.

    Puis-je demander un délai supplémentaire ?

    Seulement si tu dépasses 500 groupes d’applications ou gères un environnement multi-tenant : dans ce cas, une exemption est possible via une demande de support Azure dédiée.

    La migration automatique a-t-elle un impact pour les utilisateurs finaux ?

    Elle recrée les objets de service côté ARM, mais planifie-la quand même en dehors des heures de forte utilisation et teste-la d’abord sur un host pool non critique — Microsoft documente des cas où une intervention manuelle reste nécessaire après la migration automatique.

    En résumé

    Il te reste deux semaines pour migrer d’Azure Virtual Desktop (classic) vers la version actuelle avant le retrait de support du 30 septembre 2026. Commence par vérifier si ton environnement est éligible à la migration automatique, prépare une fenêtre de test, et profite de la bascule pour revoir ton architecture et tes licences plutôt que de migrer à l’identique dans l’urgence.

  • RDS en panne après les mises à jour de septembre 2026 : le correctif d’urgence pour Windows Server

    RDS en panne après les mises à jour de septembre 2026 : le correctif d’urgence pour Windows Server

    Si tu gères des serveurs RDS (Bureau à distance) sous Windows Server 2019, 2022 ou 2025, tu as peut-être passé une mauvaise semaine mi-septembre. Les mises à jour du Patch Tuesday du 8 septembre 2026 ont introduit une régression sérieuse : connexions qui restent bloquées, sessions impossibles à fermer proprement, et dans les cas les plus sévères, des serveurs qu’il fallait redémarrer à froid pour retrouver un état stable. Microsoft a mis six jours à publier un correctif d’urgence. Voici ce qu’il s’est passé, comment vérifier si tu es concerné, et surtout comment appliquer le correctif sans attendre le prochain cycle de mises à jour.

    Ce qui s’est cassé avec le Patch Tuesday de septembre

    Les mises à jour de sécurité du 8 septembre 2026 ont touché trois versions de Windows Server :

    • Windows Server 2019 — KB5122876
    • Windows Server 2022 — KB5122882
    • Windows Server 2025 — KB5122871

    Sur les serveurs avec le rôle Remote Desktop Services actif, le symptôme se manifestait progressivement : les connexions fonctionnaient normalement les premières heures, puis se dégradaient. De nouvelles tentatives de connexion restaient bloquées, les sessions existantes n’arrivaient plus à se déconnecter ou à se fermer proprement, et dans les situations les plus critiques, seul un redémarrage forcé du serveur permettait de retrouver un fonctionnement normal. La cause suspectée : un interblocage (deadlock) entre le service RDP et le Local Session Manager — un phénomène déjà documenté sur le forum Microsoft Q&A avant la sortie du correctif officiel.

    Es-tu concerné ?

    Le problème touche spécifiquement les serveurs qui exposent le rôle RDS — hôtes de session, connection brokers, passerelles RD Gateway. Si tu utilises Windows Server uniquement pour d’autres rôles (fichiers, contrôleur de domaine, IIS…) sans RDS actif, tu n’es normalement pas impacté par ce bug précis, même si tu as installé les mêmes KB de sécurité. Les postes clients Windows 10/11 ne sont pas directement concernés par le bug RDS serveur, mais ont reçu leurs propres correctifs dans le même lot (voir plus bas).

    Le correctif d’urgence est disponible depuis le 14-15 septembre

    Microsoft a publié des mises à jour hors bande (out-of-band) pour corriger la régression :

    • Windows Server 2019 — KB5129238
    • Windows Server 2022 — KB5129237
    • Windows Server 2025 — KB5129235

    Point important : sur les trois versions serveur, ces correctifs ne sont disponibles que via le Microsoft Update Catalog — pas de déploiement automatique via Windows Update, et pas de distribution native par WSUS sans les importer manuellement. Si tu gères un parc avec WSUS ou Configuration Manager, il faut importer ces KB explicitement.

    Au passage, le même lot corrige deux autres bugs introduits par les mises à jour du 8 septembre : le partage de dossiers Linux via Plan9 sous Hyper-V qui devenait inaccessible, et des soucis audio multicanal sur certains périphériques USB Audio Class 1.0.

    Comment déployer le correctif

    Pour un ou quelques serveurs, le plus rapide est de télécharger le paquet .msu directement depuis le Update Catalog et de l’installer avec DISM :

    Add-WindowsPackage -Online -PackagePath "C:\Patches\windows10.0-kb5129235-x64.msu"
Restart-Computer -Force

    Pour un parc plus large, importe le KB correspondant à chaque version dans WSUS (Update Services > Actions > Import Updates) ou synchronise-le dans Configuration Manager, puis déploie-le en priorité sur tes hôtes RDS avant les autres serveurs.

    Un redémarrage est nécessaire après l’installation pour que le correctif prenne effet — prévois donc une fenêtre de maintenance, surtout si tes hôtes de session hébergent des utilisateurs en horaires décalés.

    Si tu ne peux pas patcher tout de suite

    Entre la découverte du bug le 8-10 septembre et la sortie du correctif le 14-15, plusieurs administrateurs ont documenté des contournements maison — retrait du paquet fautif via DISM, ou cycle de redémarrage régulier du service Local Session Manager pour éviter le blocage complet. Maintenant que le correctif officiel existe, il n’y a plus de raison de s’appuyer sur ces bricolages : ils ne sont pas documentés par Microsoft et peuvent avoir des effets de bord. Priorise le déploiement du correctif officiel, y compris en dérogeant temporairement à ton cycle de patch management habituel vu la criticité du service concerné.

    Éviter que ça se reproduise

    Cet épisode est un bon rappel des bonnes pratiques de déploiement de patchs sur des rôles critiques comme RDS :

    • Teste les mises à jour de sécurité sur un hôte RDS non critique ou un anneau de déploiement restreint avant de les pousser sur l’ensemble du parc.
    • Surveille le tableau de bord Windows Server release health, qui recense les problèmes connus par version et par KB.
    • Si tu veux creuser le volet sécurité de ce Patch Tuesday, notre article sur le Patch Tuesday de septembre 2026 détaille les autres failles corrigées ce mois-ci et comment prioriser leur déploiement.

    FAQ

    Est-ce que ça touche aussi Windows 10 et Windows 11 ?

    Le bug RDS en lui-même est spécifique aux rôles serveur. Mais Microsoft a publié le même correctif d’urgence pour les postes clients : KB5129236 pour Windows 10, KB5129195 pour Windows 11 24H2/25H2, et KB5129194 pour Windows 11 26H1. Sur Windows 11 26H1, la mise à jour est bien distribuée via Windows Update classique — contrairement aux versions serveur.

    Le correctif passe-t-il par Windows Update automatique sur mes serveurs ?

    Non, pour Windows Server 2019, 2022 et 2025, le correctif d’urgence n’est disponible que via le Microsoft Update Catalog. Il faut l’importer manuellement dans WSUS ou ton outil de gestion de patchs.

    Faut-il désinstaller la mise à jour du 8 septembre avant d’installer le correctif ?

    Non, le correctif d’urgence s’installe par-dessus la mise à jour de sécurité initiale : les correctifs de sécurité du 8 septembre restent appliqués, seule la régression RDS est corrigée.

    En résumé

    Si tu gères des hôtes RDS sous Windows Server 2019, 2022 ou 2025 et que tu as installé les mises à jour du 8 septembre 2026, vérifie dès maintenant si le correctif d’urgence (KB5129238 / KB5129237 / KB5129235) est déployé sur ton parc. Ce n’est pas un correctif qui arrivera automatiquement par Windows Update : c’est à toi de le récupérer sur le Update Catalog et de le pousser. Si tu veux creuser aussi le volet Active Directory de ce cycle de patchs, notre article sur les changements sécurité d’Active Directory dans Windows Server 2025 complète bien le sujet.