Un seul code vous manque et tout est perdu

Le 26 juillet, l’équipe de GrapheneOS s’est lancée tout à coup dans un exposé de nombreuses mesures de sécurité, avec une insistance particulière pour la gestion des mots de passe. Ce calendrier ne doit rien au hasard : pour la première fois aux États-Unis, le ministère de la Justice poursuit un citoyen américain pour destruction présumée de données à l’aide d’un mot de passe « contraint ».

Depuis deux jours, le compte X de GrapheneOS répond à de nombreuses questions sur la gestion de ses mots de passe. L’équipe en a fait une synthèse dans son forum pour résumer toutes les informations.

L’équipe explique que le système mobile est basé sur Android 17 et « sur le matériel le plus sécurisé disponible pour Android », la liste se limitant aujourd’hui aux seuls Pixel de Google. Elle rappelle cependant que la situation va évoluer en 2027, grâce à un partenariat avec Motorola Mobility et « aux progrès réalisés par Qualcomm ». Un signal assez fort pour l’industrie, qui pourrait se rapprocher de Graphene pour lancer des smartphones très orientés vers la sécurité. On parle bien de nouveaux modèles, car aucun appareil Motorola actuel ne dispose des sécurités nécessaires.

• Motorola s’associe à GrapheneOS pour renforcer la sécurité de ses (futurs) smartphones

Les informations se concentrent tout particulièrement sur la protection des mots de passe et autres secrets, ainsi que sur les défenses du système mobile contre l’extraction de données. Le chiffrement du disque constitue ainsi la première ligne de défense : même les attaquants les plus sophistiqués ne peuvent le casser directement, et doivent soit exploiter l’OS en état « After First Unlock » (après premier déverrouillage), soit forcer le PIN ou mot de passe par force brute.

L’équipe indique également que GrapheneOS supporte uniquement les appareils ayant un secure element avec des limitations strictes sur les tentatives de mots de passe et codes PIN : 4 heures après 10 tentatives échouées, 41 jours après 15, avec seulement 20 tentatives autorisées au total. Le secure element est pour rappel une puce dédiée, physiquement et logiciellement isolée, conçue pour stocker les secrets et résister à leur extraction. Dans le contexte de GrapheneOS, il a en outre un rôle précis : il détient les compteurs de tentatives de déverrouillage et applique la limitation de débit, expliquant les délais de plus en plus longs entre les tentatives. Stocker les compteurs dans la puce empêche de « tricher » en les réinitialisant.

Parmi les autres points abordés, on peut citer la limite de caractères des mots portée de 16 à 128, la possibilité d’utiliser un facteur biométrique pour que le système reste utilisable au quotidien (5 tentatives biométriques seulement, qui comptent dans le quota général), des allocateurs de mémoire durcis, le hardware memory tagging (MTE) pour renforcer la résistance aux exploitations de failles inconnues, le blocage par défaut des nouvelles connexions USB quand l’appareil est verrouillé, ou encore un minuteur de redémarrage automatique, ramenant l’appareil en état « Before First Unlock » (avant premier déverrouillage) au bout de 18 heures (par défaut) sans déverrouillage de l’appareil. Ce dernier comportement a d’ailleurs été repris par Apple et Google dans leurs systèmes.

• Le redémarrage automatique des iPhone inactifs est bien une fonctionnalité d’iOS 18

Dans le billet, on trouve également un paragraphe consacré au PIN de contrainte. Présentée comme un outil relativement mineur et optionnel, il efface l’appareil quand il est saisi dans n’importe quelle invite d’authentification (déverrouillage, changement de réglage sensible, etc.). Il fonctionne sur tous les profils, y compris les utilisateurs secondaires et Private Spaces. L’équipe de GrapheneOS insiste : les données ne dépendent pas de cette fonctionnalité pour être protégées. Elle est considérée comme un outil parmi d’autres, et son usage réel doit être mûrement réfléchi compte tenu des conséquences physiques ou juridiques possibles.

L’affaire Samuel Tunick

La mention des conséquences juridiques n’est pas due au hasard. Si l’équipe de Graphene communique tant autour des protections de son système en ce moment, c’est à cause d’un évènement juridique majeur aux États-Unis lié à la tech.

Pour la première fois (a priori), des procureurs fédéraux poursuivent en effet un citoyen américain pour destruction présumée de données à l’aide d’un mot de passe « contraint » intégré au logiciel d’un téléphone. C’est le lien avec la communication abondante : le logiciel en question n’est autre que GrapheneOS.

Samuel Tunick a été initialement arrêté sans mandat le 25 janvier 2025 à l’aéroport de Hartsfield-Jackson (Atlanta) par les douanes américaines, sur la base de l’exception de fouille frontalière au Quatrième amendement. Alors que les agents fédéraux tentaient d’accéder à son téléphone lors de l’inspection, Tunick aurait saisi un mot de passe de contrainte GrapheneOS qui a immédiatement effacé les données stockées sur l’appareil.

Tunick est donc poursuivi en vertu de la loi américaine pour avoir fourni aux agents frontaliers un code d’accès ayant causé l’effacement du contenu numérique de son téléphone, ce que les procureurs qualifient de destruction intentionnelle de biens pour empêcher leur saisie.

Un enjeu plus grand que le cas individuel

La communication de GrapheneOS est probablement défensive, pour documenter publiquement la robustesse cryptographique de son modèle de menace face à l’attention médiatique soudaine portée à la fonction « mot de passe de contrainte ».

Sur le plan juridique, l’enjeu dépasse le cas individuel : la question posée aux tribunaux est de savoir si l’activation d’une fonctionnalité de sécurité native – conçue précisément pour protéger des données personnelles en cas de contrainte – peut être qualifiée pénalement de destruction de preuves, y compris lorsque la fouille initiale s’est déroulée sans mandat.

Sans surprise, les avocats de Samuel Tunick contestent cette version des faits. Ils affirment que la détention et la saisie étaient illégales, et accusent le gouvernement américain d’exiger l’accès au téléphone sous prétexte d’une recherche d’images pédopornographiques, sans fournir aucun élément pour étayer ces soupçons.

Pour les avocats, cette arrestation et cette affaire sont politiques. Le gouvernement s’en serait pris à Samuel Tunick non pas pour d’éventuels matériels pédopornographiques, mais pour son association avec un mouvement appelé « Defend the Atlanta Forest ». Ce dernier s’oppose à la création d’un énorme campus de formation pour les forces de l’ordre à Atlanta, surnommé « Cop City », critiqué pour son impact environnemental (plus de 34 hectares déforestés) et son coût de 67 millions de dollars.

Les avocats demandent l’annulation de toute la procédure, au motif qu’elle viole les Quatrième, Cinquième et Sixième amendements de la Constitution américaine. Des violations liées à la manière dont l’interrogatoire a été mené, au refus d’un avocat, à l’absence alléguée d’avertissements Miranda (le fameux « Vous avez le droit de garder le silence »), ou encore à la fouille et la saisie sans mandat.

« Je n’ai jamais vu cela auparavant, même si j’ai discuté du scénario potentiel avec des activistes et des journalistes au fil des années. Je pense que cette affaire rappelle que les autorités peuvent prétendre que vous avez sciemment détruit des données, donc il vaut mieux ne pas avoir ces données sur vous lorsque vous franchissez certaines frontières », a réagi Runa Sandvik, une experte en sécurité informatique, auprès de TechCrunch.

Un seul code vous manque et tout est perdu

Le 26 juillet, l’équipe de GrapheneOS s’est lancée tout à coup dans un exposé de nombreuses mesures de sécurité, avec une insistance particulière pour la gestion des mots de passe. Ce calendrier ne doit rien au hasard : pour la première fois aux États-Unis, le ministère de la Justice poursuit un citoyen américain pour destruction présumée de données à l’aide d’un mot de passe « contraint ».

Depuis deux jours, le compte X de GrapheneOS répond à de nombreuses questions sur la gestion de ses mots de passe. L’équipe en a fait une synthèse dans son forum pour résumer toutes les informations.

L’équipe explique que le système mobile est basé sur Android 17 et « sur le matériel le plus sécurisé disponible pour Android », la liste se limitant aujourd’hui aux seuls Pixel de Google. Elle rappelle cependant que la situation va évoluer en 2027, grâce à un partenariat avec Motorola Mobility et « aux progrès réalisés par Qualcomm ». Un signal assez fort pour l’industrie, qui pourrait se rapprocher de Graphene pour lancer des smartphones très orientés vers la sécurité. On parle bien de nouveaux modèles, car aucun appareil Motorola actuel ne dispose des sécurités nécessaires.

• Motorola s’associe à GrapheneOS pour renforcer la sécurité de ses (futurs) smartphones

Les informations se concentrent tout particulièrement sur la protection des mots de passe et autres secrets, ainsi que sur les défenses du système mobile contre l’extraction de données. Le chiffrement du disque constitue ainsi la première ligne de défense : même les attaquants les plus sophistiqués ne peuvent le casser directement, et doivent soit exploiter l’OS en état « After First Unlock » (après premier déverrouillage), soit forcer le PIN ou mot de passe par force brute.

L’équipe indique également que GrapheneOS supporte uniquement les appareils ayant un secure element avec des limitations strictes sur les tentatives de mots de passe et codes PIN : 4 heures après 10 tentatives échouées, 41 jours après 15, avec seulement 20 tentatives autorisées au total. Le secure element est pour rappel une puce dédiée, physiquement et logiciellement isolée, conçue pour stocker les secrets et résister à leur extraction. Dans le contexte de GrapheneOS, il a en outre un rôle précis : il détient les compteurs de tentatives de déverrouillage et applique la limitation de débit, expliquant les délais de plus en plus longs entre les tentatives. Stocker les compteurs dans la puce empêche de « tricher » en les réinitialisant.

Parmi les autres points abordés, on peut citer la limite de caractères des mots portée de 16 à 128, la possibilité d’utiliser un facteur biométrique pour que le système reste utilisable au quotidien (5 tentatives biométriques seulement, qui comptent dans le quota général), des allocateurs de mémoire durcis, le hardware memory tagging (MTE) pour renforcer la résistance aux exploitations de failles inconnues, le blocage par défaut des nouvelles connexions USB quand l’appareil est verrouillé, ou encore un minuteur de redémarrage automatique, ramenant l’appareil en état « Before First Unlock » (avant premier déverrouillage) au bout de 18 heures (par défaut) sans déverrouillage de l’appareil. Ce dernier comportement a d’ailleurs été repris par Apple et Google dans leurs systèmes.

• Le redémarrage automatique des iPhone inactifs est bien une fonctionnalité d’iOS 18

Dans le billet, on trouve également un paragraphe consacré au PIN de contrainte. Présentée comme un outil relativement mineur et optionnel, il efface l’appareil quand il est saisi dans n’importe quelle invite d’authentification (déverrouillage, changement de réglage sensible, etc.). Il fonctionne sur tous les profils, y compris les utilisateurs secondaires et Private Spaces. L’équipe de GrapheneOS insiste : les données ne dépendent pas de cette fonctionnalité pour être protégées. Elle est considérée comme un outil parmi d’autres, et son usage réel doit être mûrement réfléchi compte tenu des conséquences physiques ou juridiques possibles.

L’affaire Samuel Tunick

La mention des conséquences juridiques n’est pas due au hasard. Si l’équipe de Graphene communique tant autour des protections de son système en ce moment, c’est à cause d’un évènement juridique majeur aux États-Unis lié à la tech.

Pour la première fois (a priori), des procureurs fédéraux poursuivent en effet un citoyen américain pour destruction présumée de données à l’aide d’un mot de passe « contraint » intégré au logiciel d’un téléphone. C’est le lien avec la communication abondante : le logiciel en question n’est autre que GrapheneOS.

Samuel Tunick a été initialement arrêté sans mandat le 25 janvier 2025 à l’aéroport de Hartsfield-Jackson (Atlanta) par les douanes américaines, sur la base de l’exception de fouille frontalière au Quatrième amendement. Alors que les agents fédéraux tentaient d’accéder à son téléphone lors de l’inspection, Tunick aurait saisi un mot de passe de contrainte GrapheneOS qui a immédiatement effacé les données stockées sur l’appareil.

Tunick est donc poursuivi en vertu de la loi américaine pour avoir fourni aux agents frontaliers un code d’accès ayant causé l’effacement du contenu numérique de son téléphone, ce que les procureurs qualifient de destruction intentionnelle de biens pour empêcher leur saisie.

Un enjeu plus grand que le cas individuel

La communication de GrapheneOS est probablement défensive, pour documenter publiquement la robustesse cryptographique de son modèle de menace face à l’attention médiatique soudaine portée à la fonction « mot de passe de contrainte ».

Sur le plan juridique, l’enjeu dépasse le cas individuel : la question posée aux tribunaux est de savoir si l’activation d’une fonctionnalité de sécurité native – conçue précisément pour protéger des données personnelles en cas de contrainte – peut être qualifiée pénalement de destruction de preuves, y compris lorsque la fouille initiale s’est déroulée sans mandat.

Sans surprise, les avocats de Samuel Tunick contestent cette version des faits. Ils affirment que la détention et la saisie étaient illégales, et accusent le gouvernement américain d’exiger l’accès au téléphone sous prétexte d’une recherche d’images pédopornographiques, sans fournir aucun élément pour étayer ces soupçons.

Pour les avocats, cette arrestation et cette affaire sont politiques. Le gouvernement s’en serait pris à Samuel Tunick non pas pour d’éventuels matériels pédopornographiques, mais pour son association avec un mouvement appelé « Defend the Atlanta Forest ». Ce dernier s’oppose à la création d’un énorme campus de formation pour les forces de l’ordre à Atlanta, surnommé « Cop City », critiqué pour son impact environnemental (plus de 34 hectares déforestés) et son coût de 67 millions de dollars.

Les avocats demandent l’annulation de toute la procédure, au motif qu’elle viole les Quatrième, Cinquième et Sixième amendements de la Constitution américaine. Des violations liées à la manière dont l’interrogatoire a été mené, au refus d’un avocat, à l’absence alléguée d’avertissements Miranda (le fameux « Vous avez le droit de garder le silence »), ou encore à la fouille et la saisie sans mandat.

« Je n’ai jamais vu cela auparavant, même si j’ai discuté du scénario potentiel avec des activistes et des journalistes au fil des années. Je pense que cette affaire rappelle que les autorités peuvent prétendre que vous avez sciemment détruit des données, donc il vaut mieux ne pas avoir ces données sur vous lorsque vous franchissez certaines frontières », a réagi Runa Sandvik, une experte en sécurité informatique, auprès de TechCrunch.

La nouvelle interface de Firefox est désormais activée par défaut dans le canal Nightly du navigateur. Rappelons que cette préversion peut être installée aux côtés de la version stable sans mélanger les données, permettant de tester les nouveautés facilement.

Cette nouvelle interface, baptisée Nova, avait été présentée en mai pour la première fois. On pouvait alors l’essayer en activant un flag de test dans le about:config. On reste globalement dans ce qui avait été montré, avec des finitions supplémentaires.

Dans son nouveau billet, Mozilla évoque « un aspect et une sensation plus cohérents sur les onglets, menus, panneaux et autres surfaces du navigateur ». On note bien sûr les formes d’onglets « plus douces », des couleurs « plus chaudes », de nouvelles icônes et autres. Mozilla dit aussi avoir tenu compte des retours et réintégré le mode compact, qui va effectivement vite sembler nécessaire à une partie des utilisateurs.

Par défaut, l’interface prend en effet ses aises et propose une zone « barre de titre + barre d’onglets » plus épaisse que la concurrence. Le mode compact permet de réduire l’ensemble à ce que l’on a l’habitude de voir. Mozilla insiste sur l’aspect non terminé de son projet, expliquant d’ailleurs toujours sa présence dans le canal Nightly, le plus « brut » des canaux de préversion.

L’éditeur demande aux personnes qui testeront la nouvelle interface de porter leur regard sur tout ce qui touche aux icônes, espacements et alignements, aux thèmes et à la personnalisation, aux différentes tailles de fenêtres, à la navigation par le clavier ou encore à tout ce qui touche à l’accessibilité, notamment aux lecteurs d’écrans.

On espère de notre côté que l’aspect personnalisation sera développé. La gestion des thèmes n’est pas si simple actuellement, avec une fâcheuse tendance à rebasculer dans les variantes sombres si l’on ne fait pas attention. Si vous en avez assez de toute cette rondeur (à l’instar de votre serviteur) dans les onglets, boutons et autres, il n’existe pour l’instant aucun moyen intégré de modifier cet aspect. Mozilla devrait s’inspirer de Vivaldi, qui permet de modifier n’importe quel élément de l’interface.

La nouvelle interface de Firefox est désormais activée par défaut dans le canal Nightly du navigateur. Rappelons que cette préversion peut être installée aux côtés de la version stable sans mélanger les données, permettant de tester les nouveautés facilement.

Cette nouvelle interface, baptisée Nova, avait été présentée en mai pour la première fois. On pouvait alors l’essayer en activant un flag de test dans le about:config. On reste globalement dans ce qui avait été montré, avec des finitions supplémentaires.

Dans son nouveau billet, Mozilla évoque « un aspect et une sensation plus cohérents sur les onglets, menus, panneaux et autres surfaces du navigateur ». On note bien sûr les formes d’onglets « plus douces », des couleurs « plus chaudes », de nouvelles icônes et autres. Mozilla dit aussi avoir tenu compte des retours et réintégré le mode compact, qui va effectivement vite sembler nécessaire à une partie des utilisateurs.

Par défaut, l’interface prend en effet ses aises et propose une zone « barre de titre + barre d’onglets » plus épaisse que la concurrence. Le mode compact permet de réduire l’ensemble à ce que l’on a l’habitude de voir. Mozilla insiste sur l’aspect non terminé de son projet, expliquant d’ailleurs toujours sa présence dans le canal Nightly, le plus « brut » des canaux de préversion.

L’éditeur demande aux personnes qui testeront la nouvelle interface de porter leur regard sur tout ce qui touche aux icônes, espacements et alignements, aux thèmes et à la personnalisation, aux différentes tailles de fenêtres, à la navigation par le clavier ou encore à tout ce qui touche à l’accessibilité, notamment aux lecteurs d’écrans.

On espère de notre côté que l’aspect personnalisation sera développé. La gestion des thèmes n’est pas si simple actuellement, avec une fâcheuse tendance à rebasculer dans les variantes sombres si l’on ne fait pas attention. Si vous en avez assez de toute cette rondeur (à l’instar de votre serviteur) dans les onglets, boutons et autres, il n’existe pour l’instant aucun moyen intégré de modifier cet aspect. Mozilla devrait s’inspirer de Vivaldi, qui permet de modifier n’importe quel élément de l’interface.

Un parapluie, mais pas de baskets

Microsoft AI a présenté le 27 juillet 2026 son premier modèle dédié à la cybersécurité. Intégré dans son architecture, l’entreprise annonce battre tous les modèles actuels dans ce domaine, y compris Mythos d’Anthropic, mais attention à ce qui est réellement comparé.

Hier soir, Microsoft a annoncé officiellement MAI-Cyber-1-Flash. Il s’agit du tout premier LLM de l’éditeur consacré à la cybersécurité. Et pour un premier modèle, Microsoft a mis les petits plats dans les grands.

MAI-Cyber-1-Flash est un modèle compact, spécialisé dans le code et dérivé de la lignée MAI-Thinking-1, propre à Microsoft. Il est intégré à MDASH, le harnais multi-agents de détection et de remédiation de vulnérabilités déjà présenté par Microsoft en mai dernier. Plus récemment, l’entreprise est revenue sur le rôle prépondérant que joue désormais MDASH dans la sécurité de ses produits, expliquant l’envolée du nombre de failles corrigées dans les derniers bulletins mensuels : près de 200 en juin et plus de 570 en juillet.

Un modèle, un harnais…

Microsoft n’hésite pas à déclarer que son modèle, profondément intégré à MDASH, a été « perfectionné par les meilleurs experts en cybersécurité du secteur et renforcé dans le plus grand domaine de sécurité au monde ». Ce qui lui permet, toujours selon Microsoft, de battre tout le monde dans le domaine de la détection de failles, y compris Mythos, GPT 5.6 Sol, GPT 5.5 Cyber et Gemini 3.5 Flash Cyber. Avec 95,95 % au test CyberGym, Microsoft dépasse d’au moins 10 points la concurrence.

Mais attention, Microsoft ne compare pas directement son modèle MAI-Cyber-1-Flash aux autres : l’entreprise compare MDASH. Autrement dit, tout le harnais avec le nouveau modèle et GPT 5.4, utilisé en renfort.

Comme expliqué par l’éditeur en effet, MAI-Cyber-1-Flash est un modèle compact, conçu pour « gérer efficacement jusqu’à 90 % de toutes les tâches ». Dans cette configuration, MDASH ne basculerait vers les modèles plus gros et plus couteux (ici GPT 5.4) que dans 10 % des cas en moyenne, « pour les tâches exceptionnellement difficiles qui en ont réellement besoin ».

C’est bien cette architecture complète qui atteint près de 96 % sur CyberGym, battant Mythos de 12 points, insiste Microsoft. Rappelons que ces chiffres sont auto-rapportés et effectués dans un environnement contrôlé par Microsoft. Ils n’ont pas été vérifiés par un tiers indépendant.

Pour l’éditeur, c’est aussi une question d’économies substantielles. La meilleure offre MDASH combinait jusqu’à présent GPT 5.4 + 5.4 mini + codex 5.3. La nouvelle version intégrant MAI-Cyber-1-Flash coûterait moitié moins cher à faire tourner.

… et une plateforme

Mi-juillet, nous avions relayé un bruit de couloir : Microsoft préparait un projet nommé Perception pour venir concurrencer Anthropic et son projet Glasswing, seule manière de pouvoir utiliser Mythos.

Perception a bien été confirmé hier soir lui aussi. Il est présenté comme le système agentique qui vient chapeauter MAI-Cyber-1-Flash et MDASH. Le billet de blog dédié le présente comme une refonte de l’architecture de sécurité pour l’ère de l’IA : une nouvelle pile de sécurité doit percevoir en continu le risque sur l’ensemble du parc numérique, raisonner sur de vastes quantités de contexte et agir à vitesse machine, tout en apprenant et en s’adaptant à mesure que les environnements évoluent.

Le système coordonne trois familles d’agents spécialisés qui se transmettent le travail sans rupture de charge :

• Les agents rouges repèrent les chemins de compromission potentiels avant qu’un attaquant ne puisse les exploiter
• Les agents bleus enquêtent, évaluent le contexte et déterminent quels signaux représentent un risque réel
• Les agents verts appliquent les correctifs et durcissent l’environnement (renforcent sa sécurité)

Ces agents ne repartent pas de zéro à chaque tâche. Ils s’appuient sur un contexte de sécurité partagé : une représentation mise à jour en continu des actifs, identités, relations et risques de l’organisation. Tous les agents puisent dans ce contexte, réduisant les coûts en tokens et la latence tout en améliorant la cohérence du raisonnement, selon Microsoft.

Un programme complet, mais très jeune

Un serveur MCP est également fourni pour exécuter les actions en ligne de commande. Les agents verts peuvent aussi ouvrir directement des pull requests sur GitHub et construire des correctifs potentiels pour les vulnérabilités. Perception propose donc un système de sécurité en apprentissage continu combinant capteurs, contexte partagé, modèles multiples, agents spécialisés et mécanismes d’action capables de modifier les protections à travers l’environnement.

Le programme se présente ainsi comme une couche d’orchestration, au-dessus de MAI-Cyber-1-Flash et MDASH, avec un déploiement encore très récent et une autonomie d’action volontairement limitée à ce stade. Microsoft insiste sur le maintien d’un humain dans la boucle décisionnelle, ce qui suggère que l’entreprise elle-même reste prudente sur le niveau de confiance à accorder aux agents verts capables de modifier des systèmes de production.

Perception n’est d’ailleurs pas disponible. Le premier accès se fera sous forme de préversion le 3 août et uniquement pour des clients MDASH triés sur le volet. Même une fois lancé en version finale, il est très probable que Perception ne soit accessible qu’au travers d’un accès vérifié, à la manière de Glasswing chez Anthropic ou de Daybreak chez OpenAI.

Un parapluie, mais pas de baskets

Microsoft AI a présenté le 27 juillet 2026 son premier modèle dédié à la cybersécurité. Intégré dans son architecture, l’entreprise annonce battre tous les modèles actuels dans ce domaine, y compris Mythos d’Anthropic, mais attention à ce qui est réellement comparé.

Hier soir, Microsoft a annoncé officiellement MAI-Cyber-1-Flash. Il s’agit du tout premier LLM de l’éditeur consacré à la cybersécurité. Et pour un premier modèle, Microsoft a mis les petits plats dans les grands.

MAI-Cyber-1-Flash est un modèle compact, spécialisé dans le code et dérivé de la lignée MAI-Thinking-1, propre à Microsoft. Il est intégré à MDASH, le harnais multi-agents de détection et de remédiation de vulnérabilités déjà présenté par Microsoft en mai dernier. Plus récemment, l’entreprise est revenue sur le rôle prépondérant que joue désormais MDASH dans la sécurité de ses produits, expliquant l’envolée du nombre de failles corrigées dans les derniers bulletins mensuels : près de 200 en juin et plus de 570 en juillet.

Un modèle, un harnais…

Microsoft n’hésite pas à déclarer que son modèle, profondément intégré à MDASH, a été « perfectionné par les meilleurs experts en cybersécurité du secteur et renforcé dans le plus grand domaine de sécurité au monde ». Ce qui lui permet, toujours selon Microsoft, de battre tout le monde dans le domaine de la détection de failles, y compris Mythos, GPT 5.6 Sol, GPT 5.5 Cyber et Gemini 3.5 Flash Cyber. Avec 95,95 % au test CyberGym, Microsoft dépasse d’au moins 10 points la concurrence.

Mais attention, Microsoft ne compare pas directement son modèle MAI-Cyber-1-Flash aux autres : l’entreprise compare MDASH. Autrement dit, tout le harnais avec le nouveau modèle et GPT 5.4, utilisé en renfort.

Comme expliqué par l’éditeur en effet, MAI-Cyber-1-Flash est un modèle compact, conçu pour « gérer efficacement jusqu’à 90 % de toutes les tâches ». Dans cette configuration, MDASH ne basculerait vers les modèles plus gros et plus couteux (ici GPT 5.4) que dans 10 % des cas en moyenne, « pour les tâches exceptionnellement difficiles qui en ont réellement besoin ».

C’est bien cette architecture complète qui atteint près de 96 % sur CyberGym, battant Mythos de 12 points, insiste Microsoft. Rappelons que ces chiffres sont auto-rapportés et effectués dans un environnement contrôlé par Microsoft. Ils n’ont pas été vérifiés par un tiers indépendant.

Pour l’éditeur, c’est aussi une question d’économies substantielles. La meilleure offre MDASH combinait jusqu’à présent GPT 5.4 + 5.4 mini + codex 5.3. La nouvelle version intégrant MAI-Cyber-1-Flash coûterait moitié moins cher à faire tourner.

… et une plateforme

Mi-juillet, nous avions relayé un bruit de couloir : Microsoft préparait un projet nommé Perception pour venir concurrencer Anthropic et son projet Glasswing, seule manière de pouvoir utiliser Mythos.

Perception a bien été confirmé hier soir lui aussi. Il est présenté comme le système agentique qui vient chapeauter MAI-Cyber-1-Flash et MDASH. Le billet de blog dédié le présente comme une refonte de l’architecture de sécurité pour l’ère de l’IA : une nouvelle pile de sécurité doit percevoir en continu le risque sur l’ensemble du parc numérique, raisonner sur de vastes quantités de contexte et agir à vitesse machine, tout en apprenant et en s’adaptant à mesure que les environnements évoluent.

Le système coordonne trois familles d’agents spécialisés qui se transmettent le travail sans rupture de charge :

• Les agents rouges repèrent les chemins de compromission potentiels avant qu’un attaquant ne puisse les exploiter
• Les agents bleus enquêtent, évaluent le contexte et déterminent quels signaux représentent un risque réel
• Les agents verts appliquent les correctifs et durcissent l’environnement (renforcent sa sécurité)

Ces agents ne repartent pas de zéro à chaque tâche. Ils s’appuient sur un contexte de sécurité partagé : une représentation mise à jour en continu des actifs, identités, relations et risques de l’organisation. Tous les agents puisent dans ce contexte, réduisant les coûts en tokens et la latence tout en améliorant la cohérence du raisonnement, selon Microsoft.

Un programme complet, mais très jeune

Un serveur MCP est également fourni pour exécuter les actions en ligne de commande. Les agents verts peuvent aussi ouvrir directement des pull requests sur GitHub et construire des correctifs potentiels pour les vulnérabilités. Perception propose donc un système de sécurité en apprentissage continu combinant capteurs, contexte partagé, modèles multiples, agents spécialisés et mécanismes d’action capables de modifier les protections à travers l’environnement.

Le programme se présente ainsi comme une couche d’orchestration, au-dessus de MAI-Cyber-1-Flash et MDASH, avec un déploiement encore très récent et une autonomie d’action volontairement limitée à ce stade. Microsoft insiste sur le maintien d’un humain dans la boucle décisionnelle, ce qui suggère que l’entreprise elle-même reste prudente sur le niveau de confiance à accorder aux agents verts capables de modifier des systèmes de production.

Perception n’est d’ailleurs pas disponible. Le premier accès se fera sous forme de préversion le 3 août et uniquement pour des clients MDASH triés sur le volet. Même une fois lancé en version finale, il est très probable que Perception ne soit accessible qu’au travers d’un accès vérifié, à la manière de Glasswing chez Anthropic ou de Daybreak chez OpenAI.

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.

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.

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.

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.

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.

Discussion à poids ouverts

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.

Discussion à poids ouverts

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.

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.

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.

Du balais

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.

• Comment un simple branchement d’écran illustre un vieux problème de Windows

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.

Du balais

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.

• Comment un simple branchement d’écran illustre un vieux problème de Windows

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.

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.

• Tails 7.6 gère automatiquement les ponts Tor pour lutter contre la censure