Ctrl+Alt+Prod

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

  • OpenTelemetry Profiles : le 4e signal, six mois après son alpha publique

    OpenTelemetry Profiles : le 4e signal, six mois après son alpha publique

    Traces, métriques, logs : les trois signaux historiques d’OpenTelemetry répondent bien à « quoi » et « quand », beaucoup moins bien à « pourquoi ce pod consomme 4 cœurs pour traiter 200 requêtes par seconde ». Pour répondre à cette question-là, il fallait jusqu’ici un profiler dédié — souvent propriétaire, souvent payant, rarement corrélé au reste de ta télémétrie. Depuis le 26 mars 2026, OpenTelemetry a un quatrième signal officiel pour ça : les profiles, entrés en alpha publique.

    Six mois plus tard, où en est vraiment ce signal, et est-ce raisonnable de commencer à s’y intéresser sérieusement ?

    Ce que le profiling continu apporte concrètement

    L’idée n’est pas nouvelle — Pyroscope, Parca ou le Continuous Profiler de Datadog font ça depuis des années. Ce qui l’est, c’est la standardisation : un format commun pour représenter des stacks d’appel échantillonnées en continu, avec une corrélation native aux traces via les mêmes trace_id et span_id. Concrètement, tu peux passer d’une trace lente dans Grafana Tempo ou Jaeger directement au profil CPU du service concerné, sans changer d’outil ni recorréler manuellement par timestamp.

    Techniquement, la représentation est dédupliquée : chaque call-stack unique n’est stocké qu’une fois, référencé ensuite par index. Avec le support de dictionnaires de chaînes ajouté au format, l’annonce officielle parle d’une réduction de 40 % de la taille sur le réseau par rapport à une représentation naïve. Pour un signal dont le volume de données peut vite dépasser celui des traces classiques, ce n’est pas un détail cosmétique.

    Les runtimes déjà supportés par l’agent eBPF

    L’agent de profiling eBPF (celui qui échantillonne sans toucher au code de l’application) couvre aujourd’hui :

    • Go, avec symbolisation automatique sur la cible ;
    • Node.js (moteur V8), y compris sur architecture ARM64 ;
    • Ruby, avec des améliorations récentes sur le unwinding et la symbolisation ;
    • .NET 9 et 10 ;
    • BEAM (Erlang/Elixir), en support initial, donc encore limité.

    Si tu es sur du Python ou du Java pur JVM, la couverture native n’est pas encore là — à vérifier avant de bâtir un business case dessus.

    Le vrai statut en septembre 2026 : encore alpha, et ça compte

    L’annonce officielle est sans ambiguïté sur ce point : « with the Alpha status of the release, the signal should not be used for critical production workloads ». Ce n’est pas une formule de prudence juridique standard — les backends capables d’ingérer et d’exploiter ce format en production ne sont eux-mêmes pas encore matures partout. Le Collector OpenTelemetry sait déjà traiter et transformer des données de profiling, mais les receivers/exporters spécifiques évoluent encore vite dans opentelemetry-collector-contrib, au rythme de plusieurs changements par semaine.

    Ma position là-dessus : c’est le bon moment pour tester sur un environnement de dev ou de préproduction, pas pour remplacer ton profiler de production actuel. Si tu utilises déjà Pyroscope ou un profiler propriétaire qui te satisfait, garde-le en place et suis l’évolution du signal en parallèle — la bascule aura plus de sens quand le format atteindra au minimum le statut bêta et que ton backend d’observabilité (Grafana, Elastic, ou autre) l’exposera nativement.

    Comment ça s’articule avec ce qu’on a déjà couvert

    Si tu as suivi la mise en production de l’instrumentation eBPF zero-code (OBI), la logique est la même côté infrastructure : pas de modification de code, un agent qui observe depuis l’extérieur. La différence est dans la donnée produite — OBI génère des traces et métriques à partir du trafic réseau observé, les profiles génèrent des échantillons de call-stacks CPU/mémoire. Les deux sont complémentaires, pas substituables l’un à l’autre.

    Et si ta stack repose déjà sur l’interopérabilité OpenTelemetry/Prometheus mise en place récemment pour tes métriques, il vaut mieux garder le profiling dans un pipeline séparé pour l’instant : mélanger un signal alpha à une chaîne de métriques qui tourne en production, c’est prendre un risque de stabilité pour un gain qui reste expérimental.

    FAQ

    Faut-il réécrire son instrumentation existante pour profiter des profiles ?

    Non. L’agent eBPF fonctionne sans instrumentation manuelle du code, à condition que ton runtime figure dans la liste supportée. C’est justement l’intérêt du zero-code appliqué au profiling.

    Le format de profiling OpenTelemetry remplace-t-il pprof ?

    Il s’en inspire largement et vise l’interopérabilité avec l’écosystème existant, mais l’objectif est de devenir un format d’échange standard indépendant du langage, pas juste un pprof rebaptisé.

    Quand ce signal deviendra-t-il stable (GA) ?

    Aucune date n’est publiée à ce stade. Le passage d’alpha à bêta, puis à stable, suivra le même processus de spécification que les trois autres signaux — ça s’est compté en années pour les traces et métriques, pas en mois.

    Ce qu’il faut retenir

    Le quatrième signal d’OpenTelemetry tient ses promesses sur le papier : corrélation native avec les traces, format compact, zero-code sur les runtimes courants côté backend. Mais il reste un projet alpha avec un avertissement explicite contre un usage en production critique. Le bon réflexe maintenant : l’évaluer en préproduction, suivre les releases hebdomadaires du Collector Contrib, et prévoir de revisiter la question dans quelques mois plutôt que de migrer ta stack de profiling dès aujourd’hui.

  • Azure Backup : l’immuabilité enfin détachée de la durée de rétention

    Azure Backup : l’immuabilité enfin détachée de la durée de rétention

    Jusqu’ici, sur Azure Backup, l’immuabilité d’un point de restauration durait exactement aussi longtemps que la politique de rétention qui le protégeait. Tu voulais garder tes sauvegardes immuables 90 jours pour respecter une clause d’assurance cyber, mais ta politique de rétention en gardait 365 pour des raisons de conformité ? Impossible de dissocier les deux. Depuis début septembre 2026, Microsoft a changé la donne : la durée d’immuabilité d’un coffre Recovery Services peut désormais être fixée indépendamment de la rétention.

    C’est un détail qui a l’air anodin sur le papier, mais qui change concrètement la façon de dimensionner une stratégie de résilience, surtout si tu factures le stockage de sauvegarde à ton client ou à un autre service interne.

    Le problème que ça résout

    Avant ce changement, deux options existaient pour un coffre Recovery Services : pas d’immuabilité du tout, ou une immuabilité calquée sur la rétention de chaque politique de sauvegarde. Concrètement, si ta politique gardait les sauvegardes 7 ans pour des raisons légales, la totalité de ces 7 ans devenait immuable — WORM inclus si tu verrouillais le paramètre. Bien pratique pour la conformité, beaucoup moins pour la flexibilité opérationnelle : impossible de dire « je veux que ce soit inaltérable pendant 90 jours contre le ransomware, puis je gère la suite normalement ».

    Résultat : certaines équipes évitaient carrément le verrouillage d’immuabilité, ou finissaient par sur-dimensionner leurs politiques de rétention juste pour caler la fenêtre d’immuabilité qu’elles voulaient réellement.

    Ce qui change : deux modes au choix

    Le coffre propose maintenant deux façons d’activer l’immuabilité, dans Properties > Immutable vault > Settings :

    • Basée sur la politique de rétention (comportement historique, toujours disponible) : la durée d’immuabilité suit exactement la rétention configurée pour chaque élément protégé.
    • Durée fixe (nouveau) : tu indiques un nombre de jours — 30, 90, peu importe — et cette fenêtre s’applique uniformément à tous les points de restauration du coffre, indépendamment de la politique de rétention en vigueur.

    Une contrainte reste en place dans les deux cas : tu ne peux pas réduire la rétention de ta politique en dessous de la durée d’immuabilité configurée. Logique — sinon tu pourrais supprimer un point de restauration encore censé être inaltérable. Une fois la durée fixe dépassée, le point de restauration continue d’exister tant que la politique le retient, mais il n’est simplement plus protégé contre la suppression ou la modification.

    Le verrouillage (lock) reste optionnel et irréversible une fois activé — il transforme l’immuabilité en vraie protection WORM, au prix de ne plus jamais pouvoir la désactiver sur ce coffre. Il ne peut pas être posé à la création du coffre : il faut d’abord activer l’immuabilité, puis verrouiller séparément. Pour la désactiver (avant verrouillage), il faut passer par Resource Guard, ce qui empêche un compte compromis de couper la protection tout seul.

    Un point à connaître avant de te lancer

    La documentation officielle de Microsoft ne couvre pour l’instant que la configuration via le portail Azure — ni cmdlet PowerShell ni commande Azure CLI documentée pour activer la durée fixe à ce jour. Si ton IaC gère déjà tes coffres Recovery Services par Bicep ou Terraform, prévois donc une étape manuelle (ou une vérification après déploiement) tant que l’automatisation complète n’est pas exposée.

    Autre limite à garder en tête : cette fonctionnalité s’applique aux coffres Recovery Services — VM Azure, SQL, SAP HANA, etc. Les coffres Backup vault, qui protègent le blob storage et Azure Data Lake Storage, n’ont pas cette option de durée fixe pour le moment.

    Où ça se situe dans ta stratégie de résilience

    Si tu appliques déjà la règle 3-2-1-1-0 sur ton parc Azure, cette durée fixe te permet enfin de faire coller précisément la copie « immuable » de la règle à une fenêtre de temps choisie, sans devoir gonfler artificiellement ta rétention globale. C’est aussi une vraie alternative native à des solutions tierces comme Veeam Data Cloud Vault, qui appliquait déjà une immuabilité par défaut sans configuration — sauf que là, tu restes dans l’écosystème Azure Backup natif, sans facturation forfaitaire séparée ni connecteur supplémentaire à maintenir.

    Pour autant, je ne remplacerais pas un vault tiers isolé du tenant Azure si ton exigence de résilience inclut un scénario où le tenant lui-même est compromis (identité Entra ID détournée, abonnement entier chiffré). Un coffre Recovery Services reste une ressource Azure comme une autre : verrouillée, oui, mais dans le même environnement. Pour ce cas précis, un stockage réellement hors tenant garde son intérêt.

    FAQ

    La durée fixe remplace-t-elle le verrouillage d’immuabilité classique ?

    Non, ce sont deux réglages distincts. La durée fixe change combien de temps l’immuabilité s’applique ; le verrouillage décide si tu peux encore la désactiver un jour. Tu peux combiner les deux.

    Puis-je appliquer une durée différente par type de charge protégée dans le même coffre ?

    Non, la durée s’applique uniformément à tout le coffre. Si tu as besoin de fenêtres différentes selon les charges, il faut séparer les charges sur des coffres distincts.

    Que se passe-t-il pour les points de restauration déjà créés avant d’activer cette option ?

    La documentation Microsoft ne précise pas de rétroactivité automatique sur les points existants — pars du principe que le réglage s’applique aux nouveaux points de restauration créés après l’activation, et vérifie sur ton environnement avant de t’y fier pour un audit de conformité.

    Ce qu’il faut retenir

    Ce n’est pas un bouleversement, mais c’est exactement le genre de réglage fin qui manquait pour aligner Azure Backup sur des exigences d’assurance cyber ou de conformité qui, elles, ne demandent jamais une immuabilité calquée sur la rétention légale complète. Si tu as un audit de résilience ou un renouvellement d’assurance cyber dans les prochains mois, c’est le bon moment pour revoir la configuration de tes coffres Recovery Services et voir où une durée fixe te ferait gagner en flexibilité sans rien perdre en protection.

  • Trusted Launch as Default : Azure sécurise tes VMs Gen2

    Trusted Launch as Default : Azure sécurise tes VMs Gen2

    Une VM Azure Gen2 que tu déploies aujourd’hui via Terraform, sans rien préciser dans ton securityProfile, n’a plus le même comportement qu’il y a six mois. Secure Boot et vTPM s’activent tout seuls. Pas de case à cocher, pas de paramètre à ajouter — juste un changement silencieux de comportement par défaut qui peut surprendre si tu génères des images personnalisées ou si tu exploites une VM en hibernation.

    Trusted Launch as Default, disponible en production

    Trusted Launch as Default (TLaD) est passé en disponibilité générale cet été. Le principe : toute nouvelle VM ou tout nouveau scale set Gen2 que tu crées — que ce soit via le portail Azure, PowerShell, l’Azure CLI, un template ARM, Bicep ou Terraform — bascule automatiquement en Trusted Launch avec Secure Boot et vTPM activés, sans que tu aies à ajouter le moindre bloc securityProfile à ton code de déploiement.

    Concrètement, ça combine trois briques : Secure Boot, qui n’autorise que des systèmes d’exploitation et des pilotes signés à démarrer ; un vTPM conforme à la spec 2.0, qui sert de coffre-fort dédié pour tes clés et mesures d’intégrité ; et la surveillance d’intégrité du démarrage via Microsoft Defender for Cloud, qui déclenche une alerte si la chaîne de boot a été altérée. Rien de nouveau en soi — Trusted Launch existe depuis plusieurs années — mais jusqu’ici, il fallait le demander explicitement. Ce n’est plus le cas.

    Ce qui change vraiment côté déploiement

    Avant TLaD, l’absence de bloc securityProfile dans ton template créait une VM Gen2 « standard », sans Secure Boot ni vTPM. Depuis la bascule, avec une API en version 2025-11-01 ou supérieure, l’absence de ce même bloc produit désormais une VM Trusted Launch. Ton code ne change pas — c’est l’interprétation par défaut de son absence qui s’inverse. Si tu passais explicitement securityType: "Standard", rien ne bouge : ton intention reste respectée.

    La bascule automatique ne s’applique que si quatre conditions sont réunies : l’image source du Marketplace supporte Trusted Launch, une image issue d’une Azure Compute Gallery est elle aussi validée pour Trusted Launch, le disque source le supporte, et la taille de VM choisie fait partie des familles compatibles. Si une seule de ces conditions manque, le déploiement continue normalement — tu obtiens une VM Gen2 sans Trusted Launch, pas une erreur.

    Zéro surcoût, mais une vraie limite à connaître

    Premier point rassurant : Trusted Launch ne coûte rien de plus. C’est une couche de sécurité fondamentale incluse dans le prix de la VM, ce qui rend la question « faut-il le désactiver pour économiser » sans objet. Microsoft déconseille d’ailleurs explicitement de le désactiver sur de nouveaux déploiements, sauf cas précis.

    La vraie limite technique concerne le redimensionnement. Une fois une VM créée en Trusted Launch, tu ne peux plus la redimensionner vers une famille de taille qui ne le supporte pas — les séries M, notamment. Si ton scénario impose de basculer un jour vers une taille incompatible, la seule voie de sortie documentée consiste à désallouer la ressource, puis repasser explicitement securityType à Standard via l’API 2025-11-01 ou une version ultérieure, avec un outil client autre que le portail — cette opération n’est pas disponible dans l’interface graphique Azure.

    Trois cas où il faut désactiver la bascule explicitement

    Microsoft documente précisément les scénarios où contourner TLaD n’est pas optionnel :

    • tu utilises une VM Gen2 pour générer des images de type TrustedLaunchSupported, TrustedLaunchAndConfidentialVMSupported ou ConfidentialVMSupported dans une Azure Compute Gallery, via Azure Image Builder ou Packer ;
    • tu captures une image managée classique (managed image) à partir d’une VM Gen2 — cette fonctionnalité n’est tout simplement pas compatible avec Trusted Launch, Microsoft recommandant de migrer vers Azure Compute Gallery ;
    • tu exploites l’hibernation sur une VM Linux Gen2 — Trusted Launch et hibernation Linux restent mutuellement exclusifs à ce jour.

    Dans ces trois cas, le contournement passe par l’enregistrement de la fonctionnalité preview TrustedLaunchByDefaultPreview sous l’espace de noms Microsoft.Compute, désactivée pour ta souscription, ou par un securityType: "Standard" explicite VM par VM.

    Et les VM existantes ?

    Aucun changement. TLaD ne touche que les nouvelles créations — une VM ou un scale set déjà en production garde exactement le comportement pour lequel il a été déployé, TLaD ou pas. Si tu veux faire monter en sécurité un parc existant, la bascule reste manuelle : désallouer la VM, passer le type de sécurité à Trusted Launch, cocher Secure Boot et vTPM, puis redémarrer. Une VM Gen1 doit d’abord être mise à niveau vers Gen2, ce qui implique de valider au préalable le volume système invité — cette étape ne peut pas être ignorée, même en ligne de commande.

    FAQ

    TLaD s’applique-t-il à mes VM Gen1 ?

    Non, uniquement aux VM et scale sets Generation 2. Une VM Gen1 doit d’abord être migrée vers Gen2 — avec validation du volume système invité — avant de pouvoir bénéficier de Trusted Launch, par défaut ou manuellement.

    Est-ce que ça change mes scripts d’automatisation existants ?

    Si tes templates ARM ou modules Terraform utilisaient déjà l’API 2021-11-01 ou une version plus récente sans bloc securityProfile explicite, le comportement change sans que tu aies à toucher au code — c’est justement le point. Si tu veux garder le comportement pré-TLaD, ajoute securityType: "Standard" explicitement.

    Faut-il l’activer manuellement sur ma souscription ?

    Non. Le portail Azure, PowerShell et l’Azure CLI appliquent Trusted Launch par défaut sur les VM Gen2, indépendamment de tout enregistrement de fonctionnalité. L’enregistrement de TrustedLaunchByDefaultPreview ne concerne que les déploiements via SDK, Terraform ou d’autres outils tiers.

    Ce qu’il faut retenir

    Pour l’écrasante majorité des déploiements de VM Windows ou Linux standards, TLaD est une bonne nouvelle qui ne demande aucune action : la sécurité de base progresse sans effort de ta part, sans facture supplémentaire. La vigilance à avoir concerne surtout les pipelines de fabrication d’images (Packer, Azure Image Builder) et les environnements qui dépendent encore de managed images classiques plutôt que d’Azure Compute Gallery — ce sont eux qui ont le plus de chances de voir un déploiement automatisé changer de comportement sans prévenir. Si la résilience de tes VM Azure t’intéresse au-delà du boot sécurisé, notre article sur la GA de l’Ephemeral OS Disk avec Full Caching et celui sur le passage aux Azure Verified Modules complètent bien ce sujet.

  • RC4 et Kerberos : la dernière phase de bascule est passée

    RC4 et Kerberos : la dernière phase de bascule est passée

    Le 8 septembre 2026, la Zero Day Initiative a publié sa revue mensuelle des correctifs Microsoft. Pas une ligne sur Kerberos. Et pourtant, c’est le mois où la dernière phase d’un changement lancé en janvier est censée être derrière toi depuis juillet : la fin du repli automatique sur RC4 dans Active Directory. Si tu n’as pas suivi le dossier de près, il y a de bonnes chances qu’un ou deux comptes de service chez toi authentifient encore en RC4-HMAC sans que personne s’en soit rendu compte — jusqu’au jour où un client Windows patché refuse purement et simplement le ticket.

    CVE-2026-20833, ou pourquoi RC4 devait sauter

    Le sujet n’est pas nouveau. Depuis les correctifs de novembre 2022 liés à CVE-2022-37966, Windows préfère AES-SHA1 par défaut pour les comptes sans msDS-SupportedEncryptionTypes explicite. Mais « préférer » n’est pas « imposer » : tant qu’un compte ne supportait pas AES, le KDC continuait à délivrer du RC4-HMAC sans broncher. Cette tolérance est exactement ce qu’exploite le Kerberoasting — un attaquant demande un ticket de service, l’extrait, et le casse hors ligne parce que RC4 se prête bien mieux au brute-force qu’AES256.

    CVE-2026-20833 formalise ce risque résiduel et pousse Microsoft à couper le filet de sécurité : le repli implicite sur RC4 devait être désactivé par défaut sur les contrôleurs de domaine d’ici la fin du deuxième trimestre 2026. Ce n’est plus une recommandation, c’est un calendrier avec des dates de bascule fixées dans les correctifs de sécurité mensuels.

    Trois phases, et la troisième ne se rembobine pas

    Le déploiement a suivi un rythme volontairement progressif, en trois temps :

    • Janvier 2026 — mode audit. Aucune authentification ne casse. Les événements 4768/4769 se mettent à journaliser le type de chiffrement utilisé pour chaque demande de ticket, ce qui te donne enfin une visibilité réelle sur qui utilise encore RC4 dans ton annuaire.
    • Avril 2026 — application avec filet de rattrapage. Le KDC passe en mode AES-only pour tout compte dont msDS-SupportedEncryptionTypes n’est pas défini. Tu peux encore configurer explicitement RC4 sur un compte précis pour gagner du temps, le temps de migrer proprement.
    • Juillet 2026 — application définitive. Le mode audit et la possibilité de rollback disparaissent. RC4 ne fonctionne plus que si tu l’as explicitement autorisé compte par compte, ce qui reste fortement déconseillé.

    Nous sommes fin septembre : la phase 3 est derrière nous depuis deux mois. Si un service authentifie encore silencieusement en RC4 sur un compte que personne n’a remis à niveau, ce n’est plus une fenêtre de tir qui se referme — c’est déjà fermé, et la panne surviendra au prochain redémarrage de service, à la prochaine rotation de mot de passe, ou dès qu’un client durci rejoindra le domaine.

    Comment savoir si tu es exposé, concrètement

    Pas besoin de deviner. La méthode documentée par Microsoft passe par les journaux d’événements Kerberos :

    Get-ADObject -Filter "Name -eq 'nomducompte' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')" `
    -Properties "msDS-SupportedEncryptionTypes" |
    Format-List DistinguishedName, msDS-SupportedEncryptionTypes, Name, ObjectClass

    Une valeur de 28 (0x1C en hexadécimal) signifie RC4 + AES128 + AES256 encore acceptés. Tu veux arriver à 24 (0x18) — AES128 et AES256 uniquement, RC4 explicitement exclu. Si l’attribut n’est pas défini du tout, le KDC retombe sur DefaultDomainSupportedEncTypes, une clé de registre sous HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC — un cas plus délicat à traiter parce qu’il touche potentiellement tout le domaine d’un coup plutôt qu’un compte isolé.

    Pour repérer les échecs déjà en cours plutôt que d’attendre les tickets, l’outil de diagnostic le plus direct reste klist en ligne de commande :

    klist get HOST/serveur.contoso.com

    Un message 0xc00002fd avec le texte « The encryption type requested is not supported by the KDC » ne laisse aucune ambiguïté : le compte cible n’a pas les clés AES nécessaires. Le correctif le plus simple, quand c’est un compte utilisateur ou une machine plutôt qu’un compte de service historique, est souvent de simplement réinitialiser le mot de passe — ça régénère les clés AES-SHA1 manquantes sans toucher à quoi que ce soit d’autre.

    Le cas particulier de Microsoft Entra Domain Services

    Si tu exploites un domaine géré via Microsoft Entra Domain Services, la même logique s’applique côté cloud, avec une alerte dédiée : AADDS123 — Kerberos RC4 usage detected for service ticket issuance. Le principe de résolution est identique — désactiver RC4 dans les paramètres de sécurité du domaine managé, activer les audits de sécurité, surveiller les événements 4768/4769 — à un détail près : pour un compte de service synchronisé depuis un AD on-premises via Microsoft Entra Connect qui a temporairement besoin de RC4, c’est l’attribut msDS-SupportedEncryptionTypes côté AD local qu’il faut modifier, la valeur se synchronisant ensuite vers le domaine managé. L’état de santé du domaine se met à jour automatiquement sous deux heures une fois la dépendance corrigée.

    Ce qui casse en pratique (et ce qui ne prévient pas avant)

    Deux scénarios reviennent le plus souvent dans les tickets de support après une bascule AES-only mal préparée. Le partage SMB qui refuse soudain la connexion, avec une simple boîte de dialogue d’erreur réseau côté client — sans détail exploitable sans creuser côté serveur. Et la session PowerShell distante via New-PSSession, qui échoue silencieusement parce que WMI s’appuie sur le même mécanisme d’authentification. Dans les deux cas, le réflexe à avoir est le même : lancer klist pour confirmer que le problème vient bien d’un type de chiffrement non supporté, plutôt que de partir sur une fausse piste réseau ou pare-feu.

    Il y a un piège classique à éviter : penser qu’un compte utilisateur sans SPN (Service Principal Name) a besoin d’un msDS-SupportedEncryptionTypes configuré. Ce n’est pas le cas — c’est la configuration de l’appareil qui détermine le type de chiffrement pour les demandes de tickets de service et les clés de session, pas celle du compte utilisateur lui-même. Perdre du temps à modifier cet attribut sur des centaines de comptes utilisateurs alors que le vrai problème vient de trois comptes de service oubliés, ça arrive plus souvent qu’on ne le pense.

    FAQ

    RC4 est-il complètement supprimé de Windows en 2026 ?

    Non. Il reste utilisable, mais uniquement si tu le configures explicitement compte par compte (valeur 0x1C ou proche sur msDS-SupportedEncryptionTypes). Ce qui a disparu en juillet 2026, c’est le repli automatique et silencieux vers RC4 quand rien n’est configuré.

    Comment auditer sans casser la production ?

    Active les catégories d’audit « Kerberos Authentication Service » et « Kerberos Service Ticket Operations » via une stratégie de groupe, puis corrèle les événements 4768/4769 sur tes contrôleurs de domaine. C’est en lecture seule — aucun risque d’interrompre une authentification en cours.

    Et si je découvre la dépendance RC4 seulement maintenant, en septembre ?

    Tu peux temporairement réautoriser RC4 sur le compte concerné en fixant msDS-SupportedEncryptionTypes à une valeur qui l’inclut (0x1C par exemple), le temps de traiter la cause racine — généralement une application legacy ou un compte de service jamais réinitialisé depuis des années. Ce n’est pas un rollback de la politique KDC elle-même, juste une dérogation ciblée.

    Ce qu’il faut retenir

    Le plus gros risque n’est pas technique, il est organisationnel : découvrir la dépendance RC4 le jour où un applicatif métier tombe, plutôt qu’en amont via les journaux d’événements. Si tu n’as jamais lancé l’audit sur tes contrôleurs de domaine, c’est le moment de le faire — la fenêtre de tolérance, elle, est close depuis juillet. Pour le reste de ta feuille de route sécurité Windows Server, notre article sur la faille critique WSUS de 2026 et celui sur les changements de sécurité Active Directory dans Windows Server 2025 couvrent les deux autres chantiers qui méritent ta priorité ce trimestre.

  • Microsoft Artifact Registry, le nouveau dépôt par défaut de PSResourceGet

    Microsoft Artifact Registry, le nouveau dépôt par défaut de PSResourceGet

    Depuis la version 1.3.0-preview1 de PSResourceGet, une simple commande Get-PSResourceRepository affiche une colonne qui change la donne :

    Name                      Uri                                       Trusted Priority
----                      ---                                       ------- --------
MicrosoftArtifactRegistry https://mcr.microsoft.com/                True    40
PSGallery                 https://www.powershellgallery.com/api/v2  False   50

    La PowerShell Gallery, le dépôt communautaire historique que tu utilises probablement depuis des années sans y penser, n’est plus Trusted par défaut. Un nouveau dépôt, le Microsoft Artifact Registry, prend la tête avec une priorité plus haute (40 contre 50 — plus le chiffre est bas, plus PSResourceGet le consulte tôt). Ce n’est pas un détail cosmétique : c’est un changement de posture de sécurité assumé par Microsoft.

    Pourquoi la PowerShell Gallery a perdu la confiance par défaut

    La PowerShell Gallery reste ouverte à quiconque crée un compte et génère une clé API — c’est ce qui en a fait un dépôt communautaire riche au fil des ans. Mais cette ouverture a un coût : plusieurs chercheurs en sécurité ont documenté des scénarios de typosquatting (publier un module au nom presque identique à un paquet populaire pour piéger une faute de frappe) et de spoofing, où un module malveillant se fait passer pour un paquet officiel Microsoft en copiant son nom d’affichage et sa description.

    Rien de tout ça n’est propre à PowerShell — npm et PyPI ont vécu les mêmes attaques, à plus grande échelle encore. Mais pour un administrateur système qui installe des modules avec des privilèges élevés, souvent sur des serveurs de production, le risque n’a rien de théorique. Traiter la Gallery comme non fiable par défaut est une position raisonnable, même si elle demande un temps d’adaptation : tu devras explicitement faire confiance à un dépôt (Set-PSResourceRepository -Name PSGallery -Trusted) ou valider chaque installation communautaire au cas par cas.

    Le Microsoft Artifact Registry, concrètement

    Le MAR n’est pas un nouveau service pensé pour PowerShell : c’est le registre où Microsoft publie déjà ses images de conteneurs officielles. PSResourceGet s’appuie sur cette infrastructure existante depuis la version 1.1.0 du module, et devient dépôt par défaut à partir de la 1.3.0-preview1, aux côtés de PSGallery. Aucune authentification n’est nécessaire pour chercher, télécharger ou installer un paquet — seule la publication est verrouillée côté Microsoft, ce qui élimine mécaniquement le risque de typosquatting sur les modules officiels.

    L’enregistrer prend une seule ligne :

    # Enregistre MAR avec les réglages par défaut (Trusted, priorité 40)
Register-PSResourceRepository -MicrosoftArtifactRegistry

# Vérifie ce qui est enregistré
Get-PSResourceRepository

# Recherche et installation, sans rien changer d'autre
Find-PSResource -Repository MicrosoftArtifactRegistry -Name Az.Accounts
Install-PSResource -Name Az.Accounts -Repository MicrosoftArtifactRegistry

    Si tu es encore sur PowerShell 5.1, ou sur une version de PowerShell 7 antérieure à 7.5.0, il faut d’abord installer PSResourceGet manuellement — le module n’est pas mis à jour automatiquement avec l’exécutable :

    Install-Module -Name Microsoft.PowerShell.PSResourceGet -Repository PSGallery

    Le cas Az : plus rapide, mais pas encore sans accroc

    Le module Az est le premier gros bénéficiaire concret de ce changement : l’installer depuis le MAR plutôt que depuis PSGallery accélère nettement le téléchargement, sans passer par le processus de publication communautaire classique. La commande recommandée par Microsoft :

    Register-PSResourceRepository -Name MAR -Uri https://mcr.microsoft.com -ApiVersion ContainerRegistry
Install-PSResource -Name Az -Repository MAR

    Il y a un vrai bug à connaître avant de foncer en production : certains sous-modules, comme Az.KeyVault, échouent à l’installation depuis le MAR avec l’erreur Install-PSResource: Package(s) 'Az.Keyvault' could not be installed from repository 'MAR'. Le correctif est suivi sur le dépôt GitHub de PSResourceGet, mais en attendant, le contournement documenté par Microsoft reste d’installer ce module précis depuis PSGallery. Ce n’est pas gênant tant que tu sais que ce cas existe — ça devient un mauvais moment si tu le découvres au milieu d’un déploiement.

    Ce que ça change pour tes scripts et tes pipelines

    Si tu gères tes serveurs avec des modules exclusivement Microsoft (Az, Microsoft.Graph, ExchangeOnlineManagement dans ses versions récentes), la bascule est presque transparente : enregistre le MAR, laisse PSGallery en untrusted, et tes installations continuent de fonctionner sans invite de confirmation. C’est la configuration que je recommande par défaut sur un serveur de production.

    La situation se complique si tu dépends de modules communautaires bien installés — ImportExcel, PSFramework, ou des modules DSC tiers n’ont aucune raison d’apparaître un jour sur le MAR, qui reste réservé aux publications officielles Microsoft. Dans ce cas, remettre PSGallery en Trusted globalement annule une bonne partie de l’intérêt du changement. Une approche plus fine consiste à garder PSGallery non fiable, et à n’accorder la confiance ponctuellement à l’installation (Install-PSResource -Name ImportExcel -TrustRepository) pour les modules que tu as toi-même audités, plutôt que de rouvrir la porte à l’ensemble du dépôt communautaire.

    FAQ

    Dois-je désinstaller PSGallery ?

    Non, et ce n’est même pas recommandé : de nombreux modules n’existent que là. Le changement porte sur le niveau de confiance par défaut, pas sur la disponibilité du dépôt.

    Le MAR remplace-t-il PSGallery à terme ?

    Non, ce n’est pas l’objectif annoncé. Le MAR couvre les modules officiels Microsoft ; PSGallery reste la référence pour l’écosystème communautaire, qui représente la grande majorité des modules publiés.

    Est-ce que ça concerne aussi PowerShellGet v2 (Install-Module) ?

    Non, cette évolution est propre à PSResourceGet. Si tu es toujours sur PowerShellGet v2, c’est une raison supplémentaire de migrer.

    Faut-il une version précise de PSResourceGet ?

    Le support du MAR existe depuis la 1.1.0, mais il ne devient dépôt par défaut qu’à partir de la 1.3.0-preview1. Vérifie ta version avec Get-Module Microsoft.PowerShell.PSResourceGet -ListAvailable avant de t’étonner qu’il manque à ta liste de dépôts.

    Passe à l’action

    Lance Get-PSResourceRepository sur un de tes serveurs cette semaine, et regarde ce qui en sort. Si PSGallery apparaît encore Trusted sans que tu l’aies décidé consciemment, c’est le bon moment pour revoir cette configuration module par module plutôt que de la laisser filer.

    Pour creuser le sujet, la documentation officielle Microsoft détaille le support du Microsoft Artifact Registry dans PSResourceGet ainsi que les dépôts pris en charge, et BleepingComputer revient sur les failles de spoofing identifiées sur la PowerShell Gallery. On avait détaillé la migration vers PSResourceGet dans cet article, et la feuille de route 2026 de l’équipe PowerShell dans celui-ci.

  • GitHub Actions cache-mode : la fin du cache poisoning silencieux

    GitHub Actions cache-mode : la fin du cache poisoning silencieux

    Le 26 juin 2026, GitHub a changé silencieusement le comportement du cache de tous les workflows déclenchés par un événement pull_request_target ou une cascade workflow_run venant d’un fork : ces jobs ne pouvaient plus écrire dans le cache, seulement le lire. Un correctif discret, mais un vrai correctif de sécurité — il bloque un scénario d’attaque documenté depuis des années : un contributeur externe pousse une pull request qui empoisonne le cache, et ton workflow push de confiance restaure ensuite cette entrée corrompue en pensant récupérer ses propres artefacts de build.

    Depuis le 10 septembre 2026, cette protection binaire (lecture seule ou rien) devient un vrai réglage. cache-mode passe en disponibilité générale sur tous les plans github.com. Voici ce que ça change pour tes pipelines, et comment configurer le bon niveau d’accès sans casser tes builds.

    Le problème du cache poisoning, en clair

    Le cache GitHub Actions n’a jamais été pensé comme un espace de stockage fiable à 100 %. N’importe quel job avec un accès en écriture peut y déposer une entrée sous une clé qu’un autre job réutilisera plus tard — c’est justement tout l’intérêt du cache : accélérer les builds en réutilisant des node_modules, des dépendances Maven ou des couches Docker déjà téléchargées.

    Le souci apparaît quand deux workflows différents partagent la même clé de cache sans partager le même niveau de confiance. Un pull_request_target tourne avec les secrets et permissions du dépôt de base, même quand il traite une PR venant d’un fork inconnu — c’est justement pour ça que ce trigger existe. Si ce job a le droit d’écrire dans le cache, un attaquant n’a besoin que d’une PR pour y glisser une dépendance modifiée. Ton workflow push suivant restaure cette entrée en toute confiance, et exécute le code injecté avec des privilèges bien supérieurs à ceux d’un simple contributeur externe.

    Ce qui a changé le 26 juin, et ce qui change le 10 septembre

    Première étape, en juin : GitHub a imposé des jetons en lecture seule pour les événements « non fiables » — pull_request_target, issue_comment, et les cascades workflow_run initiées depuis un fork, dès que le contexte pointe vers le SHA de la branche par défaut. Les événements considérés comme fiables (push, schedule, workflow_dispatch, repository_dispatch, delete, registry_package, page_build) gardaient l’accès complet. Une tentative d’écriture sur un job restreint ne fait pas échouer le job : elle génère juste un avertissement, et l’écriture est ignorée.

    Cette bascule automatique protégeait déjà l’essentiel des cas. Mais elle ne laissait aucune marge de manœuvre. Impossible, par exemple, d’autoriser un job planifié à écrire dans le cache sans le lire (pour préchauffer un cache que d’autres jobs consommeront ensuite), ou de couper complètement l’accès cache d’un job qui n’en a pas besoin. cache-mode, en GA depuis le 10 septembre, comble ce vide avec quatre valeurs :

    • read — restaure les entrées existantes, ne peut rien sauvegarder. C’est le défaut appliqué automatiquement aux événements non fiables depuis juin.
    • write — lecture et écriture, le comportement classique. Défaut pour les événements fiables comme push.
    • write-only — sauvegarde sans jamais restaurer, utile pour un job dont le seul rôle est de préchauffer le cache pour les autres.
    • none — aucun accès au cache, ni en lecture ni en écriture.

    Configurer cache-mode, au niveau workflow ou par job

    Le champ se place soit en tête de fichier (avant jobs), soit directement dans la définition d’un job (après runs-on) :

    name: Build et tests
on: [push, pull_request_target]

# Défaut pour tous les jobs du workflow
cache-mode: read

jobs:
  build:
    runs-on: ubuntu-latest
    # Ce job override le défaut du workflow
    cache-mode: write
    steps:
      - uses: actions/checkout@v6
      - uses: actions/cache@v4
        with:
          path: ~/.npm
          key: npm-${{ hashFiles('package-lock.json') }}

    La hiérarchie est simple à retenir : un réglage au niveau job écrase celui du workflow, et un workflow appelé (via workflow_call) ne peut jamais obtenir plus d’accès que celui accordé par l’appelant. Impossible donc pour un workflow réutilisable de s’octroyer discrètement un accès en écriture que le caller lui refuse.

    La stratégie à adopter, sans y passer trois heures

    Pas besoin de réécrire tous tes workflows dès aujourd’hui — les défauts de juin couvrent déjà le risque principal. Mais si tu veux verrouiller les choses proprement, la règle est simple : n’accorde jamais plus que ce dont un job a besoin, et pose-toi la question à chaque job qui touche à un pull_request_target.

    Un job de build classique sur push reste en write, sans y toucher. Pour un job qui tourne sur pull_request_target mais qui n’a même pas besoin de lire le cache (un simple linter, par exemple), passe-le carrément en none — ça évite qu’il consomme des jetons de cache pour rien. Et si tu as un job planifié dédié à préchauffer le cache pour la nuit suivante, write-only est fait pour ce cas précis : il alimente le cache sans jamais avoir besoin de le lire lui-même.

    Ce que je déconseille clairement : laisser write par défaut sur un workflow entier qui mélange des jobs push et des jobs déclenchés par PR externe, en comptant sur les défauts automatiques pour rattraper le coup à ta place. Ces défauts existent, mais un réglage explicite au niveau job documente ton intention — et survit à un futur changement de trigger que tu pourrais oublier de revérifier.

    FAQ

    Est-ce que cache-mode casse mes workflows existants ?

    Non. Sans le champ, chaque job garde le comportement par défaut déjà en place depuis juin : lecture seule sur événements non fiables, lecture-écriture ailleurs. cache-mode est une option à ajouter volontairement, pas un changement de comportement forcé.

    Ça marche aussi sur GitHub Enterprise Server ?

    L’annonce du 10 septembre couvre github.com sur tous les plans. Si tu es sur GHES, vérifie la version de ta plateforme avant de t’appuyer sur ce champ — les fonctionnalités Actions arrivent en général avec un décalage sur les versions on-premise.

    Une tentative d’écriture refusée fait-elle échouer le job ?

    Non. Elle génère un avertissement dans les logs et l’écriture est silencieusement ignorée. Les restaurations en lecture, elles, ne sont jamais affectées par une restriction d’écriture.

    Faut-il aussi revoir mes clés de cache existantes ?

    Pas forcément, mais c’est le bon moment pour vérifier qu’elles n’incluent pas d’éléments contrôlables par un attaquant externe (nom de branche, titre de PR) sans validation préalable. cache-mode réduit le risque d’écriture non autorisée ; il ne remplace pas une clé de cache mal construite.

    Passe à l’action

    Si tes pipelines mélangent des jobs push et des jobs déclenchés par des PR externes — dépôt open source, contributions communautaires — c’est le moment de faire l’inventaire : quels jobs ont vraiment besoin d’écrire dans le cache, et lesquels peuvent basculer en read ou none. Une demi-heure de relecture de tes fichiers YAML vaut mieux qu’un cache empoisonné découvert en production.

    Pour aller plus loin, la documentation officielle GitHub détaille la syntaxe complète des workflows, et le changelog GitHub revient sur le passage en GA de cache-mode ainsi que sur la restriction en lecture seule de juin. Si le sujet de la chaîne d’approvisionnement CI/CD t’intéresse, on avait détaillé les défenses anti-supply-chain côté GitHub Actions et npm dans un article précédent, et les leçons des attaques de mars dans celui-ci.

  • Cisco CVSS 10, Citrix, Fortinet : les 3 failles ajoutées au catalogue CISA KEV mi-septembre 2026

    Cisco CVSS 10, Citrix, Fortinet : les 3 failles ajoutées au catalogue CISA KEV mi-septembre 2026

    Trois éditeurs, trois pare-feux ou passerelles d’accès, une seule urgence commune : la CISA a ajouté début septembre 2026 des vulnérabilités Cisco, Citrix et Fortinet à son catalogue Known Exploited Vulnerabilities (KEV), avec un délai de correction fixé au 12 septembre 2026 pour les agences fédérales américaines. Ce délai ne s’applique pas à toi si tu n’es pas une agence fédérale US — mais l’exploitation active, elle, ne fait pas de distinction de juridiction.

    La plus critique des trois n’a même pas besoin qu’on discute de son score : CVSS 10.0, le maximum de l’échelle. Détail de ce qu’il faut corriger, et dans quel ordre.

    CVE-2026-20079 : Cisco Secure FMC, root sans authentification

    La faille touche Cisco Secure Firewall Management Center (toutes versions antérieures aux correctifs listés ci-dessous) ainsi que la gestion de pare-feu via Security Cloud Control (SCC). Elle ne concerne pas Firewall Device Manager, ASA, FTD ni SCC Defense Orchestrator — si tu gères tes pare-feux Cisco uniquement via FDM, tu n’es pas dans le périmètre de cette CVE précise (mais garde un œil sur les autres).

    Le problème : un attaquant non authentifié peut contourner l’authentification de l’interface web et exécuter des scripts avec des privilèges root. Pas de contournement de configuration possible — l’avis officiel Cisco est catégorique : aucun workaround, seule la mise à jour logicielle corrige le problème. La vulnérabilité était en fait publiée depuis le 4 mars 2026, mais son exploitation active n’a été confirmée qu’en août, avec trois clusters de post-compromission identifiés déployant web shells et malwares.

    Version installée Corrigée à partir de
    7.0 et antérieures 7.0.10
    7.2 7.2.12
    7.4 7.4.8
    7.6 7.6.6
    7.7 7.7.13
    10.0 10.0.2
    10.1 10.1.0

    Si ton FMC n’a pas reçu de mise à jour depuis mars, ce n’est plus une tâche de maintenance planifiable au prochain sprint. C’est un patch d’urgence, au même titre que ce qu’on décrivait pour la faille GitLab CVSS 10 de septembre — même score, même logique : root ou accès administrateur sans mot de passe valide, ça ne se traite pas en fin de semaine.

    CVE-2026-19490 : Citrix NetScaler, l’autre porte d’entrée

    Deuxième dossier, chez Citrix cette fois : CVE-2026-19490 (score CVSS 9.3, contournement d’authentification) et sa voisine CVE-2026-19489 (score 8.8, dépassement de mémoire tampon) touchent NetScaler ADC et NetScaler Gateway configurés en serveur AAA ou Gateway, y compris les déploiements Secure Private Access Hybrid qui s’appuient sur des instances NetScaler.

    Versions concernées et correctifs, d’après le bulletin de sécurité officiel Citrix (publié le 19 août 2026) :

    • NetScaler ADC/Gateway 14.1 antérieur à 14.1-73.32 → corrigé en 14.1-73.32
    • NetScaler ADC/Gateway 13.1 antérieur à 13.1-63.21 → corrigé en 13.1-63.21
    • Variantes FIPS 14.1 antérieures à 14.1-73.32 FIPS → corrigées en 14.1-73.32 FIPS
    • Variantes FIPS/NDcPP 13.1 antérieures à 13.1-37.277 → corrigées en 13.1-37.277

    La CISA a recensé 56 tentatives d’exploitation via honeypot depuis le 3 septembre, dont 36 en une seule journée le 8 septembre — la courbe monte, elle ne redescend pas. Si ton NetScaler expose une interface de gestion ou un portail Gateway côté internet sans être à jour, ce n’est plus une question de « si » mais de « quand ».

    CVE-2025-25249 : la doyenne, mais toujours active

    La troisième CVE de la liste, CVE-2025-25249 (CVSS 7.3, dépassement de tampon basé sur le tas), touche FortiOS, FortiSwitchManager et FortiSASE, avec un risque d’exécution de code à distance. Contrairement aux deux précédentes, cette faille est plus ancienne — mais elle reste activement exploitée depuis juillet 2026 pour déployer le malware PivotC2, avec plus de 3 000 adresses IP visées et 178 appareils confirmés infectés. Les acteurs identifiés sont majoritairement russophones.

    Score plus bas que les deux autres, certes, mais ne t’y trompe pas : une backdoor persistante sur un pare-feu périmétrique vaut largement le déplacement, même à CVSS 7.3.

    Ce que ça dit de la tendance 2026

    Trois vulnérabilités, trois éditeurs différents, tous dans la même famille de produits : des équipements de sécurité périmétrique — pare-feu, passerelle d’accès distant, gestion de firewall. Le motif se répète depuis le début de l’année : les attaquants ciblent en priorité les briques censées protéger le réseau, précisément parce qu’elles sont exposées sur internet et détiennent des privilèges élevés une fois compromises. Un contournement d’authentification sur un firewall manager, c’est directement les clés du réseau — pas une simple fuite d’information à corriger « quand on aura le temps ».

    Si ton organisation applique déjà une cadence de patch mensuelle façon Patch Tuesday, ces trois CVE ne rentrent pas dans ce cycle : une exploitation active confirmée par la CISA justifie un correctif hors cycle, dans les jours qui suivent l’alerte, pas au prochain calendrier de maintenance.

    FAQ

    Comment savoir si mon FMC ou mon NetScaler a déjà été compromis ?

    Cisco et Citrix publient tous les deux des indicateurs de compromission dans leurs avis respectifs (logs d’authentification anormaux, fichiers webshell déposés, comptes créés hors process). Vérifie en priorité les connexions administratives depuis des IP inhabituelles sur les fenêtres correspondant aux dates d’exploitation active mentionnées (août 2026 pour Cisco, début septembre pour Citrix).

    Le patch seul suffit-il, ou faut-il aussi vérifier une compromission préalable ?

    Le patch corrige la vulnérabilité, pas une éventuelle compromission déjà en place. Si ton équipement était exposé et non patché avant l’alerte, une vérification de compromission (logs, intégrité des fichiers, comptes administrateurs) est indispensable avant de considérer l’incident clos.

    Ces CVE concernent-elles aussi les petites structures, ou seulement les grandes entreprises ?

    L’exploitation observée par la CISA (honeypots, campagnes à large échelle façon PivotC2) cible des IP exposées sans distinction de taille d’organisation. Un NetScaler ou un FMC non patché reste une cible, quel que soit l’effectif derrière.

    Faut-il redémarrer les équipements après le correctif ?

    Ça dépend de la version et du mode de mise à jour (mise à jour à chaud vs. remplacement d’image) — suis strictement la procédure indiquée dans l’avis de sécurité de l’éditeur concerné plutôt qu’une procédure générique, les impacts de service diffèrent d’un produit à l’autre.

    Dans les trois cas, la marche à suivre est la même : vérifie ta version installée, compare-la à la table des correctifs, et planifie la mise à jour hors cycle si tu es exposé. Un firewall ou une passerelle qui protège ton réseau ne doit jamais être, lui-même, le point d’entrée le plus simple.

  • Copilot Code Review pour Azure Repos : la revue de PR passe en preview publique

    Copilot Code Review pour Azure Repos : la revue de PR passe en preview publique

    Depuis le 26 août 2026, il n’y a plus besoin de s’inscrire sur une liste d’attente pour faire relire ses pull requests par une IA sur Azure Repos. GitHub Copilot Code Review est passé en preview publique, ouvert à tous les organisations Azure DevOps sans demande d’accès préalable. Concrètement : Copilot rejoint la liste des reviewers de ta pull request, lit le diff, et pose des commentaires ligne par ligne — exactement comme le ferait un collègue, sauf qu’il ne dort jamais et ne prend pas de café avant 9h.

    Ce n’est pas un gadget marketing greffé sur Azure Boards. C’est une brique qui s’active en quelques clics, se facture au token, et s’intègre directement dans tes policies de branche existantes. Voici ce qu’il faut savoir avant de l’activer sur un vrai projet.

    Ce que fait réellement Copilot Code Review

    Une fois activé, GitHub Copilot apparaît comme reviewer disponible sur chaque pull request d’un dépôt Git (les dépôts TFVC ne sont pas supportés — encore une raison de migrer si tu es encore dessus). Tu peux le solliciter manuellement à la demande, ou laisser une policy de branche le déclencher automatiquement à chaque nouvelle PR.

    Il pose ses commentaires directement sur les lignes concernées, et ces commentaires se comportent comme ceux d’un humain : tu peux y répondre, les résoudre, les masquer, réagir avec un emoji. Ce qu’il ne fait jamais en revanche, c’est bloquer une fusion ou approuver formellement une PR — sa review reste toujours au statut « Commentaire ». Et il ne relit pas automatiquement après un nouveau commit : si tu pousses un correctif, il faut redemander une review à la main. Pas de veille passive façon humain qui laisse traîner un onglet ouvert.

    Trois niveaux d’effort, trois facturations différentes

    Tu choisis entre Low, Medium et High au moment de la demande de review (ou tu fixes un niveau par défaut au niveau du projet ou du repo). Plus l’effort est élevé, plus Copilot consomme de tokens — et plus la facture grimpe. Pas de mystère marketing ici : Microsoft facture en GitHub AI credits, à 0,01 $ le crédit, calculés sur les tokens d’entrée, de sortie et les tokens mis en cache. La taille de la PR, tes instructions personnalisées et les mises à jour de modèle jouent aussi sur la note finale.

    Pour une équipe qui traite des dizaines de PR par jour, le choix du niveau d’effort par défaut n’est pas un détail cosmétique — c’est une ligne de budget. Autant commencer en Low sur les repos à fort volume et réserver High aux PR touchant du code sensible (auth, paiement, infra), plutôt que de l’activer partout en mode maximal dès le premier jour.

    Activer la fonctionnalité : organisation, projet, ou dépôt

    L’activation se fait à trois niveaux, du plus large au plus ciblé :

    • Organisation : Organization settings → Repos → Repositories, bascule « Allow repositories in this organization to use Copilot code review ». L’option « Enable all » active la fonctionnalité pour tous les projets et dépôts d’un coup.
    • Projet : Project settings → Repos → Repositories, bascule équivalente qui s’applique à tous les dépôts du projet, sauf override au niveau dépôt. Cette étape est facultative si l’organisation a déjà tout activé.
    • Dépôt : même chemin, sélectionne le repo concerné, onglet Settings, bascule « Enable Copilot code review for pull requests in this repository ». Une fois actif, GitHub Copilot doit apparaître dans la liste des reviewers disponibles sur une PR.

    Pour l’exécution des reviews, tu peux garder le pool Azure Pipelines hébergé par défaut, ou pointer vers un Managed DevOps Pool que tu contrôles déjà — utile si tu veux garder la main sur l’image et le dimensionnement des agents. Une contrainte à connaître avant de t’y engager : seules les images Ubuntu Server récentes sont supportées, les images Windows sont exclues, et il ne faut pas mélanger agents Ubuntu et Windows dans le même pool. Les pools self-hosted classiques, eux, ne sont pas éligibles du tout.

    Les limites concrètes à connaître avant de généraliser

    Avant de brancher ça sur ton repo monolithique de 8 Go avec des PR de 300 fichiers, quelques plafonds à vérifier :

    • Taille du dépôt : 10 Go maximum
    • Fichiers modifiés par PR : 100 maximum
    • Changements totaux : 100 maximum
    • Reviews simultanées par organisation : 5
    • Reviews simultanées par utilisateur : 2
    • Une seule review complétée par commit de fusion

    Autre point qui a son importance dans un vrai workflow : les pull requests en brouillon ne sont pas prises en charge. La PR doit être active, sans conflit de fusion, pour que Copilot accepte de la relire. Si ton équipe a l’habitude de solliciter des retours dès le brouillon, il faudra soit changer cette habitude, soit accepter que Copilot n’intervienne qu’une fois la PR passée en revue « officielle ».

    Suivre la facture sans surprise

    Les coûts remontent dans Azure Cost Management avec un délai de 48 heures après la fin d’une review — pas en temps réel, donc pas de tableau de bord pour surveiller la dépense minute par minute. Filtre sur la catégorie de compteur GitHub et la sous-catégorie GitHub Copilot for AzDO, puis regroupe par tag Organization ou Project pour savoir quelle équipe consomme quoi. Si plusieurs équipes se partagent le même abonnement Azure, configurer une alerte de budget (seuils à 75 % et 90 % par exemple, sur le produit « GitHub Copilot for AzDO ») évite la mauvaise surprise en fin de mois — un réflexe qui rejoint ce qu’on évoquait récemment sur le pilotage FinOps des charges liées à l’IA.

    Faut-il l’activer dès maintenant ?

    Pour une équipe qui fait déjà de la revue de code sérieuse (branch policies, reviewers obligatoires, checks CI bloquants), oui — activer Copilot en complément d’une review humaine, pas à sa place, a du sens dès la preview publique : le risque est faible (il ne peut jamais fusionner ni bloquer), le coût est maîtrisable en Low, et le gain (attraper les fautes d’attention avant l’œil humain) est réel. Pour une petite équipe sans process de review formalisé, en revanche, poser d’abord des branch policies et des reviewers humains obligatoires rapporte plus, tout de suite, que d’ajouter un reviewer IA à un processus qui n’existe pas encore.

    FAQ

    Copilot Code Review peut-il bloquer une fusion ?

    Non. Sa review reste toujours au statut « Commentaire », jamais « Approuvé » ni « Rejeté ». Il ne peut donc pas empêcher une fusion à lui seul — il faut une policy de branche distincte pour ça.

    Ça fonctionne sur des dépôts TFVC ?

    Non, uniquement sur des dépôts Git. Si ton équipe est encore sur TFVC, c’est une raison de plus d’envisager la migration.

    Faut-il une licence GitHub Copilot séparée ?

    La fonctionnalité est disponible en preview publique pour tous les clients Azure DevOps, sans inscription préalable, mais la consommation se facture en crédits IA GitHub via ton abonnement Azure — vérifie la documentation officielle Microsoft Learn pour le détail exact de la facturation selon ton contrat.

    Peut-on désactiver la fonctionnalité si les retours ne conviennent pas ?

    Oui, à trois niveaux : pour un utilisateur (désactiver les « Preview features » dans ses réglages personnels), pour un dépôt (bascule au niveau repo), ou pour toute l’organisation (bascule au niveau organisation, qui coupe la fonctionnalité pour tous les projets).

    Si tu gères plusieurs projets Azure DevOps, le plus simple reste de tester d’abord sur un seul dépôt à faible enjeu, de calibrer le niveau d’effort par défaut sur quelques semaines de PR réelles, puis de généraliser une fois que le rapport signal/bruit des commentaires de Copilot te convient. Et surtout : configure l’alerte de budget avant, pas après avoir découvert la facture.

  • Types définis en Bicep : la fonctionnalité qui muscle tes modules IaC

    Types définis en Bicep : la fonctionnalité qui muscle tes modules IaC

    Un paramètre Bicep mal orthographié ne plante pas toujours ton déploiement. Écris otionalProperty au lieu de optionalProperty dans un objet de configuration, et par défaut, Bicep se contente d’un avertissement BCP089 — le déploiement continue, la propriété correcte reste vide, et tu découvres le problème en production plutôt qu’en revue de code. C’est exactement le genre de bug que les types définis par l’utilisateur, disponibles depuis la CLI Bicep 0.12, permettent d’éliminer, à condition de connaître les bons décorateurs.

    Le problème que @allowed et les commentaires ne résolvent qu’à moitié

    La façon classique de contraindre un paramètre Bicep, c’est le décorateur @allowed directement sur le paramètre :

    @allowed([
  'Standard_LRS'
  'Standard_GRS'
])
param storageAccountSKU string = 'Standard_LRS'

    Ça fonctionne pour un paramètre isolé. Mais dès que tu veux réutiliser cette contrainte dans plusieurs modules — le SKU d’un compte de stockage revient dans presque tous les modules d’une landing zone —, tu recopies le même bloc @allowed partout, avec le risque qu’une équipe l’oublie ou le fasse dériver légèrement d’un module à l’autre. Les types définis par l’utilisateur déplacent cette contrainte dans un type nommé, réutilisable et exportable.

    Déclarer un type et le rendre solide

    La syntaxe de base est courte, comme le montre la documentation officielle des types définis par l’utilisateur :

    type storageAccountSkuType = 'Standard_LRS' | 'Standard_GRS'

type storageAccountConfigType = {
  name: string
  sku: storageAccountSkuType
}

param storageAccountConfig storageAccountConfigType

    Ce qui rend ces types utiles en pratique, ce sont les décorateurs qu’on peut leur attacher. Ils vivent dans le namespace sys, donc en cas de conflit de nom tu peux toujours forcer sys.description() :

    • @minLength() / @maxLength() — bornes inclusives sur des chaînes ou des tableaux.
    • @minValue() / @maxValue() — bornes inclusives sur des entiers.
    • @secure() — masque la valeur dans l’historique de déploiement, applicable aux chaînes comme aux objets entiers.
    • @description() — accepte du Markdown, utile pour la documentation générée automatiquement.
    • @sealed() — transforme un avertissement de propriété inconnue en erreur bloquante. C’est le plus rentable des cinq, et il mérite sa propre section.

    @sealed() : le décorateur qui aurait évité le bug d’introduction

    Reprenons l’exemple du typo. Sans @sealed() :

    type anObject = {
  property: string
  optionalProperty: string?
}

param aParameter anObject = {
  property: 'value'
  otionalProperty: 'value'  // typo : simple avertissement BCP089, le déploiement continue
}

    Avec @sealed() sur le type, ou directement sur le paramètre, la même faute de frappe devient une erreur de compilation, pas un warning noyé dans la sortie de az deployment :

    @sealed()
type anObject = {
  property: string
  optionalProperty: string?
}

    Sur un module partagé entre plusieurs équipes, ce n’est pas du perfectionnisme : c’est la différence entre un déploiement qui échoue tout de suite en pipeline et une ressource mal configurée qui passe une revue de code sans que personne ne le remarque. Il n’y a pas vraiment de cas où @sealed() coûte plus qu’il ne rapporte sur un type destiné à être réutilisé — mets-le par défaut, et retire-le seulement si un module a explicitement besoin de propriétés libres.

    Unions discriminées : un seul paramètre, plusieurs formes possibles

    Depuis la CLI 0.21, @discriminator() permet de typer un paramètre qui peut prendre plusieurs formes selon une propriété pivot. Pratique pour des modules qui exposent plusieurs modes de configuration sous un seul nom de paramètre :

    type FooConfig = {
  type: 'foo'
  value: int
}

type BarConfig = {
  type: 'bar'
  value: bool
}

@discriminator('type')
type ServiceConfig = FooConfig | BarConfig

param serviceConfig ServiceConfig = { type: 'bar', value: true }

    Bicep sait alors que si type vaut 'bar', value doit être un booléen, et le signale à la compilation si tu passes un entier par erreur, plutôt qu’à l’exécution côté Azure Resource Manager.

    Types dérivés de ressources : la nouveauté qui évite de deviner le schéma

    Fonctionnalité plus récente, CLI 0.34.1 minimum, les types dérivés de ressources extraient directement le schéma d’un type de ressource Azure, sans que tu aies à le recopier à la main :

    param storageAccountProps resourceInput<'Microsoft.Storage/storageAccounts@2023-01-01'>.properties = {
  accessTier: 'Hot'
  minimumTlsVersion: 'TLS1_2'
  allowBlobPublicAccess: false
  supportsHttpsTrafficOnly: true
}

resource storageAccount 'Microsoft.Storage/storageAccounts@2025-06-01' = {
  name: 'mystorageacct123'
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: storageAccountProps
}

    resourceInput<...> expose les propriétés éditables, hors champs en lecture seule ; resourceOutput<...> fait l’inverse pour typer une sortie. Une nuance à garder en tête : cette vérification est faite à l’édition et à la compilation, pas imposée par le service ARM au moment du déploiement. Un @sealed() explicite reste donc le seul mécanisme qui bloque réellement un déploiement non conforme côté Azure.

    Exporter des types pour arrêter de les redéfinir dans chaque module

    Une fois qu’un type est stabilisé, @export() le rend disponible à l’import depuis d’autres fichiers Bicep :

    @export()
type storageAccountSkuType = 'Standard_LRS' | 'Standard_GRS'

@export()
type storageAccountConfigType = {
  name: string
  sku: storageAccountSkuType
}

    Si ton équipe a déjà investi dans les Azure Verified Modules pour standardiser ses landing zones, exporter les types utilisés par ces modules dans un fichier partagé règle exactement le problème que l’AVM tente de résoudre de son côté : deux équipes qui redéfinissent le même objet de configuration avec des contraintes légèrement différentes, jusqu’à ce qu’un déploiement échoue pour une raison que personne ne retrouve rapidement.

    FAQ

    Faut-il une version particulière de Bicep CLI pour utiliser tout ça ?

    Les types de base fonctionnent dès la CLI 0.12.X. Les unions discriminées (@discriminator()) demandent la 0.21.X, et les types dérivés de ressources (resourceInput/resourceOutput) la 0.34.1 au minimum — vérifie ta version avec az bicep version avant de t’appuyer dessus dans un pipeline partagé.

    Un type récursif est-il possible en Bicep ?

    Oui, mais seulement si au moins un chemin vers l’appel récursif est optionnel. Un type où chaque niveau imbriqué référence obligatoirement le suivant, sans jamais de propriété optionnelle, ne compile pas.

    Terraform a-t-il un équivalent direct ?

    Pas vraiment sous cette forme : Terraform valide surtout via des blocs variable avec validation, sans système de types nommés et exportables aussi proche de TypeScript. Si le choix entre les deux outils se pose encore chez toi, on avait détaillé les critères dans notre comparatif Terraform vs Bicep.

    Rien de tout ça ne demande de réécrire tes modules existants d’un coup. Commence par sceller (@sealed()) les objets de configuration les plus copiés-collés dans ton dépôt, et exporte-les au fur et à mesure que tu les stabilises. C’est le genre de changement qui ne se voit dans aucune démo, mais qui t’évite un ticket de support un vendredi soir.

  • Passkeys par défaut dans Entra ID : ce qui change dès maintenant

    Passkeys par défaut dans Entra ID : ce qui change dès maintenant

    Le 1er septembre 2026, sans qu’aucun administrateur Entra ID n’ait eu à cliquer sur quoi que ce soit, Microsoft a commencé à basculer automatiquement les utilisateurs inscrits en SMS ou en appel vocal vers l’enregistrement d’une passkey. Pas une annonce vague sur une roadmap lointaine : une bascule qui tourne déjà, avec une date de coupure ferme cinq mois plus tard.

    Le 1er février 2027, Microsoft retire purement et simplement la livraison SMS/voix qu’elle opère elle-même, pour la quasi-totalité des comptes. Passé cette date, un utilisateur qui n’a que le SMS comme second facteur ne pourra plus se connecter tant qu’il n’aura pas enregistré une passkey — sans option pour repousser indéfiniment. Si ton tenant a encore des comptes qui dépendent du SMS ou de la voix, voici le calendrier exact, la commande pour savoir qui est concerné, et la checklist pour basculer avant que ce soit Microsoft qui décide à ta place.

    Le calendrier complet, sans arrondi

    Trois dates comptent vraiment, et elles ne concernent pas tout le monde de la même façon :

    • 1er septembre 2026 : activation automatique des profils de passkeys pour les utilisateurs qui utilisent déjà le SMS ou la voix, avec une campagne d’enregistrement (« nudge ») déclenchée à la prochaine authentification multifacteur.
    • 1er février 2027 : retrait du SMS/voix géré par Microsoft pour tous les utilisateurs, sauf les administrateurs généraux et les comptes externes.
    • 1er juillet 2027 : même retrait, mais cette fois pour les administrateurs généraux et les utilisateurs externes — dix mois de sursis pour les comptes les plus sensibles, pas moins.

    Après chacune de ces deux échéances, un utilisateur sans autre méthode MFA que le SMS ou la voix est bloqué à la connexion tant qu’il n’a pas enregistré une passkey. Aucune exemption n’existe passé ces dates — l’annonce officielle sur Microsoft Learn est explicite là-dessus.

    Une nuance qui compte si tu gères des comptes B2B : les invités internes suivent la date de février, pas celle de juillet. Seuls les comptes externes proprement dits (B2B collaboration) bénéficient du délai supplémentaire.

    Pourquoi maintenant, et pourquoi sans mode « je désactive et j’oublie »

    Le SMS et la voix comme second facteur ont un défaut connu depuis des années : ils transitent par le réseau télécom, vulnérable au SIM swap et à l’interception. Les passkeys reposent sur de la cryptographie à clé publique — la clé privée ne quitte jamais l’appareil, donc rien à intercepter côté réseau. Ce n’est pas une nuance marketing, c’est la raison technique pour laquelle Microsoft qualifie les passkeys de méthode « phishing-resistant » quand le SMS ne l’est pas, comme le détaille le billet du Microsoft Security Blog qui a lancé cette annonce.

    Ce qui change la donne par rapport aux précédentes campagnes de dépréciation Microsoft, c’est l’absence de porte de sortie après la date butoir. Tu peux repousser l’activation automatique via un opt-out temporaire — voir plus bas — mais l’échéance de blocage, elle, ne se négocie pas.

    Savoir qui, dans ton tenant, dépend encore du SMS ou de la voix

    Avant de basculer qui que ce soit, identifie les comptes concernés. Microsoft publie un script PowerShell dédié à cet usage exact :

    # https://github.com/microsoft/entra-sms-voice-usage-analyzer
# Rôles nécessaires : Global Reader, Authentication Policy Administrator, Security Reader
.\Get-SmsVoiceUsageReport.ps1 -TenantId "<ton-tenant-id>"

    Pour un contrôle ponctuel sans script, un appel Graph direct sur la politique d’authentification donne déjà une bonne partie de la réponse :

    GET https://graph.microsoft.com/beta/policies/authenticationmethodspolicy

    Configurer les passkeys avant que Microsoft ne s’en charge

    L’activation se fait aujourd’hui exclusivement depuis le portail — il n’existe pas encore de cmdlet PowerShell native pour l’activation de base, seul le provisioning avancé passe par Microsoft Graph, en preview. Le chemin : Entra ID → Security → Authentication methods → Policies → Passkey (FIDO2), puis l’opt-in aux profils de passkeys depuis la bannière — une action irréversible, à garder en tête avant de cliquer.

    Une fois l’opt-in fait, le profil par défaut se configure avec trois réglages qui ont un vrai impact opérationnel :

    • Passkey types : device-bound, synced, ou les deux — les passkeys synchronisées (iCloud Keychain, Google Password Manager, gestionnaires comme 1Password) simplifient l’adoption mais sortent la clé privée de l’appareil physique unique.
    • Enforce attestation : vérifie que l’authentificateur est un modèle reconnu, désactivé par défaut, à activer sur les profils sensibles.
    • Enforce key restrictions : limite les modèles acceptés par AAGUID, l’identifiant unique de chaque fabricant/modèle FIDO2 — utile pour n’autoriser que Microsoft Authenticator ou des clés YubiKey précises sur les comptes à privilèges. Le détail de la procédure est dans le guide Microsoft Learn sur l’activation des passkeys FIDO2.

    Tu peux créer jusqu’à trois profils au total, profil par défaut inclus, avec une limite de taille de 20 Ko pour l’ensemble de la politique — largement suffisant, sauf à lister des dizaines d’AAGUID par profil. Un exemple raisonnable pour une entreprise avec des comptes à privilèges : un profil « Admin » en device-bound uniquement avec attestation forcée, ciblé sur le groupe IT/Exécutifs, et un profil par défaut plus permissif (device-bound + synced, sans attestation) pour le reste des utilisateurs.

    L’opt-out temporaire : un sursis, pas une exemption

    Si tu n’es pas prêt pour la bascule automatique du 1er septembre, un appel Graph permet de sortir ton tenant de l’activation automatique et des campagnes d’enregistrement :

    PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json

{
   "optOutSettings": {
     "passkeyDynamicMigration": true
   }
}

    Permission requise : Policy.ReadWrite.AuthenticationMethod. Mais ne t’y trompe pas : ce réglage suspend l’activation automatique et les nudges, il ne touche pas à l’échéance de blocage du 1er février 2027 (ou du 1er juillet pour les admins/externes). Passé cette date, l’enregistrement d’une passkey redevient obligatoire, opt-out ou pas. Autant utiliser ce sursis pour préparer la bascule dans de bonnes conditions plutôt que pour la repousser indéfiniment — il n’existe pas de version « je ne fais rien » qui survit à l’échéance.

    Et si tu dois vraiment garder du SMS ou de la voix

    Pour des contraintes réglementaires ou des populations d’utilisateurs qui ne peuvent techniquement pas passer aux passkeys — téléphones basiques, zones sans app store —, Microsoft ouvre à partir du 30 octobre 2026 un marché de fournisseurs télécom tiers via le Microsoft Security Store. Soprano et Telesign sont les deux premiers annoncés, avec d’autres providers attendus en disponibilité générale. Ce n’est pas gratuit, et ça reste un pis-aller : la dépendance au réseau télécom ne disparaît pas, elle change juste de facturation.

    FAQ

    Mon tenant peut-il éviter complètement cette migration ?

    Non, pas au-delà des échéances de blocage. L’opt-out ne fait que retarder l’activation automatique et les campagnes d’enregistrement ; il n’annule pas la retraite du SMS/voix géré par Microsoft.

    Les passkeys synchronisées sont-elles aussi sûres que les passkeys liées à l’appareil ?

    Elles restent phishing-resistant, mais la clé privée est répliquée dans le coffre du fournisseur (iCloud Keychain, Google Password Manager…), donc le modèle de menace n’est pas identique à une clé bound à un seul appareil ou à une security key physique. Pour des comptes à privilèges, le device-bound avec attestation forcée reste le choix le plus prudent.

    Faut-il une licence Entra ID P1 ou P2 pour activer les passkeys ?

    Non. Les méthodes d’authentification de base, passkeys incluses, sont disponibles avec Microsoft Entra ID Free — ce sont certains contrôles avancés (Conditional Access, authentication strengths personnalisées) qui nécessitent P1 ou P2.

    Que tu aies déjà mis en place du Conditional Access pour sécuriser tes accès — voir notre article sur la sécurisation des identités d’agents IA dans Entra ID — ou que tu prépares encore ta politique d’enforcement — voir notre suivi du changement d’enforcement de juin 2026 —, la fenêtre entre maintenant et février 2027 est le bon moment pour traiter les passkeys comme un projet plutôt que comme une notification à ignorer. Lance le script de détection cette semaine : tu sauras exactement combien de comptes sont concernés avant que Microsoft ne bascule pour toi.