Ctrl+Alt+Prod

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

  • CVE-2026-69730 : une faille CVSS 9.8 dans Windows DNS Server

    CVE-2026-69730 : une faille CVSS 9.8 dans Windows DNS Server

    Un seul paquet réseau forgé, aucune authentification, aucune interaction utilisateur — et potentiellement une exécution de code sur ton contrôleur de domaine. C’est le résumé de CVE-2026-69730, une faille use-after-free dans le rôle DNS Server de Windows, corrigée lors du Patch Tuesday de septembre 2026. Score CVSS : 9.8 sur 10. Et ce n’était pas un cas isolé ce mois-là.

    CVE-2026-69730 : ce qu’il faut savoir

    La faille (type CWE-416, use-after-free) touche le service DNS Server de Windows. Microsoft l’a publiée le 8 septembre 2026 avec une note d’exploitabilité « Exploitation More Likely » — autrement dit, Microsoft juge qu’une exploitation est probable, sans pour autant confirmer à ce stade une exploitation active constatée dans la nature. Le vecteur d’attaque est réseau, la complexité d’exploitation faible, et aucun privilège ni interaction utilisateur n’est requis côté victime : un attaquant envoie un paquet DNS malveillant, et c’est terminé.

    Le problème de fond, c’est que le rôle DNS Server tourne très souvent sur les mêmes machines que les contrôleurs de domaine — Microsoft le recommande même historiquement pour simplifier la réplication des zones intégrées à Active Directory. Résultat : une faille « DNS », qui pourrait sembler périphérique, ouvre en réalité une porte directe sur l’infrastructure d’identité de l’entreprise. Ce n’est pas LDAP, ce n’est pas Kerberos, mais l’impact potentiel est identique.

    Le plus gros Patch Tuesday de l’histoire de Microsoft

    CVE-2026-69730 n’arrive pas seule. Le lot de septembre 2026 a corrigé 964 CVE au total — 104 classées critiques, 860 importantes — ce qui en fait, selon Tenable, le plus volumineux Patch Tuesday jamais publié par Microsoft. Deux failles zero-day distinctes (non liées au DNS) étaient par ailleurs activement exploitées dans ce même lot, ce qui a probablement capté une bonne partie de l’attention médiatique au détriment des failles DNS et Kerberos qu’on détaille ici.

    Le DNS Windows n’a d’ailleurs pas été touché par une seule faille isolée ce mois-là : CVE-2026-69551 (CVSS 8.8), CVE-2026-69813, CVE-2026-69858 et CVE-2026-77505 (CVSS 8.1 chacune) corrigent d’autres vulnérabilités dans le même composant. Si tu administres des DC avec rôle DNS intégré, ce n’est pas un correctif à traiter isolément — c’est un paquet de durcissement à appliquer en bloc.

    Et Kerberos n’est pas épargné non plus

    Dans le même Patch Tuesday, CVE-2026-69676 touche Windows Kerberos : score CVSS 8.8, exécution de code à distance via une attaque par rejeu d’authentification (authentication bypass by capture-replay). Un attaquant disposant d’un accès réseau de bas niveau — pas besoin d’être déjà authentifié sur le domaine — peut en théorie l’exploiter. Microsoft a mis à jour l’avis le 24 septembre 2026, ce qui suggère un ajustement après la publication initiale (périmètre ou détails techniques affinés). Si le sujet Kerberos t’intéresse, on avait déjà couvert la bascule RC4 vers AES sur Kerberos plus tôt ce mois-ci — deux failles différentes, mais le même composant qui continue d’accumuler les correctifs en 2026.

    Comment vérifier ton exposition

    Avant de paniquer sur l’ensemble du parc, commence par identifier où le rôle DNS Server est réellement installé :

    # Sur chaque contrôleur de domaine ou serveur Windows Server
Get-WindowsFeature -Name DNS | Where-Object Installed

# Vérifier le niveau de correctif installé
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

    Si le rôle DNS n’est pas installé sur une machine donnée, cette CVE précise ne la concerne pas — mais vérifie quand même les autres correctifs du même lot (Kerberos notamment, qui touche potentiellement tout DC, avec ou sans DNS).

    Comment patcher sans tout casser

    Rien d’exotique ici : la mise à jour cumulative de septembre 2026 corrige l’ensemble de ces CVE. La vraie question, c’est la rapidité de déploiement. Si ton parc est encore piloté via WSUS, on avait détaillé les limites actuelles de WSUS et les alternatives recommandées par Microsoft (Windows Autopatch pour les postes, Azure Update Manager pour les serveurs) — un contexte qui prend un relief particulier quand le correctif à pousser porte justement sur une CVSS 9.8 touchant l’infrastructure DNS/AD. Pour un DC en particulier, le délai entre « patch disponible » et « patch appliqué » ne devrait jamais dépasser le cycle de maintenance hebdomadaire standard, et certainement pas pour une faille de cette gravité.

    FAQ

    CVE-2026-69730 est-elle activement exploitée ?

    Au moment de la publication par Microsoft, l’éditeur qualifiait l’exploitation de « plus probable » sans confirmer d’exploitation active constatée pour cette CVE spécifique — à distinguer des deux zero-days (autres CVE) confirmés exploités dans le même lot de septembre. Vérifie le MSRC Update Guide pour le statut le plus à jour avant de prioriser ton plan de remédiation.

    Dois-je désactiver le rôle DNS sur mes DC en attendant de patcher ?

    Dans la grande majorité des environnements Active Directory, non — le DNS intégré AD est généralement indispensable au fonctionnement normal du domaine (localisation des contrôleurs, réplication). La bonne réponse ici est la rapidité de patch, pas la désactivation du service.

    Cette faille touche-t-elle aussi les serveurs DNS non liés à Active Directory ?

    Oui, tout serveur Windows avec le rôle DNS Server installé est potentiellement concerné, qu’il serve ou non de contrôleur de domaine. Le risque est simplement plus élevé quand DNS et AD DS cohabitent sur la même machine, puisqu’une compromission touche alors directement l’annuaire.

    En résumé

    Une CVSS 9.8 sans authentification requise sur un service aussi structurant que le DNS mérite un traitement prioritaire, pas une ligne de plus dans un ticket de maintenance mensuel. Si tes contrôleurs de domaine hébergent le rôle DNS — ce qui est le cas de la majorité des déploiements AD classiques — vérifie ton niveau de correctif dès aujourd’hui plutôt que d’attendre la prochaine fenêtre de maintenance planifiée.

    Sources officielles : analyse détaillée de Tenable sur le Patch Tuesday de septembre 2026, résumé et fiche CVE par Action1, et le MSRC Update Guide pour le détail officiel par produit et build.

  • PowerShell 7.6.6 : ce qui change dans la dernière mise à jour LTS

    PowerShell 7.6.6 : ce qui change dans la dernière mise à jour LTS

    Le 8 septembre 2026, l’équipe PowerShell a livré trois mises à jour de maintenance le même jour : 7.6.6, 7.5.11 et 7.4.20. Rien d’exceptionnel en soi — ce sont des « patch releases », pas des montées de version majeures. Mais la 7.6.6 embarque un changement qui casse silencieusement certains scripts, et un réglage de sécurité qui mérite qu’on s’y attarde si tu geres des postes sous Windows Defender Application Control. Voici ce qui change concrètement, et ce qu’il faut vérifier avant de déployer.

    Ce qui a changé dans PowerShell 7.6.6

    La version tourne sur .NET 10.0.12. Trois modules embarqués ont été mis à jour :

    • Microsoft.PowerShell.PSResourceGet passe en v1.2.0
    • PSReadLine passe en v2.4.5
    • Microsoft.PowerShell.ThreadJob passe en v2.2.0

    Tu peux vérifier ta version installée avec :

    $PSVersionTable.PSVersion
Get-Module -ListAvailable Microsoft.PowerShell.ThreadJob, PSReadLine, Microsoft.PowerShell.PSResourceGet

    Le piège ThreadJob : vérifie tes scripts avant de monter en version

    C’est le point qui va en surprendre plus d’un. Le module Microsoft.PowerShell.ThreadJob remplace désormais l’ancien module ThreadJob. La cmdlet Start-ThreadJob continue de fonctionner normalement en usage courant — ce n’est pas elle le problème. Le piège, c’est si un de tes scripts appelle la cmdlet par son nom pleinement qualifié avec l’ancien module :

    # Ancien appel qualifié — ne résout plus rien après la mise à jour
ThreadJob\Start-ThreadJob -ScriptBlock { Get-Process }

# Appel qualifié correct depuis 7.6.6
Microsoft.PowerShell.ThreadJob\Start-ThreadJob -ScriptBlock { Get-Process }

    Si tu ne fais jamais d’appel qualifié par module dans tes scripts (la grande majorité des usages), tu n’as rien à changer. Mais si une partie de ton code d’automatisation — modules internes, scripts de déploiement hérités — référence explicitement ThreadJob\Start-ThreadJob, fais un grep -r "ThreadJob\\\\" sur ton dépôt de scripts avant de pousser la mise à jour en production. C’est le genre de breaking change qui ne remonte qu’en prod, trois semaines après le déploiement, quand personne ne se souvient plus avoir mis à jour PowerShell.

    Un nouveau réglage WLDP pour les environnements WDAC

    Si tu administres des postes sous Windows Defender Application Control, la 7.6.6 ajoute la prise en charge du paramètre EnableFileOnlyEntry dans la Windows Lockdown Policy (WLDP). Ce réglage fait suite à un correctif livré dans la version précédente (7.6.5, 14 août 2026) qui corrigeait un comportement incohérent du dot-sourcing (pwsh -File) pour les fonctions avancées signées sous WDAC. Autre ajout lié : un repli (fallback) vers AppLocker après l’appel à WldpCanExecuteFile, pour les environnements où WDAC n’est pas la seule couche de contrôle d’exécution en place.

    Si WDAC n’est pas ton quotidien, tu peux ignorer ce point sans arrière-pensée — il ne change rien au comportement par défaut.

    Autres changements à noter

    Trois correctifs plus discrets, mais qui valent d’être connus si tu tombes dessus en debuggant :

    • WildcardPattern.Escape échappe désormais correctement les accents graves isolés (un bug qui affectait les chemins ou motifs contenant un seul backtick)
    • Le paramètre -ChildPath de Join-Path accepte maintenant un tableau de chaînes (string[]) plutôt qu’une seule chaîne — rétrocompatible pour un usage simple, mais à connaître si tu scriptes la construction de chemins dynamiquement
    • Les espaces en fin de nom de source d’événement sont désormais supprimés automatiquement (évite des entrées de journal d’événements mal formées)

    Pourquoi trois versions sorties le même jour ?

    PowerShell maintient plusieurs branches en parallèle, chacune alignée sur un cycle de support .NET différent : 7.4 est une branche LTS (Long Term Support) construite sur .NET 8, 7.5 une branche STS (Standard Term Support, cycle de support plus court) sur .NET 9, et 7.6 — la branche courante — vient de basculer sur .NET 10. Microsoft livre les correctifs de sécurité et de maintenance sur les trois branches actives simultanément plutôt que de forcer une montée de version majeure à chaque patch. Concrètement, si tu es encore en 7.4 pour des raisons de stabilité en production, tu bénéficies des mêmes correctifs de fond sans devoir sauter sur 7.6.

    FAQ

    Dois-je mettre à jour immédiatement vers 7.6.6 ?

    Si tu es déjà sur la branche 7.6, oui, sans urgence particulière — c’est un patch release, pas une version majeure avec son lot d’incertitudes. Vérifie juste l’usage de ThreadJob\Start-ThreadJob qualifié dans ton code avant de déployer à grande échelle.

    Je suis encore en PowerShell 7.4, dois-je migrer vers 7.6 ?

    Pas forcément. 7.4 reste une branche LTS activement maintenue (7.4.20 est sortie le même jour). Migre vers 7.6 si tu as besoin des nouveautés spécifiques à cette branche, pas uniquement pour suivre le numéro de version le plus récent.

    Le changement ThreadJob va-t-il casser Invoke-Command ou les jobs en arrière-plan classiques ?

    Non. Ce changement concerne uniquement le module ThreadJob et la cmdlet Start-ThreadJob utilisée en mode qualifié. Les jobs PowerShell standards (Start-Job, Invoke-Command -AsJob) ne sont pas concernés.

    En résumé

    Une mise à jour de maintenance sans drame, à condition de vérifier un seul point avant de la déployer en masse : les appels qualifiés à ThreadJob\Start-ThreadJob dans ton code existant. Le reste — modules à jour, réglage WDAC pour qui en a besoin, corrections mineures — s’installe sans accroc. Si ton parc utilise encore PSGallery par défaut pour ses modules, ça vaut aussi le coup de relire notre article sur le basculement vers Microsoft Artifact Registry, qui touche directement PSResourceGet mis à jour dans cette même release.

    Pour la vue d’ensemble des évolutions attendues sur PowerShell, OpenSSH et DSC v3 cette année, on avait détaillé la feuille de route 2026 de Microsoft — la 7.6.6 s’inscrit dans cette continuité, pas comme une rupture.

    Source officielle pour le détail complet des correctifs : What’s New in PowerShell 7.6 (Microsoft Learn) et le changelog complet sur le dépôt GitHub PowerShell/PowerShell.

  • GitHub Actions : tes runs et logs s’effacent plus vite depuis le 1er octobre

    GitHub Actions : tes runs et logs s’effacent plus vite depuis le 1er octobre

    Depuis le 1er octobre 2026, tes checks, exécutions de workflow et statuts GitHub Actions ne vivent plus indéfiniment : ils suivent désormais la même politique de rétention que les artefacts et les logs. Si tu n’as jamais touché à ce réglage, la limite par défaut tombe à 90 jours — et pour les dépôts publics, c’est un plafond dur qu’aucune configuration ne permet de dépasser.

    Ce qui a changé le 1er octobre

    Avant ce changement, les checks, les runs de workflow et les statuts créés par Actions (et par des applications tierces) pouvaient rester visibles plus de 400 jours, indépendamment du réglage de rétention des artefacts et des logs. GitHub a annoncé l’alignement de ces trois types de données sur cette même politique le 27 août 2026, avec une bascule confirmée effective le 1er octobre. Le paramètre dans les réglages du dépôt a d’ailleurs été renommé pour refléter ce périmètre élargi : il s’appelle désormais « Check, workflow run, status, artifact and log retention » plutôt que de ne mentionner qu’artefacts et logs.

    La raison donnée par GitHub est double : simplifier l’administration (un seul réglage à surveiller au lieu de plusieurs politiques implicites) et réduire la facture de stockage pour les dépôts qui, sans le savoir, conservaient des données bien au-delà de ce qu’ils avaient configuré pour les artefacts.

    Les chiffres à retenir

    La rétention se configure à trois niveaux — dépôt, organisation, entreprise — chacun pouvant resserrer mais jamais dépasser le plafond fixé au niveau supérieur. Deux chiffres à garder en tête : 90 jours par défaut, et 90 jours de plafond absolu pour les dépôts publics, quel que soit le réglage souhaité au niveau dépôt. Un dépôt privé peut viser plus large si son organisation l’autorise, un dépôt public open source non.

    L’impact concret pour toi

    Deux conséquences directes. D’abord, côté conformité et audit : si tu t’appuies sur l’historique des checks ou des statuts de commit comme preuve qu’une PR a bien passé tes contrôles qualité à une date donnée, cette preuve disparaît désormais au bout de 90 jours sauf configuration explicite plus large. Ensuite, côté facturation : artefacts et logs comptent dans le stockage Actions facturable, donc un repository qui conservait ses données plus longtemps que prévu par erreur devrait voir sa facture de stockage baisser mécaniquement.

    Ce qui est supprimé ne revient pas. GitHub est explicite là-dessus : les enregistrements qui dépassaient déjà la période configurée au moment de la bascule ont été nettoyés automatiquement, sans fenêtre de rattrapage.

    Comment vérifier et ajuster ta configuration

    Le réglage se trouve dans Settings > Actions > General de chaque dépôt (ou au niveau organisation/entreprise pour un contrôle centralisé), documenté sur la page officielle Managing GitHub Actions settings for a repository. Trois réflexes avant de passer à autre chose :

    • Vérifie la rétention actuellement configurée sur tes dépôts critiques — beaucoup d’équipes n’y ont jamais touché depuis la création du dépôt.
    • Si tu as besoin de conserver une preuve d’exécution au-delà de 90 jours (audit SOC 2, exigence contractuelle), augmente la rétention jusqu’au plafond autorisé par ton organisation, ou exporte régulièrement les données vers un stockage externe via l’API Actions.
    • Pour un dépôt public qui doit prouver sa conformité sur le long terme, ne compte plus sur la rétention native : archive toi-même les résultats de checks importants (par exemple via un job qui pousse un résumé signé vers un bucket ou un dépôt séparé).

    FAQ

    Puis-je récupérer des runs déjà supprimés par ce changement ?

    Non. GitHub est catégorique : les enregistrements nettoyés ne sont pas restaurés, qu’ils aient été supprimés avant ou après le 1er octobre.

    Ce changement affecte-t-il les workflows en cours d’exécution ?

    Non, seuls les checks, runs et statuts déjà terminés et dépassant la période de rétention configurée sont concernés.

    Un dépôt privé peut-il dépasser 90 jours de rétention ?

    Oui, si l’organisation ou l’entreprise qui l’héberge autorise une limite plus élevée. Le plafond de 90 jours est strictement réservé aux dépôts publics.

    Ce qu’il reste à faire

    Si ton pipeline s’appuie déjà sur du caching pour accélérer les builds, pense à vérifier en même temps ta configuration cache-mode — les deux réglages touchent au même menu Actions et autant les revoir ensemble. Et si tu n’as pas encore activé les défenses anti-supply-chain sur tes workflows critiques, notre article sur le sujet reste d’actualité. Dans tous les cas, prends dix minutes cette semaine pour ouvrir les réglages Actions de tes dépôts les plus sensibles : la rétention par défaut ne correspond pas forcément à ce que ton équipe pense avoir configuré.

  • ScreenConnect CVSS 9.9 : la faille qui transforme ton outil de support à distance en ver

    ScreenConnect CVSS 9.9 : la faille qui transforme ton outil de support à distance en ver

    Un client de support à distance compromis ne reste pas un problème isolé : il devient le vecteur qui infecte tous les postes qu’il touche ensuite. C’est exactement ce qui s’est passé avec CVE-2026-84869, la faille CVSS 9.9 corrigée début septembre dans ConnectWise ScreenConnect — un des outils RMM les plus utilisés par les MSP et les équipes IT internes pour le support à distance.

    Le vecteur d’attaque, en clair

    Techniquement, il s’agit d’une mauvaise gestion des privilèges combinée à une absence de contrôle d’autorisation (improper privilege management / missing authorization) dans le mécanisme de transfert de fichiers de ScreenConnect. Concrètement : un attaquant qui a accès à une session active — parce qu’il a convaincu un utilisateur d’installer un client ScreenConnect « maison » par ingénierie sociale, par exemple — peut pousser des fichiers vers l’hôte distant et déclencher leur exécution sans confirmation de l’opérateur. Pas de popup, pas de validation manuelle : le fichier arrive et s’exécute.

    Seul le client est concerné, pas les serveurs ScreenConnect. Toutes les versions antérieures à la 26.6.5, publiée le 8 septembre 2026 et listée sur le Trust Center de ConnectWise, sont vulnérables.

    Chronologie du traitement

    Le calendrier est serré, ce qui en dit long sur la gravité perçue par les équipes de sécurité :

    • 8 septembre 2026 — ConnectWise publie le bulletin de sécurité (Priority 1, le niveau le plus élevé de son échelle interne) et la version corrigée 26.6.5.
    • 11 septembre 2026 — la CISA ajoute la faille à son catalogue Known Exploited Vulnerabilities (KEV), aux côtés de deux autres failles activement exploitées.
    • 14 septembre 2026 — expiration du délai de remédiation imposé aux agences fédérales américaines (BOD 22-01) : trois jours ouvrés, signe d’une exploitation déjà massive au moment de l’ajout au KEV.

    Ce que Huntress a vu sur le terrain

    Les équipes de Huntress, citées par Help Net Security, ont documenté plusieurs intrusions construites sur ce même schéma, toutes initiées par de l’ingénierie sociale pour faire installer un client ScreenConnect détourné. Une fois la session active, l’attaque pousse quatre scripts VBScript — nommés sobrement 1.vbs à 4.vbs — chargés de profiler la machine, dissimuler l’activité, effectuer de la reconnaissance système et récupérer des composants supplémentaires. La suite est éloquente : persistance, installation d’instances ScreenConnect additionnelles sur la machine compromise, tunneling réseau, modification des contrôles de sécurité, et dans certains cas du minage de cryptomonnaie.

    Le détail le plus préoccupant pour qui gère un parc multi-sites : les clients modifiés propagent ensuite les mêmes scripts aux nouveaux systèmes qu’ils touchent, créant une diffusion de type ver. Un seul poste compromis par social engineering peut donc contaminer en cascade tout un environnement géré à distance.

    Comment réagir maintenant

    Si ton parc utilise ScreenConnect, l’ordre de priorité est simple :

    • Mettre à jour immédiatement tous les clients vers la version 26.6.5, pas seulement le serveur.
    • Passer en revue les journaux d’audit ScreenConnect des sept derniers jours à la recherche d’entrées RunFiles/RanFiles associées à des processus invités (guest) — c’est la signature directe de cette technique d’exploitation.
    • Chercher spécifiquement des transferts de fichiers .vbs, .js, .ps1 ou .bat initiés hors des opérations de support habituelles.
    • Restreindre les permissions de transfert de fichiers aux seuls utilisateurs qui en ont réellement besoin, plutôt que de les laisser ouvertes par défaut à toute session active.
    • Pour toute machine où une activité suspecte est confirmée, la réimager à partir d’un support fiable — un nettoyage partiel ne suffit pas face à une persistance de ce niveau.

    Si tu es MSP et que ScreenConnect sert à administrer les postes de plusieurs clients, le risque de propagation inter-clients mérite une communication proactive plutôt que d’attendre qu’un incident remonte de lui-même.

    FAQ

    Les serveurs ScreenConnect sont-ils concernés par cette faille ?

    Non, uniquement les clients. Mais la mise à jour des clients reste indispensable sur l’ensemble du parc, pas seulement sur les machines visiblement affectées.

    Un antivirus classique aurait-il bloqué cette attaque ?

    Pas nécessairement au moment du transfert initial : le fichier arrive via un canal de support légitime et sans confirmation utilisateur. La détection repose davantage sur l’analyse des journaux ScreenConnect et le comportement réseau post-compromission que sur la signature du fichier lui-même.

    Comment savoir si mon organisation a déjà été ciblée ?

    Cherche dans tes journaux ScreenConnect toute entrée RunFiles/RanFiles initiée par un compte invité plutôt qu’un opérateur authentifié, sur les sept à trente derniers jours selon ta politique de rétention de logs.

    Et ensuite

    Cette faille s’ajoute à la liste déjà longue des vulnérabilités critiques traitées en urgence ce trimestre — après les failles Cisco, Citrix et Fortinet ajoutées au catalogue CISA KEV mi-septembre et la faille critique GitLab CVSS 10. Le point commun : à chaque fois, l’écart entre divulgation et exploitation active se compte en jours, pas en semaines. Si tu n’as pas encore vérifié la version de tes clients ScreenConnect, c’est le moment de le faire avant de passer à autre chose.

  • Azure Pipelines : la nouvelle page de couverture de code qui change (enfin) la donne

    Azure Pipelines : la nouvelle page de couverture de code qui change (enfin) la donne

    Pendant des années, consulter la couverture de code sur Azure Pipelines voulait dire télécharger un rapport HTML en artefact et le faire tourner en local pour y voir quelque chose de lisible. Depuis le sprint 278, ce détour n’est plus nécessaire : l’onglet Code Coverage a été refondu, avec une navigation par dossier/fichier, un aperçu du code source ligne par ligne et une vraie vue de détail par module. Le déploiement s’étale sur 2 à 3 semaines selon les organisations, donc tu l’as sans doute déjà sous les yeux — ou tu l’auras d’ici peu.

    Ce qui change concrètement

    L’ancien onglet se contentait d’un pourcentage global et d’un lien vers le rapport HTML brut. La nouvelle expérience ajoute trois choses utiles au quotidien : une arborescence dossier > fichier avec le taux de couverture agrégé à chaque niveau, une visualisation du code source où les lignes couvertes, partiellement couvertes et non couvertes sont surlignées directement, et une vue Détails qui permet de filtrer par module et par configuration de build. Le toggle vers l’ancien rapport HTML reste disponible, au cas où tu aurais des scripts ou des habitudes qui en dépendent.

    Formats pris en charge pour profiter de l’expérience complète : Cobertura, JaCoCo, Clover, gcov, pcov et XML générique. Si tes rapports sont en .coverage, .cjson ou .covx, tu gardes l’onglet Code Coverage avec drill-down, mais seulement quand les mappings source sont disponibles — sinon tu restes sur l’ancien comportement.

    Ce qu’il faut pour en profiter

    Rien de nouveau à installer : la tâche Publish Code Coverage Results v2 suffit, et c’est elle qui alimente la nouvelle UI. Les tâches intégrées Visual Studio Test, .NET Core, Ant, Maven, Gulp, Grunt et Gradle savent déjà publier leur couverture dans un format compatible. Si ton pipeline utilise encore la v1 de la tâche, c’est le bon moment pour migrer — la v1 ne déclenche ni la nouvelle expérience ni la diff coverage sur les pull requests.

    La diff coverage sur les pull requests, le vrai gain

    Le point le plus intéressant n’est pas visuel, il est fonctionnel : tu peux maintenant imposer un seuil de couverture minimum sur les lignes modifiées d’une PR, pas sur l’ensemble du dépôt. Ça évite le découragement classique d’un vieux projet à 40 % de couverture globale où personne ne touchera jamais ce chiffre, tout en empêchant que du code neuf parte sans tests. La configuration se fait via un fichier à la racine du dépôt :

    coverage:
  status:
    comments: on              # Off par défaut : poste le détail fichier par fichier en commentaire de PR
    diff:
      target: 60%              # Par défaut 70% : seuil minimum de couverture sur les lignes modifiées

    Un target à 60 % plutôt que 70 % n’a rien d’arbitraire si ton équipe sort d’un legacy peu testé : mieux vaut un seuil réaliste qu’on respecte vraiment qu’un seuil ambitieux qu’on désactive après la première PR bloquée pour de mauvaises raisons.

    Les limites à connaître avant de t’enthousiasmer

    Cette diff coverage sur PR ne fonctionne aujourd’hui que pour Azure Repos — si ton code est sur GitHub avec un pipeline Azure DevOps qui le build, tu n’y as pas accès. Pour le reste, trois plafonds à garder en tête : 10 Go de pièces jointes par build pipeline au-delà desquels rien n’est traité, 7 Mo par fichier HTML au-delà desquels le rapport ne se charge plus dans la vue (télécharge l’artefact à la place), et plus de 100 fichiers modifiés dans une PR qui peut faire rester bloqué le contrôle de couverture — une limite qui va surprendre sur une grosse PR de refactoring. Et si ton pipeline est multi-stage, les résultats de couverture ne sont disponibles qu’une fois l’ensemble du pipeline terminé, pas stage par stage.

    Dernier point pour les projets qui mixent .NET Core et .NET Framework : voir des DLL en double dans la vue est normal, ce n’est pas un bug de la nouvelle expérience.

    FAQ

    Dois-je changer quelque chose dans mon pipeline existant pour voir la nouvelle interface ?

    Non, si tu utilises déjà Publish Code Coverage Results v2 avec un format supporté, la nouvelle vue s’affiche automatiquement dès que le rollout atteint ton organisation.

    La diff coverage va-t-elle bloquer mes PR existantes dès son activation ?

    Seulement si tu configures explicitement azurepipelines-coverage.yml avec une politique de branche associée à ce contrôle. Sans ce fichier, rien ne change dans ton comportement actuel.

    Que se passe-t-il si mon rapport HTML dépasse 7 Mo ?

    La vue HTML intégrée ne le charge pas. Tu dois télécharger l’artefact de rapport pour le consulter en local — vérifie aussi que tu ne publies pas des rapports non minifiés par erreur.

    Pour aller plus loin

    Si tu gères déjà tes agents de build via Managed DevOps Pools, c’est l’occasion de vérifier que tes images incluent bien les bons outils de génération de rapports de couverture (voir notre article sur Managed DevOps Pools). Et si Copilot Code Review tourne déjà sur tes PR (notre article sur sa mise en preview publique), la diff coverage est son complément naturel : l’un relit la qualité du code, l’autre vérifie que les lignes changées sont testées. Configure au moins un seuil réaliste sur tes dépôts Azure Repos actifs cette semaine — le fichier YAML tient en quatre lignes, il n’y a pas de bonne raison d’attendre.

  • bicep docs : la commande qui génère enfin la doc de tes modules Bicep

    bicep docs : la commande qui génère enfin la doc de tes modules Bicep

    Un README de module Bicep périmé, c’est le genre de dette technique dont personne ne parle jusqu’au jour où un collègue déploie avec le mauvais paramètre parce que la doc listait encore l’ancienne valeur par défaut. Jusqu’ici, la seule option sérieuse pour éviter ça était le script PowerShell Set-AVMModule maintenu par l’équipe Azure Verified Modules — efficace, mais pensé pour leur propre dépôt, pas pour ton repo Bicep perso. Depuis le 24 septembre 2026, il existe enfin une réponse native côté CLI : bicep docs.

    Ce que fait la commande

    La commande génère un fichier README.md directement à partir de ton code Bicep, sans que tu aies à écrire la moindre ligne de documentation à la main. Elle extrait et met en forme :

    • les métadonnées du module (nom, description, si tu les as renseignées via metadata) ;
    • la liste des ressources Azure déployées ;
    • un tableau des paramètres avec type, caractère obligatoire ou non, et description ;
    • un tableau des outputs ;
    • les types exportés, variables et fonctions définies dans le module, quand il y en a.

    Elle est disponible dans la Bicep CLI à partir de la version 0.47.16. Vérifie la tienne avec bicep --version avant de te lancer — aucun flag expérimental à activer dans bicepconfig.json, la commande est directement utilisable une fois le binaire à jour.

    L’utiliser au quotidien

    La syntaxe de base ne demande rien de plus que le chemin du fichier :

    bicep docs generate ./main.bicep

    Par défaut, elle écrit un README.md à côté du fichier source. Trois options couvrent la quasi-totalité des cas réels :

    # Afficher le résultat dans le terminal sans écrire de fichier
bicep docs generate ./main.bicep --stdout

# Choisir précisément le nom et l'emplacement du fichier
bicep docs generate ./main.bicep --outfile docs/README.md

# Traiter tous les modules d'un dépôt en une seule commande
bicep docs generate './modules/**/main.bicep'

    Ce dernier exemple avec --pattern est à mon avis le plus intéressant des trois : il transforme la commande en étape de pipeline. Tu peux l’ajouter dans un job GitHub Actions qui tourne à chaque pull request touchant un fichier .bicep, et faire échouer le build si le README généré diverge de celui commité — exactement le même principe qu’un terraform fmt -check, mais pour la documentation.

    Personnaliser le format avec Scriban

    Le README par défaut ne te plaît pas tel quel ? La génération repose sur Scriban, un langage de templating léger déjà utilisé ailleurs dans l’écosystème .NET. Tu peux fournir ton propre modèle via bicepconfig.json :

    {
  "documentation": {
    "template": {
      "file": "templates/readme.scriban"
    }
  }
}

    Et injecter des valeurs supplémentaires dans le template avec --custom-template-value (pour une valeur isolée) ou --custom-template-value-file-path (pour un lot de valeurs depuis un fichier). De quoi, par exemple, ajouter automatiquement un lien vers ton wiki interne ou un badge de statut de pipeline en haut de chaque README généré.

    Le point qu’il ne faut pas perdre de vue

    La fonctionnalité est encore marquée comme expérimentale par Microsoft. Ça ne veut pas dire qu’elle est buguée — elle fonctionne bien dans mes tests — mais que les noms d’options, la structure du bicepconfig.json et le modèle de template par défaut peuvent changer d’une version à l’autre sans garantie de compatibilité ascendante. Si tu l’intègres dans un pipeline de CI, épingle la version de la Bicep CLI que tu utilises plutôt que de pointer vers la dernière disponible, histoire d’éviter qu’un README généré change de structure sans prévenir un lundi matin.

    Pour un module publié publiquement ou partagé entre plusieurs équipes, je recommande clairement d’adopter la commande maintenant : le gain de cohérence dépasse largement le risque de devoir ajuster deux ou trois options dans six mois. Pour un module strictement interne et peu réutilisé, tu peux attendre que la fonctionnalité sorte de son statut expérimental sans rien perdre.

    FAQ

    Est-ce que ça remplace Set-AVMModule pour les modules Azure Verified Modules ?

    Pas entièrement pour l’instant. Le script Set-AVMModule gère aussi la validation de la structure de dossiers et la compilation du template, en plus du README. bicep docs ne fait que la partie documentation, mais le fait nativement, sans dépendance à un script PowerShell externe.

    La commande fonctionne-t-elle aussi via Azure CLI (az bicep) ?

    Au moment de la rédaction, bicep docs n’apparaît pas encore dans la liste des sous-commandes az bicep documentées officiellement. Utilise directement le binaire Bicep CLI autonome en attendant une éventuelle intégration.

    Que se passe-t-il si mon module utilise des imports compile-time ou des types définis par l’utilisateur ?

    Ces éléments activent la génération de code en langageVersion 2.0, ce qui n’empêche pas bicep docs de fonctionner — les types exportés sont justement l’une des sections que la commande documente. On en parlait d’ailleurs en détail dans notre article sur les types définis par l’utilisateur en Bicep.

    Pour aller plus loin

    Si tu gères une bibliothèque de modules Bicep internes sur le modèle des Azure Verified Modules, bicep docs est le genre de petit outil qui change vraiment le quotidien une fois automatisé dans la CI. Notre article sur le passage aux Azure Verified Modules explique pourquoi cette discipline de documentation compte autant que le code lui-même dès que plusieurs équipes consomment les mêmes modules. Installe la dernière Bicep CLI, lance bicep docs generate sur ton dépôt existant, et regarde ce qui en sort — il y a de bonnes chances que tu découvres au passage un paramètre que personne n’avait documenté depuis des mois.

  • Microsoft Entra Connect Sync : le couperet du 30 septembre est tombé, voici comment réagir

    Microsoft Entra Connect Sync : le couperet du 30 septembre est tombé, voici comment réagir

    Le 30 septembre 2026 à minuit, un bon nombre de serveurs Microsoft Entra Connect Sync ont basculé silencieusement dans un état cassé. Pas de crash spectaculaire, pas d’alerte rouge dans le centre d’administration : juste des synchronisations qui s’arrêtent, des comptes qui ne se créent plus côté cloud, et des changements de mot de passe qui ne remontent jamais. Si ton serveur tournait encore sous une version antérieure à 2.5.79.0 hier à cette heure, tu es probablement concerné, même si personne ne t’a encore appelé pour te le dire.

    Ce qui s’est vraiment passé le 30 septembre

    Microsoft a déployé une nouvelle application de service de première partie, baptisée « Microsoft Entra AD Synchronization Service » (ID d’application 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016), visible dans Enterprise Applications du centre d’administration Entra. Cette application sert désormais de pivot d’authentification entre Entra Connect et Microsoft Entra ID — c’est le cœur du durcissement de sécurité annoncé par Microsoft pour la synchronisation hybride.

    Le souci, c’est que seules les versions 2.5.79.0 et ultérieures savent dialoguer avec cette nouvelle application. En dessous, le canal de communication casse net. Microsoft a documenté le changement sans détour : « all synchronization services in Microsoft Entra Connect Sync will fail » pour tout le monde resté sous la barre.

    Le piège : ça a l’air de marcher, au début

    C’est là que ça devient intéressant, et pas dans le bon sens. Les connexions utilisateur continuent de fonctionner un moment, parce qu’Entra ID garde les hash de mot de passe synchronisés précédemment. Tu peux donc avoir l’impression que tout va bien pendant plusieurs jours.

    Sauf qu’en coulisses, le plan de contrôle identitaire est figé. Concrètement :

    • les nouveaux comptes AD créés sur site n’apparaissent plus dans Entra ID ;
    • les changements de groupes et d’attributs restent bloqués côté annuaire local ;
    • le password writeback (si tu l’utilises) ne fonctionne plus dans aucun sens ;
    • un départ collaborateur désactivé sur site ne se répercute plus dans le cloud — ce qui est le scénario qui doit vraiment t’inquiéter côté sécurité.

    Autrement dit : le symptôme le plus visible (les connexions) est justement celui qui te fait croire que tout va bien.

    Vérifier ta version, maintenant

    Deux façons rapides de savoir où tu en es. La première, en PowerShell, directement sur ton serveur Entra Connect :

    (Get-Item "C:\Program Files\Microsoft Azure AD Connect\AzureADConnect.exe").VersionInfo.ProductVersion

    La seconde, plus visuelle : clic droit sur AzureADConnect.exe, Propriétés, onglet Détails. Si le chiffre affiché commence par 2.4.x, 2.3.x ou pire, 1.x — tu es largement sous le seuil et ta synchro est probablement déjà en panne silencieuse depuis le 30 septembre.

    Si tu es déjà en 2.5.79.0 ou au-delà, tu es formellement conforme. Mais je te le dis franchement : ne t’arrête pas là. La version recommandée au moment où j’écris ces lignes est 2.6.92.0 (sortie le 23 septembre 2026), qui corrige plusieurs problèmes connus des versions 2.5.x et 2.6.1.0 — dont une régression de synchronisation assez vicieuse (voir plus bas). Rester au strict minimum légal n’a pas grand intérêt quand la dernière version est disponible gratuitement sur le même centre d’administration.

    Comment remettre ça d’aplomb

    Microsoft propose trois chemins, et le bon dépend surtout de la taille de ton annuaire :

    Mise à niveau automatique

    Si tu es déjà sur une version 2.3.20.0 ou supérieure avec la fonction d’auto-upgrade activée, et que ton installation est en mode Express avec moins de 100 000 objets, la mise à jour peut se faire sans intervention. Vérifie l’état avec Get-ADSyncAutoUpgrade — si elle est désactivée, Set-ADSyncAutoUpgrade -AutoUpgradeState Enabled la réactive.

    Mise à niveau sur place

    Pour un serveur unique, c’est la méthode la plus directe : tu télécharges le nouvel installeur et tu lances la mise à niveau in-place. Le risque principal, c’est l’indisponibilité pendant l’opération — acceptable pour une petite structure, plus délicat pour un environnement critique.

    Migration par serveur de staging (swing migration)

    C’est la méthode à privilégier pour les environnements de production sensibles : tu installes la nouvelle version sur un serveur de staging, tu valides que tout fonctionne, puis tu bascules la promotion vers ce serveur. Zéro coupure si c’est bien mené.

    Dans tous les cas, le fichier d’installation n’est plus disponible nulle part ailleurs que sur le centre d’administration Microsoft Entra, section Gérer > Microsoft Entra Connect. L’ancien lien de téléchargement direct ne sert plus à rien.

    Un bug à surveiller après la mise à niveau

    Si ton fichier miiserver.exe.config a été modifié à un moment donné (ce qui arrive plus souvent qu’on ne le pense, notamment pour des ajustements de timeout), la synchronisation peut échouer après la mise à jour vers 2.5.190.0 ou 2.6.1.0 avec cette exception précise :

    System.IO.FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=6.0.0.1'

    Le correctif tient en quelques lignes XML à ajouter dans la section assemblyBinding du même fichier :

    <dependentAssembly>
  <assemblyIdentity name="System.Diagnostics.DiagnosticSource"
                    publicKeyToken="cc7b13ffcd2ddd51"
                    culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
</dependentAssembly>

    Garde ce bloc sous le coude avant de lancer ta mise à niveau si tu sais avoir touché à ce fichier de config par le passé.

    La prochaine échéance est déjà posée

    Et ce n’est pas fini : Microsoft a déjà fixé le prochain couperet au 7 avril 2027. À cette date, il faudra être en version 2.6.84.0 ou ultérieure ET avoir configuré l’authentification par application (application-based authentication) — l’authentification héritée sera retirée, point final. Si tu viens de faire la mise à jour pour le 30 septembre, autant viser directement une version qui coche aussi cette case plutôt que de refaire l’exercice six mois plus tard.

    Pour ceux qui n’ont pas de contrainte forte à rester sur Entra Connect Sync classique, c’est aussi le bon moment pour regarder Microsoft Entra Cloud Sync, que Microsoft pousse explicitement comme alternative pour les nouveaux déploiements.

    FAQ

    Mon serveur n’affiche aucune erreur, suis-je vraiment concerné ?

    Oui, et c’est justement le piège décrit plus haut. L’absence d’erreur visible dans le Synchronization Service Manager ne garantit rien : vérifie la version exacte avec la commande PowerShell donnée plus haut, pas l’historique des exécutions.

    Puis-je revenir en arrière si la mise à niveau pose problème ?

    Techniquement oui via une sauvegarde de la base ADSync, mais ça te renvoie directement dans la fenêtre de rupture puisque la version précédente ne reparlera plus avec le nouveau service d’application. Mieux vaut sécuriser l’upgrade via une migration de staging que planifier un retour arrière.

    Et si j’utilise Entra Connect pour la fédération AD FS, est-ce impacté différemment ?

    Le durcissement concerne spécifiquement le canal de synchronisation (sync engine), pas la fédération en tant que telle. Mais si AD FS et Entra Connect Sync tournent sur la même infrastructure, un blocage de synchronisation finit presque toujours par se répercuter sur les attributs utilisés par tes règles de claims.

    Ce qu’il faut retenir

    Vérifie ta version aujourd’hui, pas la semaine prochaine. La commande PowerShell prend dix secondes à exécuter, et le coût d’une synchronisation cassée pendant plusieurs jours — comptes fantômes, départs non propagés, mots de passe désynchronisés — est largement supérieur à celui d’une fenêtre de maintenance planifiée. Si ton infrastructure AD mérite un tour de vérification plus large pendant que tu y es, notre guide sur les changements sécurité d’Active Directory dans Windows Server 2025 couvre les autres fronts à surveiller. Et puisque la version 2.6.84.0 ajoute le support des clés d’accès (passkeys) via Windows Web Account Manager, ça vaut aussi le coup de relire notre article sur les passkeys par défaut dans Entra ID pour préparer la suite.

  • Karmada, gradué CNCF : le multi-cluster Kubernetes a mûri

    Karmada, gradué CNCF : le multi-cluster Kubernetes a mûri

    Deux clusters Kubernetes, ça se gère encore à coups de contextes kubectl et de scripts bash. À partir de cinq ou six, avec des équipes différentes qui déploient dessus et des contraintes de placement (proximité GPU, région, conformité), le bricolage s’effondre. C’est le problème que Karmada attaque de front, et le projet vient de franchir une étape qui change la donne côté crédibilité : la graduation CNCF, annoncée le 7 septembre 2026.

    Pour resituer : la CNCF classe ses projets en trois étages — Sandbox, Incubating, Graduated. Graduated, c’est le niveau que Kubernetes lui-même, Prometheus ou Envoy ont atteint : audit de sécurité tiers indépendant passé, gouvernance formalisée avec un comité de direction, adoption du code de conduite CNCF, badge CII Best Practices actif. Ce n’est pas une formalité administrative — c’est la garantie qu’un projet ne dépend plus d’un seul contributeur ou d’une seule entreprise, et qu’il a survécu à un audit externe sur sa sécurité.

    Ce que fait vraiment Karmada

    Karmada (« Kubernetes Armada ») étend l’API Kubernetes standard plutôt que de la remplacer. Concrètement, tes manifests, tes contrôleurs et tes outils existants fonctionnent sans modification sur un control plane Karmada — c’est le point de différenciation qu’ils mettent en avant, et c’est ce qui change la donne comparé à une solution qui t’obligerait à réécrire tes déploiements dans un format propriétaire.

    Le control plane repose sur quatre briques : un karmada-apiserver, un karmada-controller-manager, un karmada-scheduler, et une instance etcd dédiée, isolée de celle de tes clusters membres. Par-dessus, quatre contrôleurs orchestrent la propagation des ressources : Cluster Controller, Policy Controller, Binding Controller et Execution Controller.

    PropagationPolicy et OverridePolicy : les deux API qui font le travail

    Deux CRD custom portent toute la logique métier :

    • PropagationPolicy associe une politique à un ensemble de charges de travail (relation 1:n) et définit les contraintes de placement et de répartition.
    • OverridePolicy permet de réécrire une configuration spécifiquement pour tel ou tel cluster — utile quand un cluster de prod a des limites de ressources différentes d’un cluster de dev, par exemple.

    Un exemple minimal pour distribuer un déploiement nginx sur deux clusters membres :

    apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: example-policy
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member1
        - member2

    Tu peux créer la ressource et la policy dans n’importe quel ordre — Karmada rattrape la propagation dès que les deux existent. C’est un détail, mais ça évite les race conditions bêtes dans un pipeline CI/CD qui applique du YAML en parallèle.

    Installer Karmada : compter cinq minutes, pas une journée

    La commande d’installation la plus directe passe par le plugin kubectl :

    kubectl karmada init

    La documentation officielle annonce environ cinq minutes pour que tous les composants soient prêts dans le namespace karmada-system. Une installation via Helm est disponible aussi, pour les équipes qui préfèrent tout garder dans un chart versionné plutôt que d’exécuter une commande interactive.

    Ensuite, joindre un cluster membre se fait selon deux modes. En mode push, depuis le control plane, avec le kubeconfig du cluster à joindre :

    kubectl karmada join ${MEMBER_CLUSTER_NAME} --cluster-kubeconfig=$HOME/.kube/config

    Ou en mode pull, depuis le cluster membre lui-même, ce qui évite de faire transiter un kubeconfig complet vers le control plane :

    kubectl karmada register 172.18.0.3:32443 --token [token] --discovery-token-ca-cert-hash [hash]

    Le mode pull est clairement préférable dès que tes clusters membres appartiennent à des équipes ou des environnements réseau distincts : tu n’as pas besoin de centraliser des identifiants d’accès à chaque cluster dans le control plane Karmada.

    Karmada vs les alternatives : pas de solution universelle

    Le multi-cluster n’a pas un seul bon outil, il a plusieurs outils pour plusieurs problèmes différents, et Karmada ne prétend pas tout couvrir :

    • Cluster API gère le cycle de vie des clusters eux-mêmes (créer, mettre à jour, détruire) — pas le placement des charges de travail dessus. Les deux se complètent plutôt qu’ils ne s’opposent.
    • Argo CD ApplicationSets ou Rancher Fleet déploient le même manifeste sur plusieurs clusters via une approche GitOps déclarative. C’est plus simple à adopter si ton besoin, c’est « le même état partout », mais tu n’as pas de scheduler dynamique qui décide où placer une charge selon la capacité ou la priorité au runtime.
    • Open Cluster Management (OCM) propose une architecture hub-and-spoke centrée sur l’inventaire de clusters. Le projet reste en phase Sandbox CNCF, donc à un niveau de maturité clairement inférieur à Karmada aujourd’hui.
    • KubeFleet / Azure Fleet Manager est l’option native Microsoft si tu es full-Azure avec plusieurs clusters AKS. Elle s’intègre mieux à l’écosystème Azure (RBAC, Azure Policy), mais elle t’enferme dans ce fournisseur — pas d’option pour orchestrer un cluster GCP ou on-prem à côté.

    Si ton besoin réel est du placement dynamique (répartir une charge selon la capacité GPU disponible, la latence réseau, ou une contrainte de priorité) et que tu veux rester agnostique du fournisseur cloud, Karmada est clairement le bon choix aujourd’hui — c’est littéralement le problème pour lequel il a été conçu. Si tu es mono-cloud Azure et que ton besoin se limite à synchroniser le même état sur trois clusters AKS, Fleet Manager ou même Argo CD ApplicationSets suffiront très bien, avec beaucoup moins de composants à opérer.

    L’adoption, en chiffres

    Le projet revendique plus de 1214 contributeurs issus de 292 organisations et 5600 étoiles sur GitHub. Côté production, Bloomberg, Wellhub, Alibaba Cloud, Huawei, Trip.com, Bilibili, iFLYTEK, Kuaishou, SenseTime et Vivo figurent parmi les adoptants cités. C’est une base plus large que la plupart des projets qui sortent tout juste d’Incubating — et ça pèse dans la décision d’un audit de sécurité : plus il y a d’implémentations réelles qui remontent des bugs, plus vite les trous se bouchent.

    La version 1.19, sortie en même temps que l’annonce de graduation, ajoute une amélioration de la planification multi-composants pensée pour les charges IA, et fait passer la planification basée sur les priorités en beta. Un signal cohérent avec ce qu’on voit ailleurs dans l’écosystème Kubernetes en ce moment — la pression des charges GPU/IA pousse tous les schedulers, y compris multi-cluster, à devenir plus fins sur la priorisation.

    FAQ

    Karmada a-t-il un intérêt pour deux clusters seulement ?

    Rarement. La valeur de Karmada vient du scheduling dynamique et des politiques de répartition à l’échelle. Pour deux clusters, la complexité opérationnelle d’un control plane et d’un etcd dédiés supplémentaires dépasse probablement le bénéfice — un script ou de l’ApplicationSets Argo CD fera l’affaire.

    Le control plane Karmada est-il un point de défaillance unique ?

    Il faut le traiter comme tel et le durcir en conséquence — etcd dédié à sauvegarder, accès API à restreindre. Une panne du control plane Karmada n’arrête pas les workloads déjà déployés sur les clusters membres (ils continuent de tourner normalement), mais elle bloque toute nouvelle propagation ou mise à jour de policy tant qu’elle n’est pas résolue.

    Quelle version de Kubernetes faut-il sur les clusters membres ?

    Karmada s’appuie sur les API Kubernetes standard côté membres, donc toute version supportée en amont convient en pratique. Vérifie la matrice de compatibilité officielle avant une mise à niveau majeure, en particulier si tu mélanges des membres sur des versions très éloignées les unes des autres.

    Et maintenant ?

    Si tu gères déjà plusieurs clusters à la main et que tu sens que ça devient ingérable, la graduation CNCF est un bon moment pour retester Karmada sérieusement — le badge de maturité lève une bonne partie des objections classiques côté sécurité et gouvernance qu’on entend en revue d’architecture. Commence petit : un control plane Karmada avec deux clusters de test, une PropagationPolicy simple, et regarde comment ton équipe s’approprie le modèle avant de l’étendre à la prod.

    Si le sujet qui te bloque aujourd’hui, c’est plutôt la sécurité d’un cluster unique avant même de penser au multi-cluster, notre guide complet pour sécuriser un cluster Kubernetes reste la base à poser en premier. Et si ta contrainte de placement concerne spécifiquement des GPU, notre article sur la Dynamic Resource Allocation se combine bien avec du scheduling multi-cluster Karmada pour répartir les charges IA là où la capacité existe réellement.

  • FOCUS 1.2 dans Azure Cost Management : la fin du bricolage FinOps

    FOCUS 1.2 dans Azure Cost Management : la fin du bricolage FinOps

    Si tu gères des coûts sur plusieurs clouds, tu connais la galère : chaque fournisseur a son propre export, ses propres noms de colonnes, ses propres conventions de date. AWS appelle ça UnblendedCost, Azure CostInBillingCurrency, GCP encore autre chose. Résultat, ton équipe FinOps passe plus de temps à écrire des scripts de normalisation qu’à analyser les vraies dérives de coûts.

    C’est exactement le problème que la FinOps Foundation essaie de résoudre avec FOCUS (FinOps Open Cost and Usage Specification), et Azure Cost Management l’implémente depuis un moment déjà. Sauf que la version disponible aujourd’hui dans Azure — le dataset 1.2-preview — n’est toujours pas exactement calée sur FOCUS 1.2, et la fondation a déjà publié une version 1.3. Voyons ce qui a vraiment changé, ce qui manque encore côté Azure, et comment t’en servir sans te faire piéger par les détails.

    FOCUS, en une phrase

    FOCUS est un schéma de colonnes standardisé pour les données de coûts et d’usage cloud, porté par la FinOps Foundation (elle-même sous l’ombrelle de la Linux Foundation). L’idée : au lieu que chaque fournisseur expose son format maison, tout le monde publie (au moins en option) un export avec les mêmes colonnes — BilledCost, EffectiveCost, ChargePeriodStart, ServiceCategory, etc. Tu écris tes tableaux de bord une fois, ils fonctionnent sur AWS, Azure, GCP et le reste sans réécriture.

    Microsoft, AWS, Google Cloud, Oracle Cloud, Alibaba, Huawei, Tencent, Databricks, Grafana et OVHcloud soutiennent tous FOCUS à des degrés divers. Ce n’est pas un gadget marketing : c’est devenu le format d’échange de référence pour tout ce qui touche aux FinOps hubs, aux outils tiers de gestion de coûts (CloudHealth, Vantage, nOps…) et aux rapports Power BI du FinOps toolkit Microsoft.

    Ce qui change vraiment dans le dataset 1.2-preview d’Azure

    Côté Azure Cost Management, le dataset FOCUS actuel a pour identifiant de schéma 1.2-preview, créé le 13 juin 2025 — toujours en préversion, donc, malgré le nom. Quatre colonnes bougent par rapport à la 1.1 :

    • BillingAccountType : nouvelle colonne, qui indique le type d’entité derrière BillingAccountId (« Billing Account » pour un contrat Enterprise Agreement, « Billing Profile » pour un Microsoft Customer Agreement).
    • SubAccountType : nouvelle colonne, même logique mais pour SubAccountId.
    • InvoiceId : promue au rang de colonne standard (elle vivait avant sous x_InvoiceId, le préfixe réservé aux extensions propriétaires de chaque fournisseur).
    • PricingCurrency : même chose, promue depuis x_PricingCurrency.

    Si tu migrais déjà depuis du FOCUS 1.0 ou 1.0r2, ce sont ces quatre-là qu’il faut ajouter à tes requêtes ou tes modèles Power BI. Attention à une subtilité au passage : 1.0r2 n’est pas une nouvelle version du spec, juste un correctif de format de date (les secondes sont désormais explicites — 2024-01-01T00:00:00Z plutôt que 2024-01-01T00:00Z). Si un de tes parseurs de date casse après une migration, c’est probablement ça.

    Le conformance score n’est pas 100 %, et c’est documenté

    Microsoft publie un rapport de conformité complet, chose que peu de fournisseurs cloud font aussi ouvertement. Le score actuel du dataset Azure FOCUS 1.2-preview est de 94 % : 325 exigences MUST sur 349 sont pleinement supportées, 16 partiellement, 8 pas du tout. Ce n’est pas dramatique pour un usage courant de reporting, mais si tu bâtis un outil qui dépend d’une exigence précise, vérifie-la dans le rapport de conformité complet avant de t’en servir en prod.

    Créer un export FOCUS dans Azure Cost Management

    C’est un des trois modèles proposés dans les exports Cost Management, à côté de « actual » et « amortized ». Les grandes étapes :

    1. Portail Azure → Cost Management → sélectionne le scope voulu → Exports → + Create.
    2. Onglet Basics : choisis le template Cost and usage (FOCUS).
    3. Onglet Datasets : donne un préfixe d’export unique (par exemple focus-prod-2026).
    4. Onglet Destination : type de stockage Azure Blob, compression None, et surtout Overwrite data = Enabled si tu veux un export quotidien qui écrase le fichier de la veille plutôt que d’accumuler des doublons.
    5. Review + Create, puis Run now pour ne pas attendre le prochain cycle planifié.

    Deux limites à connaître avant de te lancer : le scope groupe de gestion (management group) n’est pas supporté pour les exports FOCUS — il faut exporter par abonnement ou par profil de facturation — et si tu exportes au niveau groupe de gestion tout court (avec un autre format), le multi-devise n’est pas géré non plus. Pour une organisation multi-abonnements avec des devises différentes, prévois donc des exports séparés plutôt qu’un export consolidé unique.

    FinOps hubs : l’usage le plus courant de ces exports

    Si tu pousses ces données vers FinOps hubs (Microsoft Fabric ou Azure Data Explorer en backend), le format FOCUS est directement pris en charge et réduit le volume de données à traiter par rapport aux exports actual/amortized bruts. Le coût annoncé démarre à 120 $/mois pour un cluster Data Explorer à un nœud, plus environ 10 $/mois par million de dollars surveillés — ou 5 $/million si tu te passes de Data Explorer/Fabric et que tu restes sur du stockage brut. Pour une boîte qui gère quelques centaines de milliers de dollars de cloud par mois, ça reste anecdotique face au temps gagné à ne plus maintenir un pipeline de normalisation maison.

    FOCUS 1.3 est déjà là — Azure, pas encore

    La FinOps Foundation a annoncé FOCUS 1.3 le 11 décembre 2025 à San Francisco, avec trois apports notables : des colonnes pour l’allocation des coûts partagés (répartir un coût d’infrastructure entre plusieurs conteneurs ou bases de données qui la consomment), un dataset séparé dédié aux engagements contractuels (dates, unités restantes, sans mélanger ça avec les lignes de coût), et un horodatage obligatoire avec indicateur de complétude pour distinguer une ligne définitive d’une ligne encore révisable. AWS a profité de l’annonce pour confirmer la disponibilité générale de son propre export FOCUS 1.2 le même jour.

    Azure, de son côté, en est toujours au dataset 1.2-preview au moment de la rédaction de cet article — pas de date publique communiquée pour un passage en 1.3 ou même en 1.2 stable (non-preview). Concrètement : bâtis tes pipelines FinOps sur FOCUS maintenant, la valeur est déjà là, mais ne prends pas de dépendance dure sur une exigence 1.3 tant que le dataset Azure n’a pas suivi.

    FAQ

    FOCUS remplace-t-il les exports « actual » et « amortized » ?

    Non, les trois coexistent. FOCUS combine en réalité les deux dans un seul fichier (via les colonnes BilledCost et EffectiveCost) et réduit le temps de traitement, mais si un outil tiers attend spécifiquement le format natif Azure, garde l’export correspondant en parallèle le temps de migrer.

    Faut-il du FinOps hubs pour profiter de FOCUS ?

    Non. Tu peux consommer un export FOCUS brut depuis n’importe quel outil qui sait lire du CSV/Parquet — Power BI, un notebook Python, un pipeline dbt. FinOps hubs ajoute juste l’orchestration et le stockage optimisé si le volume le justifie.

    Le scope groupe de gestion, c’est un vrai problème ?

    Ça dépend de ta structure. Si tu as un seul groupe de gestion avec une devise unique, tu peux contourner en exportant à ce niveau avec un autre format puis en convertissant. Si tu es multi-devises, il faut accepter des exports par abonnement — plus de fichiers à gérer, mais des données propres.

    Passe à l’action

    Si tu n’as encore aucun export FOCUS configuré, le geste le plus rentable cette semaine, c’est de créer un export « one-time » sur ton abonnement de prod pour voir concrètement à quoi ressemblent les colonnes chez toi, avant de programmer un export quotidien. Tu verras vite si ton usage actuel (réservations, savings plans, ressources partagées) colle bien aux 94 % de conformité annoncés — ou si tu tombes justement dans les 6 % qui manquent encore.

    Pour aller plus loin sur la maîtrise des coûts Azure au global, notre article sur FinOps en 2026 et Cost Management pose les bases, et si tu gères un cluster Kubernetes, l’attribution des coûts AKS par namespace complète bien ce sujet côté conteneurs.

  • VMware ramène vSphere Standard : ce qu’on sait

    VMware ramène vSphere Standard : ce qu’on sait

    Il y a un peu plus d’un an, on te disait ici même qu’il fallait choisir entre VMware, Hyper-V et Azure Local à cause de la refonte des licences Broadcom. Beaucoup d’équipes ont tranché à ce moment-là, certaines en migrant vers Proxmox VE. Coup de théâtre à VMware Explore Las Vegas, du 31 août au 3 septembre 2026 : Broadcom a laissé entendre que vSphere Standard, l’édition autonome sacrifiée sur l’autel de VMware Cloud Foundation, pourrait faire son retour.

    Avant de rouvrir un dossier que tu pensais clos, voici ce qu’on sait vraiment — et surtout ce qui reste, pour l’instant, une simple déclaration d’intention.

    Ce qui a été dit à Las Vegas

    Paul Turner, Chief Product Officer de VMware chez Broadcom, a reconnu publiquement que l’entreprise avait « corrigé les incitations commerciales qui poussaient les clients vers VCF » et avait parfois « mis trop l’accent sur VCF ». Traduction sans langue de bois : la stratégie de forcer tout le monde vers l’abonnement VMware Cloud Foundation, y compris les petites infrastructures qui n’avaient besoin ni de son SDN ni de son stockage défini par logiciel, a généré assez de friction commerciale pour que Broadcom fasse machine arrière — au moins partiellement.

    La cible annoncée pour ce retour : les environnements tournant autour de 128 cœurs, donc clairement le segment PME/ETI plutôt que les grands comptes déjà engagés sur VCF.

    Ce qu’on sait avec certitude

    • Il s’agirait d’une licence autonome, distincte de l’abonnement VCF actuel.
    • La documentation VMware en vigueur précise déjà que « vSphere Standard et vSphere Enterprise Plus autonomes sont limités à vSphere 8 Update 3 et antérieur » — un rappel que ces éditions existent toujours contractuellement, juste plus vendues sur les versions récentes.
    • Le calendrier prévoit des spécifications détaillées à VMware Explore Frankfurt, le 13 octobre 2026.

    Ce qui reste flou, et pourquoi ça compte

    « Autour de 128 cœurs » n’est pas une limite de licence, c’est une formulation marketing. Et la nuance est loin d’être anecdotique : un serveur bi-socket avec des processeurs modernes dépasse largement les 128 cœurs physiques aujourd’hui, alors que 128 cœurs logiques (avec hyperthreading) se traduisent en réalité par 64 cœurs physiques. Se baser sur cette phrase pour dimensionner un futur contrat de renouvellement, c’est prendre le risque de se tromper d’un facteur deux.

    Concrètement, à ce jour, personne à l’extérieur de Broadcom ne peut te donner : le tarif, l’unité de mesure exacte (cœur physique, cœur logique, socket, VM), la date de disponibilité, ni le périmètre fonctionnel de cette édition par rapport à vSphere 9.1 complet. Tout ce que tu lirais ailleurs de plus précis relève de la spéculation, pas de l’annonce officielle.

    Pendant ce temps, l’ingénierie vSphere continue d’avancer

    Il serait injuste de réduire 2026 à la seule saga des licences. VMware Cloud Foundation 9.1, sorti en parallèle, apporte des évolutions concrètes qui n’ont rien à voir avec la politique commerciale : le vCenter Quick Patch permet d’appliquer des correctifs de sécurité avec un temps d’arrêt réduit, parfois nul, en ne mettant à jour que les paquets RPM modifiés plutôt que l’image complète. Le nouveau mode DRS Optimized vMotion Evacuation propose une évacuation non disruptive lors de la mise en maintenance d’un hôte. Et le déchargement du chiffrement vMotion sur Intel QAT libère des cœurs CPU auparavant mobilisés par cette tâche.

    Rien de tout ça ne dépend du sort de vSphere Standard — c’est disponible dans VCF 9.1 dès maintenant, ce qui montre que la plateforme technique continue d’évoluer sérieusement, indépendamment du feuilleton licence.

    Qu’est-ce que ça change pour toi, concrètement

    Trois situations, trois réponses différentes :

    Si tu es déjà passé sur Proxmox, Hyper-V ou Azure Local et que ça fonctionne, il n’y a aucune raison de revenir en arrière sur la base d’une simple déclaration d’intention sans tarif ni date. Une migration a un coût réel ; une rumeur de retour n’en a pas encore un assez concret pour la justifier.

    Si tu es en pleine négociation de renouvellement VCF, cette annonce te donne un levier légitime : tu peux explicitement demander à ton interlocuteur commercial Broadcom si vSphere Standard sera disponible avant l’échéance de ton contrat, et repousser la signature de quelques semaines si c’est jouable. Attends au moins le 13 octobre pour arbitrer.

    Si tu es encore en phase de décision et que ton infrastructure tourne effectivement autour de 60-70 cœurs physiques (donc dans la fourchette visée), patiente jusqu’à Frankfurt avant de t’engager ailleurs — mais prépare un plan B chiffré en parallèle, au cas où le tarif annoncé ne soit finalement pas compétitif face à Proxmox VE ou Hyper-V.

    FAQ

    vSphere Standard va-t-il redevenir une licence perpétuelle comme avant 2024 ?

    Rien n’a été annoncé en ce sens. Tout indique au contraire un modèle par abonnement, cohérent avec la direction prise par Broadcom sur l’ensemble du portefeuille VMware depuis le rachat.

    Cette édition inclura-t-elle les fonctionnalités de vSphere 9.1 listées plus haut ?

    Impossible à confirmer avant les spécifications détaillées d’octobre. Historiquement, les éditions Standard ont toujours eu un périmètre fonctionnel réduit par rapport aux éditions supérieures — pas de raison objective de penser que ce sera différent cette fois.

    Faut-il attendre le 13 octobre avant de renouveler un contrat qui expire avant cette date ?

    Si ton contrat expire avant, tu n’as pas le luxe d’attendre : négocie un renouvellement court (3 à 6 mois) plutôt qu’un engagement pluriannuel, le temps d’y voir plus clair.

    Ce qu’il faut retenir

    Un retour de vSphere Standard serait une bonne nouvelle pour les infrastructures de taille moyenne qui n’ont jamais eu besoin de VCF au grand complet — mais on n’y est pas encore. Note la date du 13 octobre 2026 dans ton calendrier, et jusque-là, ne prends aucune décision d’infrastructure sur la seule base d’une phrase prononcée sur une scène de conférence.