Le 2 octobre, Apple a fait savoir par une courte note destinée aux développeurs que des changements allaient être introduits pour renforcer l’accès complet au disque dans macOS.

L’entreprise indique que de nombreux contrôles ont été mis en place avec le temps sur son système, mais que l’autorisation d’accès complet au disque permet largement de les contourner. Le fonctionnement était voulu pour « permettre aux applications de sauvegarde de fonctionner correctement sur Mac ».

Cependant, des « développeurs utilisent l’accès complet au disque de manières qui pourraient mettre les utilisateurs en danger, exposant tout ce qui se trouve sur leurs systèmes – y compris les fichiers, les courriels, les messages, et même l’historique de navigation – sans que les utilisateurs en aient pleinement connaissance et compréhension », indique Apple. L’entreprise ajoute que dans les applications de communication, la confidentialité des personnes en contact pourrait également être menacée.

L’entreprise ne compte pas supprimer l’accès disque complet, dont de nombreuses applications ont besoin, par exemple pour de la prise de contrôle à distance via Anydesk ou Teamviewer. En revanche, elle va introduire « des contrôles supplémentaires pour garantir que les utilisateurs qui souhaitent réellement accorder à une application ce niveau d’accès extraordinaire ne puissent le faire qu’avec une action très explicite ». Apple estime ce chantier « crucial », car « les agents IA deviennent de plus en plus capables et autonomes », l’entreprise semblant craindre que les risques associés augmentent « considérablement ».

La note est courte et ne contient aucun détail. Apple ne dit même pas quand ces changements vont être introduits. L’actuelle version 27.2 bêta de macOS ne contient pas ces modifications, mais on peut imaginer que le nouveau contrôle sera présent dans la mouture 27.3.

Le calendrier est également particulier. Comme le souligne TechCrunch, l’annonce survient quelques jours après que le journaliste Jason Aten a affirmé que Muse (Meta) avait lu ses conversations privées. Il assure qu’il n’a jamais donné à Muse l’accès au disque complet, mais que ce dernier lui a quand même suggéré un sujet sur la base d’éléments n’apparaissant que dans l’application Messages sur son Mac. Meta conteste cette version, affirmant que la lecture des conversations dans Messages exige non seulement l’accès complet au disque, mais aussi l’activation du connecteur spécifique Muse pour l’application d’Apple.

Le 2 octobre, Apple a fait savoir par une courte note destinée aux développeurs que des changements allaient être introduits pour renforcer l’accès complet au disque dans macOS.

L’entreprise indique que de nombreux contrôles ont été mis en place avec le temps sur son système, mais que l’autorisation d’accès complet au disque permet largement de les contourner. Le fonctionnement était voulu pour « permettre aux applications de sauvegarde de fonctionner correctement sur Mac ».

Cependant, des « développeurs utilisent l’accès complet au disque de manières qui pourraient mettre les utilisateurs en danger, exposant tout ce qui se trouve sur leurs systèmes – y compris les fichiers, les courriels, les messages, et même l’historique de navigation – sans que les utilisateurs en aient pleinement connaissance et compréhension », indique Apple. L’entreprise ajoute que dans les applications de communication, la confidentialité des personnes en contact pourrait également être menacée.

L’entreprise ne compte pas supprimer l’accès disque complet, dont de nombreuses applications ont besoin, par exemple pour de la prise de contrôle à distance via Anydesk ou Teamviewer. En revanche, elle va introduire « des contrôles supplémentaires pour garantir que les utilisateurs qui souhaitent réellement accorder à une application ce niveau d’accès extraordinaire ne puissent le faire qu’avec une action très explicite ». Apple estime ce chantier « crucial », car « les agents IA deviennent de plus en plus capables et autonomes », l’entreprise semblant craindre que les risques associés augmentent « considérablement ».

La note est courte et ne contient aucun détail. Apple ne dit même pas quand ces changements vont être introduits. L’actuelle version 27.2 bêta de macOS ne contient pas ces modifications, mais on peut imaginer que le nouveau contrôle sera présent dans la mouture 27.3.

Le calendrier est également particulier. Comme le souligne TechCrunch, l’annonce survient quelques jours après que le journaliste Jason Aten a affirmé que Muse (Meta) avait lu ses conversations privées. Il assure qu’il n’a jamais donné à Muse l’accès au disque complet, mais que ce dernier lui a quand même suggéré un sujet sur la base d’éléments n’apparaissant que dans l’application Messages sur son Mac. Meta conteste cette version, affirmant que la lecture des conversations dans Messages exige non seulement l’accès complet au disque, mais aussi l’activation du connecteur spécifique Muse pour l’application d’Apple.

Orion est un navigateur conçu d’abord pour macOS. Après une version 1.0 sortie en novembre 2025 et une 1.1 en juin, Orion s’est fait un petit nom dans le domaine des butineurs.

Orion est bâti autour de WebKit, le moteur utilisé par Safari, avec l’idée bien sûr d’une intégration poussée dans l’écosystème Apple. L’équipe de développement met largement l’accent sur la vie privée : aucune télémétrie par défaut, un blocage intégré des traqueurs et publicités, des fonctions avancées comme des conteneurs multi-comptes, ou encore la compatibilité avec les extensions Chrome et Firefox. Celle-ci n’est pas toujours parfaite, mais elle a le mérite d’exister.

Il était également prévu qu’Orion arrive sur Linux et Windows, mais les plans ont changé. Dans un billet daté du 2 octobre, son éditeur Kagi renonce en effet à ces versions. La raison principale est la petite taille de l’équipe face au défi immense de maintenir trois bases de code. Contrairement à Chromium, WebKit n’a pas l’avantage d’être « prêt à l’emploi » sur plusieurs plateformes.

En conséquence, la bêta actuelle pour Linux ne sera plus mise à jour, même si on peut encore l’utiliser. La version Windows, qui devait sortir avant la fin de l’année, est elle aussi abandonnée. Kagi promet que tout le code travaillé pour ces deux plateformes sera prochainement rendu open source, afin que la communauté le récupère si elle souhaite poursuivre le travail de son côté. Des détails seront publiés au cours des 30 prochains jours à ce sujet.

L’éditeur évoque en outre des craintes de certains utilisateurs, selon lesquelles la société pourrait se disperser en tentant l’aventure du multiplateforme. L’entreprise semble donc leur donner raison et annonce que les versions macOS et iOS seront désormais les seules : « L’équipe et les ressources réparties sur les plateformes se concentrent à rendre Orion plus rapide, plus stable [et avec plus de capacités] sur les appareils Apple. Attendez-vous à des améliorations régulières dans les mois à venir ».

Orion est un navigateur conçu d’abord pour macOS. Après une version 1.0 sortie en novembre 2025 et une 1.1 en juin, Orion s’est fait un petit nom dans le domaine des butineurs.

Orion est bâti autour de WebKit, le moteur utilisé par Safari, avec l’idée bien sûr d’une intégration poussée dans l’écosystème Apple. L’équipe de développement met largement l’accent sur la vie privée : aucune télémétrie par défaut, un blocage intégré des traqueurs et publicités, des fonctions avancées comme des conteneurs multi-comptes, ou encore la compatibilité avec les extensions Chrome et Firefox. Celle-ci n’est pas toujours parfaite, mais elle a le mérite d’exister.

Il était également prévu qu’Orion arrive sur Linux et Windows, mais les plans ont changé. Dans un billet daté du 2 octobre, son éditeur Kagi renonce en effet à ces versions. La raison principale est la petite taille de l’équipe face au défi immense de maintenir trois bases de code. Contrairement à Chromium, WebKit n’a pas l’avantage d’être « prêt à l’emploi » sur plusieurs plateformes.

En conséquence, la bêta actuelle pour Linux ne sera plus mise à jour, même si on peut encore l’utiliser. La version Windows, qui devait sortir avant la fin de l’année, est elle aussi abandonnée. Kagi promet que tout le code travaillé pour ces deux plateformes sera prochainement rendu open source, afin que la communauté le récupère si elle souhaite poursuivre le travail de son côté. Des détails seront publiés au cours des 30 prochains jours à ce sujet.

L’éditeur évoque en outre des craintes de certains utilisateurs, selon lesquelles la société pourrait se disperser en tentant l’aventure du multiplateforme. L’entreprise semble donc leur donner raison et annonce que les versions macOS et iOS seront désormais les seules : « L’équipe et les ressources réparties sur les plateformes se concentrent à rendre Orion plus rapide, plus stable [et avec plus de capacités] sur les appareils Apple. Attendez-vous à des améliorations régulières dans les mois à venir ».

En mars 2026, Google a annoncé de profondes modifications pour le « sideloading » des applications sur Android. Le sideloading désigne la possibilité d’installer des applications en passant par d’autres moyens que le Play Store ou même les boutiques tierces. C’est une marque de fabrique d’Android jusqu’ici et un facteur de différenciation face à l’iPhone et son « jardin fortifié ».

Les annonces de Google n’enterraient pas le sideloading. En revanche, les règles allaient être bouleversées, et plusieurs sont entrées en vigueur le 30 septembre dans quatre pays : Brésil, Indonésie, Singapour et Thailande.

Sur les appareils encore supportés et disposant d’Android 7 ou d’une version ultérieure, les applications distribuées via les boutiques participantes doivent avoir un développeur vérifié. Traduction : une personne enregistrée auprès de Google, avec ses coordonnées et une preuve d’identité, généralement le scan d’une pièce d’identité officielle. C’est ce programme, Android Developer Verification, qui est entré en vigueur il y a quelques jours.

Si cette vérification est limitée à quatre pays, Google a annoncé que la généralisation aura lieu en 2027 pour l’ensemble des marchés. Le mécanisme de vérification n’appose pas seulement un badge de vérification, il lie l’identité du développeur à ses applications et ses clés de signature. Pour Google, c’est une question de traçabilité et de sécurité.

Quand la transition sera terminée, le sideloading deviendra nettement plus complexe. Quand vous souhaiterez installer une application récupérée depuis un site, sans passer par une boutique, il faudra en effet activer le mode Développeur dans les options de l’appareil.

Ensuite, après un redémarrage, Google réclamera un délai de 24 heures. Comment l’entreprise justifie-t-elle ce délai ? Par la nécessité de lutter contre les arnaques reposant sur l’ingénierie sociale et la pression en temps réel. Précisons que le délai n’intervient qu’une fois pour toutes les installations, pas pour chacune. En outre, ADB (Android Debug Bridge) reste en place pour les développeurs.

Si cette mesure casse en effet certains scénarios malveillants, elle risque d’avoir un impact lourd pour les boutiques non agréées et le sideloading en général, car la motivation peut vite disparaître devant une telle procédure. La liste initiale des boutiques agréées comprend le Play Store, le Galaxy Store, l’App Market d’HONOR, l’App Market d’OPPO, GetApps de Xiaomi, le V-Appstore de Vivo et le Palm Store de Transsion. Notons que la vérification des développeurs n’est pas forcément un gage de sécurité.

Ce changement fait partie d’un mouvement plus large de restrictions autour d’Android. Google semble en effet serrer la vis sur de nombreux aspects, plusieurs étant pointés du doigt par GrapheneOS, qui critique largement les changements intervenus dans la gestion des correctifs pour AOSP (Android Open Source Program).

En mars 2026, Google a annoncé de profondes modifications pour le « sideloading » des applications sur Android. Le sideloading désigne la possibilité d’installer des applications en passant par d’autres moyens que le Play Store ou même les boutiques tierces. C’est une marque de fabrique d’Android jusqu’ici et un facteur de différenciation face à l’iPhone et son « jardin fortifié ».

Les annonces de Google n’enterraient pas le sideloading. En revanche, les règles allaient être bouleversées, et plusieurs sont entrées en vigueur le 30 septembre dans quatre pays : Brésil, Indonésie, Singapour et Thailande.

Sur les appareils encore supportés et disposant d’Android 7 ou d’une version ultérieure, les applications distribuées via les boutiques participantes doivent avoir un développeur vérifié. Traduction : une personne enregistrée auprès de Google, avec ses coordonnées et une preuve d’identité, généralement le scan d’une pièce d’identité officielle. C’est ce programme, Android Developer Verification, qui est entré en vigueur il y a quelques jours.

Si cette vérification est limitée à quatre pays, Google a annoncé que la généralisation aura lieu en 2027 pour l’ensemble des marchés. Le mécanisme de vérification n’appose pas seulement un badge de vérification, il lie l’identité du développeur à ses applications et ses clés de signature. Pour Google, c’est une question de traçabilité et de sécurité.

Quand la transition sera terminée, le sideloading deviendra nettement plus complexe. Quand vous souhaiterez installer une application récupérée depuis un site, sans passer par une boutique, il faudra en effet activer le mode Développeur dans les options de l’appareil.

Ensuite, après un redémarrage, Google réclamera un délai de 24 heures. Comment l’entreprise justifie-t-elle ce délai ? Par la nécessité de lutter contre les arnaques reposant sur l’ingénierie sociale et la pression en temps réel. Précisons que le délai n’intervient qu’une fois pour toutes les installations, pas pour chacune. En outre, ADB (Android Debug Bridge) reste en place pour les développeurs.

Si cette mesure casse en effet certains scénarios malveillants, elle risque d’avoir un impact lourd pour les boutiques non agréées et le sideloading en général, car la motivation peut vite disparaître devant une telle procédure. La liste initiale des boutiques agréées comprend le Play Store, le Galaxy Store, l’App Market d’HONOR, l’App Market d’OPPO, GetApps de Xiaomi, le V-Appstore de Vivo et le Palm Store de Transsion. Notons que la vérification des développeurs n’est pas forcément un gage de sécurité.

Ce changement fait partie d’un mouvement plus large de restrictions autour d’Android. Google semble en effet serrer la vis sur de nombreux aspects, plusieurs étant pointés du doigt par GrapheneOS, qui critique largement les changements intervenus dans la gestion des correctifs pour AOSP (Android Open Source Program).

Quelque part en Pologne

Alors que l’obligation de facturation électronique est entrée en vigueur le 1ᵉʳ septembre, une première plateforme agréée annonce une fuite de données. Elle n’a pas été directement attaquée, la brèche venant d’un prestataire polonais. Le problème a cependant été assez sérieux pour que l’administration coupe temporairement ses échanges avec la plateforme.

Une plateforme agréée par l’État, VosFactures, a vu une partie des données de ses utilisateurs consultée après le piratage de son prestataire polonais Fakturownia. L’intrusion a été détectée le 27 septembre et l’accès a été coupé le 28. Le lendemain, la plateforme VosFactures a été avertie. Les 500 000 clients que revendique la plateforme ont alors commencé à être contactés.

• Facturation électronique : que faut-il savoir ?

Dans le courrier envoyé, affiché par FuitesInfos, on apprend qu’une « personne non autorisée » est parvenue à exploiter une vulnérabilité dans un mécanisme de génération de fichiers PDF à partir de modèles de factures. Cette exploitation a ensuite permis au pirate d’accéder à certains fichiers de configuration sur des serveurs du prestataire, dont des clés applicatives et des identifiants. À partir de ces informations, le pirate a réussi à déclencher des commandes arbitraires sur plusieurs serveurs applicatifs et à accéder à une copie miroir de la base de données de production.

Dans le courrier, VosFactures insiste sur plusieurs points, dont le fait que ses serveurs n’ont pas été directement attaqués. « Toutefois, certaines données relatives aux utilisateurs de VosFactures étaient traitées par ce prestataire dans le cadre de la fourniture de services techniques à FACTUALI SAS [l’opérateur de VosFactures, ndlr]. Une personne non autorisée a ainsi pu accéder à certaines données relatives aux comptes VosFactures, au clients et fournisseurs de nos utilisateurs ainsi qu’à une partie des documents générés au moyen du service », indique la plateforme dans ses e-mails.

L’entreprise rappelle également que sa propre infrastructure bénéficie de la qualification SecNumCloud de l’ANSSI, rappelant ses obligations en matière de protection des systèmes, de sécurité des données et de maitrise de leur hébergement. « À ce stade, aucun élément dont nous disposons ne révèle une compromission directe de l’environnement SecNumCloud propre à FACTUALI SAS », ajoute le courriel.

Une portée des risques encore floue

VosFactures prévient des risques habituels dans ce type de cas : les éternelles tentatives d’hameçonnage (phishing) par e-mail ou SMS, d’usurpation d’identité, de fraude au changement de coordonnées bancaires ou aux faux fournisseurs, d’accès non autorisé à d’autres services en cas de réutilisation du même mot de passe, ou encore de prise de contact frauduleuse en se faisant passer par VosFactures. Sans surprise, la plateforme recommande la plus grande prudence, avec les règles élémentaires d’hygiène numérique.

Selon FuitesInfos, l’entreprise a envoyé un deuxième e-mail pour avertir que l’ensemble des codes API fournis jusqu’à présent étaient invalidés au 1ᵉʳ octobre. Pour les clients concernés, cela signifie une rupture dans les intégrations, par exemple dans des logiciels de comptabilité. Il faut donc générer de nouveaux codes et mettre à jour les connexions concernées.

Fakturownia a également communiqué sur l’incident le 1ᵉʳ octobre, l’entreprise polonaise indiquant elle aussi avoir contacté ses clients, corrigé la faille et averti le Bureau de protection des données personnelles et le CERT polonais. Toutefois, les données dérobées sont beaucoup plus nombreuses chez le prestataire, avec notamment les mots de passe hachés, les numéros IBAN, le détail des factures ou encore les historiques des paiements. Les courriels de VosFactures étant peu précis sur ce point, nous avons contacté l’entreprise pour obtenir plus de détails et mettrons à jour cette actualité en cas de réponse.

Selon la presse polonaise, un pirate se faisant appeler Fingerprint a revendiqué l’attaque. Il dit être en possession d’une base de données de 6 To, mais ce chiffre n’a pas pu être vérifié.

Suspension temporaire des échanges avec l’AIFE

L’information a en tout cas fortement déplu à l’AIFE, l’Agence pour l’informatique financière de l’État. Sur son portail Chorus Pro (service de réception des factures fournisseurs pour les administrations publiques), on peut voir encore à l’heure actuelle un bandeau rouge. Il a été mis en place le 1ᵉʳ octobre pour avertir d’une suspension provisoire des échanges entre la plateforme agréée concernée et l’AIFE.

« À l’issue de l’examen des éléments techniques communiqués par la PA concernant cet incident, il apparaît que la situation opérationnelle des services de la PA et les mesures de sécurité prises ne justifient pas le maintien de la suspension. Les échanges entre la PA et les services opérés par l’AIFE ont donc été rétablis et restent naturellement sous surveillance comme pour l’ensemble des partenaires », indique cependant le bandeau, mis à jour pendant le week-end.

L’information tombe mal quoi qu’il en soit. L’arrivée de la facturation électronique ne s’est pas faite en douceur, de nombreuses petites entreprises se sentant lésées par ce passage forcé. L’obligation augmente mécaniquement la pression sur la sécurité des données puisque toute entreprise doit passer par l’une des plateformes agréées, dont la liste est fournie par le ministère de l’Économie et des Finances.

• Face à l’e-facturation, agriculteurs, petits commerçants et auto-entrepreneurs protestent

Quelque part en Pologne

Alors que l’obligation de facturation électronique est entrée en vigueur le 1ᵉʳ septembre, une première plateforme agréée annonce une fuite de données. Elle n’a pas été directement attaquée, la brèche venant d’un prestataire polonais. Le problème a cependant été assez sérieux pour que l’administration coupe temporairement ses échanges avec la plateforme.

Une plateforme agréée par l’État, VosFactures, a vu une partie des données de ses utilisateurs consultée après le piratage de son prestataire polonais Fakturownia. L’intrusion a été détectée le 27 septembre et l’accès a été coupé le 28. Le lendemain, la plateforme VosFactures a été avertie. Les 500 000 clients que revendique la plateforme ont alors commencé à être contactés.

• Facturation électronique : que faut-il savoir ?

Dans le courrier envoyé, affiché par FuitesInfos, on apprend qu’une « personne non autorisée » est parvenue à exploiter une vulnérabilité dans un mécanisme de génération de fichiers PDF à partir de modèles de factures. Cette exploitation a ensuite permis au pirate d’accéder à certains fichiers de configuration sur des serveurs du prestataire, dont des clés applicatives et des identifiants. À partir de ces informations, le pirate a réussi à déclencher des commandes arbitraires sur plusieurs serveurs applicatifs et à accéder à une copie miroir de la base de données de production.

Dans le courrier, VosFactures insiste sur plusieurs points, dont le fait que ses serveurs n’ont pas été directement attaqués. « Toutefois, certaines données relatives aux utilisateurs de VosFactures étaient traitées par ce prestataire dans le cadre de la fourniture de services techniques à FACTUALI SAS [l’opérateur de VosFactures, ndlr]. Une personne non autorisée a ainsi pu accéder à certaines données relatives aux comptes VosFactures, au clients et fournisseurs de nos utilisateurs ainsi qu’à une partie des documents générés au moyen du service », indique la plateforme dans ses e-mails.

L’entreprise rappelle également que sa propre infrastructure bénéficie de la qualification SecNumCloud de l’ANSSI, rappelant ses obligations en matière de protection des systèmes, de sécurité des données et de maitrise de leur hébergement. « À ce stade, aucun élément dont nous disposons ne révèle une compromission directe de l’environnement SecNumCloud propre à FACTUALI SAS », ajoute le courriel.

Une portée des risques encore floue

VosFactures prévient des risques habituels dans ce type de cas : les éternelles tentatives d’hameçonnage (phishing) par e-mail ou SMS, d’usurpation d’identité, de fraude au changement de coordonnées bancaires ou aux faux fournisseurs, d’accès non autorisé à d’autres services en cas de réutilisation du même mot de passe, ou encore de prise de contact frauduleuse en se faisant passer par VosFactures. Sans surprise, la plateforme recommande la plus grande prudence, avec les règles élémentaires d’hygiène numérique.

Selon FuitesInfos, l’entreprise a envoyé un deuxième e-mail pour avertir que l’ensemble des codes API fournis jusqu’à présent étaient invalidés au 1ᵉʳ octobre. Pour les clients concernés, cela signifie une rupture dans les intégrations, par exemple dans des logiciels de comptabilité. Il faut donc générer de nouveaux codes et mettre à jour les connexions concernées.

Fakturownia a également communiqué sur l’incident le 1ᵉʳ octobre, l’entreprise polonaise indiquant elle aussi avoir contacté ses clients, corrigé la faille et averti le Bureau de protection des données personnelles et le CERT polonais. Toutefois, les données dérobées sont beaucoup plus nombreuses chez le prestataire, avec notamment les mots de passe hachés, les numéros IBAN, le détail des factures ou encore les historiques des paiements. Les courriels de VosFactures étant peu précis sur ce point, nous avons contacté l’entreprise pour obtenir plus de détails et mettrons à jour cette actualité en cas de réponse.

Selon la presse polonaise, un pirate se faisant appeler Fingerprint a revendiqué l’attaque. Il dit être en possession d’une base de données de 6 To, mais ce chiffre n’a pas pu être vérifié.

Suspension temporaire des échanges avec l’AIFE

L’information a en tout cas fortement déplu à l’AIFE, l’Agence pour l’informatique financière de l’État. Sur son portail Chorus Pro (service de réception des factures fournisseurs pour les administrations publiques), on peut voir encore à l’heure actuelle un bandeau rouge. Il a été mis en place le 1ᵉʳ octobre pour avertir d’une suspension provisoire des échanges entre la plateforme agréée concernée et l’AIFE.

« À l’issue de l’examen des éléments techniques communiqués par la PA concernant cet incident, il apparaît que la situation opérationnelle des services de la PA et les mesures de sécurité prises ne justifient pas le maintien de la suspension. Les échanges entre la PA et les services opérés par l’AIFE ont donc été rétablis et restent naturellement sous surveillance comme pour l’ensemble des partenaires », indique cependant le bandeau, mis à jour pendant le week-end.

L’information tombe mal quoi qu’il en soit. L’arrivée de la facturation électronique ne s’est pas faite en douceur, de nombreuses petites entreprises se sentant lésées par ce passage forcé. L’obligation augmente mécaniquement la pression sur la sécurité des données puisque toute entreprise doit passer par l’une des plateformes agréées, dont la liste est fournie par le ministère de l’Économie et des Finances.

• Face à l’e-facturation, agriculteurs, petits commerçants et auto-entrepreneurs protestent

LDLC envoie actuellement des e-mails pour prévenir ses clients d’une nouvelle fuite de données. « Nous vous informons qu’un acte malveillant a permis un accès non autorisé à l’un de nos systèmes d’information, susceptible d’avoir entraîné la consultation de certaines données vous concernant », indique l’entreprise dans le courrier.

Les données concernées ? Pratiquement tout ce qu’il est possible d’avoir hors informations bancaires et de connexion : nom, prénom, adresse postale, adresse e-mail, fax, téléphone portable, téléphone fixe, langue du client, type de salutation (monsieur, madame…), codes clients techniques, type de client (particulier ou professionnel), date de dernière connexion sur le compte client web et date d’inscription sur le site.

« Vos données bancaires (RIB, numéro de carte), vos identifiants de connexion ou mots de passe n’ont pas été concernés », se dépêche d’ajouter LDLC. L’entreprise dit avoir immédiatement isolé la partie concernée de son infrastructure, révisé sa stratégie d’accès correspondante et notifié l’incident à la CNIL, « conformément à la réglementation applicable ».

Comme toujours dans ce genre de cas, les données dérobées « pourraient être utilisées pour des tentatives de fraude et de hameçonnage (phishing) », prévient LDLC. S’ensuivent plusieurs conseils, comme ne pas cliquer sur des liens reçus par SMS ou e-mail, ou ne jamais communiquer ses informations personnelles, identifiants et coordonnées bancaires par e-mail, SMS ou au téléphone. On fera remarquer, non sans ironie, qu’un nombre croissant d’entreprises s’en chargent pour nous.

Pour LDLC, c’est le quatrième incident de ce type depuis 2021. Cette année-là, l’entreprise annonçait avoir été attaquée par le groupe de pirates Ragnar Locker, qui avait mis en vente 29,5 Go de données internes. Puis 2024 avait marqué un doublé : d’abord le 29 février avec le vol des données de 1,5 million de clients, puis en décembre, sans savoir cette fois combien de personnes sont concernées.

LDLC envoie actuellement des e-mails pour prévenir ses clients d’une nouvelle fuite de données. « Nous vous informons qu’un acte malveillant a permis un accès non autorisé à l’un de nos systèmes d’information, susceptible d’avoir entraîné la consultation de certaines données vous concernant », indique l’entreprise dans le courrier.

Les données concernées ? Pratiquement tout ce qu’il est possible d’avoir hors informations bancaires et de connexion : nom, prénom, adresse postale, adresse e-mail, fax, téléphone portable, téléphone fixe, langue du client, type de salutation (monsieur, madame…), codes clients techniques, type de client (particulier ou professionnel), date de dernière connexion sur le compte client web et date d’inscription sur le site.

« Vos données bancaires (RIB, numéro de carte), vos identifiants de connexion ou mots de passe n’ont pas été concernés », se dépêche d’ajouter LDLC. L’entreprise dit avoir immédiatement isolé la partie concernée de son infrastructure, révisé sa stratégie d’accès correspondante et notifié l’incident à la CNIL, « conformément à la réglementation applicable ».

Comme toujours dans ce genre de cas, les données dérobées « pourraient être utilisées pour des tentatives de fraude et de hameçonnage (phishing) », prévient LDLC. S’ensuivent plusieurs conseils, comme ne pas cliquer sur des liens reçus par SMS ou e-mail, ou ne jamais communiquer ses informations personnelles, identifiants et coordonnées bancaires par e-mail, SMS ou au téléphone. On fera remarquer, non sans ironie, qu’un nombre croissant d’entreprises s’en chargent pour nous.

Pour LDLC, c’est le quatrième incident de ce type depuis 2021. Cette année-là, l’entreprise annonçait avoir été attaquée par le groupe de pirates Ragnar Locker, qui avait mis en vente 29,5 Go de données internes. Puis 2024 avait marqué un doublé : d’abord le 29 février avec le vol des données de 1,5 million de clients, puis en décembre, sans savoir cette fois combien de personnes sont concernées.

Rouille et préversions

La version finale d’Ubuntu 26.10 est désormais disponible. Canonical a fait quelques choix « audacieux » dans le choix des composants, avec notamment un noyau Linux 7.3 non finalisé.

Mise à jour du 15 octobre : la version finale d’Ubuntu 26.10 est maintenant disponible au téléchargement depuis le site officiel. Les variantes officielles (flavours) ne sont pas encore toutes passées à la nouvelle mouture, ce qui devrait être réglé dans les heures qui viennent.

On note l’apparition pour la première fois d’images ISO pour l’architecture RISC-V, à la fois pour la version classique d’Ubuntu et pour la variante Xubuntu (Xfce). Dans le premier cas, ces images sont encore uniquement accessibles depuis le dépôt Daily (compilations quotidiennes, non stable) , alors que dans le second l’image ISO stable est disponible.

Enfin, Canonical a indiqué que la prochaine version d’Ubuntu, la 27.04, sera nommée « Tenacious T-Rex ».

Article original du 2 octobre : Canonical avait prévenu que la bêta d’Ubuntu 26.10 serait en retard. Elle devait sortir initialement le 24 septembre, mais a été repoussée d’une semaine. Elle a bien été mise à disposition le 1ᵉʳ octobre, mais les personnes intéressées ont moins de deux semaines pour faire leurs tests, car la version finale est toujours prévue pour le 15 octobre. 

Cette première bêta concerne l’ensemble des éditions officielles de la distribution. C’est donc vrai pour les variantes Desktop, Server, WSL et Cloud, mais également pour Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, UbuntuKylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity et Xubuntu.

Comme nous l’indiquions récemment, Ubuntu 26.10 sera une version intermédiaire, donc non LTS (Long Term Support). Les personnes qui ont installé Ubuntu 26.04 ne l’auront donc pas, à moins de modifier le paramètre associé. Ces versions intermédiaires ont un support de neuf mois et sont faites pour être mises à jour tous les six mois. Les versions LTS, pour rappel, ne sont mises à jour que tous les deux ans.

• Ubuntu 24.04 LTS peut maintenant migrer vers la version 26.04

Comment ça, un noyau pas finalisé ?

Du boeuf et des patates

Le patron de SpaceXAI va participer à la création d’un important rapport prospectif sur les futurs visages de la guerre. Outre son retour officiel dans les sphères du pouvoir, plusieurs médias pointent les risques de conflits d’intérêt.

Le 30 septembre, le secrétaire américain à la Guerre, Pete Hegseth, a tenu un grand discours à la base des Marines de Quantico. Entre autres diatribes contre l’éternel « wokisme », se félicitant en particulier d’avoir sorti les « clowns idéologues » et d’avoir augmenté le nombre de tests de testostérone chez les soldats, il a évoqué une réduction de 20 % du nombre de généraux et amiraux. « Aujourd’hui, les médias parlent de purge. Moi, j’appelle cela rendre des comptes, et ça aurait dû être fait depuis longtemps », a-t-il déclaré, comme le relève Le Monde.

Le ministre était surtout venu annoncer six initiatives pour l’armée, dont plusieurs se distinguent par leur importance potentielle. C’est le cas notamment de l’Autonomous Warfare Command (Commandement de la guerre autonome).

Le communiqué le présente comme devant étendre la guerre autonome à l’ensemble des forces interarmées, sous la forme d’un « commandement de combat fonctionnel à quatre étoiles d’ici le 1ᵉʳ octobre 2027 ». Il s’appuie sur le programme Drone Dominance, qui aurait livré des milliers de systèmes robotisés au Moyen-Orient dans le cadre de l’opération Epic Fury.

De la bataille d’Azincourt à FORTRESS

Pour accoucher de ce commandement, une structure de transition chargée de préparer le terrain est mise en place, sous le nom de « Project Agincourt ». Agincourt, qui se traduit en français par Azincourt, est le nom d’une célèbre bataille de la Guerre de Cent Ans (en 1415), au cours de laquelle la chevalerie française fut écrasée par les Anglais et leurs redoutables arcs longs.

Le nom ne fait pas tant référence à la défaite française en elle-même qu’à la possibilité d’employer une arme bon marché en masse, qui l’emporte alors sur une force plus coûteuse et plus « prestigieuse ». Le projet a été confié au DRPM-UxS (Direct Reporting Portfolio Manager for Unmanned Systems), un poste créé trois mois plus tôt pour regrouper les activités du ministère de la Guerre dans le domaine des systèmes non habités.

Autre initiative importante, FORTRESS, pour « Federal Operations for Resilience, Troop Resources, Energy, Supply, and Survivability ». À terme, chaque grande installation militaire américaine produirait ainsi sa propre électricité de façon autonome, pour continuer à fonctionner si le réseau civil tombe à la suite d’une cyberattaque ou d’un sabotage.

Cette initiative prévoit aussi de relocaliser les chaînes d’approvisionnement critiques : terres rares, métaux spéciaux, semi-conducteurs et ergols. Elle comprend également la constitution de réserves stratégiques de munitions, de carburant, de médicaments et de sang. Enfin, elle couvre le durcissement des installations contre les intrusions informatiques, le sabotage et les drones, ainsi que la protection des satellites et du spectre radioélectrique.

Meridian et le « retour » d’Elon Musk

Outre la création d’une nouvelle grande base sur le sol national ou encore celle d’un « Bureau des affaires religieuses », on remarque sous le projet Meridian. Il s’agit d’une étude prospective qui doit couvrir tous les domaines de combat futurs, des profondeurs souterraines à l’espace cislunaire. Cette mission doit aboutir sous 120 jours à un rapport public non classifié, mais accompagné d’une annexe classifiée. L’échéance est fixée au 28 janvier 2027 par le mémorandum, qui prévoit que le projet soit commandé par l’intermédiaire d’une organisation partenaire (aucun nom n’a été donné).

Si le projet Meridian fait couler de l’encre, ce n’est pas tellement parce qu’il sera piloté par Emil Michael, directeur technique du ministère de la Guerre, mais parce qu’il y associe Elon Musk, Palmer Luckey et Newt Gingrich. Beaucoup y voient un retour du patron de SpaceXAI dans le giron de la Maison-Blanche, même s’il faut nuancer le propos. Dans le cadre de Meridian, son rôle relève du Pentagone, il ne revient pas dans l’exécutif présidentiel, comme c’était le cas quand il pilotait le DOGE. En outre, la mission est bornée dans le temps et limitée à un rapport.

Selon le magazine Time, le processus de réconciliation avec Donald Trump aurait commencé en décembre 2025 lors d’une « réunion clandestine » à la Maison-Blanche. Le président aurait passé plusieurs heures à tester Grok, le chatbot IA de SpaceXAI. Il aurait notamment demandé comment les Vénézuéliens réagiraient si les États-Unis capturaient Maduro, alors au pouvoir. Grok aurait caractérisé ce dernier de « dictateur répressif et profondément impopulaire », ce qui aurait aidé Donald Trump à décider sa capture le mois suivant.

En revanche, la question des conflits d’intérêts bat son plein. Axios rappelle par exemple que les entreprises d’Elon Musk et de Palmer Luckey détiennent d’importants contrats avec le Pentagone. SpaceXAI assure ainsi l’essentiel des lancements liés à la sécurité nationale, tandis qu’Anduril fournit brouilleurs, intercepteurs, moteurs de roquette et drones d’accompagnement. Même Fox News, pourtant favorable à l’administration, relève que des dirigeants d’entreprises en concurrence pour des marchés de défense vont aider à définir les capacités que l’armée devrait acquérir.

Du boeuf et des patates

Le patron de SpaceXAI va participer à la création d’un important rapport prospectif sur les futurs visages de la guerre. Outre son retour officiel dans les sphères du pouvoir, plusieurs médias pointent les risques de conflits d’intérêt.

Le 30 septembre, le secrétaire américain à la Guerre, Pete Hegseth, a tenu un grand discours à la base des Marines de Quantico. Entre autres diatribes contre l’éternel « wokisme », se félicitant en particulier d’avoir sorti les « clowns idéologues » et d’avoir augmenté le nombre de tests de testostérone chez les soldats, il a évoqué une réduction de 20 % du nombre de généraux et amiraux. « Aujourd’hui, les médias parlent de purge. Moi, j’appelle cela rendre des comptes, et ça aurait dû être fait depuis longtemps », a-t-il déclaré, comme le relève Le Monde.

Le ministre était surtout venu annoncer six initiatives pour l’armée, dont plusieurs se distinguent par leur importance potentielle. C’est le cas notamment de l’Autonomous Warfare Command (Commandement de la guerre autonome).

Le communiqué le présente comme devant étendre la guerre autonome à l’ensemble des forces interarmées, sous la forme d’un « commandement de combat fonctionnel à quatre étoiles d’ici le 1ᵉʳ octobre 2027 ». Il s’appuie sur le programme Drone Dominance, qui aurait livré des milliers de systèmes robotisés au Moyen-Orient dans le cadre de l’opération Epic Fury.

De la bataille d’Azincourt à FORTRESS

Pour accoucher de ce commandement, une structure de transition chargée de préparer le terrain est mise en place, sous le nom de « Project Agincourt ». Agincourt, qui se traduit en français par Azincourt, est le nom d’une célèbre bataille de la Guerre de Cent Ans (en 1415), au cours de laquelle la chevalerie française fut écrasée par les Anglais et leurs redoutables arcs longs.

Le nom ne fait pas tant référence à la défaite française en elle-même qu’à la possibilité d’employer une arme bon marché en masse, qui l’emporte alors sur une force plus coûteuse et plus « prestigieuse ». Le projet a été confié au DRPM-UxS (Direct Reporting Portfolio Manager for Unmanned Systems), un poste créé trois mois plus tôt pour regrouper les activités du ministère de la Guerre dans le domaine des systèmes non habités.

Autre initiative importante, FORTRESS, pour « Federal Operations for Resilience, Troop Resources, Energy, Supply, and Survivability ». À terme, chaque grande installation militaire américaine produirait ainsi sa propre électricité de façon autonome, pour continuer à fonctionner si le réseau civil tombe à la suite d’une cyberattaque ou d’un sabotage.

Cette initiative prévoit aussi de relocaliser les chaînes d’approvisionnement critiques : terres rares, métaux spéciaux, semi-conducteurs et ergols. Elle comprend également la constitution de réserves stratégiques de munitions, de carburant, de médicaments et de sang. Enfin, elle couvre le durcissement des installations contre les intrusions informatiques, le sabotage et les drones, ainsi que la protection des satellites et du spectre radioélectrique.

Meridian et le « retour » d’Elon Musk

Outre la création d’une nouvelle grande base sur le sol national ou encore celle d’un « Bureau des affaires religieuses », on remarque sous le projet Meridian. Il s’agit d’une étude prospective qui doit couvrir tous les domaines de combat futurs, des profondeurs souterraines à l’espace cislunaire. Cette mission doit aboutir sous 120 jours à un rapport public non classifié, mais accompagné d’une annexe classifiée. L’échéance est fixée au 28 janvier 2027 par le mémorandum, qui prévoit que le projet soit commandé par l’intermédiaire d’une organisation partenaire (aucun nom n’a été donné).

Si le projet Meridian fait couler de l’encre, ce n’est pas tellement parce qu’il sera piloté par Emil Michael, directeur technique du ministère de la Guerre, mais parce qu’il y associe Elon Musk, Palmer Luckey et Newt Gingrich. Beaucoup y voient un retour du patron de SpaceXAI dans le giron de la Maison-Blanche, même s’il faut nuancer le propos. Dans le cadre de Meridian, son rôle relève du Pentagone, il ne revient pas dans l’exécutif présidentiel, comme c’était le cas quand il pilotait le DOGE. En outre, la mission est bornée dans le temps et limitée à un rapport.

Selon le magazine Time, le processus de réconciliation avec Donald Trump aurait commencé en décembre 2025 lors d’une « réunion clandestine » à la Maison-Blanche. Le président aurait passé plusieurs heures à tester Grok, le chatbot IA de SpaceXAI. Il aurait notamment demandé comment les Vénézuéliens réagiraient si les États-Unis capturaient Maduro, alors au pouvoir. Grok aurait caractérisé ce dernier de « dictateur répressif et profondément impopulaire », ce qui aurait aidé Donald Trump à décider sa capture le mois suivant.

En revanche, la question des conflits d’intérêts bat son plein. Axios rappelle par exemple que les entreprises d’Elon Musk et de Palmer Luckey détiennent d’importants contrats avec le Pentagone. SpaceXAI assure ainsi l’essentiel des lancements liés à la sécurité nationale, tandis qu’Anduril fournit brouilleurs, intercepteurs, moteurs de roquette et drones d’accompagnement. Même Fox News, pourtant favorable à l’administration, relève que des dirigeants d’entreprises en concurrence pour des marchés de défense vont aider à définir les capacités que l’armée devrait acquérir.

Il y a du travail

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.

• L’Éducation nationale s’est encore fait pirater, un nombre important d’agents concernés
• Le piratage du ministère de l’Intérieur : un coup de bol opportuniste, et même pas ciblé
• Troisième fuite confirmée aux impôts, Bercy détaille sa réponse aux attaques

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 ».

Il y a du travail

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.

• L’Éducation nationale s’est encore fait pirater, un nombre important d’agents concernés
• Le piratage du ministère de l’Intérieur : un coup de bol opportuniste, et même pas ciblé
• Troisième fuite confirmée aux impôts, Bercy détaille sa réponse aux attaques

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 ».

Le correctif était pourtant là

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.

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

Le correctif était pourtant là

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.

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

Compose viendra, promis

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.

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.

Compose viendra, promis

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.

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.

Ce 29 septembre, Canonical a officiellement ouvert la mise à niveau directe d’Ubuntu 24.04 LTS (Noble Numbat) vers Ubuntu 26.04.1 LTS (Resolute Raccoon). L’information peut surprendre, Ubuntu 26.04 ayant près de six mois déjà. Pourtant, ce chemin de migration n’a en réalité qu’un mois de retard sur le calendrier habituel.

Pour rappel, les versions printanières sortant les années paires comme 24.04 et 26.04 sont étiquetées LTS, pour Long Term Support. Chez Canonical, cela signifie un support de cinq ans, extensible via l’offre Ubuntu Pro. Par défaut, ces versions ne se mettent pas à jour vers les versions intérimaires (c’est-à-dire autres que LTS). Si l’on ne touche à rien, les seules évolutions possibles sont vers les nouvelles LTS.

Souvent, les personnes choisissant ces versions privilégient la stabilité au détriment des nouveautés. En entreprise ou dans d’autres organisations, Ubuntu peut par exemple être utilisé sur des appareils de production, des serveurs, etc. Le choix de migration est donc prudent : le chemin ne s’ouvre qu’une fois que Canonical s’est assuré que les principaux problèmes ont été réglés.

Dans une annonce, Canonical indique que le chemin de migration commence à être ouvert. L’entreprise y explique que la version 26.04.1 va être proposée dans les jours qui viennent à l’ensemble des ordinateurs équipés de 24.04, via le gestionnaire de mises à jour. Le déploiement étant progressif, la notification peut ne pas apparaître tout de suite.

Signalons quand même plusieurs éléments. D’une part, rien n’oblige à installer cette nouvelle version, qui peut être refusée : Ubuntu 24.04 est supportée jusqu’en 2029, ou 2034 avec Ubuntu Pro. D’autre part, les personnes qui n’ont pas envie d’attendre la notification peuvent lancer la commande « do-release-upgrade » dans le terminal. Enfin, la migration ne peut se faire que si toutes les mises à jour en attente sont installées, que ce soit dans le gestionnaire graphique ou en ligne de commande avec apt.

En outre, attention à la migration, car ce type d’installation n’est jamais anodin. Canonical souligne plusieurs points de vigilance, dont la fin de la session GNOME sous Xorg. Le serveur graphique n’est ainsi pas supprimé, mais l’option disparait de l’écran de connexion. La session par défaut repose sur Wayland, les applications X11 passant par XWayland depuis Ubuntu 25.10. En revanche, Xfce, LXQt, Cinnamon et MATE prennent toujours en charge Xorg. Autre point de vigilance, la quantité de mémoire recommandée : 6 Go, contre 4 Go pour Ubuntu 24.04. L’installation n’est pas bloquée sur une machine avec 4 Go de mémoire, mais l’ensemble fonctionnera sans doute moins bien.

Rappelons qu’Ubuntu 26.10 arrivera le 15 octobre. Pour les personnes utilisant Ubuntu 26.04 (ou 24.04 et sur le point de migrer), la situation est celle que nous décrivions : cette mise à jour ne vous sera pas proposée. Pour recevoir cette mise à jour, il faudra soit avoir déjà une version intérimaire (semestrielle), soit avoir une version LTS configurée pour les recevoir. Si vous voulez changer ce réglage sur Ubuntu 26.04 par exemple, il faut vous rendre l’application « Logiciels et mises à jour », dans l’onglet « Mises à jour ». Dans le champ « Me notifier des nouvelles versions d’Ubuntu » choisissez alors « Pour toute nouvelle version ».

• Ubuntu 26.10 : du retard pour la bêta et un « snapping » à la Windows 11