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

  • Sauvegarde et PRA en 2026 : la règle 3-2-1-1-0 face aux ransomwares

    Sauvegarde et PRA en 2026 : la règle 3-2-1-1-0 face aux ransomwares

    90 % des organisations se disent confiantes dans leur capacité à récupérer après une cyberattaque. Dans les faits, seulement 28 % y parviennent totalement. Cet écart, révélé par le dernier rapport Veeam sur la résilience des données, résume à lui seul pourquoi « avoir des sauvegardes » et « avoir une vraie stratégie de sauvegarde et de PRA » sont deux choses très différentes. Voici ce que ces chiffres impliquent concrètement pour ton infrastructure.

    Le fossé entre confiance et réalité

    Le rapport 2026 de Veeam sur la résilience face aux ransomwares dresse un constat qui devrait faire réfléchir toute équipe infra :

    • 90 % des organisations se disent confiantes dans leur capacité de reprise après incident, mais seulement 28 % récupèrent l’intégralité de leurs données après une attaque — la récupération moyenne plafonne à 72 % des données touchées.
    • 42 % des organisations attaquées signalent une perturbation directe pour leurs clients ou utilisateurs, 41 % des pertes financières, et 38 % un arrêt de service prolongé.
    • Les organisations ayant augmenté leur budget cybersécurité affichent un taux de récupération complète de 40 %, contre seulement 16 % pour les autres — la corrélation entre investissement et résilience réelle est nette.

    Le rapport identifie quatre pratiques qui font la différence : une visibilité claire sur les données en production et en sauvegarde, des contrôles de sécurité réellement appliqués (pas seulement documentés), des tests de restauration réalistes, et un alignement de la direction sur les responsabilités et objectifs de reprise (rapport complet sur veeam.com).

    La règle 3-2-1-1-0, colonne vertébrale d’une stratégie solide

    La bonne nouvelle, c’est que le cadre pour combler cet écart existe depuis longtemps et reste valable en 2026. La règle 3-2-1 s’est enrichie de deux exigences supplémentaires face aux ransomwares modernes :

    • 3 copies de tes données (la production + 2 sauvegardes)
    • 2 supports de stockage différents (ex. disque local + stockage objet cloud)
    • 1 copie hors site (offsite, dans une autre région/datacenter)
    • 1 copie hors ligne, immuable ou air-gapée — inaccessible même si un attaquant obtient des droits d’administration sur ton infra
    • 0 erreur après vérification — une sauvegarde qui n’a jamais été testée n’est qu’une hypothèse

    Le dernier point est celui que la plupart des équipes négligent. Une sauvegarde immuable qui ne restaure pas correctement au moment critique n’apporte aucune protection réelle.

    Rendre tes sauvegardes vraiment immuables (pas juste « protégées »)

    Sur Azure, le point de départ est le soft delete renforcé des coffres Recovery Services, activé par défaut sur les nouveaux coffres depuis les dernières évolutions de sécurité d’Azure Backup, avec une rétention configurable et une protection contre la suppression accidentelle ou malveillante des points de restauration :

    # Activer l'immuabilité sur un coffre Recovery Services existant (Azure CLI)
    az backup vault backup-properties set \
      --name "rsv-prod-backup" \
      --resource-group "rg-backup" \
      --backup-storage-redundancy GeoRedundant \
      --immutability-state Locked
    
    # Vérifier l'état de l'immuabilité du coffre
    az backup vault backup-properties show \
      --name "rsv-prod-backup" \
      --resource-group "rg-backup" \
      --query immutabilitySettings

    Le point de vigilance : une fois passé en état Locked, l’immuabilité ne peut plus être désactivée, ce qui est précisément le comportement recherché contre un attaquant disposant de droits élevés. Teste d’abord en environnement non critique avant de verrouiller un coffre de production. Le détail des options (soft delete, coffres verrouillés, sauvegardes « vaulted ») est couvert dans la documentation officielle sur le soft delete renforcé d’Azure Backup et la vue d’ensemble des fonctionnalités de sécurité d’Azure Backup.

    Le PRA, ce n’est pas la sauvegarde (et c’est souvent là que ça coince)

    Avoir des sauvegardes fiables ne garantit pas un plan de reprise d’activité (PRA) fonctionnel. Ce sont deux disciplines complémentaires mais distinctes :

    • La sauvegarde répond à la question « puis-je restaurer mes données ? »
    • Le PRA répond à la question « en combien de temps mon service est-il de nouveau opérationnel, et avec quelle perte de données acceptable ? »

    Ça se traduit par deux indicateurs à définir service par service, pas globalement pour toute l’infra :

    • RPO (Recovery Point Objective) : quantité de données que tu acceptes de perdre, mesurée en temps depuis la dernière sauvegarde valide.
    • RTO (Recovery Time Objective) : délai maximal acceptable avant que le service soit de nouveau disponible.

    Un serveur de fichiers interne et une base de données transactionnelle critique n’ont pas les mêmes exigences — les traiter avec la même politique de sauvegarde est une erreur fréquente. C’est aussi un sujet que la réglementation pousse de plus en plus : la directive NIS2 en cours de transposition en France impose justement aux entités concernées de formaliser des capacités de continuité et de reprise d’activité, pas seulement des sauvegardes techniques.

    Tester vraiment, pas seulement sur le papier

    Un PRA qui n’a jamais été exécuté en conditions réelles reste une théorie. Quelques pratiques concrètes pour sortir de la théorie :

    • Planifie des exercices de restauration complets (pas juste un fichier isolé) au moins une à deux fois par an, en dehors des heures critiques.
    • Restaure vers un environnement isolé du réseau de production pour valider qu’une sauvegarde compromise ne recontamine pas l’infra restaurée.
    • Mesure le RTO réel obtenu lors du test et compare-le à ton objectif — l’écart, s’il existe, te dit exactement où prioriser tes efforts.
    • Documente qui fait quoi pendant l’exercice : un PRA qui dépend d’une seule personne disponible est un PRA fragile.

    Si ton infrastructure de sauvegarde et de reprise est déployée sur Azure, la définir en Infrastructure as Code facilite grandement la reproductibilité de ces tests — coffres, politiques de rétention et réseaux isolés redéployés à l’identique à chaque exercice. Notre article sur les Azure Landing Zones et les Azure Verified Modules couvre justement cette approche pour structurer ce type d’infrastructure de façon cohérente.

    FAQ

    Quelle différence entre RTO et RPO ?

    Le RPO mesure la perte de données acceptable (combien de temps depuis la dernière sauvegarde valide), le RTO mesure le temps d’indisponibilité acceptable avant reprise du service. Les deux se définissent ensemble, service par service.

    Une sauvegarde immuable, c’est quoi concrètement ?

    C’est une copie de sauvegarde qui ne peut être ni modifiée ni supprimée pendant une période définie, même par un compte disposant de droits d’administration — la protection ultime contre un ransomware qui aurait compromis tes accès élevés.

    À quelle fréquence tester son PRA ?

    Au minimum une à deux fois par an pour un test complet, et idéalement après chaque changement structurant de l’infrastructure (migration, nouvelle application critique, changement de fournisseur cloud).

    Ce qu’il faut retenir

    L’écart entre « je pense pouvoir récupérer » et « je peux effectivement récupérer » se comble avec trois ingrédients : des sauvegardes réellement immuables suivant la règle 3-2-1-1-0, des objectifs RTO/RPO définis service par service, et des tests de restauration exécutés en conditions réelles plutôt que supposés fonctionner. C’est un chantier qui se construit progressivement — mais qui vaut clairement l’investissement le jour où tu en as besoin.

  • Active Directory dans Windows Server 2025 : les changements sécurité à connaître

    Active Directory dans Windows Server 2025 : les changements sécurité à connaître

    Si tu administres encore des contrôleurs de domaine en 2026, le mois de septembre vient de te donner deux bonnes raisons de t’y intéresser de près : un Patch Tuesday historique qui touche directement Active Directory, et une nouvelle génération de durcissements dans Windows Server 2025 qui change pas mal d’habitudes prises depuis vingt ans. Le grand écart entre « corriger l’urgence » et « préparer la suite » résume bien où en est l’annuaire Microsoft aujourd’hui.

    Le Patch Tuesday de septembre 2026, un record qui vise directement tes DC

    Microsoft a publié le 8 septembre 2026 le plus gros lot de correctifs de son histoire : 966 failles, dont 105 classées critiques. Deux d’entre elles sont déjà exploitées activement :

    • CVE-2026-81963 — élévation de privilèges dans la pile Windows Update, via une résolution de lien incorrecte permettant d’obtenir des droits SYSTEM.
    • CVE-2026-85880 — dépassement de tampon dans Windows ALPC, exploitable localement pour élever ses privilèges.

    Ce qui doit vraiment retenir ton attention si tu gères un annuaire : 6 CVE touchent Active Directory Domain Services et 4 autres Active Directory Certificate Services, deux composants au cœur de l’authentification et de la gestion des certificats sur tes contrôleurs de domaine. Avec ce volume de correctifs, le tri par criticité et le test en environnement de pré-production ne sont plus optionnels — priorise les CVE AD DS/AD CS avant le reste du lot (détail complet du Patch Tuesday sur BleepingComputer).

    Windows Server 2025 : Active Directory fait enfin le ménage

    Au-delà du correctif du mois, Windows Server 2025 a apporté à Active Directory sa mise à jour de sécurité la plus dense depuis longtemps. Voici ce qui change concrètement pour toi.

    Kerberos : RC4 c’est terminé

    Le centre de distribution de clés Kerberos n’émet plus de TGT chiffrés en RC4-HMAC sur un DC Windows Server 2025. Si certaines de tes applications legacy dépendent encore de ce chiffrement (souvent silencieusement, via une bibliothèque ancienne), elles vont commencer à échouer. La clé de registre historique SupportedEncryptionTypes n’est d’ailleurs plus respectée : c’est désormais la stratégie de groupe « Sécurité réseau : Configurer les types de chiffrement autorisés pour Kerberos » qui fait foi.

    LDAP chiffré et signé par défaut

    Tous les nouveaux déploiements Active Directory exigent désormais la signature LDAP par défaut, et LDAP passe au chiffrement TLS 1.3 via SCHANNEL. Concrètement : les vieux scripts ou appliances qui font encore du LDAP en clair ou en bind simple non signé vont commencer à générer des échecs de connexion — mieux vaut les identifier avant la mise à niveau que le jour où un utilisateur t’appelle.

    Mots de passe de comptes ordinateur générés aléatoirement

    Autre changement discret mais important : un DC Windows Server 2025 empêche par défaut de définir le mot de passe d’un compte ordinateur avec le nom du compte lui-même — une pratique historiquement répandue et évidemment risquée. La stratégie de groupe correspondante s’appelle « Contrôleur de domaine : refuser de définir le mot de passe du compte d’ordinateur par défaut ».

    Comptes de service managés délégués (dMSA)

    Les dMSA offrent enfin un vrai chemin de migration depuis les comptes de service classiques, avec des clés entièrement aléatoires et gérées automatiquement — sans que tu aies à toucher au code des applications qui les utilisent. C’est probablement le changement le plus concret à planifier si tu as encore des comptes de service avec un mot de passe qui n’a pas changé depuis des années.

    L’ensemble de ces évolutions est détaillé dans la documentation officielle Microsoft Learn sur les nouveautés de Windows Server 2025, et Microsoft en donne le contexte complet dans cet article Tech Community dédié aux améliorations Active Directory.

    Comment préparer ta montée en version sans mauvaise surprise

    Avant de basculer tes DC vers Windows Server 2025, quelques vérifications t’évitent une bonne partie des incidents post-migration :

    # Repérer les liaisons LDAP non sécurisées sur un DC
    # (événements 2887 et 2889 dans le journal Répertoire)
    Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=2887,2889} -MaxEvents 50 |
        Select-Object TimeCreated, Id, Message
    
    # Vérifier le niveau fonctionnel actuel du domaine et de la forêt
    Get-ADDomain | Select-Object Name, DomainMode
    Get-ADForest | Select-Object Name, ForestMode
    
    # Lister les comptes de service candidats à une migration en dMSA
    Get-ADServiceAccount -Filter * -Properties PasswordLastSet |
        Sort-Object PasswordLastSet

    Ce type de script s’automatise facilement dans un pipeline de contrôle régulier — si tu veux aller plus loin sur l’automatisation PowerShell de tes tâches d’administration, notre guide complet sur l’automatisation IT avec PowerShell couvre les bases pour industrialiser ce genre de contrôle.

    Sur le plan de la conformité, ce durcissement d’Active Directory tombe au bon moment : la directive NIS2 continue sa progression en France et pousse justement vers ce niveau d’exigence sur l’authentification et la gestion des identités. Si ton organisation gère aussi l’accès conditionnel dans Entra ID, notre article sur le changement d’enforcement Conditional Access de juin 2026 complète bien cette mise à jour côté identité hybride.

    FAQ

    Faut-il migrer tous ses DC vers Windows Server 2025 immédiatement ?

    Non — mais il faut au minimum patcher en urgence les vulnérabilités AD DS/AD CS du Patch Tuesday de septembre sur tes DC existants, quelle que soit leur version. La montée vers Windows Server 2025 peut ensuite se planifier sereinement, DC par DC, en commençant par un environnement de test.

    Le niveau fonctionnel de forêt 10 est-il obligatoire ?

    Non, il n’est requis que si tu veux activer la nouvelle taille de page de base de données 32K. Tu peux exécuter des DC Windows Server 2025 avec un niveau fonctionnel inférieur sans problème.

    Comment savoir si des applications utilisent encore RC4 ou du LDAP non signé ?

    Active l’audit des événements 2887/2889 (liaisons LDAP non sécurisées) et surveille les échecs d’authentification Kerberos après application des stratégies restreignant RC4, idéalement d’abord en mode audit avant le blocage effectif.

    Ce qu’il faut retenir

    Entre le Patch Tuesday record de septembre et les durcissements natifs de Windows Server 2025, Active Directory redevient un sujet d’actualité — dans le bon sens du terme. Commence par patcher les CVE AD DS/AD CS sur tes DC actuels, puis planifie ta migration en identifiant en amont les dépendances RC4, LDAP non signé et comptes de service à risque. Ton futur toi t’en remerciera au prochain audit de sécurité.

  • Azure Landing Zones : passer aux Azure Verified Modules (AVM)

    Azure Landing Zones : passer aux Azure Verified Modules (AVM)

    Si tu déploies ou maintiens une landing zone Azure — la structure de base (management groups, policies, réseau hub, identité) sur laquelle repose toute ton organisation Azure — tu es probablement passé par du code Bicep ou Terraform artisanal, réécrit projet après projet. Les Azure Verified Modules (AVM) pour les landing zones changent la donne : ce sont des modules officiels, maintenus par Microsoft, prêts à l’emploi. On regarde ce que c’est concrètement, pourquoi ça compte, et comment démarrer.

    C’est quoi, une Azure landing zone ?

    Une landing zone Azure, c’est l’environnement de base sur lequel tu déploies tes charges de travail : hiérarchie de management groups, stratégies de gouvernance (Azure Policy), architecture réseau (hub-and-spoke ou virtual WAN), gestion des identités et rôles, journalisation centralisée. C’est le socle du Cloud Adoption Framework de Microsoft, pensé pour que chaque nouvelle application ou équipe atterrisse (d’où le nom) dans un environnement déjà sécurisé et conforme, sans repartir de zéro.

    Le problème historique : chaque organisation finissait par coder sa propre version de cette landing zone, avec ses propres bugs, ses propres angles morts de sécurité, et une maintenance qui reposait entièrement sur l’équipe interne.

    Les Azure Verified Modules, en bref

    Les Azure Verified Modules (AVM) sont des modules d’infrastructure as code réutilisables, développés et maintenus par Microsoft, disponibles aussi bien en Bicep qu’en Terraform. Chaque module suit un processus de qualité strict : conception alignée sur le Well-Architected Framework, tests automatisés (unitaires et d’intégration), documentation générée automatiquement, revue par les équipes Azure avant publication. Concrètement, ça veut dire que tu n’écris plus de code Bicep/Terraform « à la main » pour déployer un réseau virtuel, une politique ou une identité managée : tu appelles un module versionné et testé, et tu passes juste tes paramètres.

    Pour les landing zones spécifiquement, Microsoft publie une famille de modules pattern (avm/ptn/alz/*) qui couvrent la plateforme complète : gestion, connectivité, identité, monitoring, jusqu’à des modules « sandbox » pour tester rapidement une configuration.

    Deux façons de les utiliser

    Via l’accélérateur IaC Azure Landing Zones

    L’accélérateur IaC officiel automatise le déploiement complet d’une landing zone plateforme en s’appuyant sur les AVM, que tu choisisses Bicep ou Terraform. Il fonctionne en quatre phases : choix du langage IaC et du système de contrôle de version, configuration des identifiants et abonnements, bootstrap de l’environnement (pipeline CI/CD, dépôt de code), puis personnalisation et déploiement continu. Il s’intègre nativement avec Azure DevOps et GitHub pour la partie pipelines.

    En modules indépendants

    Tu n’es pas obligé de passer par l’accélérateur complet : les modules AVM sont utilisables individuellement, dans ton propre code Bicep ou Terraform existant. Si tu as déjà une landing zone en place, tu peux migrer progressivement — module par module — plutôt que de tout réécrire d’un coup.

    Pourquoi c’est le bon moment pour s’y mettre

    Trois raisons concrètes de regarder les AVM landing zones maintenant plutôt que de continuer avec du code maison :

    • Moins de dette de maintenance — les correctifs de sécurité et les nouvelles bonnes pratiques Azure sont intégrés par Microsoft dans les modules, tu n’as qu’à monter de version
    • Cohérence architecturale — tous les modules suivent le même standard de nommage, de tagging et de structure, ce qui facilite l’onboarding d’une nouvelle personne dans l’équipe infra
    • Portabilité entre Bicep et Terraform — les deux familles de modules visent la même architecture cible, utile si ton organisation change d’outil IaC ou fait cohabiter les deux

    Points de vigilance avant de migrer une landing zone existante

    Passer à AVM sur une landing zone déjà en production n’est pas anodin :

    • Compare d’abord l’état actuel de tes ressources avec ce que produirait le module AVM équivalent, pour repérer les écarts de configuration avant tout déploiement
    • Teste la migration dans un abonnement sandbox avant de toucher à la plateforme de production — le module avm/ptn/alz/sandbox existe justement pour ça
    • Prévois une fenêtre de changement, même si les modules sont conçus pour être idempotents : une landing zone touche des management groups et des policies qui peuvent impacter plusieurs équipes

    FAQ

    Les Azure Verified Modules sont-ils gratuits ?

    Oui, les modules eux-mêmes sont open source et gratuits (disponibles sur le Bicep Registry et le Terraform Registry). Tu paies uniquement les ressources Azure qu’ils déploient, comme pour n’importe quel déploiement manuel.

    Faut-il choisir entre Bicep et Terraform pour utiliser AVM ?

    Les deux familles de modules existent en parallèle et visent la même architecture. Le choix dépend surtout de ton écosystème existant : reste sur Terraform si tu gères déjà du multi-cloud ou si ton équipe le maîtrise, privilégie Bicep si tu es 100% Azure et que tu veux un outil natif sans état à gérer côté backend.

    Les AVM landing zones supportent-ils les clouds souverains (Azure Government, 21Vianet) ?

    Non pour l’instant : le déploiement via portail Azure et les modules AVM ciblent les régions Azure publiques. Sur les clouds souverains, il faut partir du code Bicep/Terraform de l’accélérateur comme base et l’adapter aux contraintes spécifiques de ces environnements.

    Pour aller plus loin

    Si tu gères déjà tes ressources Azure en Terraform, notre article sur la migration vers Terraform AzureRM 5.0 couvre les changements du provider à connaître avant d’adopter des modules AVM en Terraform. Et si ta landing zone doit s’appuyer sur des pipelines Azure DevOps, jette aussi un œil à notre article sur les Managed DevOps Pools, pensés pour justement héberger ce type de pipeline d’infrastructure sans te soucier de la maintenance des agents.

    Que tu partes d’une landing zone vierge ou que tu migres une plateforme existante, commence petit : déploie un module AVM isolé dans un abonnement sandbox, compare le résultat avec ton architecture cible, et élargis progressivement. C’est la meilleure façon d’adopter ces modules sans y perdre une semaine de debug.

    Sources

  • PowerShell 7.6 LTS : ce qui change et comment migrer sereinement

    PowerShell 7.6 LTS : ce qui change et comment migrer sereinement

    PowerShell 7.6 est sorti en version LTS (Long Term Support) le 18 mars 2026, construit sur .NET 10. Si tu gères des scripts de production, c’est la version vers laquelle tu vas devoir migrer tôt ou tard : les versions non-LTS ont un cycle de support beaucoup plus court, et Microsoft pousse clairement PowerShell 7.6 comme socle stable pour les prochaines années. On fait le tour de ce qui change, de ce qui casse, et de la marche à suivre pour migrer sans mauvaise surprise.

    Pourquoi la version LTS compte pour toi

    Une version LTS de PowerShell bénéficie d’un support étendu (généralement trois ans), contrairement aux versions intermédiaires qui ne sont maintenues que quelques mois. Si tu déploies PowerShell sur des serveurs de production, des runners CI/CD ou des postes de travail à grande échelle, c’est la version que tu dois cibler : moins de montées de version à gérer, plus de stabilité, et des correctifs de sécurité garantis sur la durée.

    PowerShell 7.6 tourne sur le runtime .NET 10, lui-même en LTS. Ça t’évite le decalage habituel où le runtime .NET atteint sa fin de support avant la version de PowerShell qui s’appuie dessus.

    Les nouveautés qui changent vraiment ton quotidien

    Fonctionnalités expérimentales devenues stables

    Quatre fonctionnalités passent enfin du statut expérimental au statut stable, ce qui veut dire que tu peux les utiliser en production sans activer de flag :

    • PSFeedbackProvider — le système de suggestions contextuelles en cas d’erreur (par exemple, proposer une commande proche quand tu tapes une commande introuvable)
    • PSNativeWindowsTildeExpansion — l’expansion du ~ vers ton répertoire utilisateur, y compris pour les commandes natives Windows
    • PSRedirectToVariable — la redirection de flux (comme 2> pour stderr) directement vers une variable
    • PSSubsystemPluginModel — le modèle de plugin pour les sous-systèmes (complétion, prédiction, etc.)

    Deux nouvelles fonctionnalités expérimentales à surveiller

    Si tu manipules beaucoup de JSON ou si tu es côté DSC (Desired State Configuration), deux nouveautés expérimentales méritent un test :

    • PSSerializeJSONLongEnumAsNumber : ConvertTo-Json traite désormais les grandes valeurs d’énumération comme des nombres plutôt que comme des chaînes, ce qui évite des conversions bancales côté consommateur de l’API
    • PSProfileDSCResource : une nouvelle ressource DSC v3 dédiée à la gestion des profils PowerShell, utile si tu standardises les profils sur un parc de machines via DSC

    Confort au quotidien : complétion, presse-papiers, process

    Une bonne partie du travail sur cette version porte sur la complétion (tab-completion) : complétion par nom court de module, meilleure inférence de type sur les variables, gestion des guillemets dans les chemins, complétion des variables assignées dans une boucle Do… Ce sont des dizaines de petits correctifs qui, cumulés, rendent la console sensiblement plus agréable à utiliser.

    Côté cmdlets, retiens surtout :

    • Get-Clipboard gagne un paramètre -Delimiter pour contrôler comment les lignes du presse-papiers sont séparées
    • Get-Command gagne un paramètre -ExcludeModule pour filtrer les résultats
    • Register-ArgumentCompleter -NativeFallback permet d’enregistrer un compléteur générique pour toutes les commandes natives qui n’ont pas de complétion dédiée
    • Start-Process -Wait a un polling plus efficace, donc moins de charge CPU inutile quand tu attends la fin d’un process
    • Deux nouveaux alias intrinsèques, PSForEach() et PSWhere(), en complément de Foreach() et Where()

    Les changements cassants à vérifier avant de migrer

    Trois points de vigilance avant de basculer tes scripts de production :

    • Module ThreadJob renommé : le module ThreadJob est remplacé par Microsoft.PowerShell.ThreadJob. La cmdlet Start-ThreadJob ne change pas de comportement, mais si tes scripts référencent le nom qualifié du module (ThreadJob\Start-ThreadJob), il faut le mettre à jour en Microsoft.PowerShell.ThreadJob\Start-ThreadJob.
    • Join-Path -ChildPath accepte désormais un tableau : le type du paramètre passe à string[]. Si tu as du code qui dépend strictement du typage string unique (réflexion, validation de paramètre custom), teste ce chemin.
    • WildcardPattern.Escape() corrige l’échappement des backticks isolés : si tu construis des patterns wildcard à partir de chaînes contenant des backticks, le résultat de l’échappement change légèrement — revérifie les regex/patterns générés dynamiquement.

    Ce sont des changements ciblés, pas une refonte : dans la grande majorité des cas, un script qui tourne sous PowerShell 7.4 ou 7.5 tournera tel quel sous 7.6. Mais « dans la grande majorité des cas » ne remplace pas un passage en environnement de test.

    Comment migrer sans mauvaise surprise

    1. Installe PowerShell 7.6 en parallèle de ta version actuelle plutôt que de l’écraser — PowerShell 7.x supporte les installations côte à côte via MSI (Windows), Homebrew (macOS) ou les paquets natifs (Linux).
    2. Fais tourner ta suite de tests / tes scripts critiques sous 7.6 dans un environnement non-prod, en particulier tout ce qui touche à ThreadJob, Join-Path ou à la génération de patterns wildcard.
    3. Vérifie tes modules tiers (PSResourceGet, PSReadLine, etc.) : PowerShell 7.6 embarque des versions mises à jour de ces modules, donc si tu épingles des versions précises ailleurs dans ton pipeline, harmonise.
    4. Planifie le déploiement en LTS une fois validé : c’est la version que tu veux garder plusieurs années, donc autant prendre le temps de bien la valider une fois, plutôt que de la pousser en urgence.

    FAQ

    PowerShell 7.6 remplace-t-il Windows PowerShell 5.1 ?

    Non, et ce n’est pas prévu à court terme. Windows PowerShell 5.1 reste présent nativement dans Windows et certains modules legacy (notamment certains modules serveur) n’existent encore que pour cette version. PowerShell 7.6 (PowerShell Core) cohabite avec 5.1 sur la même machine.

    Dois-je migrer immédiatement si je suis sur PowerShell 7.4 ?

    Pas dans l’urgence, mais ne tarde pas trop : la fenêtre de support de PowerShell 7.4 (LTS précédente) se réduit avec la disponibilité de 7.6. Planifie la migration dans les prochains mois plutôt que d’attendre la fin de support.

    Où trouver la liste complète des changements ?

    Le changelog exhaustif est publié sur le dépôt GitHub officiel de PowerShell, avec chaque pull request référencée individuellement — utile si tu veux vérifier l’impact d’un changement précis sur ton code.

    Pour aller plus loin

    Si tu es encore en train de construire tes bases d’automatisation PowerShell (modules, gestion des credentials, scripts récurrents), notre guide complet sur l’automatisation IT avec PowerShell couvre les fondamentaux avant même de te poser la question de la version.

    Migrer vers une version LTS, ça se prépare : teste tes scripts critiques dès maintenant dans un environnement isolé, note les points de friction, et programme la bascule en production sur un créneau calme plutôt qu’en urgence. Ton futur toi t’en remerciera.

    Sources

  • GitHub Actions en septembre 2026 : les nouveautés sécurité et la feuille de route à connaître

    GitHub Actions en septembre 2026 : les nouveautés sécurité et la feuille de route à connaître

    Si tes pipelines GitHub Actions tournent depuis un moment sans que tu aies retouché aux permissions ou à l’épinglage des actions tierces, cet article est pour toi. GitHub a publié début septembre 2026 trois nouveautés qui touchent directement la sécurité et la fiabilité de tes workflows, et elles s’inscrivent dans une feuille de route 2026 bien plus large sur le sujet. Tu vas voir ce qui change concrètement, comment en profiter dès maintenant, et ce qui arrive ensuite pour que tu puisses anticiper plutôt que subir.

    Ce qui vient de sortir : les mises à jour de début septembre 2026

    Le changelog officiel du 3 septembre 2026 apporte trois changements concrets.

    1. Une API pour anticiper la dépréciation des runners

    Nouvel endpoint REST : GET /actions/runners/deprecations/{version}, disponible au niveau repository, organisation ou entreprise. Il te renvoie runner_version, runtime_deprecates_at et registration_deprecates_at — de quoi programmer tes montées de version de runners self-hosted au lieu de découvrir la dépréciation le jour où un job casse en production.

    curl -H "Authorization: Bearer $GH_TOKEN" \
      -H "Accept: application/vnd.github+json" \
      https://api.github.com/repos/ORG/REPO/actions/runners/deprecations/2.319.1

    2. Une permission dédiée aux alertes Dependabot

    Le GITHUB_TOKEN gagne une permission vulnerability-alerts (valeurs read ou none), qui donne un accès en lecture seule aux alertes Dependabot depuis un workflow. Ça t’évite de devoir accorder des scopes beaucoup plus larges juste pour qu’un job lise l’état des vulnérabilités connues :

    permissions:
      vulnerability-alerts: read
      contents: read

    C’est exactement le genre de granularité que recommande la documentation officielle sur l’usage sécurisé de GitHub Actions : donner à chaque job le minimum nécessaire, jamais plus.

    3. Quatre nouvelles propriétés de contexte pour les workflows réutilisables

    Si tu factorises tes pipelines avec des reusable workflows, le contexte job expose désormais job.workflow_ref, job.workflow_sha, job.workflow_repository et job.workflow_file_path. Ça permet à un workflow réutilisable de savoir précisément d’où il est appelé et sur quelle version — utile pour du logging, de l’audit, ou pour appliquer des règles différentes selon l’appelant. Seule limite à noter : ces propriétés ne sont pas disponibles sur GitHub Enterprise Server.

    La feuille de route sécurité 2026 : ce qui arrive ensuite

    Ces trois nouveautés s’inscrivent dans une feuille de route sécurité plus large que GitHub a partagée avec la communauté. Voici les chantiers à surveiller, parce qu’ils vont probablement changer tes habitudes de configuration :

    • Verrouillage des dépendances au niveau workflow : à terme, les actions tierces devront être épinglées à un SHA de commit précis pour que le workflow s’exécute — la meilleure protection connue contre une action compromise qui pousserait une mise à jour malveillante sur son tag.
    • Protections sur le déclenchement des workflows : donner aux administrateurs un contrôle plus fin sur quels acteurs et quels événements peuvent déclencher un workflow, en particulier pour les opérations sensibles (déploiement, publication de packages).
    • Secrets mieux scopés : limiter l’accès aux secrets par workflow, par job, voire par step, plutôt que de les exposer à l’ensemble d’un run.
    • Flux d’audit immuable (« actions data stream ») : une piste d’audit séparée des logs de run classiques, pensée pour rester exploitable même si un run est compromis et ses logs supprimés, avec une intégration envisagée vers des outils SIEM.
    • Pare-feu de sortie natif : blocage par défaut du trafic sortant des runners hébergés par GitHub, avec liste d’autorisation — d’abord sur les runners managés, le support des runners self-hosted étant encore à l’étude.

    Rien de tout ça n’est encore généralisé au moment où j’écris ces lignes, mais la direction est claire : GitHub muscle sérieusement la sécurité par défaut de ses pipelines, dans la continuité des attaques de chaîne d’approvisionnement qui ont touché plusieurs actions populaires ces dernières années.

    Ce que tu peux faire dès maintenant

    Épingler tes actions tierces sans attendre l’obligation

    Plutôt que d’attendre que ça devienne obligatoire, remplace dès aujourd’hui tes références de tags (uses: actions/checkout@v4) par des SHA de commit complets :

    steps:
      - uses: actions/checkout@8edcb1bdb4e267140fa742c62e395cd74f332d84 # v4.2.2
    

    Ça demande un peu plus de maintenance (Dependabot peut s’en charger automatiquement), mais ça neutralise le scénario où un tag existant est réécrit pour pointer vers du code malveillant.

    Auditer tes permissions existantes

    Beaucoup de workflows historiques tournent encore avec des permissions par défaut trop larges. Un audit rapide consiste à passer en revue chaque fichier .github/workflows/*.yml et à vérifier qu’un bloc permissions explicite est défini au niveau du workflow ou du job, plutôt que de laisser GitHub appliquer ses valeurs par défaut.

    Ne pas négliger les runners self-hosted

    Si une partie de tes workflows tourne sur des runners self-hosted plutôt que sur l’infrastructure managée par GitHub, garde en tête que plusieurs des protections à venir (pare-feu de sortie notamment) cibleront d’abord les runners hébergés par GitHub. Sur du self-hosted, la responsabilité du durcissement réseau et système reste largement la tienne — un sujet sur lequel Azure DevOps propose une approche comparable avec ses Managed DevOps Pools, si tu veux comparer les deux écosystèmes.

    FAQ

    Faut-il déjà épingler toutes ses actions par SHA ?

    Ce n’est pas encore obligatoire, mais c’est déjà une bonne pratique recommandée par GitHub, en particulier pour les actions tierces peu maintenues ou à fort accès (secrets, déploiement). Pour les actions officielles GitHub, le risque est plus faible mais le principe reste valable.

    La permission vulnerability-alerts remplace-t-elle un scope Dependabot plus large ?

    Oui, dans les cas où un workflow n’a besoin que de lire l’état des alertes Dependabot. Avant cette permission dédiée, il fallait souvent accorder des droits plus étendus sur le repository pour arriver au même résultat.

    Le pare-feu de sortie va-t-il casser mes workflows actuels ?

    Une fois généralisé, oui potentiellement, si tes jobs contactent des services externes non listés dans l’allowlist. C’est justement pour ça qu’il vaut mieux commencer dès maintenant à documenter les destinations réseau utilisées par tes workflows, plutôt que de le découvrir en heurtant un blocage.

    En résumé

    Les nouveautés de septembre 2026 sont modestes prises isolément, mais elles annoncent une évolution de fond : GitHub Actions va progressivement imposer une hygiène de sécurité qui, aujourd’hui encore, dépend surtout de la discipline de chaque équipe. Autant prendre les devants — épingler tes actions, resserrer tes permissions, documenter tes flux réseau — plutôt que de découvrir ces contraintes le jour où elles deviennent obligatoires.

  • NIS2 en France en 2026 : où en est la loi, et comment t’y préparer sans l’attendre

    NIS2 en France en 2026 : où en est la loi, et comment t’y préparer sans l’attendre

    Si tu attends que la loi française de transposition de NIS2 soit votée pour t’en préoccuper, tu risques d’attendre longtemps — et de te retrouver à traiter dans l’urgence ce que tu aurais pu lisser sur plusieurs mois. Le texte accumule les reports depuis 2024, mais la directive européenne, elle, est déjà en vigueur, et tes clients ou donneurs d’ordre te demandent probablement déjà des garanties. Dans cet article, tu vas voir où en est exactement la loi en septembre 2026, qui sera concerné, quelles obligations concrètes t’attendent, et surtout ce que tu peux commencer à mettre en place dès aujourd’hui, indépendamment du calendrier parlementaire.

    NIS2, un rappel en une minute

    NIS2 (Network and Information Security 2) est la directive européenne (UE) 2022/2555 qui remplace la première directive NIS de 2016. Elle élargit fortement le périmètre des organisations concernées par des obligations de cybersécurité — on passe d’environ 500 entités régulées en France sous NIS1 à plusieurs milliers sous NIS2 — et durcit les obligations : gestion des risques, notification d’incidents, sécurité de la chaîne d’approvisionnement, et responsabilité personnelle des dirigeants en cas de manquement grave.

    Le délai de transposition fixé par l’Union européenne était le 17 octobre 2024. La France ne l’a pas tenu, et ce n’est pas un cas isolé : plusieurs États membres sont dans la même situation. Ça ne dispense personne des obligations de fond, qui découlent directement de la directive.

    Où en est réellement la loi française en septembre 2026 ?

    C’est le point que beaucoup d’admins et de RSSI ont du mal à suivre, tant le calendrier a glissé. Voici l’état des lieux :

    • Octobre 2024 : présentation du projet de loi de résilience (qui transpose NIS2 et intègre aussi une partie du règlement DORA) en Conseil des ministres.
    • 12 mars 2025 : adoption du texte par le Sénat en première lecture.
    • Septembre 2025 : fin de l’examen en commission spéciale à l’Assemblée nationale.
    • Été 2026 : le texte n’est finalement pas inscrit à l’ordre du jour de la session extraordinaire de juillet — nouveau report.
    • Septembre 2026 : un passage en séance publique à l’Assemblée est de nouveau annoncé, avec une promulgation qui pourrait suivre rapidement si le texte n’est pas trop amendé.

    Pendant ce temps, l’ANSSI n’a pas attendu le vote pour avancer sur le terrain technique : elle a publié en mars 2026 le référentiel ReCyF (Référentiel Cyber France), qui détaille une vingtaine d’objectifs de sécurité, et elle a ouvert la plateforme MonEspaceNIS2, qui permet à toute organisation de simuler son éligibilité et de s’enregistrer en amont. Concrètement : le texte de loi n’est pas encore promulgué, mais l’écosystème (ANSSI, secteurs régulés, grands donneurs d’ordre) fonctionne déjà largement comme si NIS2 s’appliquait.

    Qui sera concerné : entités essentielles, importantes… et ta collectivité

    Le texte français distingue deux catégories, reprises de la directive :

    • Entités essentielles : grandes entreprises (250 salariés ou plus, ou plus de 50 M€ de chiffre d’affaires) dans les secteurs à très forts enjeux — énergie, transport, banque, santé, eau, infrastructures numériques, administration publique.
    • Entités importantes : entreprises moyennes (50 salariés ou plus, ou plus de 10 M€ de chiffre d’affaires) dans ces mêmes secteurs, ou grandes entreprises dans des secteurs jugés moins critiques — postal, gestion des déchets, chimie, agroalimentaire, fabrication industrielle, services numériques.

    Particularité française : le texte étend le périmètre aux collectivités territoriales de plus de 30 000 habitants, ce qui change la donne pour pas mal d’équipes IT de collectivités qui ne se sentaient pas concernées jusque-là.

    Si tu es prestataire ou sous-traitant d’une entité régulée sans l’être toi-même directement, ne te crois pas hors sujet pour autant : la sécurité de la chaîne d’approvisionnement fait partie des obligations, ce qui veut dire que tes clients vont te demander des garanties contractuelles bien avant que la loi ne t’impose quoi que ce soit en direct.

    Les obligations concrètes qui t’attendent

    Les dix familles de mesures minimales

    Le texte prévoit dix familles de mesures de sécurité à mettre en œuvre, de façon proportionnée à la taille et à la criticité de l’entité :

    • Analyse des risques et politique de sécurité des systèmes d’information
    • Gestion des incidents
    • Continuité d’activité (sauvegardes, reprise après sinistre, gestion de crise)
    • Sécurité de la chaîne d’approvisionnement
    • Sécurité de l’acquisition, du développement et de la maintenance des systèmes
    • Évaluation de l’efficacité des mesures de gestion des risques
    • Hygiène informatique de base et formation à la cybersécurité
    • Politiques de cryptographie
    • Sécurité des ressources humaines et gestion des accès
    • Authentification multifacteur et solutions de communication sécurisées

    Notification d’incident : le calendrier qui ne pardonne pas

    Autre point à anticiper dès maintenant, indépendamment du vote de la loi : le rythme de notification d’un incident significatif. Il faut compter une alerte précoce sous 24h, une notification complète sous 72h, puis un rapport final sous un mois. Ça suppose d’avoir déjà, avant l’incident, une procédure claire et testée — pas quelque chose que tu improvises le jour J.

    Côté sanctions, le texte prévoit des montants dissuasifs : jusqu’à 10 M€ ou 2 % du chiffre d’affaires mondial pour les entités essentielles, 7 M€ ou 1,4 % pour les entités importantes, avec en plus des pouvoirs de suspension, d’injonction, et une responsabilité personnelle possible des dirigeants.

    Comment t’y préparer dès maintenant, sans attendre le vote définitif

    La bonne nouvelle, c’est qu’aucune des actions ci-dessous n’est perdue si la loi change encore de forme d’ici sa promulgation — ce sont des fondamentaux de sécurité que tu as intérêt à avoir de toute façon.

    1. Vérifie ton statut sur MonEspaceNIS2

    Le simulateur d’éligibilité de l’ANSSI te donne en quelques minutes une première indication de ta catégorie probable (essentielle, importante, ou hors périmètre). Ça t’évite de mobiliser du temps sur un sujet qui, potentiellement, ne te concerne pas encore directement.

    2. Cartographie ton SI et tes fournisseurs

    C’est le prérequis à peu près à toutes les mesures qui suivent : tu ne peux pas gérer un risque que tu n’as pas identifié. Liste tes systèmes critiques, leurs interdépendances, et surtout tes prestataires externes (hébergeur, éditeurs SaaS, intégrateurs) — c’est souvent le point aveugle.

    3. Généralise le MFA avant qu’on te l’impose

    L’authentification multifacteur fait partie des dix familles de mesures, et c’est aussi l’un des contrôles avec le meilleur rapport effort/protection contre les compromissions de comptes. Si tu es sur Microsoft Entra ID, le changement d’enforcement Conditional Access de juin 2026 pousse déjà dans ce sens côté Microsoft. Pour auditer rapidement qui n’a pas encore de méthode MFA robuste enregistrée dans ton tenant, un script PowerShell avec le module Microsoft Graph fait le travail :

    Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All", "User.Read.All"
    
    Get-MgUser -All -Property Id, DisplayName, UserPrincipalName | ForEach-Object {
        $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
        $hasStrongMfa = $methods | Where-Object {
            $_.AdditionalProperties["@odata.type"] -match "microsoftAuthenticatorAuthenticationMethod|fido2AuthenticationMethod|windowsHelloForBusinessAuthenticationMethod"
        }
        [PSCustomObject]@{
            Utilisateur = $_.UserPrincipalName
            MfaRobuste  = [bool]$hasStrongMfa
        }
    } | Where-Object { -not $_.MfaRobuste } | Export-Csv "audit-mfa-faible.csv" -NoTypeInformation -Encoding UTF8
    

    La documentation complète de la cmdlet Get-MgUserAuthenticationMethod est disponible sur Microsoft Learn.

    4. Durcis tes environnements techniques

    Si une partie de ton infrastructure tourne sur Kubernetes, la sécurisation du cluster (RBAC, network policies, gestion des secrets, images signées) rentre directement dans les mesures de sécurité du développement et de la maintenance des systèmes exigées par NIS2. Notre guide complet pour sécuriser un cluster Kubernetes couvre ces points un par un si tu veux avancer concrètement sur ce chantier.

    FAQ

    NIS2 s’applique-t-elle déjà en France si la loi n’est pas votée ?

    La directive européenne est en vigueur depuis 2023, mais elle ne devient contraignante en droit français qu’une fois transposée par une loi nationale. Tant que le texte n’est pas promulgué, il n’y a pas encore de base légale française pour sanctionner un manquement au titre de NIS2 spécifiquement. En revanche, des obligations proches existent déjà par ailleurs (LPM pour les OIV, RGPD pour les données personnelles), et attendre la loi pour agir revient à se donner très peu de temps une fois qu’elle sera votée.

    Comment savoir si mon organisation est une entité essentielle ou importante ?

    Le simulateur d’éligibilité de MonEspaceNIS2 est le point de départ le plus fiable, en croisant ton secteur d’activité, ta taille et ton chiffre d’affaires avec les annexes de la directive.

    Le MFA seul suffit-il à être conforme ?

    Non. C’est une des dix familles de mesures, pas la seule. La conformité suppose une démarche globale — analyse de risques, continuité d’activité, sécurité fournisseurs, etc. — mais le MFA reste un des contrôles les plus rapides à déployer largement et l’un de ceux qui réduisent le plus vite la surface d’attaque réelle.

    En résumé

    La loi française traîne, mais ni les obligations de fond de NIS2, ni la pression commerciale de tes clients et donneurs d’ordre n’attendent le vote définitif. Utilise ce délai à ton avantage : cartographie ton SI, généralise le MFA, avance sur le durcissement de tes environnements techniques, et suis l’avancement du texte via le site de l’ANSSI. Le jour où la loi sera promulguée, tu seras déjà bien avancé plutôt qu’en train de découvrir le sujet.

  • Conditional Access : le changement d’enforcement du 15 juin 2026

    Conditional Access : le changement d’enforcement du 15 juin 2026

    Si tu administres un tenant Microsoft Entra ID, une échéance mérite ton attention avant l’été : à partir du 15 juin 2026, Microsoft change la façon dont les Conditional Access policies gèrent les exclusions de ressources. Le changement corrige une vraie faille de sécurité, mais il peut aussi bloquer des applications qui fonctionnaient sans souci jusque-là si tu ne l’anticipes pas. Voici ce qui change, pourquoi, et comment vérifier que ton tenant est prêt.

    Le problème que ce changement corrige

    Jusqu’à présent, quand une Conditional Access policy ciblait « All resources » (toutes les ressources) tout en excluant certaines applications, ces applications exclues échappaient aussi à l’enforcement sur ce que Microsoft appelle les baseline scopes — des permissions considérées comme peu sensibles par défaut : lecture du profil de l’utilisateur (User.Read, profile, openid…), appartenance aux groupes, informations de base sur les collègues.

    Concrètement, ça veut dire qu’une application desktop comme Azure CLI ou VS Code, qui ne demande que ces scopes basiques, pouvait passer complètement à côté de tes politiques MFA — même sur un tenant où la MFA est censée être obligatoire pour tout le monde. À partir du 15 juin 2026, ces baseline scopes sont évalués comme un accès normal à l’annuaire, et donc soumis aux Conditional Access policies même en présence d’exclusions.

    Qui est concerné ?

    • Les applications qui ne demandent que des baseline scopes (OIDC : email, offline_access, openid, profile ; annuaire : User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden)
    • Les policies ciblant « All resources » avec des exclusions de ressources configurées

    Si tes applications demandent déjà des scopes plus larges (Mail.Read, Files.ReadWrite, etc.), rien ne change pour toi : elles étaient déjà soumises à l’enforcement.

    Comment vérifier si ton tenant est concerné

    1. Repérer les policies à risque

    Dans le portail Entra, filtre tes Conditional Access policies pour identifier celles qui ciblent « All resources » avec au moins une exclusion d’application. Ce sont les seules concernées par le changement.

    2. Auditer les connexions réelles avec Microsoft Graph

    Pour savoir quelles applications de ton tenant s’appuient sur ces exclusions, tu peux interroger les logs de connexion via l’API Microsoft Graph :

    GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=createdDateTime ge 2026-05-26T00:00:00Z and createdDateTime lt 2026-05-27T00:00:00Z and conditionalAccessAudiences/any(a:a eq '<ton-app-id>')&$select=createdDateTime,appId,appDisplayName,userDisplayName,userPrincipalName,ipAddress,conditionalAccessStatus

    Si tu préfères scripter cet audit plutôt que de passer par des requêtes REST brutes, le module PowerShell Microsoft Graph (Microsoft.Graph.Reports) permet de faire la même chose avec des cmdlets plus lisibles à intégrer dans un script de contrôle régulier — on détaille les bases de l’automatisation PowerShell côté administration système dans notre guide complet PowerShell pour administrateurs.

    3. Tester avant le 15 juin

    Microsoft permet d’activer l’enforcement dès maintenant, avant la bascule automatique, pour tester son impact dans un tenant de test ou avec un groupe pilote. C’est l’option la plus sûre : tu identifies les applications qui vont réclamer un défi MFA avant que ça n’arrive en production sans prévenir.

    Tes trois options

    Option A — Activer l’enforcement (recommandé)

    Depuis les paramètres Baseline scopes, connecte-toi avec un rôle Conditional Access Administrator, sélectionne « Enable enforcement », puis confirme. C’est l’option qui referme la faille de sécurité pour de bon.

    Option B — Personnaliser par application (approche hybride)

    Si une application métier a vraiment besoin de rester exclue, crée une application « placeholder » dédiée dans Entra ID, exclus-la explicitement des policies concernées, puis configure ce comportement personnalisé dans les paramètres Baseline scopes plutôt que de désactiver l’enforcement pour tout le monde.

    Option C — Désactiver l’enforcement

    Techniquement possible, mais déconseillé : ça revient à conserver la faille corrigée par ce changement. À réserver aux cas de blocage critique le temps de trouver une solution propre.

    Et si tu ne fais rien ?

    L’enforcement s’active automatiquement à partir du 15 juin 2026, en rollout progressif sur plusieurs semaines. Si tu n’as pas d’exclusions configurées sur tes policies « All resources », ce changement ne te concerne tout simplement pas. Si tu en as, mieux vaut avoir testé et anticipé plutôt que de découvrir un blocage de connexion un lundi matin.

    FAQ

    Ce changement s’applique-t-il à toutes les licences Entra ID ?

    Les Conditional Access policies nécessitent Microsoft Entra ID P1 au minimum ; le changement d’enforcement s’applique à tout tenant utilisant déjà ce type de policies avec des exclusions de ressources, quelle que soit la volumétrie.

    Comment savoir si mes comptes de secours (break-glass) sont concernés ?

    Les comptes d’urgence doivent rester exclus de toutes tes policies Conditional Access par principe, y compris de celle-ci — ce changement ne remet pas en cause cette bonne pratique fondamentale, tant que l’exclusion reste documentée et surveillée.

    Où suivre les prochaines évolutions des Conditional Access policies ?

    Le blog officiel Microsoft Entra sur Tech Community et la documentation Microsoft Learn dédiée à ce changement sont mis à jour au fil du rollout.

    En résumé

    Ce changement d’enforcement referme une faille bien réelle, mais il demande une vérification active de ta part avant le 15 juin 2026 si tes policies « All resources » comportent des exclusions. Prends le temps d’auditer tes applications, de tester en mode pilote, et de documenter les exceptions que tu choisis de garder. Pour construire tes politiques Conditional Access sur des bases solides dès le départ, la documentation Microsoft Learn sur la planification du déploiement reste la référence à suivre, phase par phase.

  • Managed DevOps Pools : la fin de la maintenance des agents Azure Pipelines

    Managed DevOps Pools : la fin de la maintenance des agents Azure Pipelines

    Tu en as marre de mettre à jour l’agent Azure Pipelines sur ta VM self-hosted, de recréer l’image quand une dépendance casse, ou de payer pour des runners qui tournent 24h/24 alors que tes builds ne durent que quelques minutes par jour ? Microsoft a justement sorti une réponse à ce problème : Managed DevOps Pools. Dans cet article, on regarde ce que c’est concrètement, comment le mettre en place, et si ça vaut le coup de migrer tes pools self-hosted existants.

    Managed DevOps Pools, c’est quoi exactement ?

    Managed DevOps Pools est un service Azure qui te fournit des pools d’agents Azure Pipelines entièrement gérés, hébergés dans l’infrastructure Microsoft (et non dans ton abonnement), mais que tu configures et factures depuis ton propre tenant Azure. En clair : tu gardes le contrôle sur l’image, la taille de VM, la région et les règles réseau, mais tu n’as plus à gérer le patching, le scaling ou le cycle de vie des machines.

    C’est la même logique que les Microsoft-hosted agents classiques, sauf que tu peux personnaliser l’image (y compris avec Azure Compute Gallery), rattacher le pool à ton propre réseau virtuel, et bénéficier d’agents « standby » qui réduisent fortement le temps d’attente avant le démarrage d’un job.

    Pourquoi c’est différent d’un pool self-hosted classique

    Aspect Managed DevOps Pools Self-hosted classique
    Gestion de l’infrastructure Entièrement prise en charge par Microsoft À ta charge (patching, mises à jour de l’agent, disque plein…)
    Scaling Automatique selon la charge des jobs en file Manuel ou via tes propres scripts d’autoscaling
    Sécurité Intégration native Azure Key Vault, IP statiques, certificats racine auto-importés À configurer toi-même sur chaque image
    Coût Facturé à l’usage, avec option Spot VM à venir Coût fixe des VM, même à l’arrêt si mal dimensionné

    Mettre en place ton premier Managed DevOps Pool

    Prérequis

    • Un abonnement Azure actif, avec le fournisseur de ressources Microsoft.DevOpsInfrastructure enregistré
    • Les droits pour créer des ressources dans ton abonnement (rôle Contributeur ou équivalent)
    • Une organisation Azure DevOps où tu as les droits d’administration des pools d’agents

    Tu peux enregistrer le fournisseur de ressources en une commande Azure CLI :

    az provider register --namespace Microsoft.DevOpsInfrastructure

    Créer le pool

    La création se fait depuis le portail Azure (recherche « Managed DevOps Pools » dans la barre de recherche) ou via une template ARM/Bicep si tu préfères tout piloter en Infrastructure as Code. Si tu gères déjà ton infra Azure avec Terraform, garde en tête que le provider azurerm ne couvre pas encore nativement cette ressource : il faut passer par le provider azapi en attendant. Si tu es en pleine migration vers AzureRM 5.0, c’est un bon moment pour vérifier ce genre de dépendances — on en parle en détail dans notre guide de migration Terraform AzureRM 5.0.

    Une fois le pool créé et nommé, il suffit de le référencer dans ton pipeline YAML exactement comme un pool self-hosted classique :

    trigger:
    - main
    
    pool:
      name: mon-pool-managed-devops
    
    steps:
    - script: echo "Build lancé sur un agent Managed DevOps Pool"
      displayName: 'Étape de build'

    Aucune modification du reste de ton pipeline n’est nécessaire : c’est un remplacement transparent pour tes définitions de pool existantes.

    Choisir son image

    Tu as le choix entre les images Marketplace proposées par Microsoft (Windows Server 2025, Ubuntu 24.04 LTS…) et tes propres images personnalisées publiées dans une Azure Compute Gallery — pratique si ton pipeline dépend d’outils spécifiques déjà préinstallés. Microsoft retire régulièrement les images en fin de vie (Windows Server 2019 et Ubuntu 20.04 sont déjà hors support sur le service), donc prévois de suivre le calendrier des versions supportées pour éviter une mauvaise surprise le jour où une image bascule en obsolète.

    Ce qui arrive prochainement

    La roadmap du service reste active. Les fonctionnalités déjà livrées en 2026 incluent la suppression des images obsolètes, l’intégration à Log Analytics pour le monitoring, et récemment la possibilité de donner un alias personnalisé à un pool. Sont annoncées pour la suite : le support de plusieurs tailles de VM dans un même pool (Instance Mix), le recyclage manuel des agents, des scripts de démarrage personnalisés, le support des VM Spot (jusqu’à -90% de coût) et, plus tard dans l’année, des agents conteneurisés. De quoi rapprocher encore un peu plus ce service d’un pool self-hosted mais sans l’astreinte de maintenance.

    FAQ

    Managed DevOps Pools remplace-t-il complètement les agents self-hosted ?

    Pas forcément. Si tu as besoin d’un accès à du matériel très spécifique (GPU particulier, périphérique physique, réseau on-premises complexe sans passer par un VNet peering) ou d’agents qui tournent en permanence sans coût à l’usage, le self-hosted classique reste pertinent. Pour la majorité des cas d’usage CI/CD standards, Managed DevOps Pools réduit nettement la charge opérationnelle.

    Est-ce compatible avec les Microsoft-hosted agents existants ?

    Oui, tu peux faire cohabiter les trois types de pools (Microsoft-hosted, Managed DevOps Pools, self-hosted) dans la même organisation et répartir tes pipelines selon leurs besoins.

    Dans quelles régions le service est-il disponible ?

    La liste des régions s’étend régulièrement ; à ce jour, Managed DevOps Pools couvre notamment l’Europe du Nord, la Suède, le Royaume-Uni, le Brésil, le Japon, la Corée, la Norvège et les Émirats Arabes Unis. Vérifie la documentation officielle Microsoft Learn pour la liste à jour avant de planifier un déploiement.

    En résumé

    Managed DevOps Pools répond directement à la douleur la plus commune des équipes qui gèrent leurs propres agents Azure Pipelines : le temps passé à maintenir l’infrastructure plutôt qu’à livrer du code. Si tu gères aujourd’hui un pool self-hosted qui te demande plus d’attention que prévu, c’est le moment de tester une migration progressive — un seul pipeline non critique suffit pour valider que tout fonctionne avant de généraliser. Consulte le guide de démarrage rapide Microsoft Learn et le dépôt de documentation sur GitHub pour suivre les évolutions du service au fil des mises à jour.

  • Sécuriser un cluster Kubernetes en 2026 : guide complet

    Sécuriser un cluster Kubernetes en 2026 : guide complet

    Ton cluster Kubernetes est-il vraiment sécurisé, ou juste « en prod depuis longtemps sans incident » ?

    Il y a une différence entre un cluster Kubernetes qui tourne sans problème et un cluster réellement sécurisé. La première catégorie te donne un faux sentiment de tranquillité, jusqu’au jour où un pod compromis obtient des droits qu’il n’aurait jamais dû avoir. Avec la sortie de Kubernetes 1.34 puis la version 1.37, actuellement la dernière stable, c’est le bon moment pour faire un point complet sur les fondamentaux de sécurité de ton cluster — qu’il tourne en AKS, EKS, GKE ou on-premise.

    Dans cet article, on passe en revue les couches de sécurité qui comptent vraiment : Pod Security Standards, RBAC, Network Policies et scan d’images. Pas de liste à cocher vague — des exemples concrets que tu peux appliquer cette semaine.

    Pod Security Standards : la base que tu dois avoir

    Depuis que PodSecurityPolicy a été retiré de Kubernetes, les Pod Security Standards (PSS) sont devenus la référence officielle pour encadrer ce qu’un pod a le droit de faire. Trois niveaux existent :

    • Privileged : aucune restriction, réservé aux composants système ou aux clusters de test isolés
    • Baseline : bloque les vulnérabilités connues et graves (pas de conteneurs privilégiés, pas d’accès root au host) tout en restant compatible avec la plupart des applications
    • Restricted : le niveau le plus strict, pensé pour la production et les environnements multi-tenant

    Appliquer un niveau via Pod Security Admission

    Le plus simple, c’est d’étiqueter tes namespaces. Tu peux même combiner audit, warn et enforce pour une transition progressive sans tout casser d’un coup :

    apiVersion: v1
    kind: Namespace
    metadata:
      name: production
      labels:
        pod-security.kubernetes.io/enforce: restricted
        pod-security.kubernetes.io/enforce-version: latest
        pod-security.kubernetes.io/audit: restricted
        pod-security.kubernetes.io/warn: restricted
    

    Un pod conforme au niveau Restricted ressemble à ça :

    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: app
        image: mon-registry/app:1.4.2
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop: ["ALL"]
    

    Astuce pour l’adoption : commence toujours en mode audit sur un namespace existant avant de passer en enforce. Ça t’évite de bloquer des déploiements légitimes que tu n’avais pas anticipés.

    RBAC : le principe du moindre privilège, pour de vrai

    Le RBAC (Role-Based Access Control) est souvent configuré une fois au démarrage du cluster, puis plus jamais revisité — et c’est justement là que le risque s’accumule au fil du temps, à mesure que des ServiceAccounts et des rôles s’empilent.

    Trois réflexes à adopter :

    • Ne donne jamais cluster-admin à un ServiceAccount applicatif. Crée des Role et RoleBinding scopés au namespace plutôt que des ClusterRole par défaut.
    • Audite régulièrement qui a accès à quoi avec kubectl auth can-i --list --as=system:serviceaccount:namespace:nom-du-sa
    • Désactive le montage automatique du token ServiceAccount pour les pods qui n’ont pas besoin de parler à l’API Kubernetes : automountServiceAccountToken: false

    Network Policies : ton cluster n’est pas un réseau plat par défaut… sauf si tu ne fais rien

    Par défaut, sans Network Policy, tous les pods de ton cluster peuvent communiquer entre eux, quel que soit le namespace. C’est pratique au début, catastrophique une fois qu’un composant est compromis : l’attaquant peut se déplacer latéralement sans aucune friction.

    La bonne pratique consiste à partir d’une politique « deny all » par namespace, puis à autoriser explicitement les flux nécessaires :

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: deny-all-ingress
      namespace: production
    spec:
      podSelector: {}
      policyTypes:
        - Ingress
    

    Puis tu ouvres au cas par cas, par exemple pour autoriser uniquement le trafic venant de ton ingress controller vers ton API. Ça demande un peu de rigueur au départ, mais ça te protège des mouvements latéraux qui transforment un incident mineur en compromission complète du cluster.

    Scan d’images et supply chain : ne déploie pas ce que tu n’as pas vérifié

    Une image de conteneur, c’est du code que tu exécutes en production, au même titre qu’un binaire. Pourtant, beaucoup d’équipes déploient encore des images sans jamais les scanner. Intègre le scan de vulnérabilités directement dans ta CI/CD, avant que l’image atteigne ton registre de production :

    • Scanne chaque image au build (Trivy, Grype ou l’outil intégré à ton registre cloud)
    • Bloque le pipeline si une vulnérabilité critique est détectée sans correctif disponible
    • Utilise des images de base minimales (distroless ou Alpine) pour réduire la surface d’attaque
    • Signe tes images avec Cosign et vérifie la signature à l’admission via une politique dédiée

    Cette approche « shift left » te coûte quelques minutes de pipeline en plus, mais elle t’évite de découvrir une CVE critique une fois l’image déjà en production sur des dizaines de pods.

    Les mêmes principes s’appliquent en amont, dans tes pipelines : les leçons des attaques supply chain CI/CD de mars 2026.

    Surveille en continu, pas seulement au moment du déploiement

    Toutes les protections précédentes réduisent la surface d’attaque, mais elles ne remplacent pas une vraie visibilité sur ce qui se passe dans ton cluster en temps réel. Active les audit logs de l’API Kubernetes pour savoir qui fait quoi, et pas seulement au moment de l’incident.

    • Centralise les audit logs dans ta stack d’observabilité (au même titre que les logs applicatifs) pour pouvoir reconstituer une chronologie en cas d’incident
    • Ajoute une détection runtime avec un outil comme Falco, qui repère les comportements anormaux à l’intérieur des conteneurs (exécution d’un shell inattendu, écriture dans un répertoire système)
    • Mets en place des alertes sur les changements de RBAC eux-mêmes : un nouveau ClusterRoleBinding créé en dehors de ta CI est un signal fort à ne jamais ignorer

    Cette couche de détection est ce qui te permet de réagir en minutes plutôt qu’en jours quand une des couches précédentes a été contournée. Aucune protection n’est infaillible à 100 % : c’est la combinaison prévention + détection qui fait la différence entre un incident contenu et une compromission complète.

    FAQ

    Par où commencer si mon cluster n’a aucune de ces protections aujourd’hui ?

    Commence par les Network Policies en mode « deny all » sur tes namespaces les plus sensibles, puis les Pod Security Standards en mode audit. Ce sont les deux mesures qui limitent le plus l’impact d’une compromission, pour un effort de mise en place raisonnable.

    Le niveau Restricted des Pod Security Standards casse-t-il les applications existantes ?

    Souvent oui, si elles n’ont pas été conçues avec ces contraintes en tête (utilisateur root, écriture sur le système de fichiers racine). D’où l’intérêt du mode audit avant enforce : tu identifies les pods problématiques sans bloquer la production.

    Faut-il un outil tiers (Falco, OPA Gatekeeper) en plus des fonctionnalités natives ?

    Les fonctionnalités natives (PSS, RBAC, NetworkPolicy) couvrent une bonne base. Des outils comme OPA Gatekeeper ou Kyverno deviennent utiles quand tu as besoin de politiques plus fines que ce que Kubernetes propose nativement, ou d’une détection runtime avec Falco.

    Comment savoir si mon cluster est déjà sur une version supportée ?

    Kubernetes maintient les trois dernières versions mineures. Vérifie ta version avec kubectl version et compare-la aux versions actives sur la page officielle des releases. Une version hors support ne reçoit plus de correctifs de sécurité.

    Les changements de la dernière version sont détaillés dans mon article sur Kubernetes 1.37.

    Le scan d’images suffit-il à sécuriser ma supply chain ?

    Non, c’est une couche parmi d’autres. Associe-le à la signature d’images et à une politique d’admission qui vérifie la provenance, sinon rien n’empêche une image non scannée de passer par un autre chemin de déploiement.

    En résumé

    La sécurité Kubernetes n’est pas un projet qu’on termine puis qu’on oublie : c’est une couche qui se construit progressivement, namespace par namespace, politique par politique. Commence par les fondamentaux — Pod Security Standards en mode audit, RBAC scopé, Network Policies deny-all, scan d’images en CI — et itère à partir de là. Chaque couche que tu ajoutes réduit concrètement ce qu’un attaquant peut faire s’il obtient un pied dans ton cluster.

    Vérifie dès aujourd’hui l’état de tes Network Policies sur ton namespace de production : c’est souvent la première surprise, et la plus rapide à corriger.

  • Terraform AzureRM 5.0 : ce qui change et comment migrer sans casse

    Terraform AzureRM 5.0 : ce qui change et comment migrer sans casse

    Terraform AzureRM 5.0 est disponible : pourquoi ce n’est pas une montée de version comme les autres

    Si tu gères de l’infra Azure avec Terraform, tu as sans doute déjà vu passer l’annonce : le provider hashicorp/azurerm vient de passer en version majeure 5.0, officiellement disponible en General Availability. Et contrairement aux montées de version mineures que tu appliques d’un terraform init -upgrade sans trop y réfléchir, celle-ci mérite que tu t’arrêtes cinq minutes avant de foncer.

    Pourquoi ? Parce que cette version 5.0 change des comportements par défaut qui touchent quasiment tous les projets Terraform sur Azure, même les plus simples. Si tu appliques la montée de version en production sans préparation, tu risques un terraform plan qui explose de partout — ou pire, un apply qui échoue en plein déploiement. Dans cet article, on regarde ensemble ce qui change concrètement, comment migrer sans y laisser ta soirée, et comment éviter les pièges classiques.

    Ce qui casse vraiment avec AzureRM 5.0

    HashiCorp a publié un guide de migration officiel, mais voici les points qui vont te concerner en priorité.

    1. Plus aucun Resource Provider enregistré par défaut

    C’est le changement le plus lourd de conséquences. En version 4.x, le provider enregistrait automatiquement une soixantaine de Resource Providers Azure (Microsoft.Compute, Microsoft.Network, etc.) au premier apply. Cette magie disparaît totalement en 5.0 : plus rien n’est enregistré automatiquement.

    Concrètement, si ton abonnement Azure n’a pas déjà ces providers enregistrés (ce qui est fréquent sur un abonnement neuf ou une souscription bien nettoyée), tes déploiements vont échouer avec des erreurs du type MissingSubscriptionRegistration. Deux options s’offrent à toi :

    • Lister explicitement les providers dont tu as besoin dans le bloc provider "azurerm"
    • Restaurer temporairement le comportement historique avec resource_provider_registrations = "legacy", le temps de migrer proprement
    provider "azurerm" {
      features {}
      resource_provider_registrations = "core"
      resource_providers_to_register   = [
        "Microsoft.ContainerService",
        "Microsoft.KeyVault"
      ]
    }
    

    Ça t’évite de découvrir le problème en pleine CI/CD un vendredi après-midi.

    2. La validation renforcée change de camp

    Le bloc enhanced_validation déménage à l’intérieur de features, et surtout, la validation des régions et des providers passe à désactivée par défaut. Résultat : les erreurs qui remontaient auparavant pendant le plan (une région mal orthographiée, par exemple) ne se déclenchent maintenant qu’au moment de l’apply. Si tu veux garder ce filet de sécurité en amont, réactive-le explicitement :

    provider "azurerm" {
      features {}
      enhanced_validation {
        locations = true
      }
    }
    

    3. Validation Preflight, mais seulement pour six ressources

    Nouveauté intéressante : le provider peut désormais valider certaines charges utiles directement contre l’API Preflight d’Azure, avant même de tenter le déploiement. Le hic, c’est que ça ne couvre pour l’instant que six types de ressources : App Service Environment v3, Service Plan, Grafana, Redis, NGINX et Event Grid. Pour tout le reste, cette protection ne s’applique pas — ne compte pas dessus comme filet universel.

    4. Les ressources App Service et Function App historiques disparaissent

    Si ton code utilise encore azurerm_app_service ou azurerm_function_app, il va falloir migrer vers les variantes typées par OS : azurerm_linux_web_app, azurerm_windows_web_app, azurerm_linux_function_app, azurerm_windows_function_app. Ce n’est pas qu’un renommage : ça implique une migration d’état Terraform (terraform state mv ou import) puisque le schéma des ressources change.

    5. Des changements de schéma plus discrets, mais tout aussi cassants

    En plus des gros titres, attends-toi à des surprises plus subtiles : des propriétés renommées avec parfois une inversion de polarité (par exemple disable_automatic_rollback devient automatic_rollback_enabled — attention au sens inverse du booléen), des attributs autrefois optionnels devenus obligatoires, des types qui passent de liste à set, et des blocs imbriqués promus en ressources autonomes. Ce sont typiquement les erreurs qui ne sautent pas aux yeux en relisant le changelog en diagonale.

    Comment migrer sans casser ta prod

    Voici la méthode que je te recommande, plutôt que de foncer tête baissée :

    • Épingle la version avant de migrer : version = "= 4.x.x" le temps de préparer le terrain, puis bascule sur = 5.0.0 de façon contrôlée plutôt que d’utiliser une contrainte ouverte comme ~> 5.0 dès le départ.
    • Teste sur une souscription non-production. Si tu n’en as pas, crée un abonnement Azure dédié aux tests d’infra — ça coûte moins cher qu’un incident en prod.
    • Lance un terraform plan complet et lis-le en entier, pas juste le résumé. C’est là que tu repères les changements de schéma silencieux.
    • Traite les migrations d’état séparément des autres changements, pour isoler les risques (App Service/Function App notamment).
    • Automatise la vérification dans ta pipeline CI/CD : un job qui bloque le merge si le plan détecte un destroy non attendu te sauve la mise plus d’une fois.

    Et si tu n’es pas encore prêt à migrer ?

    Rien ne t’oblige à sauter sur la 5.0 le jour de sa sortie. Tu peux tout à fait rester sur la branche 4.x le temps de planifier la migration — HashiCorp continue de publier des correctifs sur les anciennes versions majeures pendant une période de transition. Consulte le registre officiel du provider pour suivre les releases et leur statut de support.

    Si c’est l’outil lui-même que tu remets en question plutôt que la version du provider, regarde mon comparatif OpenTofu vs Terraform.

    Ce qui compte, c’est que la migration soit un choix planifié et testé, pas une surprise découverte parce qu’une contrainte de version trop permissive a tiré la 5.0 automatiquement dans ta CI.

    Automatise la détection des breaking changes avant qu’ils ne te surprennent

    Une bonne pratique que je te recommande, au-delà de cette migration précise : intègre un contrôle statique dans ta pipeline CI/CD pour repérer les changements risqués avant même d’arriver au plan. Des outils comme tflint ou checkov peuvent te signaler l’usage de ressources dépréciées ou de mauvaises pratiques directement dans ta merge request, avant que ça n’atteigne l’environnement de test.

    # Exemple minimal d'étape CI
    - name: Lint Terraform
      run: |
        tflint --init
        tflint
    - name: Terraform plan
      run: terraform plan -out=tfplan
    

    Combine ça avec une revue systématique du plan par un humain avant tout apply en production, même si ta pipeline est largement automatisée. Les changements de schéma silencieux comme ceux qu’AzureRM 5.0 introduit sont justement le genre de choses qu’un œil attentif repère, mais qu’un pipeline purement automatisé peut laisser passer si tu n’as pas configuré les bons garde-fous.

    FAQ

    Dois-je migrer immédiatement vers AzureRM 5.0 ?

    Non, pas dans l’urgence. Prends le temps de tester en environnement isolé. Fixe une version explicite dans tes fichiers Terraform pour éviter qu’une mise à jour automatique te bascule en 5.0 sans préparation.

    Le comportement « legacy » d’enregistrement des providers va-t-il disparaître ?

    HashiCorp le présente comme une option de transition. Ne construis pas ta stratégie long terme dessus : c’est fait pour t’aider à migrer en douceur, pas pour rester en place indéfiniment.

    Comment je repère les ressources dépréciées dans mon code existant ?

    Le guide de migration officiel liste les ressources et attributs concernés. Un passage par terraform plan avec la 5.0 activée en environnement de test te montrera aussi les erreurs de schéma directement.

    Est-ce que ça concerne aussi Bicep ou seulement Terraform ?

    Uniquement Terraform et le provider AzureRM. Bicep, qui parle directement à l’API Azure Resource Manager, n’est pas concerné par ces changements côté provider tiers.

    Si tu hésites encore entre les deux outils, j’ai comparé Terraform et Bicep pour Azure.

    Que faire si je découvre un breaking change non documenté ?

    Ouvre une issue sur le dépôt GitHub du provider. La communauté et l’équipe HashiCorp sont réactives, et ça évite à d’autres admins de tomber dans le même piège.

    En résumé

    AzureRM 5.0 apporte de vraies améliorations — moins de magie cachée, plus de contrôle explicite sur ce que Terraform fait dans ton abonnement Azure. Mais ça se paie par une migration qui demande de la méthode. Prends le temps de tester, épingle tes versions, et lis vraiment tes plan avant de les appliquer. Ton futur toi (et ton équipe d’astreinte) t’en remerciera.

    Tu as déjà migré et rencontré un cas particulier pas couvert ici ? Partage-le, ça aide toute la communauté Azure/Terraform à anticiper.