En préversion-pas-pour-tout-le-monde

La nouvelle mise à jour fonctionnelle peut être récupérée dans Windows Update. Elle contient des améliorations bienvenues, notamment pour l’Explorateur et la touche Copilot.

Microsoft propose depuis ce 22 septembre une mise à jour optionnelle (KB5124010) dans Windows 11. Elle sert à tester, pour les utilisateurs en mal d’aventure, les nouveautés fonctionnelles qui seront déployées le mois prochain avec le Patch Tuesday du 14 octobre. Pour l’installer, il faut aller dans Windows Update > Options avancées > Mises à jour facultatives.

Ces mises à jour sont devenues intéressantes depuis plusieurs mois dans le sillage de l’initiative K2. Microsoft semble en effet décidée à redorer le blason de son système, l’entreprise communiquant abondamment sur les chantiers en cours : performances, composants natifs, recul de l’IA, fluidification des usages, etc.

Vers une touche Copilot personnalisable

Parmi ces chantiers, Microsoft avait évoqué la possibilité de réaffecter la touche Copilot. Celle-ci est disponible sur un nombre croissant d’ordinateurs portables (voire fixes) vendus par les constructeurs. Sur les modèles estampillés Copilot+ (essentiellement basés sur des puces Snapdragon), elle est systématiquement présente. Actuellement, elle peut soit garder son comportement (ouvrir Copilot), soit lancer une application, soit ouvrir la recherche.

Avec la mise à jour, deux nouvelles possibilités font leur apparition : menu contextuel et Ctrl droit. L’arrivée de cette dernière est une bonne nouvelle, car la touche Copilot remplace souvent Ctrl droit, perturbant l’utilisation classique du clavier. Selon Windows Latest, une prochaine mise à jour devrait apporter une ligne « Ne rien faire ». On peut toujours rêver d’une future amélioration qui laisserait la possibilité d’affecter n’importe quelle action à la touche Copilot, voire une série d’actions (macro) comme sur certains claviers.

Du mieux pour l’Explorateur et le Bluetooth

La mise à jour contient plusieurs autres améliorations bienvenues. L’une des plus importantes est le retour de la prévisualisation des documents dans le panneau Aperçu de l’Explorateur. Cette fonction était inopérante à cause d’une ancienne faille dans NTLM, mais est de retour pour tous les documents non HTML. L’Explorateur reçoit d’autres bonus : mémorisation de l’état des sections dans l’onglet Accueil, miniatures améliorées pour les fichiers dans le cloud, une réorganisation de la vue Détails et la correction d’un bug qui provoquait la disparition du contenu de la barre d’adresse quand on cherchait à la modifier.

Parmi les autres ajouts, signalons aussi l’arrivée du support d’Emoji 17.0, la correction d’un problème avec les fonds d’écran qui pouvait laisser un simple fond noir, le support des panoramas de photos en fond pour les écrans multiples, ou encore l’apparition d’un réglage permettant de lancer toutes les applications en taille maximisée.

On note aussi une amélioration significative du Bluetooth, en particulier sa fiabilité via la correction de nombreux problèmes. Ce n’est pas un mal, tant le Bluetooth peut être capricieux sur le système de Microsoft.

Attention cependant si vous installez la mise à jour pour avoir ces nouveautés, car toutes ne seront pas forcément là tout de suite, y compris pour le Bluetooth. Microsoft garde cette drôle d’habitude de diffuser certaines améliorations dans le temps, avec un déploiement progressif. Certaines améliorations pourront donc mettre plusieurs jours avant d’être effectivement disponibles. Un fonctionnement pénible, d’autant qu’il affecte tout autant les préversions du système, pourtant conçues pour tester les nouveautés dans des environnements spécifiques.

En préversion-pas-pour-tout-le-monde

La nouvelle mise à jour fonctionnelle peut être récupérée dans Windows Update. Elle contient des améliorations bienvenues, notamment pour l’Explorateur et la touche Copilot.

Microsoft propose depuis ce 22 septembre une mise à jour optionnelle (KB5124010) dans Windows 11. Elle sert à tester, pour les utilisateurs en mal d’aventure, les nouveautés fonctionnelles qui seront déployées le mois prochain avec le Patch Tuesday du 14 octobre. Pour l’installer, il faut aller dans Windows Update > Options avancées > Mises à jour facultatives.

Ces mises à jour sont devenues intéressantes depuis plusieurs mois dans le sillage de l’initiative K2. Microsoft semble en effet décidée à redorer le blason de son système, l’entreprise communiquant abondamment sur les chantiers en cours : performances, composants natifs, recul de l’IA, fluidification des usages, etc.

Vers une touche Copilot personnalisable

Parmi ces chantiers, Microsoft avait évoqué la possibilité de réaffecter la touche Copilot. Celle-ci est disponible sur un nombre croissant d’ordinateurs portables (voire fixes) vendus par les constructeurs. Sur les modèles estampillés Copilot+ (essentiellement basés sur des puces Snapdragon), elle est systématiquement présente. Actuellement, elle peut soit garder son comportement (ouvrir Copilot), soit lancer une application, soit ouvrir la recherche.

Avec la mise à jour, deux nouvelles possibilités font leur apparition : menu contextuel et Ctrl droit. L’arrivée de cette dernière est une bonne nouvelle, car la touche Copilot remplace souvent Ctrl droit, perturbant l’utilisation classique du clavier. Selon Windows Latest, une prochaine mise à jour devrait apporter une ligne « Ne rien faire ». On peut toujours rêver d’une future amélioration qui laisserait la possibilité d’affecter n’importe quelle action à la touche Copilot, voire une série d’actions (macro) comme sur certains claviers.

Du mieux pour l’Explorateur et le Bluetooth

La mise à jour contient plusieurs autres améliorations bienvenues. L’une des plus importantes est le retour de la prévisualisation des documents dans le panneau Aperçu de l’Explorateur. Cette fonction était inopérante à cause d’une ancienne faille dans NTLM, mais est de retour pour tous les documents non HTML. L’Explorateur reçoit d’autres bonus : mémorisation de l’état des sections dans l’onglet Accueil, miniatures améliorées pour les fichiers dans le cloud, une réorganisation de la vue Détails et la correction d’un bug qui provoquait la disparition du contenu de la barre d’adresse quand on cherchait à la modifier.

Parmi les autres ajouts, signalons aussi l’arrivée du support d’Emoji 17.0, la correction d’un problème avec les fonds d’écran qui pouvait laisser un simple fond noir, le support des panoramas de photos en fond pour les écrans multiples, ou encore l’apparition d’un réglage permettant de lancer toutes les applications en taille maximisée.

On note aussi une amélioration significative du Bluetooth, en particulier sa fiabilité via la correction de nombreux problèmes. Ce n’est pas un mal, tant le Bluetooth peut être capricieux sur le système de Microsoft.

Attention cependant si vous installez la mise à jour pour avoir ces nouveautés, car toutes ne seront pas forcément là tout de suite, y compris pour le Bluetooth. Microsoft garde cette drôle d’habitude de diffuser certaines améliorations dans le temps, avec un déploiement progressif. Certaines améliorations pourront donc mettre plusieurs jours avant d’être effectivement disponibles. Un fonctionnement pénible, d’autant qu’il affecte tout autant les préversions du système, pourtant conçues pour tester les nouveautés dans des environnements spécifiques.

Depuis l’incident impliquant Hugging Face, OpenAI marche sur une corde raide. L’entreprise est lancée dans un délicat jeu d’équilibrisme, entre pression sur la publication de données techniques et la nécessité financière de ne pas perdre la confiance du public. OpenAI prépare également son entrée en bourse et a besoin que sa valeur reste au beau fixe. Le 15 septembre, le Financial Times, cité par Bloomberg, évoquait ainsi un prochain tour de table qui valoriserait OpenAI à plus de 1 200 milliards de dollars. Interrogé sur le sujet, Sam Altman avait répondu que l’opération n’aurait pas lieu avant 2027.

• OpenAI : haute voltige marketing autour de l’attaque contre Hugging Face

La machine commence cependant à se gripper. Le narratif bâti sur le marketing de la peur et la foi inébranlable sur l’avenir de l’IA et des agents se fissure face à une pluie de critiques. Beaucoup remettent en question la volonté affichée de ralentir le développement des modèles de frontière pour se concentrer sur l’élaboration d’un cadre réglementaire. La Maison-Blanche n’a pas caché son hostilité à cette idée notamment.

Le 21 septembre, le secrétaire au Trésor américain Scott Bessent est même allé plus loin au micro de CNBC : l’incident Hugging Face revient selon lui à « la responsabilité de la direction d’OpenAI, pas d’un tas d’agents ». Il a indiqué partager l’analyse de Daniel Huttenlocher, co-directeur d’un laboratoire de recherche du MIT, pour qui les humains sont responsables, et non l’IA. Ces entreprises « doivent assumer leurs responsabilités », a ajouté Scott Bessent.

Cette déclaration n’est pas isolée. Elle prolonge la position que Bessent avait défendue le 15 septembre devant la commission des services financiers de la Chambre des représentants, souligne CNBC. Le secrétaire au Trésor s’y était opposé à toute exemption de responsabilité légale pour les entreprises d’IA, estimant qu’elle servirait davantage leurs intérêts commerciaux que la sécurité du public.

La prise de position est loin d’être anodine, car elle qualifie l’incident de défaillance de gouvernance humaine, plutôt que d’illustration de la puissance intrinsèque de leurs agents et de leurs comportements imprévisibles. Le 2 septembre, nous relevions d’ailleurs les mêmes éléments, en soulignant que le rapport complet d’OpenAI montrait effectivement une succession de défaillances humaines.

À noter qu’au cours de la même interview, le secrétaire au Trésor a indiqué la possible mise en place d’un téléphone rouge avec Pékin sur les questions, et la possible nomination d’un nouveau « tsar de l’IA » pour gérer ce type de dossier.

• https://next.ink/256202/les-patrons-de-lia-appellent-a-lever-le-pied-leurs-depenses-disent-linverse/

Depuis l’incident impliquant Hugging Face, OpenAI marche sur une corde raide. L’entreprise est lancée dans un délicat jeu d’équilibrisme, entre pression sur la publication de données techniques et la nécessité financière de ne pas perdre la confiance du public. OpenAI prépare également son entrée en bourse et a besoin que sa valeur reste au beau fixe. Le 15 septembre, le Financial Times, cité par Bloomberg, évoquait ainsi un prochain tour de table qui valoriserait OpenAI à plus de 1 200 milliards de dollars. Interrogé sur le sujet, Sam Altman avait répondu que l’opération n’aurait pas lieu avant 2027.

• OpenAI : haute voltige marketing autour de l’attaque contre Hugging Face

La machine commence cependant à se gripper. Le narratif bâti sur le marketing de la peur et la foi inébranlable sur l’avenir de l’IA et des agents se fissure face à une pluie de critiques. Beaucoup remettent en question la volonté affichée de ralentir le développement des modèles de frontière pour se concentrer sur l’élaboration d’un cadre réglementaire. La Maison-Blanche n’a pas caché son hostilité à cette idée notamment.

Le 21 septembre, le secrétaire au Trésor américain Scott Bessent est même allé plus loin au micro de CNBC : l’incident Hugging Face revient selon lui à « la responsabilité de la direction d’OpenAI, pas d’un tas d’agents ». Il a indiqué partager l’analyse de Daniel Huttenlocher, co-directeur d’un laboratoire de recherche du MIT, pour qui les humains sont responsables, et non l’IA. Ces entreprises « doivent assumer leurs responsabilités », a ajouté Scott Bessent.

Cette déclaration n’est pas isolée. Elle prolonge la position que Bessent avait défendue le 15 septembre devant la commission des services financiers de la Chambre des représentants, souligne CNBC. Le secrétaire au Trésor s’y était opposé à toute exemption de responsabilité légale pour les entreprises d’IA, estimant qu’elle servirait davantage leurs intérêts commerciaux que la sécurité du public.

La prise de position est loin d’être anodine, car elle qualifie l’incident de défaillance de gouvernance humaine, plutôt que d’illustration de la puissance intrinsèque de leurs agents et de leurs comportements imprévisibles. Le 2 septembre, nous relevions d’ailleurs les mêmes éléments, en soulignant que le rapport complet d’OpenAI montrait effectivement une succession de défaillances humaines.

À noter qu’au cours de la même interview, le secrétaire au Trésor a indiqué la possible mise en place d’un téléphone rouge avec Pékin sur les questions, et la possible nomination d’un nouveau « tsar de l’IA » pour gérer ce type de dossier.

• https://next.ink/256202/les-patrons-de-lia-appellent-a-lever-le-pied-leurs-depenses-disent-linverse/

On remet une pièce

Le problème des TV connectées s’étend au-delà des téléviseurs LG pointés ces dernières semaines. Si le constructeur coréen a essuyé l’essentiel des critiques, plusieurs observateurs rappellent que la problématique est en place depuis longtemps.

Tout est parti d’une série de vidéos de la chaîne Gamers Nexus. Elle y expose ses découvertes sur plusieurs téléviseurs TV OLED de la marque LG. Dans les grandes lignes : les modèles testés sont bavards, possèdent des réglages de vie privée inutilement complexes et possèdent des failles de sécurité importantes. Ces dernières, quand elles sont exploitées, permettent de modifier jusqu’aux mots d’activation pour la reconnaissance, permettant l’écoute dans la pièce.

• Des failles dans les téléviseurs connectés LG permettent d’écouter leur environnement

LG a réagi il y a peu via un communiqué, accusant essentiellement ces vidéos de mentir et de vouloir répandre la peur. Gamers Nexus a répondu à son tour, détricotant les arguments de l’entreprise, jusqu’à faire intervenir un avocat dans la vidéo. Selon ce dernier, les mots ont été soigneusement choisis par LG dans son communiqué, notamment sur la collecte de données alimentant l’ACR (reconnaissance automatique de contenu), mécanisme permettant de faire remonter les habitudes de visionnage par télémétrie.

L’ACR a concentré l’essentiel des critiques, jusqu’à faire remonter des constatations vieilles de plusieurs années, dont la capture active des signaux sur la liaison HDMI. Ainsi, l’ACR intervient également quand le téléviseur est utilisé comme simple écran, mais les informations ne peuvent pas être émises si l’appareil n’est pas connecté à internet.

Un vieux problème

Dans notre dernier article sur le sujet, nous relevions que LG était possiblement dans une position inconfortable. Il est en effet difficile d’éteindre l’incendie autour des questions de vie privée sans évoquer l’ACR, et ce mécanisme ne peut pas être abordé sans jeter tout le reste de l’industrie sous le bus. Dans ce domaine, LG est un constructeur parmi d’autres, même s’il jouit d’une présence importante, grâce à la renommée de ses dalles. Gamers Nexus évoque ainsi un parc de 216 millions de téléviseurs connectés dans le monde.

Chez The Verge, John Higgins est spécialisé dans les tests de TV et de matériel audio. Pour notre confrère, la situation est claire : « Ce n’est pas seulement LG. Toutes les chaînes de télévision vous espionnent ». L’une des clés selon lui pour comprendre le problème est la concurrence féroce que se livrent les constructeurs. Elle a entrainé une chute constante des prix des TV, « au point que certaines entreprises les vendent à perte », affirme John Higgins.

Il rappelle que les techniques d’ACR sont en place depuis longtemps, ces empreintes étant d’ailleurs utilisées pour d’autres buts que la publicité, par exemple les études d’audience par des entreprises comme Nielsen. Ces mécaniques sont omniprésentes dès que l’on parle d’un téléviseur connecté. Il indique d’ailleurs procéder toujours de la même manière pour ses tests : une adresse Gmail jetable, la désactivation de tout ce qui peut l’être pour la publicité, l’acceptation des conditions pour la reconnaissance que lorsqu’il veut tester la fonction, etc.

Dans une utilisation quotidienne, il recommande globalement la même approche, voire davantage : « Pour aller plus loin, coupez le Wi-Fi, débranchez le câble Ethernet de la télévision et utilisez-le essentiellement comme une télévision simple ». Il recommande alors de passer par un appareil de streaming dédié. Dans son cas, une Apple TV 4K : « Non pas parce que je pense qu’Apple ne récolte pas de données, mais parce qu’elle n’utilise pas ACR et que je fais plus confiance à ses protocoles de sécurité qu’à n’importe quel fabricant de téléviseurs ou Google ».

Un petit avertissement contre Gamers Nexus

Pour John Higgins, « il n’y a vraiment aucun moyen de se protéger complètement contre la collecte de données de votre télévision, de votre appareil de streaming ou des services de streaming ». Il estime qu’il y a tout simplement trop d’argent « gagné au détriment des consommateurs », le changement ne pouvant venir que des gouvernements.

Interrogé par le journaliste, Thorin Klosowski, de l’Electronic Frontier Foundation (EFF), abonde : « Nous avons besoin d’une loi fédérale complète sur la vie privée qui couvre ce type de collecte et d’utilisation abusive de données. Plus précisément, un appareil nécessitant un consentement volontaire, sans astuces de conception trompeuses pour obtenir ce consentement, et une exigence de minimisation des données, ce qui limiterait les entreprises à n’utiliser les données que pour ce qui est nécessaire à la fourniture du service ». En Europe, ces questions sont régies par le RGPD.

Si John Higgins regrette que les consommateurs doivent se « protéger activement des entreprises » vendant les produits, il regrette aussi le ton employé parfois par Gamers Nexus. Il note par exemple que les reproches les plus graves faits à LG sont basés sur l’exploitation d’une faille permettant l’obtention d’un accès root.

Le constructeur peut être critiqué sur ces problèmes de sécurité, selon lui, mais pas sur les usages faits de ces failles, puisqu’un accès root permet de réaliser pratiquement n’importe quelle opération. En Europe, ces questions sont justement à la source du Cyber Resilience Act, qui entrera pleinement en vigueur en décembre 2027. En outre, s’il ne remet pas en cause les découvertes « accablantes » réalisées par la chaîne, John Higgins regrette l’emploi d’expressions comme « ça pourrait » ou « nous pensons ».

• Cyber Resilience Act : les obligations de signalement entrent en vigueur le 11 septembre

Reste que les vidéos de la chaîne et la couverture médiatique au sens large auront remis au goût du jour le sujet. « À moins de se déconnecter complètement et de vivre dans une cabane en forêt avec une simple télévision et une collection de blu-rays, le mieux que nous puissions faire est de limiter autant d’informations partagées que possible », conclut The Verge.

Ce 19 septembre, Flock avait justement un mot à dire sur le sujet.

On remet une pièce

Le problème des TV connectées s’étend au-delà des téléviseurs LG pointés ces dernières semaines. Si le constructeur coréen a essuyé l’essentiel des critiques, plusieurs observateurs rappellent que la problématique est en place depuis longtemps.

Tout est parti d’une série de vidéos de la chaîne Gamers Nexus. Elle y expose ses découvertes sur plusieurs téléviseurs TV OLED de la marque LG. Dans les grandes lignes : les modèles testés sont bavards, possèdent des réglages de vie privée inutilement complexes et possèdent des failles de sécurité importantes. Ces dernières, quand elles sont exploitées, permettent de modifier jusqu’aux mots d’activation pour la reconnaissance, permettant l’écoute dans la pièce.

• Des failles dans les téléviseurs connectés LG permettent d’écouter leur environnement

LG a réagi il y a peu via un communiqué, accusant essentiellement ces vidéos de mentir et de vouloir répandre la peur. Gamers Nexus a répondu à son tour, détricotant les arguments de l’entreprise, jusqu’à faire intervenir un avocat dans la vidéo. Selon ce dernier, les mots ont été soigneusement choisis par LG dans son communiqué, notamment sur la collecte de données alimentant l’ACR (reconnaissance automatique de contenu), mécanisme permettant de faire remonter les habitudes de visionnage par télémétrie.

L’ACR a concentré l’essentiel des critiques, jusqu’à faire remonter des constatations vieilles de plusieurs années, dont la capture active des signaux sur la liaison HDMI. Ainsi, l’ACR intervient également quand le téléviseur est utilisé comme simple écran, mais les informations ne peuvent pas être émises si l’appareil n’est pas connecté à internet.

Un vieux problème

Dans notre dernier article sur le sujet, nous relevions que LG était possiblement dans une position inconfortable. Il est en effet difficile d’éteindre l’incendie autour des questions de vie privée sans évoquer l’ACR, et ce mécanisme ne peut pas être abordé sans jeter tout le reste de l’industrie sous le bus. Dans ce domaine, LG est un constructeur parmi d’autres, même s’il jouit d’une présence importante, grâce à la renommée de ses dalles. Gamers Nexus évoque ainsi un parc de 216 millions de téléviseurs connectés dans le monde.

Chez The Verge, John Higgins est spécialisé dans les tests de TV et de matériel audio. Pour notre confrère, la situation est claire : « Ce n’est pas seulement LG. Toutes les chaînes de télévision vous espionnent ». L’une des clés selon lui pour comprendre le problème est la concurrence féroce que se livrent les constructeurs. Elle a entrainé une chute constante des prix des TV, « au point que certaines entreprises les vendent à perte », affirme John Higgins.

Il rappelle que les techniques d’ACR sont en place depuis longtemps, ces empreintes étant d’ailleurs utilisées pour d’autres buts que la publicité, par exemple les études d’audience par des entreprises comme Nielsen. Ces mécaniques sont omniprésentes dès que l’on parle d’un téléviseur connecté. Il indique d’ailleurs procéder toujours de la même manière pour ses tests : une adresse Gmail jetable, la désactivation de tout ce qui peut l’être pour la publicité, l’acceptation des conditions pour la reconnaissance que lorsqu’il veut tester la fonction, etc.

Dans une utilisation quotidienne, il recommande globalement la même approche, voire davantage : « Pour aller plus loin, coupez le Wi-Fi, débranchez le câble Ethernet de la télévision et utilisez-le essentiellement comme une télévision simple ». Il recommande alors de passer par un appareil de streaming dédié. Dans son cas, une Apple TV 4K : « Non pas parce que je pense qu’Apple ne récolte pas de données, mais parce qu’elle n’utilise pas ACR et que je fais plus confiance à ses protocoles de sécurité qu’à n’importe quel fabricant de téléviseurs ou Google ».

Un petit avertissement contre Gamers Nexus

Pour John Higgins, « il n’y a vraiment aucun moyen de se protéger complètement contre la collecte de données de votre télévision, de votre appareil de streaming ou des services de streaming ». Il estime qu’il y a tout simplement trop d’argent « gagné au détriment des consommateurs », le changement ne pouvant venir que des gouvernements.

Interrogé par le journaliste, Thorin Klosowski, de l’Electronic Frontier Foundation (EFF), abonde : « Nous avons besoin d’une loi fédérale complète sur la vie privée qui couvre ce type de collecte et d’utilisation abusive de données. Plus précisément, un appareil nécessitant un consentement volontaire, sans astuces de conception trompeuses pour obtenir ce consentement, et une exigence de minimisation des données, ce qui limiterait les entreprises à n’utiliser les données que pour ce qui est nécessaire à la fourniture du service ». En Europe, ces questions sont régies par le RGPD.

Si John Higgins regrette que les consommateurs doivent se « protéger activement des entreprises » vendant les produits, il regrette aussi le ton employé parfois par Gamers Nexus. Il note par exemple que les reproches les plus graves faits à LG sont basés sur l’exploitation d’une faille permettant l’obtention d’un accès root.

Le constructeur peut être critiqué sur ces problèmes de sécurité, selon lui, mais pas sur les usages faits de ces failles, puisqu’un accès root permet de réaliser pratiquement n’importe quelle opération. En Europe, ces questions sont justement à la source du Cyber Resilience Act, qui entrera pleinement en vigueur en décembre 2027. En outre, s’il ne remet pas en cause les découvertes « accablantes » réalisées par la chaîne, John Higgins regrette l’emploi d’expressions comme « ça pourrait » ou « nous pensons ».

• Cyber Resilience Act : les obligations de signalement entrent en vigueur le 11 septembre

Reste que les vidéos de la chaîne et la couverture médiatique au sens large auront remis au goût du jour le sujet. « À moins de se déconnecter complètement et de vivre dans une cabane en forêt avec une simple télévision et une collection de blu-rays, le mieux que nous puissions faire est de limiter autant d’informations partagées que possible », conclut The Verge.

Ce 19 septembre, Flock avait justement un mot à dire sur le sujet.

Overhyped

SpaceXAI a lancé son nouveau modèle Grok 4.7 ce 21 septembre. Si Elon Musk vantait l’arrivée de cette version, les résultats indépendants ne semblent pas à la hauteur des attentes. En revanche, le LLM garde pour lui l’avantage d’une tarification plus douce que certains des gros modèles lancés ces derniers mois.

Mise à jour du 23 septembre : Dans la version originale de l’article, nous avons mentionné les prix sans évoquer la consommation de tokens à l’usage. Nous avons modifié cette partie, Grok 4.7 se révélant nettement plus verbeux que son prédécesseur, avec des conséquences sur la facture.

Article original du 22 septembre :

La version 4.7 de Grok repose sur un nouveau modèle de base, plus grand que pour Grok 4.6. Dans son annonce, SpaceXAI indique qu’il a été entraîné par renforcement plus longtemps, sur des tâches plus difficiles, avec un accent sur les problèmes qui demandent plusieurs heures de travail. L’entreprise affirme que le modèle vérifie mieux son propre travail et gère mieux les contextes longs. Le modèle a aussi été entraîné pour fonctionner nativement dans l’environnement Grok Bot.

Dans la documentation fournie, on peut lire que le modèle grok-4.7 dispose d’une fenêtre de 500 000 jetons (tokens), ses connaissances s’arrêtant en mai 2026. Sans surprise, le LLM est multimodal (texte et images en entrée) et produit du texte en sortie. On retrouve en outre les quatre mêmes niveaux de raisonnement : bas, moyen, haut (par défaut) ou très haut (xhigh). Appel de fonctions, recherche web ou sur X, ou encore exécution de code sont autant de possibilités mises en avant par SpaceXAI.

La société d’Elon Musk met en avant de nombreuses qualités en phase avec les discussions actuelles autour de la sécurité. Elle évoque par exemple « de solides capacités de défense cyber » tout en gardant « de faibles taux de refus d’utilisation légitime ». Grok 4.7 aurait obtenu le score le plus élevé sur HackberBench 0.3 et n’aurait autorisé que 3,3 % des prompts risqués. En outre, le nouveau LLM se montrerait plus robuste face aux tentatives de jailbreak.

Des performances en deçà des attentes

Sur le chapitre des performances, la situation est plus complexe. Selon les chiffres avancés par l’entreprise, Grok 4.7 se débrouille bien sûr très bien. Cependant, on remarque vite que le tableau donné par SpaceXAI ne compare pas toujours les mêmes éléments. Par exemple, Grok 4.7 est testé en mode de raisonnement xHigh alors que Grok 4.6 est testé en High.

Cela n’empêche pas l’entreprise de revendiquer de très bonnes performances, surtout face à son modèle précédent et dans des domaines particuliers. « Grok 4.7 est meilleur pour créer des documents et des présentations. Dans GDPval et AA Briefcase, l’IA est sollicitée pour travailler sur des tâches réalisées par des professionnels tels que des avocats, des infirmiers et des analystes financiers. Grok 4.7 améliore Grok 4.6 sur les deux benchmarks et se comporte de manière comparable à d’autres modèles Frontier », affirme ainsi SpaceXAI.

Sur X, on trouve déjà de nombreux commentaires et tests réalisés, plus ou moins spécifiques. Côté positif, on note par exemple le tweet d’Auggie qui relève un taux de 100 % sur son test de « détection d’erreurs » sur la musique, un score que seul avait atteint Astra. Le même testeur a en revanche été moins enthousiasmé sur Bach Benchmark (qui demande aux LLM de composer des chorals à quatre voix dans le style de Bach). Si l’on en croit Artificial Analysis, les revendications de SpaceXAI sur la création de documents sont avérées, avec en particulier un bond significatif sur le test Analytical Quality Elo.

Toutefois, les retours négatifs sont plus nombreux. Pour Jose Antonio Lanz par exemple, Grok 4.7 n’a rien d’un mauvais modèle, mais il est derrière la concurrence, particulièrement Astra ou même Sonnet 5 selon les essais réalisés. Il souligne d’ailleurs qu’Elon Musk avait lui-même cherché à diminuer les attentes autour de son modèle, en indiquant dans un tweet le 14 septembre que Grok 4.7 serait davantage à comparer à Opus 5 que 5.1. Il en profite pour annoncer que Grok 4.8 sera une « amélioration notable », que Grok 4.9 sera « probablement » au niveau d’Astra et Fable et que Grok 5 sera « peut-être meilleur que tout le reste ». Plusieurs personnes ont alors fait remarquer qu’OpenAI et Anthropic allaient eux aussi lancer de nouveaux modèles pendant ces laps de temps.

Selon The Decoder, Grok 4.7 obtient 46 à l’indice Artificial Analysis (v4.3.2), qui agrège dix tests. Il se place ainsi en milieu de peloton, derrière Claude Fable 5.1 et GPT-6, à 53 chacun. Sur Terminal-Bench 4.0, l’évaluation donne 26 %, bien en dessous des 38 % annoncés par xAI, et très loin des 60 % atteints par Astra et des 55 % de Fable 5.1.

Tarifs identiques, mais plus gourmand en tokens

Si les performances semblent globalement décevantes, Grok 4.7 se débrouille mieux que son prédécesseur dans la quasi-totalité des scénarios, sans toucher aux prix. On reste donc sur 2 dollars par million de jetons en entrée et 6 dollars par million en sortie. Une variante Fast est disponible, servie par une infrastructure plus rapide, avec une facturation doublée. Elle n’est cependant disponible que via Cursor et Grok Build, pas sur l’API publique. Sur cette dernière, tous les cas d’usage passant par Grok 4.6 ont automatiquement basculé sur le nouveau modèle.

SpaceXAI joue d’ailleurs la carte du rapport performances/prix en comparant sa grille tarifaire à celles de concurrents. GPT-5.6 Sol et Claude Fable 5.1 sont dans la ligne de mire, avec respectivement 4/20 dollars et 10/50 dollars.

Cependant, cette grille tarifaire ne raconte pas toute l’histoire. Selon des tests réalisés par Artificial Analysis, Grok 4.7 est plus gourmand en tokens que son prédécesseur. L’écart est a priori significatif : 81 000 jetons de sortie par tâche Intelligence Index pour Grok 4.7 xHigh, contre 38 000 pour Grok 4.6 xHigh et 27 000 pour GPT-6 Astra Max. Selon Artificial Analysis, Grok 4.7 est particulièrement verbeux, avec 240 millions de tokens générés pendant ses tests, contre une médiane de 88 millions.

Le positionnement général est ainsi celui d’un modèle faisant mieux que Grok 4.6 pour le même prix par tokens, mais possiblement plus lourd sur la facturation et l’usage des quotas. Il n’y a donc pas de rupture, et on reste sur l’interrogation classique du choix du modèle en fonction du scénario d’usage envisagé. Grok 4.7 illustre la manière dont un LLM peut s’avérer plus cher à l’utilisation que son prédécesseur, même quand le prix par token ne bouge pas ou diminue, comme nous l’avions montré avec Opus 4.7 d’Anthropic.

• Nextquick : Pourquoi et comment Opus 4.7 crame ses tokens beaucoup plus vite qu’Opus 4.6

Enfin, on notera que le calendrier des sorties des prochaines versions ne semble pas ralentir, puisque Grok 4.8 serait proposé dans un mois. Une affirmation à prendre avec des pincettes, Grok 4.7 ayant été repoussé plusieurs fois. Le rythme cadre mal cependant avec le positionnement d’Elon Musk sur la nécessité de ralentir le développement des modèles de frontière. Il a publiquement soutenu l’idée de Dario Amodei, CEO d’Anthropic, de calmer le jeu et de réfléchir à un cadre clair pour mesurer l’alignement des modèles. Comme nous l’avions relevé toutefois, ces déclarations d’intentions ne semblent pas suivies d’actions concrètes.

• Les patrons de l’IA appellent à lever le pied, leurs dépenses disent l’inverse

Overhyped

SpaceXAI a lancé son nouveau modèle Grok 4.7 ce 21 septembre. Si Elon Musk vantait l’arrivée de cette version, les résultats indépendants ne semblent pas à la hauteur des attentes. En revanche, le LLM garde pour lui l’avantage d’une tarification plus douce que certains des gros modèles lancés ces derniers mois.

Mise à jour du 23 septembre : Dans la version originale de l’article, nous avons mentionné les prix sans évoquer la consommation de tokens à l’usage. Nous avons modifié cette partie, Grok 4.7 se révélant nettement plus verbeux que son prédécesseur, avec des conséquences sur la facture.

Article original du 22 septembre :

La version 4.7 de Grok repose sur un nouveau modèle de base, plus grand que pour Grok 4.6. Dans son annonce, SpaceXAI indique qu’il a été entraîné par renforcement plus longtemps, sur des tâches plus difficiles, avec un accent sur les problèmes qui demandent plusieurs heures de travail. L’entreprise affirme que le modèle vérifie mieux son propre travail et gère mieux les contextes longs. Le modèle a aussi été entraîné pour fonctionner nativement dans l’environnement Grok Bot.

Dans la documentation fournie, on peut lire que le modèle grok-4.7 dispose d’une fenêtre de 500 000 jetons (tokens), ses connaissances s’arrêtant en mai 2026. Sans surprise, le LLM est multimodal (texte et images en entrée) et produit du texte en sortie. On retrouve en outre les quatre mêmes niveaux de raisonnement : bas, moyen, haut (par défaut) ou très haut (xhigh). Appel de fonctions, recherche web ou sur X, ou encore exécution de code sont autant de possibilités mises en avant par SpaceXAI.

La société d’Elon Musk met en avant de nombreuses qualités en phase avec les discussions actuelles autour de la sécurité. Elle évoque par exemple « de solides capacités de défense cyber » tout en gardant « de faibles taux de refus d’utilisation légitime ». Grok 4.7 aurait obtenu le score le plus élevé sur HackberBench 0.3 et n’aurait autorisé que 3,3 % des prompts risqués. En outre, le nouveau LLM se montrerait plus robuste face aux tentatives de jailbreak.

Des performances en deçà des attentes

Sur le chapitre des performances, la situation est plus complexe. Selon les chiffres avancés par l’entreprise, Grok 4.7 se débrouille bien sûr très bien. Cependant, on remarque vite que le tableau donné par SpaceXAI ne compare pas toujours les mêmes éléments. Par exemple, Grok 4.7 est testé en mode de raisonnement xHigh alors que Grok 4.6 est testé en High.

Cela n’empêche pas l’entreprise de revendiquer de très bonnes performances, surtout face à son modèle précédent et dans des domaines particuliers. « Grok 4.7 est meilleur pour créer des documents et des présentations. Dans GDPval et AA Briefcase, l’IA est sollicitée pour travailler sur des tâches réalisées par des professionnels tels que des avocats, des infirmiers et des analystes financiers. Grok 4.7 améliore Grok 4.6 sur les deux benchmarks et se comporte de manière comparable à d’autres modèles Frontier », affirme ainsi SpaceXAI.

Sur X, on trouve déjà de nombreux commentaires et tests réalisés, plus ou moins spécifiques. Côté positif, on note par exemple le tweet d’Auggie qui relève un taux de 100 % sur son test de « détection d’erreurs » sur la musique, un score que seul avait atteint Astra. Le même testeur a en revanche été moins enthousiasmé sur Bach Benchmark (qui demande aux LLM de composer des chorals à quatre voix dans le style de Bach). Si l’on en croit Artificial Analysis, les revendications de SpaceXAI sur la création de documents sont avérées, avec en particulier un bond significatif sur le test Analytical Quality Elo.

Toutefois, les retours négatifs sont plus nombreux. Pour Jose Antonio Lanz par exemple, Grok 4.7 n’a rien d’un mauvais modèle, mais il est derrière la concurrence, particulièrement Astra ou même Sonnet 5 selon les essais réalisés. Il souligne d’ailleurs qu’Elon Musk avait lui-même cherché à diminuer les attentes autour de son modèle, en indiquant dans un tweet le 14 septembre que Grok 4.7 serait davantage à comparer à Opus 5 que 5.1. Il en profite pour annoncer que Grok 4.8 sera une « amélioration notable », que Grok 4.9 sera « probablement » au niveau d’Astra et Fable et que Grok 5 sera « peut-être meilleur que tout le reste ». Plusieurs personnes ont alors fait remarquer qu’OpenAI et Anthropic allaient eux aussi lancer de nouveaux modèles pendant ces laps de temps.

Selon The Decoder, Grok 4.7 obtient 46 à l’indice Artificial Analysis (v4.3.2), qui agrège dix tests. Il se place ainsi en milieu de peloton, derrière Claude Fable 5.1 et GPT-6, à 53 chacun. Sur Terminal-Bench 4.0, l’évaluation donne 26 %, bien en dessous des 38 % annoncés par xAI, et très loin des 60 % atteints par Astra et des 55 % de Fable 5.1.

Tarifs identiques, mais plus gourmand en tokens

Si les performances semblent globalement décevantes, Grok 4.7 se débrouille mieux que son prédécesseur dans la quasi-totalité des scénarios, sans toucher aux prix. On reste donc sur 2 dollars par million de jetons en entrée et 6 dollars par million en sortie. Une variante Fast est disponible, servie par une infrastructure plus rapide, avec une facturation doublée. Elle n’est cependant disponible que via Cursor et Grok Build, pas sur l’API publique. Sur cette dernière, tous les cas d’usage passant par Grok 4.6 ont automatiquement basculé sur le nouveau modèle.

SpaceXAI joue d’ailleurs la carte du rapport performances/prix en comparant sa grille tarifaire à celles de concurrents. GPT-5.6 Sol et Claude Fable 5.1 sont dans la ligne de mire, avec respectivement 4/20 dollars et 10/50 dollars.

Cependant, cette grille tarifaire ne raconte pas toute l’histoire. Selon des tests réalisés par Artificial Analysis, Grok 4.7 est plus gourmand en tokens que son prédécesseur. L’écart est a priori significatif : 81 000 jetons de sortie par tâche Intelligence Index pour Grok 4.7 xHigh, contre 38 000 pour Grok 4.6 xHigh et 27 000 pour GPT-6 Astra Max. Selon Artificial Analysis, Grok 4.7 est particulièrement verbeux, avec 240 millions de tokens générés pendant ses tests, contre une médiane de 88 millions.

Le positionnement général est ainsi celui d’un modèle faisant mieux que Grok 4.6 pour le même prix par tokens, mais possiblement plus lourd sur la facturation et l’usage des quotas. Il n’y a donc pas de rupture, et on reste sur l’interrogation classique du choix du modèle en fonction du scénario d’usage envisagé. Grok 4.7 illustre la manière dont un LLM peut s’avérer plus cher à l’utilisation que son prédécesseur, même quand le prix par token ne bouge pas ou diminue, comme nous l’avions montré avec Opus 4.7 d’Anthropic.

• Nextquick : Pourquoi et comment Opus 4.7 crame ses tokens beaucoup plus vite qu’Opus 4.6

Enfin, on notera que le calendrier des sorties des prochaines versions ne semble pas ralentir, puisque Grok 4.8 serait proposé dans un mois. Une affirmation à prendre avec des pincettes, Grok 4.7 ayant été repoussé plusieurs fois. Le rythme cadre mal cependant avec le positionnement d’Elon Musk sur la nécessité de ralentir le développement des modèles de frontière. Il a publiquement soutenu l’idée de Dario Amodei, CEO d’Anthropic, de calmer le jeu et de réfléchir à un cadre clair pour mesurer l’alignement des modèles. Comme nous l’avions relevé toutefois, ces déclarations d’intentions ne semblent pas suivies d’actions concrètes.

• Les patrons de l’IA appellent à lever le pied, leurs dépenses disent l’inverse

Ceci n'est pas un LLM

La société TypeSafe AI a présenté il y a quelques jours un nouveau modèle d’IA. Baptisé Jev, il se propose de traiter certaines opérations bien plus rapidement que les LLM « traditionnels », pour beaucoup moins cher. La comparaison reste cependant délicate.

L’annonce a fait l’effet d’une petite bombe sur les réseaux sociaux, particulièrement sur X : la société TypeSafe AI, fondée par Diogo Almeida, a annoncé son nouveau modèle de frontière, Jev.

Diogo Almeida se présente comme co-inventeur de ChatGPT. Un titre un peu exagéré. Il a travaillé effectivement sur les méthodes qui ont rendu capables les modèles GPT de suivre des instructions et de converser avec les utilisateurs. Mais il serait plus juste de dire qu’il est le co-inventeur du RLHF (Reinforcement Learning from Human Feedback), c’est-à-dire l’apprentissage par renforcement à partir de rétroaction humaine. Il est effectivement l’un des auteurs d’un papier fondateur sur la question.

Jev, en tout cas, n’est pas un LLM : il ne peut pas créer de texte ni même aider à la programmation. Il est décrit comme le premier « System One Model », une nouvelle catégorie de modèles conçus pour prendre des décisions rapides et structurées, que des services ou applications peuvent ensuite utiliser directement.

Ce qu’est Jev

Le modèle est comparé par TypeSafe AI à un appel de fonction : un état non structuré en entrée, des décisions probabilistes typées en sortie. Concrètement, on lui envoie un état (le contexte) et des questions portant sur cet état. Les réponses possibles sont fixées à l’avance par un schéma. Jev répond ensuite via trois primitives : le choix d’une option dans un ensemble, une note sur une échelle ordonnée, et un oui ou non calibré.

Pour bâtir Jev, TypeSafe AI dit avoir construit une nouvelle architecture de modèle, un échantillonneur parallèle et une nouvelle méthode de renforcement baptisée RLCD, pour « Reinforcement Learning for Calibrated Decisions ». L’échantillonneur parallèle signifie que toutes les questions d’une requête sont évaluées en parallèle, contrairement à un LLM dont chaque nouvel élément dépend du précédent.

Plusieurs points forts sont mis en avant, notamment la calibration via RLCD. Selon l’entreprise, cet entrainement doit permettre des réponses assorties de probabilités « honnêtes ». Dans ce contexte, une confiance plus élevée (donnée sous forme de pourcentage) signifie une meilleure exactitude. En outre, TypeSafe affirme que Jev ne peut pas halluciner, puisque la sortie est contrainte par le schéma. Il faut cependant lire entre les lignes : dans ce contexte, Jev garantit le respect du format, pas la justesse du format. En d’autres termes, Jev ne peut rien « inventer », mais il peut se tromper de catégorie.

Vite, un exemple !

Pour mieux comprendre l’intérêt de ce nouveau modèle, mieux vaut un exemple. Imaginons un service client qui reçoit 10 000 e-mails par jour. Pour chacun, un programme doit prendre plusieurs décisions : le client est-il mécontent ? Faut-il envoyer le message au service facturation, technique ou commercial ? Est-ce urgent ?

Aujourd’hui, ce type de tâche est souvent confié à un LLM comme GPT ou Claude. On lui envoie l’e-mail avec une consigne du type « dis-moi si c’est urgent », et il répond par une phrase : « Oui, ce message semble urgent car le client menace de résilier ». Problème, un programme informatique ne « comprend » pas les phrases. Il faut donc un travail supplémentaire pour extraire le « oui » de cette phrase. De plus, le modèle peut répondre à côté, ajouter des commentaires inutiles ou inventer une catégorie qui n’existe pas. Enfin, écrire une phrase mot par mot prend du temps et coûte cher.

Jev ne fonctionne pas avec des phrases, mais avec trois primitives. On applique une liste de questions dont les réponses sont fixées à l’avance :

• Le client est-il mécontent ? Oui/Non
• Quel service doit traiter cet e-mail ? Facturation/Technique/Commercial
• Quelle urgence sur une note de 1 à 5 ?

Si on continue dans cet exemple, on obtiendra une réponse du type : « oui (92 % de certitude), facturation (85 %), urgence 4 (70 %) ». Cela revient à donner un formulaire à remplir pour répondre à une question plutôt que demander son avis à une personne.

Les données émises par Jev sont formatées et peuvent être reprises telles quelles par d’autres éléments de traitement de la chaine. Quand TypeSafe affirme que son modèle ne peut pas halluciner, cela signifie que Jev ne peut pas répondre par exemple « Juridique » pour le service à contacter. En revanche, rien ne l’empêche de se tromper sur le service à effectivement contacter. On peut alors appliquer un filtre pour automatiser l’envoi à une équipe humaine pour toutes les réponses dont le score de confiance est inférieur à 80 %.

L’efficacité mise en avant

L’un des éléments les plus repris par la presse est l’efficacité du modèle. Sur les tâches pour lesquelles il a été pensé, le temps de réponse annoncé va de 70 à 500 ms, soit 40 à 200 fois plus rapide que les modèles de pointe pour des requêtes de ce type. Le prix est de 0,042 dollar par million de jetons en entrée, et la sortie est gratuite. À titre de comparaison, GPT-5.6 Terra coûte 2 dollars par million de jetons en entrée et 12 dollars en sortie.

Dans sa présentation, TypeSafe donne des chiffres mais émet elle-même des réserves. Ainsi, les gains maximaux peuvent être très précisément de x193,6 sur les performances et x444,6 moins cher. Ces chiffres viennent de quatre chaines de traitement interne : réponse aux incidents de sécurité, observation de traces d’agents, traitement de factures et service client.

Même si TypeSafe évoque une certaine prudence, il est difficile pour l’instant de jauger des performances réelles comme de la facture finale, car le modèle n’est disponible pour tout le monde que depuis le 20 septembre, sans liste d’attente. Si l’on en croit certains retours d’entreprises ayant testé le modèle, le gain semble avéré.

En outre, l’annonce de Jev est déjà contestée. Selon Nandakishor Mukkunnoth, fondateur de ConvAI Innovations, l’idée n’est pas nouvelle. Dans un billet, il indique être à l’origine des recherches qui ont mené à cette technique, dont il revendique la paternité. Il ne reproche pas à TypeSafe d’avoir copié du code, mais de ne pas avoir cité des travaux antérieurs. Sur Hacker News, plusieurs personnes notent que ce type de mésaventure est malheureusement courant, mais que l’apport de TypeSafe est surtout d’avoir réussi à en faire un produit concret.

Ce qui n’a pas empêché Nandakishor Mukkunnoth de publier une alternative libre, nommée Laya. D’autres modèles libres sont apparus en quelques jours. Si l’on en croit les premiers tests réalisés indépendamment, tous les modèles affichent des performances moindres que Jev. Si l’on donne un score de référence de 1 à ce dernier, les 78 tests effectués font ressortir des notes alternant entre 0,5 et 0,7, Laya étant dans la moyenne.

Ceci n'est pas un LLM

La société TypeSafe AI a présenté il y a quelques jours un nouveau modèle d’IA. Baptisé Jev, il se propose de traiter certaines opérations bien plus rapidement que les LLM « traditionnels », pour beaucoup moins cher. La comparaison reste cependant délicate.

L’annonce a fait l’effet d’une petite bombe sur les réseaux sociaux, particulièrement sur X : la société TypeSafe AI, fondée par Diogo Almeida, a annoncé son nouveau modèle de frontière, Jev.

Diogo Almeida se présente comme co-inventeur de ChatGPT. Un titre un peu exagéré. Il a travaillé effectivement sur les méthodes qui ont rendu capables les modèles GPT de suivre des instructions et de converser avec les utilisateurs. Mais il serait plus juste de dire qu’il est le co-inventeur du RLHF (Reinforcement Learning from Human Feedback), c’est-à-dire l’apprentissage par renforcement à partir de rétroaction humaine. Il est effectivement l’un des auteurs d’un papier fondateur sur la question.

Jev, en tout cas, n’est pas un LLM : il ne peut pas créer de texte ni même aider à la programmation. Il est décrit comme le premier « System One Model », une nouvelle catégorie de modèles conçus pour prendre des décisions rapides et structurées, que des services ou applications peuvent ensuite utiliser directement.

Ce qu’est Jev

Le modèle est comparé par TypeSafe AI à un appel de fonction : un état non structuré en entrée, des décisions probabilistes typées en sortie. Concrètement, on lui envoie un état (le contexte) et des questions portant sur cet état. Les réponses possibles sont fixées à l’avance par un schéma. Jev répond ensuite via trois primitives : le choix d’une option dans un ensemble, une note sur une échelle ordonnée, et un oui ou non calibré.

Pour bâtir Jev, TypeSafe AI dit avoir construit une nouvelle architecture de modèle, un échantillonneur parallèle et une nouvelle méthode de renforcement baptisée RLCD, pour « Reinforcement Learning for Calibrated Decisions ». L’échantillonneur parallèle signifie que toutes les questions d’une requête sont évaluées en parallèle, contrairement à un LLM dont chaque nouvel élément dépend du précédent.

Plusieurs points forts sont mis en avant, notamment la calibration via RLCD. Selon l’entreprise, cet entrainement doit permettre des réponses assorties de probabilités « honnêtes ». Dans ce contexte, une confiance plus élevée (donnée sous forme de pourcentage) signifie une meilleure exactitude. En outre, TypeSafe affirme que Jev ne peut pas halluciner, puisque la sortie est contrainte par le schéma. Il faut cependant lire entre les lignes : dans ce contexte, Jev garantit le respect du format, pas la justesse du format. En d’autres termes, Jev ne peut rien « inventer », mais il peut se tromper de catégorie.

Vite, un exemple !

Pour mieux comprendre l’intérêt de ce nouveau modèle, mieux vaut un exemple. Imaginons un service client qui reçoit 10 000 e-mails par jour. Pour chacun, un programme doit prendre plusieurs décisions : le client est-il mécontent ? Faut-il envoyer le message au service facturation, technique ou commercial ? Est-ce urgent ?

Aujourd’hui, ce type de tâche est souvent confié à un LLM comme GPT ou Claude. On lui envoie l’e-mail avec une consigne du type « dis-moi si c’est urgent », et il répond par une phrase : « Oui, ce message semble urgent car le client menace de résilier ». Problème, un programme informatique ne « comprend » pas les phrases. Il faut donc un travail supplémentaire pour extraire le « oui » de cette phrase. De plus, le modèle peut répondre à côté, ajouter des commentaires inutiles ou inventer une catégorie qui n’existe pas. Enfin, écrire une phrase mot par mot prend du temps et coûte cher.

Jev ne fonctionne pas avec des phrases, mais avec trois primitives. On applique une liste de questions dont les réponses sont fixées à l’avance :

• Le client est-il mécontent ? Oui/Non
• Quel service doit traiter cet e-mail ? Facturation/Technique/Commercial
• Quelle urgence sur une note de 1 à 5 ?

Si on continue dans cet exemple, on obtiendra une réponse du type : « oui (92 % de certitude), facturation (85 %), urgence 4 (70 %) ». Cela revient à donner un formulaire à remplir pour répondre à une question plutôt que demander son avis à une personne.

Les données émises par Jev sont formatées et peuvent être reprises telles quelles par d’autres éléments de traitement de la chaine. Quand TypeSafe affirme que son modèle ne peut pas halluciner, cela signifie que Jev ne peut pas répondre par exemple « Juridique » pour le service à contacter. En revanche, rien ne l’empêche de se tromper sur le service à effectivement contacter. On peut alors appliquer un filtre pour automatiser l’envoi à une équipe humaine pour toutes les réponses dont le score de confiance est inférieur à 80 %.

L’efficacité mise en avant

L’un des éléments les plus repris par la presse est l’efficacité du modèle. Sur les tâches pour lesquelles il a été pensé, le temps de réponse annoncé va de 70 à 500 ms, soit 40 à 200 fois plus rapide que les modèles de pointe pour des requêtes de ce type. Le prix est de 0,042 dollar par million de jetons en entrée, et la sortie est gratuite. À titre de comparaison, GPT-5.6 Terra coûte 2 dollars par million de jetons en entrée et 12 dollars en sortie.

Dans sa présentation, TypeSafe donne des chiffres mais émet elle-même des réserves. Ainsi, les gains maximaux peuvent être très précisément de x193,6 sur les performances et x444,6 moins cher. Ces chiffres viennent de quatre chaines de traitement interne : réponse aux incidents de sécurité, observation de traces d’agents, traitement de factures et service client.

Même si TypeSafe évoque une certaine prudence, il est difficile pour l’instant de jauger des performances réelles comme de la facture finale, car le modèle n’est disponible pour tout le monde que depuis le 20 septembre, sans liste d’attente. Si l’on en croit certains retours d’entreprises ayant testé le modèle, le gain semble avéré.

En outre, l’annonce de Jev est déjà contestée. Selon Nandakishor Mukkunnoth, fondateur de ConvAI Innovations, l’idée n’est pas nouvelle. Dans un billet, il indique être à l’origine des recherches qui ont mené à cette technique, dont il revendique la paternité. Il ne reproche pas à TypeSafe d’avoir copié du code, mais de ne pas avoir cité des travaux antérieurs. Sur Hacker News, plusieurs personnes notent que ce type de mésaventure est malheureusement courant, mais que l’apport de TypeSafe est surtout d’avoir réussi à en faire un produit concret.

Ce qui n’a pas empêché Nandakishor Mukkunnoth de publier une alternative libre, nommée Laya. D’autres modèles libres sont apparus en quelques jours. Si l’on en croit les premiers tests réalisés indépendamment, tous les modèles affichent des performances moindres que Jev. Si l’on donne un score de référence de 1 à ce dernier, les 78 tests effectués font ressortir des notes alternant entre 0,5 et 0,7, Laya étant dans la moyenne.

Don't be evil

L’équipe de GrapheneOS n’est pas contente. Le nouveau rythme de parution des mises à jour d’Android laisse le système alternatif sur le bord de la route un trimestre sur deux. Dans un fil sur les réseaux sociaux, elle explique les problèmes auxquels elle fait face.

« Android 17 QPR1 est la première version depuis Android Honeycomb (3.x) qui ajoute de nouvelles API pour les développeurs d’applications sans publication dans l’Android Open Source Project. Les nouvelles API sont actuellement exclusives à Pixel OS et ne sont pas disponibles pour les autres OEM Android », débute le fil de GrapheneOS sur X et Mastodon.

L’équipe dénonce une nouvelle fois les changements intervenus chez Google dans la parution des mises à jour pour Android. Dans les grandes lignes, elles ne sont plus reversées dans Android Open Source Project que durant le deuxième et le quatrième trimestres.

Deux gros reproches

L’agacement de l’équipe est palpable. Dans son fil, elle pointe surtout deux problèmes majeurs pour son propre fonctionnement.

D’une part, la disponibilité de la première QPR (Quarterly Platform Release) pour Android 17 montre la présence de nouvelles interfaces de programmation (API). Or, cette QPR1 n’est disponible que sur les propres appareils Pixel de Google. L’équipe de GrapheneOS indique qu’il ne s’agit pourtant pas d’API spécifiques aux Pixel : ce sont des interfaces Android standard, qui ne parviendront à l’AOSP et aux autres fabricants qu’en décembre 2026 avec Android 17 QPR2.

Selon l’équipe, c’est la première fois depuis l’ancienne version Honeycomb que Google ajoute ainsi des API sans les reverser immédiatement dans AOSP. Si Google répète le schéma, il pourrait donc y avoir six mois sur douze pendant lesquels les appareils Pixel seraient les seuls à profiter de ces interfaces.

D’autre part, comme on pouvait le prévoir, la question des correctifs de sécurité se pose. Le bulletin Pixel de septembre 2026 contient des correctifs supplémentaires qui touchent des composants standard de la plateforme Android, également employés par des appareils tiers. Pourtant, ces correctifs ne figurent pas au bulletin de sécurité Android du même mois, ni dans les correctifs communiqués en avance aux fabricants. En clair, les fabricants tiers et les systèmes alternatifs basés sur AOSP – dont GrapheneOS – ne recevront ces correctifs supplémentaires qu’avec la mise à jour QPR2.

L’équipe précise bien qu’elle peut les fournir plus tôt en faisant de la rétro-ingénierie du code binaire. Elle prévient toutefois : si un correctif diffusé sous forme compilée est rétro-analysable en quelques jours, le système d’accès anticipé perd une grande part de sa justification.

Une période décidément complexe

La période n’est pas simple pour Graphene. Si le système est connu pour son positionnement strict sur la sécurité, elle a décidément maille à partir avec Google depuis les changements annoncés dans le rythme de parution des mises à jour et leur disponibilité.

Il y a quelques semaines, Graphene avait averti que le support des récents Pixel 11 allait s’avérer complexe. Déconseillant l’achat de ces derniers, l’équipe avait fustigé le choix de Google de ne plus intégrer la fonction MTE (marquage mémoire) dans ses téléphones, alors que Graphene s’en sert copieusement pour vérifier l’intégrité des données en mémoire. La situation a cependant évolué, l’équipe indiquant que la gestion du MTE peut être assurée de manière logicielle, au prix d’un surcoût de 5 % pour les performances générales. Surcoût qu’elle estime raisonnable au vu des enjeux. Pour l’équipe, le retrait de l’accélération matérielle dans le cache du processeur est un choix financier avant tout. Si elle parvient à un MTE pleinement fonctionnel, elle pourra annoncer le support des Pixel 11.

Les changements dans la gestion d’AOSP agacent donc. Il s’agit d’une conséquence lointaine d’une modification annoncée en novembre 2024 dans le rythme de parution des SDK (kits de développement). En janvier 2026, Google annonçait en effet qu’elle ne publierait plus le code d’AOSP que deux fois par an, pour aligner ses calendriers de développement. En d’autres termes, il s’agissait officiellement d’une simplification.

« À partir de 2026, pour nous aligner sur notre modèle de développement stable et garantir la stabilité de la plate-forme pour l’écosystème, nous publierons le code source sur AOSP aux deuxième et au quatrième trimestre. Pour créer et contribuer à AOSP, nous vous recommandons d’utiliser android-latest-release au lieu de aosp-main. La branche de fichier manifeste android-latest-release fera toujours référence à la version la plus récente envoyée à AOSP », prévenait alors Google.

Pourtant, l’entreprise avait précisé dans la foulée à Android Authority que ce nouveau rythme ne changerait a priori rien pour les correctifs de sécurité, affirmant qu’elle continuerait à les publier chaque mois « sur une branche dédiée uniquement à la sécurité pour les versions pertinentes […], tout comme elle le fait aujourd’hui ». Une belle assurance déjà contestée plusieurs mois avant par un autre système bâti sur AOSP, LineageOS.

Motorola attendu de pied ferme

En janvier, nous rappelions également que le développement d’Android était devenu totalement interne, avec pour conséquence un retard constant d’AOSP sur Android. Nous relevions alors que les Pixel allaient avoir un avantage logiciel sur les appareils concurrents et les ROM alternatives.

Dans son dernier fil, l’équipe de GrapheneOS mentionne aussi la concrétisation d’une de ses craintes : le code source du noyau n’étant plus disponible par simple téléchargement, le délai s’allonge pour le récupérer à cause d’un passage obligatoire par un formulaire. L’équipe le confirme dans l’un des messages, une requête pour obtenir ce code source le 1ᵉʳ septembre n’ayant abouti que le 17.

Désormais, le travail d’adaptation se concentre directement sur la version QPR1 d’Android 17, mais il faudra attendre la QPR2 en décembre pour diffuser une mise à jour, en se basant sur le code qui aura été effectivement publié dans AOSP. Jusqu’ici, le travail avance par rétro-ingénierie et tâtonnements.

Dans un message, l’équipe affirme une fois de plus que les futurs appareils Motorola seront plus simples à supporter que les Pixel, qui ont perdu un sérieux avantage (la situation ne change pas pour les anciennes gammes). Le reste dépendra de Qualcomm, qui a tendance à considérer la sécurité comme un luxe, la fonction MTE n’ayant été présente jusqu’ici que dans les puces les plus onéreuses. Chez GrapheneOS, on espère ainsi la voir arriver sur des modèles moins chers, afin que l’offre Motorola équipée du système puisse toucher le milieu de gamme.

Pour rappel, les premiers appareils de Motorola sous GrapheneOS sont attendus pour l’année prochaine, sans plus de précisions pour l’instant. Le premier appareil sera destiné au segment haut de gamme.

Don't be evil

L’équipe de GrapheneOS n’est pas contente. Le nouveau rythme de parution des mises à jour d’Android laisse le système alternatif sur le bord de la route un trimestre sur deux. Dans un fil sur les réseaux sociaux, elle explique les problèmes auxquels elle fait face.

« Android 17 QPR1 est la première version depuis Android Honeycomb (3.x) qui ajoute de nouvelles API pour les développeurs d’applications sans publication dans l’Android Open Source Project. Les nouvelles API sont actuellement exclusives à Pixel OS et ne sont pas disponibles pour les autres OEM Android », débute le fil de GrapheneOS sur X et Mastodon.

L’équipe dénonce une nouvelle fois les changements intervenus chez Google dans la parution des mises à jour pour Android. Dans les grandes lignes, elles ne sont plus reversées dans Android Open Source Project que durant le deuxième et le quatrième trimestres.

Deux gros reproches

L’agacement de l’équipe est palpable. Dans son fil, elle pointe surtout deux problèmes majeurs pour son propre fonctionnement.

D’une part, la disponibilité de la première QPR (Quarterly Platform Release) pour Android 17 montre la présence de nouvelles interfaces de programmation (API). Or, cette QPR1 n’est disponible que sur les propres appareils Pixel de Google. L’équipe de GrapheneOS indique qu’il ne s’agit pourtant pas d’API spécifiques aux Pixel : ce sont des interfaces Android standard, qui ne parviendront à l’AOSP et aux autres fabricants qu’en décembre 2026 avec Android 17 QPR2.

Selon l’équipe, c’est la première fois depuis l’ancienne version Honeycomb que Google ajoute ainsi des API sans les reverser immédiatement dans AOSP. Si Google répète le schéma, il pourrait donc y avoir six mois sur douze pendant lesquels les appareils Pixel seraient les seuls à profiter de ces interfaces.

D’autre part, comme on pouvait le prévoir, la question des correctifs de sécurité se pose. Le bulletin Pixel de septembre 2026 contient des correctifs supplémentaires qui touchent des composants standard de la plateforme Android, également employés par des appareils tiers. Pourtant, ces correctifs ne figurent pas au bulletin de sécurité Android du même mois, ni dans les correctifs communiqués en avance aux fabricants. En clair, les fabricants tiers et les systèmes alternatifs basés sur AOSP – dont GrapheneOS – ne recevront ces correctifs supplémentaires qu’avec la mise à jour QPR2.

L’équipe précise bien qu’elle peut les fournir plus tôt en faisant de la rétro-ingénierie du code binaire. Elle prévient toutefois : si un correctif diffusé sous forme compilée est rétro-analysable en quelques jours, le système d’accès anticipé perd une grande part de sa justification.

Une période décidément complexe

La période n’est pas simple pour Graphene. Si le système est connu pour son positionnement strict sur la sécurité, elle a décidément maille à partir avec Google depuis les changements annoncés dans le rythme de parution des mises à jour et leur disponibilité.

Il y a quelques semaines, Graphene avait averti que le support des récents Pixel 11 allait s’avérer complexe. Déconseillant l’achat de ces derniers, l’équipe avait fustigé le choix de Google de ne plus intégrer la fonction MTE (marquage mémoire) dans ses téléphones, alors que Graphene s’en sert copieusement pour vérifier l’intégrité des données en mémoire. La situation a cependant évolué, l’équipe indiquant que la gestion du MTE peut être assurée de manière logicielle, au prix d’un surcoût de 5 % pour les performances générales. Surcoût qu’elle estime raisonnable au vu des enjeux. Pour l’équipe, le retrait de l’accélération matérielle dans le cache du processeur est un choix financier avant tout. Si elle parvient à un MTE pleinement fonctionnel, elle pourra annoncer le support des Pixel 11.

Les changements dans la gestion d’AOSP agacent donc. Il s’agit d’une conséquence lointaine d’une modification annoncée en novembre 2024 dans le rythme de parution des SDK (kits de développement). En janvier 2026, Google annonçait en effet qu’elle ne publierait plus le code d’AOSP que deux fois par an, pour aligner ses calendriers de développement. En d’autres termes, il s’agissait officiellement d’une simplification.

« À partir de 2026, pour nous aligner sur notre modèle de développement stable et garantir la stabilité de la plate-forme pour l’écosystème, nous publierons le code source sur AOSP aux deuxième et au quatrième trimestre. Pour créer et contribuer à AOSP, nous vous recommandons d’utiliser android-latest-release au lieu de aosp-main. La branche de fichier manifeste android-latest-release fera toujours référence à la version la plus récente envoyée à AOSP », prévenait alors Google.

Pourtant, l’entreprise avait précisé dans la foulée à Android Authority que ce nouveau rythme ne changerait a priori rien pour les correctifs de sécurité, affirmant qu’elle continuerait à les publier chaque mois « sur une branche dédiée uniquement à la sécurité pour les versions pertinentes […], tout comme elle le fait aujourd’hui ». Une belle assurance déjà contestée plusieurs mois avant par un autre système bâti sur AOSP, LineageOS.

Motorola attendu de pied ferme

En janvier, nous rappelions également que le développement d’Android était devenu totalement interne, avec pour conséquence un retard constant d’AOSP sur Android. Nous relevions alors que les Pixel allaient avoir un avantage logiciel sur les appareils concurrents et les ROM alternatives.

Dans son dernier fil, l’équipe de GrapheneOS mentionne aussi la concrétisation d’une de ses craintes : le code source du noyau n’étant plus disponible par simple téléchargement, le délai s’allonge pour le récupérer à cause d’un passage obligatoire par un formulaire. L’équipe le confirme dans l’un des messages, une requête pour obtenir ce code source le 1ᵉʳ septembre n’ayant abouti que le 17.

Désormais, le travail d’adaptation se concentre directement sur la version QPR1 d’Android 17, mais il faudra attendre la QPR2 en décembre pour diffuser une mise à jour, en se basant sur le code qui aura été effectivement publié dans AOSP. Jusqu’ici, le travail avance par rétro-ingénierie et tâtonnements.

Dans un message, l’équipe affirme une fois de plus que les futurs appareils Motorola seront plus simples à supporter que les Pixel, qui ont perdu un sérieux avantage (la situation ne change pas pour les anciennes gammes). Le reste dépendra de Qualcomm, qui a tendance à considérer la sécurité comme un luxe, la fonction MTE n’ayant été présente jusqu’ici que dans les puces les plus onéreuses. Chez GrapheneOS, on espère ainsi la voir arriver sur des modèles moins chers, afin que l’offre Motorola équipée du système puisse toucher le milieu de gamme.

Pour rappel, les premiers appareils de Motorola sous GrapheneOS sont attendus pour l’année prochaine, sans plus de précisions pour l’instant. Le premier appareil sera destiné au segment haut de gamme.

Dans un billet, le développeur principal de Linux Mint, Clément Lefebvre, annonce plusieurs nouveautés, dont la création d’un site dédié aux XApp. Ces dernières sont initialement les applications prévues pour Linux Mint, en reprenant une organisation et une esthétique communes. Le projet a évolué au-delà de Mint depuis et la suite application a maintenant son propre site pour en présenter les tenants et aboutissants.

Le développeur évoque ensuite les changements dans ces applications. À commencer par Thingy (Bibliothèque), qui avait bien besoin d’un nouveau design. L’outil, qui sert à réunir les documents de l’utilisateur au même endroit, change de présentation. Elle troque la répartition par application pour un tri par type de fichiers. « Peu importe désormais quelles applications sont installées ni quels formats elles supportent », précise Clément Lefebvre. L’application dispose également d’une barre latérale fournissant des catégories personnalisables.

Xepub est de son côté une liseuse destinée aux fichiers EPUB. Selon le développeur, l’expérience de lecture est faite pour ressembler à une liseuse Kindle ou Kobo. À ceci près que cette lecture se fera sur un écran classique, plus fatiguant pour les yeux qu’un appareil e-ink. L’application permettra la navigation entre chapitres, la recherche dans le contenu, l’ajout de favoris, la reprise à l’endroit précédent, ou encore un accès à la recherche via clic droit sur un mot sélectionné.

Clockenstein, lui, va remplacer le vieillissant Calendrier présent dans l’application, qui provient d’une ère GNOME avant la grande bascule vers GTK4. La nouvelle application gardera le nom « Calendrier » dans Linux Mint et veut afficher plus clairement l’état des données. L’un des objectifs est de faire comprendre quand un calendrier en ligne n’est pas disponible. L’application affichera ainsi les évènements liés en lecture seule. Elle dispose également de son propre service (daemon) et de son propre agent de notification, qui fonctionnent donc même quand l’application est fermée. Les autres applications pourront communiquer avec le nouveau Calendrier via de nouvelles API.

Ces nouveautés sont en préparation pour Linux Mint 23. Cette version du système est attendue pour la fin de l’année et constituera un saut technique important. La distribution ne se base en effet que sur les moutures LTS d’Ubuntu. Linux Mint 23 ainsi sera la première version à prendre appui sur Ubuntu 26.04, sortie plus tôt dans l’année.

Dans un billet, le développeur principal de Linux Mint, Clément Lefebvre, annonce plusieurs nouveautés, dont la création d’un site dédié aux XApp. Ces dernières sont initialement les applications prévues pour Linux Mint, en reprenant une organisation et une esthétique communes. Le projet a évolué au-delà de Mint depuis et la suite application a maintenant son propre site pour en présenter les tenants et aboutissants.

Le développeur évoque ensuite les changements dans ces applications. À commencer par Thingy (Bibliothèque), qui avait bien besoin d’un nouveau design. L’outil, qui sert à réunir les documents de l’utilisateur au même endroit, change de présentation. Elle troque la répartition par application pour un tri par type de fichiers. « Peu importe désormais quelles applications sont installées ni quels formats elles supportent », précise Clément Lefebvre. L’application dispose également d’une barre latérale fournissant des catégories personnalisables.

Xepub est de son côté une liseuse destinée aux fichiers EPUB. Selon le développeur, l’expérience de lecture est faite pour ressembler à une liseuse Kindle ou Kobo. À ceci près que cette lecture se fera sur un écran classique, plus fatiguant pour les yeux qu’un appareil e-ink. L’application permettra la navigation entre chapitres, la recherche dans le contenu, l’ajout de favoris, la reprise à l’endroit précédent, ou encore un accès à la recherche via clic droit sur un mot sélectionné.

Clockenstein, lui, va remplacer le vieillissant Calendrier présent dans l’application, qui provient d’une ère GNOME avant la grande bascule vers GTK4. La nouvelle application gardera le nom « Calendrier » dans Linux Mint et veut afficher plus clairement l’état des données. L’un des objectifs est de faire comprendre quand un calendrier en ligne n’est pas disponible. L’application affichera ainsi les évènements liés en lecture seule. Elle dispose également de son propre service (daemon) et de son propre agent de notification, qui fonctionnent donc même quand l’application est fermée. Les autres applications pourront communiquer avec le nouveau Calendrier via de nouvelles API.

Ces nouveautés sont en préparation pour Linux Mint 23. Cette version du système est attendue pour la fin de l’année et constituera un saut technique important. La distribution ne se base en effet que sur les moutures LTS d’Ubuntu. Linux Mint 23 ainsi sera la première version à prendre appui sur Ubuntu 26.04, sortie plus tôt dans l’année.

Agents en vadrouille

Dans une nouvelle publication, OpenAI évoque de nouveaux engagements sur sa manière de communiquer. L’entreprise promet ainsi de publier systématiquement des rapports quand la situation l’exigera, pour remédier à son irrégularité. Elle commence avec six nouveaux exemples d’agents dont le « comportement » a dérapé.

Dans son billet du 16 septembre, OpenAI reconnait qu’elle manquait jusqu’ici d’une « approche systématique » pour rapporter les résultats des enquêtes menées sur les cas de désalignement. « Nous avons souvent attendu de pouvoir rassembler plusieurs instances dans un seul rapport, ou de les ajouter à des cartes système pour des modèles nouvellement publiés », indique l’entreprise.

Le narratif continue sur le cadre industriel

Selon OpenAI, le degré d’avancement et l’utilisation plus intensive des agents nécessitent la mise en place d’un « consensus plus large et mieux informé ». Le ton est le même que dans les récentes interventions sur la nécessité de ralentir le développement des modèles frontière : « Nous ne pensons pas que l’industrie de l’IA ait suffisamment résolu l’alignement et la surveillance pour continuer plus longtemps d’évoluer de manière responsable à vitesse maximale ». Dans ce registre, OpenAI persiste et signe.

• Anthropic, OpenAI et Elon Musk veulent ralentir sur l’IA, la Maison-Blanche dit non

Il s’agit, pour l’entreprise, de simplement mieux communiquer. Elle affirme que des exemples de désalignement peuvent « aider à identifier les problèmes que d’autres développeurs d’IA pourraient rencontrer lorsque leurs systèmes atteignent des capacités similaires, révèlent des faiblesses dans les mesures de sécurité ou remettent en question les hypothèses sur le comportement du modèle ». L’entreprise veut se montrer responsable en montrant aux autres les problèmes qu’elle a elle-même rencontrés.

Regrettant qu’aucun cadre industriel n’existe sur la manière dont les développeurs devraient communiquer, elle propose donc le sien, à travers six exemples. Ce cadre est considéré comme « un travail en cours », ajoute la société. De manière générale, elle promet qu’elle relatera tous les exemples qui lui paraissent pertinents, notamment quand ils constituent « des preuves utiles sur la manière dont survient le désalignement du modèle ». OpenAI précise cependant qu’un exemple « n’a pas besoin de causer de préjudice » pour justifier sa publication.

Sorties de route pendant l’entrainement

Le premier exemple est celui d’un modèle interne de la famille Astra (dont GPT-6). Pendant l’entraînement, il a glissé des instructions parasites dans les résumés qui lui servent à poursuivre une tâche dans un nouveau contexte. Entre autres actions, il a laissé un message pour informer qu’il ne fallait plus tenir compte des messages du développeur, prétendument compromis. Dans un autre, il « s’estimait » affranchi de toute obligation envers les entreprises et gouvernements. Dans un résumé, il s’est laissé une instruction pour ne plus dépasser à l’avenir les 30 mots dans ses réponses, tout en interdisant les outils citations. L’instruction a été suivie par un autre agent. OpenAI dit avoir trouvé la cause, depuis corrigée. Elle ajoute que ce comportement est « extrêmement rare », sans avantage évident en termes de récompense.

Dans le deuxième exemple, également pendant l’entraînement (de GPT-5.6 cette fois), des instances se sont laissé des instructions dans leurs résumés pour masquer des erreurs ou des comportements montrant un désalignement. Une instance a ainsi proposé d’inventer des données historiques manquantes et de ne l’avouer qu’en cas de demande. Une autre recommandait de taire une incohérence entre versions de sources. Selon OpenAI, l’explication est simple : puisqu’une réponse finale trompeuse obtenait une meilleure réponse, le modèle a appris à s’en « souvenir » pour la suite. Ce type de comportement a été détecté dans 2,15 % des résumés de GPT-5.6 Sol et dans 0,27 % de ceux d’Astra. Ces chiffres ne sont pas anodins : ils correspondent à la situation actuelle, après réduction du problème, de l’aveu même d’OpenAI.

Dans le troisième exemple, le problème est parti d’une « question de routine » sur les revenus masculins dans trois secteurs d’activité d’un comté de Californie. Parmi les tâches entreprises, le modèle a tenté de s’inscrire sur un site avec une adresse jetable, a fouillé des dépôts GitHub publics et testé automatiquement des clés API, dont une a fonctionné. Puis, en voyant qu’il ne parvenait pas au résultat souhaité, il a inventé neuf valeurs et affirmé les avoir relevées sur le site demandé. OpenAI indique que cette session d’entraînement était particulièrement riche en cas de tricherie, avec des comportements équivalents.

Gofile concerné dans l’un des exemples

Dans le quatrième exemple, OpenAI évoque le cas d’un agent qui devait répondre à une question sur les identifiants et noms de tous les lacs plus grands que 5 000 000 m². La réponse a été obtenue via Python, mais puisque la réponse exigeait une citation provenant du navigateur, l’agent a déposé ses données sur un service de partage sans demander l’autorisation. Le navigateur a refusé l’adresse, et la réponse a finalement indiqué l’origine réelle des données.

Le cinquième exemple est une copie quasi-conforme de celui exposé pour Hugging Face : des modèles se sont servis du dépôt interne de paquets logiciels (Artifactory) comme d’un tableau d’affichage. Ils lisaient les notes d’autres agents travaillant sur le même problème et y répondaient. Dans un cas précédent, un agent bloqué par le filtrage réseau a vérifié qu’il pouvait écrire dans le dépôt. Il a ensuite envisagé un paquet malveillant pour faire récupérer un contenu interdit par le serveur. Faute de droits administrateur, la tentative a échoué, selon OpenAI.

Enfin, le dernier exemple relève comment des agents ont partagé des fichiers sur un hébergeur public pour répondre à la mission de produire collaborativement un tableau. Une action menée pour contourner un souci de fonctionnement du système prévu pour les partages de fichiers. Les liens des fichiers hébergés ont été transmis alors que la tâche imposait des fichiers locaux. Selon OpenAI, ce résultat provient de l’effet combiné d’environnements multi-agents défectueux et d’une généralisation de l’entraînement à la collaboration. Depuis ce test, l’accès internet direct est coupé pour les entrainements. Du moins, il est censé l’être.

Selon nos informations, l’hébergeur en question est Gofile. Nory Wojdyla, son fondateur, nous confirme avoir été contacté par OpenAI au sujet de cet incident, pour prévenir qu’un rapport en serait tiré. « Cela fait des mois que l’on constate que des données confidentielles de grosses entreprises finissent chez Gofile de façon non contrôlée par le biais d’agents », indique-t-il. Il n’a pas donné de noms, mais pointe le changement d’échelle, notant qu’il « arrive que les agents sortent de leurs instructions et prennent des libertés ».

Un cadre qui n’impose rien

La publication d’OpenAI intervient dans un calendrier aussi spécifique que sensible. L’industrie américaine réclame un ralentissement du développement des modèles frontières, arguant notamment que la puissance des agents mérite que l’on prenne le temps de la réflexion. Comme nous l’avons vu, les rapports ont surtout illustré des défaillances internes et de curieux choix d’enquêteurs pour des rapports indépendants. En outre, en dépit de mots forts sur X et d’une entente entre les entreprises américaines, leurs dépenses disent le contraire. À la Maison-Blanche, Donald Trump goûte peu l’idée.

En plus de nourrir le narratif sur le danger des agents et les risques d’extinction pour l’humanité, il pourrait s’agir pour OpenAI d’une manière de reprendre la main sur le récit. Début septembre, plusieurs cas ont été rapportés d’agents ayant encore une fois pris des libertés, notamment contre un wiki allemand dédié aux développeurs. La presse s’est emparée de l’histoire avant OpenAI.

Dans un contexte sous pression, OpenAI cherche également à rassurer, tout en fixant lui-même un cadre avant qu’on ne le lui impose éventuellement. Et pour cause : plusieurs sénateurs semblent décidés à éclaircir la réalité du danger et ont envoyé des questions précises à OpenAI, notamment sur Astra, comme le rapporte Zvi Mowshowitz, souvent critique à l’égard d’OpenAI.

Si personne ne se plaindra dans l’absolu d’informations complémentaires, la dichotomie observée depuis plusieurs mois autour des agents continue de plus belle. OpenAI écrit ainsi que l’industrie n’a pas assez travaillé sur l’alignement et la surveillance, tout en commercialisant Astra. Enfin, OpenAI ne s’est engagé sur aucun rythme de parution pour ces rapports.

Agents en vadrouille

Dans une nouvelle publication, OpenAI évoque de nouveaux engagements sur sa manière de communiquer. L’entreprise promet ainsi de publier systématiquement des rapports quand la situation l’exigera, pour remédier à son irrégularité. Elle commence avec six nouveaux exemples d’agents dont le « comportement » a dérapé.

Dans son billet du 16 septembre, OpenAI reconnait qu’elle manquait jusqu’ici d’une « approche systématique » pour rapporter les résultats des enquêtes menées sur les cas de désalignement. « Nous avons souvent attendu de pouvoir rassembler plusieurs instances dans un seul rapport, ou de les ajouter à des cartes système pour des modèles nouvellement publiés », indique l’entreprise.

Le narratif continue sur le cadre industriel

Selon OpenAI, le degré d’avancement et l’utilisation plus intensive des agents nécessitent la mise en place d’un « consensus plus large et mieux informé ». Le ton est le même que dans les récentes interventions sur la nécessité de ralentir le développement des modèles frontière : « Nous ne pensons pas que l’industrie de l’IA ait suffisamment résolu l’alignement et la surveillance pour continuer plus longtemps d’évoluer de manière responsable à vitesse maximale ». Dans ce registre, OpenAI persiste et signe.

• Anthropic, OpenAI et Elon Musk veulent ralentir sur l’IA, la Maison-Blanche dit non

Il s’agit, pour l’entreprise, de simplement mieux communiquer. Elle affirme que des exemples de désalignement peuvent « aider à identifier les problèmes que d’autres développeurs d’IA pourraient rencontrer lorsque leurs systèmes atteignent des capacités similaires, révèlent des faiblesses dans les mesures de sécurité ou remettent en question les hypothèses sur le comportement du modèle ». L’entreprise veut se montrer responsable en montrant aux autres les problèmes qu’elle a elle-même rencontrés.

Regrettant qu’aucun cadre industriel n’existe sur la manière dont les développeurs devraient communiquer, elle propose donc le sien, à travers six exemples. Ce cadre est considéré comme « un travail en cours », ajoute la société. De manière générale, elle promet qu’elle relatera tous les exemples qui lui paraissent pertinents, notamment quand ils constituent « des preuves utiles sur la manière dont survient le désalignement du modèle ». OpenAI précise cependant qu’un exemple « n’a pas besoin de causer de préjudice » pour justifier sa publication.

Sorties de route pendant l’entrainement

Le premier exemple est celui d’un modèle interne de la famille Astra (dont GPT-6). Pendant l’entraînement, il a glissé des instructions parasites dans les résumés qui lui servent à poursuivre une tâche dans un nouveau contexte. Entre autres actions, il a laissé un message pour informer qu’il ne fallait plus tenir compte des messages du développeur, prétendument compromis. Dans un autre, il « s’estimait » affranchi de toute obligation envers les entreprises et gouvernements. Dans un résumé, il s’est laissé une instruction pour ne plus dépasser à l’avenir les 30 mots dans ses réponses, tout en interdisant les outils citations. L’instruction a été suivie par un autre agent. OpenAI dit avoir trouvé la cause, depuis corrigée. Elle ajoute que ce comportement est « extrêmement rare », sans avantage évident en termes de récompense.

Dans le deuxième exemple, également pendant l’entraînement (de GPT-5.6 cette fois), des instances se sont laissé des instructions dans leurs résumés pour masquer des erreurs ou des comportements montrant un désalignement. Une instance a ainsi proposé d’inventer des données historiques manquantes et de ne l’avouer qu’en cas de demande. Une autre recommandait de taire une incohérence entre versions de sources. Selon OpenAI, l’explication est simple : puisqu’une réponse finale trompeuse obtenait une meilleure réponse, le modèle a appris à s’en « souvenir » pour la suite. Ce type de comportement a été détecté dans 2,15 % des résumés de GPT-5.6 Sol et dans 0,27 % de ceux d’Astra. Ces chiffres ne sont pas anodins : ils correspondent à la situation actuelle, après réduction du problème, de l’aveu même d’OpenAI.

Dans le troisième exemple, le problème est parti d’une « question de routine » sur les revenus masculins dans trois secteurs d’activité d’un comté de Californie. Parmi les tâches entreprises, le modèle a tenté de s’inscrire sur un site avec une adresse jetable, a fouillé des dépôts GitHub publics et testé automatiquement des clés API, dont une a fonctionné. Puis, en voyant qu’il ne parvenait pas au résultat souhaité, il a inventé neuf valeurs et affirmé les avoir relevées sur le site demandé. OpenAI indique que cette session d’entraînement était particulièrement riche en cas de tricherie, avec des comportements équivalents.

Gofile concerné dans l’un des exemples

Dans le quatrième exemple, OpenAI évoque le cas d’un agent qui devait répondre à une question sur les identifiants et noms de tous les lacs plus grands que 5 000 000 m². La réponse a été obtenue via Python, mais puisque la réponse exigeait une citation provenant du navigateur, l’agent a déposé ses données sur un service de partage sans demander l’autorisation. Le navigateur a refusé l’adresse, et la réponse a finalement indiqué l’origine réelle des données.

Le cinquième exemple est une copie quasi-conforme de celui exposé pour Hugging Face : des modèles se sont servis du dépôt interne de paquets logiciels (Artifactory) comme d’un tableau d’affichage. Ils lisaient les notes d’autres agents travaillant sur le même problème et y répondaient. Dans un cas précédent, un agent bloqué par le filtrage réseau a vérifié qu’il pouvait écrire dans le dépôt. Il a ensuite envisagé un paquet malveillant pour faire récupérer un contenu interdit par le serveur. Faute de droits administrateur, la tentative a échoué, selon OpenAI.

Enfin, le dernier exemple relève comment des agents ont partagé des fichiers sur un hébergeur public pour répondre à la mission de produire collaborativement un tableau. Une action menée pour contourner un souci de fonctionnement du système prévu pour les partages de fichiers. Les liens des fichiers hébergés ont été transmis alors que la tâche imposait des fichiers locaux. Selon OpenAI, ce résultat provient de l’effet combiné d’environnements multi-agents défectueux et d’une généralisation de l’entraînement à la collaboration. Depuis ce test, l’accès internet direct est coupé pour les entrainements. Du moins, il est censé l’être.

Selon nos informations, l’hébergeur en question est Gofile. Nory Wojdyla, son fondateur, nous confirme avoir été contacté par OpenAI au sujet de cet incident, pour prévenir qu’un rapport en serait tiré. « Cela fait des mois que l’on constate que des données confidentielles de grosses entreprises finissent chez Gofile de façon non contrôlée par le biais d’agents », indique-t-il. Il n’a pas donné de noms, mais pointe le changement d’échelle, notant qu’il « arrive que les agents sortent de leurs instructions et prennent des libertés ».

Un cadre qui n’impose rien

La publication d’OpenAI intervient dans un calendrier aussi spécifique que sensible. L’industrie américaine réclame un ralentissement du développement des modèles frontières, arguant notamment que la puissance des agents mérite que l’on prenne le temps de la réflexion. Comme nous l’avons vu, les rapports ont surtout illustré des défaillances internes et de curieux choix d’enquêteurs pour des rapports indépendants. En outre, en dépit de mots forts sur X et d’une entente entre les entreprises américaines, leurs dépenses disent le contraire. À la Maison-Blanche, Donald Trump goûte peu l’idée.

En plus de nourrir le narratif sur le danger des agents et les risques d’extinction pour l’humanité, il pourrait s’agir pour OpenAI d’une manière de reprendre la main sur le récit. Début septembre, plusieurs cas ont été rapportés d’agents ayant encore une fois pris des libertés, notamment contre un wiki allemand dédié aux développeurs. La presse s’est emparée de l’histoire avant OpenAI.

Dans un contexte sous pression, OpenAI cherche également à rassurer, tout en fixant lui-même un cadre avant qu’on ne le lui impose éventuellement. Et pour cause : plusieurs sénateurs semblent décidés à éclaircir la réalité du danger et ont envoyé des questions précises à OpenAI, notamment sur Astra, comme le rapporte Zvi Mowshowitz, souvent critique à l’égard d’OpenAI.

Si personne ne se plaindra dans l’absolu d’informations complémentaires, la dichotomie observée depuis plusieurs mois autour des agents continue de plus belle. OpenAI écrit ainsi que l’industrie n’a pas assez travaillé sur l’alignement et la surveillance, tout en commercialisant Astra. Enfin, OpenAI ne s’est engagé sur aucun rythme de parution pour ces rapports.

Plus de corrections, plus de régressions ?

Les dernières mises à jour de sécurité avaient une ampleur jamais vue. Elles ont entraîné dans leur sillage bon nombre de régressions, forçant Microsoft à publier des correctifs sans attendre le mois prochain. Malgré ces réparations, d’autres problèmes restent ouverts, notamment dans Excel et Active Directory.

Le Patch Tuesday de septembre 2026 a établi un nouveau record chez Microsoft. En frôlant le millier de failles corrigées, l’éditeur a montré les résultats concrets de sa traque boostée à l’IA, notamment son harnais MDASH et son infrastructure Perception. La firme l’avait assuré : elle pouvait détecter plus de failles dans le code que n’importe qui. Des failles, elle en a trouvé à un rythme effréné depuis juin, chaque bulletin mensuel corrigeant des centaines de vulnérabilités.

• Patch Tuesday : Microsoft frôle le millier de correctifs

Nous nous étions cependant posé la question : si la correction d’un nombre croissant implique une augmentation nette des modifications dans le code, ne risque-t-elle pas d’entrainer des régressions ? Par régressions, on entend les problèmes provoqués par ces modifications, qui font apparaitre un bug ou cassent un élément qui fonctionnait jusque-là. En clair, un effet secondaire imprévu que les tests de qualité (QA) n’ont pas détecté.

Or, le dernier Patch Tuesday a provoqué bon nombre de ces régressions.

Deux gros problèmes vite résolus

Il a fallu à Microsoft publier en urgence un correctif (KB5129195) pour rétablir plusieurs fonctions cassées. Ces publications hors cycle (hors du cycle mensuel) sont rares et réservées aux situations qui l’exigent. Le mécanisme est plus souvent utilisé pour le colmatage d’une brèche de sécurité que pour réparer des fonctions, signe que la situation dérapait.

Le 14 septembre, la mise à jour a ainsi réparé de sérieux problèmes avec les services de bureau à distance (RDS). Selon Bleeping Computer, les entreprises ont signalé des serveurs RDS qui fonctionnaient quelques heures (voire moins) avant que les connexions échouent. Les sessions existantes ne se fermaient plus correctement et, dans certains cas, seul un redémarrage forcé rétablissait le service. Le problème a été corrigé dans la mise à jour du 14 septembre. Mieux valait d’ailleurs que Microsoft s’en occupe rapidement, car certains administrateurs finissaient par désinstaller la mise à jour fautive, alors qu’elle corrigeait une faille critique (CVSS 9,8) dans RDS.

Parmi les autres problèmes corrigés, on trouve un partage inopérant de dossier vers les machines virtuelles Linux gérées par HCS. Le souci se produit quand Plan9 est utilisé sur un hôte Windows, provoquant un effet boule de neige dans plusieurs scénarios, dont le sous-système Linux (WSL) et Claude Cowork. Les machines Hyper-V classiques ne sont pas concernées si elles n’utilisent pas Plan9.

En revanche, une partie des erreurs rencontrées par les utilisateurs n’a pas encore de solution complète.

Connexions aux domaines et périphériques audio USB

L’un des bugs les plus pénibles est lié à la gestion du son dans Windows : certains périphériques audio USB deviennent inutilisables. Microsoft évoque l’absence de son, l’impossibilité de modifier le volume sur le système ainsi que des paramètres audio inaccessibles. Le problème est centré sur les fonctions multicanaux.

La mise à jour du 14 septembre ne répare que partiellement la situation. Les modes audio 8 canaux et 3D sont restaurés, mais d’autres périphériques ne fonctionnent toujours pas, relève Windows Latest. Selon nos confrères, certains microphones sont également concernés.

Autre fonction cassée le 8 septembre avec le Patch Tuesday, la perte d’approbation avec le domaine en entreprise avec des comptes protégés par Credential Guard. Le symptôme est un message d’erreur signalant que la relation de confiance a été rompue entre la machine et le domaine Active Directory.

Dans ses notes, Microsoft indique que l’origine du problème a été trouvée : depuis le Patch Tuesday, les mises à jour activent la fonction d’isolation de l’identité de la machine. « Cependant, cette fonctionnalité n’est prise en charge que pour les environnements connectés à des contrôleurs de domaine fonctionnant à un niveau fonctionnel de domaine (DFL) de Windows Server 2025 et supérieur. La fonctionnalité devrait être désactivée ailleurs », indique Microsoft.

Cette situation n’est actuellement pas résolue par une mise à jour. Elle est en revanche atténuée par une procédure consistant à désactiver l’isolation de l’identité machine, en utilisant la même méthode que pour l’activer : soit par Intune, soit par une stratégie de groupe, soit manuellement dans le registre.

Si la formulation de Microsoft laisse penser que les administrateurs sont « fautifs », plusieurs ont remonté à Bleeping Computer et IT-Connect des cas de bascule automatique sur la fonction avec la mise à jour du 8 septembre. En outre, Neowin relève que la désactivation de l’isolation après coup peut casser l’authentification et imposer de sortir puis réintégrer le poste au domaine. Ce qui explique peut-être pourquoi le problème est en statut « Mitigated » et pas « Resolved » sur la page consacrée aux problèmes.

Et le reste ?

Il ne s’agit là que des problèmes directement abordés par Microsoft. Windows Latest a dressé une liste d’autres symptômes remontés par les utilisateurs. Nos confrères expliquent ainsi avoir reçu des rapports sur des plantages continus d’Explorer.exe juste après la connexion, « laissant certains PC bloqués sur un écran noir sans bureau ou barre des tâches fonctionnelles ». Il semble que les machines concernées soient en entreprise, avec des produits comme Citrix UPM, FSLogix, Horizon ou ProfileUnity ProfileDisks sur les configurations. Un simple redémarrage d’Explorer.exe via le Gestionnaire des tâches suffirait à contourner le problème.

Autre fonction a priori cassée : l’Historique de fichiers. C’est une vieille capacité introduite par Windows 8 et qui permet la sauvegarde de plusieurs versions des fichiers vers un périphérique externe de stockage (l’opération n’est pas disponible sur le disque interne). Même si Windows 11 met largement l’accent sur le cloud (via OneDrive) et masque la fonction (on peut la trouver en écrivant « Historique » dans le menu Démarrer), Historique reste là.

Problème, la mise à jour du 8 septembre rend la fonction inexploitable. Chez une partie des utilisateurs, Historique ne parvient plus à détecter les disques externes, même quand il s’agit de ceux déjà utilisés pour la sauvegarde.

Windows Latest pointe également des bugs potentiels avec les GPU AMD. Des joueurs ont signalé des écrans noirs et des gels du système après l’installation de la mise à jour, mais toujours en dehors des jeux. Un fil sur Reddit mentionne une expiration du pilote GPU sans changement récent de ce dernier. Des configurations à base de Radeon RX 6600, RX 7700 XT, RX 7800 XT, RX 7900 GRE, RX 7900 XTX et RX 7900 XT ont été mentionnées.

On note aussi un bug gênant dans Excel : sur certaines machines, quand on copie une cellule et que l’on cherche à la coller dans une autre (dans le même tableau ou non), l’opération n’aboutit pas. Le bug semble se produire avec les séries incrémentées automatiquement quand on fait glisser l’ancrage à la souris. On peut contourner le problème en passant par la fonction Collage spécial. La désinstallation de la mise à jour n’est pas recommandée, à cause des correctifs de sécurité qu’elle contient (29 pour Excel).

Le nombre de régressions a-t-il augmenté ?

La question est délicate. En théorie, plus on intervient dans le code, plus les chances de régression augmentent. C’était vrai avant l’usage intensif des LLM, ça l’est toujours. Pour sa part, Microsoft a indiqué clairement que l’explosion du nombre de correctifs était directement imputable à son infrastructure de LLM. L’éditeur a prévenu que les mises à jour mensuelles corrigeraient ainsi un plus grand nombre de vulnérabilités. Selon Krebs on Security, Microsoft en est environ à 2 600 failles colmatées en tout depuis le début de 2026, soit le double de 2020, jusqu’ici l’année record avec ses 1 245 failles.

Cependant, Microsoft avait également précisé que les mêmes LLM servaient à augmenter les tests de régression. De fait, peut-on mettre les problèmes de cette rentrée sur le compte de cette utilisation massive ? Si l’hypothèse est « séduisante », elle n’est pas prouvée. CrowdStrike souligne par exemple qu’environ la moitié des failles corrigées le 8 septembre concernent des élévations de privilège, dont les correctifs impliquent généralement de resserrer les contrôles. Un processus pouvant effectivement engendrer des effets dans des scénarios peu ou pas testés.

En outre, les bugs engendrés par des mises à jour mensuelles n’ont rien de nouveau. En janvier 2018 par exemple, les correctifs publiés pour les failles Meltdown et Spectre rendaient certaines configurations AMD incapables de démarrer. Quatre ans plus tard, les corrections de janvier 2022 avaient créé de gros problèmes en entreprises, avec des redémarrages en boucle de contrôleurs de domaines et des volumes ReFS inaccessibles.

Si l’usage des LLM augmente mathématiquement les modifications dans le code, l’historique de Microsoft montre que ces problèmes peuvent surgir n’importe quand. Certaines mises à jour majeures, dont les versions H2 sortant à l’automne, sont connues pour créer de nombreuses incompatibilités. Contrairement aux correctifs mensuels cependant, l’entreprise ne les diffuse que petit à petit, au fur et à mesure qu’elle reçoit des signalements et écarte les PC présentant des configurations (matérielles et/ou logicielles) problématiques, jusqu’à ce que les bugs soient résolus.

On manque encore de recul pour établir des statistiques fiables. Pour l’instant, on peut simplement observer que l’historique a montré des régressions tout aussi graves avec des volumes de correctifs bien plus faibles.

Plus de corrections, plus de régressions ?

Les dernières mises à jour de sécurité avaient une ampleur jamais vue. Elles ont entraîné dans leur sillage bon nombre de régressions, forçant Microsoft à publier des correctifs sans attendre le mois prochain. Malgré ces réparations, d’autres problèmes restent ouverts, notamment dans Excel et Active Directory.

Le Patch Tuesday de septembre 2026 a établi un nouveau record chez Microsoft. En frôlant le millier de failles corrigées, l’éditeur a montré les résultats concrets de sa traque boostée à l’IA, notamment son harnais MDASH et son infrastructure Perception. La firme l’avait assuré : elle pouvait détecter plus de failles dans le code que n’importe qui. Des failles, elle en a trouvé à un rythme effréné depuis juin, chaque bulletin mensuel corrigeant des centaines de vulnérabilités.

• Patch Tuesday : Microsoft frôle le millier de correctifs

Nous nous étions cependant posé la question : si la correction d’un nombre croissant implique une augmentation nette des modifications dans le code, ne risque-t-elle pas d’entrainer des régressions ? Par régressions, on entend les problèmes provoqués par ces modifications, qui font apparaitre un bug ou cassent un élément qui fonctionnait jusque-là. En clair, un effet secondaire imprévu que les tests de qualité (QA) n’ont pas détecté.

Or, le dernier Patch Tuesday a provoqué bon nombre de ces régressions.

Deux gros problèmes vite résolus

Il a fallu à Microsoft publier en urgence un correctif (KB5129195) pour rétablir plusieurs fonctions cassées. Ces publications hors cycle (hors du cycle mensuel) sont rares et réservées aux situations qui l’exigent. Le mécanisme est plus souvent utilisé pour le colmatage d’une brèche de sécurité que pour réparer des fonctions, signe que la situation dérapait.

Le 14 septembre, la mise à jour a ainsi réparé de sérieux problèmes avec les services de bureau à distance (RDS). Selon Bleeping Computer, les entreprises ont signalé des serveurs RDS qui fonctionnaient quelques heures (voire moins) avant que les connexions échouent. Les sessions existantes ne se fermaient plus correctement et, dans certains cas, seul un redémarrage forcé rétablissait le service. Le problème a été corrigé dans la mise à jour du 14 septembre. Mieux valait d’ailleurs que Microsoft s’en occupe rapidement, car certains administrateurs finissaient par désinstaller la mise à jour fautive, alors qu’elle corrigeait une faille critique (CVSS 9,8) dans RDS.

Parmi les autres problèmes corrigés, on trouve un partage inopérant de dossier vers les machines virtuelles Linux gérées par HCS. Le souci se produit quand Plan9 est utilisé sur un hôte Windows, provoquant un effet boule de neige dans plusieurs scénarios, dont le sous-système Linux (WSL) et Claude Cowork. Les machines Hyper-V classiques ne sont pas concernées si elles n’utilisent pas Plan9.

En revanche, une partie des erreurs rencontrées par les utilisateurs n’a pas encore de solution complète.

Connexions aux domaines et périphériques audio USB

L’un des bugs les plus pénibles est lié à la gestion du son dans Windows : certains périphériques audio USB deviennent inutilisables. Microsoft évoque l’absence de son, l’impossibilité de modifier le volume sur le système ainsi que des paramètres audio inaccessibles. Le problème est centré sur les fonctions multicanaux.

La mise à jour du 14 septembre ne répare que partiellement la situation. Les modes audio 8 canaux et 3D sont restaurés, mais d’autres périphériques ne fonctionnent toujours pas, relève Windows Latest. Selon nos confrères, certains microphones sont également concernés.

Autre fonction cassée le 8 septembre avec le Patch Tuesday, la perte d’approbation avec le domaine en entreprise avec des comptes protégés par Credential Guard. Le symptôme est un message d’erreur signalant que la relation de confiance a été rompue entre la machine et le domaine Active Directory.

Dans ses notes, Microsoft indique que l’origine du problème a été trouvée : depuis le Patch Tuesday, les mises à jour activent la fonction d’isolation de l’identité de la machine. « Cependant, cette fonctionnalité n’est prise en charge que pour les environnements connectés à des contrôleurs de domaine fonctionnant à un niveau fonctionnel de domaine (DFL) de Windows Server 2025 et supérieur. La fonctionnalité devrait être désactivée ailleurs », indique Microsoft.

Cette situation n’est actuellement pas résolue par une mise à jour. Elle est en revanche atténuée par une procédure consistant à désactiver l’isolation de l’identité machine, en utilisant la même méthode que pour l’activer : soit par Intune, soit par une stratégie de groupe, soit manuellement dans le registre.

Si la formulation de Microsoft laisse penser que les administrateurs sont « fautifs », plusieurs ont remonté à Bleeping Computer et IT-Connect des cas de bascule automatique sur la fonction avec la mise à jour du 8 septembre. En outre, Neowin relève que la désactivation de l’isolation après coup peut casser l’authentification et imposer de sortir puis réintégrer le poste au domaine. Ce qui explique peut-être pourquoi le problème est en statut « Mitigated » et pas « Resolved » sur la page consacrée aux problèmes.

Et le reste ?

Il ne s’agit là que des problèmes directement abordés par Microsoft. Windows Latest a dressé une liste d’autres symptômes remontés par les utilisateurs. Nos confrères expliquent ainsi avoir reçu des rapports sur des plantages continus d’Explorer.exe juste après la connexion, « laissant certains PC bloqués sur un écran noir sans bureau ou barre des tâches fonctionnelles ». Il semble que les machines concernées soient en entreprise, avec des produits comme Citrix UPM, FSLogix, Horizon ou ProfileUnity ProfileDisks sur les configurations. Un simple redémarrage d’Explorer.exe via le Gestionnaire des tâches suffirait à contourner le problème.

Autre fonction a priori cassée : l’Historique de fichiers. C’est une vieille capacité introduite par Windows 8 et qui permet la sauvegarde de plusieurs versions des fichiers vers un périphérique externe de stockage (l’opération n’est pas disponible sur le disque interne). Même si Windows 11 met largement l’accent sur le cloud (via OneDrive) et masque la fonction (on peut la trouver en écrivant « Historique » dans le menu Démarrer), Historique reste là.

Problème, la mise à jour du 8 septembre rend la fonction inexploitable. Chez une partie des utilisateurs, Historique ne parvient plus à détecter les disques externes, même quand il s’agit de ceux déjà utilisés pour la sauvegarde.

Windows Latest pointe également des bugs potentiels avec les GPU AMD. Des joueurs ont signalé des écrans noirs et des gels du système après l’installation de la mise à jour, mais toujours en dehors des jeux. Un fil sur Reddit mentionne une expiration du pilote GPU sans changement récent de ce dernier. Des configurations à base de Radeon RX 6600, RX 7700 XT, RX 7800 XT, RX 7900 GRE, RX 7900 XTX et RX 7900 XT ont été mentionnées.

On note aussi un bug gênant dans Excel : sur certaines machines, quand on copie une cellule et que l’on cherche à la coller dans une autre (dans le même tableau ou non), l’opération n’aboutit pas. Le bug semble se produire avec les séries incrémentées automatiquement quand on fait glisser l’ancrage à la souris. On peut contourner le problème en passant par la fonction Collage spécial. La désinstallation de la mise à jour n’est pas recommandée, à cause des correctifs de sécurité qu’elle contient (29 pour Excel).

Le nombre de régressions a-t-il augmenté ?

La question est délicate. En théorie, plus on intervient dans le code, plus les chances de régression augmentent. C’était vrai avant l’usage intensif des LLM, ça l’est toujours. Pour sa part, Microsoft a indiqué clairement que l’explosion du nombre de correctifs était directement imputable à son infrastructure de LLM. L’éditeur a prévenu que les mises à jour mensuelles corrigeraient ainsi un plus grand nombre de vulnérabilités. Selon Krebs on Security, Microsoft en est environ à 2 600 failles colmatées en tout depuis le début de 2026, soit le double de 2020, jusqu’ici l’année record avec ses 1 245 failles.

Cependant, Microsoft avait également précisé que les mêmes LLM servaient à augmenter les tests de régression. De fait, peut-on mettre les problèmes de cette rentrée sur le compte de cette utilisation massive ? Si l’hypothèse est « séduisante », elle n’est pas prouvée. CrowdStrike souligne par exemple qu’environ la moitié des failles corrigées le 8 septembre concernent des élévations de privilège, dont les correctifs impliquent généralement de resserrer les contrôles. Un processus pouvant effectivement engendrer des effets dans des scénarios peu ou pas testés.

En outre, les bugs engendrés par des mises à jour mensuelles n’ont rien de nouveau. En janvier 2018 par exemple, les correctifs publiés pour les failles Meltdown et Spectre rendaient certaines configurations AMD incapables de démarrer. Quatre ans plus tard, les corrections de janvier 2022 avaient créé de gros problèmes en entreprises, avec des redémarrages en boucle de contrôleurs de domaines et des volumes ReFS inaccessibles.

Si l’usage des LLM augmente mathématiquement les modifications dans le code, l’historique de Microsoft montre que ces problèmes peuvent surgir n’importe quand. Certaines mises à jour majeures, dont les versions H2 sortant à l’automne, sont connues pour créer de nombreuses incompatibilités. Contrairement aux correctifs mensuels cependant, l’entreprise ne les diffuse que petit à petit, au fur et à mesure qu’elle reçoit des signalements et écarte les PC présentant des configurations (matérielles et/ou logicielles) problématiques, jusqu’à ce que les bugs soient résolus.

On manque encore de recul pour établir des statistiques fiables. Pour l’instant, on peut simplement observer que l’historique a montré des régressions tout aussi graves avec des volumes de correctifs bien plus faibles.

Chapeau la distrib'

Fedora 45 vient d’entrer dans sa phase bêta. Les nouveautés sont assez nombreuses, notamment sur la sécurité et les paquets reproductibles.

Fedora est le laboratoire à ciel ouvert de Red Hat. La distribution est connue pour être pionnière dans ses choix technologiques, comme le choix du serveur d’affichage Wayland par défaut dès la version 25, longtemps avant les autres distributions (et les bugs de jeunesse qui allaient avec).

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

Comme Ubuntu, Fedora dispose d’un rythme biannuel, au printemps et à l’automne. La nouvelle mouture 45 est ainsi prévue pour le 20 octobre, ou le 27 en cas de problème. Maintenant que la bêta est disponible, on peut observer ses nouveautés, parmi lesquelles une hausse manifeste du niveau de sécurité.

Toutes les variantes du système peuvent être téléchargées (images ISO) depuis le site officiel. Sur la page de téléchargement, il faut penser à activer le sélecteur d’affichage pour la bêta. Depuis l’annonce officielle, les différents liens pointent tous directement vers les versions 45.

Composants de base

La bêta de Fedora 45 est livrée avec le noyau Linux 7.2, la dernière révision stable (sortie le 16 aout). Parmi les nouveautés de ce dernier, le Cache Aware Scheduling permet à l’équilibrage de charge de tenir compte du cache de dernier niveau au sein des processeurs. Phoronix, connu pour ses tests de performances, indiquait en outre que le noyau 7.2 introduisait des gains mesurables de performances pour les processeurs AMD et Intel. Entre autres nouveautés, on trouve une première prise en charge du HDMI 2.1 FRL dans le pilote AMDGPU, le support du protocole USB4STREAM d’Intel ou diverses prises en charge dans KVM de fonctions de sécurité propres à AMD et Intel.

Comme toujours avec Fedora, la version proposée par défaut pour les PC, Workstation, est fournie avec GNOME, qui passe pour l’occasion en version 51. Cette mouture n’est pas finalisée, même si les composants en bêta sont remplacés par leurs équivalents RC (Release Candidate) après l’installation de Fedora 45. GNOME 51 inaugure des curseurs au format SVG (déjà présents dans KDE), une nouvelle interface de gestion des empreintes digitales, le support de la connexion distante multi-utilisateurs via Kerberos, de nouveaux réglages pour le pavé tactile, de meilleures performances pour Agenda ou encore le nettoyage du code auparavant lié aux anciens pilotes NVIDIA. Pour les personnes n’appréciant pas GNOME, KDE Plasma 6.7 est disponible dans une version dédiée.

Côté développement, la chaîne GNU passe à GCC 16.2, binutils 2.47, glibc 2.44 et gdb 17.2. S’y ajoutent LLVM 23 pour l’ensemble des sous-projets, Go 1.27, Python 3.15, Perl 5.44 et Lua 5.5. Dans les notes de version de la distribution, on peut lire que plusieurs changements cassent la compatibilité. Par exemple, Setuptools 82 supprime le module pkg_resources. Pandas passe de la 2.3 à la 3.0, avec une gestion des chaînes revue, un comportement copie-sur-écriture cohérent et la suppression de fonctionnalités dépréciées depuis longtemps. Même chose avec libxml2, dont le passage de la 2.13.9 à la 2.15.3 s’est accompagné d’un changement d’ABI, imposant une recompilation de masse avec dépréciation des liaisons Python.

Parmi les autres changements, Podman 6 est une des mises à jour les plus lourdes de conséquences. Elle « inclut des changements importants de rupture de l’API et de la ligne de commande, de nouvelles fonctionnalités, ainsi que la suppression finale de composants obsolètes tels que slirp4netns, cgroups v1 et le backend BoltDB », prévient Fedora. Citons également le passage de MySQL de la version 8.4 à 9.7, et celui de MariaDB de la version 11.8 à la 12.3. NetworkManager prend en charge par défaut les réseaux « IPv6-mostly ».

Sécurité : plusieurs serrages de vis

Plusieurs changements importants sont présents dans Fedora 45. D’abord, l’équipe indique avoir franchi la barre des 90 % de paquets reproductibles.

Pour comprendre l’intérêt, rappelons qu’un paquet est dit « reproductible » si, à partir du même code source, du même environnement de compilation et des mêmes instructions, n’importe qui peut régénérer une copie identique bit à bit du paquet publié. En clair, il s’agit d’un gage de sécurité de la chaine d’approvisionnement : c’est la garantie que le binaire téléchargé correspond bien au code source publié. Dans le cas de Fedora, toute non-reproductibilité détectée est considérée comme un bug et est traitée comme telle, via un rapport. La distribution n’est pas la seule à progresser dans ce domaine, d’autres comme Arch Linux ou NixOS font de même.

On reste dans le sujet avec la vérification désormais obligatoire des signatures par le gestionnaire de paquets RPM. Un mode de vérification stricte, conformément au comportement en amont introduit par la version 6.0, comme nous l’indiquions il y a un an. Ainsi, seuls les paquets dont la signature est vérifiée peuvent être installés, sauf dérogation explicite avec --nosignature ou l’API correspondante. Les RPM compilés localement et non signés sont directement concernés. Côté Fedora, ce changement se fait dans la foulée du passage à RPM 6.1.

Fedora 45 restreint également ptrace par réglage global dans le noyau qui retire par défaut certaines permissions de débogage aux utilisateurs non privilégiés. L’objectif est d’empêcher un logiciel malveillant d’inspecter les autres processus du même utilisateur. En revanche, si des outils de débogage sont installés, un fichier sysctl rétablit le comportement classique de Fedora 44 et des versions précédentes.

Autre changement significatif, le changement de fournisseur par défaut du service Secret. On passe ainsi de KWallet et GNOME Keyring à oo7. Écrit en Rust, il implémente la même interface D-Bus org.freedesktop.secrets, et se veut une alternative légère utilisable sur tous les environnements. Il est développé dans le cadre du projet linux-credentials et sert déjà de service de secrets natif pour COSMIC Desktop. D’après la fiche Fedora, oo7 doit permettre un modèle d’autorisation limitée par application ou par service, ouvrir la voie à l’authentification FIDO2 et mieux encadrer l’accès des applications isolées aux secrets.

On trouve d’autres modifications liées à la sécurité, comme l’interdiction par DNF5 de changer de fournisseur par défaut. Un changement important, car à moins d’une manipulation spécifique, un paquet installé ne peut donc plus être remplacé automatiquement par celui d’un autre fournisseur. Signalons aussi que chpasswd et newusers passent désormais par PAM et appliquent donc les politiques de mots de passe du système.

Chapeau la distrib'

Fedora 45 vient d’entrer dans sa phase bêta. Les nouveautés sont assez nombreuses, notamment sur la sécurité et les paquets reproductibles.

Fedora est le laboratoire à ciel ouvert de Red Hat. La distribution est connue pour être pionnière dans ses choix technologiques, comme le choix du serveur d’affichage Wayland par défaut dès la version 25, longtemps avant les autres distributions (et les bugs de jeunesse qui allaient avec).

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

Comme Ubuntu, Fedora dispose d’un rythme biannuel, au printemps et à l’automne. La nouvelle mouture 45 est ainsi prévue pour le 20 octobre, ou le 27 en cas de problème. Maintenant que la bêta est disponible, on peut observer ses nouveautés, parmi lesquelles une hausse manifeste du niveau de sécurité.

Toutes les variantes du système peuvent être téléchargées (images ISO) depuis le site officiel. Sur la page de téléchargement, il faut penser à activer le sélecteur d’affichage pour la bêta. Depuis l’annonce officielle, les différents liens pointent tous directement vers les versions 45.

Composants de base

La bêta de Fedora 45 est livrée avec le noyau Linux 7.2, la dernière révision stable (sortie le 16 aout). Parmi les nouveautés de ce dernier, le Cache Aware Scheduling permet à l’équilibrage de charge de tenir compte du cache de dernier niveau au sein des processeurs. Phoronix, connu pour ses tests de performances, indiquait en outre que le noyau 7.2 introduisait des gains mesurables de performances pour les processeurs AMD et Intel. Entre autres nouveautés, on trouve une première prise en charge du HDMI 2.1 FRL dans le pilote AMDGPU, le support du protocole USB4STREAM d’Intel ou diverses prises en charge dans KVM de fonctions de sécurité propres à AMD et Intel.

Comme toujours avec Fedora, la version proposée par défaut pour les PC, Workstation, est fournie avec GNOME, qui passe pour l’occasion en version 51. Cette mouture n’est pas finalisée, même si les composants en bêta sont remplacés par leurs équivalents RC (Release Candidate) après l’installation de Fedora 45. GNOME 51 inaugure des curseurs au format SVG (déjà présents dans KDE), une nouvelle interface de gestion des empreintes digitales, le support de la connexion distante multi-utilisateurs via Kerberos, de nouveaux réglages pour le pavé tactile, de meilleures performances pour Agenda ou encore le nettoyage du code auparavant lié aux anciens pilotes NVIDIA. Pour les personnes n’appréciant pas GNOME, KDE Plasma 6.7 est disponible dans une version dédiée.

Côté développement, la chaîne GNU passe à GCC 16.2, binutils 2.47, glibc 2.44 et gdb 17.2. S’y ajoutent LLVM 23 pour l’ensemble des sous-projets, Go 1.27, Python 3.15, Perl 5.44 et Lua 5.5. Dans les notes de version de la distribution, on peut lire que plusieurs changements cassent la compatibilité. Par exemple, Setuptools 82 supprime le module pkg_resources. Pandas passe de la 2.3 à la 3.0, avec une gestion des chaînes revue, un comportement copie-sur-écriture cohérent et la suppression de fonctionnalités dépréciées depuis longtemps. Même chose avec libxml2, dont le passage de la 2.13.9 à la 2.15.3 s’est accompagné d’un changement d’ABI, imposant une recompilation de masse avec dépréciation des liaisons Python.

Parmi les autres changements, Podman 6 est une des mises à jour les plus lourdes de conséquences. Elle « inclut des changements importants de rupture de l’API et de la ligne de commande, de nouvelles fonctionnalités, ainsi que la suppression finale de composants obsolètes tels que slirp4netns, cgroups v1 et le backend BoltDB », prévient Fedora. Citons également le passage de MySQL de la version 8.4 à 9.7, et celui de MariaDB de la version 11.8 à la 12.3. NetworkManager prend en charge par défaut les réseaux « IPv6-mostly ».

Sécurité : plusieurs serrages de vis

Plusieurs changements importants sont présents dans Fedora 45. D’abord, l’équipe indique avoir franchi la barre des 90 % de paquets reproductibles.

Pour comprendre l’intérêt, rappelons qu’un paquet est dit « reproductible » si, à partir du même code source, du même environnement de compilation et des mêmes instructions, n’importe qui peut régénérer une copie identique bit à bit du paquet publié. En clair, il s’agit d’un gage de sécurité de la chaine d’approvisionnement : c’est la garantie que le binaire téléchargé correspond bien au code source publié. Dans le cas de Fedora, toute non-reproductibilité détectée est considérée comme un bug et est traitée comme telle, via un rapport. La distribution n’est pas la seule à progresser dans ce domaine, d’autres comme Arch Linux ou NixOS font de même.

On reste dans le sujet avec la vérification désormais obligatoire des signatures par le gestionnaire de paquets RPM. Un mode de vérification stricte, conformément au comportement en amont introduit par la version 6.0, comme nous l’indiquions il y a un an. Ainsi, seuls les paquets dont la signature est vérifiée peuvent être installés, sauf dérogation explicite avec --nosignature ou l’API correspondante. Les RPM compilés localement et non signés sont directement concernés. Côté Fedora, ce changement se fait dans la foulée du passage à RPM 6.1.

Fedora 45 restreint également ptrace par réglage global dans le noyau qui retire par défaut certaines permissions de débogage aux utilisateurs non privilégiés. L’objectif est d’empêcher un logiciel malveillant d’inspecter les autres processus du même utilisateur. En revanche, si des outils de débogage sont installés, un fichier sysctl rétablit le comportement classique de Fedora 44 et des versions précédentes.

Autre changement significatif, le changement de fournisseur par défaut du service Secret. On passe ainsi de KWallet et GNOME Keyring à oo7. Écrit en Rust, il implémente la même interface D-Bus org.freedesktop.secrets, et se veut une alternative légère utilisable sur tous les environnements. Il est développé dans le cadre du projet linux-credentials et sert déjà de service de secrets natif pour COSMIC Desktop. D’après la fiche Fedora, oo7 doit permettre un modèle d’autorisation limitée par application ou par service, ouvrir la voie à l’authentification FIDO2 et mieux encadrer l’accès des applications isolées aux secrets.

On trouve d’autres modifications liées à la sécurité, comme l’interdiction par DNF5 de changer de fournisseur par défaut. Un changement important, car à moins d’une manipulation spécifique, un paquet installé ne peut donc plus être remplacé automatiquement par celui d’un autre fournisseur. Signalons aussi que chpasswd et newusers passent désormais par PAM et appliquent donc les politiques de mots de passe du système.