❌

Vue normale

Reçu — 1 octobre 2026 ⏭ Actualités numériques

Sécurité : le premier point de situation REACTIV de l’ANSSI illustre l’ampleur du problème

1 octobre 2026 à 13:55
Il y a du travail
Sécurité : le premier point de situation REACTIV de l’ANSSI illustre l’ampleur du problème

L’ANSSI a publié le premier point de situation de son dispositif REACTIV. Le rapport est sobre et direct, alignant les causes des différents incidents cyber des deux derniers mois contre les ministères, avec des chiffres éloquents.

Le dispositif REACTIV (pour REponse & ACTion Interministérielle face aux Violations de données) a été créé par l’ANSSI (Agence nationale de la sécurité des systèmes d’information) à la demande du Premier ministre Sébastien Lecornu. Annoncée publiquement le 7 septembre, elle constitue une réorientation des moyens opérationnels de l’ANSSI vers deux tâches : le traitement des comptes utilisateurs compromis et l’analyse des violations de données.

Cybersécurité : l’ANSSI lance son mécanisme REACTIV dédié aux services de l’État – Next↗

Comme nous l’indiquions au moment de l’annonce, l’agence obtient deux pouvoirs nouveaux. D’abord, elle centralise la communication technique de crise. Ensuite, et surtout, l’ANSSI peut imposer aux ministères des mesures de protection immédiates dans des délais contraints. Vincent Strubel, directeur de l’agence, avait bien précisé lors de l’annonce que l’effort était temporaire et qu’il se faisait au détriment d’autres pans de la menace.

La situation exigeait une forme d’urgence. Il n’aura fallu que trois semaines pour que l’ANSSI publie un premier point d’étape, faisant le bilan des attaques des deux derniers mois contre plusieurs ministères.

Des brèches en pagaille

Depuis le 1ᵉʳ août 2026, 99 violations de données ont été signalées à l’ANSSI, dont 67 sont confirmées et 32 sont en cours de traitement par l’agence.

Parmi les incidents, la faille CVE-2026-72898 (score CVSS 10) dans Metabase (une plateforme open source dédiée à l’intelligence économique) et son exploitation sont en bonne place. L’ANSSI évoque neuf instances ministérielles compromises depuis début août. « Cette vulnérabilité, de type injection SQL, permet l’accès à la base de données de l’application Metabase pour un utilisateur non authentifié et l’obtention des droits administrateurs de l’instance », indique le rapport.

Lorsque la faille a été découverte le 3 août par Metabase, elle était déjà exploitée. Le correctif a été publié le 6 août. Pour les ministères français en revanche, il ne s’agissait probablement déjà plus d’une faille 0-day, l’attaque contre France VAE étant par exemple survenue le 8 août. L’exploitation de cette faille a servi également contre Zéro Logement Vacant, Qualicharge et probablement Docurba, même si l’enquête n’est pas terminée.

Mais cette faille a aussi servi contre le propre Laboratoire d’innovation de l’ANSSI et contre la Direction interministérielle du numérique (DINUM), deux agences relevant du Premier ministre. Dans le premier cas, l’ANSSI pointe « la compromission de 118 comptes utilisateurs Metabase dont une trentaine de comptes d’utilisateurs externes (données statistiques d’utilisation, identifiants, courriels et mots de passe hachés) ». Les instances vulnérables ont été mises à jour, les mots de passe ont été renouvelés pour l’ensemble des comptes et les comptes inutilisés depuis plus de trois mois ont été désactivés.

Dans le cas de la DINUM, deux instances Metabase ont été compromises, ProConnect et Nuage-Public. « Les données exfiltrées portent sur des informations administratives d’organismes publics (SIREN, SIRET, budgets, effectifs), des métadonnées de contributions à des projets logiciels open source, et des historiques de connexions anonymisés », indique l’ANSSI. L’agence ajoute que ces données étaient cependant déjà publiques. Là encore, les vulnérabilités ont été colmatées, les secrets réinitialisés et les comptes créés par l’attaquant supprimés.

Le rapport n’indique pas toutefois dans quelle mesure ces instances Metabase étaient exposées à internet. Dans tous les cas, l’information tombe mal pour l’ANSSI, qui doit montrer l’exemple, notamment en matière de réactivité sur les correctifs sortant régulièrement. Il s’est écoulé au moins plusieurs jours entre la publication du correctif de Metabase et les premiers signes d’attaque contre la faille au sein des ministères, témoignant d’un retard dans l’application. Dans le cas de l’agence, même s’il s’agit uniquement de son Laboratoire d’innovation, le signal renvoyé n’est pas glorieux.

On peut noter également que l’avis du CERT-FR sur plusieurs failles Metabase a été publié le 24 août, alors que trois des quatre failles (dont CVE-2026-72898) étaient connues depuis le 6 et la dernière le 11.

Des défauts de sécurisation classiques

Les autres incidents relèvent malheureusement de défauts de sécurité classiques. Par exemple, des identifiants volés par des infostealers sur des postes personnels ou de partenaires, puis utilisés contre des services exposés sans double authentification. C’est le cas pour le PIGP (Portail de la Gestion Publique de la DGFIP), le cadastre et l’AEFE (Agence pour l’enseignement français à l’étranger).

L’absence de double authentification ressort justement dans le rapport, ou un deuxième facteur par simple e-mail, cette méthode n’étant plus considérée comme robuste depuis longtemps. Le point de situation évoque également la compromission de sous-traitants, dont un de TRACFIN, et le serveur d’échange avec les prestataires de la DGDDI.

On note aussi que plusieurs incidents sont en cours de qualification. Par exemple, pour Signal Logement (identification de logements insalubres) et le BCPR (Bureau des courriers parlementaires et réservés), duquel des e-mails auraient été exfiltrés, sans que l’ANSSI en soit certaine pour l’instant.

En outre, si la mission de REACTIV est surtout de pouvoir imposer des mesures concrètes dans des délais contraints, on ne sait rien des éventuels changements mis en place pour faire évoluer la culture de la cybersécurité chez l’ensemble des personnes concernées. Si l’exploitation de failles peut souvent être combattue par une application stricte des correctifs de sécurité, les attaques passant par des comptes compromis doivent interpeler les utilisateurs impliqués et leur hygiène numérique, dont la gestion de leurs mots de passe.

Une utilisation sérieuse de la double authentification ne semble pas toujours la règle non plus, le mécanisme relevant des ministères et de leurs services informatiques. À ce sujet, la position de l’ANSSI est d’ailleurs claire : « facteur clé de nombreux incidents analysés par l’ANSSI, l’absence de MFA, ou l’utilisation d’un second facteur faible (e-mail), a facilité les intrusions puisqu’un mot de passe faible ou une fuite de mot de passe suffisait à l’attaquant pour s’octroyer a minima un accès utilisateur ».

Sécurité : le premier point de situation REACTIV de l’ANSSI illustre l’ampleur du problème

1 octobre 2026 à 13:55
Il y a du travail
Sécurité : le premier point de situation REACTIV de l’ANSSI illustre l’ampleur du problème

L’ANSSI a publié le premier point de situation de son dispositif REACTIV. Le rapport est sobre et direct, alignant les causes des différents incidents cyber des deux derniers mois contre les ministères, avec des chiffres éloquents.

Le dispositif REACTIV (pour REponse & ACTion Interministérielle face aux Violations de données) a été créé par l’ANSSI (Agence nationale de la sécurité des systèmes d’information) à la demande du Premier ministre Sébastien Lecornu. Annoncée publiquement le 7 septembre, elle constitue une réorientation des moyens opérationnels de l’ANSSI vers deux tâches : le traitement des comptes utilisateurs compromis et l’analyse des violations de données.

Cybersécurité : l’ANSSI lance son mécanisme REACTIV dédié aux services de l’État – Next↗

Comme nous l’indiquions au moment de l’annonce, l’agence obtient deux pouvoirs nouveaux. D’abord, elle centralise la communication technique de crise. Ensuite, et surtout, l’ANSSI peut imposer aux ministères des mesures de protection immédiates dans des délais contraints. Vincent Strubel, directeur de l’agence, avait bien précisé lors de l’annonce que l’effort était temporaire et qu’il se faisait au détriment d’autres pans de la menace.

La situation exigeait une forme d’urgence. Il n’aura fallu que trois semaines pour que l’ANSSI publie un premier point d’étape, faisant le bilan des attaques des deux derniers mois contre plusieurs ministères.

Des brèches en pagaille

Depuis le 1ᵉʳ août 2026, 99 violations de données ont été signalées à l’ANSSI, dont 67 sont confirmées et 32 sont en cours de traitement par l’agence.

Parmi les incidents, la faille CVE-2026-72898 (score CVSS 10) dans Metabase (une plateforme open source dédiée à l’intelligence économique) et son exploitation sont en bonne place. L’ANSSI évoque neuf instances ministérielles compromises depuis début août. « Cette vulnérabilité, de type injection SQL, permet l’accès à la base de données de l’application Metabase pour un utilisateur non authentifié et l’obtention des droits administrateurs de l’instance », indique le rapport.

Lorsque la faille a été découverte le 3 août par Metabase, elle était déjà exploitée. Le correctif a été publié le 6 août. Pour les ministères français en revanche, il ne s’agissait probablement déjà plus d’une faille 0-day, l’attaque contre France VAE étant par exemple survenue le 8 août. L’exploitation de cette faille a servi également contre Zéro Logement Vacant, Qualicharge et probablement Docurba, même si l’enquête n’est pas terminée.

Mais cette faille a aussi servi contre le propre Laboratoire d’innovation de l’ANSSI et contre la Direction interministérielle du numérique (DINUM), deux agences relevant du Premier ministre. Dans le premier cas, l’ANSSI pointe « la compromission de 118 comptes utilisateurs Metabase dont une trentaine de comptes d’utilisateurs externes (données statistiques d’utilisation, identifiants, courriels et mots de passe hachés) ». Les instances vulnérables ont été mises à jour, les mots de passe ont été renouvelés pour l’ensemble des comptes et les comptes inutilisés depuis plus de trois mois ont été désactivés.

Dans le cas de la DINUM, deux instances Metabase ont été compromises, ProConnect et Nuage-Public. « Les données exfiltrées portent sur des informations administratives d’organismes publics (SIREN, SIRET, budgets, effectifs), des métadonnées de contributions à des projets logiciels open source, et des historiques de connexions anonymisés », indique l’ANSSI. L’agence ajoute que ces données étaient cependant déjà publiques. Là encore, les vulnérabilités ont été colmatées, les secrets réinitialisés et les comptes créés par l’attaquant supprimés.

Le rapport n’indique pas toutefois dans quelle mesure ces instances Metabase étaient exposées à internet. Dans tous les cas, l’information tombe mal pour l’ANSSI, qui doit montrer l’exemple, notamment en matière de réactivité sur les correctifs sortant régulièrement. Il s’est écoulé au moins plusieurs jours entre la publication du correctif de Metabase et les premiers signes d’attaque contre la faille au sein des ministères, témoignant d’un retard dans l’application. Dans le cas de l’agence, même s’il s’agit uniquement de son Laboratoire d’innovation, le signal renvoyé n’est pas glorieux.

On peut noter également que l’avis du CERT-FR sur plusieurs failles Metabase a été publié le 24 août, alors que trois des quatre failles (dont CVE-2026-72898) étaient connues depuis le 6 et la dernière le 11.

Des défauts de sécurisation classiques

Les autres incidents relèvent malheureusement de défauts de sécurité classiques. Par exemple, des identifiants volés par des infostealers sur des postes personnels ou de partenaires, puis utilisés contre des services exposés sans double authentification. C’est le cas pour le PIGP (Portail de la Gestion Publique de la DGFIP), le cadastre et l’AEFE (Agence pour l’enseignement français à l’étranger).

L’absence de double authentification ressort justement dans le rapport, ou un deuxième facteur par simple e-mail, cette méthode n’étant plus considérée comme robuste depuis longtemps. Le point de situation évoque également la compromission de sous-traitants, dont un de TRACFIN, et le serveur d’échange avec les prestataires de la DGDDI.

On note aussi que plusieurs incidents sont en cours de qualification. Par exemple, pour Signal Logement (identification de logements insalubres) et le BCPR (Bureau des courriers parlementaires et réservés), duquel des e-mails auraient été exfiltrés, sans que l’ANSSI en soit certaine pour l’instant.

En outre, si la mission de REACTIV est surtout de pouvoir imposer des mesures concrètes dans des délais contraints, on ne sait rien des éventuels changements mis en place pour faire évoluer la culture de la cybersécurité chez l’ensemble des personnes concernées. Si l’exploitation de failles peut souvent être combattue par une application stricte des correctifs de sécurité, les attaques passant par des comptes compromis doivent interpeler les utilisateurs impliqués et leur hygiène numérique, dont la gestion de leurs mots de passe.

Une utilisation sérieuse de la double authentification ne semble pas toujours la règle non plus, le mécanisme relevant des ministères et de leurs services informatiques. À ce sujet, la position de l’ANSSI est d’ailleurs claire : « facteur clé de nombreux incidents analysés par l’ANSSI, l’absence de MFA, ou l’utilisation d’un second facteur faible (e-mail), a facilité les intrusions puisqu’un mot de passe faible ou une fuite de mot de passe suffisait à l’attaquant pour s’octroyer a minima un accès utilisateur ».

Les serveurs e-mail Zimbra visés par l’exploitation très active d’une faille critique

1 octobre 2026 à 07:36
Le correctif était pourtant là
Les serveurs e-mail Zimbra visés par l’exploitation très active d’une faille critique

Les personnes et organisations disposant de serveurs équipés de Zimbra pour la gestion de leurs e-mails doivent mettre à jour aussi rapidement que possible les composants logiciels. Une faille est exploitée depuis plus de deux mois, alors que le correctif existe depuis le 20 juillet.

Dans un long billet publié le 30 septembre, Microsoft Threat Intelligence a fourni une analyse de l’exploitation de CVE-2026-73570, une faille de type « injection de commandes système non authentifiée » dans Zimbra Collaboration Suite (ZCS), une solution e-mail très populaire.

Cette faille, présente dans toutes les versions antérieures à la 10.1.20, est en fait corrigée depuis juillet. Cependant, les systèmes non mis à jour seraient encore nombreux, Microsoft indique que la faille – critique, avec un score CVSS de 8,9 – est exploitée depuis fin juillet au moins. L’éditeur évoque un minimum de plusieurs centaines de serveurs compromis par l’exploitation de cette faille.

Cette vulnérabilité est présente dans le traitement des notifications SNMP de Zimbra. Elle peut être exploitée dès lors que le paquet optionnel zimbra-snmp est installé et que les notifications sont activées. Un attaquant non authentifié peut alors envoyer des requêtes SMTP spécialement conçues pour provoquer une erreur, lui permettant après coup d’exécuter des commandes système arbitraires avec les droits de l’utilisateur zimbra.

Des attaques rondement menées

Dans son billet, Microsoft dit avoir observé deux outils de balayage le 28 juillet et le 7 août, donc après le correctif mais avant la divulgation, intervenue le 13 août avec la publication des informations dans la base NVD. « Les sondes incluaient des requêtes HTTP et des vérifications d’identité DNS, ICMP et en bande, utilisant des commandes telles que curl, wget, ping, nslookup et id », vers des services d’interaction comme oast[.]fun ou requestrepo[.]com, ou vers une infrastructure propre à la campagne d’attaque sous bypass[.]eu[.]org. Les requêtes HTTP portaient un User-Agent spécifique, ZB73570, suggérant selon Microsoft que des acteurs ont analysé le correctif avant la publication des détails du bulletin CVE.

Les attaquants ont ensuite déposé des pages JSP malveillantes (webshells) dans les répertoires Jetty et mailboxd, puis les ont recopiées sur les autres nœuds de boîtes aux lettres. Ils allaient parfois jusqu’à ouvrir temporairement les droits d’écriture du répertoire public avant de les rétablir. Ils ont aussi installé un service systemd déguisé, zimlog.service, dont les horodatages avaient été modifiés pour imiter sshd.service.

Source : Microsoft

L’exploitation se faisait au moyen du journal zmmailboxd.out remplacé par un lien symbolique vers /etc/pam.d/sudo, qui invoquait alors zmmailboxdmgr, exécuté avec des privilèges élevés. Les pirates étaient ensuite capables de voler des secrets, de se déplacer latéralement dans l’infrastructure et d’exfiltrer des contenus. Microsoft n’attribue cette activité à aucun acteur nommé, le rapport mentionnant des victimes dans plusieurs régions et secteurs, et un mélange d’opérations automatisées et manuelles.

Du pain sur la planche

Selon le rapport, toute instance Zimbra qui n’a pas été mise à jour avant fin juillet doit être considérée comme potentiellement compromise. L’installation de la mise à jour est la mesure la plus urgente à entreprendre. À défaut, si l’opération est impossible dans l’immédiat, Microsoft recommande la désinstallation du paquet zimbra-snmp, la désactivation des notifications SNMP et la restriction de l’accès SNMP et SMTP aux seuls hôtes de confiance.

Une fois la mise à jour effectuée, plusieurs actions sont encore nécessaires :

  • Renouveler toutes les clés zimbraPreAuthKey et zimbraAuthTokenKey
  • Inspecter /etc/sudoers.d/ (notamment 81_metric), /etc/pam.d/ et les unités systemd (zimlog.service, chronyd-helper.service, syslog_init.service)
  • Chercher les JSP et fichiers *_jsp.java inattendus sur la totalité des nœuds

Les serveurs e-mail Zimbra visés par l’exploitation très active d’une faille critique

1 octobre 2026 à 07:36
Le correctif était pourtant là
Les serveurs e-mail Zimbra visés par l’exploitation très active d’une faille critique

Les personnes et organisations disposant de serveurs équipés de Zimbra pour la gestion de leurs e-mails doivent mettre à jour aussi rapidement que possible les composants logiciels. Une faille est exploitée depuis plus de deux mois, alors que le correctif existe depuis le 20 juillet.

Dans un long billet publié le 30 septembre, Microsoft Threat Intelligence a fourni une analyse de l’exploitation de CVE-2026-73570, une faille de type « injection de commandes système non authentifiée » dans Zimbra Collaboration Suite (ZCS), une solution e-mail très populaire.

Cette faille, présente dans toutes les versions antérieures à la 10.1.20, est en fait corrigée depuis juillet. Cependant, les systèmes non mis à jour seraient encore nombreux, Microsoft indique que la faille – critique, avec un score CVSS de 8,9 – est exploitée depuis fin juillet au moins. L’éditeur évoque un minimum de plusieurs centaines de serveurs compromis par l’exploitation de cette faille.

Cette vulnérabilité est présente dans le traitement des notifications SNMP de Zimbra. Elle peut être exploitée dès lors que le paquet optionnel zimbra-snmp est installé et que les notifications sont activées. Un attaquant non authentifié peut alors envoyer des requêtes SMTP spécialement conçues pour provoquer une erreur, lui permettant après coup d’exécuter des commandes système arbitraires avec les droits de l’utilisateur zimbra.

Des attaques rondement menées

Dans son billet, Microsoft dit avoir observé deux outils de balayage le 28 juillet et le 7 août, donc après le correctif mais avant la divulgation, intervenue le 13 août avec la publication des informations dans la base NVD. « Les sondes incluaient des requêtes HTTP et des vérifications d’identité DNS, ICMP et en bande, utilisant des commandes telles que curl, wget, ping, nslookup et id », vers des services d’interaction comme oast[.]fun ou requestrepo[.]com, ou vers une infrastructure propre à la campagne d’attaque sous bypass[.]eu[.]org. Les requêtes HTTP portaient un User-Agent spécifique, ZB73570, suggérant selon Microsoft que des acteurs ont analysé le correctif avant la publication des détails du bulletin CVE.

Les attaquants ont ensuite déposé des pages JSP malveillantes (webshells) dans les répertoires Jetty et mailboxd, puis les ont recopiées sur les autres nœuds de boîtes aux lettres. Ils allaient parfois jusqu’à ouvrir temporairement les droits d’écriture du répertoire public avant de les rétablir. Ils ont aussi installé un service systemd déguisé, zimlog.service, dont les horodatages avaient été modifiés pour imiter sshd.service.

Source : Microsoft

L’exploitation se faisait au moyen du journal zmmailboxd.out remplacé par un lien symbolique vers /etc/pam.d/sudo, qui invoquait alors zmmailboxdmgr, exécuté avec des privilèges élevés. Les pirates étaient ensuite capables de voler des secrets, de se déplacer latéralement dans l’infrastructure et d’exfiltrer des contenus. Microsoft n’attribue cette activité à aucun acteur nommé, le rapport mentionnant des victimes dans plusieurs régions et secteurs, et un mélange d’opérations automatisées et manuelles.

Du pain sur la planche

Selon le rapport, toute instance Zimbra qui n’a pas été mise à jour avant fin juillet doit être considérée comme potentiellement compromise. L’installation de la mise à jour est la mesure la plus urgente à entreprendre. À défaut, si l’opération est impossible dans l’immédiat, Microsoft recommande la désinstallation du paquet zimbra-snmp, la désactivation des notifications SNMP et la restriction de l’accès SNMP et SMTP aux seuls hôtes de confiance.

Une fois la mise à jour effectuée, plusieurs actions sont encore nécessaires :

  • Renouveler toutes les clés zimbraPreAuthKey et zimbraAuthTokenKey
  • Inspecter /etc/sudoers.d/ (notamment 81_metric), /etc/pam.d/ et les unités systemd (zimlog.service, chronyd-helper.service, syslog_init.service)
  • Chercher les JSP et fichiers *_jsp.java inattendus sur la totalité des nœuds

Microsoft dégaine ses conteneurs WSL (Linux) en version finale

1 octobre 2026 à 05:59
Compose viendra, promis
Microsoft dégaine ses conteneurs WSL (Linux) en version finale

Microsoft a donné le coup d’envoi officiel pour ses conteneurs WSL. Ils permettent de créer, exécuter et gérer des conteneurs Linux directement depuis Windows.

Au début de l’été, Microsoft a profité de sa conférence Build pour présenter un nouveau projet baptisé « WSL Container », avec une préversion dans la foulée. L’objectif était clair : fournir un moyen intégré et prêt pour l’entreprise de créer, exécuter et gérer des conteneurs Linux sur Windows, sans nécessiter d’outillage tiers supplémentaire.

Depuis le 29 septembre, la fonction est disponible en version finale. Microsoft n’y va pas par quatre chemins : « WSL est au cœur de notre engagement à faire de Windows le meilleur endroit pour construire, exécuter et gérer des charges de travail Linux. À mesure que l’IA, le développement cloud-native, les conteneurs et les écosystèmes open source continuent de converger vers Linux, de plus en plus de développeurs choisissent d’exécuter ces charges directement sur des appareils Windows ». Les conteneurs sont donc une évolution logique de WSL, affirme l’éditeur.

Petit point de rappel d’abord : qu’est-ce que WSL ? Le Windows Subsystem for Linux est un composant de Windows permettant de faire fonctionner directement une distribution Linux virtualisée. Plusieurs sont disponibles d’ailleurs dans le Microsoft Store, comme Ubuntu et Debian.

Source : Microsoft

Disponible directement dans la nouvelle version de WSL

Pour utiliser les conteneurs, pas besoin d’installer de nouveaux composants, car la nouvelle fonction fait simplement partie de la dernière mouture du WSL (3.0.1). On peut donc l’installer soit en récupérant le binaire depuis le dépôt GitHub, soit via la commande « wsl --update » dans le terminal.

Le produit livré hier soir repose sur deux briques. D’abord, l’outil wslc.exe qui sert à construire, lancer et déployer les conteneurs. Microsoft fournit en même temps un alias intégré container.exe pour reprendre les commandes habituelles. Ensuite, une API – sous forme de paquet NuGet Microsoft.WSL.Containers – pour permettre aux applications Windows natives de piloter ces conteneurs. L’éditeur donne comme exemple l’exécution locale de charges IA.

En matière d’architecture, chaque utilisateur a sa propre session, dont les privilèges peuvent être réglés, y compris de manière centralisée en entreprise. Le stockage, lui, peut se faire de trois manières : un VHD par session, des volumes reposant sur VHD ou des volumes de conteneurs reposant sur virtiofs, que Microsoft présente comme jusqu’à deux fois plus rapides que l’approche plan9 utilisée jusqu’à présent par WSL.

Quant au réseau, il est géré par un composant nommé Consommé, qui consiste en un processus s’occupant de tout ce qui touche au DNS, au routage et au mappage des ports. Cette approche doit notamment permettre de travailler plus facilement avec des VPN et des pare-feux.

Docker dans la ligne de mire

D’accord, mais pour quoi faire ? On trouve sur le site de Microsoft ou dans la presse des exemples d’utilisation. Le plus simple est celui d’une application Windows embarquant un composant Linux. Ainsi, un logiciel de bureau en C# peut lancer un conteneur servant un modèle d’inférence, communiquer avec lui puis l’arrêter à la fermeture. C’est l’exemple de charge IA locale donné précédemment par Microsoft.

Si le nom n’est jamais cité, Docker est directement dans la ligne de mire. Microsoft met en avant ses intégrations avec d’autres produits de son écosystème, Intune et Defender for Endpoint étant cités. L’arrivée des conteneurs WSL permet aux applications Windows de les exploiter directement, sans passer par des produits tiers (il faut quand même que WSL soit installé).

Il s’agit cependant d’une version 1.0, qui cible surtout les grandes entreprises dans lesquelles ce niveau d’intégration peut faire la différence. En outre, il y a des limites. Selon Microsoft, la fonction la plus demandée est la compatibilité avec Docker Compose, via la prise en charge directe des fichiers compose.yaml existants. L’entreprise affirme que ce support est « une priorité pour nos prochaines versions ».

La version finale apporte des nouveautés

Si vous avez testé les conteneurs WSL cet été, la version finale apporte bon nombre d’améliorations, notamment pour les commandes disponibles, qui en comptent une dizaine de nouvelles. Citons par exemple « wslc container restart » qui permet de redémarrer un conteneur en fonctionnement, « wslc system info » pour voir une vue de synthèse de l’environnement conteneur, ou « wslc network connect » pour attacher les conteneurs au réseau (ou « disconnect » pour les détacher).

Entre temps, des intégrations sont également apparues avec des partenaires ou des projets communautaires. Les conteneurs sont ainsi supportés (sans grande surprise) dans Visual Studio Code, dans lequel on peut déclarer wslc comme pilote par défaut pour créer et interagir avec les conteneurs WSL. Microsoft cite aussi Aspire, Lazywslc, WSL Container Desktop ou encore WSLc Remote. Ce dernier permet de lancer wslc depuis les distributions Linux prises en charge par WSL.

Microsoft ajoute que les investissements dans WSL continueront. « Au fil du temps, nous voyons Linux sous Windows évoluer au-delà d’un environnement de développement vers une plateforme d’exécution stratégique pour l’IA et les charges de travail natives cloud, participant aux mêmes cadres de sécurité, de gestion et de gouvernance d’entreprise que Windows », assure ainsi l’entreprise.

Microsoft dégaine ses conteneurs WSL (Linux) en version finale

1 octobre 2026 à 05:59
Compose viendra, promis
Microsoft dégaine ses conteneurs WSL (Linux) en version finale

Microsoft a donné le coup d’envoi officiel pour ses conteneurs WSL. Ils permettent de créer, exécuter et gérer des conteneurs Linux directement depuis Windows.

Au début de l’été, Microsoft a profité de sa conférence Build pour présenter un nouveau projet baptisé « WSL Container », avec une préversion dans la foulée. L’objectif était clair : fournir un moyen intégré et prêt pour l’entreprise de créer, exécuter et gérer des conteneurs Linux sur Windows, sans nécessiter d’outillage tiers supplémentaire.

Depuis le 29 septembre, la fonction est disponible en version finale. Microsoft n’y va pas par quatre chemins : « WSL est au cœur de notre engagement à faire de Windows le meilleur endroit pour construire, exécuter et gérer des charges de travail Linux. À mesure que l’IA, le développement cloud-native, les conteneurs et les écosystèmes open source continuent de converger vers Linux, de plus en plus de développeurs choisissent d’exécuter ces charges directement sur des appareils Windows ». Les conteneurs sont donc une évolution logique de WSL, affirme l’éditeur.

Petit point de rappel d’abord : qu’est-ce que WSL ? Le Windows Subsystem for Linux est un composant de Windows permettant de faire fonctionner directement une distribution Linux virtualisée. Plusieurs sont disponibles d’ailleurs dans le Microsoft Store, comme Ubuntu et Debian.

Source : Microsoft

Disponible directement dans la nouvelle version de WSL

Pour utiliser les conteneurs, pas besoin d’installer de nouveaux composants, car la nouvelle fonction fait simplement partie de la dernière mouture du WSL (3.0.1). On peut donc l’installer soit en récupérant le binaire depuis le dépôt GitHub, soit via la commande « wsl --update » dans le terminal.

Le produit livré hier soir repose sur deux briques. D’abord, l’outil wslc.exe qui sert à construire, lancer et déployer les conteneurs. Microsoft fournit en même temps un alias intégré container.exe pour reprendre les commandes habituelles. Ensuite, une API – sous forme de paquet NuGet Microsoft.WSL.Containers – pour permettre aux applications Windows natives de piloter ces conteneurs. L’éditeur donne comme exemple l’exécution locale de charges IA.

En matière d’architecture, chaque utilisateur a sa propre session, dont les privilèges peuvent être réglés, y compris de manière centralisée en entreprise. Le stockage, lui, peut se faire de trois manières : un VHD par session, des volumes reposant sur VHD ou des volumes de conteneurs reposant sur virtiofs, que Microsoft présente comme jusqu’à deux fois plus rapides que l’approche plan9 utilisée jusqu’à présent par WSL.

Quant au réseau, il est géré par un composant nommé Consommé, qui consiste en un processus s’occupant de tout ce qui touche au DNS, au routage et au mappage des ports. Cette approche doit notamment permettre de travailler plus facilement avec des VPN et des pare-feux.

Docker dans la ligne de mire

D’accord, mais pour quoi faire ? On trouve sur le site de Microsoft ou dans la presse des exemples d’utilisation. Le plus simple est celui d’une application Windows embarquant un composant Linux. Ainsi, un logiciel de bureau en C# peut lancer un conteneur servant un modèle d’inférence, communiquer avec lui puis l’arrêter à la fermeture. C’est l’exemple de charge IA locale donné précédemment par Microsoft.

Si le nom n’est jamais cité, Docker est directement dans la ligne de mire. Microsoft met en avant ses intégrations avec d’autres produits de son écosystème, Intune et Defender for Endpoint étant cités. L’arrivée des conteneurs WSL permet aux applications Windows de les exploiter directement, sans passer par des produits tiers (il faut quand même que WSL soit installé).

Il s’agit cependant d’une version 1.0, qui cible surtout les grandes entreprises dans lesquelles ce niveau d’intégration peut faire la différence. En outre, il y a des limites. Selon Microsoft, la fonction la plus demandée est la compatibilité avec Docker Compose, via la prise en charge directe des fichiers compose.yaml existants. L’entreprise affirme que ce support est « une priorité pour nos prochaines versions ».

La version finale apporte des nouveautés

Si vous avez testé les conteneurs WSL cet été, la version finale apporte bon nombre d’améliorations, notamment pour les commandes disponibles, qui en comptent une dizaine de nouvelles. Citons par exemple « wslc container restart » qui permet de redémarrer un conteneur en fonctionnement, « wslc system info » pour voir une vue de synthèse de l’environnement conteneur, ou « wslc network connect » pour attacher les conteneurs au réseau (ou « disconnect » pour les détacher).

Entre temps, des intégrations sont également apparues avec des partenaires ou des projets communautaires. Les conteneurs sont ainsi supportés (sans grande surprise) dans Visual Studio Code, dans lequel on peut déclarer wslc comme pilote par défaut pour créer et interagir avec les conteneurs WSL. Microsoft cite aussi Aspire, Lazywslc, WSL Container Desktop ou encore WSLc Remote. Ce dernier permet de lancer wslc depuis les distributions Linux prises en charge par WSL.

Microsoft ajoute que les investissements dans WSL continueront. « Au fil du temps, nous voyons Linux sous Windows évoluer au-delà d’un environnement de développement vers une plateforme d’exécution stratégique pour l’IA et les charges de travail natives cloud, participant aux mêmes cadres de sécurité, de gestion et de gouvernance d’entreprise que Windows », assure ainsi l’entreprise.

❌