Le 21 juillet, OpenAI a publié un communiqué étonnant : un de ses systèmes IA était responsable de l’attaque orchestrée contre Hugging Face. Des détails étaient fournis, mais l’histoire gardait des zones d’ombre. Si l’incident a été transformé en opportunité commerciale, il semble être le résultat d’une vaste carence en sécurité.
Dans notre article du 22 juillet, nous relations les évènements tels qu’ils ont été décrits par OpenAI et Hugging Face. Dans les grandes lignes, la plateforme open source dédiée à l’IA avait révélé le 16 juillet avoir été attaqué par au moins un agent IA autonome. Cinq jours plus tard, OpenAI communiquait pour annoncer être indirectement à l’origine de l’attaque.
Illustration : Flock
Que s’était-il passé ? OpenAI avait expliqué que des tests étaient en cours sur un système d’IA comprenant le récent modèle GPT-5.6 Sol ainsi qu’un autre, décrit comme simplement plus puissant. Dans ces tests, les garde-fous avaient été levés pour mesurer justement les capacités des modèles.
L’un des tests demandait aux modèles de résoudre un certain problème. Ces derniers avaient estimé que la réponse se trouvait probablement chez Hugging Face. Ils s’étaient alors échappés de leur environnement de test (révélant au passage une faille signalée à l’éditeur tiers concerné), avaient récupéré des identifiants de membres du personnel de Hugging Face et fouillé dans l’infrastructure de l’entreprise, compromettant au passage une partie des serveurs.
Une semaine pour s’en apercevoir
L’histoire comportait de nombreuses zones d’ombre. Nous relevions par exemple qu’il s’était écoulé cinq jours entre la présentation de l’attaque par Hugging Face et le communiqué d’OpenAI sur ce qui s’était passé. Cette dernière n’avait-elle donc découvert l’incident qu’avec le billet de Hugging Face ? Selon Reuters, ce serait bien le cas.
Selon nos confrères, la chronologie ne plaide pas en faveur d’OpenAI. L’agent se serait ainsi échappé de son environnement de test le 9 juillet et aurait commencé son intrusion chez Hugging Face le 11. OpenAI n’aurait compris la responsabilité de son système qu’à la publication du billet de Hugging Face le 16 juillet. Des membres du personnel n’auraient commencé à trouver des traces d’activité suspecte dans les journaux internes que durant le week-end du 18 - 19 juillet. Les deux entreprises ne se seraient pas parlées avant le 20 juillet, aboutissant à la communication publique du 21 juillet.
Reuters évoque deux sources proches du dossier, selon lesquelles il se serait donc écoulé une semaine avant qu’OpenAI s’aperçoive de sa responsabilité, entre la sortie de l’agent le 9 juillet et le billet de Hugging Face le 16.
Comment expliquer une telle latence ? Cette lenteur s’expliquerait par le fait qu’OpenAI fait tourner plusieurs tests simultanément, rendant difficile pour les employés la surveillance individuelle de chaque test, tant la masse de données générées est importante. Reuters apporte d’autres informations, notamment la création par un agent d’une note destinée à de futures versions de lui-même et contenant des instructions sur la manière de s’échapper des contraintes imposées par OpenAI. En revanche, l’article ne dit pas si cet agent en particulier est lié à l’attaque.
Autre point important, Hugging Face avait évoqué un contact avec les forces de l’ordre. D’après l’agence de presse, il s’agit bien du FBI qui n’a pas souhaité réagir. Silence également de la part de la plateforme. Chez OpenAI, une porte-parole a déclaré que l’article de Reuters contenait « plusieurs inexactitudes », mais n’a pas répondu aux demandes de détails.
Le 21 juillet, OpenAI a publié un communiqué étonnant : un de ses systèmes IA était responsable de l’attaque orchestrée contre Hugging Face. Des détails étaient fournis, mais l’histoire gardait des zones d’ombre. Si l’incident a été transformé en opportunité commerciale, il semble être le résultat d’une vaste carence en sécurité.
Dans notre article du 22 juillet, nous relations les évènements tels qu’ils ont été décrits par OpenAI et Hugging Face. Dans les grandes lignes, la plateforme open source dédiée à l’IA avait révélé le 16 juillet avoir été attaqué par au moins un agent IA autonome. Cinq jours plus tard, OpenAI communiquait pour annoncer être indirectement à l’origine de l’attaque.
Illustration : Flock
Que s’était-il passé ? OpenAI avait expliqué que des tests étaient en cours sur un système d’IA comprenant le récent modèle GPT-5.6 Sol ainsi qu’un autre, décrit comme simplement plus puissant. Dans ces tests, les garde-fous avaient été levés pour mesurer justement les capacités des modèles.
L’un des tests demandait aux modèles de résoudre un certain problème. Ces derniers avaient estimé que la réponse se trouvait probablement chez Hugging Face. Ils s’étaient alors échappés de leur environnement de test (révélant au passage une faille signalée à l’éditeur tiers concerné), avaient récupéré des identifiants de membres du personnel de Hugging Face et fouillé dans l’infrastructure de l’entreprise, compromettant au passage une partie des serveurs.
Une semaine pour s’en apercevoir
L’histoire comportait de nombreuses zones d’ombre. Nous relevions par exemple qu’il s’était écoulé cinq jours entre la présentation de l’attaque par Hugging Face et le communiqué d’OpenAI sur ce qui s’était passé. Cette dernière n’avait-elle donc découvert l’incident qu’avec le billet de Hugging Face ? Selon Reuters, ce serait bien le cas.
Selon nos confrères, la chronologie ne plaide pas en faveur d’OpenAI. L’agent se serait ainsi échappé de son environnement de test le 9 juillet et aurait commencé son intrusion chez Hugging Face le 11. OpenAI n’aurait compris la responsabilité de son système qu’à la publication du billet de Hugging Face le 16 juillet. Des membres du personnel n’auraient commencé à trouver des traces d’activité suspecte dans les journaux internes que durant le week-end du 18 - 19 juillet. Les deux entreprises ne se seraient pas parlées avant le 20 juillet, aboutissant à la communication publique du 21 juillet.
Reuters évoque deux sources proches du dossier, selon lesquelles il se serait donc écoulé une semaine avant qu’OpenAI s’aperçoive de sa responsabilité, entre la sortie de l’agent le 9 juillet et le billet de Hugging Face le 16.
Comment expliquer une telle latence ? Cette lenteur s’expliquerait par le fait qu’OpenAI fait tourner plusieurs tests simultanément, rendant difficile pour les employés la surveillance individuelle de chaque test, tant la masse de données générées est importante. Reuters apporte d’autres informations, notamment la création par un agent d’une note destinée à de futures versions de lui-même et contenant des instructions sur la manière de s’échapper des contraintes imposées par OpenAI. En revanche, l’article ne dit pas si cet agent en particulier est lié à l’attaque.
Autre point important, Hugging Face avait évoqué un contact avec les forces de l’ordre. D’après l’agence de presse, il s’agit bien du FBI qui n’a pas souhaité réagir. Silence également de la part de la plateforme. Chez OpenAI, une porte-parole a déclaré que l’article de Reuters contenait « plusieurs inexactitudes », mais n’a pas répondu aux demandes de détails.
Le 24 juillet, l’Arcep a annoncé l’ouverture d’une consultation publique pour élargir sa collecte de données environnementales, en perspective de l’édition 2028 de son enquête annuelle « Pour un numérique soutenable », à la suite d’une campagne de collecte qui aurait donc lieu en 2027.
Rappelons que depuis 2020, l’Arcep collecte des indicateurs environnementaux auprès des acteurs du numérique, mission formalisée par le gouvernement l’année suivante et consolidée juridiquement par la loi REEN de décembre 2021. L’autorité dispose ainsi d’un pouvoir de collecte auprès des opérateurs télécoms, fournisseurs de services de communication en ligne, opérateurs de centres de données, fabricants de terminaux, équipementiers réseaux et fournisseurs de systèmes d’exploitation.
Les données recueillies sont présentées depuis, chaque année, dans ses rapports sur le numérique soutenable. En mars 2024 par exemple, le rapport incluait pour la première fois des informations sur la consommation des box, décodeurs et répéteurs.
Illustration : Flock
Dès l’automne dernier, l’autorité avait cependant annoncé sa volonté de capter de nouvelles informations pour mesurer l’impact environnemental de l’IA. C’est l’objet de la nouvelle consultation publique, avec deux extensions principales au recueil de données.
Chez les fournisseurs d’IA générative d’abord, l’Arcep propose de collecter des indicateurs permettant d’évaluer les émissions de gaz à effet de serre associées, de documenter les caractéristiques des modèles sous-jacents aux services les plus utilisés en France, et de mesurer les ressources mobilisées en entraînement et en inférence : volume de calcul, temps cumulé d’usage des processeurs et consommation énergétique.
Chez les opérateurs de centres de données et fournisseurs de services cloud, les nouveaux indicateurs serviraient à vérifier comment la chaleur est valorisée, à évaluer l’influence des systèmes de refroidissement sur l’empreinte environnementale des centres de données et à couvrir les obligations du règlement délégué (UE) 2024/1364, en application de la directive européenne sur l’efficacité énergétique (directive UE 2023/1791, dite EED), qui pose l’obligation de reporting pour les centres de données.
La consultation publique est ouverte à toutes les parties prenantes jusqu’au 30 septembre. La décision finale de collecte est attendue d’ici fin 2026, sous réserve d’homologation par la ministre déléguée chargée de l’IA et du numérique.
Le 24 juillet, l’Arcep a annoncé l’ouverture d’une consultation publique pour élargir sa collecte de données environnementales, en perspective de l’édition 2028 de son enquête annuelle « Pour un numérique soutenable », à la suite d’une campagne de collecte qui aurait donc lieu en 2027.
Rappelons que depuis 2020, l’Arcep collecte des indicateurs environnementaux auprès des acteurs du numérique, mission formalisée par le gouvernement l’année suivante et consolidée juridiquement par la loi REEN de décembre 2021. L’autorité dispose ainsi d’un pouvoir de collecte auprès des opérateurs télécoms, fournisseurs de services de communication en ligne, opérateurs de centres de données, fabricants de terminaux, équipementiers réseaux et fournisseurs de systèmes d’exploitation.
Les données recueillies sont présentées depuis, chaque année, dans ses rapports sur le numérique soutenable. En mars 2024 par exemple, le rapport incluait pour la première fois des informations sur la consommation des box, décodeurs et répéteurs.
Illustration : Flock
Dès l’automne dernier, l’autorité avait cependant annoncé sa volonté de capter de nouvelles informations pour mesurer l’impact environnemental de l’IA. C’est l’objet de la nouvelle consultation publique, avec deux extensions principales au recueil de données.
Chez les fournisseurs d’IA générative d’abord, l’Arcep propose de collecter des indicateurs permettant d’évaluer les émissions de gaz à effet de serre associées, de documenter les caractéristiques des modèles sous-jacents aux services les plus utilisés en France, et de mesurer les ressources mobilisées en entraînement et en inférence : volume de calcul, temps cumulé d’usage des processeurs et consommation énergétique.
Chez les opérateurs de centres de données et fournisseurs de services cloud, les nouveaux indicateurs serviraient à vérifier comment la chaleur est valorisée, à évaluer l’influence des systèmes de refroidissement sur l’empreinte environnementale des centres de données et à couvrir les obligations du règlement délégué (UE) 2024/1364, en application de la directive européenne sur l’efficacité énergétique (directive UE 2023/1791, dite EED), qui pose l’obligation de reporting pour les centres de données.
La consultation publique est ouverte à toutes les parties prenantes jusqu’au 30 septembre. La décision finale de collecte est attendue d’ici fin 2026, sous réserve d’homologation par la ministre déléguée chargée de l’IA et du numérique.
Pour les personnes intéressées par une couverture supplémentaire des équipements neufs chez Apple, il fallait jusqu’à présent souscrire un contrat AppleCare distinct pour chaque appareil acheté chez Apple. AppleCare One permet d’ajouter jusqu’à trois appareils sous un même abonnement : iPhone, Mac, Apple Watch, iPad, AirPods, Apple TV, HomePod ou Apple Vision Pro. La seule condition est que les appareils soient rattachés au même compte iCloud.
En France, la formule de base sera facturée 20,99 euros par mois pour trois appareils, avec un supplément de 5,99 euros par mois par appareil additionnel, comme indiqué sur la page dédiée du site officiel. À titre de comparaison, la protection du seul iPhone coûte à partir de 9,99 euros par mois ou 99,99 euros par an, bien que le tarif évolue en fonction du modèle.
Au-delà de l’aspect tarifaire, les prestations sont celles de l’assistance AppleCare+. Pour un iPhone, un iPad ou une Apple Watch, cela signifie par exemple jusqu’à trois déclarations de perte ou de vol par an. Un point important, car le vol n’est pas compris dans la garantie AppleCare standard. La formule prend également en charge un nombre illimité de réparations pour dégâts accidentels, ainsi qu’une assistance prioritaire.
Les réparations peuvent être effectuées « souvent » le jour même en Apple Store ou centre de service agréé, et dans n’importe quel pays où sont implantées ces structures (Apple évoque plus de 5 000 centres agréés dans le monde).
Attention cependant sur les réparations, car une franchise s’applique : 29 euros pour les réparations d’écran et les dégâts sur le dos en verre, 99 euros pour tous les autres dégâts accidentels, et 129 euros en cas de perte ou de vol. Durant toute la durée de couverture en revanche, le remplacement de la batterie est gratuit si la capacité passe sous la barre des 80 %.
AppleCare One est donc un AppleCare+ pour plusieurs appareils à un tarif réduit en comparaison du cumul classique. Il y a en outre un sérieux avantage : si AppleCare+ doit être souscrit dans les 60 jours suivant l’achat du produit neuf, AppleCare One peut prendre en charge des appareils ayant jusqu’à 4 ans, à condition qu’ils soient en bon état. Auquel cas, après ajout du numéro de série dans la déclaration en ligne, un examen physique en magasin sera peut-être nécessaire. C’est en tout cas ce qu’indiquait Apple au lancement de cette garantie en juillet 2025 lors du lancement aux États-Unis.
Pour les personnes intéressées par une couverture supplémentaire des équipements neufs chez Apple, il fallait jusqu’à présent souscrire un contrat AppleCare distinct pour chaque appareil acheté chez Apple. AppleCare One permet d’ajouter jusqu’à trois appareils sous un même abonnement : iPhone, Mac, Apple Watch, iPad, AirPods, Apple TV, HomePod ou Apple Vision Pro. La seule condition est que les appareils soient rattachés au même compte iCloud.
En France, la formule de base sera facturée 20,99 euros par mois pour trois appareils, avec un supplément de 5,99 euros par mois par appareil additionnel, comme indiqué sur la page dédiée du site officiel. À titre de comparaison, la protection du seul iPhone coûte à partir de 9,99 euros par mois ou 99,99 euros par an, bien que le tarif évolue en fonction du modèle.
Au-delà de l’aspect tarifaire, les prestations sont celles de l’assistance AppleCare+. Pour un iPhone, un iPad ou une Apple Watch, cela signifie par exemple jusqu’à trois déclarations de perte ou de vol par an. Un point important, car le vol n’est pas compris dans la garantie AppleCare standard. La formule prend également en charge un nombre illimité de réparations pour dégâts accidentels, ainsi qu’une assistance prioritaire.
Les réparations peuvent être effectuées « souvent » le jour même en Apple Store ou centre de service agréé, et dans n’importe quel pays où sont implantées ces structures (Apple évoque plus de 5 000 centres agréés dans le monde).
Attention cependant sur les réparations, car une franchise s’applique : 29 euros pour les réparations d’écran et les dégâts sur le dos en verre, 99 euros pour tous les autres dégâts accidentels, et 129 euros en cas de perte ou de vol. Durant toute la durée de couverture en revanche, le remplacement de la batterie est gratuit si la capacité passe sous la barre des 80 %.
AppleCare One est donc un AppleCare+ pour plusieurs appareils à un tarif réduit en comparaison du cumul classique. Il y a en outre un sérieux avantage : si AppleCare+ doit être souscrit dans les 60 jours suivant l’achat du produit neuf, AppleCare One peut prendre en charge des appareils ayant jusqu’à 4 ans, à condition qu’ils soient en bon état. Auquel cas, après ajout du numéro de série dans la déclaration en ligne, un examen physique en magasin sera peut-être nécessaire. C’est en tout cas ce qu’indiquait Apple au lancement de cette garantie en juillet 2025 lors du lancement aux États-Unis.
Une discussion a été ouverte au sein du projet sur la manière dont il faut considérer les participations au code quand elles sont soutenues par les LLM. Ce n’est pas la première fois que la communauté essaie de statuer sur l’IA générative.
Debian a ouvert une résolution générale (GR) sur l’usage des LLM au sein du projet. La période de discussion a débuté le 24 juillet 2026, après des semaines de débat sur la liste de diffusion debian-vote.
Ce n’est pas la première tentative sur ce sujet. Une précédente discussion menée par l’ex-DPL (Debian Project Leader) Lucas Nussbaum, en février-mars 2026, s’était soldée par un abandon du vote, la communauté ayant préféré continuer à traiter les contributions IA au cas par cas. Le projet Debian avait décidé de ne pas décider. Cette résolution relance donc le débat avec un texte plus structuré et davantage de propositions.
Quatre propositions, du radical au plus mesuré
La proposition A, portée par Matthias Geiger et Jesse Rhodes, est la plus radicale : l’interdiction de toute contribution directe rédigée avec l’aide de LLM : paquets sources, logiciels officiels (lintian, etc.), ressources web, documentation, traductions, communications officielles. Les projets amont utilisant l’IA, ainsi que les correctifs de sécurité amont, sont exclus du périmètre. Le texte propose même d’ajouter un point 6 au Contrat Social de Debian sur le sujet.
Plusieurs arguments sont donnés. D’abord, le statut juridique flou du copyright des sorties de LLM. Ensuite, des problèmes de qualité (paquets mal formés, fichiers watch non fonctionnels). En outre, un impact sur la dynamique communautaire : charge de relecture, non-apprentissage des nouveaux contributeurs, etc. Enfin, la question éthique, le scraping massif ayant perturbé l’infrastructure web de Debian et la question de l’empreinte environnementale étant prégnante.
La proposition B, portée par l’ancien DPL, Lucas Nussbaum, est plus mesurée. Elle autorise les contributions assistées par IA sous six conditions cumulatives :
compatibilité légale de l’outil utilisé
vérification des droits sur le contenu préexistant réutilisé
responsabilité totale du contributeur
divulgation de l’usage via un tag Git type Generated-By: ou Assisted-By:
discussion préalable pour les modifications massives ou automatisées
interdiction de transmettre des données sensibles (rapports de sécurité sous embargo, discussions privées) à des fournisseurs IA non fiables
La proposition C, portée par Ian Jackson, est un rejet de principe mais « pragmatique ». Elle demande à tous les contributeurs d’éviter les LLM et appelle plus largement la communauté du logiciel libre à rejeter cette technologie, tout en reconnaissant qu’une interdiction totale est impraticable puisque de nombreux projets amont y recourent. Il propose cependant des règles strictes : les messages destinés aux humains (rapports de bugs, listes de diffusion, Salsa, blogs Planet Debian) doivent être rédigés uniquement par des humains, tout usage de LLM doit être divulgué, les mainteneurs individuels peuvent totalement bannir l’IA sur leurs projets. Et la plus stricte d’entre elles : les violations sont traitées comme des manquements au Code de Conduite.
Quant à la proposition D, portée par Pierre-Elliott Bécue, elle ressemble beaucoup à la B dans l’esprit : une acceptation encadrée, portée sur les responsabilités. En clair, Debian n’endosse pas l’usage de l’IA générative mais reconnaît sa réalité et refuse une interdiction jugée « contre-productive et inapplicable ». Cette proposition place la responsabilité sur le contributeur (conformité DFSG, signature GPG personnelle, marquage de l’usage IA dans les commits et notes de version), avec une clause spécifique interdisant l’usage d’IA cloud pour des données sensibles ou non publiques.
Une décision importante
Plusieurs éléments intéressants entourant cette nouvelle résolution générale. D’abord, la proximité avec l’ancienne : à peine quelques mois, signalant le besoin pour les développeurs de trancher un sujet devenu central. L’IA générative est partout et les LLM sont utilisés dans une part croissante des projets. Précisons quand même que la précédente discussion en février-mars n’a pas atteint le statut officiel de GR. Il s’est écoulé environ un mois entre le brouillon alors préparé par Lucas Nussbaum et l’abandon du processus.
On ne sait pas combien de temps durera la résolution générale, mais la discussion et le vote seront importants. Debian n’est pas n’importe quelle distribution : en plus de son utilisation proprement dite, elle sert de socle à de nombreux autres systèmes, dont le plus connu est Ubuntu, la distribution Linux la plus utilisée aujourd’hui. Ce qui n’empêche pas d’autres organisations, comme Canonical, de procéder à des modifications assistées par IA.
Cette résolution cristallise de nombreux aspects entourant les LLM. Le fait que les questions éthiques et environnementales fassent partie de la réflexion est significatif, mais le sujet est complexe : comment trancher entre une interrogation croissante sur les gains potentiels et les conséquences négatives d’une utilisation intensive ? Si les membres du projet Debian regardent en direction de Linus Torvalds, une proposition B ou D pourrait l’emporter : une vision pragmatique et responsabilisée des contributions.
Une discussion a été ouverte au sein du projet sur la manière dont il faut considérer les participations au code quand elles sont soutenues par les LLM. Ce n’est pas la première fois que la communauté essaie de statuer sur l’IA générative.
Debian a ouvert une résolution générale (GR) sur l’usage des LLM au sein du projet. La période de discussion a débuté le 24 juillet 2026, après des semaines de débat sur la liste de diffusion debian-vote.
Ce n’est pas la première tentative sur ce sujet. Une précédente discussion menée par l’ex-DPL (Debian Project Leader) Lucas Nussbaum, en février-mars 2026, s’était soldée par un abandon du vote, la communauté ayant préféré continuer à traiter les contributions IA au cas par cas. Le projet Debian avait décidé de ne pas décider. Cette résolution relance donc le débat avec un texte plus structuré et davantage de propositions.
Quatre propositions, du radical au plus mesuré
La proposition A, portée par Matthias Geiger et Jesse Rhodes, est la plus radicale : l’interdiction de toute contribution directe rédigée avec l’aide de LLM : paquets sources, logiciels officiels (lintian, etc.), ressources web, documentation, traductions, communications officielles. Les projets amont utilisant l’IA, ainsi que les correctifs de sécurité amont, sont exclus du périmètre. Le texte propose même d’ajouter un point 6 au Contrat Social de Debian sur le sujet.
Plusieurs arguments sont donnés. D’abord, le statut juridique flou du copyright des sorties de LLM. Ensuite, des problèmes de qualité (paquets mal formés, fichiers watch non fonctionnels). En outre, un impact sur la dynamique communautaire : charge de relecture, non-apprentissage des nouveaux contributeurs, etc. Enfin, la question éthique, le scraping massif ayant perturbé l’infrastructure web de Debian et la question de l’empreinte environnementale étant prégnante.
La proposition B, portée par l’ancien DPL, Lucas Nussbaum, est plus mesurée. Elle autorise les contributions assistées par IA sous six conditions cumulatives :
compatibilité légale de l’outil utilisé
vérification des droits sur le contenu préexistant réutilisé
responsabilité totale du contributeur
divulgation de l’usage via un tag Git type Generated-By: ou Assisted-By:
discussion préalable pour les modifications massives ou automatisées
interdiction de transmettre des données sensibles (rapports de sécurité sous embargo, discussions privées) à des fournisseurs IA non fiables
La proposition C, portée par Ian Jackson, est un rejet de principe mais « pragmatique ». Elle demande à tous les contributeurs d’éviter les LLM et appelle plus largement la communauté du logiciel libre à rejeter cette technologie, tout en reconnaissant qu’une interdiction totale est impraticable puisque de nombreux projets amont y recourent. Il propose cependant des règles strictes : les messages destinés aux humains (rapports de bugs, listes de diffusion, Salsa, blogs Planet Debian) doivent être rédigés uniquement par des humains, tout usage de LLM doit être divulgué, les mainteneurs individuels peuvent totalement bannir l’IA sur leurs projets. Et la plus stricte d’entre elles : les violations sont traitées comme des manquements au Code de Conduite.
Quant à la proposition D, portée par Pierre-Elliott Bécue, elle ressemble beaucoup à la B dans l’esprit : une acceptation encadrée, portée sur les responsabilités. En clair, Debian n’endosse pas l’usage de l’IA générative mais reconnaît sa réalité et refuse une interdiction jugée « contre-productive et inapplicable ». Cette proposition place la responsabilité sur le contributeur (conformité DFSG, signature GPG personnelle, marquage de l’usage IA dans les commits et notes de version), avec une clause spécifique interdisant l’usage d’IA cloud pour des données sensibles ou non publiques.
Une décision importante
Plusieurs éléments intéressants entourant cette nouvelle résolution générale. D’abord, la proximité avec l’ancienne : à peine quelques mois, signalant le besoin pour les développeurs de trancher un sujet devenu central. L’IA générative est partout et les LLM sont utilisés dans une part croissante des projets. Précisons quand même que la précédente discussion en février-mars n’a pas atteint le statut officiel de GR. Il s’est écoulé environ un mois entre le brouillon alors préparé par Lucas Nussbaum et l’abandon du processus.
On ne sait pas combien de temps durera la résolution générale, mais la discussion et le vote seront importants. Debian n’est pas n’importe quelle distribution : en plus de son utilisation proprement dite, elle sert de socle à de nombreux autres systèmes, dont le plus connu est Ubuntu, la distribution Linux la plus utilisée aujourd’hui. Ce qui n’empêche pas d’autres organisations, comme Canonical, de procéder à des modifications assistées par IA.
Cette résolution cristallise de nombreux aspects entourant les LLM. Le fait que les questions éthiques et environnementales fassent partie de la réflexion est significatif, mais le sujet est complexe : comment trancher entre une interrogation croissante sur les gains potentiels et les conséquences négatives d’une utilisation intensive ? Si les membres du projet Debian regardent en direction de Linus Torvalds, une proposition B ou D pourrait l’emporter : une vision pragmatique et responsabilisée des contributions.
L’information peut étonner : Chromium n’est-il pas déjà présent sur les systèmes Linux et l’architecture Arm64 ? Si, mais Chrome ne l’était pas. En mars, Google avait promis que son navigateur serait porté vers cette architecture durant le deuxième trimestre. La société est en retard, mais le navigateur est effectivement disponible, même s’il faut « ruser » pour l’obtenir.
Des builds Arm64 ont été ajoutées récemment aux dépôts officiels, comme le relève OMGUbuntu. Depuis un appareil Arm64, la page de téléchargement renvoie vers un installeur AMD64, mais il suffit de modifier le lien en remplaçant amd64 par arm64 pour récupérer la version stable pour l’architecture souhaitée. On peut également récupérer le paquet DEB correspondant via Apt sur Ubuntu, la commande ajoutant au passage le dépôt Google pour assurer les mises à jour. Nos confrères n’ont pas testé d’autres systèmes ni la version RPM.
Source : OMGUbuntu
Quel intérêt alors d’installer Chrome si Chromium et d’autres – comme Vivaldi – existent déjà ? Parce qu’on peut vouloir Chrome pour la synchronisation du compte Google (extensions, marque-pages, mots de passe…).
Autre raison : le support DRM Widevine intégré nativement. Jusqu’à présent, faire fonctionner Widevine sur Arm Linux hors ChromeOS nécessitait d’extraire le binaire aarch64 d’une image ChromeOS via des scripts tiers. Une gageure. Le module Widevine reste de type « Software Secure », ce qui plafonne Netflix et les autres services à 720p/1080p au lieu de la 4K ou du HDR, faute de chaine TEE (Trusted Execution Environment) valide. « C’est agaçant, mais c’est la même situation sur Intel/AMD », indique OMGUbuntu.
Sur un Raspberry Pi 5 sous Ubuntu 26.04, le décodage vidéo matériel était inactif pendant les tests, ce qui limite les performances sur les flux haute définition, toujours selon nos confrères. BBC iPlayer en réglage maximal tournait sans accroc, contrairement au Firefox Snap Arm64 d’Ubuntu qui saccade davantage. YouTube en 4K montrait des saccades et frames perdues, probablement à cause du matériel plutôt que de Chrome, tandis que le 2K était parfaitement fluide.
L’information peut étonner : Chromium n’est-il pas déjà présent sur les systèmes Linux et l’architecture Arm64 ? Si, mais Chrome ne l’était pas. En mars, Google avait promis que son navigateur serait porté vers cette architecture durant le deuxième trimestre. La société est en retard, mais le navigateur est effectivement disponible, même s’il faut « ruser » pour l’obtenir.
Des builds Arm64 ont été ajoutées récemment aux dépôts officiels, comme le relève OMGUbuntu. Depuis un appareil Arm64, la page de téléchargement renvoie vers un installeur AMD64, mais il suffit de modifier le lien en remplaçant amd64 par arm64 pour récupérer la version stable pour l’architecture souhaitée. On peut également récupérer le paquet DEB correspondant via Apt sur Ubuntu, la commande ajoutant au passage le dépôt Google pour assurer les mises à jour. Nos confrères n’ont pas testé d’autres systèmes ni la version RPM.
Source : OMGUbuntu
Quel intérêt alors d’installer Chrome si Chromium et d’autres – comme Vivaldi – existent déjà ? Parce qu’on peut vouloir Chrome pour la synchronisation du compte Google (extensions, marque-pages, mots de passe…).
Autre raison : le support DRM Widevine intégré nativement. Jusqu’à présent, faire fonctionner Widevine sur Arm Linux hors ChromeOS nécessitait d’extraire le binaire aarch64 d’une image ChromeOS via des scripts tiers. Une gageure. Le module Widevine reste de type « Software Secure », ce qui plafonne Netflix et les autres services à 720p/1080p au lieu de la 4K ou du HDR, faute de chaine TEE (Trusted Execution Environment) valide. « C’est agaçant, mais c’est la même situation sur Intel/AMD », indique OMGUbuntu.
Sur un Raspberry Pi 5 sous Ubuntu 26.04, le décodage vidéo matériel était inactif pendant les tests, ce qui limite les performances sur les flux haute définition, toujours selon nos confrères. BBC iPlayer en réglage maximal tournait sans accroc, contrairement au Firefox Snap Arm64 d’Ubuntu qui saccade davantage. YouTube en 4K montrait des saccades et frames perdues, probablement à cause du matériel plutôt que de Chrome, tandis que le 2K était parfaitement fluide.
La mode c'est les passkeys, on est envahi de passkeys
Cette fois, c’est décidé : les SMS et la voix ne seront bientôt plus autorisés dans Entra comme facteur d’authentification. Microsoft évoque l’IA comme accélérateur de cette décision, l’entreprise renvoyant évidemment vers les clés d’accès (passkeys).
Microsoft a annoncé le retrait des SMS et de la voix comme méthodes de MFA (multi-factor authentification) dans l’annuaire d’identité Entra, avec bascule vers les clés d’accès par défaut et une échéance ferme au 1ᵉʳ février 2027.
L’entreprise justifie ce changement par l’explosion de l’IA générative, qui a modifié l’économie du phishing et de l’ingénierie sociale, en automatisant le vol d’identifiants et les opérations d’échanges de SIM (SIM swap) à grande échelle et en deux fois moins de temps.
Un programme au pas de course
Ce changement important ne sera pas d’une traite. Microsoft fournit un calendrier, où les étapes vont cependant s’enchainer rapidement :
1ᵉʳ septembre 2026 : invite automatique à enregistrer une clé d’accès lors du prochain défi MFA
18 septembre 2026 : publication de la liste des fournisseurs télécom compatibles pour les organisations qui doivent conserver les SMS et/ou la voix pour des raisons réglementaires
30 octobre 2026 : obligation de configurer un fournisseur télécom supporté via le Microsoft Security Store pour les organisations restant sur MFA téléphonique
1ᵉʳ février 2027 : retrait définitif des SMS/voix fournis par Microsoft, sans dérogation possible
Plusieurs points importants à préciser tout de même. Pour éviter que le processus automatique ne perturbe trop les organisations à compter du 1ᵉʳ septembre, une API sera fournie le 1ᵉʳ aout. Elle permettra aux équipes d’administrations de se retirer (opt-out) du mécanisme pour gérer elles-mêmes la transition.
Il reste 69% de l'article à découvrir. Vous devez être abonné•e pour lire la suite de cet article. Déjà abonné•e ? Générez une clé RSS dans votre profil.
La mini-saga de l’été autour des écrans LG vient de finir sa première saison. Le constructeur a supprimé sa publicité pour McAfee, mais le problème sous-jacent reste entier et LG se défend d’avoir mal agi.
LG est sous un feu nourri de critiques pour le comportement observé par de nombreuses personnes autour d’une partie de ses écrans, même dans le haut de gamme et jusqu’à des écrans proposés depuis plusieurs années. Depuis environ trois semaines, des propriétaires de moniteurs LG (essentiellement la gamme UltraGear) constatent qu’après un simple branchement de l’écran, le pilote est récupéré automatiquement par Windows, en même temps qu’une application dont le seul objectif semble être de la publicité pour McAfee.
Comme nous l’avions expliqué, LG exploite un mécanisme présent dans Windows depuis longtemps. Cependant, la documentation de Microsoft recommandait de faire attention avec les comportements déclenchés de cette manière s’ils ne répondaient pas à un besoin concret de l’utilisateur. Une application peut être utile pour fournir des fonctions liées, mais elle peut vite provoquer de la frustration quand elle est utilisée à d’autres fins. Dont acte.
Microsoft intervient, clap de fin (pour l’instant)
On pouvait se demander si Microsoft était au courant de la situation. Sur X le 18 juillet, Tim Sweeney, fondateur et CEO d’Epic Games, a directement interpelé Pavan Davuluri, vice-président de Microsoft à la tête de la division Windows et Appareils. Le lendemain, le responsable remerciait « Tim » et indiquait que l’entreprise se penchait sur la situation.
Le 22 juillet, Pavan Davuluri revient avec un nouveau message : « Merci encore d’avoir porté cela à notre attention. Nous avons pris contact avec l’équipe chez LG et, comme étape immédiate suivante, ils ont accepté de désactiver la fenêtre contextuelle McAfee dans leur application. Nous apprécions la collaboration de LG avec nous vers un objectif commun d’une meilleure expérience pour nos clients mutuels ». Un langage très policé au vu du contexte, mais au moins la situation progresse.
Pour LG, le choix de l’utilisateur a été respecté
« LG Electronics réaffirme que McAfee n’est pas installé automatiquement et n’est jamais installé sans le consentement explicite de l’utilisateur. Le programme d’installation de l’application LG Monitor est distribué via le processus officiel de distribution Windows de Microsoft, qui incluait McAfee en option. McAfee ne sera installé que si l’utilisateur choisit activement de poursuivre l’installation et donne son consentement. McAfee n’est en aucun cas installé automatiquement ou sans l’autorisation de l’utilisateur », nous a quand même indiqué le constructeur.
Il ne s’agit cependant que d’une partie du problème. Les personnes concernées avaient bien vu le choix, mais la frustration venait de la question qui leur était posée encore et encore. Gamer Nexus s’était largement penché sur ce comportement, indiquant que la notification était revenue 31 fois sur 32 redémarrages. On reste ainsi sur la volonté de profiter d’une fonction existante pour pousser automatiquement de la publicité.
En outre, la question du processus utilisé reste entière. Dans notre article précédent, nous nous interrogions sur le bien-fondé de cette fonction, qui permet une installation sans intervention de l’utilisateur. L’immense majorité des constructeurs en profite, mais n’a jamais commis l’erreur – grossière – de le faire sans demander la permission. MSI, Gigabyte, Logitech et d’autres font ainsi apparaître une fenêtre demandant si l’application peut s’installer. En cas de refus, la question ne revient pas, à moins d’une mise à jour majeure de Windows (la 25H2 de Windows 11 par exemple). D’autres, comme Razer, ont davantage tiré sur la corde, en installant notamment son application Synapse au branchement d’une webcam de la marque.
La mini-saga de l’été autour des écrans LG vient de finir sa première saison. Le constructeur a supprimé sa publicité pour McAfee, mais le problème sous-jacent reste entier et LG se défend d’avoir mal agi.
LG est sous un feu nourri de critiques pour le comportement observé par de nombreuses personnes autour d’une partie de ses écrans, même dans le haut de gamme et jusqu’à des écrans proposés depuis plusieurs années. Depuis environ trois semaines, des propriétaires de moniteurs LG (essentiellement la gamme UltraGear) constatent qu’après un simple branchement de l’écran, le pilote est récupéré automatiquement par Windows, en même temps qu’une application dont le seul objectif semble être de la publicité pour McAfee.
Comme nous l’avions expliqué, LG exploite un mécanisme présent dans Windows depuis longtemps. Cependant, la documentation de Microsoft recommandait de faire attention avec les comportements déclenchés de cette manière s’ils ne répondaient pas à un besoin concret de l’utilisateur. Une application peut être utile pour fournir des fonctions liées, mais elle peut vite provoquer de la frustration quand elle est utilisée à d’autres fins. Dont acte.
Microsoft intervient, clap de fin (pour l’instant)
On pouvait se demander si Microsoft était au courant de la situation. Sur X le 18 juillet, Tim Sweeney, fondateur et CEO d’Epic Games, a directement interpelé Pavan Davuluri, vice-président de Microsoft à la tête de la division Windows et Appareils. Le lendemain, le responsable remerciait « Tim » et indiquait que l’entreprise se penchait sur la situation.
Le 22 juillet, Pavan Davuluri revient avec un nouveau message : « Merci encore d’avoir porté cela à notre attention. Nous avons pris contact avec l’équipe chez LG et, comme étape immédiate suivante, ils ont accepté de désactiver la fenêtre contextuelle McAfee dans leur application. Nous apprécions la collaboration de LG avec nous vers un objectif commun d’une meilleure expérience pour nos clients mutuels ». Un langage très policé au vu du contexte, mais au moins la situation progresse.
Pour LG, le choix de l’utilisateur a été respecté
« LG Electronics réaffirme que McAfee n’est pas installé automatiquement et n’est jamais installé sans le consentement explicite de l’utilisateur. Le programme d’installation de l’application LG Monitor est distribué via le processus officiel de distribution Windows de Microsoft, qui incluait McAfee en option. McAfee ne sera installé que si l’utilisateur choisit activement de poursuivre l’installation et donne son consentement. McAfee n’est en aucun cas installé automatiquement ou sans l’autorisation de l’utilisateur », nous a quand même indiqué le constructeur.
Il ne s’agit cependant que d’une partie du problème. Les personnes concernées avaient bien vu le choix, mais la frustration venait de la question qui leur était posée encore et encore. Gamer Nexus s’était largement penché sur ce comportement, indiquant que la notification était revenue 31 fois sur 32 redémarrages. On reste ainsi sur la volonté de profiter d’une fonction existante pour pousser automatiquement de la publicité.
En outre, la question du processus utilisé reste entière. Dans notre article précédent, nous nous interrogions sur le bien-fondé de cette fonction, qui permet une installation sans intervention de l’utilisateur. L’immense majorité des constructeurs en profite, mais n’a jamais commis l’erreur – grossière – de le faire sans demander la permission. MSI, Gigabyte, Logitech et d’autres font ainsi apparaître une fenêtre demandant si l’application peut s’installer. En cas de refus, la question ne revient pas, à moins d’une mise à jour majeure de Windows (la 25H2 de Windows 11 par exemple). D’autres, comme Razer, ont davantage tiré sur la corde, en installant notamment son application Synapse au branchement d’une webcam de la marque.
Si Tails 7.9 n’avait pas vraiment marqué par ses nouveautés (essentiellement quelques mises à jour logicielles), la version 7.10 comporte quelques changements plus visibles.
La modification la plus importante est la bascule du processus d’arrêt par défaut vers celui de GNOME. L’équipe justifie ce choix par une procédure certes plus lente, mais qui réduit les risques de pertes de données. Elle signale notamment aux utilisateurs les applications ouvertes avec des documents non sauvegardés.
Source : Tails
Comme le montre la capture, le système s’éteindra dans tous les cas au bout de 60 secondes, que les documents aient été sauvegardés ou non. En outre, « l’arrêt d’urgence » – qui consiste à débrancher le média utilisé pour charger Tails – est toujours disponible, même s’il présente un risque accru de perte de données.
Pour le lecteur vidéo, l’équipe a fait le choix inverse : le lecteur vidéo de GNOME est abandonné au profit de Celluloid, présenté comme « plus moderne et plus fiable ». Au sein de Tails, Celluloid ne peut pas accéder au réseau. L’équipe conseille d’utiliser Tor Browser pour les vidéos en ligne (certains MP4, AVI…), tandis que les adresses vers des flux en streaming peuvent être ouvertes dans VLC. Celluloid pourrait ne pas fonctionner sur certains ordinateurs de 2011 ou plus anciens, auquel cas VLC est de nouveau conseillé.
Pour le reste, Tails 7.10 propose quelques évolutions logicielles et de firmwares, ainsi que la version 15.0.19 de Tor Browser. Pour les personnes ayant une clé USB avec le système, Tails 7.0 et les versions ultérieures intègrent directement un processus de mise à jour.
Si Tails 7.9 n’avait pas vraiment marqué par ses nouveautés (essentiellement quelques mises à jour logicielles), la version 7.10 comporte quelques changements plus visibles.
La modification la plus importante est la bascule du processus d’arrêt par défaut vers celui de GNOME. L’équipe justifie ce choix par une procédure certes plus lente, mais qui réduit les risques de pertes de données. Elle signale notamment aux utilisateurs les applications ouvertes avec des documents non sauvegardés.
Source : Tails
Comme le montre la capture, le système s’éteindra dans tous les cas au bout de 60 secondes, que les documents aient été sauvegardés ou non. En outre, « l’arrêt d’urgence » – qui consiste à débrancher le média utilisé pour charger Tails – est toujours disponible, même s’il présente un risque accru de perte de données.
Pour le lecteur vidéo, l’équipe a fait le choix inverse : le lecteur vidéo de GNOME est abandonné au profit de Celluloid, présenté comme « plus moderne et plus fiable ». Au sein de Tails, Celluloid ne peut pas accéder au réseau. L’équipe conseille d’utiliser Tor Browser pour les vidéos en ligne (certains MP4, AVI…), tandis que les adresses vers des flux en streaming peuvent être ouvertes dans VLC. Celluloid pourrait ne pas fonctionner sur certains ordinateurs de 2011 ou plus anciens, auquel cas VLC est de nouveau conseillé.
Pour le reste, Tails 7.10 propose quelques évolutions logicielles et de firmwares, ainsi que la version 15.0.19 de Tor Browser. Pour les personnes ayant une clé USB avec le système, Tails 7.0 et les versions ultérieures intègrent directement un processus de mise à jour.
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.).
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.
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.).
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.
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.
Source : OVHcloud
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 ».
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.
Source : OVHcloud
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 ».
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.
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.
Connexion
