Pour Canonical, l’intelligence artificielle se répartit en deux grandes catégories : l’IA implicite, qui améliore discrètement des fonctions existantes, et l’IA explicite, qui correspond à des fonctions que l’on appelle en toute connaissance de cause. Dans notre article du 8 juin, nous évoquions quelques exemples d’IA implicite donnés, comme l’amélioration de l’autofocus pour la webcam ou la qualité du son sur le micro. Ces opérations pourraient être réalisées assez simplement depuis un modèle local.

La seule fonction d’IA explicite prévue était alors une dictée vocale à l’échelle de tout le système. Le 17 juin, Canonical a précisé dans un billet son projet, nommé Myna : « une nouvelle initiative visant à introduire la dictée vocale sur Ubuntu Desktop. Nommé d’après le myna [mainate religieux en français, ndlr], connu pour sa capacité à imiter la parole humaine, le projet vise à offrir une expérience de dictée qui ressemble naturellement à un ordinateur de bureau tout en respectant la confidentialité des utilisateurs et fonctionnant entièrement sur du matériel local ».

L’éditeur confirme l’arrivée de cette fonction dans Ubuntu 26.10, qui arrivera en octobre. Il s’agira d’une première version, au fonctionnement simple : en appuyant sur une touche, on déclenchera l’écoute et le texte s’affichera dans le champ texte de l’application utilisée. Cette première version visera Ubuntu Desktop sous Wayland avec GNOME. Canonical ajoute que l’architecture sera « suffisamment ouverte pour supporter d’autres environnements de bureau à l’avenir ».

Canonical affirme que la fonction est pensée dès la conception pour la confidentialité. Elle ne fonctionnera qu’en local, sans besoin d’une connexion internet. L’accès au microphone ne se fera qu’avec l’activation explicite du raccourci clavier. Quant à l’audio récupéré, il est effacé de la mémoire après avoir été traité et rien n’est envoyé sur des serveurs.

Ubuntu dit chercher des retours sur cette fonction. Un dépôt GitHub a été ouvert pour l’occasion, mais on ne trouve pour l’instant qu’un peu de documentation.

Pour Canonical, l’intelligence artificielle se répartit en deux grandes catégories : l’IA implicite, qui améliore discrètement des fonctions existantes, et l’IA explicite, qui correspond à des fonctions que l’on appelle en toute connaissance de cause. Dans notre article du 8 juin, nous évoquions quelques exemples d’IA implicite donnés, comme l’amélioration de l’autofocus pour la webcam ou la qualité du son sur le micro. Ces opérations pourraient être réalisées assez simplement depuis un modèle local.

La seule fonction d’IA explicite prévue était alors une dictée vocale à l’échelle de tout le système. Le 17 juin, Canonical a précisé dans un billet son projet, nommé Myna : « une nouvelle initiative visant à introduire la dictée vocale sur Ubuntu Desktop. Nommé d’après le myna [mainate religieux en français, ndlr], connu pour sa capacité à imiter la parole humaine, le projet vise à offrir une expérience de dictée qui ressemble naturellement à un ordinateur de bureau tout en respectant la confidentialité des utilisateurs et fonctionnant entièrement sur du matériel local ».

L’éditeur confirme l’arrivée de cette fonction dans Ubuntu 26.10, qui arrivera en octobre. Il s’agira d’une première version, au fonctionnement simple : en appuyant sur une touche, on déclenchera l’écoute et le texte s’affichera dans le champ texte de l’application utilisée. Cette première version visera Ubuntu Desktop sous Wayland avec GNOME. Canonical ajoute que l’architecture sera « suffisamment ouverte pour supporter d’autres environnements de bureau à l’avenir ».

Canonical affirme que la fonction est pensée dès la conception pour la confidentialité. Elle ne fonctionnera qu’en local, sans besoin d’une connexion internet. L’accès au microphone ne se fera qu’avec l’activation explicite du raccourci clavier. Quant à l’audio récupéré, il est effacé de la mémoire après avoir été traité et rien n’est envoyé sur des serveurs.

Ubuntu dit chercher des retours sur cette fonction. Un dépôt GitHub a été ouvert pour l’occasion, mais on ne trouve pour l’instant qu’un peu de documentation.

Sans foi sur le métier

Il y a une semaine, une importante campagne d’attaque a été détectée contre les pare-feux Fortinet. 80 000 mots de passe ont été récupérés par des pirates, ce qui représenterait la moitié environ des pare-feux Fortinet exposés à Internet.

L’attaque a été découverte par le chercheur Volodymyr Diachenko (souvent appelé Bob). Dans une publication LinkedIn le 15 juin, il avertit qu’une « campagne massive de force brute/exploitation » a été découverte en pleine action sur des pare-feux Fortinet. Il évoque alors 21 634 noms de domaine uniques, liés à des entreprises allant de Chevron à Fortinet elle-même. Les mots de passe ont été obtenus par craquage du hachage, puis utilisés pour obtenir des données et la prise de contrôle de réseaux internes.

Selon les chercheurs de SOCRadar, le mode opératoire et les traces laissées sont à rapprocher des acteurs malveillants russes. L’attaque est décrite comme particulièrement sophistiquée, ayant abouti à un lot de données comprenant à la fois des mots de passe et des identifiants SSL VPN depuis des fichiers de configuration compromis.

Toujours selon SOCRadar, les équipements attaqués étaient répartis dans 194 pays. Les plus touchés sont l’Inde, les États-Unis et le Mexique, avec près de 12 000 identifiants compromis entre eux. La France est présente dans la liste avec 1 116 identifiants.

La répartition par type de « credentials » révèle une prédominance de comptes organisationnels, pointant vers un ciblage délibéré des entreprises. Foxconn, Samsung, Comcast, Siemens, Lenovo, PwC, Accenture et Oracle, ainsi que de nombreuses entités gouvernementales et opérateurs d’infrastructures critiques ont été touchés. Un contractant turc de l’OTAN figure également parmi les cibles.

Convergence de défaillances

Si l’attaque a été nommée FortiBleed, le cas n’a rien à voir avec Heartbleed : il s’agit bien d’une campagne industrielle de vol et d’utilisation d’identifiants. À la racine de l’attaque, il n’y a pas une faille unique et cataclysmique, mais une série de défaillances en lien avec l’hygiène numérique.

Selon le chercheur Kevin Beaumont dans un billet du 18 juin, les pirates ont commencé par scanner internet à la recherche d’instances Fortinet dont l’interface de gestion FortiGate était accessible publiquement. Ils se sont ensuite intéressés à celles présentant un profil spécifique.

Dans les versions 7.2.11, 7.4.8 et 7.6.1 de FortiOS, le système d’exploitation équipant ses pare-feux, Fortinet a en effet introduit la fonction de hachage PBKDF2 pour les identifiants administrateurs, pour remplacer l’ancien SHA-256. Cependant, lors d’une mise à jour depuis des versions antérieures, les mots de passe existants restent stockés en SHA-256 jusqu’à ce que l’administrateur se reconnecte après l’opération. De nombreuses organisations ont donc appliqué une nouvelle version sans déclencher de nouveau hachage : leurs firewalls, pourtant mis à jour, demeuraient vulnérables.

Les moyens des ambitions

Les pirates ne se sont pas lancés non plus à l’aveuglette. Ils ont opéré sur la base d’identifiants déjà obtenus par plusieurs sources : la fuite Fortinet de 2021 portant sur environ 500 000 comptes FortiGate VPN, les données obtenues après une faille 0-day en 2022, ou encore d’autres bases existantes. Les mots de passe testés n’étant donc pas aléatoires : ils avaient déjà fonctionné par le passé sur des appareils Fortinet.

L’ampleur de l’attaque est connue, car les chercheurs ont pu remonter jusqu’aux pirates russes, car leur serveur était lui-même exposé publiquement. Les journaux récupérés indiquaient environ 1,16 milliard de tentatives d’identification contre 320 777 cibles FortiGate, ainsi que 2,1 milliards de tentatives supplémentaires contre plus de 163 650 serveurs Microsoft SQL Server, indique le site InfoStealers. Le groupe interceptait les hachages d’authentification SSL VPN et les crackait sur un cluster dédié de 45 GPU géré via Hashtopolis, selon Kevin Beaumont.

Au moins une faille existante pourrait avoir été utilisée : la vulnérabilité CVE-2026-24858, qui permet un contournement d’authentification SAML SSO FortiCloud et est classée comme critique, avec un score CVSS de 9,8 sur 10, comme l’indique RansomNews. Elle a été révélée en janvier et est déjà corrigée, mais des appareils ont pu passer à côté du correctif. Du côté de SOCRadar, on note que deux autres failles ont été activement exploitées pendant cette période, CVE-2026-21643 et CVE-2026-35616. Elles concernent FortiClient EMS, mais le lien avec FortiBleed n’est pas confirmé. Aucune faille 0-day ne semble avoir été utilisée.

Pour Fortinet, tout n’est qu’un recyclage d’anciennes fuites

Les recommandations sont claires :

• réinitialiser immédiatement tous les mots de passe administrateurs et VPN (notamment pour les appareils exposés sur Internet)
• activer l’authentification multifacteur sur tous les comptes d’accès administrateurs et distants
• restreindre l’accès à l’interface de gestion aux réseaux internes de confiance
• mettre à jour FortiOS vers une version supportant PBKDF2 et s’assurer que chaque administrateur se reconnecte ensuite pour déclencher un nouveau hachage

Pour Fortinet, il ne s’agit que d’une exploitation d’anciennes bases de données. « D’après notre analyse, les données impliquées sont un mélange de données d’incidents précédents, ainsi qu’un [cracking par] force brute des identifiants, et ne sont pas liées à un incident récent ni à un avertissement. Les organisations qui suivent les meilleures pratiques, y compris la mise à jour régulière des identifiants de sécurité […] courent un risque minimal lié aux détails de compromission des identifiants mentionnés dans les rapports », a déclaré l’entreprise à TechRadar le 18 juin. Elle ajoutait cependant que l’enquête continuait et que la sécurité de ses clients restait sa priorité.

Kevin Beaumont relativise ces déclarations, précisant que les fuites contiennent des données plus récentes.

Sans foi sur le métier

Il y a une semaine, une importante campagne d’attaque a été détectée contre les pare-feux Fortinet. 80 000 mots de passe ont été récupérés par des pirates, ce qui représenterait la moitié environ des pare-feux Fortinet exposés à Internet.

L’attaque a été découverte par le chercheur Volodymyr Diachenko (souvent appelé Bob). Dans une publication LinkedIn le 15 juin, il avertit qu’une « campagne massive de force brute/exploitation » a été découverte en pleine action sur des pare-feux Fortinet. Il évoque alors 21 634 noms de domaine uniques, liés à des entreprises allant de Chevron à Fortinet elle-même. Les mots de passe ont été obtenus par craquage du hachage, puis utilisés pour obtenir des données et la prise de contrôle de réseaux internes.

Selon les chercheurs de SOCRadar, le mode opératoire et les traces laissées sont à rapprocher des acteurs malveillants russes. L’attaque est décrite comme particulièrement sophistiquée, ayant abouti à un lot de données comprenant à la fois des mots de passe et des identifiants SSL VPN depuis des fichiers de configuration compromis.

Toujours selon SOCRadar, les équipements attaqués étaient répartis dans 194 pays. Les plus touchés sont l’Inde, les États-Unis et le Mexique, avec près de 12 000 identifiants compromis entre eux. La France est présente dans la liste avec 1 116 identifiants.

La répartition par type de « credentials » révèle une prédominance de comptes organisationnels, pointant vers un ciblage délibéré des entreprises. Foxconn, Samsung, Comcast, Siemens, Lenovo, PwC, Accenture et Oracle, ainsi que de nombreuses entités gouvernementales et opérateurs d’infrastructures critiques ont été touchés. Un contractant turc de l’OTAN figure également parmi les cibles.

Convergence de défaillances

Si l’attaque a été nommée FortiBleed, le cas n’a rien à voir avec Heartbleed : il s’agit bien d’une campagne industrielle de vol et d’utilisation d’identifiants. À la racine de l’attaque, il n’y a pas une faille unique et cataclysmique, mais une série de défaillances en lien avec l’hygiène numérique.

Selon le chercheur Kevin Beaumont dans un billet du 18 juin, les pirates ont commencé par scanner internet à la recherche d’instances Fortinet dont l’interface de gestion FortiGate était accessible publiquement. Ils se sont ensuite intéressés à celles présentant un profil spécifique.

Dans les versions 7.2.11, 7.4.8 et 7.6.1 de FortiOS, le système d’exploitation équipant ses pare-feux, Fortinet a en effet introduit la fonction de hachage PBKDF2 pour les identifiants administrateurs, pour remplacer l’ancien SHA-256. Cependant, lors d’une mise à jour depuis des versions antérieures, les mots de passe existants restent stockés en SHA-256 jusqu’à ce que l’administrateur se reconnecte après l’opération. De nombreuses organisations ont donc appliqué une nouvelle version sans déclencher de nouveau hachage : leurs firewalls, pourtant mis à jour, demeuraient vulnérables.

Les moyens des ambitions

Les pirates ne se sont pas lancés non plus à l’aveuglette. Ils ont opéré sur la base d’identifiants déjà obtenus par plusieurs sources : la fuite Fortinet de 2021 portant sur environ 500 000 comptes FortiGate VPN, les données obtenues après une faille 0-day en 2022, ou encore d’autres bases existantes. Les mots de passe testés n’étant donc pas aléatoires : ils avaient déjà fonctionné par le passé sur des appareils Fortinet.

L’ampleur de l’attaque est connue, car les chercheurs ont pu remonter jusqu’aux pirates russes, car leur serveur était lui-même exposé publiquement. Les journaux récupérés indiquaient environ 1,16 milliard de tentatives d’identification contre 320 777 cibles FortiGate, ainsi que 2,1 milliards de tentatives supplémentaires contre plus de 163 650 serveurs Microsoft SQL Server, indique le site InfoStealers. Le groupe interceptait les hachages d’authentification SSL VPN et les crackait sur un cluster dédié de 45 GPU géré via Hashtopolis, selon Kevin Beaumont.

Au moins une faille existante pourrait avoir été utilisée : la vulnérabilité CVE-2026-24858, qui permet un contournement d’authentification SAML SSO FortiCloud et est classée comme critique, avec un score CVSS de 9,8 sur 10, comme l’indique RansomNews. Elle a été révélée en janvier et est déjà corrigée, mais des appareils ont pu passer à côté du correctif. Du côté de SOCRadar, on note que deux autres failles ont été activement exploitées pendant cette période, CVE-2026-21643 et CVE-2026-35616. Elles concernent FortiClient EMS, mais le lien avec FortiBleed n’est pas confirmé. Aucune faille 0-day ne semble avoir été utilisée.

Pour Fortinet, tout n’est qu’un recyclage d’anciennes fuites

Les recommandations sont claires :

• réinitialiser immédiatement tous les mots de passe administrateurs et VPN (notamment pour les appareils exposés sur Internet)
• activer l’authentification multifacteur sur tous les comptes d’accès administrateurs et distants
• restreindre l’accès à l’interface de gestion aux réseaux internes de confiance
• mettre à jour FortiOS vers une version supportant PBKDF2 et s’assurer que chaque administrateur se reconnecte ensuite pour déclencher un nouveau hachage

Pour Fortinet, il ne s’agit que d’une exploitation d’anciennes bases de données. « D’après notre analyse, les données impliquées sont un mélange de données d’incidents précédents, ainsi qu’un [cracking par] force brute des identifiants, et ne sont pas liées à un incident récent ni à un avertissement. Les organisations qui suivent les meilleures pratiques, y compris la mise à jour régulière des identifiants de sécurité […] courent un risque minimal lié aux détails de compromission des identifiants mentionnés dans les rapports », a déclaré l’entreprise à TechRadar le 18 juin. Elle ajoutait cependant que l’enquête continuait et que la sécurité de ses clients restait sa priorité.

Kevin Beaumont relativise ces déclarations, précisant que les fuites contiennent des données plus récentes.

Bain d'huile

WhatsApp est la messagerie instantanée la plus utilisée au monde après Messenger, les deux appartenant à Meta. Le service possède plusieurs applications, dont deux « desktop » pour Windows et macOS. La différence de traitement est pourtant énorme.

L’histoire de la version Windows du client WhatsApp se découpe en trois phases :

• Jusqu’en 2023 : la première version, essentiellement le service web encapsulé dans une application Electron, qui embarquait également tout le moteur Chromium pour le rendu
• De fin 2022 à 2025 : nouvelle version, native et utilisant UWP (Universal Windows Platform). Particulièrement légère et rapide
• Depuis 2025 : version en date, basée sur WebView2, donc retour à une encapsulation web

Depuis cette dernière mouture, les critiques n’ont pas manqué. Alors que la version native était célébrée pour ses performances, la nouvelle retourne à un rendu web, avec la consommation des ressources qui l’accompagnent.

Pluie de critiques

Si le grand public se « déplace » rarement pour commenter les applications du quotidien, il en va autrement de la presse spécialisée. Windows Latest s’est largement étendu sur le sujet dès novembre 2025, critiquant l’appétit vorace en ressources : 300 Mo de mémoire sur l’écran de connexion, en moyenne 1,2 Go en discutant, et jusqu’à 2 voire 3 Go en utilisation intensive. Nous avons nous-mêmes constaté que l’application pouvait dépasser ces 3 Go, notamment quand on ouvre le panneau des médias échangés dans une longue conversation. Dans ce cas, il n’est pas rare que l’occupation CPU grimpe en flèche, entrainant des ralentissements sur le reste du système.

Fin mai, IntraBlog publiait un billet allant dans le même sens, notant ici encore la forte consommation des ressources. Le site signalait également la multiplication des processus en arrière-plan, un manque fréquent de réactivité et des problèmes de fiabilité, particulièrement dans la synchronisation. Même chose chez Digital Trends, où la critique était sévère fin avril. Même John Grubber, habitué des informations Apple sur son blog Daring Fireball, n’hésitait pas à dire fin 2025 que la nouvelle application était « merdique ».

Sur Reddit, même combat. Les plaintes sont nombreuses, la plupart soulignant la consommation excessive de ressources et la lenteur générale. Plusieurs affirment avoir basculé sur la version web, la mouture desktop n’apportant plus rien. D’autres évoquent des problèmes fréquents de déconnexion, et d’autres encore recommandent d’ouvrir la version web et de passer par l’installation d’application web de Chrome (ou d’un autre navigateur Chromium).

Silence de Meta et pression de Microsoft

On peut comprendre pourquoi Meta s’est orientée vers ces technologies. L’utilisation d’une version web réclame moins de ressources de développement, puisqu’il s’agit dans les grandes lignes de reprendre l’existant. Contrairement à la première version qui utilisait Electron, la dernière se sert de WebView2, une vue web dérivée d’Edge. Techniquement, cette application devrait donc être plus légère, notamment car il n’est plus nécessaire d’embarquer tout le moteur Chromium. En pratique, le client WhatsApp semble renvoyer plusieurs années dans le passé.

Interrogée par plusieurs médias sur le sujet, Meta n’a pourtant jamais répondu. En novembre 2025, certains y voyaient d’ailleurs le signe d’une bascule : l’âge du code natif était-il révolu ?

Pourtant, si le sujet refait intensément parler aujourd’hui, c’est parce que Microsoft semble avoir changé complètement de braquet. À la dernière conférence Build, l’éditeur a largement appuyé sur le code natif et l’utilisation de son framework WinUI. Une équipe est actuellement chargée de développer de nouvelles applications internes, dont le code a été confirmé comme natif. Des éléments actuellement en React Native, dont le menu Démarrer, vont également être réécrits en code natif.

• Vers des applications natives et un menu contextuel personnalisable pour Windows 11

Concrètement, pour les développeurs tiers, le message de Microsoft a été inhabituellement direct : WinUI n’est pas une expérience en attente d’être remplacée, ni un pont technologique avant la prochaine grande unification : c’est désormais la plateforme de production native pour les apps Windows modernes. L’entreprise en est même jusqu’à parler de « web app slop ».

Cette nouvelle insistance de Microsoft et la pression des utilisateurs seront-elles suffisantes pour faire changer d’avis Meta ? Pour l’instant, WhatsApp reste en zone grise. Mais il est probable que cette version WebView2 ait été conçue pour des questions de coûts. En attendant, la version Mac reste native, avec des performances sans commune mesure.

Bain d'huile

WhatsApp est la messagerie instantanée la plus utilisée au monde après Messenger, les deux appartenant à Meta. Le service possède plusieurs applications, dont deux « desktop » pour Windows et macOS. La différence de traitement est pourtant énorme.

L’histoire de la version Windows du client WhatsApp se découpe en trois phases :

• Jusqu’en 2023 : la première version, essentiellement le service web encapsulé dans une application Electron, qui embarquait également tout le moteur Chromium pour le rendu
• De fin 2022 à 2025 : nouvelle version, native et utilisant UWP (Universal Windows Platform). Particulièrement légère et rapide
• Depuis 2025 : version en date, basée sur WebView2, donc retour à une encapsulation web

Depuis cette dernière mouture, les critiques n’ont pas manqué. Alors que la version native était célébrée pour ses performances, la nouvelle retourne à un rendu web, avec la consommation des ressources qui l’accompagnent.

Pluie de critiques

Si le grand public se « déplace » rarement pour commenter les applications du quotidien, il en va autrement de la presse spécialisée. Windows Latest s’est largement étendu sur le sujet dès novembre 2025, critiquant l’appétit vorace en ressources : 300 Mo de mémoire sur l’écran de connexion, en moyenne 1,2 Go en discutant, et jusqu’à 2 voire 3 Go en utilisation intensive. Nous avons nous-mêmes constaté que l’application pouvait dépasser ces 3 Go, notamment quand on ouvre le panneau des médias échangés dans une longue conversation. Dans ce cas, il n’est pas rare que l’occupation CPU grimpe en flèche, entrainant des ralentissements sur le reste du système.

Fin mai, IntraBlog publiait un billet allant dans le même sens, notant ici encore la forte consommation des ressources. Le site signalait également la multiplication des processus en arrière-plan, un manque fréquent de réactivité et des problèmes de fiabilité, particulièrement dans la synchronisation. Même chose chez Digital Trends, où la critique était sévère fin avril. Même John Grubber, habitué des informations Apple sur son blog Daring Fireball, n’hésitait pas à dire fin 2025 que la nouvelle application était « merdique ».

Sur Reddit, même combat. Les plaintes sont nombreuses, la plupart soulignant la consommation excessive de ressources et la lenteur générale. Plusieurs affirment avoir basculé sur la version web, la mouture desktop n’apportant plus rien. D’autres évoquent des problèmes fréquents de déconnexion, et d’autres encore recommandent d’ouvrir la version web et de passer par l’installation d’application web de Chrome (ou d’un autre navigateur Chromium).

Silence de Meta et pression de Microsoft

On peut comprendre pourquoi Meta s’est orientée vers ces technologies. L’utilisation d’une version web réclame moins de ressources de développement, puisqu’il s’agit dans les grandes lignes de reprendre l’existant. Contrairement à la première version qui utilisait Electron, la dernière se sert de WebView2, une vue web dérivée d’Edge. Techniquement, cette application devrait donc être plus légère, notamment car il n’est plus nécessaire d’embarquer tout le moteur Chromium. En pratique, le client WhatsApp semble renvoyer plusieurs années dans le passé.

Interrogée par plusieurs médias sur le sujet, Meta n’a pourtant jamais répondu. En novembre 2025, certains y voyaient d’ailleurs le signe d’une bascule : l’âge du code natif était-il révolu ?

Pourtant, si le sujet refait intensément parler aujourd’hui, c’est parce que Microsoft semble avoir changé complètement de braquet. À la dernière conférence Build, l’éditeur a largement appuyé sur le code natif et l’utilisation de son framework WinUI. Une équipe est actuellement chargée de développer de nouvelles applications internes, dont le code a été confirmé comme natif. Des éléments actuellement en React Native, dont le menu Démarrer, vont également être réécrits en code natif.

• Vers des applications natives et un menu contextuel personnalisable pour Windows 11

Concrètement, pour les développeurs tiers, le message de Microsoft a été inhabituellement direct : WinUI n’est pas une expérience en attente d’être remplacée, ni un pont technologique avant la prochaine grande unification : c’est désormais la plateforme de production native pour les apps Windows modernes. L’entreprise en est même jusqu’à parler de « web app slop ».

Cette nouvelle insistance de Microsoft et la pression des utilisateurs seront-elles suffisantes pour faire changer d’avis Meta ? Pour l’instant, WhatsApp reste en zone grise. Mais il est probable que cette version WebView2 ait été conçue pour des questions de coûts. En attendant, la version Mac reste native, avec des performances sans commune mesure.