Ctrl+Alt+Prod

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

  • PSResourceGet : dis adieu à PowerShellGet v2 pour gérer tes modules

    PSResourceGet : dis adieu à PowerShellGet v2 pour gérer tes modules

    Si tu tapes encore Install-Module par réflexe, il est temps de regarder ce qui a changé. Depuis PowerShell 7.4, un nouveau module gère l’installation et la publication de packages : PSResourceGet. Il est désormais le standard embarqué dans PowerShell 7.6 LTS, pendant que PowerShellGet v2 et PackageManagement entrent doucement en fin de vie. Si tu gères des scripts, des modules internes ou des pipelines CI/CD qui installent des dépendances PowerShell, voici ce qui change concrètement et comment migrer sans tout casser.

    Pourquoi PowerShellGet v2 arrive en fin de course

    PowerShellGet v2 et son compagnon PackageManagement datent d’une époque où PowerShell tournait encore essentiellement sous Windows, avec un modèle de providers hérité qui complique la maintenance et ralentit les opérations sur de gros catalogues de modules. Microsoft a retravaillé ce socle de zéro avec Microsoft.PowerShell.PSResourceGet, disponible depuis PowerShell 7.4.0 et embarqué par défaut avec PowerShell 7.6 (voir notre article sur la migration vers PowerShell 7.6 LTS) : plus rapide, pensé cross-platform dès le départ, et compatible avec le protocole NuGet v3.

    Ce que PSResourceGet change concrètement

    Le changement le plus visible est la disparition du modèle de providers au profit d’un accès direct aux dépôts NuGet, ce qui se traduit par des opérations nettement plus rapides sur la PowerShell Gallery ou sur tes dépôts internes. Les cmdlets ont aussi été simplifiées : au lieu d’avoir des commandes séparées pour les modules et les scripts, PSResourceGet unifie tout sous une seule famille de verbes.

    PowerShellGet v2 PSResourceGet
    Find-Module / Find-Script Find-PSResource
    Install-Module / Install-Script Install-PSResource
    Update-Module Update-PSResource
    Publish-Module / Publish-Script Publish-PSResource
    Register-PSRepository Register-PSResourceRepository

    Migrer en pratique

    Vérifier ce qui est déjà en place

    Sur PowerShell 7.4 et plus, PSResourceGet est déjà présent. Vérifie la version installée et mets-la à jour si besoin, la Gallery reçoit des correctifs régulièrement :

    Get-Module -Name Microsoft.PowerShell.PSResourceGet -ListAvailable
Install-PSResource -Name Microsoft.PowerShell.PSResourceGet -Scope AllUsers -Reinstall

    Récupérer tes dépôts existants

    Si tu as des dépôts NuGet enregistrés sous PowerShellGet v2 (un flux Azure Artifacts interne, par exemple), pas besoin de tout ressaisir à la main : Import-PSGetRepository les reprend automatiquement, à l’exception du dépôt PSGallery par défaut qui est déjà préconfiguré.

    Import-PSGetRepository -Force
Get-PSResourceRepository

    Adapter tes scripts et tes pipelines CI/CD

    Remplace tes appels Install-Module par Install-PSResource dans tes scripts de bootstrap et tes jobs CI/CD. La syntaxe reste proche, avec quelques différences à connaître : Install-PSResource ne charge plus automatiquement le module dans la session courante après installation, il faut un Import-Module explicite. Pour des installations reproductibles avec un fichier de dépendances versionné, utilise le paramètre RequiredResourceFile plutôt que d’égrainer les installations une par une :

    Install-PSResource -RequiredResourceFile ./requirements.psd1 -TrustRepository

    C’est particulièrement utile dans une pipeline CI/CD où tu veux un comportement déterministe et reproductible d’un run à l’autre. Si tu es justement en train de revoir la sécurité de tes pipelines, ça vaut le coup de coupler cette migration à un audit plus large : on détaille les bonnes pratiques (épinglage par digest, SBOM, authentification sans secret) dans notre article sur la sécurisation des pipelines CI/CD après les attaques supply chain de 2026.

    Points de vigilance avant de migrer ton parc

    PSResourceGet a encore quelques limitations à connaître avant de basculer en masse. Contrairement à Install-Module, Install-PSResource ne résout pas encore automatiquement les dépendances des ressources provenant de dépôts utilisant le protocole NuGet v3 — tu dois les installer individuellement dans ce cas précis, en attendant que Microsoft comble cet écart dans une future version. Teste aussi tes scripts d’automatisation existants qui s’appuient sur le nom exact des anciennes cmdlets : si tu n’as pas encore migré ces appels, ils continuent de fonctionner (PowerShellGet v2 reste installable en parallèle), mais autant profiter de la bascule vers 7.6 LTS pour nettoyer.

    FAQ

    PowerShellGet v2 va-t-il cesser de fonctionner du jour au lendemain ?

    Non, aucune date de retrait n’est annoncée à ce stade et les deux modules peuvent cohabiter. Mais tout le développement actif se concentre désormais sur PSResourceGet, donc mieux vaut planifier la migration plutôt que la subir.

    Dois-je réinstaller tous mes modules après la migration ?

    Non, PSResourceGet fonctionne avec les modules déjà installés sur ta machine, quelle que soit la méthode utilisée à l’origine. La migration concerne la façon dont tu installes et gères tes modules à l’avenir, pas ce qui est déjà en place.

    PSResourceGet fonctionne-t-il sur PowerShell 5.1 ?

    Oui, le module est également disponible pour Windows PowerShell 5.1 via la PowerShell Gallery, même s’il est pensé et optimisé en priorité pour PowerShell 7.x.

    Passe à l’action

    Si tu migres déjà vers PowerShell 7.6 LTS, c’est le bon moment pour basculer aussi ta gestion de modules vers PSResourceGet : commence par un environnement de test, importe tes dépôts existants, puis remplace progressivement tes appels Install-Module dans tes scripts les plus critiques. Le gain en vitesse et en fiabilité se fait sentir dès les premières exécutions, surtout si tu gères un grand nombre de modules internes.

  • Sécurité des pipelines CI/CD en 2026 : les leçons des attaques supply chain de mars

    Sécurité des pipelines CI/CD en 2026 : les leçons des attaques supply chain de mars

    En mars 2026, quatre outils utilisés quotidiennement dans des pipelines CI/CD partout dans le monde — Trivy, Checkmarx KICS, LiteLLM et une dépendance de axios — se sont retrouvés compromis en l’espace de deux semaines. Pas des outils obscurs : des scanners de sécurité et des librairies que des dizaines de milliers d’équipes exécutent en confiance, sans y penser, à chaque build. Si ta pipeline CI/CD ressemble à la plupart — des actions tierces épinglées sur un tag, des secrets stockés en clair, aucune vérification de provenance sur ce qui sort en production — ces incidents te concernent directement. On fait le point sur ce qui s’est passé, les schémas d’attaque qui reviennent, et surtout les défenses concrètes à mettre en place sur Azure DevOps ou GitHub Actions.

    Ce qui s’est passé en mars 2026

    Entre le 19 et le 31 mars 2026, une série de compromissions a touché des composants au cœur de nombreuses pipelines CI/CD, comme l’a documenté l’analyse post-mortem publiée par GitLab :

    • Trivy, le scanner de vulnérabilités utilisé dans d’innombrables jobs de scan de conteneurs, a été compromis par un malware volant les secrets présents dans l’environnement d’exécution.
    • Checkmarx KICS, un scanner IaC largement utilisé pour auditer du Terraform et du Bicep, a subi une injection similaire de vol de credentials.
    • LiteLLM, une passerelle vers des API de LLM de plus en plus intégrée dans les workflows d’automatisation, a livré des versions PyPI trojanisées contenant des backdoors.
    • Une dépendance transitive de axios (le module plain-crypto-js) s’est révélée malveillante, touchant potentiellement tout projet JavaScript qui l’incluait sans le savoir.

    Un cinquième incident, distinct mais révélateur du même laxisme ambiant, a montré des source maps npm non filtrées exposant du code source en production.

    Trois schémas d’attaque qui reviennent

    Ce n’est pas un hasard si ces incidents se ressemblent. Ils exploitent trois failles structurelles qu’on retrouve dans la grande majorité des pipelines :

    La confiance implicite envers les outils et actions

    Une action GitHub référencée par un tag mutable (@v3 plutôt qu’un digest de commit), une image Docker tirée par son tag latest, un scanner installé sans vérification de checksum : autant de points où tu fais confiance à ce qui a été publié la dernière fois que tu as regardé, pas à ce qui tourne réellement aujourd’hui.

    Les erreurs de configuration

    Artefacts de debug oubliés dans un build de production, logs verbeux qui exposent des tokens, permissions de pipeline trop larges par défaut — ces erreurs classiques transforment une simple compromission d’outil en fuite de données complète.

    La propagation par dépendances transitives

    Tu audites peut-être tes dépendances directes. Mais une seule version compromise, plusieurs niveaux en dessous dans l’arbre de dépendances, se propage silencieusement à tout ce qui en dépend — comme l’a montré l’incident axios.

    Les défenses concrètes à mettre en place

    Passer à une authentification sans secret

    La première chose qu’un attaquant cherche dans une pipeline compromise, ce sont des secrets à long terme : tokens Azure, clés d’API, mots de passe de service principal. La parade recommandée par Microsoft dans le Cloud Adoption Framework est de basculer sur l’authentification par fédération d’identité (OpenID Connect) pour tes connexions de service Azure DevOps comme pour tes workflows GitHub Actions — plus aucun secret client à stocker, donc plus rien à voler. On a détaillé la mise en œuvre côté Azure DevOps dans notre article sur la fédération d’identité pour les service connections.

    Épingler aux digests, jamais aux tags

    Un tag comme actions/checkout@v4 peut techniquement pointer vers un commit différent demain si le mainteneur (ou un attaquant ayant compromis son compte) le déplace. Épingler sur le digest SHA immuable (actions/checkout@a1b2c3d...) garantit que tu exécutes exactement le code que tu as audité, pas une version substituée après coup. Le même principe s’applique à tes images de base Docker : préfère un digest à un tag latest ou même à un tag de version.

    Générer un SBOM et scanner tes dépendances en continu

    Un inventaire à jour de tout ce qui compose ton build (SBOM — Software Bill of Materials) est ce qui te permet de répondre en quelques minutes, et non en plusieurs jours, à la question « est-ce qu’on utilise le composant compromis ?» le jour où un incident comme celui de mars 2026 est annoncé. Couplé à une analyse de composition logicielle (SCA) et à des outils comme Dependabot pour la mise à jour automatique des dépendances vulnérables, c’est la base d’une hygiène supply chain sérieuse.

    Vérifier la provenance de ce que tu déploies

    Les attestations de provenance (SLSA, Supply-chain Levels for Software Artifacts) permettent de prouver cryptographiquement qu’un artefact a bien été construit par ta pipeline, à partir du code source attendu, et qu’il n’a pas été substitué entre le build et le déploiement. GitHub propose nativement les Artifact Attestations, qui permettent d’atteindre le niveau SLSA 3 sans infrastructure supplémentaire à opérer toi-même. Encore émergent début 2026 mais à surveiller de près : les fonctionnalités de type « Dependency Firewall » qui bloquent automatiquement l’installation de versions connues comme compromises, avant même l’exécution du job.

    Isoler tes runners self-hébergés

    Un runner self-hosted partagé entre plusieurs projets, avec un accès réseau large et une identité trop permissive, est une cible de choix : une seule pipeline compromise donne potentiellement accès à tout ce que ce runner peut atteindre. Isole tes runners par niveau de confiance (production vs. développement), limite leurs permissions réseau sortantes, et évite de leur attacher des identités managées avec des droits qui dépassent largement ce dont un job donné a besoin.

    Une checklist pour ta prochaine revue de pipeline

    Avant ta prochaine passe de sécurisation, vérifie que tu coches ces points, qu’on ait affaire à GitHub Actions, Azure Pipelines ou GitLab CI :

    • Aucun secret à longue durée de vie dans les pipelines : authentification via OIDC / workload identity federation partout où c’est possible
    • Actions et images tierces épinglées par digest, pas par tag
    • SBOM généré à chaque build et scan de dépendances actif (Dependabot ou équivalent)
    • Attestations de provenance activées sur les artefacts qui partent en production
    • Approbations obligatoires sur les modifications de configuration CI/CD elle-même, pas seulement sur les déploiements
    • Runners self-hébergés isolés par niveau de confiance, avec des permissions réseau et des identités minimales

    FAQ

    Le passage aux digests casse-t-il les mises à jour automatiques de dépendances ?

    Non, à condition d’utiliser un outil comme Dependabot ou Renovate qui sait résoudre et mettre à jour les digests automatiquement via des pull requests — tu gardes la traçabilité et la revue humaine, sans revenir à un tag mutable.

    Faut-il migrer toutes les pipelines d’un coup ?

    Non, commence par les pipelines qui déploient en production et celles qui manipulent des secrets sensibles. L’authentification sans secret et l’épinglage par digest sont les deux mesures avec le meilleur ratio effort/impact pour démarrer.

    Les attestations SLSA sont-elles seulement pour GitHub Actions ?

    Le concept est indépendant de la plateforme : GitHub propose une implémentation native, mais des équivalents existent ou émergent pour Azure Pipelines et GitLab CI via des outils tiers comme Sigstore/cosign.

    Passe à l’action

    Les incidents de mars 2026 n’ont épargné personne parce qu’ils ciblaient l’angle mort classique : la confiance aveugle envers ce qui tourne « habituellement » dans une pipeline. Prends une heure cette semaine pour auditer tes connexions de service, vérifie si tes actions critiques sont épinglées par tag ou par digest, et active un scan de dépendances si ce n’est pas déjà fait. Ce sont trois changements simples qui réduisent drastiquement ta surface d’attaque, sans ralentir tes déploiements.

  • Patch Tuesday septembre 2026 : 974 failles, 2 zero-days à patcher

    Patch Tuesday septembre 2026 : 974 failles, 2 zero-days à patcher

    Le Patch Tuesday de septembre 2026 vient de battre un record peu enviable : 974 vulnérabilités corrigées en un seul mois, dont deux zero-days activement exploités. Si tu gères des serveurs Windows, des contrôleurs de domaine ou de l’infrastructure Azure, voici ce qu’il faut retenir pour prioriser tes déploiements sans te noyer dans la liste complète des CVE.

    Un volume de correctifs inédit

    Microsoft a corrigé 974 failles ce mois-ci, contre 570 en juillet et 400 en août 2026 — une hausse en partie attribuée au déploiement d’un système de découverte de vulnérabilités assisté par IA côté Microsoft. La répartition donne une idée de l’ampleur : 113 vulnérabilités critiques et 860 importantes, avec 253 failles d’exécution de code à distance (RCE) et 438 d’élévation de privilèges. Les zones les plus touchées : composants Windows (Hyper-V, DNS Server, ALPC), Office, SQL Server, Exchange Server, et les services cloud (Entra ID, Azure).

    Les deux zero-days activement exploités

    Deux failles sont d’ores et déjà exploitées dans la nature — c’est elles qu’il faut patcher en tout premier, avant même de regarder le reste de la liste.

    CVE-2026-81963 — Windows Update Stack, élévation de privilèges

    Une faille de résolution de lien qui permet à un attaquant d’obtenir des privilèges SYSTEM. C’est la première vulnérabilité d’élévation de privilèges du Windows Update Stack exploitée dans la nature depuis 2022 — un composant qui, par nature, tourne avec des droits élevés sur quasiment toutes les machines Windows du parc.

    CVE-2026-85880 — Windows ALPC, élévation de privilèges

    Un dépassement de tampon basé sur le tas (heap overflow) dans l’Advanced Local Procedure Call de Windows, exploitable localement pour obtenir SYSTEM. C’est le premier correctif touchant l’ALPC en plus de trois ans, et le deuxième zero-day sur ce composant depuis janvier 2023 — un signal que cette surface d’attaque reste activement ciblée par les chercheurs offensifs comme par les attaquants.

    Les autres CVE critiques à ne pas laisser traîner

    • CVE-2026-69730 — Windows DNS Server, RCE, CVSS 9.8, « exploitation plus probable » selon Microsoft. Si tu exposes un DNS Server Windows, en particulier sur un contrôleur de domaine, ce correctif passe avant tout le reste.
    • CVE-2026-69676 — Windows Kerberos, RCE, CVSS 8.8. Kerberos étant au cœur de l’authentification Active Directory, une exploitation réussie a un impact potentiellement massif sur l’ensemble du domaine.

    Comment prioriser sans tout patcher en urgence le même jour

    Avec près de 1000 correctifs, il est illusoire de vouloir tout déployer en une nuit. Voici l’ordre de priorité qui ressort de l’analyse des éditeurs de sécurité (Qualys, Tenable, CrowdStrike) :

    1. Immédiat : les deux zero-days (CVE-2026-81963 et CVE-2026-85880) sur l’ensemble du parc Windows, en particulier les machines avec des privilèges élevés ou exposées à des réseaux non fiables. Priorité absolue aux contrôleurs de domaine et à l’infrastructure d’authentification, puisque l’ALPC touche des processus Windows centraux.
    2. Haute priorité : les RCE critiques exposées côté réseau — DNS Server (CVE-2026-69730) et Kerberos (CVE-2026-69676) — ainsi qu’Exchange Server et les applications Office directement exposées à du contenu externe.
    3. Priorité secondaire : élévations de privilèges locales sans exploitation connue, divulgations d’information, et vulnérabilités de déni de service.

    Comme toujours sur un volume aussi important, teste en environnement non-production avant un déploiement large, surtout pour les correctifs touchant des composants aussi sensibles que l’ALPC ou le DNS Server.

    Automatiser le déploiement plutôt que courir après chaque Patch Tuesday

    Si ton parc de postes Windows dépend encore de campagnes de patch manuelles, c’est le bon moment pour regarder du côté de Windows Autopatch, qui gère désormais le hotpatching par défaut et priorise automatiquement les correctifs de sécurité critiques sans redémarrage complet pour une bonne partie des CVE mensuelles — on en parlait plus en détail dans notre article sur l’évolution d’Intune et du bundling M365 E3/E5. Pour les contrôleurs de domaine et l’infrastructure Windows Server, notre guide sur les changements sécurité d’Active Directory dans Windows Server 2025 complète bien la priorisation ci-dessus.

    FAQ

    Faut-il patcher en urgence même hors fenêtre de maintenance habituelle ?

    Pour les deux zero-days activement exploités, oui — un déploiement hors cycle est justifié sur les systèmes à risque (contrôleurs de domaine, serveurs exposés), quitte à planifier un redémarrage en heures creuses plutôt que d’attendre la prochaine fenêtre mensuelle.

    Le volume record de ce mois signifie-t-il que Windows est devenu moins sûr ?

    Pas nécessairement — la hausse est en grande partie due à l’intensification des efforts de découverte de vulnérabilités par Microsoft lui-même (recherche interne assistée par IA), ce qui tend plutôt à réduire le nombre de failles non découvertes exploitables par des tiers. Ça ne change rien à l’urgence de patcher, en revanche.

    Où suivre les détails techniques de chaque CVE ?

    Le security update guide officiel de Microsoft reste la référence pour le détail CVE par CVE ; les analyses d’éditeurs comme Tenable ou Qualys sont utiles pour une lecture priorisée rapide.

    En résumé

    Deux CVE à patcher aujourd’hui (CVE-2026-81963, CVE-2026-85880), deux RCE critiques à ne pas laisser traîner plus de quelques jours (DNS Server, Kerberos), et un volume global qui justifie plus que jamais un déploiement automatisé et priorisé plutôt qu’une gestion manuelle mois par mois. Si ce n’est pas déjà fait, c’est l’occasion de vérifier que ton dispositif de patch management priorise automatiquement les CVE avec exploitation active — c’est ce qui fait la différence entre un incident évité et un incident subi.

  • Service connections Azure DevOps : passe à la fédération d’identité

    Service connections Azure DevOps : passe à la fédération d’identité

    Si tes pipelines Azure DevOps utilisent encore des service connections basées sur un service principal avec secret ou pire, un Personal Access Token planqué dans une variable « secrète », tu portes une dette de sécurité qui n’a plus vraiment de raison d’être en 2026. Microsoft pousse depuis plusieurs mois une alternative sans secret, la Microsoft Entra Workload Identity Federation, désormais l’approche recommandée pour authentifier tes pipelines auprès d’Azure et même d’autres organisations Azure DevOps. Dans cet article, tu vas voir pourquoi ce changement compte, comment le mettre en place concrètement, et les pièges classiques à éviter.

    Si tu es en train de revoir la façon dont tes pipelines s’exécutent, ça vaut aussi le coup de relire notre article sur les Managed DevOps Pools et la fin de la maintenance des agents : les deux sujets touchent à la même logique de simplification et de sécurisation de l’exécution de tes pipelines.

    Le problème avec les service connections « classiques »

    Une service connection Azure Resource Manager basée sur un service principal avec secret, c’est un identifiant et une chaîne secrète stockés côté Azure DevOps, avec une date d’expiration à surveiller manuellement. Deux soucis récurrents en découlent :

    • Le secret doit être renouvelé régulièrement, et un oubli casse silencieusement tous les pipelines qui en dépendent, souvent un lundi matin.
    • Le secret circule (portail Entra, connexion Azure DevOps, parfois des exports de configuration), ce qui élargit la surface d’attaque en cas de fuite.

    Un Personal Access Token utilisé comme raccourci pose le même genre de problème, en pire : il est souvent lié à un compte personnel, avec des droits plus larges que nécessaire.

    Ce que change le Workload Identity Federation

    Avec la fédération d’identité, Azure DevOps n’a plus besoin de connaître un secret. Le pipeline s’authentifie via un jeton JWT éphémère, émis à la volée, vérifié par Microsoft Entra ID via une relation de confiance fédérée établie une fois pour toutes entre ton organisation Azure DevOps et ton tenant Entra. Concrètement, ça t’évite :

    • de créer, stocker ou faire tourner un secret quel qu’il soit ;
    • les pannes de pipeline liées à une expiration de secret non anticipée ;
    • une bonne partie de la surface d’exposition en cas de fuite de configuration, puisqu’il n’y a simplement rien à voler.

    Autre bénéfice concret : la fédération permet aussi de connecter proprement une organisation Azure DevOps à une autre organisation Azure DevOps (par exemple pour aller chercher un repo externe ou publier sur un flux d’artefacts partagé), sans passer par un PAT partagé entre équipes.

    Mettre en place une service connection fédérée

    La documentation officielle Microsoft détaille la procédure complète (Access Azure DevOps with Microsoft Entra workload identity), mais voici l’essentiel.

    1. Ajouter le service principal ou la managed identity à l’organisation

    Dans Organization Settings > Users > Add users, tu ajoutes l’identité (par son nom ou son Object ID Entra) avec un access level Basic, et tu l’assignes à un groupe avec les droits minimum nécessaires — évite de la mettre directement dans Project Collection Administrators par facilité.

    2. Créer la connexion de service

    Dans Project Settings > Service connections > New service connection, tu choisis le type Azure Resource Manager (ou Azure DevOps pour un accès cross-org) puis l’option workload identity federation, et tu sélectionnes l’identité créée à l’étape précédente.

    3. L’utiliser dans un pipeline YAML

    steps:
- task: AzureCLI@3
  inputs:
    connectionType: 'azureDevOps'
    azureDevOpsServiceConnection: 'my-azdo-connection'
    scriptType: 'pscore'
    inlineScript: |
      az devops project list --query "value[].{Name:name, Id:id}" -o table

    Pour authentifier un flux d’artefacts NuGet, c’est tout aussi direct :

    - task: NuGetAuthenticate@1
  inputs:
    nuGetServiceConnections: 'my-azdo-connection'

    Managed identity ou service principal : lequel choisir ?

    Les deux fonctionnent avec la fédération, mais la durée de vie du jeton diffère : environ 1h pour un service principal, contre 24h pour une managed identity. Si tes pipelines enchaînent des étapes longues (build + déploiement + tests d’intégration qui dépassent l’heure), préfère une managed identity pour éviter une expiration en plein milieu d’exécution.

    Pièges et limitations à connaître

    • Applications multi-tenant non supportées : configure ton app registration Entra en AzureADMyOrg, pas en AzureADMultipleOrgs.
    • AADSTS700238 : un administrateur Entra doit explicitement autoriser la fédération d’identité de charge de travail au niveau du tenant avant que ça fonctionne — la même équipe qui gère tes politiques Conditional Access est généralement la bonne interlocutrice pour débloquer ce point.
    • AADSTS70021 (« No matching federated identity record ») : le plus souvent une URL d’issuer ou un subject mal renseigné côté federated credential — à vérifier directement dans la boîte de dialogue d’édition de la connexion.
    • Clouds souverains : certains environnements Azure souverains bloquent encore la fédération (erreur AADSTS900382) — vérifie la compatibilité avant de migrer un projet critique.
    • Le service principal ou la managed identity doit être ajouté comme utilisateur dans chaque organisation Azure DevOps cible pour un accès cross-org, même si c’est la même identité Entra derrière.

    Et côté sécurisation du code, quoi de neuf ?

    Dans la même logique de renforcement de la sécurité des pipelines, Microsoft a aussi fait évoluer l’offre GitHub Advanced Security pour Azure DevOps, désormais disponible en deux produits indépendants plutôt qu’un seul bundle : GitHub Secret Protection (protection contre les fuites de secrets avant qu’elles n’arrivent) et GitHub Code Security (scan de dépendances et analyse CodeQL). Les clients existants ne sont pas impactés automatiquement — la bascule vers l’un ou l’autre produit se fait à la demande via le portail Azure. Plus de détails sur le blog officiel Azure DevOps.

    FAQ

    Le Workload Identity Federation remplace-t-il complètement les PAT ?

    Pour l’authentification pipeline vers Azure ou vers une autre organisation Azure DevOps, oui, c’est l’option recommandée. Les PAT restent utiles pour certains scénarios d’automatisation en dehors des pipelines (scripts locaux, outils tiers), mais leur usage doit rester limité et avec une durée de vie courte.

    Est-ce compatible avec les agents self-hosted ?

    Oui, la fédération d’identité fonctionne aussi bien avec les agents Microsoft-hosted qu’avec des agents self-hosted ou des Managed DevOps Pools.

    Ça coûte plus cher ?

    Non, la fédération d’identité ne change rien à la facturation Azure DevOps — c’est une méthode d’authentification, pas un service payant.

    En résumé

    Si tu gères encore des service connections avec secret qui expirent tous les six ou douze mois, c’est le moment de planifier la bascule. Commence par un projet non critique pour valider la configuration Entra, documente les groupes de droits, puis généralise. Tu gagnes en sécurité, tu perds une corvée récurrente de rotation de secrets — difficile de trouver un meilleur compromis.

  • Microsoft Intune en 2026 : ce que le bundling M365 E3/E5 change pour toi

    Microsoft Intune en 2026 : ce que le bundling M365 E3/E5 change pour toi

    Si tu gères le parc de postes de ton organisation avec Microsoft Intune, l’été 2026 a changé la donne sans que tu aies eu grand-chose à faire : une bonne partie des fonctionnalités jusque-là vendues en add-on payant a migré directement dans tes licences Microsoft 365 E3 et E5. À côté de ça, Windows Autopatch a basculé le hotpatching en activé par défaut, et Intune continue d’élargir son périmètre sur Linux et Android. Voici ce qui a changé concrètement, et ce que ça implique pour ta feuille de route.

    L’Intune Suite arrive dans tes licences M365, sans coût supplémentaire

    Jusqu’ici, les fonctionnalités avancées de gestion des terminaux (Remote Help, Advanced Analytics, Endpoint Privilege Management…) nécessitaient l’add-on payant Intune Suite. Depuis l’été 2026, Microsoft les intègre progressivement dans les abonnements Microsoft 365 E3 et E5 existants.

    Le partage entre les deux niveaux n’est pas identique :

    • Microsoft 365 E3 reçoit Intune Plan 2 (Microsoft Tunnel, mises à jour firmware over-the-air, gestion des terminaux spécialisés), Remote Help et Advanced Analytics.
    • Microsoft 365 E5 reçoit l’intégralité de l’Intune Suite, avec en plus les trois capacités premium qui restent exclusives à E5 : Endpoint Privilege Management (élévation de privilèges à la demande, sans compte admin permanent), Enterprise App Management, et Cloud PKI.

    Le déploiement s’est fait progressivement entre juin et début août 2026, avec un préavis de 30 jours dans le centre d’administration avant le provisionnement automatique de chaque tenant — aucune action manuelle n’était nécessaire pour recevoir les entitlements. Deux points de vigilance si ce n’est pas encore fait de ton côté :

    • Nettoyage des licences : si ton organisation payait déjà l’add-on Intune Suite en standalone, vérifie que tu ne payes pas en double à ton prochain renouvellement.
    • Mise en service réelle : recevoir l’entitlement ne veut pas dire que la fonctionnalité est configurée. Endpoint Privilege Management en particulier change la façon dont tu gères les droits admin sur les postes — ça mérite une vraie phase de conception avant activation en masse, pas juste un clic dans le centre d’administration.

    Windows Autopatch : le hotpatching passe en activé par défaut

    Depuis la mise à jour de sécurité de mai 2026, les mises à jour hotpatch sont activées par défaut pour tous les appareils éligibles gérés via Windows Autopatch. Le principe : les correctifs de sécurité s’installent plus vite et avec beaucoup moins de redémarrages qu’une mise à jour cumulative classique, ce qui réduit la fenêtre d’exposition entre la sortie du correctif et son application effective sur le parc.

    Si ton organisation n’est pas prête pour ce changement, deux options de désactivation existent, disponibles depuis le 1er avril 2026 dans le centre d’administration Intune :

    • un réglage au niveau du tenant, qui désactive le hotpatching pour l’ensemble des appareils éligibles ;
    • une stratégie de mise à jour qualité, qui permet de contrôler le comportement pour un groupe d’appareils spécifique — cette stratégie a priorité sur le réglage tenant pour les appareils qu’elle cible.

    Autopatch update readiness : un tableau de bord unifié

    Toujours côté Autopatch, la fonctionnalité update readiness centralise le suivi des mises à jour Windows sur l’ensemble des appareils, qu’ils soient gérés directement par Intune ou inscrits dans un groupe Windows Autopatch. Tu retrouves en un seul tableau de bord le parcours de mise à jour de chaque appareil, des alertes centralisées sur les échecs et conflits de stratégie, un vérificateur de préparation qui signale les appareils à risque (espace disque, compatibilité), et la possibilité de déclencher une réinstallation de l’OS à distance pour réparer les appareils bloqués. De quoi limiter les allers-retours de diagnostic manuel quand une campagne de mise à jour cale sur une partie du parc.

    Linux et Android : le périmètre de gestion continue de s’élargir

    Deux évolutions à noter si ton parc dépasse le seul Windows :

    Côté Linux, Intune supporte désormais RHEL 9 LTS et RHEL 10 LTS. Le support de RHEL 8 LTS prend fin en juillet 2026 — les appareils déjà inscrits en RHEL 8 restent gérés, mais il vaut mieux planifier la bascule des postes restants plutôt que d’attendre une rupture de support.

    Côté Android, Intune finalise sa migration vers l’Android Management API de Google pour les appareils personnels en mode profil professionnel (BYOD). Concrètement, ça apporte un enrôlement web sans installation d’application dédiée, et une nouvelle implémentation de la distribution des stratégies alignée avec ce qui existe déjà pour les appareils corporate. La migration se pilote par groupes ciblés plutôt qu’en bascule globale, ce qui te laisse la main sur le rythme.

    Comment préparer ta feuille de route

    • Vérifie dans le centre d’administration Microsoft Intune quelles licences Intune Suite ton tenant a effectivement reçues, et compare avec ce que tu payais déjà en add-on.
    • Si tu es sur Windows Autopatch et que le hotpatching par défaut ne convient pas à ton contexte (applications sensibles au redémarrage, contraintes de test), configure le réglage tenant ou une stratégie de mise à jour qualité avant la prochaine campagne.
    • Si Endpoint Privilege Management t’intéresse, commence par un pilote sur un groupe restreint : le changement de modèle (fin des comptes admin permanents) demande un accompagnement utilisateur, pas juste un déploiement technique.
    • Recense tes postes RHEL 8 restants si applicable, et planifie leur migration avant que le manque de support ne devienne un problème de sécurité.

    Ces changements de gestion des terminaux s’articulent naturellement avec tes politiques d’accès conditionnel : plus la conformité des appareils remonte finement dans Intune, plus tes règles dans Entra ID peuvent s’appuyer dessus. Si tu n’as pas encore revu tes règles suite au changement d’enforcement de l’accès conditionnel de juin 2026, c’est le bon moment de faire les deux en même temps.

    FAQ

    Dois-je faire une demande pour recevoir les nouvelles licences Intune Suite ?

    Non. Le provisionnement s’est fait automatiquement pour les tenants disposant de licences Microsoft 365 E3 ou E5, avec un préavis de 30 jours affiché dans le centre d’administration avant l’activation. Si ton déploiement n’a pas encore eu lieu, vérifie l’état dans le centre d’administration Microsoft 365 plutôt que d’ouvrir un ticket support.

    Le hotpatching remplace-t-il complètement les mises à jour cumulatives classiques ?

    Non, il s’y ajoute en alternance : les hotpatchs couvrent les mois intermédiaires sans redémarrage lourd, tandis que les mises à jour cumulatives de référence (baseline) restent appliquées périodiquement selon le cycle Windows Autopatch.

    Que se passe-t-il pour mes appareils RHEL 8 après juillet 2026 ?

    Ils restent inscrits et gérés, mais ne bénéficient plus des correctifs et évolutions associés au support LTS. Migrer vers RHEL 9 ou 10 reste recommandé dès que possible plutôt que de laisser ces postes sur une version non supportée.

    En résumé

    2026 aura été une année de simplification côté licences Intune (Suite intégrée dans E3/E5) et de durcissement côté exploitation (hotpatching par défaut, meilleure visibilité sur la préparation aux mises à jour). Rien de tout ça n’exige une action dans l’urgence, mais chaque point mérite une vérification de ton côté : les licences que tu payes peut-être encore en double, le comportement de mise à jour que tu n’as peut-être pas choisi, et le périmètre Linux/Android qui s’est élargi pendant que tu avais le dos tourné.

  • Kubernetes 1.37 : les nouveautés à connaître avant ta prochaine mise à jour

    Kubernetes 1.37 : les nouveautés à connaître avant ta prochaine mise à jour

    Kubernetes 1.37, nom de code « Garhwal », est sorti le 26 août 2026. Si tu gères des clusters en production, cette version mérite ton attention : elle fait passer en stable plusieurs fonctionnalités de sécurité qui traînaient en beta depuis des mois, et elle acte le début de la fin pour un composant que tu utilises peut-être encore sans le savoir. Dans cet article, tu retrouves les changements qui comptent vraiment pour l’exploitation quotidienne, sans passer par les 67 items de la release note officielle.

    Ce qui passe en stable (GA) et que tu peux activer sans crainte

    Une version stable, c’est une fonctionnalité que tu peux mettre en production sans attendre le prochain cycle. Sur les 67 améliorations de Kubernetes 1.37, 16 franchissent ce cap. Voici celles qui changent concrètement ta façon de gérer un cluster.

    Montage de volumes SELinux accéléré

    Si tes nœuds tournent avec SELinux en mode enforcing (RHEL, Fedora CoreOS…), tu as sûrement déjà vu un pod mettre de longues secondes, voire des minutes, à démarrer sur un volume contenant beaucoup de fichiers : c’est le relabeling SELinux fichier par fichier qui bloque. Kubernetes 1.37 généralise l’option de montage native -o context, qui applique le label au niveau du point de montage plutôt qu’à chaque fichier. Le gain de démarrage est immédiat, et ça ferme au passage certaines techniques d’exploitation basées sur les chemins hôte.

    Certificats de pods (Pod Certificates) en GA

    C’est la fonctionnalité qui va t’intéresser si tu cherches à sortir du tout-bearer-token pour l’authentification inter-services. Avec la source de volume projeté PodCertificate, chaque pod peut désormais recevoir automatiquement un certificat X.509 signé, avec rotation gérée par Kubernetes. Ça t’évite de déployer et maintenir cert-manager ou un sidecar dédié juste pour du mTLS basique entre services internes. À utiliser en complément d’un service mesh si tu en as un, ou en solution autonome si ton besoin est simple.

    Ressources au niveau du pod

    Pour les workloads composés de plusieurs conteneurs étroitement couplés (un conteneur principal + un sidecar de log shipping, par exemple), tu peux désormais définir un pool de ressources CPU/mémoire partagé au niveau du pod plutôt que de fixer des limites rigides conteneur par conteneur. Résultat : moins de sur-provisionnement « au cas où » sur chaque conteneur pris isolément.

    DRA : les tolérances de dispositifs passent en GA

    La Dynamic Resource Allocation (DRA), qui gère l’attribution de matériel spécialisé (GPU, TPU, cartes réseau dédiées), avait déjà atteint la GA en 1.34. En 1.37, les device taints/tolerations deviennent stables : un device défaillant ou en maintenance peut désormais être « tainté » exactement comme un nœud, et tes workloads peuvent choisir de tolérer ce taint ou non. Si tu opères des pools de GPU pour de l’inférence IA, c’est le genre de détail qui t’évite un incident silencieux le jour où une carte commence à dériver.

    Ce qui arrive en beta : à tester avant la prochaine LTS

    Les fonctionnalités en beta sont activées par défaut dans la plupart des cas, mais restent à valider en environnement de test avant une généralisation.

    • ClusterTrustBundles : une API cluster-scoped pour distribuer des ancres de confiance X.509 à tes workloads, avec mise à jour automatique lors des rotations de certificats — le complément naturel des Pod Certificates ci-dessus.
    • Préemption pour le redimensionnement de pods à chaud : le scheduler peut désormais préempter des pods de priorité plus basse pour libérer de la place quand une demande de resize « in-place » ne trouve pas de ressources disponibles sur un nœud saturé.
    • Scoring de capacité de stockage : les nœuds peuvent être priorisés lors du provisionnement de volumes persistants selon leur capacité disponible, pour étaler la charge ou au contraire consolider selon ta stratégie.
    • Autoscaling horizontal jusqu’à zéro réplique pour le HorizontalPodAutoscaler, utile pour des workloads événementiels qui n’ont pas besoin de tourner en continu.

    La dépréciation à anticiper : la fin programmée d’IPVS

    C’est le point qui mérite une ligne dans ton backlog d’infra dès maintenant. Le backend kube-proxy IPVS est officiellement déprécié à partir de la 1.37, avec une suppression prévue en 1.43. En parallèle, le nouveau backend NFTables (alpha en 1.37, avec un support de l’accès NodePort en localhost via proxy userspace) est sur une trajectoire pour devenir le backend par défaut dès la version 1.40, en remplacement progressif d’iptables.

    Concrètement, si ton cluster tourne encore avec IPVS, tu as jusqu’à la 1.43 pour basculer, mais autant commencer à planifier la migration vers iptables (le mode le plus courant aujourd’hui) ou NFTables plutôt que d’attendre le dernier moment. Vérifie la configuration de ton kube-proxy avec kubectl get configmap kube-proxy -n kube-system -o yaml si tu as un doute sur le backend actuellement utilisé.

    Comment préparer ta mise à jour vers Kubernetes 1.37

    Avant de lancer la migration sur un cluster de production, quelques réflexes qui t’évitent les mauvaises surprises :

    • Consulte la note de version officielle pour la liste complète des 67 changements, y compris ceux spécifiques à ta distribution (EKS, AKS, GKE ont chacune leur propre calendrier de disponibilité).
    • Teste d’abord sur un cluster de non-production, en particulier si tu utilises SELinux en mode enforcing ou si tu as des CRD volumineuses (le décodage concurrent des watchs, en beta, cible justement ce cas).
    • Si tu es sur IPVS, planifie ta bascule de backend kube-proxy indépendamment de la montée de version elle-même, pour isoler les deux changements.
    • Documente-toi sur les guides de dépréciation officiels pour vérifier qu’aucune API que tu utilises n’arrive en fin de vie dans cette version.

    Si tu veux revoir les fondamentaux du hardening d’un cluster avant de monter en version, notre guide complet pour sécuriser un cluster Kubernetes reste une bonne base, indépendamment de la version installée.

    FAQ

    Faut-il migrer vers Kubernetes 1.37 tout de suite ?

    Pas dans l’urgence. Comme pour toute montée de version majeure, teste d’abord en environnement de non-production. Les fonctionnalités GA de cette version (SELinux, Pod Certificates, DRA taints) sont solides, mais rien n’oblige à migrer avant ta fenêtre de maintenance habituelle — sauf si tu es concerné par la dépréciation d’IPVS.

    IPVS va-t-il disparaître immédiatement ?

    Non. La dépréciation en 1.37 signifie que le composant est marqué pour suppression, prévue en 1.43 — tu as donc plusieurs cycles de release devant toi (généralement plusieurs mois par version) pour planifier la migration.

    Les Pod Certificates remplacent-ils un service mesh ?

    Pas forcément. Ils couvrent le besoin de base (certificat X.509 par pod, rotation automatique) mais un service mesh comme Istio ou Linkerd ajoute des couches supplémentaires (observabilité, retry, politiques de trafic). Pour un besoin de mTLS simple entre quelques services, les Pod Certificates peuvent suffire seuls.

    En résumé

    Kubernetes 1.37 consolide surtout des fondations de sécurité posées lors des versions précédentes : SELinux et certificats de pods passent enfin en stable, la DRA continue sa maturation pour les workloads GPU, et le compte à rebours démarre officiellement pour IPVS. Rien qui impose une migration en urgence, mais de quoi mettre à jour ta feuille de route infra pour les prochains mois. Si un point de cet article te concerne directement — bascule IPVS, adoption des Pod Certificates —, c’est le bon moment pour ouvrir le ticket avant que ça devienne urgent.

  • Terraform ou Bicep en 2026 : lequel choisir pour Azure ?

    Terraform ou Bicep en 2026 : lequel choisir pour Azure ?

    Terraform ou Bicep pour tes déploiements Azure ? Si tu te poses encore la question en 2026, tu n’es pas en retard — c’est même le bon moment pour trancher, parce que les deux outils ont beaucoup évolué depuis 2024 et l’écart entre eux s’est réduit sur plusieurs points qui faisaient historiquement pencher la balance. Dans cet article, on fait le point sur ce qui a vraiment changé, les forces et limites actuelles de chaque outil, et comment choisir sans te tromper selon ton contexte.

    Ce qui a changé depuis 2024-2025

    Quatre évolutions ont rebattu les cartes :

    • Les deployment stacks donnent enfin à Bicep une vraie gestion du cycle de vie complet des ressources (création, mise à jour, et surtout suppression propre des ressources qui sortent du template), ce qui comblait un manque réel face au terraform destroy.
    • Les Azure Verified Modules (AVM) couvrent désormais les deux langages avec le même niveau d’exigence, alors que Bicep avait longtemps l’avantage du support « officiel » Microsoft plus poussé.
    • Terraform a intégré un framework de test natif depuis la version 1.6, réduisant la dépendance à des outils tiers comme Terratest pour valider un module avant de le publier.
    • Le provider azurerm en version 4.x a réduit le décalage historique avec les nouveaux services Azure, et le provider AzAPI comble le reste en donnant un accès direct aux API Azure Resource Manager dès leur sortie, sans attendre le mapping HCL.

    Bicep en 2026 : forces et limites

    Bicep reste l’outil natif d’Azure : pas d’état externe à gérer, syntaxe plus concise que l’ARM JSON qu’il remplace, et accès immédiat aux nouvelles fonctionnalités Azure dès leur disponibilité dans Resource Manager. Les deployment stacks permettent maintenant de gérer un ensemble de ressources comme une unité versionnée, avec un contrôle fin sur ce qui doit être supprimé (deleteAll, deleteResources ou detachAll) quand tu retires une ressource du template :

    az stack sub create \
  --name "stack-rg-prod" \
  --location "francecentral" \
  --template-file "main.bicep" \
  --deployment-resource-group "rg-prod" \
  --action-on-unmanage "deleteResources" \
  --deny-settings-mode "none"

    La limite reste son périmètre : Bicep ne pilote qu’Azure. Si ton organisation gère aussi de l’AWS, du GCP, ou des ressources SaaS (DNS, monitoring tiers…), tu devras de toute façon avoir un second outil à côté.

    Terraform en 2026 : forces et limites

    Terraform garde son atout historique : un seul outil pour orchestrer plusieurs fournisseurs, et un écosystème de providers considérable. Le framework de test natif (disponible depuis Terraform 1.6) permet d’écrire des scénarios de validation directement en HCL, sans dépendance externe :

    run "verify_resource_group_location" {
  command = plan

  assert {
    condition     = azurerm_resource_group.main.location == "francecentral"
    error_message = "Le resource group doit être déployé en France Central"
  }
}

    Côté couverture Azure, le provider AzAPI comble le décalage historique avec azurerm : il expose les ressources Azure Resource Manager dès leur publication, y compris en preview, avec des fonctions pour construire et analyser les IDs de ressources directement au moment du plan. La contrepartie de Terraform reste la gestion d’un état externe : un atout pour le diff/plan avant application, mais une surface de maintenance et de sécurité (stockage, verrouillage, secrets) que Bicep n’a pas.

    Azure Verified Modules : le vrai terrain d’entente

    Les Azure Verified Modules sont sans doute le développement le plus structurant des deux dernières années sur ce sujet : des modules réutilisables, maintenus par Microsoft, conformes au Well-Architected Framework, disponibles dans les deux langages avec le même standard de qualité (tests automatisés, documentation générée, revue par les équipes Azure). Utiliser un module AVM te fait gagner du temps de conception ET réduit ton risque de config non conforme aux bonnes pratiques Azure, quel que soit le langage que tu choisis. Les équipes AVM viennent aussi de publier de la documentation sur le développement piloté par spécification avec GitHub Copilot et Spec Kit, pour accélérer la génération de solutions Azure à partir des modules — à surveiller si tu explores l’IA dans ton workflow IaC.

    C’est notamment ce qui rend la migration vers les AVM pour tes landing zones pertinente indépendamment du langage choisi : la standardisation apportée par les modules compte souvent plus que le débat Bicep vs Terraform en lui-même.

    Comment choisir sans te tromper

    Trois questions à te poser :

    • Es-tu 100 % Azure, ou multi-cloud / multi-SaaS ? Si tu es strictement Azure avec une petite équipe, Bicep te simplifie la vie (pas d’état à gérer). Dès que d’autres fournisseurs entrent en jeu, Terraform évite d’avoir deux outils à maintenir.
    • Pars-tu de zéro ou migres-tu de l’ARM JSON existant ? Bicep a un chemin de migration direct depuis l’ARM JSON (decompile automatique). Repartir de zéro en Terraform a du sens si tu anticipes une extension multi-cloud à moyen terme.
    • As-tu déjà un investissement Terraform significatif ? Si ton équipe maîtrise déjà Terraform et que ton parc de modules fonctionne bien, le coût de migration vers Bicep est rarement justifié seulement par les nouveautés listées ici. Comme le résume bien la comparaison de Technspire sur le sujet, l’outil compte moins que la discipline avec laquelle tu le maintiens : tests, revues de modules, gestion des secrets et de l’état.

    Si tu es encore sur un ancien provider azurerm, ça vaut aussi le coup de vérifier où tu en es : le guide de migration vers AzureRM 5.0 couvre les changements à anticiper avant d’aller plus loin, quel que soit le sens dans lequel tu fais évoluer ton IaC ensuite.

    FAQ

    Peut-on mixer Bicep et Terraform dans la même organisation ?

    Oui, et c’est même courant en pratique : une équipe plateforme sur Terraform pour l’infrastructure transverse (réseau, identité), et des équipes produit sur Bicep pour leurs ressources applicatives. Le risque à surveiller, c’est la duplication de logique de configuration entre les deux — les AVM aident justement à limiter ce risque en donnant un référentiel commun.

    Les deployment stacks remplacent-ils vraiment le besoin d’un état Terraform ?

    Ils comblent l’essentiel du manque pour la suppression propre des ressources, mais Bicep n’expose pas d’équivalent au terraform plan en tant que diff détaillé avant application — ce qui reste un vrai avantage de Terraform pour les changements à fort impact.

    Faut-il attendre une version encore plus mature avant de se lancer ?

    Non, les deux outils sont production-ready depuis longtemps. Le risque n’est pas dans la maturité technique, mais dans le manque de discipline (pas de revue de code IaC, pas de tests, secrets en clair) — un problème indépendant du langage choisi.

    Conclusion

    En 2026, le débat Bicep vs Terraform ressemble moins à un choix définitif qu’à une décision de contexte : Azure pur et équipe réduite pour Bicep, environnement hétérogène ou investissement existant pour Terraform. Dans les deux cas, les Azure Verified Modules sont le levier qui compte le plus pour la qualité de ton infrastructure. Commence par auditer ton parc actuel, identifie où les AVM peuvent remplacer du code IaC maison, et le choix du langage deviendra secondaire.

  • FinOps en 2026 : maîtriser tes coûts Azure avec Cost Management

    FinOps en 2026 : maîtriser tes coûts Azure avec Cost Management

    Tu regardes ta facture Azure du mois et tu ne reconnais plus grand-chose ? Tu n’es pas seul. Entre les ressources oubliées, les réservations jamais achetées et les équipes qui provisionnent sans se soucier du coût, la dérive budgétaire cloud est devenue un classique. C’est exactement le problème que le FinOps essaie de résoudre — et en 2026, la discipline change de dimension. Le FinOps Framework vient d’être mis à jour en profondeur, et Microsoft a densifié son outillage natif autour d’Azure Cost Management. Dans cet article, tu vas voir ce qui a changé, quels outils Azure utiliser concrètement, et comment démarrer une démarche FinOps sans tout révolutionner du jour au lendemain.

    Le FinOps Framework 2026 : trois évolutions qui changent la donne

    Porté par la FinOps Foundation, le framework de référence a été révisé en 2026 pour refléter un constat simple : la discipline ne se limite plus à surveiller la facture Azure ou AWS du mois. Trois changements structurent cette nouvelle version.

    Executive Strategy Alignment : FinOps s’invite au comité de direction

    Une nouvelle capacité formalise ce que beaucoup d’équipes FinOps matures faisaient déjà de façon informelle : porter les arbitrages de coût au niveau exécutif. Elle couvre l’alignement avec les priorités de la direction, la stratégie d’investissement pluriannuelle, la priorisation des produits et le soutien aux décisions stratégiques. Concrètement, ça veut dire que tes rapports de coûts ne doivent plus seulement dire « voilà ce qu’on a dépensé », mais « voilà ce que ça nous rapporte et ce qu’on te recommande d’arbitrer ».

    De nouvelles catégories technologiques : SaaS, data platforms et IA

    Le framework ne se limite plus au cloud public. Il couvre désormais le SaaS, les data centers on-premises, les plateformes de données cloud (Snowflake, Databricks…) et l’intelligence artificielle, chacune avec sa propre guidance. Si tu géres des coûts de tokens LLM ou des clusters Databricks à côté de ton abonnement Azure, ce n’est plus un angle mort du framework.

    Les FinOps Scopes redéfinis autour du métier

    Les « scopes » ne sont plus uniquement pensés autour de l’infrastructure (une souscription, un tag) mais comme des segments de dépense alignés sur des questions métier concrètes : combien coûte telle fonctionnalité produit, tel client, telle équipe. C’est un changement de posture : partir du besoin business plutôt que de la topologie technique.

    Les outils Microsoft pour piloter tes coûts Azure au quotidien

    Sur le plan pratique, tu n’as pas besoin d’attendre pour appliquer ces principes : Azure fournit déjà l’essentiel de l’outillage nécessaire.

    Azure Cost Management : budgets, alertes et détection d’anomalies

    Azure Cost Management reste le socle : analyse des coûts, budgets avec seuils d’alerte, et détection automatique d’anomalies basée sur ton historique d’usage normalisé. La bonne pratique documentée par Microsoft est de poser des seuils à 90 % (dépense idéale), 100 % (budget cible) et 110 % (alerte de dépassement), sur des alertes réelles ET prévisionnelles :

    az consumption budget create \
  --budget-name "budget-prod-rg" \
  --amount 5000 \
  --category cost \
  --time-grain monthly \
  --start-date 2026-10-01 \
  --end-date 2027-09-30 \
  --resource-group "rg-prod" \
  --notifications '{
    "Actual_GreaterThan_90_Percent": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 90,
      "contactEmails": ["equipe-infra@monentreprise.fr"]
    },
    "Forecasted_GreaterThan_110_Percent": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 110,
      "thresholdType": "Forecasted",
      "contactEmails": ["equipe-infra@monentreprise.fr"]
    }
  }'

    Pense aussi à activer tag inheritance dans Cost Management : ça t’évite de te retrouver avec des ressources orphelines impossibles à rattacher à une équipe ou un projet au moment de faire les comptes.

    FinOps toolkit : hubs, Power BI et alertes automatisées sur les ressources inactives

    Le FinOps toolkit de Microsoft complète l’outillage natif avec des composants prêts à déployer : les FinOps hubs pour centraliser et normaliser tes exports de coûts dans un data lake, des rapports Power BI, et surtout « FinOps alerts », une solution basée sur Azure Logic Apps qui scanne périodiquement ton environnement pour repérer les ressources inactives (VM arrêtées mais toujours facturées, disques orphelins, IP publiques non utilisées) et notifie automatiquement les équipes responsables. C’est le genre d’automatisation qui te fait gagner un vrai temps d’ingénieur, plutôt que de dépouiller un classeur Excel chaque fin de mois.

    FOCUS : un format commun pour comparer tes coûts multi-fournisseurs

    Si tu gères plusieurs fournisseurs cloud ou SaaS, la spécification FOCUS (FinOps Open Cost and Usage Specification) mérite ton attention : c’est un format de données de coûts standardisé, désormais supporté nativement par les exports Cost Management vers Azure Data Lake Storage. Ça t’évite de réécrire un pipeline de normalisation à la main dès que tu ajoutes un fournisseur.

    Mettre en place une démarche FinOps concrète, sans tout révolutionner

    Tu n’as pas besoin d’une équipe FinOps dédiée pour commencer. Voici un chemin réaliste :

    • Commence par les alertes, pas par le budget parfait. Un seuil approximatif qui prévient d’une dérive vaut mieux qu’aucune alerte en attendant le budget idéal.
    • Structure ton tagging (équipe, projet, environnement) et active l’héritage de tags pour limiter les coûts non attribuables.
    • Passe en revue les recommandations Azure Advisor régulièrement — c’est la source la plus fiable de pistes d’optimisation immédiates (VM à redimensionner, réservations à envisager).
    • Automatise la détection des ressources inactives avec FinOps alerts plutôt que de compter sur une revue manuelle mensuelle.
    • Documente qui décide quoi : qui peut ajuster un budget, qui reçoit les alertes de dépassement, qui arbitre entre performance et coût. Sans ça, les meilleurs outils du monde ne servent à rien.

    Si tu poses tes fondations de gouvernance (tagging, landing zones structurées) en même temps que ta démarche FinOps, tu gagnes du temps sur les deux fronts — c’est d’ailleurs l’un des arguments pour passer aux Azure Verified Modules sur tes landing zones : une infrastructure standardisée dès le départ rend le suivi des coûts par équipe ou projet beaucoup plus simple qu’un rattrapage a posteriori.

    FAQ

    Le FinOps, c’est réservé aux grandes entreprises avec une grosse facture cloud ?

    Non. Les principes (visibilité, alertes, responsabilisation des équipes) s’appliquent dès qu’un abonnement Azure dépasse quelques centaines d’euros par mois. Ce qui change avec la taille, c’est le degré de formalisation : une petite équipe peut se contenter de budgets et d’alertes bien réglés, sans capacité dédiée ni comité exécutif.

    Quelle différence entre FinOps et un simple contrôle budgétaire ?

    Le contrôle budgétaire classique regarde a posteriori si on est dans les clous. Le FinOps vise à donner aux équipes techniques une visibilité en temps réel sur l’impact financier de leurs choix d’architecture, pour qu’elles puissent arbitrer elles-mêmes entre coût et performance, au moment où elles conçoivent — pas six mois plus tard en comité budgétaire.

    Faut-il un outil tiers ou les outils natifs Azure suffisent ?

    Pour démarrer, Azure Cost Management et le FinOps toolkit couvrent l’essentiel : budgets, alertes, anomalies, tableaux de bord Power BI. Les outils tiers deviennent pertinents surtout en environnement multi-cloud complexe, où tu as besoin d’une vue consolidée au-delà d’Azure — c’est justement le rôle que FOCUS est censé faciliter, tiers ou pas.

    Conclusion

    Le FinOps 2026 n’est plus seulement une affaire de tableurs et d’alertes de fin de mois : c’est un cadre qui invite à connecter la donnée de coût aux décisions produit et aux priorités de la direction. Mais tu n’as pas besoin d’attendre d’avoir tout ce dispositif en place pour commencer. Configure tes premières alertes de budget cette semaine, active FinOps alerts sur tes ressources inactives, et construis à partir de là. C’est ce genre de petites victoires régulières qui fait tenir une démarche FinOps dans la durée — bien plus qu’un grand plan jamais terminé.

  • Grafana 13, Prometheus 3 et OpenTelemetry : la nouvelle donne de l’observabilité en 2026

    Grafana 13, Prometheus 3 et OpenTelemetry : la nouvelle donne de l’observabilité en 2026

    Si ta facture d’observabilité augmente plus vite que ton infra elle-même, tu n’es pas seul. Entre l’explosion du volume de logs, la multiplication des outils et la pression pour réduire les coûts, 2026 marque un vrai tournant : Grafana 13, Prometheus 3 et la généralisation d’OpenTelemetry redessinent ce qu’une stack de monitoring moderne doit faire. Voici ce qui change concrètement, et comment en tirer parti sans tout réécrire du jour au lendemain.

    Grafana 13 : de la donnée brute à l’action

    Présentée à GrafanaCON 2026, cette version pousse Grafana au-delà du simple outil de visualisation, avec pour objectif de raccourcir le chemin entre une métrique et une décision :

    • Tableaux de bord suggérés intégrant des méthodologies standard comme DORA (pour le delivery) et USE/RED (pour l’infra et les services), pour ne plus repartir d’une page blanche
    • Tableaux de bord dynamiques qui s’adaptent au contexte et aux variables sélectionnées par l’utilisateur
    • Workflows Git bidirectionnels avec gestion d’API versionnée, pour appliquer une vraie gouvernance (revue, historique, rollback) sur tes dashboards comme sur du code
    • Un écosystème élargi à 170 sources de données et 120 panneaux de visualisation

    Grafana revendique aujourd’hui 35 millions d’utilisateurs dans le monde — la plateforme n’est plus une simple couche de visualisation posée sur Prometheus, elle devient le point d’entrée unique pour l’exploitation au quotidien.

    Loki repensé pour les gros volumes de logs

    Le moteur de stockage de logs de Grafana a été retravaillé en profondeur pour tenir la charge des environnements modernes :

    • Ingestion adossée à Kafka pour des pipelines plus durables et plus résilients aux pics
    • Un planificateur de requêtes distribué qui exécute les analyses en parallèle
    • Des gains annoncés de 10x sur les performances de requêtes agrégées, avec 20x moins de données scannées pour arriver au résultat

    Concrètement, ça veut dire des requêtes de logs sur de larges fenêtres temporelles qui restent exploitables en interactif, là où elles auraient nécessité un job batch auparavant.

    Prometheus 3 : OTLP natif et histogrammes natifs

    Prometheus a lui aussi fait sa mue. Le changement le plus structurant pour les équipes qui utilisent OpenTelemetry : Prometheus embarque désormais un récepteur de métriques OTLP natif, sans passer par un exportateur intermédiaire.

    # Activer la réception OTLP native dans prometheus.yml / au démarrage
prometheus --web.enable-otlp-receiver

# Les métriques OTLP sont alors acceptées directement sur :
# POST /api/v1/otlp/v1/metrics

    Autres évolutions notables pour la migration :

    • Support UTF-8 complet dans les noms de métriques et de labels par défaut (fini la conversion systématique des points en underscores, ce qui simplifie l’intégration avec des sources OpenTelemetry)
    • Remote Write 2.0, qui transporte metadata, exemplars, timestamps de création et histogrammes natifs ensemble, avec interning de chaînes pour réduire la taille des payloads
    • Une UI repensée façon PromLens, avec une vue arborescente qui décompose une requête PromQL en sa structure logique

    Si tu migres depuis Prometheus 2.x (guide de migration officiel), passe d’abord par la version 2.55 : un rollback depuis la 3.0 n’est possible que vers cette version, pas plus loin en arrière. Vérifie aussi tes règles d’alerting utilisant des regex, puisque le matching inclut désormais les retours à la ligne.

    OpenTelemetry devient le standard de facto

    Tous les langages, plateformes et fournisseurs cloud majeurs supportent désormais OpenTelemetry nativement, ce qui élimine une bonne partie de l’instrumentation dupliquée qu’on devait maintenir manuellement il y a encore deux ou trois ans. Grafana accompagne ce mouvement avec Alloy, sa distribution de collecteur qui accepte une configuration YAML native OpenTelemetry, avec une installation en une seule commande sous Linux et un support renforcé de l’opérateur Kubernetes pour l’auto-instrumentation des workloads conteneurisés.

    Les tendances à surveiller pour ta stratégie 2026

    Une étude Grafana Labs menée auprès de 150 décideurs IT met en évidence plusieurs signaux à prendre en compte quand tu planifies ta stack :

    • Valeur plutôt que volume : la télémétrie adaptative peut réduire le volume de données ingérées de 50 à 80 %, en ne conservant que les signaux réellement exploitables
    • Consolidation encore difficile : 73 % des organisations ont adopté ou migrent vers une observabilité unifiée, mais seulement 14 % jugent leur consolidation « très réussie » — ne sous-estime pas l’effort de mise en cohérence entre équipes
    • Les SLO sortent de la conformité : 86 % des équipes les utilisent déjà, et ils s’invitent de plus en plus dans la planification de sprint et les décisions business, pas seulement dans les rapports d’incident
    • L’IA comme copilote : 84 % des organisations explorent l’IA en observabilité, avec un glissement progressif de l’assistance à la requête vers des agents capables d’investiguer un incident de façon autonome

    FAQ

    Faut-il migrer vers Prometheus 3 dès maintenant ?

    Le moteur de stockage (TSDB) n’a pas changé, ce qui rend l’upgrade relativement sûr techniquement. Le vrai travail est de vérifier tes règles d’alerting et tes scrape configs avant de basculer, plutôt que d’attendre une contrainte externe pour t’y mettre.

    OpenTelemetry remplace-t-il Prometheus et Grafana ?

    Non, OpenTelemetry est un standard de collecte et de transport de la télémétrie (métriques, logs, traces), pas un outil de stockage ou de visualisation. Il vient en complément de Prometheus (stockage des métriques) et Grafana (visualisation), en simplifiant l’instrumentation en amont.

    Par où commencer si on part de zéro ?

    Instrumente avec OpenTelemetry dès le départ plutôt que des SDK propriétaires : tu gardes la liberté de changer de backend (Prometheus, Grafana Cloud, Datadog…) sans réinstrumenter ton code plus tard.

    Pour aller plus loin

    Une bonne stack d’observabilité ne vaut que si elle tourne sur une infra stable : si tu exploites Prometheus et Grafana sur Kubernetes, notre guide de sécurisation d’un cluster Kubernetes couvre les bases à ne pas négliger avant de brancher tes collecteurs. Et si tu veux automatiser le déploiement de ta stack de monitoring dans tes pipelines, jette un œil à notre article sur les nouveautés sécurité de GitHub Actions.

  • VMware, Hyper-V ou Azure Local en 2026 : comment décider après la crise des licences Broadcom

    VMware, Hyper-V ou Azure Local en 2026 : comment décider après la crise des licences Broadcom

    Depuis le rachat de VMware par Broadcom, la question n’est plus « quel hyperviseur choisir » mais « combien ça va coûter cette année, et l’année prochaine ». Entre la fin des licences perpétuelles, les hausses de prix à trois chiffres et les minimums contractuels, beaucoup d’équipes infra ont été forcées de rouvrir un dossier qu’elles croyaient clos depuis dix ans. Dans cet article, tu vas voir ce qui a vraiment changé chez VMware, pourquoi Hyper-V et Azure Local reviennent en force, et comment migrer sans y laisser un week-end complet.

    Ce qui a changé chez VMware depuis le rachat par Broadcom

    Le changement le plus violent, c’est la fin des licences perpétuelles. VMware fonctionne désormais uniquement en abonnement, avec un regroupement forcé dans des bundles rigides (VCF ou VVF) que tu ne peux plus découper à la carte. Concrètement, ça se traduit par :

    • Une tarification au cœur physique, avec un minimum de 16 cœurs par socket et un minimum contractuel de 72 cœurs — même si ton cluster est plus petit, tu payes pour ce plancher
    • Des hausses de renouvellement qui vont, selon les témoignages, de 2x à 12x le tarif précédent
    • Une pénalité de 20 % en cas de renouvellement tardif

    Pour une PME ou une ETI avec un cluster de taille modeste, ce changement de modèle peut représenter un budget infra multiplié par plusieurs, sans aucune fonctionnalité supplémentaire en face. C’est ce qui a relancé l’intérêt pour des alternatives que beaucoup avaient mises de côté depuis longtemps.

    Hyper-V : la solution que tu payes peut-être déjà

    Si tu as des licences Windows Server, Hyper-V est inclus — pas de coût de licence additionnel pour l’hyperviseur lui-même. Et avec Windows Server 2025, il a fait un vrai bond en avant côté scalabilité et gestion :

    • Scalabilité : jusqu’à 4 pétaoctets de mémoire et 2 048 processeurs logiques par hôte, et jusqu’à 240 To de mémoire / 2 048 processeurs virtuels pour les VM de génération 2
    • Network ATC : une approche par intention (« je veux ce réseau pour le management, celui-ci pour le stockage ») qui élimine une bonne partie de la dérive de configuration réseau sur les clusters
    • Compatibilité processeur dynamique : le cluster calcule automatiquement le plus grand dénominateur commun de fonctionnalités CPU entre tous les nœuds, pour que tes VM profitent du maximum de capacités disponibles sans casser la migration à chaud
    • Clusters workgroup : tu peux désormais faire du live migration entre nœuds Hyper-V qui ne sont pas membres d’un domaine Active Directory

    Attention cependant : les nœuds Windows Server 2025 ne peuvent pas rejoindre un cluster existant en 2019 ou 2022 — le clustering mixte n’est pas supporté entre ces versions. Si tu migres depuis un cluster plus ancien, prévois un cluster cible neuf et un transfert de VM via stockage partagé ou live migration cross-cluster.

    Azure Local : le pas suivant vers l’hybride

    Azure Local (l’ex-Azure Stack HCI) pousse le raisonnement un cran plus loin : c’est du Hyper-V et du Failover Clustering, mais piloté depuis le portail Azure via Azure Arc, avec une tarification à l’abonnement mensuel par cœur physique.

    • Environ 10 $/cœur/mois en hyperconvergé, 20,10 $/cœur/mois en configuration avec SAN dissocié
    • Si tu détiens déjà des licences Windows Server Datacenter avec Software Assurance, l’Azure Hybrid Benefit peut ramener le coût du système d’exploitation invité à 0 $/mois
    • Gestion GPU centralisée depuis Azure (inventaire, partitionnement, cycle de vie des workloads accélérés) actuellement en preview
    • Azure Arc Site Manager pour piloter plusieurs sites Azure Local depuis une vue unique, clusters Kubernetes inclus
    • Ajout de nœuds directement depuis le portail Azure, en preview, sans repasser par un outillage local

    C’est une option particulièrement pertinente si tu es déjà engagé dans l’écosystème Azure et que tu veux une gouvernance unifiée entre ton on-premise et le cloud, avec le même RBAC et les mêmes Azure Policy des deux côtés.

    Migrer sans tout casser

    Trois chemins existent aujourd’hui pour sortir de VMware, du plus léger au plus outillé :

    1. L’extension VM Conversion de Windows Admin Center

    Pensée pour des migrations ponctuelles sans System Center, elle fonctionne en deux temps : une synchronisation initiale du disque pendant que la VM source continue de tourner, puis une migration finale qui ne réplique que les blocs modifiés (Change Block Tracking) pour minimiser la fenêtre de coupure.

    2. System Center VMM 2025

    Pour du volume, VMM 2025 propose une conversion V2V environ quatre fois plus rapide qu’avant, avec ce type de commande PowerShell :

    # Politique de disque pour les nouveaux disques partagés lors de la conversion
Set-StorageSetting -NewDiskPolicy OfflineShared

# Bascule ensuite en gestion des VM Azure Local via Arc-enabled SCVMM
# (la gestion Azure VM directe depuis VMM n'est plus supportée en 2025)

    VMM limite à dix conversions en parallèle depuis un même hôte ESXi source vers une même destination Hyper-V — au-delà, mieux vaut étaler en plusieurs lots pour ne pas saturer le stockage.

    3. Azure Migrate, pour aller directement vers Azure Local

    Azure Migrate sait désormais répliquer et migrer aussi bien des VM Hyper-V que VMware vers Azure Local, avec un support Terraform et Azure CLI en preview pour scripter des migrations reproductibles — pratique si tu veux industrialiser ça en infra as code plutôt que de cliquer VM par VM.

    Et les alternatives open source ?

    Si tu veux sortir complètement de l’écosystème Microsoft, Proxmox (licence par socket, gratuit à l’usage avec support entreprise en option), Nutanix AHV (capacité modulaire, plutôt pour les gros comptes) et XCP-ng (basé sur Xen, migration à chaud solide) sont les trois noms qui reviennent le plus souvent dans les retours d’expérience 2026. Ils demandent en général plus d’huile de coude à l’exploitation, en échange d’une facture nettement plus prévisible.

    FAQ

    Migrer vers Hyper-V fait-il perdre des fonctionnalités avancées de VMware ?

    Sur des environnements très complexes utilisant DRS ou une intégration multi-cloud poussée, VMware garde une avance fonctionnelle. Pour la majorité des usages (clusters standards, haute disponibilité, snapshots, live migration), Hyper-V couvre largement le besoin.

    Faut-il migrer en une seule fois ?

    Non, et ce n’est pas recommandé. La conversion V2V par lots (via VMM ou Windows Admin Center) permet de valider chaque vague avant de continuer, ce qui limite le risque en cas de VM récalcitrante.

    Azure Local est-il utilisable sans connexion internet permanente ?

    Oui, Azure Local supporte un fonctionnement déconnecté pour les sites avec une connectivité limitée, même si la gestion complète depuis le portail Azure nécessite une synchronisation périodique.

    Pour aller plus loin

    Que tu partes vers Hyper-V, Azure Local ou une alternative open source, prends le temps de revoir aussi ta stratégie de sauvegarde : les mécanismes d’immuabilité et la règle 3-2-1-1-0 restent valables quel que soit l’hyperviseur, comme on le détaille dans notre guide sauvegarde et PRA 2026. Et si ta bascule s’accompagne d’un passage sous Windows Server 2025, jette un œil à notre article sur les durcissements sécurité d’Active Directory sous cette version avant de basculer tes contrôleurs de domaine.