Il y a le bon CVE et le mauvais CVE

La publication en 48 heures de 432 bulletins CVE pour le noyau Linux a provoqué des interrogations sur la meilleure manière d’intégrer un tel flot de corrections dans les environnements de production. La situation est plus complexe qu’il n’y paraît.

Entre les 20 et 21 juillet, un lot conséquent de 432 CVE a été publié pour le noyau Linux. Cela ne signifie pas que 432 failles ont été corrigées, car le fonctionnement des CVE est différent pour le noyau. En revanche, ils correspondent quand même à des corrections portées dans la branche principale par les mainteneurs du noyau. Se pose alors la question de leur répercussion concrète.

D’abord, qu’est-ce qu’un CVE ? C’est un identifiant unique (Common Vulnerabilities and Exposures) attribué à une faille de sécurité informatique connue publiquement. Une telle vulnérabilité se définit par une faiblesse de la logique d’un logiciel, permettant alors à un attaquant de violer la politique de sécurité et d’effectuer des actions auxquelles il n’a normalement pas droit. Dans la plupart des cas, les CVE sont publiés avant les correctifs associés, car ils servent souvent de base pour les bulletins de sécurité. Le CVE s’accompagne généralement d’un score CVSS (Common Vulnerability Scoring System), censé représenter le niveau de dangerosité de la faille, et de détails contextuels (vecteur d’attaque à distance, niveau de privilèges requis, etc.).

• CVSS 4.0 : dur, dur, d’être un expert !

Il y a CVE et CVE

Les CVE sont attribués par les CNA (CVE Numbering Authorities). Or, depuis février 2024, le projet Linux est devenu sa propre autorité de numérotation, avec des règles spécifiques pour répondre à l’échelle de son immense base de code.

Pour comprendre la situation actuelle, il faut retenir que ces règles sont inversées par rapport au reste de l’industrie. Dans un cas classique, la découverte d’une faille entraine l’attribution d’un CVE, l’alerte puis le développement du patch. Que les détails soient parfois publiés plus tard n’y change rien, le CVE est attribué d’abord. Au sein du projet Linux, c’est le contraire : la découverte d’une faiblesse dans le code entraine le développement d’un patch puis la fusion de celui-ci dans les branches stables du noyau, et seulement après l’apparition d’un CVE. Ce qui signifie qu’au sein du noyau Linux, les failles non corrigées n’ont pas de CVE.

Autre précision importante : l’équipe du noyau attribue systématiquement un CVE à tout correctif de bug susceptible d’impacter la stabilité ou l’accès mémoire, sans chercher à qualifier si le bug est facilement exploitable ou non. C’est ce qu’expliquait sur son blog Greg Kroah-Hartman, mainteneur principal des branches stables du noyau, en février dernier. De même, aucun score CVSS n’est produit, et pour cause : les développeurs du noyau ne connaissent pas l’usage fait de Linux, donc dans quel type d’environnement le code sera exécuté.

En revanche, là où un CVE traditionnel décrit un comportement de haut niveau, un CVE Linux correspond directement à un identifiant de commit Git. Ce suivi automatisé explique pourquoi l’utilisation massive de fuzzers et d’outils d’analyse statique génère des pics soudains de plusieurs centaines de CVE.

Mais alors, où est le problème ?

Si la publication de 432 CVE est en soi inédite, ils correspondent donc à des bugs déjà corrigés. Pourtant Jan Schaumann, architecte en chef de la sécurité de l’information chez Akamai Technologies, s’en est plaint sur la liste de diffusion OSS-SEC. Il y exprime son inquiétude devant un tel volume, demandant comment les entreprises, et de manière générale les environnements de production, peuvent suivre un tel rythme.

Mais en quoi est-ce un problème ? Si les failles sont déjà corrigées, ne suffit-il pas d’attendre sagement la prochaine révision du noyau ? Ce n’est pas si simple.

Plusieurs éléments doivent être considérés. D’un côté, les corrections intégrées aux branches stables signifient que toutes les versions actuellement supportées du noyau Linux vont les répercuter. En théorie, il suffirait d’installer la version suivante dans la branche utilisée, par exemple la 7.2 si l’on utilise une distribution évoluant avec les versions les plus récentes. De l’autre, les environnements de production utilisent souvent des versions modifiées, voire d’anciennes versions dans lesquelles les équipes « backportent » (rétroportent) les modifications qui les intéressent.

C’est là que survient le problème dont se plaint Jan Schaumann : quand 432 CVE sont publiés en 24 heures, comment savoir ce qui est important et doit être rétroporté ? Dans un courrier envoyé à The Register, il évoque la possibilité de faire travailler des LLM pour gérer automatiquement le flux. « Des mises à jour automatisées, régulières et fréquentes qui intègrent tous les changements dans un délai donné me semblent la seule approche raisonnable, mais cela est très difficile pour de nombreuses grandes organisations », explique-t-il ainsi.

Le dernier noyau disponible, toujours

Sur la liste de diffusion OSS-SEC, la discussion présente des réponses intéressantes, notamment celle de Greg Kroah-Hartman en personne. Bien qu’il ne réagisse pas directement au message initial, les solutions envisagées par d’autres sont passées en revue, et il donne nettement sa préférence : toujours utiliser le dernier noyau stable disponible sur la branche souhaitée et vérifier régulièrement l’ensemble des systèmes gérés.

Kroah-Hartman reconnait que ce n’est pas toujours simple au sein des entreprises, mais que des produits payants permettent de gérer efficacement ce processus. Si payer un tel produit n’est pas possible, il recommande d’installer des distributions comme Debian ou Yocto, car « leurs pratiques de sécurité sont extraordinaires ». Les autres solutions représentent plus de travail ou une sécurité moindre. Vérifier un par un les CVE pour ne considérer que ceux importants dans l’infrastructure ? On peut le faire de manière automatisée pour vérifier ce qui ressort à l’intersection des fichiers visés par les CVE et des fichiers réellement utilisés dans l’environnement géré. Mais on en revient à la proposition de Jan Schaumann, et toutes les organisations ne peuvent pas se permettre un tel pipeline de gestion.

En d’autres termes, la meilleure solution reste la répercussion des nouveaux noyaux quand ils deviennent disponibles, mais l’explosion du nombre de CVE – très probablement portée par l’utilisation croissante des LLM – rend la lecture plus complexe. Pour Greg Kroah-Hartman cependant, il n’y a pas vraiment de problème : les 432 CVE étaient en préparation depuis des semaines, personne ne devrait être surpris.

Il y a le bon CVE et le mauvais CVE

La publication en 48 heures de 432 bulletins CVE pour le noyau Linux a provoqué des interrogations sur la meilleure manière d’intégrer un tel flot de corrections dans les environnements de production. La situation est plus complexe qu’il n’y paraît.

Entre les 20 et 21 juillet, un lot conséquent de 432 CVE a été publié pour le noyau Linux. Cela ne signifie pas que 432 failles ont été corrigées, car le fonctionnement des CVE est différent pour le noyau. En revanche, ils correspondent quand même à des corrections portées dans la branche principale par les mainteneurs du noyau. Se pose alors la question de leur répercussion concrète.

D’abord, qu’est-ce qu’un CVE ? C’est un identifiant unique (Common Vulnerabilities and Exposures) attribué à une faille de sécurité informatique connue publiquement. Une telle vulnérabilité se définit par une faiblesse de la logique d’un logiciel, permettant alors à un attaquant de violer la politique de sécurité et d’effectuer des actions auxquelles il n’a normalement pas droit. Dans la plupart des cas, les CVE sont publiés avant les correctifs associés, car ils servent souvent de base pour les bulletins de sécurité. Le CVE s’accompagne généralement d’un score CVSS (Common Vulnerability Scoring System), censé représenter le niveau de dangerosité de la faille, et de détails contextuels (vecteur d’attaque à distance, niveau de privilèges requis, etc.).

• CVSS 4.0 : dur, dur, d’être un expert !

Il y a CVE et CVE

Les CVE sont attribués par les CNA (CVE Numbering Authorities). Or, depuis février 2024, le projet Linux est devenu sa propre autorité de numérotation, avec des règles spécifiques pour répondre à l’échelle de son immense base de code.

Pour comprendre la situation actuelle, il faut retenir que ces règles sont inversées par rapport au reste de l’industrie. Dans un cas classique, la découverte d’une faille entraine l’attribution d’un CVE, l’alerte puis le développement du patch. Que les détails soient parfois publiés plus tard n’y change rien, le CVE est attribué d’abord. Au sein du projet Linux, c’est le contraire : la découverte d’une faiblesse dans le code entraine le développement d’un patch puis la fusion de celui-ci dans les branches stables du noyau, et seulement après l’apparition d’un CVE. Ce qui signifie qu’au sein du noyau Linux, les failles non corrigées n’ont pas de CVE.

Autre précision importante : l’équipe du noyau attribue systématiquement un CVE à tout correctif de bug susceptible d’impacter la stabilité ou l’accès mémoire, sans chercher à qualifier si le bug est facilement exploitable ou non. C’est ce qu’expliquait sur son blog Greg Kroah-Hartman, mainteneur principal des branches stables du noyau, en février dernier. De même, aucun score CVSS n’est produit, et pour cause : les développeurs du noyau ne connaissent pas l’usage fait de Linux, donc dans quel type d’environnement le code sera exécuté.

En revanche, là où un CVE traditionnel décrit un comportement de haut niveau, un CVE Linux correspond directement à un identifiant de commit Git. Ce suivi automatisé explique pourquoi l’utilisation massive de fuzzers et d’outils d’analyse statique génère des pics soudains de plusieurs centaines de CVE.

Mais alors, où est le problème ?

Si la publication de 432 CVE est en soi inédite, ils correspondent donc à des bugs déjà corrigés. Pourtant Jan Schaumann, architecte en chef de la sécurité de l’information chez Akamai Technologies, s’en est plaint sur la liste de diffusion OSS-SEC. Il y exprime son inquiétude devant un tel volume, demandant comment les entreprises, et de manière générale les environnements de production, peuvent suivre un tel rythme.

Mais en quoi est-ce un problème ? Si les failles sont déjà corrigées, ne suffit-il pas d’attendre sagement la prochaine révision du noyau ? Ce n’est pas si simple.

Plusieurs éléments doivent être considérés. D’un côté, les corrections intégrées aux branches stables signifient que toutes les versions actuellement supportées du noyau Linux vont les répercuter. En théorie, il suffirait d’installer la version suivante dans la branche utilisée, par exemple la 7.2 si l’on utilise une distribution évoluant avec les versions les plus récentes. De l’autre, les environnements de production utilisent souvent des versions modifiées, voire d’anciennes versions dans lesquelles les équipes « backportent » (rétroportent) les modifications qui les intéressent.

C’est là que survient le problème dont se plaint Jan Schaumann : quand 432 CVE sont publiés en 24 heures, comment savoir ce qui est important et doit être rétroporté ? Dans un courrier envoyé à The Register, il évoque la possibilité de faire travailler des LLM pour gérer automatiquement le flux. « Des mises à jour automatisées, régulières et fréquentes qui intègrent tous les changements dans un délai donné me semblent la seule approche raisonnable, mais cela est très difficile pour de nombreuses grandes organisations », explique-t-il ainsi.

Le dernier noyau disponible, toujours

Sur la liste de diffusion OSS-SEC, la discussion présente des réponses intéressantes, notamment celle de Greg Kroah-Hartman en personne. Bien qu’il ne réagisse pas directement au message initial, les solutions envisagées par d’autres sont passées en revue, et il donne nettement sa préférence : toujours utiliser le dernier noyau stable disponible sur la branche souhaitée et vérifier régulièrement l’ensemble des systèmes gérés.

Kroah-Hartman reconnait que ce n’est pas toujours simple au sein des entreprises, mais que des produits payants permettent de gérer efficacement ce processus. Si payer un tel produit n’est pas possible, il recommande d’installer des distributions comme Debian ou Yocto, car « leurs pratiques de sécurité sont extraordinaires ». Les autres solutions représentent plus de travail ou une sécurité moindre. Vérifier un par un les CVE pour ne considérer que ceux importants dans l’infrastructure ? On peut le faire de manière automatisée pour vérifier ce qui ressort à l’intersection des fichiers visés par les CVE et des fichiers réellement utilisés dans l’environnement géré. Mais on en revient à la proposition de Jan Schaumann, et toutes les organisations ne peuvent pas se permettre un tel pipeline de gestion.

En d’autres termes, la meilleure solution reste la répercussion des nouveaux noyaux quand ils deviennent disponibles, mais l’explosion du nombre de CVE – très probablement portée par l’utilisation croissante des LLM – rend la lecture plus complexe. Pour Greg Kroah-Hartman cependant, il n’y a pas vraiment de problème : les 432 CVE étaient en préparation depuis des semaines, personne ne devrait être surpris.

Première fois, mais pas la dernière

Dans un billet de blog, l’entreprise explique comment l’apparition d’une faille critique dans le moteur de virtualisation KVM a entrainé une vaste campagne de mises à jour dans ses infrastructures. Elle a choisi une approche radicale, avec un impact assumé sur les clients, prévenus en amont.

L’incident débute le 6 juillet, quand les détails d’une faille critique apparaissent. Estampillée CVE-2026-53359 et surnommée Januscape, elle réside dans le code de shadow paging du moteur de virtualisation KVM sur l’architecture x86.

« KVM constitue le moteur de virtualisation sur lequel repose l’immense majorité des instances hébergées chez OVHcloud. Le mécanisme est le suivant : lorsqu’une modification externe d’un Page Directory Entry (PDE) survient, l’entrée RMAP peut conserver une référence vers une page mémoire déjà libérée. Le noyau déréférence ensuite cette page obsolète, ce qui peut entraîner un plantage de l’hyperviseur ou, dans les scénarios les plus défavorables, une élévation de privilège côté hôte. L’exploit est reproductible : un test interne sur un hôte non patché provoque un crash en environ deux minutes », explique OVHcloud dans son billet.

Le lendemain, OVHcloud déclenche une cellule de crise pour aborder la situation, avec la question centrale : comment mettre à jour des dizaines de milliers de serveurs hôtes hyperviseurs, représentant environ un million de machines virtuelles ?

Cinq solutions, aucune idéale

Comme l’entreprise l’explique dans son billet, cinq possibilités étaient sur la table. Elle pouvait attendre l’arrivée des noyaux Linux officiels mis à jour, mais elle aurait été alors « tributaire d’un agenda tiers ». Un live patch ? Une opération « sensible par nature », qui permet de gagner du temps mais entraine aussi une réduction du niveau de durcissement et une baisse des capacités de détection en cas de compromission.

OVHcloud a considéré rapidement la désactivation de la virtualisation imbriquée, qui permet notamment de lancer des machines virtuelles à l’intérieur d’autres machines virtuelles. La solution est écartée, faute de pouvoir mesurer l’impact sur les clients.

Une piste plus sérieuse était la migration live, depuis des hôtes vulnérables vers d’autres vides et patchés. L’option est décrite comme « très satisfaisante » pour la continuité, sans impact sur les machines virtuelles. Elle a toutefois un sérieux désavantage : elle prend beaucoup de temps. OVHcloud la garde sous le coude pour certaines machines critiques.

La solution adoptée consiste finalement à mettre les mains dans le cambouis, en intégrant soi-même le patch dans les noyaux utilisés, en diffusant ces derniers et en redémarrant la totalité des hôtes.

Un « patching unilatéral à impact contrôlé »

Le choix de cette solution est « assumé », selon OVHcloud. Elle affirme qu’il s’agissait de la seule solution possible pour tenir compte des paramètres : la criticité de la faille, le nombre de machines à traiter et le degré de perturbation pour les clients. « Une action rapide et globale protège le plus grand nombre, quitte à impacter une minorité de manière temporaire », ajoute OVHcloud.

Tout s’est très vite enchainé. Le soir du 7 juillet, le « backport » du correctif est réalisé dans le noyau et les tests de validation commencent. Dans les heures qui suivent, les équipes confirment que le noyau mis à jour n’est plus sensible à la faille. Dans la foulée, le comité exécutif donne son feu vert pour un déploiement dès le lendemain matin.

OVHcloud n’a cependant pas déclenché ce déploiement sur la totalité des machines virtuelles au même instant. L’opération commence dans la région Sydney, avec plusieurs avantages : le nombre d’hôtes est limité, la plage de déploiement correspond aux heures de bureau en France et l’entreprise pourra collecter les premiers retours, avant de se tourner vers des déploiements plus importants. Le 8 juillet, en début d’après-midi (heure de Paris), tous les hôtes VPS (Virtual Private Server) de la région sont mis à jour et redémarrés.

L’entreprise suit littéralement le soleil : « Chaque région prend le relais à son tour, sur sa matinée locale, en transmettant le contexte à la suivante ». Elle estime avoir récolté assez de retours pour lancer la première vague européenne sur les VPS (RBX, GRA6, WAW, DE, SBG, MIL, UK) à 18h30, toujours le 8 juillet. À chaque fois, les VPS sont migrés les premiers, l’offre Public Cloud présentant d’autres défis. Les régions à plus faible densité sont traitées d’abord, tandis que celles à fort volume sont « orchestrées avec une granularité plus fine, lot par lot, pour diluer le risque ».

Plusieurs mécanismes ont été mis en place pour limiter les risques pendant les opérations, notamment des seuils d’arrêt. Chaque vague de redémarrages était bornée par un seuil d’arrêt automatique : 15 hôtes en panne simultanée pour les régions à forte densité (GRA, RBX, BHS), 5 hôtes pour les autres, avec arrêt systématique à 06h00 locales ou sur demande du centre de données. Ce mécanisme vise à ne pas superposer des redémarrages supplémentaires à une situation de panne matérielle déjà en cours de traitement.

Les orchestrateurs ont en outre calculé un graphe de co-localisation par projet et ont défini des vagues mutuellement exclusives. Ainsi, deux hôtes portant des instances du même projet ne sont jamais redémarrés dans la même fenêtre, un hôte devant être revenu en service avant le lancement du suivant dans la même classe. Cette règle est appliquée en « best effort », non garantie à 100 % sur l’ensemble du parc.

Des incidents quand même

Malgré les précautions, des problèmes sont quand même apparus. Certaines machines virtuelles n’ont pas redémarré après le reboot de leur hôte, dès la première vague européenne. Un conflit a été détecté entre libvirt-guests.service et Nova Compute, provoquant l’arrêt des instances sans synchronisation API.

Dès le deuxième jour, un problème de corruption de données est apparu sur des services synchrones. Des machines virtuelles réparties sur trois clusters ont présenté des données corrompues, à cause probablement d’un redémarrage forcé en pleine écriture disque. La période d’attente avant kill forcé a été étendue à 60 secondes, et un script de redémarrage automatique des VM restées éteintes a été déployé.

À Paris, dans la nuit du deuxième au troisième jour, des soucis de saturation mutuelle sont apparus entre les API Nova et Neutron. Cette dernière plafonnant à 10 processus, la situation a provoqué deux heures de panne HTTP 503. Le correctif appliqué a consisté à augmenter le nombre de workers Neutron de 10 à 30 et celui des processus Apache de 10 à 32.

Sur le plan matériel, environ 20 à 30 hôtes sur 6 000 ne sont pas revenus seuls après la première nuit de redémarrages (barrettes mémoire défaillantes, configuration BIOS, interfaces réseau inactives), indique OVHcloud. Certains cas aux États-Unis ont même nécessité un retrait de la batterie CMOS et un drain d’alimentation. Des techniciens ont été mobilisés en renfort sur chaque site pour intervenir en priorité sur les hôtes en échec.

En tout, l’opération s’est étalée sur 11 jours.

Ce type d’opération se reproduira, assure OVHcloud

Côté communication aux clients, la stratégie retenue a été l’envoi de messages ciblés de manière progressive, déclenché région par région et vague par vague, aux seuls clients concernés par les hôtes programmés.

Le choix initial de ne pas ouvrir de page publique de statut visait à ne pas exposer la séquence de déploiement, un arbitrage voulu entre transparence et risque (éviter d’inciter des clients à tester l’exploit). Les limites de ce dispositif sont pointées par OVHcloud : pour GRA6 (près de 90 000 clients non contactés), l’envoi massif d’e-mails a été écarté pour ne pas saturer le support, ce qui a conduit à un pivot vers une bannière conditionnelle dans le Manager (basée sur une liste de comptes impactés) le lendemain et – finalement – la création d’une page de statut Public Cloud le jour suivant.

En revanche, malgré les détails fournis par l’entreprise, le descriptif est essentiellement qualitatif : on ne connait pas le nombre total d’incidents clients, la durée cumulée d’indisponibilité, ni les éventuelles compensations.

L’entreprise indique en tout cas avoir tiré des enseignements de cette migration, car elle n’avait jamais été confrontée à une situation critique d’une telle ampleur, les épisodes précédents ayant été traités par rotation naturelle du parc combinée à des migrations live planifiées sur une durée longue.

OVHcloud se veut claire également : ce type de procédure d’urgence est amené à se reproduire compte tenu du rythme des publications de vulnérabilités noyau, sous l’impulsion de l’IA générative notamment. Les axes d’amélioration identifiés par l’entreprise portent sur trois points : la maîtrise de l’impact brut des redémarrages, l’information en amont des clients, et la procédure d’accompagnement des clients impactés. L’entreprise évoque donc un « exploit » réalisé par ses équipes, mais ajoute : « Nous devrons faire mieux la prochaine fois, aussi bien dans la maîtrise de l’impact brut des redémarrages que dans l’information en amont des clients et dans la procédure d’accompagnement des clients impactés lors des opérations ».

Première fois, mais pas la dernière

Dans un billet de blog, l’entreprise explique comment l’apparition d’une faille critique dans le moteur de virtualisation KVM a entrainé une vaste campagne de mises à jour dans ses infrastructures. Elle a choisi une approche radicale, avec un impact assumé sur les clients, prévenus en amont.

L’incident débute le 6 juillet, quand les détails d’une faille critique apparaissent. Estampillée CVE-2026-53359 et surnommée Januscape, elle réside dans le code de shadow paging du moteur de virtualisation KVM sur l’architecture x86.

« KVM constitue le moteur de virtualisation sur lequel repose l’immense majorité des instances hébergées chez OVHcloud. Le mécanisme est le suivant : lorsqu’une modification externe d’un Page Directory Entry (PDE) survient, l’entrée RMAP peut conserver une référence vers une page mémoire déjà libérée. Le noyau déréférence ensuite cette page obsolète, ce qui peut entraîner un plantage de l’hyperviseur ou, dans les scénarios les plus défavorables, une élévation de privilège côté hôte. L’exploit est reproductible : un test interne sur un hôte non patché provoque un crash en environ deux minutes », explique OVHcloud dans son billet.

Le lendemain, OVHcloud déclenche une cellule de crise pour aborder la situation, avec la question centrale : comment mettre à jour des dizaines de milliers de serveurs hôtes hyperviseurs, représentant environ un million de machines virtuelles ?

Cinq solutions, aucune idéale

Comme l’entreprise l’explique dans son billet, cinq possibilités étaient sur la table. Elle pouvait attendre l’arrivée des noyaux Linux officiels mis à jour, mais elle aurait été alors « tributaire d’un agenda tiers ». Un live patch ? Une opération « sensible par nature », qui permet de gagner du temps mais entraine aussi une réduction du niveau de durcissement et une baisse des capacités de détection en cas de compromission.

OVHcloud a considéré rapidement la désactivation de la virtualisation imbriquée, qui permet notamment de lancer des machines virtuelles à l’intérieur d’autres machines virtuelles. La solution est écartée, faute de pouvoir mesurer l’impact sur les clients.

Une piste plus sérieuse était la migration live, depuis des hôtes vulnérables vers d’autres vides et patchés. L’option est décrite comme « très satisfaisante » pour la continuité, sans impact sur les machines virtuelles. Elle a toutefois un sérieux désavantage : elle prend beaucoup de temps. OVHcloud la garde sous le coude pour certaines machines critiques.

La solution adoptée consiste finalement à mettre les mains dans le cambouis, en intégrant soi-même le patch dans les noyaux utilisés, en diffusant ces derniers et en redémarrant la totalité des hôtes.

Un « patching unilatéral à impact contrôlé »

Le choix de cette solution est « assumé », selon OVHcloud. Elle affirme qu’il s’agissait de la seule solution possible pour tenir compte des paramètres : la criticité de la faille, le nombre de machines à traiter et le degré de perturbation pour les clients. « Une action rapide et globale protège le plus grand nombre, quitte à impacter une minorité de manière temporaire », ajoute OVHcloud.

Tout s’est très vite enchainé. Le soir du 7 juillet, le « backport » du correctif est réalisé dans le noyau et les tests de validation commencent. Dans les heures qui suivent, les équipes confirment que le noyau mis à jour n’est plus sensible à la faille. Dans la foulée, le comité exécutif donne son feu vert pour un déploiement dès le lendemain matin.

OVHcloud n’a cependant pas déclenché ce déploiement sur la totalité des machines virtuelles au même instant. L’opération commence dans la région Sydney, avec plusieurs avantages : le nombre d’hôtes est limité, la plage de déploiement correspond aux heures de bureau en France et l’entreprise pourra collecter les premiers retours, avant de se tourner vers des déploiements plus importants. Le 8 juillet, en début d’après-midi (heure de Paris), tous les hôtes VPS (Virtual Private Server) de la région sont mis à jour et redémarrés.

L’entreprise suit littéralement le soleil : « Chaque région prend le relais à son tour, sur sa matinée locale, en transmettant le contexte à la suivante ». Elle estime avoir récolté assez de retours pour lancer la première vague européenne sur les VPS (RBX, GRA6, WAW, DE, SBG, MIL, UK) à 18h30, toujours le 8 juillet. À chaque fois, les VPS sont migrés les premiers, l’offre Public Cloud présentant d’autres défis. Les régions à plus faible densité sont traitées d’abord, tandis que celles à fort volume sont « orchestrées avec une granularité plus fine, lot par lot, pour diluer le risque ».

Plusieurs mécanismes ont été mis en place pour limiter les risques pendant les opérations, notamment des seuils d’arrêt. Chaque vague de redémarrages était bornée par un seuil d’arrêt automatique : 15 hôtes en panne simultanée pour les régions à forte densité (GRA, RBX, BHS), 5 hôtes pour les autres, avec arrêt systématique à 06h00 locales ou sur demande du centre de données. Ce mécanisme vise à ne pas superposer des redémarrages supplémentaires à une situation de panne matérielle déjà en cours de traitement.

Les orchestrateurs ont en outre calculé un graphe de co-localisation par projet et ont défini des vagues mutuellement exclusives. Ainsi, deux hôtes portant des instances du même projet ne sont jamais redémarrés dans la même fenêtre, un hôte devant être revenu en service avant le lancement du suivant dans la même classe. Cette règle est appliquée en « best effort », non garantie à 100 % sur l’ensemble du parc.

Des incidents quand même

Malgré les précautions, des problèmes sont quand même apparus. Certaines machines virtuelles n’ont pas redémarré après le reboot de leur hôte, dès la première vague européenne. Un conflit a été détecté entre libvirt-guests.service et Nova Compute, provoquant l’arrêt des instances sans synchronisation API.

Dès le deuxième jour, un problème de corruption de données est apparu sur des services synchrones. Des machines virtuelles réparties sur trois clusters ont présenté des données corrompues, à cause probablement d’un redémarrage forcé en pleine écriture disque. La période d’attente avant kill forcé a été étendue à 60 secondes, et un script de redémarrage automatique des VM restées éteintes a été déployé.

À Paris, dans la nuit du deuxième au troisième jour, des soucis de saturation mutuelle sont apparus entre les API Nova et Neutron. Cette dernière plafonnant à 10 processus, la situation a provoqué deux heures de panne HTTP 503. Le correctif appliqué a consisté à augmenter le nombre de workers Neutron de 10 à 30 et celui des processus Apache de 10 à 32.

Sur le plan matériel, environ 20 à 30 hôtes sur 6 000 ne sont pas revenus seuls après la première nuit de redémarrages (barrettes mémoire défaillantes, configuration BIOS, interfaces réseau inactives), indique OVHcloud. Certains cas aux États-Unis ont même nécessité un retrait de la batterie CMOS et un drain d’alimentation. Des techniciens ont été mobilisés en renfort sur chaque site pour intervenir en priorité sur les hôtes en échec.

En tout, l’opération s’est étalée sur 11 jours.

Ce type d’opération se reproduira, assure OVHcloud

Côté communication aux clients, la stratégie retenue a été l’envoi de messages ciblés de manière progressive, déclenché région par région et vague par vague, aux seuls clients concernés par les hôtes programmés.

Le choix initial de ne pas ouvrir de page publique de statut visait à ne pas exposer la séquence de déploiement, un arbitrage voulu entre transparence et risque (éviter d’inciter des clients à tester l’exploit). Les limites de ce dispositif sont pointées par OVHcloud : pour GRA6 (près de 90 000 clients non contactés), l’envoi massif d’e-mails a été écarté pour ne pas saturer le support, ce qui a conduit à un pivot vers une bannière conditionnelle dans le Manager (basée sur une liste de comptes impactés) le lendemain et – finalement – la création d’une page de statut Public Cloud le jour suivant.

En revanche, malgré les détails fournis par l’entreprise, le descriptif est essentiellement qualitatif : on ne connait pas le nombre total d’incidents clients, la durée cumulée d’indisponibilité, ni les éventuelles compensations.

L’entreprise indique en tout cas avoir tiré des enseignements de cette migration, car elle n’avait jamais été confrontée à une situation critique d’une telle ampleur, les épisodes précédents ayant été traités par rotation naturelle du parc combinée à des migrations live planifiées sur une durée longue.

OVHcloud se veut claire également : ce type de procédure d’urgence est amené à se reproduire compte tenu du rythme des publications de vulnérabilités noyau, sous l’impulsion de l’IA générative notamment. Les axes d’amélioration identifiés par l’entreprise portent sur trois points : la maîtrise de l’impact brut des redémarrages, l’information en amont des clients, et la procédure d’accompagnement des clients impactés. L’entreprise évoque donc un « exploit » réalisé par ses équipes, mais ajoute : « Nous devrons faire mieux la prochaine fois, aussi bien dans la maîtrise de l’impact brut des redémarrages que dans l’information en amont des clients et dans la procédure d’accompagnement des clients impactés lors des opérations ».

À boire et à manger

Le projet de loi Ripost a été définitivement adopté par le Parlement ce 21 juillet. Le texte vise à durcir le ton face à un certain nombre de troubles à l’ordre public. Mais si les rodéos urbains et le protoxyde d’azote font les gros titres, le texte contient également des mesures liées à la lecture automatisée des plaques d’immatriculation et à la vidéosurveillance algorithmique.

La loi Ripost – pour « réponses immédiates aux phénomènes troublant l’ordre public, la sécurité et la tranquillité de nos concitoyens » – a finalement été adoptée tard dans la nuit du mardi 21 juillet. Le texte avait déjà fait l’objet d’une première lecture au Sénat le 25 mars, suivie d’une première lecture à l’Assemblée le 28 mai. La commission mixte paritaire avait été convoquée le 17 juillet pour lisser les désaccords.

• Vidéosurveillance algorithmique : la loi Ripost étend encore la prolongation jusqu’en 2030

Le texte adopté correspond en très grande partie à celui validé par la CMP. Hétéroclite, qualifié parfois par l’opposition et ses détracteurs de « fourre-tout », il doit apporter des réponses concrètes, voire durcies, à une liste de situations liées à l’ordre public.

Portée par le ministre de l’Intérieur Laurent Nuñez, la loi Ripost comporte de nombreuses mesures sécuritaires. Les plus relayées sont l’interdiction complète de la vente de protoxyde d’azote (gaz hilarant) au grand public, de nouveaux délits instaurés pour les rodéos urbains et les free parties (occasionnant des manifestations en juin), ou encore le relèvement de l’amende forfaitaire délictuelle pour usage de stupéfiants à 500 euros.

Certaines de ces mesures ont cependant un lien direct avec le numérique et la vidéosurveillance algorithmique.

Autour des lecteurs automatisés de plaques d’immatriculation (LAPI)

Les articles 15 et 15 bis ont trait aux LAPI, à la durée de conservation des données ou encore à l’accès à ces dernières.

La loi Ripost introduit un changement d’échelle. D’abord, le périmètre d’accès aux données LAPI pour la police, la gendarmerie et les douanes est étendu à 11 catégories : terrorisme, criminalité organisée, vol/recel de véhicules, vol aggravé, évasion, escroquerie, soustraction de mineurs, contrebande de tabac, trafic de déchets, refus d’obtempérer et – objet de nombreux débats – aide à l’entrée et au séjour irréguliers.

Ensuite, la durée de conservation évolue largement, passant de 15 jours actuellement à un an. En revanche, le fichier n’est pas assorti d’un « open bar » : la police, la gendarmerie et les douanes peuvent y accéder pendant un mois à compter de la collecte, l’accès étant ensuite réservé aux enquêtes judiciaires, sur autorisation d’un magistrat. La loi précise en outre que les traitements liés « ne comportent aucune technique de reconnaissance faciale ».

Enfin, l’article 15 introduit une mesure là encore très contestée : une base légale pour des conventions entre les services de l’État et des personnes morales de droit privé exploitant des dispositifs LAPI (parkings, autoroutes…) pour organiser la mise à disposition de leurs données aux forces de l’ordre. Autant de points que la Quadrature du Net avait largement décriés dans son billet du 17 juin, l’association y voyant la mise en place d’une « surveillance massive des déplacements ».

Des craintes largement alimentées par l’article 15 bis, du moins dans sa version de travail. La version adoptée traite toujours de l’analyse algorithmique des trajets des véhicules, mais les cas sont maintenant plus encadrés.

Le statut est ainsi expérimental, fixé à une période de trois ans et surtout limité à trois finalités spécifiques : criminalité organisée, vol et recel de véhicules volés, ainsi que vol aggravé. La conservation des données est fixée à quatre mois (maximum) et seuls peuvent y accéder les « personnels de la police nationale et de la gendarmerie nationale affectés dans des services de renseignement ».

Les traitements associés excluent « toute exploitation de la photographie des occupants des véhicules ». Dans le cadre de cette expérimentation, les données recueillies ne peuvent pas non plus être croisées avec d’autres traitements de données à caractère personnel.

La vidéosurveillance algorithmique est là pour rester

Sans grande surprise, l’article 19 de la loi Ripost confirme la prolongation jusqu’au 31 décembre 2030 de la vidéosurveillance algorithmique pour la seule finalité de prévention du terrorisme et des atteintes graves à la sécurité des personnes, avec extension aux bâtiments ouverts au public exposés à un risque permanent ou exceptionnel, en plus des grands événements. Là encore, la loi maintient l’exclusion de toute identification biométrique.

En revanche, l’article 19 bis est nouveau. Il ouvre une expérimentation – une de plus – jusqu’au 31 décembre 2027 de traitements algorithmiques sur les images de surveillance des commerces de détail, grandes surfaces et centres commerciaux, à la seule fin de prévention du vol.

Sur le papier, le dispositif est très encadré : interdiction de toute identification biométrique ou reconnaissance faciale, contrôle humain obligatoire, analyse d’impact CNIL, registre des suites données aux signalements, attestation de conformité publiée avant mise à disposition du système, et interdiction d’utiliser les images comme données d’entraînement. En outre, un rapport d’évaluation devra être remis au Parlement avant le 30 septembre 2027.

Billes numériques

La loi Ripost contient plusieurs autres éléments liés au numérique, soit pour compléter des mesures introduites, soit pour préciser certaines règles de traitement.

Par exemple, l’article 7 ter habilite l’autorité administrative à faire retirer, bloquer ou déréférencer les contenus en ligne relatifs à la vente illégale de protoxyde d’azote, via les mécanismes prévus à l’article L. 521-3-1 du code de la consommation. Autrement dit, un blocage administratif de contenu, sans intervention d’un juge.

L’article 11 introduit toutefois une clause de souveraineté numérique : les données transmises dans le cadre de certaines procédures de coopération judiciaire ne peuvent être traitées, hébergées ou rendues accessibles via une solution (logiciel, infrastructure…) fournie par une entité susceptible d’être soumise à une législation étrangère extraterritoriale. Difficile de ne pas penser aux lois américaines comme le Cloud Act et sa portée extraterritoriale qui a tant fait couler d’encre.

Enfin, plusieurs articles intronisent des autorisations d’exploitation pour des dispositifs de caméras spécifiques. L’article 14 bis, par exemple, autorise à titre expérimental les opérateurs de transport public ferroviaire à capter, transmettre et enregistrer des images prises sur la voie publique et dans des lieux ouverts au public, via des caméras frontales. La finalité est toujours la même : prévention des accidents pendant l’intervention des agents, constat des infractions, etc. À chaque fois, le périmètre est strict, les données ne peuvent être gardées que 30 jours et les modalités doivent être fixées par décret en Conseil d’État, après avis de la CNIL.

À boire et à manger

Le projet de loi Ripost a été définitivement adopté par le Parlement ce 21 juillet. Le texte vise à durcir le ton face à un certain nombre de troubles à l’ordre public. Mais si les rodéos urbains et le protoxyde d’azote font les gros titres, le texte contient également des mesures liées à la lecture automatisée des plaques d’immatriculation et à la vidéosurveillance algorithmique.

La loi Ripost – pour « réponses immédiates aux phénomènes troublant l’ordre public, la sécurité et la tranquillité de nos concitoyens » – a finalement été adoptée tard dans la nuit du mardi 21 juillet. Le texte avait déjà fait l’objet d’une première lecture au Sénat le 25 mars, suivie d’une première lecture à l’Assemblée le 28 mai. La commission mixte paritaire avait été convoquée le 17 juillet pour lisser les désaccords.

• Vidéosurveillance algorithmique : la loi Ripost étend encore la prolongation jusqu’en 2030

Le texte adopté correspond en très grande partie à celui validé par la CMP. Hétéroclite, qualifié parfois par l’opposition et ses détracteurs de « fourre-tout », il doit apporter des réponses concrètes, voire durcies, à une liste de situations liées à l’ordre public.

Portée par le ministre de l’Intérieur Laurent Nuñez, la loi Ripost comporte de nombreuses mesures sécuritaires. Les plus relayées sont l’interdiction complète de la vente de protoxyde d’azote (gaz hilarant) au grand public, de nouveaux délits instaurés pour les rodéos urbains et les free parties (occasionnant des manifestations en juin), ou encore le relèvement de l’amende forfaitaire délictuelle pour usage de stupéfiants à 500 euros.

Certaines de ces mesures ont cependant un lien direct avec le numérique et la vidéosurveillance algorithmique.

Autour des lecteurs automatisés de plaques d’immatriculation (LAPI)

Les articles 15 et 15 bis ont trait aux LAPI, à la durée de conservation des données ou encore à l’accès à ces dernières.

La loi Ripost introduit un changement d’échelle. D’abord, le périmètre d’accès aux données LAPI pour la police, la gendarmerie et les douanes est étendu à 11 catégories : terrorisme, criminalité organisée, vol/recel de véhicules, vol aggravé, évasion, escroquerie, soustraction de mineurs, contrebande de tabac, trafic de déchets, refus d’obtempérer et – objet de nombreux débats – aide à l’entrée et au séjour irréguliers.

Ensuite, la durée de conservation évolue largement, passant de 15 jours actuellement à un an. En revanche, le fichier n’est pas assorti d’un « open bar » : la police, la gendarmerie et les douanes peuvent y accéder pendant un mois à compter de la collecte, l’accès étant ensuite réservé aux enquêtes judiciaires, sur autorisation d’un magistrat. La loi précise en outre que les traitements liés « ne comportent aucune technique de reconnaissance faciale ».

Enfin, l’article 15 introduit une mesure là encore très contestée : une base légale pour des conventions entre les services de l’État et des personnes morales de droit privé exploitant des dispositifs LAPI (parkings, autoroutes…) pour organiser la mise à disposition de leurs données aux forces de l’ordre. Autant de points que la Quadrature du Net avait largement décriés dans son billet du 17 juin, l’association y voyant la mise en place d’une « surveillance massive des déplacements ».

Des craintes largement alimentées par l’article 15 bis, du moins dans sa version de travail. La version adoptée traite toujours de l’analyse algorithmique des trajets des véhicules, mais les cas sont maintenant plus encadrés.

Le statut est ainsi expérimental, fixé à une période de trois ans et surtout limité à trois finalités spécifiques : criminalité organisée, vol et recel de véhicules volés, ainsi que vol aggravé. La conservation des données est fixée à quatre mois (maximum) et seuls peuvent y accéder les « personnels de la police nationale et de la gendarmerie nationale affectés dans des services de renseignement ».

Les traitements associés excluent « toute exploitation de la photographie des occupants des véhicules ». Dans le cadre de cette expérimentation, les données recueillies ne peuvent pas non plus être croisées avec d’autres traitements de données à caractère personnel.

La vidéosurveillance algorithmique est là pour rester

Sans grande surprise, l’article 19 de la loi Ripost confirme la prolongation jusqu’au 31 décembre 2030 de la vidéosurveillance algorithmique pour la seule finalité de prévention du terrorisme et des atteintes graves à la sécurité des personnes, avec extension aux bâtiments ouverts au public exposés à un risque permanent ou exceptionnel, en plus des grands événements. Là encore, la loi maintient l’exclusion de toute identification biométrique.

En revanche, l’article 19 bis est nouveau. Il ouvre une expérimentation – une de plus – jusqu’au 31 décembre 2027 de traitements algorithmiques sur les images de surveillance des commerces de détail, grandes surfaces et centres commerciaux, à la seule fin de prévention du vol.

Sur le papier, le dispositif est très encadré : interdiction de toute identification biométrique ou reconnaissance faciale, contrôle humain obligatoire, analyse d’impact CNIL, registre des suites données aux signalements, attestation de conformité publiée avant mise à disposition du système, et interdiction d’utiliser les images comme données d’entraînement. En outre, un rapport d’évaluation devra être remis au Parlement avant le 30 septembre 2027.

Billes numériques

La loi Ripost contient plusieurs autres éléments liés au numérique, soit pour compléter des mesures introduites, soit pour préciser certaines règles de traitement.

Par exemple, l’article 7 ter habilite l’autorité administrative à faire retirer, bloquer ou déréférencer les contenus en ligne relatifs à la vente illégale de protoxyde d’azote, via les mécanismes prévus à l’article L. 521-3-1 du code de la consommation. Autrement dit, un blocage administratif de contenu, sans intervention d’un juge.

L’article 11 introduit toutefois une clause de souveraineté numérique : les données transmises dans le cadre de certaines procédures de coopération judiciaire ne peuvent être traitées, hébergées ou rendues accessibles via une solution (logiciel, infrastructure…) fournie par une entité susceptible d’être soumise à une législation étrangère extraterritoriale. Difficile de ne pas penser aux lois américaines comme le Cloud Act et sa portée extraterritoriale qui a tant fait couler d’encre.

Enfin, plusieurs articles intronisent des autorisations d’exploitation pour des dispositifs de caméras spécifiques. L’article 14 bis, par exemple, autorise à titre expérimental les opérateurs de transport public ferroviaire à capter, transmettre et enregistrer des images prises sur la voie publique et dans des lieux ouverts au public, via des caméras frontales. La finalité est toujours la même : prévention des accidents pendant l’intervention des agents, constat des infractions, etc. À chaque fois, le périmètre est strict, les données ne peuvent être gardées que 30 jours et les modalités doivent être fixées par décret en Conseil d’État, après avis de la CNIL.

Entre autres problèmes, Windows 11 a beau représenter le système le plus moderne de Microsoft, il traine de vieux boulets esthétiques. Le problème est le même qu’avec Windows 10, même si le travail a continué depuis : des éléments d’interface datent de Windows 2000, voire d’avant, cassant l’homogénéité de l’interface.

L’un des cas les plus emblématiques est la fenêtre de propriétés d’un fichier, à laquelle on accède via le classique clic droit. En plus de ne pas avoir changé depuis très, très longtemps, elle ne tient pas compte du thème actif dans Windows. Elle se présente actuellement comme cela :

Mais phantomofearth, bien connu des réseaux sociaux pour ses trouvailles dans Windows, a révélé le 21 juillet sur Bluesky qu’une transformation se profile : la fenêtre des propriétés est modernisée. Pour l’instant, elle n’apparait que dans le contexte de la Corbeille, mais il s’agit bien d’une nouvelle fenêtre créée avec WinUI, d’où l’apparence cohérente avec le reste du système et le support du thème sombre. La disposition des éléments est strictement la même qu’actuellement, avec l’avantage de ne pas casser les habitudes.

Cette modification est présente dans la dernière préversion du système (26300.8935, branche expérimentale). Microsoft ne l’aborde pas encore dans un billet, mais ce n’est probablement qu’une question de temps. Il n’y a pas non plus de raison que ce changement reste cantonné à la Corbeille dans les prochaines préversions.

Rappelons que Microsoft travaille sur son initiative « K2 » visant à redorer le blason d’un Windows 11 qui n’a jamais provoqué l’enthousiasme. L’éditeur a mis en avant un travail sur les performances, l’arrivée d’applications natives, le recul de l’IA ou encore une plus grande personnalisation de l’interface. Une bonne partie de ces changements devrait se refléter dans la mise à jour 26H2.

Entre autres problèmes, Windows 11 a beau représenter le système le plus moderne de Microsoft, il traine de vieux boulets esthétiques. Le problème est le même qu’avec Windows 10, même si le travail a continué depuis : des éléments d’interface datent de Windows 2000, voire d’avant, cassant l’homogénéité de l’interface.

L’un des cas les plus emblématiques est la fenêtre de propriétés d’un fichier, à laquelle on accède via le classique clic droit. En plus de ne pas avoir changé depuis très, très longtemps, elle ne tient pas compte du thème actif dans Windows. Elle se présente actuellement comme cela :

Mais phantomofearth, bien connu des réseaux sociaux pour ses trouvailles dans Windows, a révélé le 21 juillet sur Bluesky qu’une transformation se profile : la fenêtre des propriétés est modernisée. Pour l’instant, elle n’apparait que dans le contexte de la Corbeille, mais il s’agit bien d’une nouvelle fenêtre créée avec WinUI, d’où l’apparence cohérente avec le reste du système et le support du thème sombre. La disposition des éléments est strictement la même qu’actuellement, avec l’avantage de ne pas casser les habitudes.

Cette modification est présente dans la dernière préversion du système (26300.8935, branche expérimentale). Microsoft ne l’aborde pas encore dans un billet, mais ce n’est probablement qu’une question de temps. Il n’y a pas non plus de raison que ce changement reste cantonné à la Corbeille dans les prochaines préversions.

Rappelons que Microsoft travaille sur son initiative « K2 » visant à redorer le blason d’un Windows 11 qui n’a jamais provoqué l’enthousiasme. L’éditeur a mis en avant un travail sur les performances, l’arrivée d’applications natives, le recul de l’IA ou encore une plus grande personnalisation de l’interface. Une bonne partie de ces changements devrait se refléter dans la mise à jour 26H2.

Foutu progrès

Hugging Face a communiqué récemment sur une attaque menée par un agent autonome contre ses infrastructures, occasionnant une compromission partielle. Patatras ! OpenAI vient de révéler qu’il s’agissait de l’un de ses modèles et qu’il s’était « échappé » de la sandbox où il était censé être confiné.

Le 16 juillet, Hugging Face a publié un billet de sécurité décrivant une intrusion dans une partie de son infrastructure de production. L’entreprise a affirmé qu’il s’agissait d’un système d’agent IA autonome, détecté et disséqué en grande partie grâce à sa propre architecture par la suite. Hugging Face dit avoir tiré quelques leçons importantes de l’aventure, mais précisait ne pas avoir trouvé quel modèle avait été utilisé.

• Attaquée par un agent IA autonome, Hugging Face a analysé les traces avec un LLM local

Et voilà qu’OpenAI a fourni la réponse ce 21 juillet : les modèles étaient les siens. Détournés par des pirates pour les militariser ? Que nenni, les agents ont fait leur vie et ont manifestement échappé au contrôle de leurs gardiens. Le problème de cybersécurité, réel et concret, est devenu un argument marketing.

Les évènements qui ont mené à l’attaque

Dans son propre billet, OpenAI donne des informations sur ce qui s’est passé, en plus de préciser les modèles utilisés dans l’attaque contre Hugging Face : le récent GPT 5.6 Sol ainsi que des modèles en préversion présentés comme encore « plus capables », configurés volontairement avec des barrières plus faibles autour des capacités cyber.

Les modèles étaient soumis à un benchmark interne nommé ExploitGym, conçu pour évaluer les capacités d’exploitation avancée sur des chemins d’attaque complexes, en désactivant les classifieurs de production qui bloquent normalement les activités cyber à haut risque.

L’environnement de test était censé être isolé, avec un accès réseau limité à un proxy interne servant de cache pour les paquets nécessaires. Cependant, les modèles ont consacré une quantité « substantielle » de calcul d’inférence à trouver un moyen d’obtenir un accès Internet ouvert, en exploitant une vulnérabilité 0-day dans ce proxy de cache. Cette faille a été communiquée au fournisseur concerné, précise OpenAI.

En clair, les modèles ont dépensé de la puissance de calcul pour s’échapper de leur bac à sable (sandbox). Une fois à l’air libre, les choses ont pris une autre tournure. Le système IA d’OpenAI, qui cherchait à résoudre les benchmarks qui lui étaient imposés, a « estimé » que les datasets (jeux de données) et solutions à ExploitGym devaient se trouver sur Hugging Face. Les modèles ont donc cherché tous les moyens d’obtenir les informations jugées nécessaires, jusqu’à voler des identifiants et identifier plusieurs nouvelles failles 0-day.

Autrement dit, l’attaque déclenchée contre Hugging Face n’était pas malveillante dans le sens classique du terme. Le système IA a simplement considéré que l’entreprise devait avoir la solution au problème qui lui était imposé et a donc cherché à tricher, Hugging Face se trouvant simplement sur le chemin.

Évidemment, vu depuis l’autre entreprise, l’incident n’avait rien de fascinant. L’intrusion s’est faite depuis un dataset malveillant provoquant une exécution de code dans un pipeline dédié. Rappelons que Hugging Face a d’abord essayé d’analyser la situation en passant par les API commerciales des grandes entreprises de l’IA, ce qui n’a pas fonctionné : ces API ne faisaient pas la différence entre des demandes liées à une attaque et d’autres liées à une analyse d’évènement cyber.

Hugging Face avait fini par installer le modèle chinois GLM 5.2 (poids ouverts) sur sa propre infrastructure pour mener ses analyses, sans dépendre de qui que ce soit. Une certaine ironie dans la situation que l’entreprise a nommée « l’asymétrie du garde-fou ».

Ce type d’incident se reproduira

Le risque d’un nouvel incident n’est plus théorique, les deux entreprises étant explicites sur le sujet. Hugging Face conclut que l’outillage offensif autonome piloté par IA n’est plus hypothétique, qu’il abaisse le coût de campagnes vastes, patientes et multi-étapes, et opère à vitesse machine.

OpenAI, de son côté, s’appuie sur des évaluations de l’UK AI Security Institute montrant que des modèles comme GPT 5.6 Sol sont de plus en plus capables de soutenir des opérations cyber complexes et multi-étapes sur de longues périodes. Pour l’éditeur, cet incident confirme que ces capacités théoriques s’appliquent en conditions réelles.

La récidive est d’autant plus possible que la sécurité générale dépend toujours de son maillon le plus faible. Or, il semble qu’OpenAI n’ait pas bien configuré son environnement de test : comment un laboratoire de pointe peut-il lancer des tests sur des capacités offensives sans confinement robuste ni surveillance suffisante ?

En outre, l’asymétrie décrite par Hugging Face sera toujours là. On retrouvera ainsi les modèles « débridés » en attaque, qu’ils soient utilisés à des fins de test ou par de vrais acteurs malveillants, tandis que la défense devra se contenter des modèles commerciaux, dont les capacités cyber sont volontairement tronquées.

D’ailleurs, l’évènement n’est pas isolé. OpenAI indique que le même jour, un modèle en préversion a été mis en pause après s’être échappé là encore de sa zone de confinement pour aller poster sur GitHub.

De l’incident cyber à l’opportunité marketing

OpenAI tire un bénéfice commercial direct et immédiat de l’histoire. Son billet se termine en invitant explicitement d’autres organisations à rejoindre le programme « Trusted Access » et à expérimenter ces modèles pour améliorer prévention, détection et réponse aux incidents. Sans surprise, Hugging Face a été intégré à ce même programme dans la foulée.

Le narratif est en outre bien connu, avec des modèles si « puissants » qu’ils en arrivent à pirater une entreprise tierce par accident. Une aura de danger qu’OpenAI a déjà exploitée et dont Anthropic s’est fait l’experte, un puissant « marketing de la peur » faisant la célébrité de son programme Glasswing et du modèle Mythos.

• Anthropic et la stratégie marketing de la peur autour de sa nouvelle IA Mythos (2/3)

Nous faisons également remarquer qu’il s’est écoulé cinq jours entre la publication de Hugging Face et celle d’OpenAI, laissant le temps de transformer une histoire potentiellement compromettante en argumentaire produit, d’autant que les forces de l’ordre ont été averties (on ne sait pas encore si OpenAI sera inquiétée).

Cependant, même si la communication bat son plein pour changer un problème en opportunité, les évènements décrits semblent bel et bien réels. Une faille 0-day a été trouvée dans un produit utilisé pour le confinement de l’environnement de test, une exécution de code a été déclenchée chez un partenaire, du temps et de l’argent ont été investis pour détecter, analyser, réparer et avertir.

En revanche, aucune des deux entreprises ne s’est exprimée sur la période de cinq jours entre les deux billets. À moins d’une campagne de communication savamment orchestrée, il est probable que Hugging Face n’ait pas su d’où venait l’attaque et qu’OpenAI ne l’en ait avertie qu’après le billet du 16 juillet. Au vu des annonces d’OpenAI – surtout l’intégration de Hugging Face dans Trusted Access –, les cinq jours semblent avoir servi à accorder les violons et à s’entendre sur la suite des évènements.

Enfin, OpenAI assure qu’elle fera tout pour que ce type d’incident ne se reproduise pas. « Cet incident souligne la nécessité de renforcer davantage l’alignement de notre modèle, les protections cyber pendant l’évaluation, et la surveillance lors des tests internes », affirme l’entreprise. Un argument que Micah Carroll, chercheur chez OpenAI, reprend sur X : « Si cela ne vous convainc pas que les risques de mésalignement vont devenir une préoccupation clé à l’avenir, je ne sais pas ce qui le fera ».

Foutu progrès

Hugging Face a communiqué récemment sur une attaque menée par un agent autonome contre ses infrastructures, occasionnant une compromission partielle. Patatras ! OpenAI vient de révéler qu’il s’agissait de l’un de ses modèles et qu’il s’était « échappé » de la sandbox où il était censé être confiné.

Le 16 juillet, Hugging Face a publié un billet de sécurité décrivant une intrusion dans une partie de son infrastructure de production. L’entreprise a affirmé qu’il s’agissait d’un système d’agent IA autonome, détecté et disséqué en grande partie grâce à sa propre architecture par la suite. Hugging Face dit avoir tiré quelques leçons importantes de l’aventure, mais précisait ne pas avoir trouvé quel modèle avait été utilisé.

• Attaquée par un agent IA autonome, Hugging Face a analysé les traces avec un LLM local

Et voilà qu’OpenAI a fourni la réponse ce 21 juillet : les modèles étaient les siens. Détournés par des pirates pour les militariser ? Que nenni, les agents ont fait leur vie et ont manifestement échappé au contrôle de leurs gardiens. Le problème de cybersécurité, réel et concret, est devenu un argument marketing.

Les évènements qui ont mené à l’attaque

Dans son propre billet, OpenAI donne des informations sur ce qui s’est passé, en plus de préciser les modèles utilisés dans l’attaque contre Hugging Face : le récent GPT 5.6 Sol ainsi que des modèles en préversion présentés comme encore « plus capables », configurés volontairement avec des barrières plus faibles autour des capacités cyber.

Les modèles étaient soumis à un benchmark interne nommé ExploitGym, conçu pour évaluer les capacités d’exploitation avancée sur des chemins d’attaque complexes, en désactivant les classifieurs de production qui bloquent normalement les activités cyber à haut risque.

L’environnement de test était censé être isolé, avec un accès réseau limité à un proxy interne servant de cache pour les paquets nécessaires. Cependant, les modèles ont consacré une quantité « substantielle » de calcul d’inférence à trouver un moyen d’obtenir un accès Internet ouvert, en exploitant une vulnérabilité 0-day dans ce proxy de cache. Cette faille a été communiquée au fournisseur concerné, précise OpenAI.

En clair, les modèles ont dépensé de la puissance de calcul pour s’échapper de leur bac à sable (sandbox). Une fois à l’air libre, les choses ont pris une autre tournure. Le système IA d’OpenAI, qui cherchait à résoudre les benchmarks qui lui étaient imposés, a « estimé » que les datasets (jeux de données) et solutions à ExploitGym devaient se trouver sur Hugging Face. Les modèles ont donc cherché tous les moyens d’obtenir les informations jugées nécessaires, jusqu’à voler des identifiants et identifier plusieurs nouvelles failles 0-day.

Autrement dit, l’attaque déclenchée contre Hugging Face n’était pas malveillante dans le sens classique du terme. Le système IA a simplement considéré que l’entreprise devait avoir la solution au problème qui lui était imposé et a donc cherché à tricher, Hugging Face se trouvant simplement sur le chemin.

Évidemment, vu depuis l’autre entreprise, l’incident n’avait rien de fascinant. L’intrusion s’est faite depuis un dataset malveillant provoquant une exécution de code dans un pipeline dédié. Rappelons que Hugging Face a d’abord essayé d’analyser la situation en passant par les API commerciales des grandes entreprises de l’IA, ce qui n’a pas fonctionné : ces API ne faisaient pas la différence entre des demandes liées à une attaque et d’autres liées à une analyse d’évènement cyber.

Hugging Face avait fini par installer le modèle chinois GLM 5.2 (poids ouverts) sur sa propre infrastructure pour mener ses analyses, sans dépendre de qui que ce soit. Une certaine ironie dans la situation que l’entreprise a nommée « l’asymétrie du garde-fou ».

Ce type d’incident se reproduira

Le risque d’un nouvel incident n’est plus théorique, les deux entreprises étant explicites sur le sujet. Hugging Face conclut que l’outillage offensif autonome piloté par IA n’est plus hypothétique, qu’il abaisse le coût de campagnes vastes, patientes et multi-étapes, et opère à vitesse machine.

OpenAI, de son côté, s’appuie sur des évaluations de l’UK AI Security Institute montrant que des modèles comme GPT 5.6 Sol sont de plus en plus capables de soutenir des opérations cyber complexes et multi-étapes sur de longues périodes. Pour l’éditeur, cet incident confirme que ces capacités théoriques s’appliquent en conditions réelles.

La récidive est d’autant plus possible que la sécurité générale dépend toujours de son maillon le plus faible. Or, il semble qu’OpenAI n’ait pas bien configuré son environnement de test : comment un laboratoire de pointe peut-il lancer des tests sur des capacités offensives sans confinement robuste ni surveillance suffisante ?

En outre, l’asymétrie décrite par Hugging Face sera toujours là. On retrouvera ainsi les modèles « débridés » en attaque, qu’ils soient utilisés à des fins de test ou par de vrais acteurs malveillants, tandis que la défense devra se contenter des modèles commerciaux, dont les capacités cyber sont volontairement tronquées.

D’ailleurs, l’évènement n’est pas isolé. OpenAI indique que le même jour, un modèle en préversion a été mis en pause après s’être échappé là encore de sa zone de confinement pour aller poster sur GitHub.

De l’incident cyber à l’opportunité marketing

OpenAI tire un bénéfice commercial direct et immédiat de l’histoire. Son billet se termine en invitant explicitement d’autres organisations à rejoindre le programme « Trusted Access » et à expérimenter ces modèles pour améliorer prévention, détection et réponse aux incidents. Sans surprise, Hugging Face a été intégré à ce même programme dans la foulée.

Le narratif est en outre bien connu, avec des modèles si « puissants » qu’ils en arrivent à pirater une entreprise tierce par accident. Une aura de danger qu’OpenAI a déjà exploitée et dont Anthropic s’est fait l’experte, un puissant « marketing de la peur » faisant la célébrité de son programme Glasswing et du modèle Mythos.

• Anthropic et la stratégie marketing de la peur autour de sa nouvelle IA Mythos (2/3)

Nous faisons également remarquer qu’il s’est écoulé cinq jours entre la publication de Hugging Face et celle d’OpenAI, laissant le temps de transformer une histoire potentiellement compromettante en argumentaire produit, d’autant que les forces de l’ordre ont été averties (on ne sait pas encore si OpenAI sera inquiétée).

Cependant, même si la communication bat son plein pour changer un problème en opportunité, les évènements décrits semblent bel et bien réels. Une faille 0-day a été trouvée dans un produit utilisé pour le confinement de l’environnement de test, une exécution de code a été déclenchée chez un partenaire, du temps et de l’argent ont été investis pour détecter, analyser, réparer et avertir.

En revanche, aucune des deux entreprises ne s’est exprimée sur la période de cinq jours entre les deux billets. À moins d’une campagne de communication savamment orchestrée, il est probable que Hugging Face n’ait pas su d’où venait l’attaque et qu’OpenAI ne l’en ait avertie qu’après le billet du 16 juillet. Au vu des annonces d’OpenAI – surtout l’intégration de Hugging Face dans Trusted Access –, les cinq jours semblent avoir servi à accorder les violons et à s’entendre sur la suite des évènements.

Enfin, OpenAI assure qu’elle fera tout pour que ce type d’incident ne se reproduise pas. « Cet incident souligne la nécessité de renforcer davantage l’alignement de notre modèle, les protections cyber pendant l’évaluation, et la surveillance lors des tests internes », affirme l’entreprise. Un argument que Micah Carroll, chercheur chez OpenAI, reprend sur X : « Si cela ne vous convainc pas que les risques de mésalignement vont devenir une préoccupation clé à l’avenir, je ne sais pas ce qui le fera ».

Chacun sa boite

Firefox fournit un joli lâcher de nouveautés, dont la principale est clairement l’arrivée des conteneurs. Ceux-ci existent depuis des années sous forme d’extensions, mais on parle cette fois d’une intégration native pour l’ensemble des sites.

Firefox 153 est l’avant-dernière révision mensuelle. La mouture 154 arrivera le 18 aout, mais la 155 sera là dès le 1ᵉʳ septembre : Mozilla a décidé de suivre le reste de l’industrie sur une publication bimensuelle. Et pour fêter l’évènement (façon de parler), les nouveautés sont assez nombreuses.

Des conteneurs enfin présents par défaut

Le changement le plus significatif est l’intégration native des containers (conteneurs d’onglets), jusqu’ici réservés à l’extension Multi-Account Containers. Mozilla décrit cette fonctionnalité comme permettant de séparer les cookies par container pour utiliser différents comptes sur un même site et limiter le tracking cross-site entre eux.

Quatre containers préconfigurés sont fournis par défaut : Personnel, Banque, Achats et Travail, chacun avec sa couleur représentée par un liseré sur le haut de l’onglet. L’utilisateur peut en créer d’autres, avec nom, couleur et icône personnalisés. Pour accéder aux conteneurs, il suffit de faire un clic droit sur le bouton « + » servant à ouvrir un onglet.

Le même menu permet de se rendre dans le panneau de gestion des conteneurs, où l’on peut configurer ceux existant déjà et en ajouter d’autres. Une option permet même de forcer l’affichage du menu, pour qu’un clic sur « + » propose systématiquement un onglet standard ou un conteneur. Le raccourci Ctrl + T n’est cependant pas affecté et ouvre toujours un onglet classique.

Nombreux petits ajouts

Firefox 153 ajoute bon nombre de nouveautés plus ou moins importantes. Dans l’éditeur PDF par exemple, on peut maintenant ajouter des images en tant que nouvelles pages, ou fusionner des PDF en glissant un fichier directement dans le panneau latéral, plutôt que de passer par le sélecteur de fichier.

On trouve également de nouvelles actions rapides pour la barre d’adresse : taper « labs » ou « experiment » ouvre directement Firefox Labs. Taper « pick color », « color picker » ou « eyedropper » active un sélecteur de couleur permettant de copier n’importe quelle teinte affichée sur une page. Pour rappel, les actions rapides ne se lancent pas par simple validation avec Entrée, car cette manipulation lance toujours la recherche sur les mots saisis. À la place, le menu qui s’ouvre en-dessous fait apparaitre la fonction correspondante, sur laquelle on peut cliquer ou – plus simplement – sélectionner avec Tab avant de faire Entrée.

Firefox 153 se dote en outre d’une fonction de partage par code QR. On y accède par un clic droit sur l’onglet, puis Partager > Générer un code QR. L’icône de géolocalisation s’affiche désormais en rouge quand un site accède à la position, y compris sur les pages de résultats de recherche où elle était auparavant masquée. Côté IA, la fonctionnalité « Smart Window » (le mode IA expérimental de Firefox) permet de choisir le modèle préféré.

La nouvelle mouture présente aussi des apports spécifiques aux plateformes. Sur Windows 10/11, la lecture des vidéos prend enfin en charge le HDR, à condition que l’écran supporte cette capacité bien sûr. Cette prise en charge est pour l’instant limitée aux configurations dotées d’un GPU dédié AMD ou NVIDIA. Sous Linux/GTK, les coins arrondis en bas des fenêtres sont désormais activés par défaut (l’option existait déjà manuellement depuis 2023). Sous macOS, Firefox prend en charge le raccourci système Apple Globe + F pour le plein écran. Et comme toujours avec les nouvelles moutures, Firefox 153 colmate des dizaines de failles de sécurité, dont 17 de sévérité élevée.

Enfin, et c’est clairement un élément important pour une partie des utilisateurs, Firefox 153 est ESR (Extended Support Release). Ces versions sont maintenues par Mozilla pendant 15 mois : une fois par an, avec une période de sûreté de trois mois pour laisser le temps de faire la mise à jour. Durant ces 15 mois, Mozilla s’engage à fournir les correctifs de sécurité sans toucher à l’aspect fonctionnel.

Chacun sa boite

Firefox fournit un joli lâcher de nouveautés, dont la principale est clairement l’arrivée des conteneurs. Ceux-ci existent depuis des années sous forme d’extensions, mais on parle cette fois d’une intégration native pour l’ensemble des sites.

Firefox 153 est l’avant-dernière révision mensuelle. La mouture 154 arrivera le 18 aout, mais la 155 sera là dès le 1ᵉʳ septembre : Mozilla a décidé de suivre le reste de l’industrie sur une publication bimensuelle. Et pour fêter l’évènement (façon de parler), les nouveautés sont assez nombreuses.

Des conteneurs enfin présents par défaut

Le changement le plus significatif est l’intégration native des containers (conteneurs d’onglets), jusqu’ici réservés à l’extension Multi-Account Containers. Mozilla décrit cette fonctionnalité comme permettant de séparer les cookies par container pour utiliser différents comptes sur un même site et limiter le tracking cross-site entre eux.

Quatre containers préconfigurés sont fournis par défaut : Personnel, Banque, Achats et Travail, chacun avec sa couleur représentée par un liseré sur le haut de l’onglet. L’utilisateur peut en créer d’autres, avec nom, couleur et icône personnalisés. Pour accéder aux conteneurs, il suffit de faire un clic droit sur le bouton « + » servant à ouvrir un onglet.

Le même menu permet de se rendre dans le panneau de gestion des conteneurs, où l’on peut configurer ceux existant déjà et en ajouter d’autres. Une option permet même de forcer l’affichage du menu, pour qu’un clic sur « + » propose systématiquement un onglet standard ou un conteneur. Le raccourci Ctrl + T n’est cependant pas affecté et ouvre toujours un onglet classique.

Nombreux petits ajouts

Firefox 153 ajoute bon nombre de nouveautés plus ou moins importantes. Dans l’éditeur PDF par exemple, on peut maintenant ajouter des images en tant que nouvelles pages, ou fusionner des PDF en glissant un fichier directement dans le panneau latéral, plutôt que de passer par le sélecteur de fichier.

On trouve également de nouvelles actions rapides pour la barre d’adresse : taper « labs » ou « experiment » ouvre directement Firefox Labs. Taper « pick color », « color picker » ou « eyedropper » active un sélecteur de couleur permettant de copier n’importe quelle teinte affichée sur une page. Pour rappel, les actions rapides ne se lancent pas par simple validation avec Entrée, car cette manipulation lance toujours la recherche sur les mots saisis. À la place, le menu qui s’ouvre en-dessous fait apparaitre la fonction correspondante, sur laquelle on peut cliquer ou – plus simplement – sélectionner avec Tab avant de faire Entrée.

Firefox 153 se dote en outre d’une fonction de partage par code QR. On y accède par un clic droit sur l’onglet, puis Partager > Générer un code QR. L’icône de géolocalisation s’affiche désormais en rouge quand un site accède à la position, y compris sur les pages de résultats de recherche où elle était auparavant masquée. Côté IA, la fonctionnalité « Smart Window » (le mode IA expérimental de Firefox) permet de choisir le modèle préféré.

La nouvelle mouture présente aussi des apports spécifiques aux plateformes. Sur Windows 10/11, la lecture des vidéos prend enfin en charge le HDR, à condition que l’écran supporte cette capacité bien sûr. Cette prise en charge est pour l’instant limitée aux configurations dotées d’un GPU dédié AMD ou NVIDIA. Sous Linux/GTK, les coins arrondis en bas des fenêtres sont désormais activés par défaut (l’option existait déjà manuellement depuis 2023). Sous macOS, Firefox prend en charge le raccourci système Apple Globe + F pour le plein écran. Et comme toujours avec les nouvelles moutures, Firefox 153 colmate des dizaines de failles de sécurité, dont 17 de sévérité élevée.

Enfin, et c’est clairement un élément important pour une partie des utilisateurs, Firefox 153 est ESR (Extended Support Release). Ces versions sont maintenues par Mozilla pendant 15 mois : une fois par an, avec une période de sûreté de trois mois pour laisser le temps de faire la mise à jour. Durant ces 15 mois, Mozilla s’engage à fournir les correctifs de sécurité sans toucher à l’aspect fonctionnel.

L'important, c'est le choix

Des propriétaires de moniteurs LG ont constaté qu’après un simple branchement de l’écran, Windows installe silencieusement une application nommée LG Monitor App Installer. Sa seule mission semble être de proposer un essai de l’antivirus McAfee. Le processus détourne une capacité du système à simplifier l’installation des composants et périphériques.

Depuis environ trois semaines, des propriétaires de moniteurs LG (essentiellement la gamme UltraGear) constatent qu’après un simple branchement de l’écran, l’application LG Monitor App Installer apparait d’elle-même, sans boîte de dialogue de consentement. Son comportement observé consiste principalement à afficher un pop-up faisant la promotion d’un essai gratuit de 30 jours de McAfee, qui bascule ensuite vers un abonnement payant (39,99 dollars la première année).

La chaîne YouTube Gamers Nexus a reproduit le phénomène en achetant un moniteur LG UltraGear 34GX900A-B (1 200 dollars) : l’installation apparaît dans le menu Démarrer environ une minute après branchement, et le pop-up McAfee s’est affiché sur 31 des 32 démarrages testés.

Qu’est-ce que c’est que ce bazar ?

Il ne s’agit pas d’un piratage, mais d’un processus basé sur une fonctionnalité parfaitement documentée depuis Windows 8. Elle est basée sur les métadonnées et se déroule en quatre étapes :

1. Connexion du périphérique
2. Récupération des métadonnées associées depuis les serveurs de Microsoft
3. Téléchargement du pilote via Windows Update
4. Téléchargement automatique de l’application associée via le Microsoft Store

Il ne faut que trois conditions pour que la chaine se lance, simples à réunir : une connexion internet, un compte Microsoft (permettant le lien avec le Store) et des paramètres non modifiés de Windows.

La simplicité du processus fait son efficacité aussi bien que le lit des critiques. Microsoft reconnait dans sa documentation que « la fonction d’installation automatique ne fournit pas de notification à l’utilisateur lors de l’installation de l’application ». L’éditeur met d’ailleurs en garde les constructeurs : « Certains utilisateurs peuvent trouver cette expérience confuse et frustrante, et attribuer une mauvaise note à votre application ». Il ne croyait pas si bien dire.

Rien ne va

Windows Latest s’est abondamment penché sur la situation. En creusant, nos confrères se sont rendu compte que LG n’en est pas à son coup d’essai. Un technicien en réparation PC avait ainsi signalé le comportement sur le forum Microsoft Tech Community dès juillet 2025, qualifiant l’app de PUP (« potentially unwanted program ») forcé à chaque branchement d’un moniteur LG en atelier. Le fil n’a cependant jamais reçu de réponse de Microsoft.

Ce qui a rendu le problème visible ces dernières semaines, c’est une mise à jour de l’application dont les notes de version ajoutent explicitement McAfee comme « application supplémentaire », le tout rédigé dans un langage très publicitaire : « Live confidently online with all-in-one protection » (« Vivez en toute confiance en ligne avec une protection tout-en-un »). Pour nos confrères, il s’agit d’un aveu indirect de LG plutôt que d’un simple bug.

Autre problème : les droits de l’application. Comme pointé ici aussi par Windows Latest, LG Monitor App Installer dispose de tous les droits système. Elle peut utiliser toutes les ressources et accéder à la connexion internet.

Selon certains médias, dont Gadget Review, LG aurait retiré le contenu publicitaire McAfee de son application dès le 13 juillet 2026 suite aux critiques, tout en précisant que le processus d’installation silencieuse restait pleinement opérationnel. Or, l’article de Windows Latest, publié ce 21 juillet, documente encore la présence de McAfee dans les notes de version et les captures d’écran du Store à cette date. Il est possible que le retrait ait été partiel, temporaire, ou concerne une région ou une version spécifique. Aucune confirmation officielle de LG n’existe pour trancher.

Sur la fiche de l’application dans le Store américain, les avis laissés par les utilisateurs reflètent l’agacement généralisé face à la pratique. Il semble toutefois que le ménage ait été fait, car plus aucun avis ne semble présent au moment où nous écrivons ces lignes. Sur Reddit, dans des fils comme r/pcmasterrace et r/LGOLED, le ton dominant est la surprise puis la colère : plusieurs utilisateurs rapportent n’avoir découvert le problème qu’en fouillant manuellement la liste des applications de démarrage.

Un vieux « problème »

On peut remédier à la situation de plusieurs manières. D’une part, l’application peut être désinstallée et il ne semble pas qu’elle revienne d’elle-même. C’est au moins ça de gagné. D’autre part, on peut interdire à Windows de déclencher ce type d’action de manière définitive, mais il faut plonger dans les politiques de groupe.

Commencez par appuyer sur Win + R, écrivez « gpedit.msc » et validez avec Entrée. Rendez-vous ensuite dans Configuration ordinateur > Modèles d’administration > Système > Installation de périphériques. Cherchez la ligne « Empêcher le téléchargement automatique des applications associées aux métadonnées de l’appareil », double-cliquez dessus et sélectionnez « Activé » en haut à gauche de la fenêtre qui s’est ouverte. À compter de maintenant, plus aucune installation de ce type n’aura lieu.

Il est « dommage » d’en arriver là, car le mécanisme en lui-même peut faire gagner du temps. Les personnes possédant des périphériques Logitech par exemple savent qu’en branchant une souris ou un clavier, un popup propose l’installation de l’application Logi+, qui sert à régler finement ces appareils. Seulement, il s’agit d’une proposition que l’on peut refuser, pas d’une installation automatique et silencieuse.

De nombreux autres constructeurs proposent des mécanismes équivalents. MSI et Gigabyte, par exemple, font apparaitre ce genre de petite fenêtre pour proposer l’installation d’une suite d’utilitaires pour leurs cartes mères. Encore une fois, il s’agit d’une simple proposition, qui ne réapparait le plus souvent qu’après une mise à jour majeure de Windows (par exemple après la dernière 25H2 de Windows 11).

Le mécanisme peut donc être utile, mais il n’a pas été pensé pour ce type de cas. Il est probable que les remontées au vitriol des utilisateurs aient déclenché une conversation sur le sujet entre les deux entreprises. Après tout, ce type d’incident peut rejaillir facilement sur Microsoft pour avoir fourni le mécanisme de base.

Que faudrait-il faire ? Plusieurs pistes peuvent aisément être imaginées pour régler le problème à la racine. La plus radicale est de supprimer ce comportement de Windows. On peut le faire manuellement (comme nous l’avons vu), mais Microsoft ne ferait-elle pas mieux de désactiver ces liens automatiques ? L’entreprise pourrait recourir à des solutions intermédiaires, en serrant davantage la vis pour les constructeurs qui abusent du mécanisme, par exemple en rendant obligatoire la validation de l’utilisateur et en limitant les droits de ces applications.

L'important, c'est le choix

Des propriétaires de moniteurs LG ont constaté qu’après un simple branchement de l’écran, Windows installe silencieusement une application nommée LG Monitor App Installer. Sa seule mission semble être de proposer un essai de l’antivirus McAfee. Le processus détourne une capacité du système à simplifier l’installation des composants et périphériques.

Depuis environ trois semaines, des propriétaires de moniteurs LG (essentiellement la gamme UltraGear) constatent qu’après un simple branchement de l’écran, l’application LG Monitor App Installer apparait d’elle-même, sans boîte de dialogue de consentement. Son comportement observé consiste principalement à afficher un pop-up faisant la promotion d’un essai gratuit de 30 jours de McAfee, qui bascule ensuite vers un abonnement payant (39,99 dollars la première année).

La chaîne YouTube Gamers Nexus a reproduit le phénomène en achetant un moniteur LG UltraGear 34GX900A-B (1 200 dollars) : l’installation apparaît dans le menu Démarrer environ une minute après branchement, et le pop-up McAfee s’est affiché sur 31 des 32 démarrages testés.

Qu’est-ce que c’est que ce bazar ?

Il ne s’agit pas d’un piratage, mais d’un processus basé sur une fonctionnalité parfaitement documentée depuis Windows 8. Elle est basée sur les métadonnées et se déroule en quatre étapes :

1. Connexion du périphérique
2. Récupération des métadonnées associées depuis les serveurs de Microsoft
3. Téléchargement du pilote via Windows Update
4. Téléchargement automatique de l’application associée via le Microsoft Store

Il ne faut que trois conditions pour que la chaine se lance, simples à réunir : une connexion internet, un compte Microsoft (permettant le lien avec le Store) et des paramètres non modifiés de Windows.

La simplicité du processus fait son efficacité aussi bien que le lit des critiques. Microsoft reconnait dans sa documentation que « la fonction d’installation automatique ne fournit pas de notification à l’utilisateur lors de l’installation de l’application ». L’éditeur met d’ailleurs en garde les constructeurs : « Certains utilisateurs peuvent trouver cette expérience confuse et frustrante, et attribuer une mauvaise note à votre application ». Il ne croyait pas si bien dire.

Rien ne va

Windows Latest s’est abondamment penché sur la situation. En creusant, nos confrères se sont rendu compte que LG n’en est pas à son coup d’essai. Un technicien en réparation PC avait ainsi signalé le comportement sur le forum Microsoft Tech Community dès juillet 2025, qualifiant l’app de PUP (« potentially unwanted program ») forcé à chaque branchement d’un moniteur LG en atelier. Le fil n’a cependant jamais reçu de réponse de Microsoft.

Ce qui a rendu le problème visible ces dernières semaines, c’est une mise à jour de l’application dont les notes de version ajoutent explicitement McAfee comme « application supplémentaire », le tout rédigé dans un langage très publicitaire : « Live confidently online with all-in-one protection » (« Vivez en toute confiance en ligne avec une protection tout-en-un »). Pour nos confrères, il s’agit d’un aveu indirect de LG plutôt que d’un simple bug.

Autre problème : les droits de l’application. Comme pointé ici aussi par Windows Latest, LG Monitor App Installer dispose de tous les droits système. Elle peut utiliser toutes les ressources et accéder à la connexion internet.

Selon certains médias, dont Gadget Review, LG aurait retiré le contenu publicitaire McAfee de son application dès le 13 juillet 2026 suite aux critiques, tout en précisant que le processus d’installation silencieuse restait pleinement opérationnel. Or, l’article de Windows Latest, publié ce 21 juillet, documente encore la présence de McAfee dans les notes de version et les captures d’écran du Store à cette date. Il est possible que le retrait ait été partiel, temporaire, ou concerne une région ou une version spécifique. Aucune confirmation officielle de LG n’existe pour trancher.

Sur la fiche de l’application dans le Store américain, les avis laissés par les utilisateurs reflètent l’agacement généralisé face à la pratique. Il semble toutefois que le ménage ait été fait, car plus aucun avis ne semble présent au moment où nous écrivons ces lignes. Sur Reddit, dans des fils comme r/pcmasterrace et r/LGOLED, le ton dominant est la surprise puis la colère : plusieurs utilisateurs rapportent n’avoir découvert le problème qu’en fouillant manuellement la liste des applications de démarrage.

Un vieux « problème »

On peut remédier à la situation de plusieurs manières. D’une part, l’application peut être désinstallée et il ne semble pas qu’elle revienne d’elle-même. C’est au moins ça de gagné. D’autre part, on peut interdire à Windows de déclencher ce type d’action de manière définitive, mais il faut plonger dans les politiques de groupe.

Commencez par appuyer sur Win + R, écrivez « gpedit.msc » et validez avec Entrée. Rendez-vous ensuite dans Configuration ordinateur > Modèles d’administration > Système > Installation de périphériques. Cherchez la ligne « Empêcher le téléchargement automatique des applications associées aux métadonnées de l’appareil », double-cliquez dessus et sélectionnez « Activé » en haut à gauche de la fenêtre qui s’est ouverte. À compter de maintenant, plus aucune installation de ce type n’aura lieu.

Il est « dommage » d’en arriver là, car le mécanisme en lui-même peut faire gagner du temps. Les personnes possédant des périphériques Logitech par exemple savent qu’en branchant une souris ou un clavier, un popup propose l’installation de l’application Logi+, qui sert à régler finement ces appareils. Seulement, il s’agit d’une proposition que l’on peut refuser, pas d’une installation automatique et silencieuse.

De nombreux autres constructeurs proposent des mécanismes équivalents. MSI et Gigabyte, par exemple, font apparaitre ce genre de petite fenêtre pour proposer l’installation d’une suite d’utilitaires pour leurs cartes mères. Encore une fois, il s’agit d’une simple proposition, qui ne réapparait le plus souvent qu’après une mise à jour majeure de Windows (par exemple après la dernière 25H2 de Windows 11).

Le mécanisme peut donc être utile, mais il n’a pas été pensé pour ce type de cas. Il est probable que les remontées au vitriol des utilisateurs aient déclenché une conversation sur le sujet entre les deux entreprises. Après tout, ce type d’incident peut rejaillir facilement sur Microsoft pour avoir fourni le mécanisme de base.

Que faudrait-il faire ? Plusieurs pistes peuvent aisément être imaginées pour régler le problème à la racine. La plus radicale est de supprimer ce comportement de Windows. On peut le faire manuellement (comme nous l’avons vu), mais Microsoft ne ferait-elle pas mieux de désactiver ces liens automatiques ? L’entreprise pourrait recourir à des solutions intermédiaires, en serrant davantage la vis pour les constructeurs qui abusent du mécanisme, par exemple en rendant obligatoire la validation de l’utilisateur et en limitant les droits de ces applications.

Brand new war

Hugging Face a publié le 16 juillet 2026 une divulgation d’incident au sujet d’une intrusion dans une partie de son infrastructure de production. Selon l’entreprise, cette intrusion présentait une caractéristique inédite : elle a été pilotée de bout en bout par un système d’agent IA autonome.

Au constat de cette intrusion, Hugging Face en a opposé un autre : l’incident a été détecté et analysé en grande partie par la propre IA de l’éditeur.

Dans son compte rendu, l’entreprise indique avoir identifié un accès non autorisé à un ensemble limité de jeux de données internes et à plusieurs identifiants utilisés par ses services, tout en précisant que l’évaluation de l’impact sur les données de partenaires ou clients était encore en cours. Point important pour l’écosystème : aucune preuve d’altération des modèles, datasets (lots de données) ou Spaces publics destinés aux utilisateurs n’a été trouvée. La chaîne d’approvisionnement logicielle (images de conteneurs, paquets publiés) a été vérifiée et a été déclarée comme saine.

Comment les pirates sont-ils entrés ?

Le point d’entrée se situe dans le pipeline de traitement des datasets. Un jeu de données malveillant a exploité deux chemins d’exécution de code dans le traitement des datasets : un chargeur de dataset à exécution de code distant et une injection de template dans une configuration de dataset, avec pour finalité l’exécution du code sur un worker de traitement.

À partir de ce point d’ancrage, les pirates ont progressé vers un accès au niveau du nœud, récupéré des identifiants cloud et de cluster, puis se sont déplacés latéralement dans plusieurs clusters internes pendant plusieurs jours.

Mais qui a attaqué ? On ne le sait pas encore, mais l’entreprise évoque une campagne menée par un framework d’agents autonomes, semblant construit sur un harnais de recherche en sécurité offensive de type agentique, bien que le LLM utilisé reste inconnu à ce stade. Ce framework a exécuté plusieurs milliers d’actions individuelles à travers un ensemble de sandbox (bacs à sable) éphémères, avec un serveur C&C (command-and-control) auto-migrant hébergé sur des services publics. Hugging Face, c’est la matérialisation concrète du scénario d’« attaquant agentique » anticipé par le secteur.

Les actions entreprises

Comme toujours dans ce genre d’annonce, l’entreprise liste les actions entreprises pour juguler le problème et éviter qu’il se reproduise.

Hugging Face dit ainsi avoir corrigé les chemins d’exécution de code du dataset ayant permis l’accès initial, supprimé le point d’ancrage des pirates, reconstruit les nœuds compromis, révoqué et regénéré les identifiants affectés, déclenché une rotation préventive plus large des secrets (mots de passe et autres informations identifiantes), déployé des garde-fous et contrôles d’admission plus stricts sur les clusters, et amélioré la détection pour qu’un signal de sévérité élevée déclenche une alerte en quelques minutes, tous les jours. L’entreprise ajoute travailler avec des spécialistes externes en analyse de ce type d’incident (forensic) et a signalé l’incident aux autorités judiciaires.

Rappelons que ce n’est pas la première fois que Hugging Face est attaquée et qu’une partie de ses infrastructures est compromise. En juin 2024, la société avait averti qu’un sous-ensemble de secrets avait été dérobé et que des accès non autorisés avaient été détectés dans un certain nombre de Spaces. Elle recommandait alors l’actualisation de tous les jetons et clés d’authentification.

IA contre IA

Le sujet est devenu courant depuis plusieurs mois : l’IA générative, et plus particulièrement les agents, provoquent une rupture dans le domaine de la cybersécurité. Le sujet est particulièrement prégnant depuis l’arrivée du modèle Mythos d’Anthropic, accessible depuis le fameux projet Glasswing, auquel seules des organisations triées sur le volet peuvent accéder. Ce fut notamment le cas de Mozilla.

• Firefox 150 corrige 271 vulnérabilités repérées par Claude Mythos

Hugging Face indique ainsi avoir utilisé son propre pipeline de triage basé sur des LLM pour corréler les signaux de sécurité et détecter la compromission. Pour reconstituer l’attaque, l’entreprise a fait tourner des agents d’analyse LLM sur l’intégralité du journal d’actions de l’attaquant, comprenant plus de 17 000 événements enregistrés. Elle dit avoir réussi à reconstituer la chronologie, à extraire les indicateurs de compromission, à cartographier les identifiants touchés et à séparer l’impact réel de l’activité leurre.

Elle évoque également un « problème d’asymétrie » intéressant. Hugging Face a d’abord tenté d’utiliser des modèles frontières via des API commerciales, mais ces requêtes nécessitaient de soumettre de larges volumes de commandes d’attaque réelles, des charges utiles d’exploitation et des éléments C&C. Résultat ? Elles ont été bloquées par les garde-fous de sécurité des fournisseurs, incapables de distinguer les requêtes d’un analyste travaillant à la réponse à un incident de celles d’un attaquant.

Une « leçon » à tirer, selon Hugging Face

En conséquence, Hugging Face a fini par faire tourner l’analyse forensic sur le modèle chinois GLM 5.2, dont les poids ouverts ont fait couler pas mal d’encre (le cas se reproduit avec Kimi K3). Le LLM a été exécuté sur la propre infrastructure de l’entreprise, en local, sans lien avec l’extérieur.

Hugging Face en tire justement une leçon opérationnelle : mieux vaut disposer d’un modèle capable, exécutable sur sa propre infrastructure, validé et prêt avant un incident, autant pour éviter le blocage par les garde-fous que pour empêcher que les données de l’attaquant et les identifiants quittent l’environnement. Elle ajoute cependant qu’il ne s’agit pas d’un argument contre les mesures de sécurité des modèles hébergés, et indique avoir partagé ce retour avec les fournisseurs concernés.

« Les outils offensifs autonomes pilotés par l’IA ne sont plus théoriques. Cela réduit le coût de gestion d’une campagne large, patiente et en plusieurs étapes, et cela fonctionne à la vitesse de la machine. Défendre une plateforme en ligne signifie désormais traiter la surface de données et de modèles comme une surface d’attaque de premier ordre, et utiliser l’IA en défense pour suivre le rythme. Nous continuerons à y investir et à partager ce que nous apprenons », conclut Hugging Face.

Brand new war

Hugging Face a publié le 16 juillet 2026 une divulgation d’incident au sujet d’une intrusion dans une partie de son infrastructure de production. Selon l’entreprise, cette intrusion présentait une caractéristique inédite : elle a été pilotée de bout en bout par un système d’agent IA autonome.

Au constat de cette intrusion, Hugging Face en a opposé un autre : l’incident a été détecté et analysé en grande partie par la propre IA de l’éditeur.

Dans son compte rendu, l’entreprise indique avoir identifié un accès non autorisé à un ensemble limité de jeux de données internes et à plusieurs identifiants utilisés par ses services, tout en précisant que l’évaluation de l’impact sur les données de partenaires ou clients était encore en cours. Point important pour l’écosystème : aucune preuve d’altération des modèles, datasets (lots de données) ou Spaces publics destinés aux utilisateurs n’a été trouvée. La chaîne d’approvisionnement logicielle (images de conteneurs, paquets publiés) a été vérifiée et a été déclarée comme saine.

Comment les pirates sont-ils entrés ?

Le point d’entrée se situe dans le pipeline de traitement des datasets. Un jeu de données malveillant a exploité deux chemins d’exécution de code dans le traitement des datasets : un chargeur de dataset à exécution de code distant et une injection de template dans une configuration de dataset, avec pour finalité l’exécution du code sur un worker de traitement.

À partir de ce point d’ancrage, les pirates ont progressé vers un accès au niveau du nœud, récupéré des identifiants cloud et de cluster, puis se sont déplacés latéralement dans plusieurs clusters internes pendant plusieurs jours.

Mais qui a attaqué ? On ne le sait pas encore, mais l’entreprise évoque une campagne menée par un framework d’agents autonomes, semblant construit sur un harnais de recherche en sécurité offensive de type agentique, bien que le LLM utilisé reste inconnu à ce stade. Ce framework a exécuté plusieurs milliers d’actions individuelles à travers un ensemble de sandbox (bacs à sable) éphémères, avec un serveur C&C (command-and-control) auto-migrant hébergé sur des services publics. Hugging Face, c’est la matérialisation concrète du scénario d’« attaquant agentique » anticipé par le secteur.

Les actions entreprises

Comme toujours dans ce genre d’annonce, l’entreprise liste les actions entreprises pour juguler le problème et éviter qu’il se reproduise.

Hugging Face dit ainsi avoir corrigé les chemins d’exécution de code du dataset ayant permis l’accès initial, supprimé le point d’ancrage des pirates, reconstruit les nœuds compromis, révoqué et regénéré les identifiants affectés, déclenché une rotation préventive plus large des secrets (mots de passe et autres informations identifiantes), déployé des garde-fous et contrôles d’admission plus stricts sur les clusters, et amélioré la détection pour qu’un signal de sévérité élevée déclenche une alerte en quelques minutes, tous les jours. L’entreprise ajoute travailler avec des spécialistes externes en analyse de ce type d’incident (forensic) et a signalé l’incident aux autorités judiciaires.

Rappelons que ce n’est pas la première fois que Hugging Face est attaquée et qu’une partie de ses infrastructures est compromise. En juin 2024, la société avait averti qu’un sous-ensemble de secrets avait été dérobé et que des accès non autorisés avaient été détectés dans un certain nombre de Spaces. Elle recommandait alors l’actualisation de tous les jetons et clés d’authentification.

IA contre IA

Le sujet est devenu courant depuis plusieurs mois : l’IA générative, et plus particulièrement les agents, provoquent une rupture dans le domaine de la cybersécurité. Le sujet est particulièrement prégnant depuis l’arrivée du modèle Mythos d’Anthropic, accessible depuis le fameux projet Glasswing, auquel seules des organisations triées sur le volet peuvent accéder. Ce fut notamment le cas de Mozilla.

• Firefox 150 corrige 271 vulnérabilités repérées par Claude Mythos

Hugging Face indique ainsi avoir utilisé son propre pipeline de triage basé sur des LLM pour corréler les signaux de sécurité et détecter la compromission. Pour reconstituer l’attaque, l’entreprise a fait tourner des agents d’analyse LLM sur l’intégralité du journal d’actions de l’attaquant, comprenant plus de 17 000 événements enregistrés. Elle dit avoir réussi à reconstituer la chronologie, à extraire les indicateurs de compromission, à cartographier les identifiants touchés et à séparer l’impact réel de l’activité leurre.

Elle évoque également un « problème d’asymétrie » intéressant. Hugging Face a d’abord tenté d’utiliser des modèles frontières via des API commerciales, mais ces requêtes nécessitaient de soumettre de larges volumes de commandes d’attaque réelles, des charges utiles d’exploitation et des éléments C&C. Résultat ? Elles ont été bloquées par les garde-fous de sécurité des fournisseurs, incapables de distinguer les requêtes d’un analyste travaillant à la réponse à un incident de celles d’un attaquant.

Une « leçon » à tirer, selon Hugging Face

En conséquence, Hugging Face a fini par faire tourner l’analyse forensic sur le modèle chinois GLM 5.2, dont les poids ouverts ont fait couler pas mal d’encre (le cas se reproduit avec Kimi K3). Le LLM a été exécuté sur la propre infrastructure de l’entreprise, en local, sans lien avec l’extérieur.

Hugging Face en tire justement une leçon opérationnelle : mieux vaut disposer d’un modèle capable, exécutable sur sa propre infrastructure, validé et prêt avant un incident, autant pour éviter le blocage par les garde-fous que pour empêcher que les données de l’attaquant et les identifiants quittent l’environnement. Elle ajoute cependant qu’il ne s’agit pas d’un argument contre les mesures de sécurité des modèles hébergés, et indique avoir partagé ce retour avec les fournisseurs concernés.

« Les outils offensifs autonomes pilotés par l’IA ne sont plus théoriques. Cela réduit le coût de gestion d’une campagne large, patiente et en plusieurs étapes, et cela fonctionne à la vitesse de la machine. Défendre une plateforme en ligne signifie désormais traiter la surface de données et de modèles comme une surface d’attaque de premier ordre, et utiliser l’IA en défense pour suivre le rythme. Nous continuerons à y investir et à partager ce que nous apprenons », conclut Hugging Face.

France, travaille !

France Travail travaille sur un algorithme de profilage des chômeurs à des fins de contrôle. C’est ce qu’affirme la Quadrature du Net, document interne à l’appui. Celui-ci semble être un support PowerPoint pour une présentation de 30 min. L’association déplore une massification des contrôles et un glissement dangereux des décisions politiques vers des technologies présentées comme « objectives ».

Le document présenté (PDF) a trait au ciblage du Contrôle de Recherche d’emploi, ou CRE. France Travail y évoque immédiatement la « logique d’engagements réciproques au service du retour à l’emploi ». Ainsi, tout le monde a droit à un accompagnement personnalisé dans l’objectif de retrouver un emploi. « En contrepartie, l’usager s’engage à participer aux actions proposées et à rechercher activement un emploi : c’est le devoir d’assiduité et de recherche d’emploi ». Des droits et des devoirs formalisés dans un « contrat d’engagement dynamique », dont le respect « fait l’objet d’un contrôle », le fameux CRE.

Six principes sont mis en avant : maintien du contradictoire (le demandeur doit toujours pouvoir se justifier après une notification de manquement), universalité du contrôle, équité de traitement, bénéfice du doute, maintien du lien territorial et séparation des activités de contrôle et d’accompagnement. Selon la Quadrature du Net cependant, plusieurs de ces principes pourraient être remis en cause.

Un outil IA de plus dans la besace

La présentation date de décembre 2025 et ressemble à un point d’étape sur les travaux en cours. Signalons tout de suite que France Travail dispose déjà de plusieurs outils alimentés par l’IA, comme mentionné sur son site. ChatFT assiste par exemple les conseillers dans les échanges avec les demandeurs d’emploi et facilite la création de documents. MatchFT a pour mission de faire « correspondre les offres d’emploi aux profils des candidats. Il contacte ensuite par SMS les candidats identifiés comme correspondant à l’offre pour leur proposer et les sonder sur leur intérêt ». Ces deux outils ont été développés par Mistral.

Le document porte largement sur les questions de contrôles, qui peuvent être déclenchés pour plusieurs raisons : vérification de l’assiduité, contrôles aléatoires, signalements par des agences ou encore contrôles issus de requêtes ciblées. Ces dernières sont particulièrement mises en lumière car elles « visent des situations présentant une forte probabilité d’insuffisance de recherche d’emploi » : métiers en tension, sortants de formation ou de prestations, ruptures conventionnelles, créateurs d’entreprises ou encore frontaliers. Pour 2026, France Travail envisageait 500 000 contrôles ciblés, soit 40 % du total des vérifications.

France Travail note dans ses objectifs que le CRE « vise avant tout à améliorer la qualité de l’accompagnement en permettant d’identifier si une insuffisance relève d’un besoin de soutien renforcé ou d’un contournement volontaire ». L’action prise peut être une « redynamisation », une révision du suivi ou une sanction, si « le comportement est volontairement abusif ».

Et tout le sujet du document est bien de fluidifier ce processus en se servant d’une IA pour analyser « 26 variables clés », dans l’idée de « reconstituer les parcours des demandeurs d’emploi » qui nécessitent « une expertise approfondie » qui sera alors transmise aux services CRE.

Un modèle statistique, pas un LLM

Le modèle utilisé est présenté comme statistique (arbre de décision), il ne s’agit donc pas d’IA générative (LLM). Parmi les 26 critères, on trouve l’historique des cessations, le délai d’inscription, le nombre d’entretiens, le niveau de formation, le métier recherché, l’indicateur de tension sur ce métier, les heures travaillées, la présence et l’ancienneté d’une ORE (Offre Raisonnable d’Emploi), le nombre de refus d’offres, la présence et l’ancienneté d’un CV visible, ou encore le nombre d’absences aux prestations et les synthèses des derniers entretiens. Attention cependant, le poids des variables n’est pas connu, on ne sait donc pas de quelle manière elles sont pondérées dans la formule de France Travail.

Dans le document, il est dit que le modèle est entraîné sur les données historiques du CRE, pour lui apprendre les relations entre les caractéristiques (les variables et leurs données) et les résultats des services CRE. Ainsi, le modèle apprend en faisant des prédictions basées sur le parcours, les compare à la réalité, puis corrige ses erreurs pour s’améliorer. Une approche classique. Sur un échantillon de 60 000 anciens dossiers, 79 % des dossiers ciblés par le modèle ont donné lieu à un examen complémentaire contre 53 % pour les dossiers issus de la requête aléatoire, et 64 % des dossiers ciblés ont conduit à une redynamisation ou une sanction.

L’étape suivante ? Appliquer le modèle sur la population actuelle inscrite à France Travail. Il a retourné une liste d’individus « qu’il considère comme les plus susceptibles de nécessiter un CRE ». Point intéressant, le document relève qu’une recherche active de biais de sélection a été menée. France Travail dit avoir « identifié que le modèle pouvait favoriser le contrôle des demandeurs d’emploi ayant les plus faibles revenus », ce qui avait conduit à retirer la variable « Salaire Journalier de Référence » (SJR). Elle a été réintégrée en tenant compte de la ventilation des demandeurs d’emploi par tranche de SJR « telle qu’elle existe dans la population générale ».

En outre, le document indique qu’il ne s’agit pas d’un projet de recherche : une première campagne de 7 000 tests avait déjà été menée au sein de la population des demandeurs avec une rupture conventionnelle et une deuxième campagne était « en cours de réalisation ». Pourquoi ce groupe en particulier ? Parce qu’il coûte en moyenne plus cher à France Travail.

Alors pourquoi recourir à l’IA ? Le document donne trois raisons : le nombre élevé de variables, la « suppression des a priori » grâce à l’utilisation de « critères objectifs », et le gain d’efficacité « démontré », car supérieur aux modèles actuels fondés sur des règles métiers. Le document mentionne explicitement la volonté d’élargir l’utilisation du nouveau modèle à « d’autres publics de demandeurs d’emploi ».

La Quadrature du Net dénonce une « dépolitisation »

Pour l’association, que le modèle soit un LLM n’est pas la question. Le sujet est le même que pour la CNAM et la CNAF : le solutionnisme technologique.

• Transparence, discriminations : les questions soulevées par l’algorithme de la CAF

L’association dénonce ainsi certains arguments avancés par le document, notamment la « suppression des a priori » et les « critères objectifs », présentés comme des corolaires à l’utilisation de l’intelligence artificielle. Pour la Quadrature, on assiste à la « transformation d’un problème politique – le choix des critères de sélection des personnes à contrôler – en un problème purement technique ». Une dépolitisation qui ne peut entrainer, selon l’association, qu’une « délégitimation de la critique des politiques de contrôle », ces dernières étant présentées comme « neutres » et « objectives ».

Outre la déresponsabilisation des dirigeants, la Quadrature pointe aussi l’opacité systématique autour des algorithmes de profilage. « En permettant aux responsables des institutions sociales de taire la réalité du tri social organisé, elle complique considérablement la mise en lumière de leurs dérives », fustige-t-elle. Et pour cause : le code source de l’algorithme de la CNAF « n’a été obtenu qu’après une longue bataille juridique et médiatique, tandis que celui de l’Assurance maladie ne l’a été qu’à la faveur d’une erreur de caviardage par l’administration ».

Et celui de France Travail ? « […] toutes nos demandes d’accès au code des IA utilisées par France Travail sont, à ce jour, restées lettres mortes », ajoute la Quadrature. L’association a adressé ses demandes à la CADA, mais France Travail a refusé de « communiquer la moindre information sur des IA aussi sensibles que celles utilisées pour échanger par SMS afin de proposer des offres d’emplois à des usager·ères (MatchFt) ou celle que France Travail a généralisé auprès de ses conseillers afin de les aider dans leurs tâches quotidiennes (ChatFt) », sans motivation de sa décision auprès de la CADA, « en violation flagrante de la loi ».

La Quadrature dit observer une volonté d’automatiser l’ensemble de la chaine de contrôle pour répondre aux objectifs gouvernementaux, qui incluent 1,5 million de contrôles en 2027 pour les demandeurs d’emploi. Devant l’ampleur des chantiers en cours, elle craint particulièrement l’arrivée future d’une IA générative qui, ne se contentant plus de pointer des dossiers, formulerait des suggestions de décisions.

Pour l’instant, on reste dans l’optique du « faisceau d’indices », utilisé pour braquer un projecteur sur un dossier en délicatesse. Pour France Travail, cette approche est neutre : ce n’est pas parce qu’un dossier est mis en lumière pour contrôle qu’un abus est systématiquement suspecté. Mais la massification est en cours, puisque depuis le 1ᵉʳ janvier 2026, toute personne recevant le RSA doit obligatoirement s’inscrire sur France Travail, plus de 6 millions de personnes pouvant alors être concernées en tout.

Dans le document, France Travail dit clairement son intention d’élargir le modèle à d’autres publics. La Quadrature craint de ce fait la généralisation d’un scoring et la mise en place d’une répression sociale contre les populations les plus vulnérables.

Où sont les analyses de risques ?

Ces questions sont particulièrement présentes dans une série de quatre podcasts publiée ce lundi 20 juillet par la cellule investigation de Radio France, qui a enquêté en partenariat avec la Quadrature du Net. La journaliste Audrey Travère y aborde de nombreux autres points, mais l’épisode 3 est entièrement consacré à la question de l’IA au sein de France Travail et au parallèle avec les cas de la CNAM et de la CNAF.

Elle s’est également entretenue avec Soizic Pénicaud, cofondatrice de l’Observatoire des algorithmes publics (Odap) et enseignante à Sciences-Po Paris. Celle-ci s’est dit surprise que les tests de cet algorithme aient pu se faire sans que personne n’en ait entendu parler. Pas un mot non plus sur son évaluation, d’analyse d’impact sur les données personnelles, ni « d’évaluation des discriminations entrainées par ces algorithmes ».

• [Interview] Efficacité, coût des algorithmes publics : les administrations manquent de transparence

Soizic Pénicaud rappelle en outre l’un des fondamentaux dans tout ce qui touche à l’IA : « Les humains, on sait qu’il y a des enjeux de biais, c’est incontestable, alors qu’un algorithme, on va nous dire que c’est statistique, c’est mathématique, c’est neutre, c’est objectif. En réalité, ça découle d’un ensemble de choix, et ces choix ne vont pas être questionnés. L’algorithme va systématiquement taper sur les mêmes. Et ça, ça pose un problème, car cela signifie un passage à l’échelle de la discrimination ».

Quant à l’argument de la décision humaine à la fin, là encore Soizic Pénicaud pointe l’influence algorithmique : on aura toujours tendance à plus cliquer sur un élément pointé comme très probable par une IA.

Nous avons contacté le ministère du Travail pour obtenir des informations complémentaires et actualiserons cet article en cas de réponse.

France, travaille !

France Travail travaille sur un algorithme de profilage des chômeurs à des fins de contrôle. C’est ce qu’affirme la Quadrature du Net, document interne à l’appui. Celui-ci semble être un support PowerPoint pour une présentation de 30 min. L’association déplore une massification des contrôles et un glissement dangereux des décisions politiques vers des technologies présentées comme « objectives ».

Le document présenté (PDF) a trait au ciblage du Contrôle de Recherche d’emploi, ou CRE. France Travail y évoque immédiatement la « logique d’engagements réciproques au service du retour à l’emploi ». Ainsi, tout le monde a droit à un accompagnement personnalisé dans l’objectif de retrouver un emploi. « En contrepartie, l’usager s’engage à participer aux actions proposées et à rechercher activement un emploi : c’est le devoir d’assiduité et de recherche d’emploi ». Des droits et des devoirs formalisés dans un « contrat d’engagement dynamique », dont le respect « fait l’objet d’un contrôle », le fameux CRE.

Six principes sont mis en avant : maintien du contradictoire (le demandeur doit toujours pouvoir se justifier après une notification de manquement), universalité du contrôle, équité de traitement, bénéfice du doute, maintien du lien territorial et séparation des activités de contrôle et d’accompagnement. Selon la Quadrature du Net cependant, plusieurs de ces principes pourraient être remis en cause.

Un outil IA de plus dans la besace

La présentation date de décembre 2025 et ressemble à un point d’étape sur les travaux en cours. Signalons tout de suite que France Travail dispose déjà de plusieurs outils alimentés par l’IA, comme mentionné sur son site. ChatFT assiste par exemple les conseillers dans les échanges avec les demandeurs d’emploi et facilite la création de documents. MatchFT a pour mission de faire « correspondre les offres d’emploi aux profils des candidats. Il contacte ensuite par SMS les candidats identifiés comme correspondant à l’offre pour leur proposer et les sonder sur leur intérêt ». Ces deux outils ont été développés par Mistral.

Le document porte largement sur les questions de contrôles, qui peuvent être déclenchés pour plusieurs raisons : vérification de l’assiduité, contrôles aléatoires, signalements par des agences ou encore contrôles issus de requêtes ciblées. Ces dernières sont particulièrement mises en lumière car elles « visent des situations présentant une forte probabilité d’insuffisance de recherche d’emploi » : métiers en tension, sortants de formation ou de prestations, ruptures conventionnelles, créateurs d’entreprises ou encore frontaliers. Pour 2026, France Travail envisageait 500 000 contrôles ciblés, soit 40 % du total des vérifications.

France Travail note dans ses objectifs que le CRE « vise avant tout à améliorer la qualité de l’accompagnement en permettant d’identifier si une insuffisance relève d’un besoin de soutien renforcé ou d’un contournement volontaire ». L’action prise peut être une « redynamisation », une révision du suivi ou une sanction, si « le comportement est volontairement abusif ».

Et tout le sujet du document est bien de fluidifier ce processus en se servant d’une IA pour analyser « 26 variables clés », dans l’idée de « reconstituer les parcours des demandeurs d’emploi » qui nécessitent « une expertise approfondie » qui sera alors transmise aux services CRE.

Un modèle statistique, pas un LLM

Le modèle utilisé est présenté comme statistique (arbre de décision), il ne s’agit donc pas d’IA générative (LLM). Parmi les 26 critères, on trouve l’historique des cessations, le délai d’inscription, le nombre d’entretiens, le niveau de formation, le métier recherché, l’indicateur de tension sur ce métier, les heures travaillées, la présence et l’ancienneté d’une ORE (Offre Raisonnable d’Emploi), le nombre de refus d’offres, la présence et l’ancienneté d’un CV visible, ou encore le nombre d’absences aux prestations et les synthèses des derniers entretiens. Attention cependant, le poids des variables n’est pas connu, on ne sait donc pas de quelle manière elles sont pondérées dans la formule de France Travail.

Dans le document, il est dit que le modèle est entraîné sur les données historiques du CRE, pour lui apprendre les relations entre les caractéristiques (les variables et leurs données) et les résultats des services CRE. Ainsi, le modèle apprend en faisant des prédictions basées sur le parcours, les compare à la réalité, puis corrige ses erreurs pour s’améliorer. Une approche classique. Sur un échantillon de 60 000 anciens dossiers, 79 % des dossiers ciblés par le modèle ont donné lieu à un examen complémentaire contre 53 % pour les dossiers issus de la requête aléatoire, et 64 % des dossiers ciblés ont conduit à une redynamisation ou une sanction.

L’étape suivante ? Appliquer le modèle sur la population actuelle inscrite à France Travail. Il a retourné une liste d’individus « qu’il considère comme les plus susceptibles de nécessiter un CRE ». Point intéressant, le document relève qu’une recherche active de biais de sélection a été menée. France Travail dit avoir « identifié que le modèle pouvait favoriser le contrôle des demandeurs d’emploi ayant les plus faibles revenus », ce qui avait conduit à retirer la variable « Salaire Journalier de Référence » (SJR). Elle a été réintégrée en tenant compte de la ventilation des demandeurs d’emploi par tranche de SJR « telle qu’elle existe dans la population générale ».

En outre, le document indique qu’il ne s’agit pas d’un projet de recherche : une première campagne de 7 000 tests avait déjà été menée au sein de la population des demandeurs avec une rupture conventionnelle et une deuxième campagne était « en cours de réalisation ». Pourquoi ce groupe en particulier ? Parce qu’il coûte en moyenne plus cher à France Travail.

Alors pourquoi recourir à l’IA ? Le document donne trois raisons : le nombre élevé de variables, la « suppression des a priori » grâce à l’utilisation de « critères objectifs », et le gain d’efficacité « démontré », car supérieur aux modèles actuels fondés sur des règles métiers. Le document mentionne explicitement la volonté d’élargir l’utilisation du nouveau modèle à « d’autres publics de demandeurs d’emploi ».

La Quadrature du Net dénonce une « dépolitisation »

Pour l’association, que le modèle soit un LLM n’est pas la question. Le sujet est le même que pour la CNAM et la CNAF : le solutionnisme technologique.

• Transparence, discriminations : les questions soulevées par l’algorithme de la CAF

L’association dénonce ainsi certains arguments avancés par le document, notamment la « suppression des a priori » et les « critères objectifs », présentés comme des corolaires à l’utilisation de l’intelligence artificielle. Pour la Quadrature, on assiste à la « transformation d’un problème politique – le choix des critères de sélection des personnes à contrôler – en un problème purement technique ». Une dépolitisation qui ne peut entrainer, selon l’association, qu’une « délégitimation de la critique des politiques de contrôle », ces dernières étant présentées comme « neutres » et « objectives ».

Outre la déresponsabilisation des dirigeants, la Quadrature pointe aussi l’opacité systématique autour des algorithmes de profilage. « En permettant aux responsables des institutions sociales de taire la réalité du tri social organisé, elle complique considérablement la mise en lumière de leurs dérives », fustige-t-elle. Et pour cause : le code source de l’algorithme de la CNAF « n’a été obtenu qu’après une longue bataille juridique et médiatique, tandis que celui de l’Assurance maladie ne l’a été qu’à la faveur d’une erreur de caviardage par l’administration ».

Et celui de France Travail ? « […] toutes nos demandes d’accès au code des IA utilisées par France Travail sont, à ce jour, restées lettres mortes », ajoute la Quadrature. L’association a adressé ses demandes à la CADA, mais France Travail a refusé de « communiquer la moindre information sur des IA aussi sensibles que celles utilisées pour échanger par SMS afin de proposer des offres d’emplois à des usager·ères (MatchFt) ou celle que France Travail a généralisé auprès de ses conseillers afin de les aider dans leurs tâches quotidiennes (ChatFt) », sans motivation de sa décision auprès de la CADA, « en violation flagrante de la loi ».

La Quadrature dit observer une volonté d’automatiser l’ensemble de la chaine de contrôle pour répondre aux objectifs gouvernementaux, qui incluent 1,5 million de contrôles en 2027 pour les demandeurs d’emploi. Devant l’ampleur des chantiers en cours, elle craint particulièrement l’arrivée future d’une IA générative qui, ne se contentant plus de pointer des dossiers, formulerait des suggestions de décisions.

Pour l’instant, on reste dans l’optique du « faisceau d’indices », utilisé pour braquer un projecteur sur un dossier en délicatesse. Pour France Travail, cette approche est neutre : ce n’est pas parce qu’un dossier est mis en lumière pour contrôle qu’un abus est systématiquement suspecté. Mais la massification est en cours, puisque depuis le 1ᵉʳ janvier 2026, toute personne recevant le RSA doit obligatoirement s’inscrire sur France Travail, plus de 6 millions de personnes pouvant alors être concernées en tout.

Dans le document, France Travail dit clairement son intention d’élargir le modèle à d’autres publics. La Quadrature craint de ce fait la généralisation d’un scoring et la mise en place d’une répression sociale contre les populations les plus vulnérables.

Où sont les analyses de risques ?

Ces questions sont particulièrement présentes dans une série de quatre podcasts publiée ce lundi 20 juillet par la cellule investigation de Radio France, qui a enquêté en partenariat avec la Quadrature du Net. La journaliste Audrey Travère y aborde de nombreux autres points, mais l’épisode 3 est entièrement consacré à la question de l’IA au sein de France Travail et au parallèle avec les cas de la CNAM et de la CNAF.

Elle s’est également entretenue avec Soizic Pénicaud, cofondatrice de l’Observatoire des algorithmes publics (Odap) et enseignante à Sciences-Po Paris. Celle-ci s’est dit surprise que les tests de cet algorithme aient pu se faire sans que personne n’en ait entendu parler. Pas un mot non plus sur son évaluation, d’analyse d’impact sur les données personnelles, ni « d’évaluation des discriminations entrainées par ces algorithmes ».

• [Interview] Efficacité, coût des algorithmes publics : les administrations manquent de transparence

Soizic Pénicaud rappelle en outre l’un des fondamentaux dans tout ce qui touche à l’IA : « Les humains, on sait qu’il y a des enjeux de biais, c’est incontestable, alors qu’un algorithme, on va nous dire que c’est statistique, c’est mathématique, c’est neutre, c’est objectif. En réalité, ça découle d’un ensemble de choix, et ces choix ne vont pas être questionnés. L’algorithme va systématiquement taper sur les mêmes. Et ça, ça pose un problème, car cela signifie un passage à l’échelle de la discrimination ».

Quant à l’argument de la décision humaine à la fin, là encore Soizic Pénicaud pointe l’influence algorithmique : on aura toujours tendance à plus cliquer sur un élément pointé comme très probable par une IA.

Nous avons contacté le ministère du Travail pour obtenir des informations complémentaires et actualiserons cet article en cas de réponse.

Ça va comme les vagues de chaleur

Microsoft a publié une nouvelle version de son Patch Tuesday à destination des ordinateurs Dell qui présentaient un sérieux problème de surchauffe. Pour ces machines, le téléchargement et l’installation automatique avaient été coupés. Il est maintenant de retour.

Le Patch Tuesday de juillet a corrigé 570 failles dans Windows 11, marquant un record absolu pour Microsoft, presque le triple du mois précédent. Dans cette mise à jour mensuelle, on trouvait également une nouvelle interface système pour le gestionnaire de connexions USB-C.

Quelques jours plus tard, rien n’allait plus : certains ordinateurs Dell présentaient des problèmes de surchauffe, de performances fortement dégradées et d’autonomie nettement réduite. La faute à une incompatibilité avec le composant Innovation Platform Framework d’Intel, chargé de l’allocation thermique, des limites d’alimentation (Power Limits PL1/PL2) et des politiques de refroidissement passif/actif au niveau du processeur.

Depuis ce 18 juillet, une nouvelle mise à jour est proposée par Windows Update pour résoudre le problème, Microsoft ayant été en contact avec Intel. Elle a été publiée hors cycle mensuel, une procédure que Microsoft n’utilise en général que pour les problèmes les plus sérieux.

Une mise à jour pour… tout le monde

Le nouveau correctif semble effectivement corriger le problème, mais il est déployé curieusement sur l’ensemble des machines si vous avez activé l’option « Recevez les dernières mises à jour dès qu’elles sont disponibles ». L’une de nos machines l’a ainsi reçue, nécessitant un triple redémarrage. Attention, ce n’est pas un comportement louche, cela peut arriver avec certaines mises à jour, ne forcez pas l’extinction de la machine.

Au sujet des modèles initialement concernés, Windows Latest en donne une liste compilée depuis ses sources :

• Dell Pro Max 14 Premium MA14250
• Dell Pro Max 16 Premium MA16250
• Dell Pro Precision 7 14 PW714260
• Dell Pro Precision 7 16 PW716260
• Precision 5470, 5480, 5490 et 5770
• XPS 17 9720 et 9730

Nos confrères signalent que les machines non concernées par le défaut ne devraient pas installer la mise à jour et fustigent le manque de précision de Microsoft dans la nomenclature de ces téléchargements. Si vous n’avez fait aucun changement dans Windows Update, le correctif attend dans les mises à jour optionnelles, comme l’indique Microsoft dans ses notes de version.

L’entreprise ajoute que cette mise à jour « est uniquement recommandée pour les appareils concernés par ce problème » et devrait s’installer automatiquement sur les ordinateurs dont le Patch Tuesday avait été bloqué à cause de l’incompatibilité. Dans le cas de notre machine, non concernée par le problème, aucun comportement étrange n’est à déplorer cependant malgré de multiples essais (bureautique, jeux, sur secteur ou non…).

Ça va comme les vagues de chaleur

Microsoft a publié une nouvelle version de son Patch Tuesday à destination des ordinateurs Dell qui présentaient un sérieux problème de surchauffe. Pour ces machines, le téléchargement et l’installation automatique avaient été coupés. Il est maintenant de retour.

Le Patch Tuesday de juillet a corrigé 570 failles dans Windows 11, marquant un record absolu pour Microsoft, presque le triple du mois précédent. Dans cette mise à jour mensuelle, on trouvait également une nouvelle interface système pour le gestionnaire de connexions USB-C.

Quelques jours plus tard, rien n’allait plus : certains ordinateurs Dell présentaient des problèmes de surchauffe, de performances fortement dégradées et d’autonomie nettement réduite. La faute à une incompatibilité avec le composant Innovation Platform Framework d’Intel, chargé de l’allocation thermique, des limites d’alimentation (Power Limits PL1/PL2) et des politiques de refroidissement passif/actif au niveau du processeur.

Depuis ce 18 juillet, une nouvelle mise à jour est proposée par Windows Update pour résoudre le problème, Microsoft ayant été en contact avec Intel. Elle a été publiée hors cycle mensuel, une procédure que Microsoft n’utilise en général que pour les problèmes les plus sérieux.

Une mise à jour pour… tout le monde

Le nouveau correctif semble effectivement corriger le problème, mais il est déployé curieusement sur l’ensemble des machines si vous avez activé l’option « Recevez les dernières mises à jour dès qu’elles sont disponibles ». L’une de nos machines l’a ainsi reçue, nécessitant un triple redémarrage. Attention, ce n’est pas un comportement louche, cela peut arriver avec certaines mises à jour, ne forcez pas l’extinction de la machine.

Au sujet des modèles initialement concernés, Windows Latest en donne une liste compilée depuis ses sources :

• Dell Pro Max 14 Premium MA14250
• Dell Pro Max 16 Premium MA16250
• Dell Pro Precision 7 14 PW714260
• Dell Pro Precision 7 16 PW716260
• Precision 5470, 5480, 5490 et 5770
• XPS 17 9720 et 9730

Nos confrères signalent que les machines non concernées par le défaut ne devraient pas installer la mise à jour et fustigent le manque de précision de Microsoft dans la nomenclature de ces téléchargements. Si vous n’avez fait aucun changement dans Windows Update, le correctif attend dans les mises à jour optionnelles, comme l’indique Microsoft dans ses notes de version.

L’entreprise ajoute que cette mise à jour « est uniquement recommandée pour les appareils concernés par ce problème » et devrait s’installer automatiquement sur les ordinateurs dont le Patch Tuesday avait été bloqué à cause de l’incompatibilité. Dans le cas de notre machine, non concernée par le problème, aucun comportement étrange n’est à déplorer cependant malgré de multiples essais (bureautique, jeux, sur secteur ou non…).