Ctrl+Alt+Prod

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

  • Azure Dsv7/Esv7 : les tailles à 248 et 372 vCPU passent en GA

    Azure Dsv7/Esv7 : les tailles à 248 et 372 vCPU passent en GA

    372 vCPU et 2,8 Tio de mémoire sur une seule machine virtuelle : c’est désormais une taille Azure disponible en production, pas une démo de salon. Depuis le 25 août 2026, les tailles à 248 et 372 vCPU des séries D/E v7 sont passées en disponibilité générale, et elles changent la donne pour tout ce qui ne se découpe pas facilement en petits morceaux — grosses bases en mémoire, workloads d’IA à contexte large, applications sensibles à la latence inter-nœuds.

    Ce qui change avec ces nouvelles tailles

    Les séries concernées sont Dsv7, Ddsv7, Esv7 et Edsv7, toutes bâties sur un processeur Intel Xeon 6 6973P-C (Granite Rapids) cadencé à 3,6 GHz en turbo tous cœurs, avec AVX-512 et Advanced Matrix Extensions. Microsoft annonce jusqu’à 20 % de performance de calcul en plus par rapport à la génération v6 précédente. Les deux tailles phares à retenir :

    • Esv7 / Edsv7, 372 vCPU — jusqu’à 2 832 Gio de RAM, jusqu’à 400 Gbps réseau, et jusqu’à 800 000 IOPS / 20 Gio/s vers du stockage distant Premium SSD v2 ou Ultra Disk.
    • Ddsv7 / Edsv7, 372 vCPU — avec disque NVMe local, jusqu’à 9,6 millions d’IOPS et 53,76 Gio/s de débit sur le disque temporaire local, d’après la fiche Edsv7-series de Microsoft Learn.

    Pour fixer un repère : Standard_E372ids_v7 monte à 500 000 IOPS / 16 000 Mo/s en Premium SSD non mis en cache, et jusqu’à 800 000 IOPS / 20 000 Mo/s en Ultra Disk ou Premium SSD v2 — le haut du tableau des tailles Edsv7, documenté précisément sur la page de la famille D. Ces chiffres n’ont plus grand-chose à voir avec ce qu’on pouvait attendre d’une VM Azure il y a encore deux ans.

    Côté disponibilité, la mise à jour couvre huit régions pour l’instant : Central US, East US, East US 2, Germany West Central, South Central US, Sweden Central, West US 2 et West US 3 — à vérifier avant de planifier un déploiement si tu n’es pas déjà dans une de ces zones.

    Pour quels workloads ça change vraiment quelque chose

    Microsoft cible explicitement les grosses bases en mémoire (SQL Server, SAP HANA, Redis en mode in-memory), les moteurs d’analytique et de data warehousing, et — sans surprise en 2026 — les workloads d’IA agentique à fenêtre de contexte large. Le point commun entre tous ces cas : ce sont des charges qui perdent en performance dès qu’elles doivent se répartir sur plusieurs nœuds et traverser le réseau pour chaque requête. Une base SAP HANA en mémoire qui tenait auparavant sur un cluster de plusieurs VM E v6 moyennes peut désormais tenir sur une seule E372ids_v7, ce qui supprime purement et simplement la latence de sharding inter-nœuds.

    Ça a aussi une conséquence qu’on mentionne rarement dans les annonces marketing : moins de VM pour le même volume de calcul, c’est moins de licences par cœur à gérer si tu es sous licensing SQL Server Enterprise par cœur physique, et une surface d’administration réduite. Le revers de la médaille, c’est la concentration du risque — une seule VM de cette taille qui tombe, c’est potentiellement toute ta base qui part avec elle, pas un nœud sur quatre. Le Live Migration et les Memory Preserving Updates restent supportés sur ces séries, ce qui limite l’exposition aux redémarrages de maintenance planifiée, mais ça ne protège pas d’une panne applicative.

    Le piège à connaître avant de migrer

    Ces séries fonctionnent uniquement sur des VM de génération 2 (Gen2) et nécessitent une image qui supporte NVMe — un prérequis déjà posé par la bascule Trusted Launch par défaut sur les VM Gen2 dont on parlait en septembre. Si tu tentes de redéployer une image personnalisée ancienne, sans pilote NVMe, sur une taille Ddsv7 ou Edsv7, le déploiement échoue avec un message d’erreur explicite plutôt qu’un démarrage silencieusement dégradé — ce n’est pas un bug, c’est documenté comme un comportement attendu. Vérifie le support NVMe de ton image avant de migrer, pas après.

    Autre point à ne pas laisser de côté : la variante Dsv7 « sans suffixe d » n’a aucun stockage local, contrairement à Ddsv7. Si ton workload a besoin du disque NVMe local — par exemple pour profiter du Full Caching des Ephemeral OS Disks passé en GA en septembre — c’est Ddsv7 ou Edsv7 qu’il te faut, pas Dsv7. Avec un disque local pouvant atteindre plusieurs téraoctets sur ces tailles, la contrainte « stockage local ≥ 2× la taille du disque OS + 1 Gio » exigée par le Full Caching devient triviale à satisfaire, même avec une image OS volumineuse.

    Comment déployer une de ces tailles

    Rien de nouveau côté outillage — ces tailles se créent comme n’importe quelle autre VM Azure, à condition de cibler une des régions disponibles :

    az vm create \
  --resource-group mon-groupe-ressources \
  --name vm-sap-hana-01 \
  --image Ubuntu2404 \
  --size Standard_E372ids_v7 \
  --location swedencentral \
  --generation V2 \
  --admin-username azureuser \
  --generate-ssh-keys

    Avant de lancer ce genre de déploiement en production, passe par la calculatrice de prix Azure — une VM à 372 vCPU n’a pas le même ticket d’entrée qu’une D4s_v5, et le coût du stockage Ultra Disk ou Premium SSD v2 associé se facture à part.

    FAQ

    Ces tailles remplacent-elles les séries v6 existantes ?
    Non, les tailles v6 restent disponibles et ne sont pas annoncées en retrait. Les v7 s’ajoutent en haut de gamme, avec un plafond de vCPU et de débit nettement supérieur, pas comme un remplacement généralisé du catalogue existant.

    Faut-il forcément du NVMe pour utiliser ces tailles ?
    Oui pour le stockage local des variantes Ddsv7/Edsv7 — l’image OS doit supporter NVMe, sous peine d’échec de déploiement. Les variantes Dsv7/Esv7 sans stockage local n’ont pas cette contrainte puisqu’elles n’exposent pas de disque NVMe du tout.

    Ces tailles sont-elles disponibles partout ?
    Non, seulement dans huit régions pour l’instant (Central US, East US, East US 2, Germany West Central, South Central US, Sweden Central, West US 2, West US 3). Vérifie la disponibilité régionale avant d’engager un projet dessus.

    En pratique

    Si tu gères une base en mémoire ou un moteur d’analytique qui souffre aujourd’hui du sharding entre plusieurs VM, c’est le moment de recalculer le coût d’une consolidation sur une seule instance E372ids_v7 ou D372 — moins de nœuds à patcher, moins de licences par cœur à suivre, et une latence inter-nœuds qui disparaît purement et simplement. Vérifie juste le support NVMe de tes images avant de lancer le premier test, et commence par une région où ces tailles sont déjà disponibles.

  • CVE-2026-70229 : la faille RCE non authentifiée dans Active Directory Domain Services

    CVE-2026-70229 : la faille RCE non authentifiée dans Active Directory Domain Services

    Le 13 octobre 2026, Microsoft a corrigé une vulnérabilité qui permet à n’importe quel attaquant présent sur le réseau de ton domaine de viser directement tes contrôleurs — sans identifiants, sans phishing, sans compte compromis au préalable. La faille porte la référence CVE-2026-70229 et touche Active Directory Domain Services (AD DS) lui-même, pas un composant périphérique.

    Ce correctif arrive dans un Patch Tuesday particulièrement chargé (1 407 failles corrigées au total selon le récapitulatif d’IT-Connect), mais celle-ci mérite qu’on s’y arrête : elle touche le cœur de ton infrastructure d’identité.

    Ce que CVE-2026-70229 permet concrètement

    Il s’agit d’un défaut d’autorisation (CWE-863) : AD DS ne vérifie pas correctement les droits d’un demandeur avant de traiter une opération privilégiée. Concrètement, un attaquant non authentifié peut envoyer des paquets réseau spécialement construits à un contrôleur de domaine pour y déclencher une exécution de code, sans identifiants et sans interaction utilisateur. Le vecteur CVSS publié est AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, pour un score de base de 8.1.

    Remarque importante sur la gravité : 8.1 place la faille dans la bande « élevée » (High) de l’échelle CVSS, pas dans la bande « critique » (9.0 et au-delà) — même si plusieurs relais de presse la qualifient de « critique » en se basant sur son impact plutôt que sur son score. La nuance vient du AC:H : la complexité d’attaque est haute. Microsoft précise que l’exploitation dépend de conditions réseau et d’un minutage précis, donc ce n’est pas le genre de faille qu’on déclenche en un clic depuis un script trouvé sur GitHub. Pas de preuve de concept publique à ce jour, et le score EPSS (probabilité d’exploitation à 30 jours) tourne autour de 0,71 %, ce qui reste bas.

    Ceci dit, AD DS porte Kerberos, LDAP, la réplication et les GPO. Une exécution de code sur un contrôleur de domaine, même difficile à déclencher de façon fiable, ouvre la porte à la falsification de tickets, à la modification de l’appartenance aux groupes et au mouvement latéral vers tous les postes joints au domaine. Le score CVSS mesure la difficulté d’exploitation, pas la gravité de ce qui se passe une fois que ça marche.

    Les correctifs par version de Windows Server

    Le correctif est inclus dans les mises à jour cumulatives d’octobre, à appliquer en priorité sur tes contrôleurs de domaine avant les serveurs membres :

    • Windows Server 2025 — KB5126646, build 26100.33650.
    • Windows Server 2022 — KB5126655, build 20348.5761. C’est la dernière mise à jour du cycle de support grand public ; le support continue jusqu’au 14 octobre 2031.
    • Windows Server 2019 — KB5126651, build 17763.9376.
    • Windows Server 2016 — KB5126868, build 14393.9612. Installe d’abord la mise à jour de la pile de maintenance KB5126649 ; sur WSUS, approuve les deux KB.

    Si tu fais encore tourner des contrôleurs de domaine sous Windows Server 2012 ou 2012 R2 : le support étendu (ESU) s’est arrêté exactement le même jour, le 13 octobre 2026. Les derniers correctifs de sécurité jamais publiés pour ces versions sont KB5126835 et KB5126836. Après ça, plus rien — ce Patch Tuesday était littéralement ta dernière fenêtre de rattrapage avant de migrer.

    Le reste du lot d’octobre qui concerne tes contrôleurs de domaine

    Deux autres changements de cette mise à jour valent le détour, même s’ils sont moins spectaculaires que le RCE non authentifié.

    D’abord, la correction de l’ACL du conteneur Distributed Key Manager (DKM) d’AD FS, liée à CVE-2026-56155 — une faille d’élévation de privilèges exploitée comme zero-day et corrigée en juillet 2026. Depuis octobre, le correctif durcit automatiquement les ACL trop permissives sur ce conteneur, sans action de ta part. Si pour une raison précise tu as besoin de désactiver ce durcissement automatique (compatibilité avec un outillage tiers, par exemple), une valeur de registre nommée RemediateDkmAcl permet de l’opter-out — la procédure exacte est documentée dans KB5121391, à consulter avant de toucher à un environnement AD FS en production. C’est le même type d’abus de confiance d’infrastructure PKI/fédération que Certighost (CVE-2026-54121) dans AD CS, dont on parlait la semaine dernière : un composant périphérique de l’écosystème AD qui finit par accorder une confiance qu’il ne devrait pas.

    Ensuite, une amélioration du canal sécurisé Netlogon dans KB5126646 : les serveurs membres se connectent plus fiablement aux contrôleurs de domaine déployés avant Windows Server 2025. Utile si tu es en pleine migration et que tu fais tourner des DC de générations mélangées pendant la transition.

    Sur Windows Server 2022 et 2019, Microsoft ajoute aussi un audit NTLM avancé qui indique qui utilise encore NTLM, pourquoi il a été sélectionné, et où l’authentification a lieu — pratique pour repérer les dépendances avant le retrait progressif de NTLM.

    Limiter l’exposition en complément du correctif

    Patcher reste la priorité, mais un contrôleur de domaine joignable depuis n’importe quel poste du réseau reste un risque en soi, faille ou pas :

    • Restreins l’accès réseau entrant aux ports d’administration AD (389, 636, 3268, 3269, 88, 445) aux seuls sous-réseaux d’administration légitimes.
    • Administre AD DS uniquement depuis des postes d’administration durcis (PAW), jamais depuis un poste utilisateur standard.
    • Audite les appartenances aux groupes à privilèges et les changements d’ACL récents ; surveille les ID d’événements 4662, 4670 et 5136.
    • Surveille le trafic LDAP, RPC ou DRSUAPI inattendu émis par des hôtes qui ne sont pas des contrôleurs de domaine.

    Une règle de pare-feu basique pour limiter l’administration AD à un sous-réseau dédié, à titre d’illustration :

    New-NetFirewallRule -DisplayName "AD DS - Sous-reseau admin uniquement" `
  -Direction Inbound -Protocol TCP `
  -LocalPort 389,636,3268,3269,88,445 `
  -RemoteAddress 10.10.0.0/24 -Action Allow

    FAQ

    Ce correctif est-il vraiment urgent si rien n’est exploité pour l’instant ?
    Oui. Le score EPSS bas et l’absence de preuve de concept publique aujourd’hui ne garantissent rien pour demain — l’ACL AD FS corrigée dans cette même mise à jour (CVE-2026-56155) était, elle, un zero-day activement exploité en juillet. Un contrôleur de domaine non patché reste la pire chose à laisser traîner, indépendamment du timing de l’exploitation publique.

    La faille est-elle vraiment « critique » comme le disent certains titres ?
    Au sens strict de l’échelle CVSS, non : 8.1 correspond à la bande « élevée », pas « critique » (9.0+). La complexité d’attaque haute (AC:H) explique cet écart avec la perception médiatique. Ça ne change rien à la priorité de patch sur tes DC — juste à la façon de présenter le risque si tu dois le justifier en interne.

    Le correctif casse-t-il quelque chose en production ?
    La page de KB5126646 référence un problème connu lié à WSUS (CVE-2025-59287, une faille RCE distincte). Vérifie les notes de version avant un déploiement en masse si tu administres WSUS en parallèle de tes contrôleurs de domaine.

    Je suis encore sur Windows Server 2012 R2, qu’est-ce que je fais ?
    Tu appliques KB5126836 maintenant si tu ne l’as pas encore fait — c’est le tout dernier correctif de sécurité jamais publié pour cette version, l’ESU s’est arrêté le 13 octobre 2026. Ensuite, tu planifies la migration sans attendre : il n’y aura plus de filet de sécurité au prochain problème.

    En pratique

    Patche tes contrôleurs de domaine avant tout le reste de ton parc ce mois-ci, dans cet ordre : DC, puis serveurs membres, puis postes de travail. Si tu gères encore des DC en 2012/2012 R2, c’est le moment de transformer « il faudra migrer un jour » en ticket planifié cette semaine — l’ESU ne reviendra pas te sauver la prochaine fois.

  • Microsoft Graph PowerShell v3 : fini Windows PowerShell 5.1

    Microsoft Graph PowerShell v3 : fini Windows PowerShell 5.1

    Si tes scripts d’administration M365 tournent encore sous Windows PowerShell 5.1 avec le module Microsoft.Graph, tu as jusqu’au quatrième trimestre 2026 pour changer ça. Dans un billet publié le 16 septembre 2026, l’équipe Microsoft 365 Dev a confirmé que la version 3.0.0 du Microsoft Graph PowerShell SDK n’aura plus de support explicite pour Windows PowerShell 5.1 — seul PowerShell 7.x restera maintenu.

    Ce n’est pas une surprise brutale : Microsoft prépare le terrain depuis des mois avec le retrait progressif d’Azure AD PowerShell au profit de Graph. Mais c’est la première fois que la coupure entre les deux moteurs PowerShell est posée aussi clairement, avec un calendrier précis plutôt qu’une recommandation vague.

    Ce qui change concrètement

    La v3 change surtout l’outillage qui génère les cmdlets à partir du schéma de l’API Graph — l’équipe la présente comme « minimalement disruptive », l’essentiel de l’usage existant devant continuer à fonctionner tel quel. Des divergences volontaires sont prévues, elles seront documentées au fil des billets alpha et bêta à venir. Le changement qui compte vraiment pour toi est ailleurs : les modules v3.x ne cibleront que PowerShell 7.x — alors que la documentation officielle du SDK présente encore aujourd’hui la compatibilité avec Windows PowerShell 5.1 comme un avantage du produit.

    Le calendrier annoncé tient en deux temps :

    • Maintenant à ~12 mois : période de retrait. La branche v2.x reste compatible avec Windows PowerShell 5.1 et continue de recevoir des correctifs de sécurité si nécessaire, mais les bugs spécifiques à 5.1 ne seront plus activement investigués.
    • Q4 2026 : sortie de la v3.0.0. Après ce point, plus aucune nouvelle version v2 n’est publiée, sauf correctif de sécurité critique.

    Dans les commentaires du billet, Gavin Barron de l’équipe Graph précise que la v2.36.1 (ou plus récente) reste fonctionnelle sans limite de date connue, et que les versions antérieures à celle-ci ne peuvent déjà plus utiliser l’authentification interactive par navigateur (Interactive Browser Credential) — un détail qui pousse à une mise à jour immédiate, indépendamment de la question du support 5.1.

    Pourquoi Microsoft fait ce choix

    L’argument technique tient en une phrase : PowerShell 7.x, construit sur le .NET moderne, règle une bonne partie des problèmes de chargement d’assemblies et de conflits de dépendances qui touchent encore 5.1. La v2 du SDK utilisait déjà les Assembly Load Contexts de PowerShell Core pour limiter ces conflits — Microsoft reconnaît elle-même que ce n’est « pas une solution parfaite », et plusieurs commentateurs du billet signalent des conflits persistants quand Graph charge dans la même session que les modules Teams ou Exchange Online. Concentrer l’effort d’ingénierie sur un seul runtime plutôt que de maintenir deux chemins de compatibilité en parallèle, c’est ce qui doit permettre des correctifs plus rapides à l’avenir.

    Ce que ça implique pour tes scripts

    Si tu administres des tenants Microsoft 365 ou Entra ID via PowerShell, trois choses à vérifier dès maintenant plutôt qu’au moment où la v3 sort :

    • Vérifie ta version actuelle du module avec Get-InstalledModule Microsoft.Graph, et mets à jour vers au moins la 2.36.1 si tu es en dessous — l’authentification interactive en dépend déjà.
    • Si tes scripts tournent encore sous Windows PowerShell 5.1 (console powershell.exe, pas pwsh.exe), planifie leur portage vers PowerShell 7 maintenant. C’est généralement direct pour du code Graph pur, moins pour les scripts qui mélangent Graph avec des modules legacy comme ActiveDirectory ou certains modules IIS/Scheduled Task, dont la compatibilité avec PowerShell 7 reste incertaine selon les retours des lecteurs du billet.
    • Si tu exploites System Center Orchestrator 2025, le sujet est plus épineux : son activité de script .NET ne supporte que Windows PowerShell, et Microsoft n’a pour l’instant donné aucune réponse sur ce cas précis dans les commentaires du billet.
    # Vérifier la version installée du SDK Graph
Get-InstalledModule Microsoft.Graph | Select-Object Name, Version

# Mettre à jour vers la dernière version disponible
Update-Module Microsoft.Graph

# Confirmer le moteur PowerShell utilisé (7.x attendu, pas 5.1)
$PSVersionTable.PSVersion

    Pour la bascule elle-même, la documentation officielle sur la migration de Windows PowerShell 5.1 vers PowerShell 7 reste la référence à suivre : emplacement du profil différent, bascule du switch -UseWindowsPowerShell pour les modules encore incompatibles, et liste à jour des modules qui fonctionnent nativement en 7.x.

    Une tendance plus large

    Ce retrait de 5.1 côté Graph s’inscrit dans un mouvement de fond déjà documenté sur ce blog : la feuille de route 2026 de Microsoft pour PowerShell pousse clairement vers 7.x comme plateforme unique, et la Preview 5 de la 7.7 confirme que tout l’investissement produit se concentre désormais là. Windows PowerShell 5.1 n’est pas officiellement retiré de Windows — il reste là, maintenu via les canaux de support Windows standard — mais chaque module d’automatisation majeur qui lâche son support actif est un signal de plus qu’il est temps de migrer, pas une raison de paniquer.

    FAQ

    Mes scripts PowerShell 5.1 avec Graph vont-ils casser du jour au lendemain ?

    Non. La v2.x continue de fonctionner sous 5.1 ; ce qui change, c’est que les bugs spécifiques à 5.1 ne seront plus corrigés activement, et qu’aucune nouvelle fonctionnalité Graph ne sera testée sur ce runtime au-delà de la v2.

    Dois-je attendre la sortie de la v3 pour migrer vers PowerShell 7 ?

    Non, l’inverse : migre maintenant, pendant que tu as le temps, plutôt que dans l’urgence quand la v3 sortira au T4 2026 et que la v2 cessera de recevoir des mises à jour.

    Et pour Azure PowerShell ou le module Active Directory ?

    Ces modules sont déjà listés comme compatibles PowerShell 7 par Microsoft. Le point de friction concerne surtout les modules plus anciens ou très spécialisés (certains modules IIS, Scheduled Task, ou l’activité .NET de System Center Orchestrator), à tester au cas par cas avant de basculer en production.

    Pour la suite

    Commence par un simple Get-InstalledModule Microsoft.Graph sur tes postes d’administration et tes serveurs de script — si tu es sous la 2.36.1, la mise à jour est gratuite et immédiate. Pour la bascule complète vers PowerShell 7, mieux vaut la traiter comme un projet planifié sur les prochains mois que comme un correctif de dernière minute à l’approche du T4 2026.

  • GitHub Package Firewall : stopper les malwares npm en pleine CI

    GitHub Package Firewall : stopper les malwares npm en pleine CI

    Le 17 juin 2026, un mainteneur npm compromis publie mastra@1.13.1 depuis une adresse Tutamail anonyme, en dehors du pipeline GitHub Actions habituel. Le seul changement : une dépendance ajoutée, easy-day-js, un typosquat de la bibliothèque dayjs. Résultat : 140 packages de l’écosystème @mastra touchés, un script postinstall qui désactive la vérification TLS, télécharge une charge de second niveau et installe une persistance sur Windows, macOS et Linux. Microsoft attribue l’attaque à Sapphire Sleet, un groupe nord-coréen, avec un niveau de confiance élevé.

    C’est ce genre de scénario que GitHub Package Firewall, passé en preview publique le 20 octobre 2026, essaie d’intercepter avant qu’il n’atteigne tes runners. Pas en analysant le code après coup, mais en se plaçant entre tes endpoints et le registre npm, au moment même où le `npm install` part chercher ses dépendances.

    Ce que fait réellement le pare-feu

    Le principe est simple sur le papier. Tu configures tes runners Actions, tes postes de développement ou tes agents de code pour router leurs requêtes npm — métadonnées de package comme téléchargements effectifs — à travers le pare-feu plutôt que directement vers la registry publique. Chaque requête est alors évaluée contre une politique que tu définis au niveau de l’organisation : une période de cooldown qui bloque les versions trop récentes (le temps que la communauté détecte une éventuelle charge malveillante), une vérification croisée avec la GitHub Advisory Database, et des contrôles de chaîne d’approvisionnement comme la détection d’une attestation de provenance qui régresse entre deux versions.

    Si un package légitime se retrouve bloqué par erreur, tu peux demander une exception via un workflow similaire à celui des autres fonctionnalités GitHub Advanced Security — pas de blocage définitif sans recours.

    Ce qui manque encore

    Deux limites à garder en tête avant de t’enthousiasmer. D’abord, seul l’écosystème npm est couvert pour l’instant — rien pour PyPI, NuGet ou les modules Terraform, alors que les attaques par typosquat touchent tous les registries. Ensuite, et c’est le point le plus important : le pare-feu ne protège que le trafic qui passe réellement par lui. Un runner mal configuré, un script qui pointe en dur vers registry.npmjs.org, ou un développeur qui installe en local sans passer par le proxy d’entreprise, contournent entièrement la protection. Ce n’est pas un défaut caché, GitHub le dit explicitement dans sa documentation : la fonctionnalité dépend de l’endpoint qui joue le jeu.

    Disponible pour tous les clients GitHub Enterprise Cloud (y compris avec data residency), gratuit pendant la preview, facturé à l’usage comme Actions à la disponibilité générale — sans date ni tarif annoncés pour l’instant.

    Pourquoi ça a du sens maintenant

    Le cas Mastra n’est pas isolé. TanStack, Jscrambler, et une bonne partie du calendrier 2026 des compromissions npm suivent le même schéma, déjà détaillé dans notre tour d’horizon des attaques supply chain CI/CD de 2026 : un compte mainteneur pris, un typosquat ou une dépendance ajoutée discrètement, un hook postinstall qui exfiltre des tokens avant même que le code applicatif ne tourne. C’est exactement le moment où un pare-feu en amont du téléchargement a le plus de valeur — contrairement à un scan de code qui arrive après coup, quand le malware a déjà eu l’occasion de s’exécuter.

    Ça rejoint la logique derrière les workflow lockfiles GitHub Actions, publiés quatre jours plus tôt : les deux mécanismes attaquent le même problème — une chaîne de dépendances qui change sous tes pieds sans que tu t’en rendes compte — mais à des niveaux différents. Les lockfiles verrouillent le graphe de dépendances de tes workflows Actions eux-mêmes ; le pare-feu filtre ce que npm va chercher pendant l’exécution de ton build. Les deux ensemble, pas l’un à la place de l’autre.

    En attendant que le pare-feu couvre d’autres écosystèmes, la mitigation la plus simple reste à la portée de tout le monde dès aujourd’hui : npm install --ignore-scripts désactive l’exécution de tout hook postinstall, au prix de devoir parfois relancer manuellement un build natif pour les packages qui en ont réellement besoin.

    # Installer sans exécuter les scripts de cycle de vie
npm install --ignore-scripts

# Vérifier après coup si une dépendance a tenté d'en profiter
npm config get ignore-scripts

    FAQ

    Le pare-feu remplace-t-il un scanner de dépendances type Dependabot ou Snyk ?

    Non. Dependabot et les scanners SCA analysent ton code et tes manifestes de dépendances pour repérer des vulnérabilités connues. Le pare-feu, lui, agit en amont, au moment où npm va chercher un package sur le réseau — il bloque avant le téléchargement, pas après coup sur une base déjà installée.

    Faut-il GitHub Enterprise pour en profiter ?

    Oui, c’est réservé aux clients GitHub Enterprise Cloud à ce stade (data residency incluse). Rien n’indique pour l’instant une disponibilité sur les plans Team ou Pro.

    Si je n’ai pas Enterprise, que faire en attendant ?

    Verrouille tes dépendances avec un fichier de lock à jour, désactive les scripts de cycle de vie par défaut sur les environnements CI qui n’en ont pas besoin, et surveille les alertes de la GitHub Advisory Database sur tes dépôts — c’est la même base que le pare-feu interroge en coulisses.

    Pour la suite

    Le pare-feu npm est un bon réflexe défense-en-profondeur, pas une solution miracle : il ne vaut que ce que vaut le routage réseau derrière lui. Si tu es sur GitHub Enterprise, active-le en mode non bloquant d’abord pour calibrer la politique de cooldown sans casser tes builds, puis passe en application stricte une fois que tu as confiance dans les faux positifs. Et quel que soit ton plan GitHub, prends cinq minutes pour vérifier que tes pipelines n’installent pas déjà des dépendances avec des scripts de cycle de vie que tu n’as jamais auditées.

  • CVE-2026-96951 : zero-day Windows Shell exploité

    CVE-2026-96951 : zero-day Windows Shell exploité

    Le 13 octobre 2026, Microsoft a publié son plus gros Patch Tuesday à ce jour : 1 411 failles corrigées en une seule fournée, dont 70 classées critiques (57 d’exécution de code à distance, 11 d’élévation de privilèges, 2 de spoofing). Trois zero-days dans le lot. Une seule compte vraiment pour la priorisation immédiate : CVE-2026-96951, un contournement du Mark of the Web dans le Shell Windows, déjà exploité activement avant même la sortie du correctif. Le délai fixé par la CISA pour les agences fédérales américaines, le 16 octobre, est passé depuis quatre jours au moment où tu lis ces lignes. Si ce correctif n’est pas encore déployé chez toi, c’est le moment de remonter la pile des priorités.

    Ce que fait CVE-2026-96951

    Le Mark of the Web (MOTW) est l’attribut que Windows attache automatiquement à un fichier téléchargé depuis Internet — c’est lui qui déclenche l’avertissement SmartScreen, la Vue protégée d’Office, ou le blocage par défaut de certaines macros. Microsoft décrit CVE-2026-96951 comme une injection de commande dans le Shell Windows permettant à un attaquant non authentifié de contourner cette protection par le réseau. En clair : un fichier qui devrait être marqué comme non fiable passe au travers, et la victime se retrouve à exécuter un contenu que Windows aurait dû signaler.

    Microsoft n’a publié aucun détail sur le vecteur d’exploitation exact ni sur qui a découvert la faille — une discrétion fréquente quand l’exploitation est déjà active et que communiquer le mécanisme risquerait d’accélérer sa diffusion. On sait en revanche, via le tracker de vulnérabilités Senserva, que le score CVSS retenu est de 8.8 et que la faille touche la quasi-totalité du parc Windows encore sous support : Windows 10 (1607, 1809, 21H2, 22H2), Windows 11 (23H2 à 26H2), et Windows Server de 2012 R2 à 2025, Server Core compris.

    Le contournement MOTW ne sert quasiment jamais seul. C’est une brique qui désamorce une protection pour laisser passer l’étape suivante d’une attaque, typiquement un document ou un exécutable qui, une fois le marquage neutralisé, s’ouvre sans l’avertissement qui aurait dû faire hésiter l’utilisateur ou bloquer l’exécution. Le genre de brique qu’on retrouve en amont de campagnes de phishing livrant un chargeur ou un ransomware, même si Microsoft n’a lié cette CVE précise à aucune campagne nommée pour l’instant.

    Les deux autres zero-days du mois

    Contrairement à CVE-2026-96951, les deux autres ne sont pas exploitées activement : elles ont simplement été rendues publiques avant le correctif, ce qui justifie quand même une priorité au-dessus de la moyenne.

    CVE-2026-108398 touche le .NET Framework : un chemin de recherche non fiable permet à un attaquant déjà authentifié localement de déposer un assembly .NET forgé et de contourner Windows Defender Application Control (WDAC), avec exécution de code dans un processus protégé, sans interaction de l’utilisateur. C’est James Forshaw, de Google Project Zero, qui l’a signalée ; son nom revient régulièrement sur ce type de faille touchant les mécanismes de confiance Windows.

    CVE-2026-92707 est plus anodine : un déni de service dans MessagePack-CSharp, causé par une allocation mémoire séquentielle mal bornée côté .NET, exploitable à distance sans authentification. Microsoft la classe « modérée », loin derrière les deux premières en termes de priorité de correctif.

    Patcher, concrètement

    Les correctifs de CVE-2026-96951 sont répartis sur neuf mises à jour cumulatives selon la version visée : KB5126646, KB5126651, KB5126653, KB5126655, KB5126657, KB5126836, KB5126868, KB5127646 et KB5127648. Ces mêmes KB corrigent au passage huit autres CVE, dont CVE-2026-100202 et CVE-2026-105010 — appliquer la bonne mise à jour cumulative pour ta version de Windows règle donc plusieurs problèmes d’un coup, pas seulement le zero-day.

    Pour prioriser sans tout relire ligne par ligne : commence par les postes et serveurs exposés à des téléchargements non maîtrisés (postes utilisateurs avec accès web large, serveurs de fichiers partagés avec l’extérieur), continue avec le reste du parc Windows selon ton cycle de déploiement habituel, et vérifie après coup que le niveau de patch correspond bien au KB attendu pour chaque version. Un inventaire rapide des mises à jour installées, via l’outil de gestion de patchs que tu utilises déjà, suffit pour un contrôle à l’échelle d’un parc.

    Le catalogue KEV de la CISA référence CVE-2026-96951 depuis le 13 octobre avec exploitation active confirmée — c’est la source la plus fiable pour suivre l’évolution du statut si de nouvelles informations sortent. Pour le détail officiel complet de ce Patch Tuesday, le Security Update Guide de Microsoft reste la référence, même si l’interface n’est pas la plus agréable à parcourir en masse.

    FAQ

    Faut-il redémarrer les serveurs immédiatement après l’installation du correctif ?

    Oui. Comme pour toute mise à jour cumulative Windows touchant un composant aussi bas niveau que le Shell, le correctif n’est actif qu’après redémarrage. Planifier une fenêtre de maintenance rapide prime sur l’attente d’un créneau plus confortable, vu l’exploitation déjà confirmée.

    Les 1 411 failles corrigées concernent-elles toutes Windows ?

    Non, ce chiffre couvre l’ensemble du portefeuille Microsoft pour ce Patch Tuesday — Windows, .NET, Office, Azure et autres produits — pas uniquement le système d’exploitation. Les trois zero-days de ce mois concernent spécifiquement Windows Shell et .NET Framework.

    Le délai CISA du 16 octobre s’applique-t-il à mon entreprise si je ne suis pas une agence fédérale américaine ?

    Non, la directive opérationnelle contraignante de la CISA ne vise que les agences fédérales civiles américaines. Mais le calendrier qu’elle fixe reste un bon repère de priorité pour n’importe quelle organisation : si une faille est jugée assez critique pour imposer une deadline légale à l’administration américaine, elle l’est probablement aussi pour ton infrastructure.

    Si tu veux comparer avec le volume du mois précédent, on avait couvert le Patch Tuesday de septembre 2026 et ses 974 failles — la progression en un mois donne une idée de la cadence à laquelle le volant de correctifs continue de grossir. Et si le sujet des zero-days activement exploités t’intéresse plus largement, notre article sur le zero-day FortiMail CVE-2026-104286 suit le même type de mécanique de divulgation.

  • Azure DevOps Wiki : l’éditeur passe sous Monaco (VS Code)

    Azure DevOps Wiki : l’éditeur passe sous Monaco (VS Code)

    Le 8 octobre 2026, Microsoft a mis en preview publique un nouvel éditeur pour le Wiki d’Azure DevOps. Rien de révolutionnaire dans l’annonce — un composant d’édition qui change — mais le détail compte : c’est Monaco, le moteur qui fait tourner Visual Studio Code dans un navigateur, qui remplace l’ancien éditeur. Concrètement, ton Wiki de documentation interne récupère une partie de l’expérience d’édition que tu as déjà sur ton poste, sans rien installer.

    Ce que Monaco change concrètement dans l’éditeur Wiki

    La liste des ajouts tient en une poignée de points, mais chacun répond à une frustration précise de l’ancien éditeur :

    • Coloration syntaxique du Markdown et numéros de ligne, comme dans VS Code — fini l’édition à l’aveugle sur un bloc de code imbriqué dans une liste.
    • Recherche et remplacement natifs, directement dans la page en cours d’édition.
    • Annuler et rétablir qui couvrent enfin le formatage, le collage, les pièces jointes et l’autocomplétion — pas seulement le texte brut.
    • Autocomplétion déclenchée par caractère : ! pour une pull request, @ pour une personne, # pour un item de travail, en plus des liens Wiki et des modèles de page.
    • Préférences persistantes pour le retour à la ligne automatique et le défilement synchronisé entre l’édition et l’aperçu.

    Sur le papier, c’est un simple rattrapage : ce sont des fonctionnalités qu’un éditeur de texte sérieux propose depuis longtemps. Dans les faits, pour une équipe qui écrit sa documentation d’architecture, ses runbooks ou ses post-mortems directement dans le Wiki d’Azure DevOps plutôt que dans un outil externe, la différence entre corriger un formatage cassé à la main et un Ctrl+Z qui fonctionne vraiment change l’envie de documenter au jour le jour, pas seulement le confort.

    Pourquoi Monaco précisément

    Monaco est le composant d’édition open source que Microsoft a extrait de VS Code pour le réutiliser ailleurs — dans GitHub.dev, dans le Cloud Shell du portail Azure, et maintenant dans le Wiki. Réutiliser ce composant plutôt qu’un éditeur Markdown générique a un avantage direct : les raccourcis clavier, le comportement de l’autocomplétion et la gestion de la sélection multi-curseur te sont probablement déjà familiers si tu passes tes journées dans VS Code. Rien à réapprendre pour profiter du nouvel éditeur.

    Activer la preview

    Le nouvel éditeur se branche depuis le menu Preview features d’Azure DevOps, activable pour ton compte personnel ou pour toute l’organisation. Une fois activé au niveau organisation, il s’applique à toutes les pages Wiki sans distinction — pas de bascule page par page.

    Microsoft ne communique encore aucune date de disponibilité générale ni de date de fin de preview. Les retours passent par les commentaires du billet officiel ou par le portail Developer Community, le canal habituel pour ce genre de requête produit chez Microsoft.

    Ce que l’annonce ne couvre pas

    Pas un mot sur l’aperçu Markdown en lui-même (il existait déjà avant Monaco et n’a visiblement pas changé), pas de liste d’extensions ou de support de diagrammes, et aucune mention de limitation connue à ce stade de la preview. Si ton Wiki contient beaucoup de tableaux Markdown complexes ou de blocs Mermaid, vérifie leur rendu avant de généraliser l’activation à toute l’organisation — rien dans le billet officiel ne garantit qu’ils aient été spécifiquement testés avec le nouvel éditeur.

    Ce changement s’inscrit dans une tendance plus large sur Azure DevOps cette année : moderniser les interfaces historiques une par une plutôt que de tout refaire d’un coup. On l’a vu récemment avec la nouvelle page de couverture de code des Pipelines, et avec l’arrivée de l’IA dans la revue de pull requests via Copilot Code Review.

    FAQ

    Le nouvel éditeur Wiki est-il disponible sur Azure DevOps Server, la version self-hosted ?

    L’annonce officielle ne mentionne qu’Azure DevOps Services, la version SaaS. Pour Azure DevOps Server, mieux vaut suivre les notes de version dédiées plutôt que de supposer une disponibilité simultanée.

    Est-ce que j’ai besoin de droits d’administration pour l’activer ?

    Pour toi seul, non — l’activation individuelle se fait depuis ton propre menu Preview features. Pour l’activer au niveau de toute l’organisation, il faut les droits d’administration d’organisation.

    Le contenu Markdown existant est-il affecté par le changement d’éditeur ?

    Non, seul le composant d’édition change. Le contenu Markdown stocké reste identique — tu peux désactiver la preview et retrouver l’ancien éditeur sans perte de contenu.

    Si tu gères un Wiki volumineux, le plus simple reste d’activer la preview sur ton compte perso quelques jours avant de la proposer à toute l’équipe — le temps de vérifier que les pages les plus utilisées, runbooks et procédures d’astreinte en tête, s’affichent et s’éditent sans surprise. Les détails complets de l’annonce sont sur le billet officiel Azure DevOps Blog.

  • OpenTofu 1.13 : le chiffrement de state face à Terraform

    OpenTofu 1.13 : le chiffrement de state face à Terraform

    Le 29 septembre 2026, OpenTofu a publié sa version 1.13. Le changelog tient en quatre fonctionnalités mises en avant et quatre changements cassants — rien de spectaculaire sur le papier. Sauf qu’en creusant la partie chiffrement du state, maintenue depuis plusieurs versions mais étendue ici, on retombe sur l’argument le plus concret en faveur d’OpenTofu face à Terraform depuis le fork lui-même : Terraform ne chiffre toujours pas nativement le contenu de son state. Voici ce qui change avec cette version, et pourquoi ça pèse dans la balance si tu hésites encore entre les deux outils.

    Ce qui change avec la 1.13

    Le chiffrement du state gagne trois mécanismes de contexte

    Le bloc encryption dans terraform { } existe depuis plusieurs versions. Sa structure reste la même : un ou plusieurs key_provider, une method qui référence ces clés, puis un bloc state et un bloc plan qui pointent vers cette méthode.

    terraform {
  encryption {
    key_provider "pbkdf2" "mykey" {
      passphrase = var.state_passphrase  # minimum 16 caractères
    }
    method "aes_gcm" "mymethod" {
      keys = key_provider.pbkdf2.mykey
    }
    state {
      method = method.aes_gcm.mymethod
    }
    plan {
      method = method.aes_gcm.mymethod
    }
  }
}

    Les fournisseurs de clés supportés couvrent la quasi-totalité des cas réels : passphrase dérivée via PBKDF2, AWS KMS, GCP KMS, Azure Key Vault, le moteur Transit d’OpenBao (compatible HashiCorp Vault 1.14), et un provider générique external qui exécute ton propre programme — OVHcloud maintient d’ailleurs son propre provider KMS basé sur ce mécanisme.

    La vraie nouveauté de la 1.13 porte sur le contexte de déchiffrement. GCP KMS reçoit un champ additional_authenticated_data, AWS KMS un champ encryption_context, OpenBao un argument associated_data. Dans les trois cas, le principe est identique : la clé seule ne suffit plus à déchiffrer un state. Il faut aussi que le contexte (nom du projet, environnement, équipe…) corresponde. Concrètement, une clé AWS KMS volée ou mal cloisonnée entre deux comptes ne permet plus de déchiffrer le state d’un environnement qui n’est pas le sien.

    Le reste du changelog, en bref

    Windows ARM64 passe en support officiel, avec des binaires publiés directement (certains providers tiers ne suivent pas encore). La fonction convert permet de déclarer explicitement le type attendu d’une valeur inconnue au moment du plan — utile pour calmer le bruit des diffs quand un module retourne une valeur qui ne sera connue qu’à l’apply. Dans le même esprit, les fonctions assume... laissent l’auteur d’un module affirmer une propriété sur une valeur inconnue (non nulle, préfixe donné…) : si l’affirmation est fausse à l’apply, l’opération échoue plutôt que de produire un résultat silencieusement incohérent.

    Deux fonctionnalités expérimentales complètent la liste : un linter activable via le flag -lint sur les commandes qui le supportent, et des « Symbol Libraries », des artefacts réutilisables de valeurs, de fonctions et de types importables depuis les mêmes sources que les modules.

    Ce qui casse en mettant à jour

    Quatre points à vérifier avant de passer en 1.13 :

    • Le provisioner WinRM disparaît complètement pour remote-exec et file — un bloc connection avec type = "winrm" devient une erreur. OpenTofu recommande de migrer vers OpenSSH côté Windows.
    • La sortie de base64gzip change : elle reste équivalente, mais plus identique octet par octet, à cause d’une compression DEFLATE optimisée. Tu peux voir apparaître des diffs sur des arguments qui en dépendent — un ignore_changes temporaire fait l’affaire en attendant.
    • macOS 13 Ventura devient la version minimale supportée pour les builds macOS.
    • La 1.13 est la dernière série à publier des binaires 32 bits (386, arm) officiels — un avertissement s’affiche déjà sur tofu init sur ces plateformes, et la 1.14 ne les inclura plus.

    Et côté Terraform, qu’est-ce qui existe d’équivalent ?

    Rien. C’est la différence structurelle la plus nette entre les deux outils aujourd’hui. La documentation officielle de HashiCorp le dit sans détour : « tu peux chiffrer ton state au repos, mais la méthode de chiffrement dépend de ton backend spécifique ». Sur S3, ça veut dire activer l’option encrypt du backend. Sur GCS, utiliser des clés gérées par le client. Sur HCP Terraform, le chiffrement est automatique. En stockage local, le state reste un fichier en clair, point final — HashiCorp recommande juste de ne jamais le committer et de le traiter comme sensible.

    Ça fonctionne, mais ça reste un chiffrement de transport ou de stockage externe à l’outil, pas un chiffrement du contenu piloté par Terraform lui-même. Si ton backend est mal configuré, ou si quelqu’un récupère une copie du fichier state hors backend (un export, un backup oublié sur un poste), le contenu est lisible — secrets inclus, puisque le state contient souvent des valeurs sensibles en clair malgré les bonnes pratiques.

    On avait déjà creusé la question du choix entre les deux outils dans notre comparatif OpenTofu vs Terraform en 2026, à l’époque surtout sous l’angle licence et écosystème de providers. Un an plus tard, l’écart sur le chiffrement du state mérite d’être ajouté à la liste — pas comme argument décisif à lui seul, mais comme point concret si la sensibilité de ton state (comptes de service, mots de passe de bases de données, clés d’API) te pèse déjà.

    Migrer un projet existant vers le chiffrement OpenTofu

    La bascule n’a rien d’instantané ni d’automatique, et c’est volontaire. Ajoute le bloc encryption à ta configuration, génère une passphrase d’au moins 16 caractères (ou configure ton KMS), passe-la via une variable jamais committée — un coffre de secrets, pas un fichier .tfvars versionné. Au tofu plan suivant, OpenTofu re-chiffre le state existant selon la méthode déclarée ; garde une copie de l’ancien state en lieu sûr avant de lancer l’opération, histoire de pouvoir revenir en arrière si la configuration du provider de clé a un défaut que tu n’as pas vu venir.

    Pour des équipes qui partagent un seul backend entre plusieurs environnements — un cas plus courant qu’il ne devrait l’être, faute de temps pour en séparer les accès — ajouter encryption_context ou additional_authenticated_data dès cette migration coûte une ligne de configuration et change concrètement qui peut lire quoi en cas de fuite de clé.

    FAQ

    Faut-il absolument chiffrer son state si on utilise déjà un backend S3 avec encrypt = true ?

    Ça dépend de ce que tu veux couvrir. Le chiffrement du backend protège le fichier stocké sur S3. Le chiffrement OpenTofu protège le contenu lui-même, y compris s’il sort du backend — une copie locale, un export, un transfert. Les deux ne sont pas redondants, ils couvrent des scénarios de fuite différents.

    Le chiffrement ralentit-il les commandes plan et apply ?

    Le surcoût vient uniquement du chiffrement et du déchiffrement AES-GCM du fichier state, qui reste de taille modeste pour l’écrasante majorité des projets. Sur un state de plusieurs centaines de ressources, la différence n’est pas perceptible à l’usage.

    Est-ce que je peux migrer progressivement, environnement par environnement ?

    Oui, rien n’empêche d’activer le chiffrement sur un seul environnement d’abord — staging, par exemple — pour valider la configuration du key provider avant de la généraliser à la prod.

    OpenTofu 1.13 reste-t-il compatible avec un state produit par Terraform ?

    Oui pour la lecture d’un state existant non chiffré. La bascule vers le chiffrement OpenTofu est une étape volontaire que tu déclenches toi-même, pas un changement de format imposé à l’import.

    Si ton état actuel repose sur un simple encrypt = true côté backend et que tu veux passer à l’étape suivante, la note de version officielle 1.13.0 et le changelog complet sur GitHub listent tout le détail technique nécessaire avant de te lancer. Si tu es encore sur Terraform et que cet article te fait hésiter, on a aussi de quoi suivre ce que la 1.17 bêta de Terraform apporte de son côté avant de trancher.

  • Control plane Kubernetes : trois façons de saturer, pas une seule

    Control plane Kubernetes : trois façons de saturer, pas une seule

    Une requête humaine envoyée à un agent IA en déclenche en moyenne une vingtaine côté infrastructure — c’est le chiffre cité par Bob Killen et Daniel Krook, tous deux directeurs à la CNCF, dans un entretien repris par The New Stack le 16 octobre 2026. Ces agents attendent une réponse en moins de 200 millisecondes, alors qu’un pod Kubernetes n’est garanti de démarrer qu’en environ une seconde. L’écart entre ces deux chiffres, ce n’est pas un détail de perf : c’est en train de redéfinir ce qui fait tomber un control plane.

    Et la réponse n’est pas « trop de nodes ». Joe Betz, tech lead du SIG API Machinery de Kubernetes, a publié via The New Stack une analyse qui mérite d’être lue par quiconque opère un cluster au-delà de quelques centaines de nodes — ou qui commence à y faire tourner des charges d’agents. Son argument : un control plane peut saturer selon trois axes complètement indépendants, et résoudre l’un ne fait strictement rien pour les deux autres.

    Le nombre de nodes n’est que la moitié de l’histoire

    Le réflexe classique, c’est de dimensionner le control plane en fonction du nombre de nodes attendu. Ça marche pour un type de charge précis, mais pas pour les deux autres que décrit Betz. Voici les trois axes, avec les chiffres qu’il donne pour chacun.

    Axe 1 : saturé par les nodes (flottes d’entraînement ML, clusters géants)

    Le symptôme classique : les heartbeats des kubelets finissent par noyer le control plane. Le kube-apiserver consomme de plus en plus de mémoire, et etcd commence à peiner. À 100 000 nodes avec un heartbeat toutes les 10 secondes, le simple maintien en vie (« liveness ») représente déjà environ 10 000 écritures par seconde — et dans les mesures de Betz, le renouvellement des leases (les baux de heartbeat) compte pour près de 70% du débit d’écriture total. Autrement dit : sur un très gros cluster, la majorité de la charge d’écriture d’etcd ne sert à rien d’autre qu’à dire « je suis toujours vivant ». C’est typiquement le profil des flottes d’entraînement ML qui pilotent des GPU via la Dynamic Resource Allocation — beaucoup de nodes, du heartbeat classique, pas forcément beaucoup de churn.

    Axe 2 : saturé par le churn (plateformes d’agents)

    Ici, le nombre de nodes reste modeste, mais le taux de rotation des objets explose. Une session d’agent est une custom resource qu’on crée, suspend, reprend et détruit, potentiellement des milliers de fois par minute. Chaque transition de cycle de vie est une écriture, donc le débit dépend de l’activité des sessions, pas du nombre de machines. C’est précisément l’axe qui devient pertinent avec les plateformes d’agents IA décrites plus haut, même sur un cluster de taille raisonnable.

    Axe 3 : saturé par l’état (clusters de plateforme)

    Beaucoup de types d’objets différents, et des dizaines de milliers d’objets globalement peu actifs — l’exemple donné par Betz évoque environ 200 opérateurs tournant sur le même cluster. Le piège : chaque kube-apiserver maintient un cache de watch complet en mémoire, donc le coût mémoire total se multiplie par le nombre d’instances d’apiserver. Ajouter des apiservers pour tenir la charge de requêtes — un réflexe courant, y compris dans la configuration par défaut de kOps — augmente donc aussi la consommation mémoire globale, pas seulement la capacité.

    Quatre points de découplage, pas une solution miracle

    Betz appelle ça des « seams » : des points de découplage entre composants, en général une frontière réseau, qui permettent de changer une pièce sans toucher au reste. Il en identifie quatre, chacun ciblant un axe précis.

    Point de découplage Ce qu’il contrôle Axe soulagé État
    Contrat de stockage Quel etcd stocke quel type de ressource Churn Le flag --etcd-servers-overrides existe déjà pour les ressources natives — rien d’équivalent pour les custom resources à ce jour
    Contrat de liveness des nodes Comment les heartbeats atteignent le control plane Nombre de nodes Une couche dédiée côté nodes absorbe les renouvellements ; le changement côté etcd (rafraîchir les leases en mémoire plutôt que par un commit Raft complet) bénéficie à tous les clusters
    Axe de sharding Comment contrôleurs, caches et stockage se répartissent les objets Les trois à la fois KEP-5866 propose un filtrage par plage de hash — la coordination entre shards reste un problème ouvert
    Résidence du cache Ce que chaque apiserver garde en mémoire État Un prototype à deux shards réduit le tas mémoire par shard d’environ moitié — pas encore disponible en amont

    Un point que Betz insiste à corriger : etcd n’est pas le problème et ne doit pas être remplacé. Son argument, c’est qu’un stockage consistant généraliste ne devrait simplement pas absorber du trafic qui n’a pas besoin de durabilité forte — les events et les leases de nodes, typiquement.

    L’échelle de recettes, en binaires upstream standards

    Au-delà de la théorie, l’article propose une grille concrète de dimensionnement, composée uniquement à partir de briques déjà disponibles dans Kubernetes upstream :

    • HA classique — jusqu’à 5 000 nodes, 2 à 3 control planes identiques, aucun point de découplage nécessaire. Configuration mesurée en conditions réelles.
    • Role-Split — de 5 000 à 20 000 nodes, des pools de machines séparés pour l’API serving, le scheduler, le controller-manager et etcd. Déjà disponible, bénéfice pas encore formellement mesuré.
    • Node Plane — de 20 000 à 65 000 nodes, Role-Split plus une couche dédiée qui absorbe les baux de heartbeat. Mesuré, sur un seul déploiement de référence.
    • Partitioned Store — autour de 100 000 nodes, Node Plane plus un découpage des types de ressources sur des stockages indépendants. Démontré en externe.
    • Sharded Slice — au-delà, K unités de shard, chacune un contrôleur plus un apiserver épinglé sur une plage de hash. N’existe pas encore en pratique.

    Note que cette logique de répartition par unités indépendantes ressemble, à un niveau d’abstraction différent, à ce que fait Karmada pour répartir une charge sur plusieurs clusters plutôt que sur plusieurs shards d’un même control plane — deux réponses distinctes au même problème de fond : un seul control plane ne peut pas tout absorber indéfiniment.

    Betz le dit sans détour : aucune recette testée à l’échelle n’a encore été publiée pour les clusters churn-bound ou state-bound. Pour le nombre de nodes, le chemin est balisé ; pour le churn et l’état, c’est encore un terrain de recherche.

    Ce que ça change si ton cluster fait 500 nodes, pas 100 000

    Sincèrement, si tu gères un cluster de taille courante, l’axe « nombre de nodes » ne te concerne probablement pas avant longtemps — les seuils dont parle Betz sont ceux des hyperscalers et des plus gros clusters d’entraînement ML. Ce qui change la donne, c’est l’axe churn : dès que tu fais tourner une plateforme d’agents IA, même sur un cluster modeste, le taux de création/destruction d’objets peut grimper très vite, et c’est un axe de saturation complètement indépendant de ta taille de cluster. Le réflexe utile ici n’est pas d’ajouter des nodes au control plane, mais de surveiller le débit d’écriture etcd (etcd_server_proposals_committed_total et la latence de etcd_disk_wal_fsync_duration_seconds sont de bons points de départ côté métriques) avant que ça ne devienne un incident. Sur ce terrain, le pattern RBAC strict et l’allowlist d’outils décrits pour les agents kagent valent aussi la peine d’être appliqués à n’importe quel contrôleur custom qui crée des objets à haute fréquence.

    FAQ

    Mon cluster de 50 nodes peut-il être concerné par ces problèmes ?

    Pas par l’axe « node-bound » décrit ici, qui ne devient critique qu’à très grande échelle. Mais l’axe « churn-bound » peut te toucher dès qu’un contrôleur ou une plateforme d’agents crée et détruit des objets à haute fréquence, indépendamment de la taille du cluster.

    Faut-il arrêter d’ajouter des instances d’apiserver pour tenir la charge ?

    Pas systématiquement, mais il faut savoir ce que ça coûte : chaque apiserver supplémentaire porte son propre cache de watch complet en mémoire. Ça augmente la capacité de traitement des requêtes, mais ça multiplie aussi la consommation mémoire totale du cluster.

    Le flag --etcd-servers-overrides est-il utilisable aujourd’hui ?

    Oui, il est déjà documenté dans la référence officielle kube-apiserver et permet de router des types de ressources natifs vers des backends etcd séparés. Sa limite actuelle : il ne couvre pas les custom resources, qui nécessitent une configuration de stockage par CRD pas encore disponible.

    Où en est KEP-5866 ?

    C’est une proposition d’amélioration encore en phase de prototype, qui ajoute un filtrage par plage de hash pour répartir le trafic API. La coordination entre shards et le sharding du controller-manager restent des problèmes non résolus à ce stade.

    À retenir avant ton prochain audit de capacité

    La prochaine fois qu’un tableau de bord grafana montre un control plane sous tension, résiste à la tentation de regarder uniquement le nombre de nodes. Vérifie le débit d’écriture etcd et sa répartition entre leases, events et objets métier — ça te dira en deux minutes sur quel axe tu es en train de saturer, et donc quel correctif a une chance de fonctionner. Si tu fais déjà tourner une plateforme d’agents ou de CI à forte rotation d’objets sur Kubernetes, ce diagnostic vaut le coup d’être posé maintenant, avant que ça devienne un incident un vendredi soir.

  • CSP sur Entra ID : fin des scripts injectés dès mi-octobre 2026

    CSP sur Entra ID : fin des scripts injectés dès mi-octobre 2026

    Un admin IT installe une extension Chrome qui ajoute un bandeau d’avertissement sur la page de connexion de son organisation, histoire de rappeler aux utilisateurs de vérifier l’URL avant de taper leur mot de passe. Bonne intention, mauvais moment : à partir de la mi-octobre 2026, ce genre d’extension va simplement arrêter de fonctionner sur login.microsoftonline.com, sans message d’erreur visible pour l’utilisateur final. La page de connexion, elle, continuera de marcher normalement.

    C’est l’effet de la nouvelle Content Security Policy (CSP) que Microsoft déploie sur l’expérience de connexion Entra ID. Le changement a été annoncé au Message Center en décembre 2025 (référence MC1191924) et son application globale démarre mi-à-fin octobre 2026, selon la documentation officielle Microsoft Learn. Si tu gères des tenants Entra ID, voici ce qui change concrètement et ce qu’il faut vérifier avant que ça tombe.

    Ce durcissement s’inscrit dans une série de resserrements de la sécurité d’authentification Entra ID en 2026, après le passage des passkeys en méthode d’authentification par défaut cet été. Même logique de fond : réduire la surface d’attaque côté navigateur sans attendre que l’utilisateur agisse.

    Le problème que Microsoft referme

    La cible, c’est l’injection de scripts externes sur la page de connexion : attaque XSS classique, extension de navigateur malveillante, ou simplement un outil tiers qui modifie le DOM de la page pour y ajouter du contenu. Dans les trois cas, du code qui n’a pas été écrit par Microsoft s’exécute dans le contexte de la page où l’utilisateur tape son mot de passe. Les conséquences possibles sont connues : vol de identifiants ou de tokens, prise de contrôle de session, ou simplement perte de confiance si la page de connexion se comporte de façon inattendue.

    Microsoft précise dans sa documentation que les mécanismes existants (filtrage côté navigateur, protections natives d’Entra ID) restent la première ligne de défense. La CSP s’ajoute en profondeur, pour les cas où un script arrive malgré tout à s’injecter — via une extension installée localement ou une faille zero-day. Le principe d’une CSP, détaillé par l’OWASP Cheat Sheet dédiée, est simple : une liste blanche de domaines et de scripts autorisés, tout le reste est bloqué par défaut, sans exception.

    La presse spécialisée en sécurité a repris l’annonce quelques jours avant son entrée en vigueur — BleepingComputer note que la majorité des violations observées par Microsoft en amont provenaient d’extensions de navigateur tierces, pas d’attaques ciblées.

    Ce qui change exactement

    Concrètement, Microsoft Entra ID impose un en-tête CSP qui n’autorise à s’exécuter que les scripts provenant de domaines Microsoft de confiance. Trois précisions importantes, directement issues de la documentation officielle :

    • L’application ne concerne que les connexions via navigateur, sur login.microsoftonline.com précisément. Les autres domaines ne sont pas touchés par ce changement.
    • Les flux basés sur MSAL (Microsoft Authentication Library) qui interrogent directement les API du service de jetons de sécurité (STS) d’Entra ID ne sont pas affectés, puisque l’application se limite à l’URL de connexion navigateur.
    • Les clients Microsoft Entra External ID utilisant un domaine personnalisé ou un domaine CIAM ne sont pas impactés non plus.

    Si ton organisation n’utilise aucun outil ni extension qui injecte du code dans la page de connexion, l’expérience ne change strictement rien pour tes utilisateurs — Microsoft le dit explicitement, et c’est le cas de la grande majorité des tenants. Le changement vise les 10-15% de cas où un outil tiers s’appuie sur cette pratique, d’après l’analyse de Microsoft sur l’origine des violations qu’elle observe actuellement en amont du rollout.

    Qui risque d’être concerné

    D’après les retours déjà documentés, les cas les plus fréquents de script injecté sur une page de connexion sont :

    • des extensions de navigateur de sécurité ou de productivité (gestionnaires de mots de passe tiers, outils de monitoring, bloqueurs de contenu) qui modifient le DOM des pages visitées ;
    • des outils de supervision ou de test (certains frameworks d’automatisation UI, des extensions de débogage) laissés actifs en dehors d’un contexte de développement ;
    • des solutions de marque blanche ou de personnalisation visuelle qui injectent du JavaScript plutôt que de passer par les mécanismes de branding natifs d’Entra ID (logo, bandeau, texte personnalisé — ces options-là restent disponibles et ne sont pas concernées par la CSP).

    Le point à retenir : ce n’est pas ta personnalisation de marque qui casse, c’est tout ce qui s’exécute en JavaScript injecté par-dessus la page plutôt que configuré nativement.

    Comment tester ton tenant avant le rollout

    Microsoft Learn détaille une méthode de test simple, à faire dès maintenant plutôt que d’attendre le jour J :

    1. Ouvre la console développeur de ton navigateur (F12 sous Chrome ou Edge) avant de lancer un flux de connexion vers ton tenant.
    2. Déroule un parcours de connexion complet en gardant la console ouverte.
    3. Repère les violations CSP, qui s’affichent en rouge dans la console et identifient précisément le script bloqué et son origine.
    4. Répète le test avec les différents profils et postes utilisés dans ton organisation (extensions installées, outils de support, postes partagés) — une violation causée par l’extension d’une seule équipe ne remontera que sur les parcours de connexion de cette équipe.

    Si un outil tiers déclenche une violation, la recommandation officielle est de contacter l’éditeur pour obtenir une version compatible avec la CSP, plutôt que de chercher un contournement — il n’y a pas d’option tenant pour désactiver cette CSP, contrairement à ce qu’on peut faire sur un site Power Pages par exemple.

    FAQ

    Est-ce que ça bloque la connexion des utilisateurs ?

    Non. Les utilisateurs peuvent continuer à se connecter normalement même si un script tiers est bloqué par la CSP. Ce qui casse, c’est le comportement ajouté par ce script précis (bandeau, overlay, tracking) — pas le flux d’authentification lui-même.

    Faut-il activer quelque chose dans le tenant ?

    Non, l’application est activée par défaut, sans configuration côté tenant. C’est justement l’absence de bouton pour la désactiver qui en fait une protection fiable à l’échelle de tous les tenants Entra ID — mais ça veut aussi dire qu’il faut tester en amont, pas réagir après coup.

    Mes personnalisations de marque (logo, couleurs) vont-elles disparaître ?

    Non, les mécanismes de branding natifs d’Entra ID (Company Branding) ne passent pas par de l’injection de script et ne sont pas concernés.

    Et si on utilise MSAL pour une appli custom ?

    Pas d’impact. L’application de la CSP se limite à la page de connexion navigateur sur login.microsoftonline.com ; les flux MSAL qui parlent directement aux API du STS Entra ID restent inchangés.

    Ce qu’il faut faire cette semaine

    Si tu n’as encore rien testé, le test console décrit plus haut prend cinq minutes et peut t’éviter un ticket de support en pleine mi-octobre. Fais-le sur un compte de test avec les extensions réellement utilisées par tes équipes support et sécurité — c’est là que se cachent la plupart des violations, pas dans la configuration Entra ID elle-même. Si ton organisation personnalise déjà la page de connexion via les Conditional Access ou le Company Branding plutôt que du script injecté, cette échéance ne te concerne tout simplement pas.

    Et si tes politiques de Conditional Access couvrent déjà des identités non humaines (agents IA, comptes de service), ça vaut le coup de revérifier leur posture pendant que tu y es — on a détaillé comment sécuriser les identités d’agents IA dans Entra ID dans un article précédent.

  • FOCUS 1.3 : la spec FinOps règle enfin le casse-tête des coûts partagés

    FOCUS 1.3 : la spec FinOps règle enfin le casse-tête des coûts partagés

    Sur AKS, un pod peut consommer du CPU, de la mémoire et de la bande passante sans qu’aucune ligne de facturation Azure ne le dise explicitement : la facture arrive au niveau du nœud, pas du pod. Répartir ce coût entre les équipes qui partagent le cluster reste, encore aujourd’hui, un bricolage de tags et de règles maison. C’est précisément ce que la FinOps Foundation a cherché à corriger avec la version 1.3 de sa spécification FOCUS, ratifiée le 5 décembre 2025.

    Le problème : un coût, plusieurs consommateurs

    FOCUS (FinOps Open Cost and Usage Specification) normalise le format des données de facturation cloud pour que les mêmes requêtes fonctionnent chez AWS, Azure, GCP ou un fournisseur SaaS. On avait détaillé la version 1.2 et son arrivée dans Azure Cost Management dans cet article. Mais la 1.2 ne disait rien de précis sur la répartition des coûts partagés, pods Kubernetes, instances de base de données mutualisées, chaque fournisseur appliquant sa propre logique, non documentée, non comparable d’un cloud à l’autre.

    Ce que la 1.3 ajoute concrètement

    Split cost allocation calculé par le fournisseur

    Le dataset Cost and Usage passe à 65 colonnes avec cette version, selon la spécification officielle, et une partie sert justement à exposer la méthode de répartition qu’utilise le fournisseur de données, plutôt que de laisser chaque équipe FinOps deviner. L’exemple donné par la fondation : le coût d’une VM sous-jacente peut désormais être ventilé entre les pods Kubernetes qui tournent dessus, sans ressaisie manuelle.

    Contract Commitments : un dataset séparé

    Les engagements contractuels (dates de début/fin, unités restantes, descriptions) sortent du dataset de coûts et d’usage pour former leur propre jeu de données, avec 13 colonnes dédiées. Logique : ces informations sont souvent plus sensibles (négociation, remises) et méritent des permissions d’accès distinctes de celles appliquées à la facturation courante.

    Recency et Completeness

    Chaque dataset doit désormais porter un horodatage de dernière mise à jour et un statut de complétude. Sans ça, impossible de savoir si une ligne de coût est définitive ou encore sujette à révision, un problème classique avec les coûts cloud, souvent réajustés après coup (remises rétroactives, corrections de facturation).

    Service Provider vs Host Provider

    Les colonnes historiques Provider et Publisher restent lisibles en 1.3 mais passent en dépréciées, elles disparaîtront en 1.4. Elles sont remplacées par une distinction plus fine entre le fournisseur qui vend la ressource et celui qui l’héberge réellement, utile dès qu’il y a de la revente dans la chaîne (marketplace, CSP, reseller).

    Le support vendor n’a pas encore rattrapé le papier

    Selon le communiqué de la Linux Foundation, AWS a annoncé la disponibilité générale de FOCUS 1.2 au moment de cette sortie. Microsoft et Google sont cités comme contributeurs à la 1.3, de même qu’Alibaba, Databricks, Grafana, Huawei, Oracle Cloud Infrastructure, OVHcloud et Tencent, mais sans qu’aucun d’eux confirme publiquement un export FOCUS 1.3 disponible à ce jour. Concrètement : Azure Cost Management exporte en FOCUS 1.2 (voir l’article dédié ci-dessus), pas encore en 1.3. Avant de refaire tes dashboards de répartition de coûts autour des nouvelles colonnes, vérifie d’abord ce que ton export Azure/AWS/GCP expose réellement : le Validator 2.0 de la fondation ne couvre lui-même que les exigences de la 1.2 pour l’instant.

    Et la 1.4, déjà en préparation

    La fondation travaille déjà sur la 1.4, avec un dataset de factures FOCUS et des dimensions de contrat élargies, annoncée selon le blog officiel de la FinOps Foundation en parallèle d’un nouveau projet, Tokenomicon, pensé pour la gouvernance des coûts de tokens IA. Si tu ne factures pas encore d’inférence LLM à l’échelle, ce n’est pas la priorité : la répartition des coûts partagés de la 1.3 a plus de valeur immédiate pour un cluster Kubernetes ou une flotte de bases de données mutualisées que les tokens IA de la 1.4.

    Ce que ça change pour ton reporting

    Si ton fournisseur expose déjà du FOCUS 1.2, la bascule vers 1.3 demande surtout d’ajouter les nouvelles colonnes de répartition à tes requêtes existantes : le format de base ne change pas de philosophie. En revanche, séparer les Contract Commitments dans tes modèles de reporting vaut la peine d’être anticipé maintenant, avant que ton équipe sécurité ne pose la question des permissions d’accès aux clauses contractuelles.

    FAQ

    FOCUS 1.3 est-il rétrocompatible avec la 1.2 ?

    Oui pour l’essentiel : les colonnes Provider et Publisher de la 1.2 restent lisibles en 1.3, simplement marquées comme dépréciées en vue de leur retrait en 1.4.

    Azure expose-t-il déjà du FOCUS 1.3 ?

    Pas à notre connaissance au moment de la rédaction : Microsoft est cité comme contributeur à la 1.3, mais Azure Cost Management reste documenté sur la 1.2.

    Faut-il migrer ses dashboards dès maintenant ?

    Seulement si ton fournisseur expose déjà les nouvelles colonnes. Sinon, la priorité reste de vérifier la couverture FOCUS de ton export actuel avant d’investir du temps sur une version pas encore disponible côté data.

    Si tu gères des coûts Kubernetes ou des bases partagées entre équipes, surveille l’annonce du support FOCUS 1.3 côté Azure/AWS/GCP dans les prochains mois : c’est là que la répartition des coûts partagés deviendra enfin automatisable plutôt que bricolée en interne.