Small si beautiful

Après le lancement de nouvelles versions majeures chez pratiquement tous les acteurs de l’IA générative, Mistral dégaine sa famille de modèles ouverts Mistral 3. Bien que celle-ci comprenne un modèle multimodal, ce sont surtout les plus petits qui sont mis en avant.

L’entreprise française n’en démord pas : lancer des modèles géants n’est pas nécessairement ce qu’il y a de mieux pour les entreprises. Elle reste centrée sur sa stratégie de publication de modèles à poids ouvert, dans l’idée que le monde professionnel va s’en emparer, les personnaliser, les distiller ou les entrainer sur ses propres données.

Mistral veut régner sur les modèles ouverts

Dans l’annonce, on remarque tout de suite que les comparaisons se font uniquement avec d’autres modèles ouverts, comme DeepSeek (en version 3.1 ou 3.2 selon les cas, étrangement) ou Kimi-K2. Sans trop de surprises dans le cadre de ce type d’annonce, les modèles Mistral 3 arrivent premiers dans la plupart des benchmarks, toujours à prendre avec des pincettes.

• La plupart des benchmarks de LLM ne s’appuient pas sur une méthode fiable

L’entreprise donne quelques informations supplémentaires sur son grand modèle Large 3. Par exemple, qu’il a été entrainé depuis zéro sur une infrastructure comprenant 3 000 GPU H200 de NVIDIA. Il s’agit également du premier modèle de type MoE (mixture-of-experts) de Mistral. Dans une version proposée au format NVFP4 (construite avec llm-compressor), Mistral affirme que son modèle peut fonctionner « efficacement » sur un nœud comportant huit puces A100 ou H100.

Cette approche permet pour rappel de dispatcher les requêtes vers des réseaux plus spécialisés du type de calcul lors de l’évaluation. Le principal avantage est une réduction de la consommation, le modèle n’activant qu’une partie des neurones pour traiter la demande (41 milliards de paramètres actifs sur 675 milliards au total). C’est le modèle présenté comme idéal pour les opérations lourdes, comme le développement et la création de contenus.

Mistral Large 3 se classe actuellement deuxième sur LMArena dans la catégorie des modèles ouverts sans capacités de raisonnement. La société ajoute que le développement de la nouvelle famille s’est fait en partenariat avec NVIDIA, aboutissant notamment à une « inférence efficace » pour TensorRT-LLM et SGLang.

La « petite » famille

Bien que Mistral aborde ses nouveautés du jour avec le modèle Large, ce sont surtout les petits modèles que la société met en avant. La série Ministral 3 comprend ainsi des variantes à 3, 8 et 14 milliards de paramètres, conçues pour l’informatique en périphérie (edge) et le fonctionnement local, toujours sous licence Apache 2.0. Tous ces modèles ont également des variantes de raisonnement, la version 14B atteignant par exemple 85 % sur le test AIME 25. Cette version, la plus volumineuse des trois, peut fonctionner sur une machine embarquant 24 Go de mémoire et un seul GPU.

Mistral semble particulièrement fière de ses petits modèles, assurant qu’ils offrent « le meilleur rapport coût/performance de tous les modèles open source » actuellement. Les versions classiques (sans raisonnement) sont au niveau ou dépassent les modèles concurrents, selon l’entreprise, tout en consommant « souvent » moins de jetons.

En tout, cette famille comprend trois modèles, les trois tailles étant disponibles dans des variantes Base (modèles de fondation pré-entrainés), Instruct (conçus surtout pour les chatbots) et Reasoning. Tous prennent en charge la vision, sont multilingues et fonctionnent avec des fenêtres allant de 128 000 à 256 000 jetons.

Guillaume Lample, fondateur de Mistral, a mis en avant la vision de l’entreprise auprès de plusieurs médias, dont TechCrunch et le Financial Times : « Nos clients sont parfois contents de débuter avec un très grand modèle de langage qu’ils n’ont pas besoin de peaufiner. Mais quand ils le déploient, ils réalisent que c’est cher et lent. Ils viennent alors nous voir pour affiner de petits modèles, afin de gérer leurs cas d’usage. Dans la pratique, la grande majorité des cas d’usage d’entreprises sont des choses que les petits modèles peuvent résoudre, surtout si vous les affinez ».

Comme le rappellent d’ailleurs nos confrères, cette orientation marquée vers les petits modèles capables de fonctionner localement rapproche l’entreprise de « l’IA physique ». Elle travaille par exemple avec Stellantis sur un assistant IA embarqué, avec la société allemande de défense Helsing sur des modèles vision-langage-action pour des drones, ou encore très récemment avec la Home Team Science and Technology Agency (HTX) de Singapour sur des modèles spécialisés pour robots.

Small si beautiful

Après le lancement de nouvelles versions majeures chez pratiquement tous les acteurs de l’IA générative, Mistral dégaine sa famille de modèles ouverts Mistral 3. Bien que celle-ci comprenne un modèle multimodal, ce sont surtout les plus petits qui sont mis en avant.

L’entreprise française n’en démord pas : lancer des modèles géants n’est pas nécessairement ce qu’il y a de mieux pour les entreprises. Elle reste centrée sur sa stratégie de publication de modèles à poids ouvert, dans l’idée que le monde professionnel va s’en emparer, les personnaliser, les distiller ou les entrainer sur ses propres données.

Mistral veut régner sur les modèles ouverts

Dans l’annonce, on remarque tout de suite que les comparaisons se font uniquement avec d’autres modèles ouverts, comme DeepSeek (en version 3.1 ou 3.2 selon les cas, étrangement) ou Kimi-K2. Sans trop de surprises dans le cadre de ce type d’annonce, les modèles Mistral 3 arrivent premiers dans la plupart des benchmarks, toujours à prendre avec des pincettes.

• La plupart des benchmarks de LLM ne s’appuient pas sur une méthode fiable

L’entreprise donne quelques informations supplémentaires sur son grand modèle Large 3. Par exemple, qu’il a été entrainé depuis zéro sur une infrastructure comprenant 3 000 GPU H200 de NVIDIA. Il s’agit également du premier modèle de type MoE (mixture-of-experts) de Mistral. Dans une version proposée au format NVFP4 (construite avec llm-compressor), Mistral affirme que son modèle peut fonctionner « efficacement » sur un nœud comportant huit puces A100 ou H100.

Cette approche permet pour rappel de dispatcher les requêtes vers des réseaux plus spécialisés du type de calcul lors de l’évaluation. Le principal avantage est une réduction de la consommation, le modèle n’activant qu’une partie des neurones pour traiter la demande (41 milliards de paramètres actifs sur 675 milliards au total). C’est le modèle présenté comme idéal pour les opérations lourdes, comme le développement et la création de contenus.

Mistral Large 3 se classe actuellement deuxième sur LMArena dans la catégorie des modèles ouverts sans capacités de raisonnement. La société ajoute que le développement de la nouvelle famille s’est fait en partenariat avec NVIDIA, aboutissant notamment à une « inférence efficace » pour TensorRT-LLM et SGLang.

La « petite » famille

Bien que Mistral aborde ses nouveautés du jour avec le modèle Large, ce sont surtout les petits modèles que la société met en avant. La série Ministral 3 comprend ainsi des variantes à 3, 8 et 14 milliards de paramètres, conçues pour l’informatique en périphérie (edge) et le fonctionnement local, toujours sous licence Apache 2.0. Tous ces modèles ont également des variantes de raisonnement, la version 14B atteignant par exemple 85 % sur le test AIME 25. Cette version, la plus volumineuse des trois, peut fonctionner sur une machine embarquant 24 Go de mémoire et un seul GPU.

Mistral semble particulièrement fière de ses petits modèles, assurant qu’ils offrent « le meilleur rapport coût/performance de tous les modèles open source » actuellement. Les versions classiques (sans raisonnement) sont au niveau ou dépassent les modèles concurrents, selon l’entreprise, tout en consommant « souvent » moins de jetons.

En tout, cette famille comprend trois modèles, les trois tailles étant disponibles dans des variantes Base (modèles de fondation pré-entrainés), Instruct (conçus surtout pour les chatbots) et Reasoning. Tous prennent en charge la vision, sont multilingues et fonctionnent avec des fenêtres allant de 128 000 à 256 000 jetons.

Guillaume Lample, fondateur de Mistral, a mis en avant la vision de l’entreprise auprès de plusieurs médias, dont TechCrunch et le Financial Times : « Nos clients sont parfois contents de débuter avec un très grand modèle de langage qu’ils n’ont pas besoin de peaufiner. Mais quand ils le déploient, ils réalisent que c’est cher et lent. Ils viennent alors nous voir pour affiner de petits modèles, afin de gérer leurs cas d’usage. Dans la pratique, la grande majorité des cas d’usage d’entreprises sont des choses que les petits modèles peuvent résoudre, surtout si vous les affinez ».

Comme le rappellent d’ailleurs nos confrères, cette orientation marquée vers les petits modèles capables de fonctionner localement rapproche l’entreprise de « l’IA physique ». Elle travaille par exemple avec Stellantis sur un assistant IA embarqué, avec la société allemande de défense Helsing sur des modèles vision-langage-action pour des drones, ou encore très récemment avec la Home Team Science and Technology Agency (HTX) de Singapour sur des modèles spécialisés pour robots.

Avec la version 9.1, la suite bureautique avait introduit un agent en version bêta. L’éditeur se sent suffisamment prêt désormais pour le lancer dans le grand bain.

Comme toujours avec ce type de fonction, elle est conçue pour gérer des requêtes comme le résumé de tout ou partie d’un document, des questions sur le contenu, le remplissage de PDF ou encore des modifications dans la présentation.

OnlyOffice ne dispose pas de son propre modèle. Pour utiliser l’agent maison, il faut disposer d’une clé API pour un LLM existant, comme ChatGPT, Claude ou Gemini. On peut aussi le connecter à un serveur LLM ou MCP local fonctionnant avec des solutions de type Ollama. Comme le rappelle OMGUbuntu cependant, le travail avec les LLM implique souvent des conditions d’utilisation incluant la réutilisation des contenus analysés à des fins d’entrainement.

Parmi les autres nouveautés de cette version, signalons la possibilité de choisir une couleur personnalisée pour caviarder des passages dans un document PDF, l’enregistrement d’une série d’actions sous forme de macro pour la réutiliser plus tard, la personnalisation des raccourcis clavier, la possibilité d’insérer des équations depuis des sources en ligne, la disponibilité de cases à cocher et de boutons radio dans l’éditeur de formulaires, ainsi qu’un correctif de sécurité.

La nouvelle mouture de la suite peut être téléchargée depuis le site officiel ou le dépôt GitHub.

Avec la version 9.1, la suite bureautique avait introduit un agent en version bêta. L’éditeur se sent suffisamment prêt désormais pour le lancer dans le grand bain.

Comme toujours avec ce type de fonction, elle est conçue pour gérer des requêtes comme le résumé de tout ou partie d’un document, des questions sur le contenu, le remplissage de PDF ou encore des modifications dans la présentation.

OnlyOffice ne dispose pas de son propre modèle. Pour utiliser l’agent maison, il faut disposer d’une clé API pour un LLM existant, comme ChatGPT, Claude ou Gemini. On peut aussi le connecter à un serveur LLM ou MCP local fonctionnant avec des solutions de type Ollama. Comme le rappelle OMGUbuntu cependant, le travail avec les LLM implique souvent des conditions d’utilisation incluant la réutilisation des contenus analysés à des fins d’entrainement.

Parmi les autres nouveautés de cette version, signalons la possibilité de choisir une couleur personnalisée pour caviarder des passages dans un document PDF, l’enregistrement d’une série d’actions sous forme de macro pour la réutiliser plus tard, la personnalisation des raccourcis clavier, la possibilité d’insérer des équations depuis des sources en ligne, la disponibilité de cases à cocher et de boutons radio dans l’éditeur de formulaires, ainsi qu’un correctif de sécurité.

La nouvelle mouture de la suite peut être téléchargée depuis le site officiel ou le dépôt GitHub.

Oui, non, peut-être

Sur X, un échange entre un ingénieur et Proton a remis la sécurité des messages chiffrés du réseau social sur le devant de la scène. Même si la solution adoptée n’est pas aussi simple que l’ingénieur le pensait, elle reste très critiquée.

Au cours des derniers mois, X a diffusé auprès d’un nombre croissant d’utilisateurs sa fonction de messagerie sécurisée Xchat, présentée comme ayant un chiffrement de bout en bout (E2EE).

• XChat : la nouvelle messagerie d’Elon Musk au système de chiffrement qui laisse dubitatif

« Toutes les affirmations sur le chiffrement de bout en bout ne se valent pas »

Ce 1ᵉʳ décembre, Ansgar, chercheur à la fondation Ethereum, a publié un message sur X pour s’en prendre à cette sécurité, qu’il a qualifiée de « ridicule ». Il pointait deux défauts majeurs dans l’implémentation faite par X : la clé privée de chiffrement est stockée sur les serveurs de l’entreprise et les conversations ne sont protégées que par un code PIN à quatre chiffres.

Cette communication a rapidement été reprise par le compte officiel de Proton, avec un message simple : « Malheureusement, toutes les affirmations sur le chiffrement de bout en bout ne se valent pas ». Il enchainait sur la propension des « géants de la tech » à « vendre du vent en matière de confidentialité en prétendant offrir chiffrement et protection de la vie privée, alors qu’en réalité, ils détiennent la clé principale et peuvent accéder à vos contenus ».

Rappelons que l’objectif du chiffrement de bout en bout est de transmettre une information que seul le destinataire pourra lire. Dans une solution E2EE solide, aucun des intermédiaires impliqués dans la transmission de ces données ne peut lire l’information, car seul le destinataire possède la clé privée pour déchiffrer le message. Quand l’un des acteurs dispose de la clé, il a la capacité d’accéder aux informations, brisant la promesse initiale.

Sécurité matérielle, mais code à quatre chiffres

En pratique, c’est un peu plus complexe. Au lancement, X reconnaissait déjà que son implémentation ne disposait pas d’une sécurité persistante, ce qui la rendait plus sensible aux attaques par l’homme du milieu (MITM). Cependant, en réponse à un tweet du chercheur en sécurité Matthew Green, un ingénieur de chez X avait confirmé l’utilisation de serveurs HSM (Hardware Security Modules) pour stocker les clés privées. X se sert de Juicebox (pdf) pour la sécurité des clés, un projet open source divisant les secrets en plusieurs morceaux, stockés par les HSM. Ils ne peuvent être reconstruits qu’avec le code PIN.

Si Ansgar a reconnu dans un premier temps que l’implémentation n’était pas aussi simple qu’il le pensait, elle augmentait la pression sur le code PIN, limité à quatre chiffres et donc sujet aux attaques par force brute. Quatre chiffres, cela ne laisse que 10 000 possibilités, ce qui se casse quasi instantanément s’il n’y a pas de protections supplémentaires.

Dans un autre message avertissant Proton de son changement d’avis, il signalait également que les HSM, qui permettent de faciliter l’utilisation, sont de moins bonnes protections que des clés privées stockées directement chez les utilisateurs. Proton a remercié le chercheur mais assume son message initial, puisque des géants « comme Google, Microsoft, etc » peuvent accéder aux e-mails, fichiers sur le cloud et autres.

Les éléments mis en avant ne sont cependant pas nouveaux. Matthew Garrett, un autre chercheur en sécurité, les avait déjà mentionnés dans un billet de blog daté du 5 juin. D’autres étaient revenus sur la question, par exemple le compte Mysk le 4 septembre pour affirmer que X n’implémentait pas correctement Juicebox.

Oui, non, peut-être

Sur X, un échange entre un ingénieur et Proton a remis la sécurité des messages chiffrés du réseau social sur le devant de la scène. Même si la solution adoptée n’est pas aussi simple que l’ingénieur le pensait, elle reste très critiquée.

Au cours des derniers mois, X a diffusé auprès d’un nombre croissant d’utilisateurs sa fonction de messagerie sécurisée Xchat, présentée comme ayant un chiffrement de bout en bout (E2EE).

• XChat : la nouvelle messagerie d’Elon Musk au système de chiffrement qui laisse dubitatif

« Toutes les affirmations sur le chiffrement de bout en bout ne se valent pas »

Ce 1ᵉʳ décembre, Ansgar, chercheur à la fondation Ethereum, a publié un message sur X pour s’en prendre à cette sécurité, qu’il a qualifiée de « ridicule ». Il pointait deux défauts majeurs dans l’implémentation faite par X : la clé privée de chiffrement est stockée sur les serveurs de l’entreprise et les conversations ne sont protégées que par un code PIN à quatre chiffres.

Cette communication a rapidement été reprise par le compte officiel de Proton, avec un message simple : « Malheureusement, toutes les affirmations sur le chiffrement de bout en bout ne se valent pas ». Il enchainait sur la propension des « géants de la tech » à « vendre du vent en matière de confidentialité en prétendant offrir chiffrement et protection de la vie privée, alors qu’en réalité, ils détiennent la clé principale et peuvent accéder à vos contenus ».

Rappelons que l’objectif du chiffrement de bout en bout est de transmettre une information que seul le destinataire pourra lire. Dans une solution E2EE solide, aucun des intermédiaires impliqués dans la transmission de ces données ne peut lire l’information, car seul le destinataire possède la clé privée pour déchiffrer le message. Quand l’un des acteurs dispose de la clé, il a la capacité d’accéder aux informations, brisant la promesse initiale.

Sécurité matérielle, mais code à quatre chiffres

En pratique, c’est un peu plus complexe. Au lancement, X reconnaissait déjà que son implémentation ne disposait pas d’une sécurité persistante, ce qui la rendait plus sensible aux attaques par l’homme du milieu (MITM). Cependant, en réponse à un tweet du chercheur en sécurité Matthew Green, un ingénieur de chez X avait confirmé l’utilisation de serveurs HSM (Hardware Security Modules) pour stocker les clés privées. X se sert de Juicebox (pdf) pour la sécurité des clés, un projet open source divisant les secrets en plusieurs morceaux, stockés par les HSM. Ils ne peuvent être reconstruits qu’avec le code PIN.

Si Ansgar a reconnu dans un premier temps que l’implémentation n’était pas aussi simple qu’il le pensait, elle augmentait la pression sur le code PIN, limité à quatre chiffres et donc sujet aux attaques par force brute. Quatre chiffres, cela ne laisse que 10 000 possibilités, ce qui se casse quasi instantanément s’il n’y a pas de protections supplémentaires.

Dans un autre message avertissant Proton de son changement d’avis, il signalait également que les HSM, qui permettent de faciliter l’utilisation, sont de moins bonnes protections que des clés privées stockées directement chez les utilisateurs. Proton a remercié le chercheur mais assume son message initial, puisque des géants « comme Google, Microsoft, etc » peuvent accéder aux e-mails, fichiers sur le cloud et autres.

Les éléments mis en avant ne sont cependant pas nouveaux. Matthew Garrett, un autre chercheur en sécurité, les avait déjà mentionnés dans un billet de blog daté du 5 juin. D’autres étaient revenus sur la question, par exemple le compte Mysk le 4 septembre pour affirmer que X n’implémentait pas correctement Juicebox.

On a dit pas de baskets

Pavel Durov, créateur de la messagerie Telegram, a lancé officiellement sa plateforme Cocoon, qui se propose de répartir les requêtes IA sur un réseau distribué d’ordinateurs. Elle est également présentée comme confidentielle et chiffrée. Mais en dépit d’une annonce semblant destinée à tous les possesseurs de GPU, Cocoon s’adresse à un matériel très spécifique.

Début novembre, Pavel Durov présentait son réseau décentralisé Cocoon, largement intégré à la plateforme Telegram, basé sur la chaine TON et proposant de répartir les calculs liés à l’IA sur un ensemble de machines disponibles, plutôt que le traitement classique via un ou plusieurs centres de données dédiés. La chaine TON (The Open Network) a été initialement créée par Telegram, mais est gérée par une équipe indépendante depuis 2021, après un abandon par Telegram en 2020.

L’initiative était présentée comme particulièrement sécurisée et respectueuse de la confidentialité, tant des requêtes que des données. Une sorte d’étrange mariage entre Private Cloud Compute d’Apple, Seti@Home et blockchain. Le nom Cocoon signifie d’ailleurs Confidential Compute Open Network.

Le réseau a été officiellement lancé ce 30 novembre, comme annoncé lundi par Pavel Durov sur son compte X. Il présente son projet comme salvateur pour « les propriétaires de GPU qui engrangent déjà des gains considérables », laissant penser que tout le monde peut en profiter. Mais lorsque l’on épluche les documentations techniques disponibles, la réalité est toute autre et il reste de nombreuses zones d’ombre.

Un cercle vertueux selon Durov

L’équipe de FreeBSD vient d’annoncer la disponibilité de la version finale pour la quinzième édition majeure du système Unix.

La plupart des évolutions sont largement liées à la modernisation générale des paquets. On trouve cependant plusieurs améliorations notables, dont une génération des artefacts (images d’installations, de machines virtuelles et autres) sans requérir de droits administrateur. On peut également voir une implémentation native d’inotify, ou encore le passage à la version 2.4.0-rc4 de ZFS.

FreeBSD 15 introduit surtout deux changements majeurs. D’abord, l’introduction d’une nouvelle méthode pour l’installation et la gestion du système, basée sur le gestionnaire de paquets pkg. Lors de l’installation, les utilisateurs peuvent choisir entre la nouvelle méthode et l’ancienne (distribution sets). L’équipe précise cependant que cette dernière sera supprimée avec FreeBSD 16.

L’autre grande nouveauté est l’arrivée des builds reproductibles. Aussi appelée compilation déterministe, cette méthode permet de s’assurer que le code binaire pourra être reproduit par d’autres personnes. Il s’agit d’une étape importante pour la confiance, car la conséquence principale est que les utilisateurs peuvent s’assurer notamment que les images fournies par l’équipe sont bien ce qu’elles prétendent être et correspondent aux sources.

Signalons également une progression significative du support des ordinateurs portables par le système grâce à l’initiative FreeBSD-on-laptops, surtout pour le matériel Wi-Fi et graphique.

L’équipe de FreeBSD vient d’annoncer la disponibilité de la version finale pour la quinzième édition majeure du système Unix.

La plupart des évolutions sont largement liées à la modernisation générale des paquets. On trouve cependant plusieurs améliorations notables, dont une génération des artefacts (images d’installations, de machines virtuelles et autres) sans requérir de droits administrateur. On peut également voir une implémentation native d’inotify, ou encore le passage à la version 2.4.0-rc4 de ZFS.

FreeBSD 15 introduit surtout deux changements majeurs. D’abord, l’introduction d’une nouvelle méthode pour l’installation et la gestion du système, basée sur le gestionnaire de paquets pkg. Lors de l’installation, les utilisateurs peuvent choisir entre la nouvelle méthode et l’ancienne (distribution sets). L’équipe précise cependant que cette dernière sera supprimée avec FreeBSD 16.

L’autre grande nouveauté est l’arrivée des builds reproductibles. Aussi appelée compilation déterministe, cette méthode permet de s’assurer que le code binaire pourra être reproduit par d’autres personnes. Il s’agit d’une étape importante pour la confiance, car la conséquence principale est que les utilisateurs peuvent s’assurer notamment que les images fournies par l’équipe sont bien ce qu’elles prétendent être et correspondent aux sources.

Signalons également une progression significative du support des ordinateurs portables par le système grâce à l’initiative FreeBSD-on-laptops, surtout pour le matériel Wi-Fi et graphique.

Le monde Linux finit l’année avec une nouvelle version majeure du noyau riche en nouveautés. Selon Phoronix, elle affiche de bonnes performances, ne semble pas contenir de régression par rapport au noyau 6.17 et semble avoir tout ce qu’il faut pour devenir la nouvelle mouture LTS (Long Term Support).

Comme toujours, les améliorations concernent pour beaucoup le support du matériel, mais pas seulement. Plusieurs améliorations de performances sont présentes, notamment pour le swap, lors de la réception des paquets UDP ou encore de l’allocation de la mémoire. On y trouve également le support du chiffrement PSP pour les connexions TCP, la prise en charge de la fonction Secure AVIC d’AMD ainsi que des améliorations dans celle d’Ext4. On note aussi l’apparition du pilote Rust Binder.

Le noyau 6.18 contient aussi plusieurs améliorations liées à la sécurité. Il supporte par exemple le sous-système d’audit pour gérer plusieurs modules de sécurité en même temps, ou encore la signature des programmes BPF.

La nouvelle version supprime également le support de Bcachefs. Ce système de fichiers était pris en charge par le noyau Linux depuis sa version 6.7. De type copy-on-write, il avait été pensé par son développeur principal, Kent Overstreet, comme une alternative à d’autres systèmes de fichiers modernes comme ZFS ou Btrfs. Mais en juin dernier, arguant de violations répétées d’Overstreet aux règles de maintenance du noyau, Linus Torvalds a fait passer le statut de Bcachefs de « Supporté » à « Maintenu extérieurement ».

• Systèmes de fichiers : ext4 et Btrfs, les « frères ennemis » du monde Linux

Comme toujours, la récupération du nouveau noyau dépend essentiellement de la distribution utilisée. Si vous utilisez un système « classique » comme Ubuntu, Fedora ou autre, vous resterez probablement sur la version déjà utilisée. Dans le cas d’une rolling release, les chances sont beaucoup plus élevées.

Le monde Linux finit l’année avec une nouvelle version majeure du noyau riche en nouveautés. Selon Phoronix, elle affiche de bonnes performances, ne semble pas contenir de régression par rapport au noyau 6.17 et semble avoir tout ce qu’il faut pour devenir la nouvelle mouture LTS (Long Term Support).

Comme toujours, les améliorations concernent pour beaucoup le support du matériel, mais pas seulement. Plusieurs améliorations de performances sont présentes, notamment pour le swap, lors de la réception des paquets UDP ou encore de l’allocation de la mémoire. On y trouve également le support du chiffrement PSP pour les connexions TCP, la prise en charge de la fonction Secure AVIC d’AMD ainsi que des améliorations dans celle d’Ext4. On note aussi l’apparition du pilote Rust Binder.

Le noyau 6.18 contient aussi plusieurs améliorations liées à la sécurité. Il supporte par exemple le sous-système d’audit pour gérer plusieurs modules de sécurité en même temps, ou encore la signature des programmes BPF.

La nouvelle version supprime également le support de Bcachefs. Ce système de fichiers était pris en charge par le noyau Linux depuis sa version 6.7. De type copy-on-write, il avait été pensé par son développeur principal, Kent Overstreet, comme une alternative à d’autres systèmes de fichiers modernes comme ZFS ou Btrfs. Mais en juin dernier, arguant de violations répétées d’Overstreet aux règles de maintenance du noyau, Linus Torvalds a fait passer le statut de Bcachefs de « Supporté » à « Maintenu extérieurement ».

• Systèmes de fichiers : ext4 et Btrfs, les « frères ennemis » du monde Linux

Comme toujours, la récupération du nouveau noyau dépend essentiellement de la distribution utilisée. Si vous utilisez un système « classique » comme Ubuntu, Fedora ou autre, vous resterez probablement sur la version déjà utilisée. Dans le cas d’une rolling release, les chances sont beaucoup plus élevées.

Dans une version bêta publiée le 25 novembre, Valve a introduit un changement technique majeur pour le client Steam : le passage au tout 64 bits pour Windows 10 et 11. Pour les personnes possédant un Windows 10 en 32 bits, la version 32 bits de Steam recevra des mises à jour jusqu’au 1ᵉʳ janvier 2026. Il ne reste donc qu’un mois.

Cette transition vers le 64 bits ne devrait rien changer côté utilisateurs. La nouvelle est « satisfaisante » d’un point de vue technique, mais un passage au 64 bits sur ce type d’application n’entraine aucun gain visible. La transition devenait pressante cependant pour d’autres raisons, principalement de compatibilité, les composants et pilotes 32 bits étant presque tous abandonnés.

On remarque cependant que Valve est en pleine modernisation de ses clients. Au cours des derniers mois, l’entreprise a ainsi lancé une version native pour les Mac Apple Silicon. Cette fois, le gain de performances était majeur, car l’ancienne version était prévue pour l’architecture x86 des anciens Mac Intel. L’application se lançait, mais via la couche d’émulation Rosetta, et offrait des performances particulièrement dégradées.

Cette phase de modernisation s’est incarnée également le 20 novembre avec le lancement du Steam Runtime 4.0 pour Linux, le composant principal de Steam pour le lancement des jeux et le lien avec la couche Proton (passée récemment en version 10). Cette version 4.0 a apporté des changements majeurs, notamment un appui sur les bibliothèques de Debian 13 contre 11 précédemment.

L’éditeur avertissait d’ailleurs les développeurs que l’utilisation de cette version entrainerait des cassures de rétrocompatibilité. On peut également voir dans les changements que la plupart des bibliothèques ne sont désormais plus disponibles qu’en x86_64.

• Valve revient sur le marché des consoles de salon avec sa Steam Machine et un casque VR

Dans une version bêta publiée le 25 novembre, Valve a introduit un changement technique majeur pour le client Steam : le passage au tout 64 bits pour Windows 10 et 11. Pour les personnes possédant un Windows 10 en 32 bits, la version 32 bits de Steam recevra des mises à jour jusqu’au 1ᵉʳ janvier 2026. Il ne reste donc qu’un mois.

Cette transition vers le 64 bits ne devrait rien changer côté utilisateurs. La nouvelle est « satisfaisante » d’un point de vue technique, mais un passage au 64 bits sur ce type d’application n’entraine aucun gain visible. La transition devenait pressante cependant pour d’autres raisons, principalement de compatibilité, les composants et pilotes 32 bits étant presque tous abandonnés.

On remarque cependant que Valve est en pleine modernisation de ses clients. Au cours des derniers mois, l’entreprise a ainsi lancé une version native pour les Mac Apple Silicon. Cette fois, le gain de performances était majeur, car l’ancienne version était prévue pour l’architecture x86 des anciens Mac Intel. L’application se lançait, mais via la couche d’émulation Rosetta, et offrait des performances particulièrement dégradées.

Cette phase de modernisation s’est incarnée également le 20 novembre avec le lancement du Steam Runtime 4.0 pour Linux, le composant principal de Steam pour le lancement des jeux et le lien avec la couche Proton (passée récemment en version 10). Cette version 4.0 a apporté des changements majeurs, notamment un appui sur les bibliothèques de Debian 13 contre 11 précédemment.

L’éditeur avertissait d’ailleurs les développeurs que l’utilisation de cette version entrainerait des cassures de rétrocompatibilité. On peut également voir dans les changements que la plupart des bibliothèques ne sont désormais plus disponibles qu’en x86_64.

• Valve revient sur le marché des consoles de salon avec sa Steam Machine et un casque VR

« Tartufferies »

OVHcloud serait aux prises avec la justice canadienne, qui ordonne à l’entreprise française de remettre des données dans le cadre d’une décision de justice. Pour l’avocat Alexandre Archambault, il n’y a cependant rien de nouveau dans ce type de procédure, en vertu des accords d’adéquation et du RGPD.

Dans un article publié le 26 novembre, le média allemand Heise décrit une situation inextricable : OVHcloud est sommée d’obéir à une décision de justice canadienne dans le cadre d’une enquête criminelle.

18 mois plus tôt

Cette décision a été initialement rendue en avril 2024 par la Cour de justice de l’Ontario. Puisque des données sont présentes sur des serveurs appartenant à OVHcloud sur des serveurs situés en France, au Royaume-Uni et en Australie, demande est faite à la filiale canadienne de transmettre ces informations. Celle-ci étant une entité juridique indépendante, elle répond qu’elle ne peut pas transférer les informations réclamées.

Selon Heise, l’affaire remonte, en France, aux oreilles du SISSE (Service de l’information stratégique et de la sécurité économiques). Un premier courrier aurait été envoyé à OVHcloud en mai 2024 pour rappeler qu’en vertu de la loi de blocage de 1968 (renforcée en 2022), il est interdit aux entreprises françaises de transmettre des informations à une autorité étrangère hors des canaux internationaux.

Le 25 septembre suivant, la juge chargée de l’affaire en Ontario, Heather Perkins-McVey, décide que c’est la maison mère française qui doit envoyer les données. Elle motive sa décision en faisant référence à la « présence virtuelle » : « Puisque OVH opère à l’échelle mondiale et propose des services au Canada, l’entreprise est soumise à la juridiction canadienne, peu importe où se trouvent les serveurs physiques », écrivent nos confrères. Une vision qui se rapprocherait du Cloud Act américain.

Conflit diplomatique ?

La Cour aurait donné jusqu’au 27 octobre 2024 à OVHcloud pour répondre. La société française aurait alors fait appel devant la Cour supérieure de justice de l’Ontario. Janvier 2025, nouveau courrier de la SISSE, décrit comme « plus détaillé », mais enfonçant le clou : tout envoi de données à la Gendarmerie royale du Canada serait illégal.

Le 21 février, toujours selon Heise, le ministère français de la Justice serait intervenu pour assurer à ses homologues canadiens qu’ils bénéficieraient d’un « traitement accéléré » en passant par la voie officielle. Le ministère aurait ainsi montré sa volonté de coopération, indiquant qu’OVHcloud se tenait prête, l’entreprise ayant préparé les données demandées. Mais la Gendarmerie canadienne aurait insisté pour une transmission directe, appuyée par le tribunal en Ontario.

Nos confrères affirment que l’affaire est depuis suivie de près par l’industrie technologique comme illustration des tensions autour du modèle commercial habituel du cloud, et plus généralement de la notion de souveraineté des données.

L’affaire rappelle celle qui avait alimenté la création du Cloud Act américain : Microsoft était sommée par un tribunal de fournir les données d’une personne accusée de trafic de drogue. Problème, ces données étaient situées sur un serveur en Irlande, l’entreprise estimant qu’il fallait passer par la voie classique de coopération. Pour le tribunal américain, Microsoft était une entreprise mondiale dont le siège était aux États-Unis, elle devait donc pouvoir transmettre ces données, où qu’elles soient. L’emplacement physique des serveurs n’avait pas d’importance.

« C’est une tempête dans un verre d’eau ! »

L’avocat Alexandre Archambault, spécialiste des questions numériques, n’est cependant pas d’accord avec le récit que dresse Heise de la situation. Il s’étonne également des réactions émues autour de la question, car il n’y a selon lui rien de nouveau dans cette affaire.

Contacté, il ne cache pas son agacement : « Il faut qu’on arrête vraiment ces tartufferies ! C’est une tempête dans un verre d’eau. Moi ce que je vois, c’est qu’une juridiction s’est prononcée, avec des magistrats indépendants, dans le cadre d’une procédure contradictoire, publique, sur laquelle tout le monde peut faire valoir ses points de vue. On est face à une décision de justice. Et bien sûr, si on n’applique pas cette décision, on s’expose à des sanctions. Et on peut tout à fait contester la décision là-bas, ce qui a été fait ».

L’avocat cite en exemple un arrêt de la cour d’appel de Paris (via le site de la Cour de cassation) dans le cadre d’une affaire où il était exigé de la filiale allemande d’OVHcloud qu’elle applique la loi française. OVHcloud avait contesté, mais la Cour avait confirmé la validité de la demande. « On peut difficilement exiger, à juste titre d’ailleurs, d’acteurs établis hors de France de communiquer des éléments d’identification d’auteurs d’infractions en ligne, tout en s’indignant que d’autres pays fassent la même chose », estime Alexandre Archambault.

Tout est dans le RGPD

Pour l’avocat, OVHcloud « n’est pas coincée entre deux lois » et le média allemand s’est trompé. « Le droit de l’Union, notamment au titre du DSA et du prochain règlement E-evidence, dit que les acteurs du numérique établis sur le sol européen doivent coopérer avec les autorités judiciaires, quelles qu’elles soient. Tout est dans l’article 48 du RGPD ! ».

Que dit ce dernier ? Que toute « décision d’une juridiction ou d’une autorité administrative d’un pays tiers exigeant d’un responsable du traitement ou d’un sous-traitant qu’il transfère ou divulgue des données à caractère personnel ne peut être reconnue ou rendue exécutoire de quelque manière que ce soit qu’à la condition qu’elle soit fondée sur un accord international, tel qu’un traité d’entraide judiciaire, en vigueur entre le pays tiers demandeur et l’Union ou un État membre, sans préjudice d’autres motifs de transfert en vertu du présent chapitre ».

Or, rappelle l’avocat, il y a non seulement un traité d’entraide entre la France et le Canada, mais également un accord d’adéquation avec le pays. La CNIL pointait ainsi en décembre 2024 que le Canada faisait justement partie d’un groupe de onze pays bénéficiant « d’un niveau de protection adéquat », à la suite d’un examen d’évaluation de ces accords au regard du RGPD.

Les courriers du SISSE ne seraient donc que des rappels de la bonne marche à suivre dans ce contexte, mais il est difficile d’en savoir plus, leur contenu n’étant pas consultable.

Contactée, OVHcloud n’a pas souhaité réagir, indiquant simplement : « Nous ne commentons pas les décisions de justice ».

« Tartufferies »

OVHcloud serait aux prises avec la justice canadienne, qui ordonne à l’entreprise française de remettre des données dans le cadre d’une décision de justice. Pour l’avocat Alexandre Archambault, il n’y a cependant rien de nouveau dans ce type de procédure, en vertu des accords d’adéquation et du RGPD.

Dans un article publié le 26 novembre, le média allemand Heise décrit une situation inextricable : OVHcloud est sommée d’obéir à une décision de justice canadienne dans le cadre d’une enquête criminelle.

18 mois plus tôt

Cette décision a été initialement rendue en avril 2024 par la Cour de justice de l’Ontario. Puisque des données sont présentes sur des serveurs appartenant à OVHcloud sur des serveurs situés en France, au Royaume-Uni et en Australie, demande est faite à la filiale canadienne de transmettre ces informations. Celle-ci étant une entité juridique indépendante, elle répond qu’elle ne peut pas transférer les informations réclamées.

Selon Heise, l’affaire remonte, en France, aux oreilles du SISSE (Service de l’information stratégique et de la sécurité économiques). Un premier courrier aurait été envoyé à OVHcloud en mai 2024 pour rappeler qu’en vertu de la loi de blocage de 1968 (renforcée en 2022), il est interdit aux entreprises françaises de transmettre des informations à une autorité étrangère hors des canaux internationaux.

Le 25 septembre suivant, la juge chargée de l’affaire en Ontario, Heather Perkins-McVey, décide que c’est la maison mère française qui doit envoyer les données. Elle motive sa décision en faisant référence à la « présence virtuelle » : « Puisque OVH opère à l’échelle mondiale et propose des services au Canada, l’entreprise est soumise à la juridiction canadienne, peu importe où se trouvent les serveurs physiques », écrivent nos confrères. Une vision qui se rapprocherait du Cloud Act américain.

Conflit diplomatique ?

La Cour aurait donné jusqu’au 27 octobre 2024 à OVHcloud pour répondre. La société française aurait alors fait appel devant la Cour supérieure de justice de l’Ontario. Janvier 2025, nouveau courrier de la SISSE, décrit comme « plus détaillé », mais enfonçant le clou : tout envoi de données à la Gendarmerie royale du Canada serait illégal.

Le 21 février, toujours selon Heise, le ministère français de la Justice serait intervenu pour assurer à ses homologues canadiens qu’ils bénéficieraient d’un « traitement accéléré » en passant par la voie officielle. Le ministère aurait ainsi montré sa volonté de coopération, indiquant qu’OVHcloud se tenait prête, l’entreprise ayant préparé les données demandées. Mais la Gendarmerie canadienne aurait insisté pour une transmission directe, appuyée par le tribunal en Ontario.

Nos confrères affirment que l’affaire est depuis suivie de près par l’industrie technologique comme illustration des tensions autour du modèle commercial habituel du cloud, et plus généralement de la notion de souveraineté des données.

L’affaire rappelle celle qui avait alimenté la création du Cloud Act américain : Microsoft était sommée par un tribunal de fournir les données d’une personne accusée de trafic de drogue. Problème, ces données étaient situées sur un serveur en Irlande, l’entreprise estimant qu’il fallait passer par la voie classique de coopération. Pour le tribunal américain, Microsoft était une entreprise mondiale dont le siège était aux États-Unis, elle devait donc pouvoir transmettre ces données, où qu’elles soient. L’emplacement physique des serveurs n’avait pas d’importance.

« C’est une tempête dans un verre d’eau ! »

L’avocat Alexandre Archambault, spécialiste des questions numériques, n’est cependant pas d’accord avec le récit que dresse Heise de la situation. Il s’étonne également des réactions émues autour de la question, car il n’y a selon lui rien de nouveau dans cette affaire.

Contacté, il ne cache pas son agacement : « Il faut qu’on arrête vraiment ces tartufferies ! C’est une tempête dans un verre d’eau. Moi ce que je vois, c’est qu’une juridiction s’est prononcée, avec des magistrats indépendants, dans le cadre d’une procédure contradictoire, publique, sur laquelle tout le monde peut faire valoir ses points de vue. On est face à une décision de justice. Et bien sûr, si on n’applique pas cette décision, on s’expose à des sanctions. Et on peut tout à fait contester la décision là-bas, ce qui a été fait ».

L’avocat cite en exemple un arrêt de la cour d’appel de Paris (via le site de la Cour de cassation) dans le cadre d’une affaire où il était exigé de la filiale allemande d’OVHcloud qu’elle applique la loi française. OVHcloud avait contesté, mais la Cour avait confirmé la validité de la demande. « On peut difficilement exiger, à juste titre d’ailleurs, d’acteurs établis hors de France de communiquer des éléments d’identification d’auteurs d’infractions en ligne, tout en s’indignant que d’autres pays fassent la même chose », estime Alexandre Archambault.

Tout est dans le RGPD

Pour l’avocat, OVHcloud « n’est pas coincée entre deux lois » et le média allemand s’est trompé. « Le droit de l’Union, notamment au titre du DSA et du prochain règlement E-evidence, dit que les acteurs du numérique établis sur le sol européen doivent coopérer avec les autorités judiciaires, quelles qu’elles soient. Tout est dans l’article 48 du RGPD ! ».

Que dit ce dernier ? Que toute « décision d’une juridiction ou d’une autorité administrative d’un pays tiers exigeant d’un responsable du traitement ou d’un sous-traitant qu’il transfère ou divulgue des données à caractère personnel ne peut être reconnue ou rendue exécutoire de quelque manière que ce soit qu’à la condition qu’elle soit fondée sur un accord international, tel qu’un traité d’entraide judiciaire, en vigueur entre le pays tiers demandeur et l’Union ou un État membre, sans préjudice d’autres motifs de transfert en vertu du présent chapitre ».

Or, rappelle l’avocat, il y a non seulement un traité d’entraide entre la France et le Canada, mais également un accord d’adéquation avec le pays. La CNIL pointait ainsi en décembre 2024 que le Canada faisait justement partie d’un groupe de onze pays bénéficiant « d’un niveau de protection adéquat », à la suite d’un examen d’évaluation de ces accords au regard du RGPD.

Les courriers du SISSE ne seraient donc que des rappels de la bonne marche à suivre dans ce contexte, mais il est difficile d’en savoir plus, leur contenu n’étant pas consultable.

Contactée, OVHcloud n’a pas souhaité réagir, indiquant simplement : « Nous ne commentons pas les décisions de justice ».

Tic tac

Toujours dans le lent cheminement menant de X11 à Wayland, l’équipe de KDE vient de confirmer le 26 novembre que la future mouture 6.8 de KDE Plasma n’aura plus de session X11.

Plasma 6.8 n’aura donc plus qu’une session Wayland. Comme GNOME récemment, les applications X11 seront confiées aux bons soins de XWayland. Comme nous l’avions expliqué dans notre dossier dédié, ce dernier permet de traiter les demandes pour l’ancien serveur d’affichage en enfermant ce dernier dans un client Wayland. La session X11, elle, disparaitra. Selon l’équipe de développement, « ce changement ouvre de nouvelles opportunités pour les fonctionnalités, les optimisations et la rapidité de développement ».

• X11, Wayland : pourquoi la transition est-elle aussi longue ?

KDE lance le compte à rebours

Dans l’ensemble, l’équipe de KDE prévoit un support de X11 dans Plasma jusqu’à début 2027. Le support pourrait être plus long dans Plasma 6.7, l’équipe prévoyant de publier des versions supplémentaires de corrections de bugs. Pour un besoin plus long, le billet recommande de s’orienter vers des distributions dont le support LTS garantit la présence de X11 pour l’instant. AlmaLinux 9 et son support jusqu’en 2032 sont donnés comme exemple.

L’équipe de KDE veut rassurer sur le support des applications via XWayland. Elle précise qu’elle a ajouté des fonctions supplémentaires de compatibilité, dont une prise en charge améliorée pour la mise à l’échelle fractionnée et une compatibilité rétroactive (optionnelle) pour les raccourcis généraux de X11 et l’émulation d’entrée (input).

Un support complet en bonne voie

Dans le billet, on trouve d’autres éléments intéressants. Par exemple, au sein de KDE lui-même, le support de X11 reste présent, permettant de lancer des applications KDE dans d’autres environnements de bureau. Le support des cartes NVIDIA est jugé en très bon état, même s’il faut passer par le pilote propriétaire. Côté accessibilité, l’équipe estime que les fonctions sont au même niveau qu’avec X11, avec des améliorations spécifiques dans Wayland, notamment dans les gestes tactiles sur touchpad. Il pourrait cependant y avoir quelques problèmes avec d’autres fonctions fournies par certaines applications tierces.

Les développeurs de KDE précisent quand même qu’il reste un certain nombre de problèmes importants, mais que le travail de correction est en bonne voie. Une partie d’entre eux seront corrigés dès la prochaine mouture 6.6, comme la mise en miroir pour la sortie vidéo. D’autres soucis, comme la restauration de session ou la mémorisation des positions de fenêtres, sont « activement travaillés ».

Il s’écoulera donc du temps avant que X11 disparaisse de KDE Plasma, mais le compte à rebours est lancé. Selon le calendrier actuel, KDE Plasma 6.8 est prévu pour octobre 2026, laissant près d’un an pour corriger les derniers problèmes. À noter que la plupart des distributions avec KDE proposent par défaut une session Wayland depuis un moment maintenant.

Tic tac

Toujours dans le lent cheminement menant de X11 à Wayland, l’équipe de KDE vient de confirmer le 26 novembre que la future mouture 6.8 de KDE Plasma n’aura plus de session X11.

Plasma 6.8 n’aura donc plus qu’une session Wayland. Comme GNOME récemment, les applications X11 seront confiées aux bons soins de XWayland. Comme nous l’avions expliqué dans notre dossier dédié, ce dernier permet de traiter les demandes pour l’ancien serveur d’affichage en enfermant ce dernier dans un client Wayland. La session X11, elle, disparaitra. Selon l’équipe de développement, « ce changement ouvre de nouvelles opportunités pour les fonctionnalités, les optimisations et la rapidité de développement ».

• X11, Wayland : pourquoi la transition est-elle aussi longue ?

KDE lance le compte à rebours

Dans l’ensemble, l’équipe de KDE prévoit un support de X11 dans Plasma jusqu’à début 2027. Le support pourrait être plus long dans Plasma 6.7, l’équipe prévoyant de publier des versions supplémentaires de corrections de bugs. Pour un besoin plus long, le billet recommande de s’orienter vers des distributions dont le support LTS garantit la présence de X11 pour l’instant. AlmaLinux 9 et son support jusqu’en 2032 sont donnés comme exemple.

L’équipe de KDE veut rassurer sur le support des applications via XWayland. Elle précise qu’elle a ajouté des fonctions supplémentaires de compatibilité, dont une prise en charge améliorée pour la mise à l’échelle fractionnée et une compatibilité rétroactive (optionnelle) pour les raccourcis généraux de X11 et l’émulation d’entrée (input).

Un support complet en bonne voie

Dans le billet, on trouve d’autres éléments intéressants. Par exemple, au sein de KDE lui-même, le support de X11 reste présent, permettant de lancer des applications KDE dans d’autres environnements de bureau. Le support des cartes NVIDIA est jugé en très bon état, même s’il faut passer par le pilote propriétaire. Côté accessibilité, l’équipe estime que les fonctions sont au même niveau qu’avec X11, avec des améliorations spécifiques dans Wayland, notamment dans les gestes tactiles sur touchpad. Il pourrait cependant y avoir quelques problèmes avec d’autres fonctions fournies par certaines applications tierces.

Les développeurs de KDE précisent quand même qu’il reste un certain nombre de problèmes importants, mais que le travail de correction est en bonne voie. Une partie d’entre eux seront corrigés dès la prochaine mouture 6.6, comme la mise en miroir pour la sortie vidéo. D’autres soucis, comme la restauration de session ou la mémorisation des positions de fenêtres, sont « activement travaillés ».

Il s’écoulera donc du temps avant que X11 disparaisse de KDE Plasma, mais le compte à rebours est lancé. Selon le calendrier actuel, KDE Plasma 6.8 est prévu pour octobre 2026, laissant près d’un an pour corriger les derniers problèmes. À noter que la plupart des distributions avec KDE proposent par défaut une session Wayland depuis un moment maintenant.

Rien d'important

Au cours des trois dernières semaines, de nombreuses mairies françaises ont dû avertir une partie de leurs administrés : plusieurs de leurs données personnelles se sont retrouvées dans la nature. Ces piratages, qui seraient menés par le même groupe, s’inscrivent dans un contexte plus large d’attaques contre des prestataires de services.

Un nombre important de mairies, dont beaucoup en Bretagne, ont signalé des incidents cyber. Tous en commun une fuite d’informations : nom, prénom et, selon les cas, adresse postale, adresse e-mail et numéro de téléphone. Des données non sensibles, mais qui peuvent alimenter ensuite les grandes opérations de phishing.

La première mairie à avoir communiqué sur le sujet semble être Brest, le 14 novembre, faisant état d’une fuite de 50 000 données environ. Sur X, SaxX s’empare du sujet et commence à faire l’historique des fuites en commençant par Brest. Le 19 novembre, c’était au tour de Quimper avec 12 000 données, puis le chiffre total s’est rapidement approché des 100 000 avec plusieurs autres villes de Bretagne. Le même jour, on apprenait que la mairie d’Alfortville (Île-de-France cette fois) commençait à envoyer des e-mails concernant là encore une fuite, avec toujours les mêmes caractéristiques.

Il est rapidement apparu que toutes ces mairies n’avaient pas été directement piratées. Les attaques étaient dirigées contre des prestataires de services, notamment deux plateformes fournissant des solutions de prises de rendez-vous : RDV360 et SynBird. Sur le site Bonjourlafuite.eu.org, on peut voir plusieurs mairies référencées, avec des captures des messages envoyés aux personnes concernées.

Plus précisément, les informations sont celles données par les administrés lors des demandes de rendez-vous pour la production d’une pièce d’identité. Dans la plupart des cas, ces informations proviennent de demandes faites entre 2022 et 2025.

Une vigilance particulière demandée

Dans tous les communiqués ou presque, les mairies indiquent qu’une déclaration a été faite à la CNIL (elles y sont légalement tenues) et qu’une plainte a été déposée. Si certaines communications ne le mentionnent pas, d’autres indiquent clairement qu’il s’agit d’un piratage de l’un des deux prestataires, RDV360 ou Synbird.

La fuite toucherait 1 300 communes, selon Le Parisien. Dans ses colonnes, la société savoyarde Synbird a réagi, confirmant le problème : « La fuite concerne les clients qui utilisent notre module de rendez-vous et de réservations de salle. Elle est circonscrite aux rendez-vous pris de début à fin octobre ». L’entreprise affirme avoir retracé l’origine du problème jusqu’à un poste d’employé municipal.

C’est la réutilisation d’un mot de passe, obtenu par une autre fuite, qui aurait permis aux pirates d’accéder au compte d’une mairie cliente. « L’attaquant a ensuite exploité une faille de sécurité dans le logiciel pour exporter des données. Ce problème a depuis été réglé par nos développeurs », a précisé Synbird, qui a ajouté que l’incident avait été déclaré à la CNIL et qu’un dépôt de plainte à la gendarmerie était en cours.

Les conseils donnés dans la plupart des cas sont les mêmes que ceux de la mairie de Brest dans son communiqué du 14 novembre : « aux personnes ayant fait une demande de pièces d’identité pendant cette période une vigilance particulière notamment en cas de démarchages inhabituels par mail et/ou téléphone, ou de demandes de coordonnées bancaires, même émise d’un opérateur connu des usagers ».

Sur son compte, SaxX affirme que ces fuites, pour des données allant de 2021 à novembre 2025, ont été orchestrées par un groupe de cybercriminels nommé « dumpsec » (qui est curieusement le nom d’un outil de sécurité utilisé pour des audits). Ce groupe aurait contacté le hacker et lui aurait fourni un échantillon « de 20 000 lignes concernant RDV360 ». Sur l’ensemble des mairies touchées par l’incident, 14 millions de données auraient été aspirées.

« Aucune donnée sensible »

La plupart des communiqués, à l’instar de ceux d’Ergué-Gébaric et de Guipavas, mettent l’accent sur l’absence de données « sensibles » dans les fuites. « Aucune donnée sensible, aucun document ou pièce d’identité, aucune donnée financière et aucun mot de passe n’ont été prélevés », peut-on lire par exemple dans le communiqué de Guipavas.

Pour autant, ces informations peuvent se révéler dangereuses. Elles alimentent les campagnes de phishing, et peuvent parfois servir à des attaques plus personnalisées, comme on l’a vu avec Ledger très récemment. Même sans ce type d’attaque plus ciblée, les numéros de téléphone et adresses e-mail intègrent de vastes bases de données exploitées pour des tentatives d’arnaques en tous genres.

• Du phishing ciblé directement dans votre boite aux lettres physique, le cas Ledger

Sans aller jusqu’à la communication de Pandora en aout dernier, ce type de communication tend à banaliser les fuites d’informations jugées « non sensibles ». Il est malheureusement vrai que ces fuites sont devenues monnaie courante, avec d’énormes opérations au cours des deux dernières années notamment, dont celles des deux plus gros prestataires de tiers payant en France, ou encore le cas emblématique de France Travail.

On remarque également que ces fuites interviennent une fois de plus dans le cadre de l’exploitation d’une faille chez un partenaire, comme c’était le cas pour France Travail.

Rien d'important

Au cours des trois dernières semaines, de nombreuses mairies françaises ont dû avertir une partie de leurs administrés : plusieurs de leurs données personnelles se sont retrouvées dans la nature. Ces piratages, qui seraient menés par le même groupe, s’inscrivent dans un contexte plus large d’attaques contre des prestataires de services.

Un nombre important de mairies, dont beaucoup en Bretagne, ont signalé des incidents cyber. Tous en commun une fuite d’informations : nom, prénom et, selon les cas, adresse postale, adresse e-mail et numéro de téléphone. Des données non sensibles, mais qui peuvent alimenter ensuite les grandes opérations de phishing.

La première mairie à avoir communiqué sur le sujet semble être Brest, le 14 novembre, faisant état d’une fuite de 50 000 données environ. Sur X, SaxX s’empare du sujet et commence à faire l’historique des fuites en commençant par Brest. Le 19 novembre, c’était au tour de Quimper avec 12 000 données, puis le chiffre total s’est rapidement approché des 100 000 avec plusieurs autres villes de Bretagne. Le même jour, on apprenait que la mairie d’Alfortville (Île-de-France cette fois) commençait à envoyer des e-mails concernant là encore une fuite, avec toujours les mêmes caractéristiques.

Il est rapidement apparu que toutes ces mairies n’avaient pas été directement piratées. Les attaques étaient dirigées contre des prestataires de services, notamment deux plateformes fournissant des solutions de prises de rendez-vous : RDV360 et SynBird. Sur le site Bonjourlafuite.eu.org, on peut voir plusieurs mairies référencées, avec des captures des messages envoyés aux personnes concernées.

Plus précisément, les informations sont celles données par les administrés lors des demandes de rendez-vous pour la production d’une pièce d’identité. Dans la plupart des cas, ces informations proviennent de demandes faites entre 2022 et 2025.

Une vigilance particulière demandée

Dans tous les communiqués ou presque, les mairies indiquent qu’une déclaration a été faite à la CNIL (elles y sont légalement tenues) et qu’une plainte a été déposée. Si certaines communications ne le mentionnent pas, d’autres indiquent clairement qu’il s’agit d’un piratage de l’un des deux prestataires, RDV360 ou Synbird.

La fuite toucherait 1 300 communes, selon Le Parisien. Dans ses colonnes, la société savoyarde Synbird a réagi, confirmant le problème : « La fuite concerne les clients qui utilisent notre module de rendez-vous et de réservations de salle. Elle est circonscrite aux rendez-vous pris de début à fin octobre ». L’entreprise affirme avoir retracé l’origine du problème jusqu’à un poste d’employé municipal.

C’est la réutilisation d’un mot de passe, obtenu par une autre fuite, qui aurait permis aux pirates d’accéder au compte d’une mairie cliente. « L’attaquant a ensuite exploité une faille de sécurité dans le logiciel pour exporter des données. Ce problème a depuis été réglé par nos développeurs », a précisé Synbird, qui a ajouté que l’incident avait été déclaré à la CNIL et qu’un dépôt de plainte à la gendarmerie était en cours.

Les conseils donnés dans la plupart des cas sont les mêmes que ceux de la mairie de Brest dans son communiqué du 14 novembre : « aux personnes ayant fait une demande de pièces d’identité pendant cette période une vigilance particulière notamment en cas de démarchages inhabituels par mail et/ou téléphone, ou de demandes de coordonnées bancaires, même émise d’un opérateur connu des usagers ».

Sur son compte, SaxX affirme que ces fuites, pour des données allant de 2021 à novembre 2025, ont été orchestrées par un groupe de cybercriminels nommé « dumpsec » (qui est curieusement le nom d’un outil de sécurité utilisé pour des audits). Ce groupe aurait contacté le hacker et lui aurait fourni un échantillon « de 20 000 lignes concernant RDV360 ». Sur l’ensemble des mairies touchées par l’incident, 14 millions de données auraient été aspirées.

« Aucune donnée sensible »

La plupart des communiqués, à l’instar de ceux d’Ergué-Gébaric et de Guipavas, mettent l’accent sur l’absence de données « sensibles » dans les fuites. « Aucune donnée sensible, aucun document ou pièce d’identité, aucune donnée financière et aucun mot de passe n’ont été prélevés », peut-on lire par exemple dans le communiqué de Guipavas.

Pour autant, ces informations peuvent se révéler dangereuses. Elles alimentent les campagnes de phishing, et peuvent parfois servir à des attaques plus personnalisées, comme on l’a vu avec Ledger très récemment. Même sans ce type d’attaque plus ciblée, les numéros de téléphone et adresses e-mail intègrent de vastes bases de données exploitées pour des tentatives d’arnaques en tous genres.

• Du phishing ciblé directement dans votre boite aux lettres physique, le cas Ledger

Sans aller jusqu’à la communication de Pandora en aout dernier, ce type de communication tend à banaliser les fuites d’informations jugées « non sensibles ». Il est malheureusement vrai que ces fuites sont devenues monnaie courante, avec d’énormes opérations au cours des deux dernières années notamment, dont celles des deux plus gros prestataires de tiers payant en France, ou encore le cas emblématique de France Travail.

On remarque également que ces fuites interviennent une fois de plus dans le cadre de l’exploitation d’une faille chez un partenaire, comme c’était le cas pour France Travail.

Fin mars, Plex annonçait à la fois une hausse des prix et un changement d’approche pour la diffusion des contenus médias en dehors de son réseau domestique. En clair, il s’agissait de faire passer les utilisateurs à la caisse.

• Plex revoit ses prix à la hausse et lance une option payante pour la lecture à distance

Sans toucher à la diffusion domestique, il était proposé deux manières de payer, selon le contexte. Pour la personne ayant le serveur et les contenus, une formule Plex Pass (6,99 dollars par mois ou 69,99 dollars par an) déverrouillait la possibilité de streamer vers des personnes extérieures au réseau, par internet donc. Dans l’autre sens, une personne peut payer 1,99 dollar par mois (ou 19,99 dollars par an) pour un Remote Watch Pass, permettant l’accès à un serveur Plex distant, sans que son possesseur ait besoin d’un Plex Pass.

Il était prévu que ces règles entrent en vigueur à compter du 29 avril, mais l’application ne se fait réellement que cette semaine, en commençant par l’application Roku. L’équipe a confirmé le changement dans un message dans son forum le 20 novembre et repéré par How-To Geek le 25.

Si cette obligation est limitée pour l’instant, elle sera généralisée l’année prochaine à toutes les autres applications (Android TV, Apple TV, FireTV…) « ainsi qu’à tout client tiers utilisant l’API pour proposer le streaming à distance ».

Rappelons que ces changements concernent l’accès distant pour les serveurs Plex. Les personnes utilisant cette solution de streaming pour de la diffusion locale ne sont pas concernées.