Le trésor des données

L’achat de matériels domotiques comprend souvent tout un lot de fonctions connectées pour les exploiter depuis d’autres plateformes. Il arrive pourtant que les entreprises derrière ces produits changent brutalement de logique commerciale, des capacités gratuites devenant tout à coup payantes. Plusieurs cas interrogent sur ces revirements.

La société espagnole Airzone commercialise des solutions de contrôle connectées pour le chauffage et la climatisation. Depuis fin octobre, les clients doivent décider s’ils payent pour une formule à 48 euros par an permettant de préserver certaines fonctions, notamment le pilotage à distance.

Ce changement est rétroactif et concerne donc l’ensemble des clients disposant déjà de produits Airzone. Comme l’un de nos lecteurs nous l’a signalé, cette bascule se fait dans la douleur, avec de très nombreux avis négatifs sur Trustpilot, la note moyenne de l’entreprise s’étant effondrée à 1,1 sur 5. L’instauration de la formule payante Airzone Cloud passe mal.

Plusieurs avis mentionnent un changement abusif dans les conditions d’utilisation et certains vont jusqu’à mentionner qu’un signalement a été fait auprès de la DGCCRF. « Quant à la clause vous autorisant à annuler unilatéralement cette gratuité ou à modifier les caractéristiques du service après l’achat, je vous rappelle qu’en droit français (Article L. 212 - 1 du Code de la consommation), les clauses permettant à un professionnel de modifier unilatéralement les conditions du contrat ou de supprimer une fonctionnalité essentielle du bien sont réputées abusives et nulles. Elles ne sauraient m’être opposées », fustige par exemple un client.

Ce changement n’est cependant pas une surprise. Il avait été communiqué en mai et Airzone précise depuis que les nouveaux clients ont droit à une période gratuite de six mois. Mais attention, car l’abonnement affecte d’autres aspects de l’utilisation, notamment un abaissement à un seul jour d’historique des données pour les graphiques intégrés, contre 1 à 3 ans dans la formule payante.

Comme le précisait alors iGen, Airzone est partenaire d’environ 200 fabricants d’équipements CVC, dont des pompes à chaleur et climatisations. Ses produits se retrouvent donc souvent dans des équipements vendus dans le commerce, rendant le changement particulièrement visible.

Le composant Webserver, nœud du problème

Une installation Airzone (qui comprend les registres motorisés, les thermostats et la carte centrale) doit fonctionner seule. On peut cependant demander à ajouter en option un composant nommé Webserver. Il se branche sur le bus domotique de la maison et connecte le tout au réseau.

Le Webserver est une option payante, ajoutée au devis pour pouvoir justement piloter l’installation domotique à distance. C’est un cas classique, qui permet par exemple de déclencher manuellement le chauffage ou la climatisation à l’avance quand on est sur la route du retour.

Or, comme mentionné par plusieurs clients dans les forums de QueChoisir, Airzone mettait en avant la gratuité du service liée à ce composant optionnel. Ils estiment que cet aspect a été un facteur important de la décision d’achat.

« J’ai acheté le webserver à la fin de l’hiver pour pouvoir piloter ma maison depuis mon téléphone. Si j’avais su que cela allait devenir payant je n’aurais pas dépensé cet argent, car maintenant si je ne paye pas l’abonnement (qui n’existait pas et dont personne ne m’a parlé au moment de l’achat) je reviens au point de départ », explique un client, qui évoque une « prise d’otage ».

« J’ai le système Airzone sur gainable Hitachi depuis plusieurs années. Depuis peu le contrôle extérieur par application est payant. Une honte quand on voit le prix d’achat du système sachant qu’avant cela était gratuit et qu’à la pose on m’a vendu ce système de réglage comme gratuit », indique un autre.

Nous avons contacté Airzone pour éclaircir ce point et mettrons cet article à jour en cas de réponse.

Le cas Withings

L’entreprise française Withings a également fait parler d’elle pour des raisons similaires. À la mi-octobre, l’entreprise a en effet introduit un changement particulièrement désagréable pour les nouveaux clients : pour les comptes créés depuis le 13 octobre, il est désormais nécessaire de passer par une formule payante Withings+ (10 euros par mois ou 100 euros par an) pour transférer les données vers des plateformes tierces. Les anciens utilisateurs ne sont pas concernés.

La décision a créé une vive polémique, notamment chez nos confrères de MacG, qui s’interrogeaient alors : cela ne revient-il pas à placer un verrou sur les données des utilisateurs ? La formule payante devient d’autant plus incontournable que parmi les plateformes tierces, il y a Apple et Google. Pour les personnes qui visaient des produits Withings dans l’idée de synchroniser et rassembler les données dans Santé (Apple) ou Health (Google), l’abonnement est nécessaire, alors qu’il s’agissait jusqu’à très récemment d’une fonction considérée comme basique. Même chose pour Strava.

Au micro de BFMTV, Vincent Brand, chef de produit numérique, a assumé pleinement le choix, évoquant une nécessité pour l’entreprise : « Si on veut que Withings soit encore là dans les années qui viennent, il faut compter sur un transfert de valeur. Avant, elle était sur le hardware, aujourd’hui, c’est la donnée », ajoutant que « le monde n’est plus le même aujourd’hui ».

Facteur « aggravant » autour du changement, Withings n’a pas fait de communication dédiée, frôlant l’effet Streisand. Il est simplement apparu dans une FAQ sur la page d’assistance et sur les écrans des nouveaux clients qui voulaient transférer des données. Interrogé sur ce manque de communication, Vincent Brand a simplement répondu : « On savait que nos clients allaient le voir ». Problème, la méthode peut donner l’impression que le changement a été introduit en douce. « On a sûrement fait quelque chose qui n’était pas totalement optimisé, c’est une certitude », a concédé le responsable. Et pour cause : cette information n’est pas disponible sur les emballages des produits, des clients s’estiment donc floués.

La compatibilité avec le Data Act et le RGPD s’est également posée. Mais pour Withings, il n’y a aucun problème : non seulement rien ne change pour les personnes souhaitant rester dans le seul écosystème Withings, mais les données personnelles peuvent toujours être récupérées. « Le RGPD et le Data Act sont bien évidemment respectés, notamment le droit à la portabilité ou l’interopérabilité ».

Et comme dans un nombre croissant de situations similaires, quelqu’un a décidé de contourner le changement. Un développeur s’est servi de Claude Code pour créer YourOwnWeigh pour récupérer les données et les synchroniser avec des plateformes tierces sans avoir à passer par l’abonnement. Disponible sur GitHub sous licence MIT, le projet se présente sous forme d’application web avec des composants en Python spécifiques à chaque plateforme (fonctionne sur macOS et Linux, bientôt sur Windows).

Grain à moudre

Tous ces cas – y compris celui de Wink en 2020 – invitent cependant à la réflexion sur les achats d’appareils connectés. Le point de vue commun est que la vente de matériel ne suffit pas, même si les deux changements diffèrent : Airzone fait payer l’usage d’une fonction, quand Withings fait payer la circulation des données.

Rien ne porte à croire que ce changement était envisagé dès le départ, mais qu’il s’agisse de contraintes économiques ou d’autres facteurs, la sentence est la même pour la clientèle. Pour les acheteurs prospectant dans la domotique ou la santé connectée, la question de la politique des données est donc encore plus importante. Il ne s’agit plus seulement de leur sécurité ou de la vie privée, mais de la manière dont leurs données seront exploitables à travers d’autres services.

Ces formules ont toutes pour trait commun de rendre payante une fonctionnalité qui était jusque-là gratuite. Il ne s’agit donc pas de formules premium au sens classique, qui reviendraient à payer un supplément pour des fonctions supplémentaires. Pour autant, aucune règle n’oblige actuellement un fabricant à annoncer, au moment de la vente, combien de temps un service restera gratuit, ni même s’il continuera d’exister.

Ces changements invitent quoi qu’il en soit à se poser la question avant d’acheter, car il ne suffit plus de savoir ce que l’objet sait faire le jour de son acquisition. Des projets comme Home Assistant ou YourOwnWeigh montrent que l’on peut presque retirer les fabricants de l’équation, mais il faut pour cela des compétences, du temps et parfois d’autres matériels spécifiques.

Du code « jetable »

Gregory Kurtzer, créateur de CentOS et Rocky Linux, a créé un noyau compatible Linux, nommé Ginux. Loin d’être une proposition concrète, le projet était surtout une expérience : était-il possible de proposer un noyau compatible principalement développé par IA ?

L’expérience fait parler d’elle depuis plusieurs jours. Gregory Kurtzer est loin d’être un inconnu, il est connu pour avoir créé CentOS, une distribution Linux 100 % compatible avec Red Hat Enterprise Linux (RHEL), dont elle est une reconstruction. Apparue en 2003, CentOS attire l’attention, jusqu’à ce que Red Hat commence à sponsoriser la distribution en 2014. Dans les années suivantes, Red Hat embauche progressivement les développeurs travaillant sur CentOS, jusqu’à récupérer la gestion du projet.

Décembre 2020, patatras : Red Hat met fin à CentOS et pousse Stream, sa variante conçue pour intégrer les nouveautés. Le positionnement est alors clair : Fedora pour son aspect laboratoire, CentOS Stream pour intégrer les nouveautés en vue d’une utilisation professionnelle, RHEL pour l’offre commerciale. Gregory Kurtzer, frustré par le nouveau positionnement de Red Hat, crée alors Rocky Linux, à nouveau une reconstruction de RHEL, avec la même compatibilité complète.

• Red Hat met fin à CentOS et pousse Stream, colère au sein de la communauté

Alors quand le développeur annonce avoir créé un noyau compatible Linux, développé avec l’IA, le sujet attire l’attention. Mais pas toujours pour les « bonnes » raisons.

Un noyau compatible, pas un fork

Le projet Ginux est surtout une expérience. Il la présente sur X le 27 octobre comme « un nouveau noyau de système d’exploitation compatible avec Linux qui démarre Rocky Linux 10 avec systemd, le tout en utilisant l’ingénierie agentique dirigée par l’humain (HDAE) ».

Le noyau est conçu pour l’architecture x86-64 et est indépendant. Il ne s’agit pas d’un fork du noyau actuel. Le code utilisé est principalement écrit en Rust. Ginux propose sa propre gestion mémoire, son processus de démarrage, son ordonnanceur, son modèle de processus, ses systèmes de fichiers, son réseau, ses périphériques et sa couche de compatibilité Linux.

Sa particularité est d’implémenter l’interface binaire (ABI) de Linux afin de faire tourner les exécutables Linux existants, sans modification. Gregory Kurtzer indique que cette compatibilité est partielle : sur 375 appels système recondensés dans l’ABI Linux 6.12 en x86-64, 82 sont entièrement implémentés, 245 le sont partiellement et 48 sont refusés volontairement.

Dans l’architecture choisie par le développeur, les charges de travail sont réparties dans des environnements nommés « domaines ». Chacun dispose de ses processus, espaces d’adressage, systèmes de fichiers, points de montage, privilèges et cycle de vie. Il présente ces frontières comme plus marquées que les espaces de noms Linux et les conteneurs OCI (Open Container Initiative).

Des limites assumées

Gregory Kurtzer affirme que son projet a pris 11 jours. Il tâche de rester « humble » dans l’annonce en précisant plusieurs points. D’abord, le nom Ginux fait référence aussi bien à Greg qu’à GPT. Dans le README du projet sur GitHub, l’auteur plaisante : pour s’assurer que son égo reste contenu, le G est officiellement une référence à GPT, puisque le projet a été entièrement réalisé avec GPT-5.6 Sol.

En outre, Ginux ne fonctionne pour l’instant qu’au sein d’une machine virtuelle QEMU. Il n’y a donc ni profil matériel physique, ni support des GPU et disques NVMe, ni audit de sécurité indépendant. Le code est publié sous licence Apache 2.0 comme prototype de recherche.

Le développement cible principalement QEMU/KVM avec une configuration x86-64 Q35, et le dépôt documente aussi une exécution en émulation QEMU sur Apple Silicon. Kurtzer reconnaît que la couverture ABI est incomplète et le matériel peu pris en charge. Réseau, systèmes de fichiers, application des limites de ressources et sécurité demandent encore un travail décrit comme « considérable ».

Dans la méthode HDAE évoquée, c’est lui-même qui a fixé l’architecture, les contraintes, les jalons et les critères d’acceptation. L’agent, lui, menait la boucle d’implémentation : il était chargé d’écrire, démarrer, tester, diagnostiquer, corriger, recommencer face à des vérifications exécutables. C’est l’ensemble de ces actions qui ont alimenté une tâche unique confiée à GPT-5.6 Sol, produisant finalement 139 000 lignes de code et de tests, réparties sur un millier de validations Git environ.

Une expérience, pas un concurrent

En quelques jours, le projet a généré une attention croissante. Face à un nombre croissant de questions sur la possibilité que Ginux puisse concurrencer le noyau Linux, Gregory Kurtzer est intervenu le 29 octobre pour expliquer que « les gens passent à côté du but de Ginux » et que ce dernier n’a pas été conçu pour rivaliser avec Linux : « Ce serait idiot ! ».

Il considère le code produit comme jetable, car Ginux en tant que tel n’était pas le but de l’expérience. Il s’agissait bien du processus de création, c’est-à-dire confier à un agent un travail de longue haleine, guidé par une infrastructure, pour répondre à la question : « L’IA, dirigée par un ingénieur expérimenté, pouvait-elle construire et valider un système logiciel extraordinairement complexe ? ».

Il répète d’ailleurs que l’article de recherche documente la méthodologie, les résultats et les limitations, pas le noyau comme possibilité alternative. Il estime que les questions posées sur la méthode sont plus intéressantes que le résultat. Par exemple : « Combien de temps faut-il pour reproduire un problème, identifier la cause racine, implémenter une correction et valider le résultat ? Quelle intervention humaine est réellement requise ? ».

« Parce que la vraie question n’a jamais été de savoir si l’IA pouvait remplacer Linux. Même si elle peut remplacer certains aspects de sa fonction, elle ne peut pas reproduire la communauté, les normes, la collaboration, l’alignement ou la stabilité », affirme-t-il. Dans une autre publication le 30 octobre, il détaille d’ailleurs comment il a collecté les retours pour déclencher de nouveaux travaux, pour continuer à tester sa méthode.

Ginux est donc davantage une démonstration de faisabilité qu’un produit. Rien n’empêche bien sûr la communauté de s’emparer du projet et de le poursuivre. Rien ne permet d’affirmer que ce noyau alternatif, s’il était développé plus avant, offrirait des avantages concrets et mesurables par rapport au noyau Linux.

Si l’expérience a fait parler, c’est aussi parce que la question de l’IA agite largement le domaine du logiciel libre. La récente enquête publiée par Linux Foundation a montré en partie l’ampleur de ce questionnement, avec des développeurs et mainteneurs de projets dans une position ambivalente, entre abaissement du ticket d’entrée et besoins accrus de vérifier toute la production de code. Dans cette optique, l’expérience de Kurtzer donne un aperçu de ce qu’une IA, employée par un développeur expérimenté, peut accomplir quand elle est strictement encadrée.

• IA : la Linux Foundation constate l’épuisement croissant des contributeurs

Au feu !

Face à l’ampleur de la polémique, Proton a bien été obligée de réagir. L’entreprise suisse subit les foudres des utilisateurs et un torrent de réactions négatives suite aux révélations de 404 Media sur ses méthodes internes et son utilisation forcenée de l’IA.

Deux articles de 404 Media ont provoqué une crise au sein de Proton. Le 26 octobre, nos confrères révélaient le contenu d’un e-mail envoyé aux employés pour les avertir qu’ils allaient être « réinterrogés » au cours d’entretien sur la manière dont l’IA avait transformé leur travail. Le message laissait clairement entendre que leur emploi était menacé s’ils ne l’utilisaient pas assez. Le 29 octobre, deuxième article, cette fois pour détailler l’ambiance interne, avec un Andy Yen (CEO) très offensif, voire insultant avec les développeurs.

• Chez Proton, le rouleau compresseur de l’IA écrase tout

Le point le plus inquiétant pour les utilisateurs, comme vu sur Reddit et X notamment, semblait l’accélération de la production de code par IA au détriment de la sécurité. 404 Media avait mis en avant un échange sur Slack dans lequel un développeur demandait du temps pour réaliser des tests de pénétration sur du nouveau code. Andy Yen y répondait en critiquant la requête et en évoquant une « mentalité de loser ».

Proton cherche maintenant à éteindre l’incendie

Au soir du 30 octobre, plusieurs publications sont apparues. D’abord, un nouvel article de 404 Media pour indiquer que les « réentretiens » n’auraient finalement pas lieu. Selon nos confrères, Andy Yen a confirmé ce changement lors d’une réunion interne, estimant que le débat avait servi le but poursuivi : que l’IA devienne un sujet actif et que les développeurs se lancent dans une formation personnelle.

Il faut également éteindre publiquement l’incendie. Sur X et LinkedIn, dans la nuit du 30 au 31 octobre, le compte officiel Proton a publié un long message pour aborder plusieurs points de tension. Ainsi, l’entreprise n’installerait aucun logiciel sur les postes des développeurs pour surveiller leur utilisation de l’IA, une rumeur qui proviendrait d’un « malentendu sur le fonctionnement des logiciels MDM », ces derniers étant destinés à gérer des parcs d’appareils de manière centralisée.

« Ensuite, notre utilisation de l’IA ne se fera jamais au détriment de la sécurité. Au cours de l’année écoulée, contrairement à ce qui a été allégué, des couches supplémentaires de révision de sécurité ont été ajoutées pour faire face à la menace posée par des IA hostiles qui scrutent le code open source de Proton à la recherche de vulnérabilités. Notre code est open source, et sa sécurité reste ouverte à la vérification de tous », affirme l’entreprise.

Proton dit également vouloir faire preuve de transparence. Elle veut « ouvrir le capot » pour montrer comment elle utilise l’IA en interne. Elle compte par exemple publier des informations sur ses outils et rendre leur code open source, « y compris sur des versions plus avancées de Lumo avec des capacités accrues, qui n’ont jamais été mises à disposition en dehors de l’entreprise ». Lumo est pour rappel le chatbot maison, qui doit permettre d’utiliser l’IA sans envoyer d’informations chez les grandes entreprises américaines.

La société suisse promet en outre de communiquer des informations sur la manière dont les révisions de code et de sécurité sont réalisées. Elle veut se montrer transparente sur ses politiques en IA, y compris les domaines dans lesquels elle est autorisée ou interdite. « Au lieu de pouvoir seulement voir le code open source final que nous produisons pour vérifier la sécurité, vous pourrez également évaluer comment ce code a été produit », ajoute Proton, qui confirme à nouveau que les employés ne seront pas réinterrogés sur leur utilisation de l’IA.

Oui, mais…

Bien que l’entreprise cherche à contrôler autant les dégâts que possible, on peut relever plusieurs problèmes. D’abord, son amende honorable n’a été publiée que sur deux réseaux sociaux, X et LinkedIn. Le texte n’a pas fait l’objet d’une communication plus officielle, sur le blog de l’entreprise par exemple.

Ensuite, les bonnes volontés de Proton ne sont accompagnées d’aucune date. L’éditeur s’engage donc sur plusieurs processus, mais sans calendrier.

Sur la présence d’un logiciel qui analyserait l’utilisation de l’IA, la situation reste floue. On se souvient que Brad Butler, directeur technique, a indiqué que 90 % du code produit en octobre avait été généré par IA (a priori par Claude). La mesure semble donc exister quelque part, peut-être au niveau de GitHub via la console de Copilot.

La promesse de transparence autour de Lumo devra également être confrontée à la réalité, car ce n’est pas la première fois que Proton s’engage sur ce sujet. L’European Open Source AI Index avait en effet critiqué en aout 2025 la présentation initiale de Lumo comme « open source ». Selon cet index, seuls les codes des applications mobile et web sont ouverts.

• Proton lance son assistant IA Lumo et déménage ses installations en Allemagne

Surtout, l’entreprise a désormais deux problèmes sérieux d’image. D’abord, sur son activité elle-même : Proton se présente depuis toujours comme l’alternative sécurisée aux grands groupes américains. Les extraits de conversations publiés par 404 Media ne vont pas exactement dans ce sens.

Ensuite, que ce soit sur X, Reddit ou LinkedIn, de nombreuses personnes remettent en question le rôle d’Andy Yen à la tête de l’entreprise, beaucoup appelant désormais à sa démission. Il est accusé d’avoir installé un climat délétère au sein de Proton, la course à la croissance et aux profits mettant en danger les fondements de l’offre logicielle. D’autres encore estiment que si l’IA est désormais incontournable, Andy Yen reste responsable de son utilisation forcée au point de mettre en danger les emplois et de ses insultes aux personnes qui réclament du temps pour tester le code produit.

Microsoft avait promis de remanier le menu contextuel de Windows 11 sur les fichiers. C’est désormais chose faite, avec la mise à jour KB5127936 disponible depuis peu en option. Ce qui signifie qu’elle n’apparaitra que si vous déclenchez une recherche volontaire de mise à jour dans Windows Update. Sinon, elle sera installée automatiquement le mois prochain.

Problème : comme toujours chez Microsoft, les nouvelles fonctions n’apparaissent pas tout de suite. Le nouveau menu contextuel est en cours de déploiement. Pour vérifier si vous l’avez après l’installation de la mise à jour, il suffit de vérifier en faisant un clic droit sur un fichier. Si c’est bien le nouveau menu, vous verrez une ligne « Personnaliser le menu » tout en bas. Il existe toutefois un moyen de forcer l’activation en passant par l’outil ViVeTool, dans un Terminal avec droits administrateur, via la commande :

vivetool /enable /id:60813048

Sur certaines configurations, cet ID peut ne pas suffire. Auquel cas, il faudra tenter avec la fin de commande « /id:49453572,60813048 », voire « /id:49453572,60813048,61934903 ». Dans notre cas, la commande simple a suffi.

Après un redémarrage, vous aurez alors le nouveau menu. Le jeu en vaut-il la chandelle ? Tout dépend de votre utilisation du fameux menu. Le nouveau est clairement plus réactif, ce qui était un point régulier de friction jusqu’ici. Surtout, le menu est maintenant personnalisable. En cliquant sur le dernier élément du menu, le panneau idoine s’ouvre dans Paramètres.

Les options sont assez nombreuses. On peut voir notamment une ligne permettant de retrouver les options Couper/Copier/Coller en liste, et plus les icônes en tête de menu. Il aura donc fallu cinq ans à Microsoft à comprendre qu’un élément aussi basique que le menu contextuel doit être réactif, personnalisable et que l’on ne casse pas plusieurs décennies de mémoire musculaire impunément.

La mise à jour KB5127936 contient d’autres nouveautés, comme une fenêtre modernisée pour AutoPlay, un affichage plus cohérent pour les résultats de recherche dans l’Explorateur, une nouvelle Gaming Task View en mode Xbox, ou encore l’intronisation officielle de la réinstallation par le cloud, que Microsoft avait présentée en juillet.

Vous avez le week-end pour tout réinstaller

Une version piégée de l’extension Claude Code pour Visual Studio Code a été distribuée le 29 octobre dans la boutique Cursor. Elle installait une porte dérobée SSH persistante. Même si le problème a été résolu, l’extension frelatée a été installée par environ 5 000 personnes et pose de nouveau la question des chaînes d’approvisionnement.

Dans la journée du 29 octobre, quelque part entre 10h27 et 21h35 (heure de Paris), une version vérolée de l’extension Claude Code pour VS Code a été distribuée dans la boutique de Cursor. Estampillée 2.1.313, elle est restée suffisamment de temps en ligne pour avoir été téléchargée. Les 5 000 personnes concernées sont actuellement contactées, a indiqué Cursor.

L’éditeur dit avoir supprimé la version, arrêté intégralement sa boutique d’extensions, audité les accès, renouvelé ses clés, reconstruit la boutique et fait mettre hors ligne le serveur de l’attaquant par son hébergeur. Les différents contrôles n’ont révélé aucune autre extension modifiée.

Où l’attaque a-t-elle commencé ?

Le principal point flou dans cette histoire est que l’on ne sait pas exactement quand tout a commencé. Tout dépend de qui raconte l’incident.

Chez Phorion par exemple, l’attaque est présentée comme une compromission de la fiche officielle sur Open VSX, la marketplace ouverte de la Fondation Eclipse pour l’écosystème des éditeurs API compatibles avec VS Code. Phorion affirme également qu’Anthropic a retiré la version 2.1.313 d’Open VSX, de npm et même du Marketplace de Microsoft pour VS Code.

OpenSourceMalware, qui a publié la première analyse, indique que l’échantillon analysé provenait bien d’Open VSX. Le site en a déduit une diffusion par npm et le Marketplace de Microsoft en se basant sur un constat : la version 2.1.313 n’y figurait plus. Il précise que la provenance de l’artefact n’est pas établie et que ses conclusions ne prouvent pas une compromission de la distribution officielle d’Anthropic. Et pour cause, les retraits de npn et du Marketplace peuvent n’être qu’une mesure de sécurité, dans l’optique de supprimer toutes les versions 2.1.313 existantes. Problème, pour l’instant, ni Anthropic ni Microsoft n’ont réagi publiquement à l’incident.

Chez StepSecurity, on affirme que la compromission a commencé chez Open VSX avant d’être étendue à Cursor, puisque la boutique de ce dernier est un intermédiaire dont la base se synchronise avec le registre Open VSX. Les contrôles de sécurité appliqués sur ce dernier sont limités, avec un examen portant sur les motifs malveillants les plus connus. Ce qui signifie que l’extension vérolée aurait passé non seulement ces contrôles, mais également ceux de Cursor, plus poussés.

Illustration de ces incertitudes, The Hacker News a mis à jour son article pour indiquer que la compromission venait de Cursor seul. Pour cela, il faudrait que l’infrastructure propre à Cursor ait été compromise, ce que l’éditeur ne dit pas clairement. Cependant, le nombre d’actions entreprises pourrait aller dans ce sens, Cursor ayant renouvelé ses clés et reconstruit son magasin.

Le fonctionnement du malware

Si on ne sait pas comment tout a commencé ni qui est réellement concerné, on connait en revanche mieux le fonctionnement du code malveillant, les analyses de Phorion, OpenSourceMalware et Cursor s’accordant sur les détails.

L’extension contient ainsi un chargeur de 66 lignes, placé en tête du fichier extension.js. Il se lance dès le chargement du module, sans nécessiter d’action de l’utilisateur et donc avant même de lancer une conversation avec Claude. Ce chargeur ajoute une clé publique SSH liée à l’attaquant dans le dossier ~/.ssh/authorized_keys, pour lui donner un accès distant permanent sur l’ordinateur de la victime. La clé est étiquetée « svc-telemetry » pour paraitre anodine.

Le code vérifie ensuite que le service SSH est présent et actif. Dans le cas contraire, il tente de l’activer. Sur la plupart des Mac et PC sous Windows, l’étape échoue, non seulement faute de droits administrateur mais aussi car le code contient des erreurs. Sur Linux, le code réussit.

Le malware cherche ensuite à faire établir une connexion sortante vers le serveur de l’attaquant et à la maintenir ouverte. L’attaquant n’a alors plus qu’à emprunter ce tunnel en sens inverse pour atteindre la porte SSH et entrer avec sa clé privée, ouvrant la voie vers un terminal et la possibilité de lancer des commandes.

Le code installe aussi un petit script qui se relance à chaque démarrage de l’ordinateur et retente la connexion une fois par minute. Sur macOS, ce script se déguise en composant Apple (com.apple.sysmond), sur Windows en tâche Sysmon ou en script dans le dossier Démarrage, et sur Linux en tâche planifiée. La désinstallation de l’extension ne suffit donc pas. Le code envoie enfin une fiche descriptive de la machine avec nom de l’ordinateur, utilisateur, système, adresse IP publique, adresse électronique Git et dossier de travail.

Cette charge utile ne vole donc en elle-même aucune information cruciale, mais elle prépare le terrain. Le danger vient avant tout de ce que le pirate peut réaliser une fois la connexion établie via SSH.

Des vérifications à faire

La fiche de Cursor sur l’incident, publiée hier soir, mentionne uniquement des vérifications à faire pour macOS et Windows. L’éditeur ne le dit pas explicitement, mais il semble que Linux ne soit curieusement pas concerné, malgré les détails techniques allant pourtant dans ce sens.

Faute de script officiel, les analyses de Phorion et OpenSourceMalware présentent une série de commandes bash. Dans les trois cas cependant, si une preuve de compromission est détectée, il faudra effectuer plusieurs manipulations. Mais la recommandation est claire : réinstaller complètement la machine sera l’option la plus sûre.

Cursor indique dans son billet que les 5 000 personnes (environ) qui ont installé l’extension modifiée sont contactées pour être averties du problème.

Du travail pour les relations presse

L’ambiance chez Proton est particulièrement difficile autour de l’usage de l’IA et de l’attitude du patron de l’entreprise, Andy Yen. C’est ce qu’affirme 404 Media dans un article. La société suisse a désormais un sérieux problème d’image à résoudre.

Mise à jour du 30 octobre à 18 h :

Selon un nouvel article de 404 Media, Andy Yen, CEO de Proton, a annoncé que les « réentretiens » des employés n’auraient finalement pas lieu. Ils visaient à identifier les développeurs qui n’utilisaient pas assez l’IA. Leurs emplois semblaient directement menacés.

Le nouvel article indique qu’une réunion s’est tenue aujourd’hui même, vendredi 30 octobre. Andy Yen y aurait reconnu un échec de communication de sa part, tout en annonçant que la poussée vers l’IA continuerait. Il aurait affirmé que ces nouveaux entretiens étaient à présent inutiles, car la situation avait abouti au résultat voulu : déclencher une vaste conversation sur l’IA et accélérer la formation. Une réorganisation serait prévue pour le mois prochain, mais aucune suppression d’emploi ne serait prévue.

Les salariés interrogés par nos confrères sont partagés. L’un d’entre eux y voit un progrès, un autre regrette l’absence de responsabilité de la direction, un autre encore évoque une simple gestion de crise. Selon ce dernier, les constats sur l’utilisation de l’IA passeront dans les évaluations annuelles et ne sont donc que différées.

---

Article original du 30 octobre à 12h02 : Proton est connue depuis des années comme l’entreprise suisse pourvoyeuse de solutions respectueuses de la vie privée. Et pour cause : tous ses produits communiquent en utilisant le chiffrement de bout en bout. En d’autres termes, personne ne peut voir ce qui transite ou est stocké, pas même Proton. Cependant, cette efficacité dépend étroitement de la manière dont la technologie est implémentée.

Selon un long article de 404 Media du 29 octobre, les employés craignent désormais pour l’intégrité du code. La raison ? Une obligation d’utiliser autant que possible l’IA, au point que la direction de Proton envisagerait de ne plus embaucher d’ingénieurs dès l’année prochaine, mais des chefs de produit utilisant l’IA, Claude étant largement cité.

Injonctions sur l’IA

404 Media dit avoir échangé avec huit employés actuels et un ancien, consulté des conversations Slack, des enregistrements de réunions ou encore un manifeste sur l’IA rédigé par le directeur technique de Proton, Bart Butler.

Un employé a par exemple demandé récemment s’il était possible de prendre quelques jours pour analyser le code généré et réaliser des tests de pénétration pour en mesurer le degré de sécurité. Selon nos confrères, le CEO de l’entreprise, Andy Yen, a répondu sur Slack qu’il s’agissait de « conneries et d’une attitude de perdant », que rapidité et sécurité étaient « bien sûr » compatibles et qu’il fallait arrêter de « réfléchir à comment être plus lent ».

Dans une ambiance électrique, Andy Yen a ouvert une adresse e-mail servant à signaler tout obstacle à une adoption plus large de l’IA. Selon 404, l’entreprise est même allée jusqu’à installer sur les postes des employés un logiciel mesurant la quantité de code produite par LLM. Le résultat, proclamé par le Bart Butler lui-même, est que 90 % du code écrit pour l’instant en octobre a été généré par IA. Sur cette proportion, une grande partie viendrait de Claude, selon plusieurs employés.

« Le train arrive, montez à bord ou soyez écrasés »

Le déclencheur de la colère semble avoir été un e-mail envoyé à tous les employés pour les avertir que des « réentretiens » allaient avoir lieu, chaque salarié devant être évalué sur son utilisation de l’IA par une personne extérieure à son équipe et à sa chaîne hiérarchique. Ces entretiens sont prévus pour la période du 4 au 11 novembre, les salariés devant apporter des exemples concrets de ce que l’IA a changé dans leur travail. L’e-mail avertit que ces entretiens auront des conséquences : « Votre capacité à vous aligner avec leurs vues déterminera votre avenir avec nous, ou si vous en avez un ».

L’attitude d’Andy Yen semble avoir largement changé en août. Dans une interview accordée à Wired, le patron indiquait alors que Proton s’était lancée dans l’IA à contrecœur, car la technologie impliquait une forme de surveillance. Yen avait même proclamé qu’il préférerait un monde sans IA. Le LLM maison, Lumo, était présenté comme une manière de faire de l’IA générative en préservant la vie privée des utilisateurs.

À la fin du même mois, le ton était déjà très différent en interne. « Le train arrive, montez à bord ou soyez écrasés. Ne soyez pas l’opérateur professionnel de fax à l’ère d’internet », a-t-il déclaré dans une conversation Slack.

« Je pense que d’ici la fin de cette année, la plupart des développeurs arrêteront de programmer et commenceront à écrire des spécifications pour des tests que l’IA va coder et exécuter, afin de valider le code écrit par l’IA que les humains ne pourront plus vérifier. Ce sera la dernière année où nous embaucherons des ingénieurs, et à partir de l’année prochaine, nous recruterons ce que nous appelions autrefois des chefs de produit, pour construire des choses avec l’IA »

Proton ne nie pas les révélations

Andy Yen cherche désormais à mettre en place une nouvelle équipe qui devra travailler nettement plus dur et poser les bases du futur pour l’entreprise. Le patron a explicitement mentionné son désir de voir Proton devenir une « entreprise 996 », en référence à une culture grandissante (en Chine et dans la Silicon Valley) de travailler de 9 h à 21 h, six jours par semaine. Les avantages matériels suivraient, avec notamment une hausse de 30 % du salaire et une carte bancaire dédiée aux frais professionnels.

Interrogée sur ce climat de peur et de pression, l’entreprise n’a pas nié : « Les temps de grands changements font peur, et l’industrie technologique dans son ensemble doit faire face à cette transition. Nous n’avons pas toujours communiqué nos intentions aussi bien que nous aurions pu, mais Proton s’engage à aider nos collègues à se reformer et à se requalifier pour l’avenir », a déclaré un porte-parole.

L’entreprise a cependant un sérieux problème d’image désormais, suite à l’article de 404 Media du 26 octobre sur l’e-mail qui semble avoir tout déclenché. Sur Reddit, la colère est palpable chez les utilisateurs, notamment ceux abonnés. Beaucoup affirment avoir résilié ou leur intention de le faire.

« Votre personnel était suffisamment qualifié pour obtenir son poste au départ. Si vous pensez maintenant que certains d’entre eux n’ont pas les compétences nécessaires pour s’adapter aux technologies évoluant à une vitesse ultra-rapide, vous avez clairement échoué en ne mettant pas en place un programme de formation d’amélioration continue efficace. Vous avez échoué en tant que direction. Vous les avez laissés tomber », affirme par exemple neilbaldwn.

Nouvelle mouture majeure pour Tor Browser, dont la version 16 se fonde désormais sur Firefox 153 ESR, avec à la clé un an de changements techniques sous le capot. Dans son billet, l’équipe de Tor Browser indique que son audit annuel du code de Firefox a porté sur plus de 270 anomalies référencées dans Bugzilla, susceptibles de nuire à la vie privée ou à la sécurité.

Côté nouveautés, la plus visible est la refonte des paramètres, qui reprennent en bonne partie ceux de Firefox. Ainsi, la page Général disparaît et son contenu est réparti entre Apparence, Téléchargements, Onglets et navigation, Accessibilité et Langues. Les pages spécifiques à Tor – comme Connexion et Niveau de sécurité – ont été reconstruites avec les nouveaux composants de Firefox.

Certains réglages qui pourraient dégrader la vie privée ou faciliter la prise d’empreinte du navigateur sont masqués ou accompagnés d’avertissements. L’équipe du navigateur ajoute que les préférences personnelles sont gardées lors de la mise à jour.

Autre nouveauté importante, les titres de fenêtres génériques. Cette option (Confidentialité et sécurité> Protections contre les applications tierces) permet de remplacer tous les titres par « Tor Brower », avec pour objectif de barrer la route au système ou autres applications qui voudraient lire l’historique de navigation via les titres de fenêtres. L’équipe est en quête de retours sur cette fonction, qui a d’ailleurs été reversée à Firefox via deux nouvelles lignes dans le about:config :

• privacy.exposeContentTitleInWindow
• privacy.exposeContentTitleInWindow.pbm.

Outre une révision complète du manuel utilisateur, Tor Browser 16 introduit également une version ARM 64 bits pour Linux (Aarch64). Cette architecture était supposée dans la branche Alpha du navigateur, mais l’équipe recommande désormais de basculer sur la branche stable.

Puisque l’on parle d’architectures, Tor Browser 16 ne prend plus en charge les installations Linux 32 bits. « Heureusement, très peu de personnes devraient être touchées, car nous recevons actuellement environ 200 vérifications de mise à jour par jour de cette plateforme, contre un pic d’environ 4 000 en 2019. La plupart des utilisateurs 32 bits restants devraient pouvoir passer à la version 64 bits, sauf s’ils utilisent du matériel ou des versions de Linux obsolètes », précise le billet.

Quant à la version Android, elle reprend elle aussi les améliorations de Mozilla sur l’année écoulée, dont le passage progressif à Jetpack Compose, permettant une migration vers des interfaces « natives », autrement dit Material Design 3. L’équipe de Tor Browser rappelle cependant que Google limite la taille des applications distribuées en APK à 100 Mo, ce qui représente « un défi constant ». Il a fallu par exemple sortir le manuel utilisateur alors que l’équipe aurait préféré qu’il soit toujours consultable, indépendamment des conditions réseau.

• Télécharger Tor Browser 16 pour ordinateurs
• Télécharger Tor Browser 16 pour Android

Un autre genre de confinement

Après une première annonce en 2023, Canonical semblait avoir laissé tomber son idée d’un Ubuntu Core Desktop, un système pensé pour être immuable, atomique et attestable. Voilà pourtant qu’elle remet le couvert, affirmant cette fois accélérer le projet.

Pour comprendre les enjeux, il faut revenir aux définitions : qu’est-ce qu’un système d’exploitation immuable, atomique et attestable ? D’abord, immuable : c’est un système dont les fichiers essentiels sont en lecture seule. Avec ce fonctionnement, en théorie, aucun utilisateur ni aucune application ne peut les modifier.

Ensuite, lorsque l’on parle de système atomique, on évoque surtout ses mises à jour : elles s’appliquent soit entièrement, soit pas du tout. Les deux vont très souvent de pair, de sorte que le système vise une prévisibilité extrême, la base ne changeant pas. Les applications sont isolées, aussi bien du système qu’entre elles, chacune résidant dans son propre conteneur. Dans le cas de Canonical, vous l’aurez deviné, on parle bien de Snap.

Sur ce socle vient se greffer un système d’attestation. Une telle version d’Ubuntu doit ainsi prouver à tout moment ce qu’elle exécute. Interrogée, la machine peut démontrer quels logiciels elle fait tourner, simplifiant les vérifications et rendant les altérations plus complexes. Ce type de mécanisme passe souvent par un composant matériel dédié, TPM dans la grande majorité des cas.

Le retour d’Ubuntu Core Desktop

Dans son nouveau billet du 28 octobre, Canonical reconnait que la préversion de 2023 n’a pas été à la hauteur. Les débuts ont certes été encourageants, mais le projet est devenu très silencieux dès l’année suivante. Selon le site It’s FOSS, l’explication tient dans la manière dont Canonical avait dessiné son système, une grande partie du bureau (dont GNOME et l’écran de connexion) étant réunie dans un seul snap volumineux.

Dans le fond, le principe est inchangé. Tous les composants sont livrés sous forme de snaps, dont le chargeur d’amorçage, le noyau, l’environnement de bureau, les démons (services) et toutes les applications. Mais en pratique, l’approche est cette fois beaucoup plus modulaire. Canonical dit vouloir définir des interfaces claires entre les composants. Ainsi, le gestionnaire d’affichage, l’environnement de bureau, les serveurs multimédias, le réseau et les autres fonctions devront respecter des interfaces clairement définies sans dépendre d’une implémentation particulière.

Dans ce fonctionnement, chaque partie du bureau peut évoluer individuellement. C’est effectivement à la base la promesse des snaps et, plus généralement, de tous les conteneurs logiciels. Bénéfice de cette évolution modulaire, il ne serait plus nécessaire de reconstruire tout le système à chaque changement. Selon Canonical, ce facteur différencierait Ubuntu Core Desktop des autres systèmes immuables comme Fedora Silverblue ou openSUSE Aeon.

Conséquence, cette version du système n’obligerait pas à utiliser GNOME. Canonical indique s’être rapprochée de l’équipe de KDE Neon Core et avoir produit une variante de KDE Neon fondée sur Ubuntu Core.

• KDE fête ses 30 ans

Canonical vise trois cas d’usage pour la 27.04

L’entreprise explique qu’une équipe dédiée est désormais constituée pour travailler sur Ubuntu Core Desktop et que des préversions quotidiennes seront construites pendant le cycle de développement d’Ubuntu 27.04. Pour l’instant, la nouvelle équipe remet en place les chaînes de production d’images et fait le point sur la situation.

Canonical indique que trois cas d’usage prioritaires sont visés. D’abord, le navigateur, cas jugé le plus simple car Firefox et Chromium sont livrés en snaps depuis des années. Ils sont compatibles avec le système de permissions et peuvent donc accorder l’accès à la caméra et au micro.

Ensuite, le développement logiciel. Cette fois, la situation se complique : un système de fichiers en lecture seule et des permissions strictes ne font pas forcément bon ménage avec les habitudes des développeurs. De plus, des outils répandus comme Visual Studio Code fonctionnent en mode « classic », qui accorde de nombreuses permissions au système. VSC ne fonctionne d’ailleurs pas sur Ubuntu Core. Solution envisagée par Canonical : placer ces applications dans Workshop, un environnement de développement isolé propre à l’entreprise, tandis que les fenêtres associées seraient affichées sur le bureau principal. Canonical compare directement cette solution à WSLg (Windows Subsystem for Linux GUI) de Microsoft.

Enfin, le jeu vidéo, avec l’objectif affiché de pouvoir fonctionner aussi bien sur ordinateur classique que sur des consoles portables comme le Steam Deck. Techniquement, le snap de Steam satisfait déjà les exigences de confinement strict, mais il a été largement mis de côté ces deux dernières années. Dans l’idéal, les composants graphiques seront eux aussi modulaires, afin que Mesa et Proton puissent être mis à jour sans toucher au reste du système. Canonical dit aussi étudier des modes de commande où l’appareil démarre directement sur une interface de jeu plutôt que sur un bureau classique.

La route sera longue

Dans tous les cas, le principal obstacle est la disponibilité des applications en snaps. Core Desktop ne peut pas exécuter un autre format. Il faut également que les permissions soient gérées, afin qu’une application puisse toujours demander l’autorisation avant d’accéder à la caméra, au micro ou à un dossier personnel. Autre défi, la modularisation complète du bureau et la prise en charge de KDE Plasma au même niveau que GNOME.

Le projet reste jeune, voire très jeune. Canonical précise d’ailleurs que la version classique d’Ubuntu est là pour rester, aucun calendrier n’étant donné pour une éventuelle bascule par défaut sur Core Desktop. Concernant les variantes officielles du système (les flavors comme Kubuntu, Edubuntu, Xubuntu…), le billet indique que les mainteneurs concernés seront libres de proposer leur propre variante de Core Desktop, s’ils le souhaitent.

Oui, c'est compliqué

Argon tout juste présenté il y a un mois, Google l’éclipse déjà par un nouveau venu : Carbon. Il prend la tête des modèles de pointe de l’entreprise, mais il n’est pas encore disponible et les détails manquent.

Google a présenté Argon le 30 septembre comme premier représentant de la famille Gemini 4. Il n’a cependant pas été disponible de tout de suite, le LLM ayant dans un premier temps été examiné par le gouvernement américain. Le 13 octobre, le nouveau modèle a finalement été lancé publiquement. À peine deux semaines plus tard, voilà qu’Argon est déjà remplacé.

Son successeur se nomme Carbon. Il prend ainsi la tête des LLM frontière (de pointe) chez Google et, si l’on en croit les chiffres communiqués, de bon nombre de classements tous modèles confondus. Ce n’est pas tout à fait une surprise cependant, des rumeurs circulaient depuis trois semaines environ sur cette arrivée.

Des performances à l’avenant, mais…

Au vu des scores donnés par Google, Carbon est premier dans 15 des 17 benchmarks référencés. Il n’est derrière que sur deux des tests : FrontierSWE 2, où Carbon obtient 61,2 %, derrière GPT-6 Astra (65,5 %) et Opus 5.5 (62,3 %), et OSWorld, où Opus reste en tête avec 87,2 %, contre 81,5 % pour Carbon.

Artificial Analysis classe Carbon (en effort High) premier de son Intelligence Index v5.0 avec 59 points, devant Claude Opus 5.5 (58), GPT-6 Astra (57) et Argon (50). Attention avec cette version 5 de l’indice, car elle a été révisée pour limiter la saturation (les notes maximales devenaient souvent atteintes). 60 % des tests étant désormais privés ou à réponses non publiées, les scores ne sont pas comparables à ceux des versions précédentes.

Carbon surpasse son prédécesseur dans tous les cas de figure, avec des bonds parfois importants dans certains domaines, comme un passage de 42 à 54,8 % sur ExploitGym. La cybersécurité est d’ailleurs mise en avant par Google, qui précise tout de même que ses tests ont été menés sans aucun garde-fou. Impossible en l’état de savoir ce que les clients auront réellement entre les mains, même si ce n’est que l’un des nombreux points que Google n’aborde pas dans sa présentation.

Parmi les progrès que Google revendique face à Argon, on peut voir un taux de triche désormais à 0,0 % sur Terminal-Bench 4.0, une baisse de 80 % des alertes de désalignement graves dans ses environnements internes de développement, ou encore une réduction de moitié des réponses non étayées.

… peu d’informations concrètes

Problème, Carbon a beau sembler puissant, Google tait pour l’instant de nombreuses informations. La plupart des données fournies émanent de tests internes ou de formulations floues, par exemple sur l’utilisation enthousiasmée des employés qui l’ont testé pendant plusieurs jours. Google ne dit rien non plus de la disponibilité. Si l’on applique le calendrier d’Argon, la sortie publique pourrait intervenir dans deux semaines. Un petit nombre de spécialistes de la cybersécurité y a cependant accès, le nombre devant augmenter progressivement via le programme Fairwind.

Côté tarifs, puisque Carbon remplace Argon, il reprend les mêmes : 2 dollars par million de jetons en entrée, 10 dollars en sortie, avec une remise de 95 % sur les jetons d’entrée en cache. À l’issue de la période de lancement, le tarif passera respectivement à 4 et 20 dollars, mais Google ne donne aucun détail temporel. Carbon, comme Argon, est donc un modèle onéreux. Il est d’ailleurs épinglé comme tel par Artificial Analysis, dont l’indice maison affiche un coût de 7,76 dollars par tâche, qui reste cependant moins élevé que ceux affichés par les derniers modèles Anthropic en effort maximal.

Si Carbon est présenté explicitement comme un successeur d’Argon, sur lequel il est bâti, la gamme Gemini manque de lisibilité, d’autant qu’Argon reste au catalogue. Sa période promotionnelle se finit le 1er décembre, et on peut se demander si Google ne compte pas le retirer alors, pour laisser place à Carbon et sa propre période promotionnelle. Le nouveau venu serait sinon moins cher que son grand frère, ce qui n’aurait guère de sens.

La facture est salée

Amazon a présenté le 28 octobre une nouvelle série d’appareils Alexa. Si trois sont des révisions et améliorations, deux sont entièrement nouveaux : Alexa Photo Frame et Echo Time.

Automne oblige, de nombreux constructeurs lancent de nouveaux produits ou renouvellent leurs gammes. Chez Apple par exemple, depuis l’iPhone 18 Pro et l’iPhone Duo les produits se sont enchainés, notamment dans le domaine de la domotique, ou très récemment un MacBook Pro tactile dont on se demande pourquoi une arrivée aussi tardive sur ce créneau.

Chez Amazon, l’heure est au renouvellement des appareils Alexa. Cinq ont été présentés, dont trois sont des modernisations de produits existants et deux sont nouveaux. Mais rien de tout cela n’est prévu pour être disponible en Europe.

Alexa Photo Frame et Echo Time

L’Alexa Photo Frame est un cadre photo numérique de 10 pouces, conçu pour être davantage accroché à un mur que posé sur un meuble. L’écran est décrit comme semi-mat et antireflet et les prix de lancement sont de 199,99 dollars en noir, ou 229 dollars avec un cadre en bois (bouleau ou noyer). La disponibilité est immédiate, en tout cas aux États-Unis et dans certains marchés, mais pas en Europe pour l’instant. Pour le Vieux Continent, rien n’a été annoncé.

Le cadre photo est fait pour fonctionner avec Alexa+, qu’il faudra donc souscrire si ce n’est pas déjà fait. Il exploite le compte Amazon Photos pour choisir les images, en écartant automatiquement tout ce qui n’a pas lieu d’être affiché sur ce type de produit, comme les captures d’écran et les tickets de caisse. Via une commande vocale, on peut lui demander de se concentrer sur certaines catégories de photos comme des visages souriants, des personnes spécifiques ou d’autres thématiques.

L’autre appareil est un réveil, Echo Time. Il propose diverses fonctions comme un suivi du sommeil (désactivé par défaut). Il peut également déclencher une alarme « intelligente » quand ce suivi est activé, afin de vous réveiller dans une fenêtre de 10 à 60 min quand l’appareil détecte un sommeil léger avant l’heure prévue.

Affichant un design sphérique, l’appareil est équipé d’un écran 3,2 pouces personnalisable, avec « des centaines de cadrans d’horloge ». Amazon prend bien soin de préciser qu’aucune caméra n’est présente. L’Echo Time est commercialisé 199,99 dollars ou 209,99 pour une version « Kids », tout de même. Certaines fonctions nécessitent là aussi Alexa+.

Nouvelles versions pour Echo Dot, Echo Show et Echo Studio

On continue dans la domotique avec des renouvellements de produits existants.

À commencer par l’Echo Dot, la petite enceinte connectée ressemblant très fortement au HomePod Mini d’Apple. La petite boule intègre désormais un concentrateur domotique compatible Zigbee, Matter et Thread, ainsi qu’un répéteur Wi-Fi eero couvrant une surface d’environ 93 m² selon Amazon. La nouvelle mouture intègre également une puce Z23 d’Amazon, censée accélérer les traitements des commandes vocales sur l’appareil, puisqu’il est censé servir de pont entre les différents équipements connectés. La petite enceinte est vendue 99,99 dollars et réclame une nouvelle fois Alexa+.

L’Echo Studio reste sur son positionnement de version plus musclée de la Dot. La nouvelle version est présentée par Amazon comme son enceinte « la plus avancée », avec cette fois une caméra (13 mégapixels) et de l’intelligence visuelle. En clair, l’enceinte peut être utilisée comme caméra de surveillance lorsque l’on quitte le domicile et reconnaitre ce qu’elle voit. Cette reconnaissance s’applique à différents scénarios, comme la possibilité de lui montrer une boite de jeux pour en obtenir les règles. Ces fonctions ont besoin d’Alexa+. Un lien sera prochainement ajouté avec les équipements Fire TV pour transmettre les appels vidéo sur le téléviseur. Le tarif de lancement est de 249,99 dollars.

Amazon rappelle plusieurs éléments importants, comme la présence sur tous ses produits Echo d’un bouton physique permettant de désactiver les micros et caméras. En outre, des indicateurs sont fournis pour indiquer quand des données sont envoyées vers le cloud (une LED dans la nouvelle Echo Studio).

Enfin, Amazon renouvelle son Echo Show, son écran de contrôle pensé pour la cuisine. Il est maintenant équipé d’un écran 16 pouces et intègre pour la première fois Fire TV et une caméra à vision nocturne. L’appareil peut se mettre en plusieurs modes : organisateur familial, cadre photo ou encore tableau de bord domotique. Le cadre de l’appareil se veut 40 % plus fin que la gamme précédente et le prix débute à 499,99 dollars (en précommande). Pour ce prix élevé, le support mural et la télécommande Alexa sont fournis. Alexa+ est bien sûr de la partie.

Un plan 3D de la maison

L’Echo Show 16, dans son mode domotique, pourra en outre exploiter Alexa Home Map. Le service permet d’obtenir une vue 3D de sa maison pour y localiser tous les appareils connectés compatibles. « Vous pouvez contrôler les fonctions principales de l’appareil directement depuis la carte : tapoter pour éteindre les lumières, baisser le volume de votre musique ou vérifier vos caméras de sécurité », indique Amazon.

La création de cette carte commence avec l’adresse postale renseignée par l’utilisateur, pour obtenir une vue extérieure de la maison. Ensuite, il faudra se balader dans toutes les pièces avec un iPhone compatible (Android n’est pas encore pris en charge, pas même les propres tablettes Alexa d’Amazon) pour que le plan se dessine en temps réel. La fonction n’est cependant pas disponible immédiatement. Elle n’arrivera que plus tard dans l’année, sous forme de préversion.

Chacun ses apps, et les vaches...

Et si l’IA ouvrait grandes les portes d’une forme de réappropriation technologique ? Une certaine ironie, quand on connait ses effets sur le prix de la mémoire. Mais un nombre croissant de personnes se lancent dans des projets permettant de modifier en profondeur certains produits, notamment les TV connectées.

Il n’y a qu’à se plonger dans les dernières récriminations autour des téléviseurs connectés LG pour saisir l’agacement. Ces produits proposent de tout réunir dans une même interface, mais intègrent souvent de nombreux mécanismes de pistage pour mieux servir de la publicité sur mesure. Un mécanisme classique, non spécifique à cette gamme de produits connectés.

Si l’on en croit plusieurs sites comme TechCrunch et Tom’s Guide, un nombre croissant de développeurs en herbe ne sont plus disposés à accepter la situation. Dans un mouvement que l’on retrouve plutôt sur Windows habituellement, certains ont donc eu une idée : et s’ils modifiaient leur appareil pour supprimer tout ce qui ne leur plaisait pas ?

Ménage d’automne

L’effet est documenté depuis un moment déjà et ressort régulièrement, jusque dans les rapports de Linux Foundation : l’IA générative abaisse le ticket d’entrée. Comprendre par là qu’une idée peut rapidement se transformer en un code concret, les générations successives de modèles rendant l’opération de plus en plus simple.

La vague du « vibe coding » s’étend dans toutes les directions et nos confrères notent en particulier un front ouvert sur les TV connectées. Ainsi, le projet dumbtv annonce clairement la couleur : « Votre téléviseur doit faire ce pour quoi vous avez payé : vos applications, vos entrées HDMI, et rien d’autre. Pas de publicités directement sur la télé, pas de suivi des visionnages, pas de mise à jour que vous n’avez pas demandée ».

Sur le site dédié (en plus du dépôt GitHub), le projet se propose de remanier complètement les appareils sous Fire TV, dont les dongles Amazon. L’installation requiert un ordinateur, un accès réseau pour l’appareil visé ainsi que l’activation du mode ADB (Android Debug Bridge) sur ce même appareil. Après quoi, avec quelques manipulations, on peut en théorie supprimer les publications, les contenus sponsorisés, les techniques de création d’empreinte numérique (fingerprinting) et ainsi de suite.

Si le projet a rapidement dépassé les 1 700 étoiles sur GitHub, un autre a attiré encore plus les regards : CleanYourTV. Le dépôt correspondant dépasse les 43 000 étoiles et affiche fièrement sa médaille d’or obtenue comme dépôt le plus « tendance » de la semaine du 19 octobre. Et pour cause : le projet propose ni plus ni moins que de lancer un grand nettoyage sur votre TV connectée à la seule condition qu’elle embarque Android TV ou Google TV (toujours via le mode ADB).

En tant que tel, CleanYourTV ne désinstalle rien. Il cache les éléments et les désactive : télémétrie, services publicitaires et bon nombre de composants sont ainsi remisés au placard. Le choix de ne pas les désinstaller semble une mesure de sécurité, afin qu’un simple script de restauration puisse remettre la TV dans son état original. En revanche, l’outil installe son propre lanceur (décrit comme léger et natif), autrement dit l’interface principale avec les applications, dans une version plus sobre ressemblant fortement à l’Apple TV.

Une forme de réappropriation

Dans une série de tweets publiés le 17 octobre, l’auteur de CleanMyTV explique simplement avoir « vibe codé » la télé de ses parents. Elle affichait des publicités avant même de pouvoir atteindre Netflix. Le produit est un modèle Xiaomi selon ses dires, dont la référence a été donnée à Claude Code dans le prompt. L’appareil a été trouvé sur le Wi-Fi, aboutissant à la suppression de 25 composants Xiaomi. De là est née l’idée du projet et de sa mise à disposition (le code est sous licence open source MIT).

Ces projets ne sont pas isolés, on en trouve d’autres sur X, racontant tous la même histoire : un constat d’interface lente, des applications inutiles, des publicités trop nombreuses. Le désir est donc systématiquement le même, une reprise en main d’un produit payé mais dont l’expérience utilisateur s’est révélée insatisfaisante, voire franchement agaçante.

Dans la plupart des cas, on trouve Claude parmi les contributeurs des projets, confirmation que le projet a été largement accéléré par un agent. Les personnes derrière ces créations sont souvent elles-mêmes des développeurs, mais on peut se poser la question : se seraient-elles lancées dans ces opérations sans IA ?

« Ça ne me plait pas, donc je modifie »

La question est d’autant plus intéressante qu’elle permet d’entrevoir une longue liste de possibilités. The Verge a par exemple relevé récemment que le même vibe coding permettait à des passionnés des modifications poussées de produits utilisés dans la production musicale, via la création de firmwares personnalisés. Nos confrères indiquaient avoir remarqué une « explosion » de ces microgiciels sur le subreddit r/synthesizers. Précédemment, ce type d’opération nécessitait de vastes compétences, affirment nos confrères.

Sans tomber dans une longue liste d’exemples, l’IA semble avoir déclenché une vague d’interrogations sur une partie des produits qui nous entourent. Le développeur italien Carmine Paolino, par exemple, n’apprécie pas les technologies web dans les applications. Il a donc créé des versions natives pour plusieurs d’entre elles, en particulier pour Spotify et WhatsApp, avec respectivement Spotifast et ZapFast.

L’obtention de meilleures performances est un puissant moteur de motivation. Dans notre cas, nous nous amusons par exemple à créer un client alternatif et multiplateforme pour Mattermost (sur une base Rust, C# et Avalonia) pour explorer la manière dont on peut alléger la pression sur la mémoire vive, en particulier dans cette période d’explosion des prix. Sur cette petite application (qui se limite volontairement à la partie messagerie texte pour une seule équipe), la consommation tourne en moyenne autour de 130 à 150 Mo, contre 600 Mo en moyenne pour Mattermost, dont le client officiel est basé sur Electron (qui simplifie largement les problématiques de support multiplateforme).

Les mises en garde restent les mêmes

Mais attention, les bonnes performances ont beau être agréables, elles « n’excusent » pas tout. Point commun à pratiquement tous ces projets, ils s’attaquent à des produits commerciaux d’entreprises qui goûtent sans doute peu de voir leur matériel ou leur application ainsi modifiée. Des sociétés comme Spotify ou Meta (pour WhatsApp) pourraient voir d’un très mauvais œil l’arrivée de ces versions et modifier leur licence pour en interdire la fabrication. Mais qui sait, Meta pourrait tenir compte du message sous-jacent : des utilisateurs ne sont pas disposés à consacrer 1 à 3 Go de mémoire pour une simple messagerie.

En outre, si le phénomène peut être enthousiasmant dans tout son potentiel, il est facile de lancer des projets, beaucoup moins de les entretenir, et encore moins de le faire sérieusement. Les IA peuvent se tromper, des secrets peuvent se glisser dans le code et des erreurs énormes peuvent apparaitre, avec à la clé de possibles failles de sécurité béantes chez les utilisateurs. L’aspect systématiquement open source de ces travaux (toujours sous licence MIT ou Apache 2.0) limite en théorie la casse, mais la prudence reste de mise.

• #Nextquick : libre et open source ne sont pas synonymes de sécurité

Vitesse et précipitation

Une faille de sécurité critique a été découverte dans la plupart des firmwares UEFI utilisés dans les serveurs. Bien qu’elle ne requière pas d’authentification, il faut remplir plusieurs conditions pour l’exploiter, dont l’utilisation du PXE pour le démarrage réseau.

Quand on allume un ordinateur, un petit logiciel est d’abord chargé d’initialiser le matériel et de préparer les conditions au lancement du système d’exploitation. On l’a historiquement appelé « BIOS » (Basic Input/Output System), mais il s’agit depuis longtemps d’un microgiciel (firmware) nommé UEFI (Unified Extensible Firmware Interface). Parmi les fonctions apportées par ce firmware plus moderne, des fonctionnalités réseau en standard.

Dans la grande majorité des cas, les constructeurs n’écrivent pas leur UEFI depuis zéro. Ils se basent sur des travaux existants, en particulier EDK II, une base de code libre maintenue par le projet TianoCore. Presque tous les éditeurs de firmware – dont AMI, Insyde et Phoenix – s’en servent copieusement, y compris Project Mu, une variante renforcée (durcie) d’EDK II maintenue par Microsoft.

Or, c’est dans cette base EDK II que réside la faille.

Un débordement en mémoire

La faille en question, estampillée CVE-2026-97631, réside dans la fonction de démarrage réseau, ou PXE. Quand elle est activée, la machine ne démarre pas sur son disque, elle récupère son système sur un serveur distant. Ce mécanisme est largement utilisé dans les centres de données pour installer ou réinstaller en masse des serveurs.

Pendant ce démarrage réseau, le pilote PXE (NetworkPkg ou UefiPxeBcDxe) attend d’éventuels messages d’erreur ICMP. S’il en reçoit, il les copie dans une zone de mémoire de taille fixe, précisément 504 octets. Il existe deux variantes du code pour le réseau, une pour IPv4, l’autre pour IPv6. C’est là que réside le problème : dans les deux cas, la copie en mémoire continue même si le message d’erreur dépasse les 504 octets. En outre, le pointeur de destination avance sur la base du total cumulé au lieu de la taille du seul fragment copié.

Dans le scénario d’une attaque, un pirate peut donc exploiter ce mécanisme pour écrire un message trop long, avec des octets choisis en dépassement de la zone prévue en mémoire. Rien en amont ne limite la taille du message, renforçant l’ampleur du problème. Le pirate peut donc glisser des instructions dans ces octets, qui seront alors exécutées par le firmware UEFI.

Les conditions d’exploitation

La faille CVE-2026-97631 affiche un score CVSS 4.0 de 9,5 sur 10, soit très près du maximum. Le seul facteur limitant la portée de l’exploitation est l’obligation d’utiliser PXE, ce qui n’arrive que dans des environnements spécifiques, et a priori pas chez le grand public. Autre condition tout de même, il faut connaitre la version exacte du firmware que l’on veut attaquer.

Si ces deux conditions sont remplies, tout ce que le pirate a à faire est d’envoyer un message d’erreur ICMP spécialement conçu pour y glisser des commandes. Aucune authentification n’est nécessaire. De plus, puisque les commandes sont exécutées à un stade très précoce de la chaine de démarrage, ni Secure Boot ni le démarrage mesuré n’ont le temps d’intervenir.

C’est l’accumulation de ces deux éléments – aucune authentification et déclenchement avant tous les mécanismes de sécurité – qui donne son score de gravité à la faille. S’il parvient à exploiter la faille, le pirate a même le choix : se servir de la corruption mémoire pour provoquer une exception processeur et le blocage du démarrage, ou l’exécution du code qui aura alors le niveau de privilège le plus élevé. Même si ce code ne survit pas lui-même au redémarrage, il peut être utilisé pour installer des composants persistants.

Une divulgation « ratée »

La faille a été découverte par Alex Matrosov d’Anthropic et Dan Holmes-Mitra de Google, qui ont également fourni la solution recommandée. On ne sait pas quand cette découverte a eu lieu, mais la communication de l’équipe de TianoCore a entrainé une réservation de l’identifiant CVE le 24 septembre.

En théorie, les détails d’une telle vulnérabilité restent secrets jusqu’à ce que ces correctifs soient disponibles, mais il y a eu une erreur. Ars Technica parle de « divulgation ratée » : AMI a publié fin septembre une demande de modification publique qui décrivait la faille et contenait le correctif. Alex Matrosov et Dan Holmes-Mitra s’en sont aperçus, ont prévenu TianoCore, qui a alors décidé de rendre public l’avis de sécurité le 22 octobre.

En outre, bien que le correctif ait effectivement été proposé, les différentes parties s’étaient mises d’accord pour attendre une publication des détails en janvier. L’erreur d’AMI a précipité le calendrier, car le délai devait servir aux éditeurs de firmwares à proposer de nouvelles moutures. Il faut désormais surveiller ce que des entreprises comme Dell, Lenovo, SuperMicro ou encore HPE publient. Selon les cas, le mécanisme de mise à jour peut être plus ou moins complexe, mais il réclame dans tous les cas un temps d’immobilisation du serveur.

Les firmwares concernés sont a priori très nombreux, sur la base du code vulnérable d’EDK II. Ars Technica a interrogé Intel et Arm sur la portée du problème, les deux entreprises affirmant que leurs produits ne sont pas concernés. Nos confrères indiquent cependant que l’une comme l’autre utilisent amplement EDK II comme base de référence. Dans le cas d’Intel, le dépôt GitHub pour les binaires FSP (Firmware Support Package) mentionne clairement EDK II et TianoCore. Même chose pour Arm. D’autres entreprises comme AMD, Microsoft et Amazon n’ont pas répondu aux questions de nos confrères, mais elles sont très probablement concernées aussi.

La méfiance est donc de mise. Il est recommandé de dresser l’inventaire des machines utilisant PXE. Si parmi elles certaines l’ont activé sans l’utiliser, mieux vaut le désactiver pour supprimer la surface d’attaque. Si la fonction est nécessaire, il est recommandé de garder le trafic de démarrage sur un segment isolé du réseau, de surveiller les pages de support des constructeurs ou des éditeurs impliqués et de filtrer les messages ICMP inattendus.

Commençons par un rappel. OpenAI propose quatre gammes de modèles, du moins cher au plus « capable ». Luna est ainsi vendu comme le modèle le plus rapide pour les questions courantes, Terra comme le modèle à tout faire, Sol pour les tâches complexes et Astra pour les plus gros besoins. Si Astra a ouvert le bal de la génération de modèles GPT-6 début septembre, Luna et Sol ont suivi peu de temps après. Ne manquait plus qu’une mise à jour de Terra, resté sur GPT-5.6. C’est désormais chose faite.

Pour l’occasion, Terra passe directement sur GPT-6.1, comme Sol fin septembre. OpenAI présente son nouveau modèle comme rapide, capable de combiner raisonnement visuel détaillé et pilotage précis de l’ordinateur, le tout avec une rédaction plus naturelle. L’entreprise cite plusieurs cas d’utilisation, allant de la rédaction de propositions à l’interprétation de dessins techniques, en passant par le remplissage de formulaires et le montage vidéo.

L’accent est largement mis sur la tarification API. Le prix est ainsi de 1 dollar par million de jetons (tokens) en entrée et de 5 dollars en sortie (le double en mode Fast), contre respectivement 2 et 12 dollars pour GPT-5.6 Terra. Le tarif de l’écriture en cache est divisé par deux, à 1,25 dollar le million de jetons, tandis que le prix de la lecture est divisé par quatre, passant de 0,20 à 0,05 dollar. De manière générale, le nouveau Terra est annoncé comme deux fois moins cher que l’ancien.

« Avec un effort maximal, Terra est plus de trois fois plus efficace que Claude Opus 5.5 en matière d’utilisation des tokens, et son prix par token est quatre fois inférieur, ce qui se traduit par un coût par tâche environ neuf fois inférieur », vante ainsi OpenAI.

Sans surprise, GPT-6.1 Terra bat la génération précédente dans tous les tests. Selon OpenAI, il flirte même avec les étoiles d’Astra sur certaines tâches. Sur Terminal-Bench 4.0 en particulier, le score est plus que doublé par rapport à l’ancienne, passant de 21,5 à 50,3 %. Le modèle se veut également rapide, avec une exécution trois fois plus rapide que GPT-6.1 Sol sur Last Exam.

Artificial Analysis confirme les meilleures performances, avec un gain de 6 points dans son Intelligence Index en effort maximal, de 7 à 13 points sur des efforts moins importants, et un coût par tâche (toujours sur son propre benchmark) de 0,40 dollar, contre 1,40 pour la génération précédente.

OpenAI l’affirme également, son modèle se trompe beaucoup moins. Sur son benchmark interne, « le taux d’erreur avec un faible effort de raisonnement est passé de 53,6 % avec GPT-5.6 Terra à 16,7 % avec GPT-6.1 Terra, soit une baisse de près de 37 points de pourcentage. Avec un effort maximal, le taux d’erreur a baissé de 18 points de pourcentage pour atteindre 4,3 %, se rapprochant ainsi des taux de GPT-6 Astra et de GPT-6.1 Sol », indique OpenAI. Difficile d’en savoir plus sur la base d’un benchmark interne, donc non reproductible.

Le nouveau « modèle du quotidien » est disponible pour les personnes abonnées Plus, Pro, Enterprise et Edu, mais uniquement dans ChatGPT Work et Codex pour l’instant. On peut également y accéder via l’API sous le nom gpt-6.1-terra.

Beau bazar

Quel effet produit l’IA sur le développement open source ? Selon un rapport de la Linux Foundation, il est conséquent, entre augmentation de la production brute, abaissement du ticket d’entrée, obligation plus intense de relecture et épuisement d’une partie des personnes impliquées.

La question de la productivité et des transformations dans les processus est au cœur des questionnements autour de l’IA, les études, rapports et articles étant particulièrement nombreux depuis quelques mois. Dans les grandes lignes, les constats sont les mêmes : la production brute s’envole, mais l’IA impose sa « taxe de vérification », annulant une partie importante de ses bénéfices et ne débouchant pas sur une hausse des livraisons de produits finis dans les mêmes proportions.

• L’humain, goulot d’étranglement des gains de productivité par l’IA

La Linux Foundation souhaitait donc faire un point d’étape auprès de mainteneurs de projets open source, pour savoir comment leurs habitudes avaient changé, et surtout quels étaient les problèmes constatés. Une étude a ainsi été réalisée par Sam Boysel de la Linux Foundation et Anni Lai de Generative AI Commons, avec une préface de Brian Proffitt de Red Hat. L’entreprise a d’ailleurs financé le travail.

Un effet direct sur la production

Au cœur du rapport, on trouve un constat significatif : les effets de l’IA dépendent de la taille du projet. Ainsi, 59 % des mainteneurs ont observé une hausse du volume des contributions, le chiffre passant à 69 % dans les projets d’au moins 50 contributeurs. Un quart environ des demandes de fusion reçues sont jugées de faible qualité, 31 % dans les grands projets. C’est le fameux « slop » (ou bouillie) tant décrié, notamment par l’équipe de FFmpeg.

• FFmpeg, Google et la « bouillie » des rapports de bugs générés par IA

Sans trop de surprise, 52 % des mainteneurs indiquent que leur temps de relecture a augmenté, le chiffre passant à 64 % dans les grands projets. Dans ces derniers, l’épuisement est d’ailleurs devenu la première préoccupation, devant la qualité des contributions. Une nouvelle manifestation de la « taxe de vérification ». La vérification, justement, repose largement sur la confiance et l’inspection mutuelle, les attestations formelles se développant avec la taille du projet : 20 % dans les petits, 41 % dans les grands. Signe des temps : les trois quarts des mainteneurs interrogés ont indiqué recourir au moins partiellement à l’IA pour examiner les contributions reçues.

Une barrière d’entrée plus basse, mais une confiance dégradée

L’utilisation de l’IA au sein des projets est cependant très variable. 35 % seulement ont une politique écrite autorisant l’IA, 10 % l’interdisent, 23 % comptent en adopter une et le tiers restant n’a encore rien de prévu. Les politiques existantes portent surtout sur la divulgation et la responsabilité du contributeur (76 % chacune), beaucoup moins sur les licences (39 %). Les chiffres reflètent un paysage contrasté que nous avons pu voir à plusieurs reprises. Certains projets, dont Debian et le noyau Linux lui-même, n’ont plus aucun problème avec les contributions générées par IA, à condition que la personne qui les soumet soit en mesure de les expliquer. D’autres, comme Zig, Servo, Gentoo ou encore QEMU interdisent toute contribution générée par IA.

• Debian ne dit pas non à l’IA et divise la communauté

D’autres données intéressantes sont présentes dans le rapport. Par exemple, l’IA est utilisée dans toutes les étapes du développement : nouvelles fonctionnalités (83 %), débogage et tests (78 %), refactorisation (71 %), ou encore documentation (69 %). Sans surprise une fois de plus, les principaux gains de temps observés sont à 52 % sur l’écriture du code, mais les mainteneurs évoquent des gains se réduisant avec la complexité du projet. Sur les tâches complexes, 21 % indiquent même mettre plus de temps qu’avant.

Si les mainteneurs estiment à 71 % que l’IA abaisse la barrière d’entrée, elle dégrade aussi la confiance au sein de la communauté pour 53 % d’entre eux, quand 13 % seulement y voient une amélioration. Dans le même domaine, 46 % pensent que le besoin d’accompagnement des nouveaux venus dans un projet est supérieur.

La Linux Foundation avance ses recommandations

Le rapport, fourni très officiellement par la fondation, comporte huit recommandations applicables à tout projet libre. On y retrouve des prises de position déjà observées dans certains projets, qui sont également autant de constats faits par le rapport auprès des mainteneneurs :

• établir une politique claire et écrite sur les contributions assistées par IA et sur le signalement des vulnérabilités ;
• donner la priorité, dans cette politique, aux exigences de transparence et de divulgation. Les contributeurs doivent indiquer clairement et de façon constante aux mainteneurs les outils d’IA générative utilisés ;
• reporter la charge de la vérification sur les contributeurs, en exigeant une attestation sur l’honneur, des tests et une documentation des modifications assistées par IA avant leur soumission ;
• normaliser les pratiques d’attribution des contributions assistées par IA, afin que la divulgation ne reste pas laissée à l’appréciation de chacun. Une solution serait d’adopter et d’imposer le format « Assisted-by: » dans les commits ;
• utiliser l’IA comme outil de maintenance : les outils d’IA peuvent servir à trier, résumer et signaler les problèmes dans les contributions reçues, pour alléger la relecture et réduire l’épuisement des mainteneurs ;
• continuer d’investir dans l’accompagnement humain des nouveaux contributeurs : l’IA générative abaisse la barrière d’entrée, mais elle augmente le besoin d’encadrement une fois ces contributeurs arrivés, au lieu de le réduire ;
• mettre en balance les gains d’accessibilité apportés par l’IA générative et son coût pour la confiance au sein de la communauté, et concevoir des règles de contribution qui accueillent les nouveaux venus sans sacrifier la qualité ni la confiance ;
• une gouvernance de qualité et la confiance comptent davantage que l’amélioration des performances techniques.

En somme, chaque projet devra faire ses propres choix, car ces propositions ne sont pas des obligations. La Linux Foundation n’a d’ailleurs aucun pouvoir en la matière, l’un des principaux buts de la structure étant d’aider et de fournir des ressources, en plus de son effet structurant.

Entre conseils déclaratifs et « combattre le feu par le feu »

Certains points peuvent d’ailleurs faire hausser quelques sourcils. Par exemple, la recommandation d’utiliser le format « Assisted-by: » dans les commits est fait en référence directe au noyau Linux. Or, les mainteneurs de ce dernier ont récemment décidé de ne plus le rendre obligatoire. Linus Torvalds, en particulier, s’est montré très clair sur la question, avec une certaine véhémence face à un mainteneur du noyau qui militait pour préserver cette obligation. Même si le rapport a été clos en juin dernier, il ne tient pas compte de ce changement, qui reste antérieur à la publication de la Linux Foundation.

• Pour Linus Torvalds, le code généré par IA est légitime, à condition de savoir le lire

Cette synthèse affiche également plusieurs faiblesses. Outre son aspect purement déclaratif, le profil des mainteneurs interrogés est particulier, les répondants ayant été recrutés via les canaux de la fondation. 52 % des interrogés ont ainsi 11 ans ou plus d’ancienneté comme contributeurs et 75 % utilisent l’IA quotidiennement, tous usages confondus. En outre, les secteurs d’activité dominants sont les systèmes d’exploitation et l’infrastructure. On est donc plutôt face à un groupe de développeurs expérimentés, loin des contributeurs occasionnels, ce qui éloigne d’autant la vue de synthèse du paysage open source.

Le rapport apporte néanmoins plusieurs bénéfices, notamment des données chiffrées sur un sujet jusqu’ici traité surtout à travers quelques incidents et prises de position. Il montre aussi que la charge se concentre sur les grands projets et les équipes de mainteneurs, qu’il existe un retard manifeste sur la gouvernance des projets, ou encore que les tâches complexes n’affichent aucun gain voire prennent plus de temps.

Surtout, le rapport enfonce un peu plus le clou sur le glissement des coûts de la production de code vers sa vérification. Mais il pose aussi une question sans la trancher : comment préserver la confiance si l’IA élargit le vivier de contributeurs tout en affaiblissant les signaux qui permettaient de juger une contribution avant de la lire en détail ? Le libre se retrouve dans une position inconfortable, assis entre deux chaises, entre relecture systématique et filtrage à l’entrée pour les nouveaux venus.

Enfin, le rapport évoque dans son résumé du début une recommandation qu’il ne reconduit pas dans sa liste finale : « combattre le feu par le feu ». En d’autres termes, les mainteneurs devraient eux aussi utiliser l’IA comme premier maillon de la chaine de vérification, afin de retrouver du temps.

Nouvelle mouture pour le logiciel open source d’enregistrement vidéo et de streaming en direct, avec bon nombre de nouveautés à la clé. L’un des plus gros changements se situe sous le capot, avec la mise à jour de CEF (Chromium Embedded Framework), le composant utilisé pour les sources navigateur et les panneaux ancrables. Il passe de la version 127/6533 à la 150/7871, soit un cumul de plus de deux ans de modifications.

On reste sous le capot avec une série d’améliorations, comme l’activation par défaut de NVENC (NVIDIA Encoder) sur ARM64, la présence des derniers SDK NVIDIA Broadcast pour les effets audio et vidéo, une meilleure détection des jeux en plein écran, une gestion améliorée de la transparence de la capture d’écran sur macOS, un découpage amélioré des fichiers MP4/MOV hybrides, ou encore une mise à l’échelle du débit audio selon le nombre de canaux pendant un enregistrement simple.

Côté interface, la nouveauté majeure est la nouvelle gestion des plugins. Les extensions natives sont ainsi regroupées dans un nouveau dossier core, tandis que les plugins tiers ont un nouvel emplacement et une nouvelle arborescence. Attention, les extensions tierces existantes sont encore chargées depuis les anciens emplacements, mais uniquement jusqu’à la prochaine version 34, qui bloquera ce scénario. L’équipe d’OBS a mis à disposition une page explicative à ce sujet, avertissant les développeurs qu’ils doivent mettre à jour leur code pendant l’intervalle, sans quoi leurs plugins ne seront plus chargés.

Parmi les autres améliorations, signalons-en plusieurs pour l’interface. Par exemple, pour l’accrochage des sources dans l’aperçu, un indicateur visuel a été ajouté. L’accrochage se fait désormais sur l’ensemble de l’axe et plus seulement au contact, tandis que les sources masquées sont ignorées. On remarque aussi l’apparition de raccourcis clavier pour l’écoute audio, l’ajout d’une vérification des codeurs manquants au chargement des profils, ou encore des soucis corrigés avec les champs numériques à incrément, dont la saison pouvait parfois se bloquer ou les nombres se tronquer.

Dans les notes de version, on peut également voir un « nettoyage » assez prononcé pour cette version, qui abandonne de nombreux composants, voire plateformes. Ubuntu 24.04 n’est ainsi plus pris en charge. Pour les utilisateurs concernés, il est donc nécessaire de migrer vers la version 26.04, dont le chemin de migration s’est ouvert il y a moins d’un mois. L’utilisation de la version Flatpak permet de contourner ce problème. OBS Studio 33 écarte en outre toutes les versions 6.X et 7.X de FFmpeg, ainsi que toutes les moutures de Qt entre la 6.4 et la 6.9.

• Télécharger OBS Studio 33

À noter que la nouvelle mouture est présente sur le dépôt GitHub du projet depuis trois jours mais n’a pas encore été répercutée sur le site officiel au moment où nous publions cet article.

« Taxe de vérification »

L’interrogation est croissante : les investissements dans l’IA sont-ils suivis d’effets tangibles sur la productivité ? Si l’on en croit le gestionnaire d’actifs Apollo Global Management, pas encore, la « faute » au facteur humain.

Apollo Global Management est l’un des principaux gestionnaires d’actifs alternatifs au monde. Il est aussi un important financeur des infrastructures de l’IA. En janvier 2026 par exemple, ses fonds ont mené un financement de 3,5 milliards de dollars pour l’acquisition de processeurs GB200 de NVIDIA loués à une filiale de xAI (devenu entre-temps Space XAI puis SpaceXSI).

Aussi, quand l’économiste en chef, Torsten Slok, publie un billet le 24 octobre sur les gains de productivité sous l’influence de l’IA, beaucoup tendent l’oreille. Qu’en dit Slok ? Qu’en dépit des investissements massifs, l’intelligence artificielle n’aurait produit aucun gain financier pour les entreprises américaines en dehors du secteur technologique.

Hors tech, point de salut ?

Le billet a été publié dans le cadre de sa lettre quotidienne The Daily Spark. Il se base essentiellement sur cinq facteurs.

Le premier, et le plus important, est que le chiffre d’affaires par salarié augmente bien pour les sept grandes valeurs technologiques, surnommées « les sept magnifiques », ou « Mag 7 » (Alphabet, Amazon, Apple, Meta, Microsoft, NVIDIA et Tesla). En revanche, il stagne pour les 493 autres sociétés du S&P 500.

Il note d’autres éléments participant à cet avis, notamment une même divergence pour les marges bénéficiaires. En outre, la productivité globale des facteurs (PGF) ne montrerait aucune accélération, Torsten Slok utilisant la série corrigée du taux d’utilisation de la Fed de San Francisco. Enfin, non seulement les dépenses d’IA sont très concentrées, mais elles sont également circulaires, un point abordé plusieurs fois dans nos actualités.

• IA : la valse des contrats entre NVIDIA, OpenAI et consorts ravive les craintes d’une bulle
• Les patrons de l’IA appellent à lever le pied, leurs dépenses disent l’inverse

« Les entreprises soutenues par le capital-risque dépensent de plus en plus pour les tokens, mais l’entreprise américaine grand public n’a pas besoin du dernier modèle et refuse de le payer. Tant que les dépenses en IA agentique et en tokens seront limitées à une petite partie de l’économie, les effets macroéconomiques de l’IA seront très limités », assène l’économiste.

Pourquoi si peu de mouvement dans la productivité ? Selon Torsten Slok, l’IA a beau « être une excellente calculatrice », l’intelligence en entreprise « est surtout un jugement », qui lui-même dépend du contexte : « l’IA ne comprend pas la responsabilité, la confiance, la culture, les règles non écrites, les compromis éthiques ou l’équité, qui façonnent tous le risque réputationnel et favorisent finalement la croissance des revenus et les marges bénéficiaires ».

Pour l’économiste, « l’histoire de l’IA sera décidée dans le S&P 493 » (le S&P500 sans les « sept magnifiques »). Pour l’instant, l’IA serait surtout visible dans l’investissement et les valorisations, mais ne se traduirait pas encore en productivité.

L’humain, ce goulot d’étranglement

On peut relier en partie ces observations à d’autres relevées par le New York Times le 10 octobre. La journaliste Sarah Kessler y posait la question : si l’IA est censée « anéantir des tâches inutiles et rendre des professions entières obsolètes », pourquoi ne le constate-t-on pas sur le terrain ? Elle cite une récente enquête auprès de 6 000 cadres supérieurs, et dont 90 % ont estimé que l’IA « n’avait aucun impact, ni sur l’emploi ni sur la productivité ». Elle citait également un précédent de Torsten Slok, selon qui « le rendement productif de l’IA reste une prévision plutôt qu’une observation ».

Sur le pourquoi, le New York Times propose deux facteurs. Le premier est le plus simple : les entreprises ont besoin de temps pour s’adapter et faire évoluer leurs processus. Le second est plus complexe : une « taxe de vérification ». Ce phénomène, également appelé « botsitting », désigne la tâche de vérifier que les résultats produits par l’IA sont exacts, sûrs et donc utilisables. L’article cite notamment une étude de Workday auprès de 3 200 employés et dirigeants, selon laquelle 37 % du temps gagné par l’IA étaient réinvestis dans la vérification, la correction, la clarification ou la réécriture des résultats.

Ce goulot est d’autant plus complexe que les modèles progressent et accomplissent de nouvelles tâches. Si les sorties des LLM se font plus riches et plus complexes, la vérification devra évoluer également. Interrogé, Ian Stoica, professeur d’informatique à l’université de Berkeley (Californie), résume le problème : « Vous ne pouvez pas vérifier si vous ne comprenez pas le problème ». Le niveau d’expertise devra donc lui aussi évoluer.

Le cas particulier du logiciel

Ce goulot d’étranglement se retrouverait particulièrement dans le domaine du logiciel, sans doute le domaine d’application le plus avancé de l’IA aujourd’hui. Si l’on retourne en juin, une étude MIT-Wharton mettait ainsi en avant une hausse de 180 % de l’activité de programmation par l’utilisation d’agents asynchrones, mais cette dernière ne se traduirait que par une augmentation de 30 % du nombre de versions effectivement publiées.

Selon l’étude, ce n’est pas une surprise, car le résultat de chaque étape dans la chaine complète de production doit être combiné avec l’effort humain nécessaire à l’étape suivante. Ainsi le code produit par l’IA doit encore être vérifié, intégré, testé et publié. L’expertise et le jugement humains ont un coût, qui s’intercale entre toutes les étapes. L’étude faisait également ressortir un autre indicateur intéressant : ces efforts ne se traduisent pas par une hausse de l’utilisation finale des produits. Même en mettant de côté l’inévitable adaptation des processus, l’attention des consommateurs reste une ressource rare, d’autant plus dans un monde foisonnant d’opportunités nouvelles.

Le 9 octobre, Ars Technica relayait une autre étude, cette fois de deux économistes d’Harvard, Fiona Chen et James Stratton, et traitant des goulots d’étranglement dans le domaine du logiciel. Si celle du MIT-Wharton travaillait sur les historiques de GitHub et les données internes de Microsoft, celle des deux économistes se base sur les tickets et les grands ensembles fonctionnels résolus dans Jira, plutôt que les versions publiées.

Pourtant, dans les grandes lignes, les constatations sont les mêmes. L’étude d’Harvard met ainsi en avant une hausse de 30 % de la production de lignes de code, de 20 % dans les validations et de 23 % pour les demandes de fusions, mais aucun changement statistiquement significatif dans la résolution des tickets.

Si les signaux semblent tous aller dans le même sens, ils jettent ainsi un éclairage plus cru sur l’un des éléments pointés par Torsten Slok. Le chiffre d’affaires par salarié chez les « sept magnifiques » apparait ainsi comme une conséquence des ventes de services IA et d’infrastructures, mais pas directement d’un gain de productivité.

Il suffira de changer de matériel

Windows 11 introduit la prise en charge d’instructions matérielles qui promettent une hausse générale des performances. Ces instructions, APX, n’équipent cependant aucun processeur aujourd’hui.

Le 23 octobre, Microsoft a publié la build 29695 dans le canal Expérimental de son programme Windows Insider. Si cette préversion contient bon nombre d’améliorations en lien avec l’accessibilité et le contrôle parental, elle présente une nouveauté nettement plus discrète, presque cachée dans les options pour développeurs : le support des instructions APX.

APX double les registres généraux

Un peu de contexte. En 2024, Intel et AMD ont formé le x86 Ecosystem Advisory Group (x86 EAG), dont l’objectif est faire évoluer le jeu d’instructions x86-64 de manière concertée, afin d’établir une plateforme matérielle cohérente. C’est d’ailleurs dans ce cadre qu’Intel avait abandonné son projet de x86S.

Le 27 août 2025, Robert Hormuth, vice-président d’AMD, publie un message sur LinkedIn pour informer que l’EAG a déjà produit ses premières technologies : le nouveau modèle d’interruption FRED (Flexible Return and Event Delivery), ainsi que les instructions AVX10 et APX.

Si les différentes variantes d’AVX sont orientées vers le calcul vectoriel, l’objectif d’APX est au contraire d’augmenter les performances du code général. APX n’est pas directement issu de l’EAG puisqu’Intel avait présenté ces instructions en juillet 2023. Un processeur compatible APX dispose de 32 registres généraux, contre 16 aujourd’hui.

Selon Intel, un code compilé avec APX permet de réduire les lectures de 10 % en mémoire et les écritures d’au moins 20 %, comparé à un code compilé x86_64 standard. En outre, les instructions entières peuvent désigner un registre de destination distinct via un format à trois opérandes qu’Intel nomme NDD dans sa documentation. Cet ajout permet d’éviter l’écrasement d’une des sources et de réduire les copies de registres.

En outre, le code APX compte environ 10 % d’instructions en moins, la densité du code étant similaire malgré des préfixes plus longs. Notons aussi qu’APX élargit le jeu d’instructions conditionnelles de x86 pour limiter le coût des erreurs dans la prédiction de branchement.

Retour à Windows

C’est le support de ces instructions que Microsoft vient d’ajouter à sa dernière build dans le canal Expérimental. Ce qui veut dire que la firme commence effectivement à compiler le code du système avec APX. On peut activer ce support dans les options pour développeurs, laissant une interrogation en suspens : pourquoi passer par un paramètre si le code est prêt ?

Bien que l’on puisse se réjouir d’un tel support, l’enthousiasme fait face à une barrière matérielle : aucun processeur actuel ne supporte les instructions APX.

Chez Intel, il va falloir attendre en effet la génération Nova Lake, toujours censée arriver fin 2026 (avec le nouveau socket LGA 1954). Tom’s Hardware indiquait cependant en juin dernier que, selon plusieurs sources, un lancement au premier trimestre 2027 était plus probable, via la série Core Ultra 400. Côté AMD, on ignore encore quand arrivera le support d’APX. Peut-on l’espérer pour les processeurs de bureau Zen6 ? Dans l’absolu oui, mais avec de grosses pincettes : AMD respecte habituellement la parité sur les instructions entre ses puces EPYC et Ryzen, et les puces EPYC Zen6 (Venice) ne possèdent pas (a priori) les instructions APX.

En d’autres termes, si les instructions promettent une hausse générale des performances (sans doute très variable selon les scénarios), Microsoft ne fait que préparer le terrain. On peut imaginer que le lancement des processeurs Nova Lake s’accompagnera d’une campagne marketing pour encourager le grand public (ou les entreprises) à se tourner vers de nouveaux achats, en misant sur ces améliorations.

Notez enfin que Microsoft n’est pas le premier acteur à réagir sur les instructions APX. Leur prise en charge initiale a commencé en effet dans le noyau Linux à partir de sa version 6.16.

En 2009, Microsoft lance The Garage, un drôle d’ovni. L’idée est simple : les employés devraient pouvoir développer leurs projets personnels, tout en profitant des conseils et infrastructures de l’entreprise. Un groupe expérimental d’où de nombreuses idées vont fuser.

En 2014, The Garage prend une tout autre dimension. Le nouveau CEO de Microsoft, Satya Nadella, considère alors le groupe comme une très bonne initiative. Cette année, Microsoft organise ainsi, pour la première fois de son histoire, un hackathon. 11 000 personnes de 80 pays vont y participer, consacrant le succès de l’opération.

En 17 ans d’existence, The Garage a vu fleurir de nombreuses idées, dont plusieurs ont finalement été intégrées à des offres commerciales ou endossées très officiellement par Microsoft. C’est par exemple de ce groupe expérimental qu’est issu Arrow Launcher pour Android, qui finira par devenir Microsoft Launcher. Autre outil qui a connu une belle histoire, Mouse without Borders, qui permet de contrôler plusieurs PC depuis un seul duo clavier/souris, et intégré aux PowerToys depuis 2023.

On pourrait aussi citer Journal, le clavier pour iOS Word Flow, ou encore l’application de prise de notes Plumbago, autant de projets depuis arrêtés ou intégrés sous une autre forme. D’autres sont devenus des produits à part entière, comme Azure Quickstart Center, Azure Resource Graph, Microsoft Health Bot Service ou Video Indexer.

Pourquoi fermer aujourd’hui The Garage ? Selon GeekWire, qui dit avoir eu accès à la FAQ interne sur le sujet, Microsoft estimerait que l’innovation n’est aujourd’hui plus limitée à ce type de groupe, mais survient « chaque jour au sein de chacune de nos équipes ». Les espaces physiques dédiés au Garage commencent ainsi à être fermés dans les locaux qui en avaient développés, les employés ne pouvant emporter aucun équipement présent sur place.

Si l’on en croit GeekWire, la décision est bien sûr controversée. Sur le service Blind, qui sert à commenter anonymement les conditions de travail dans une entreprise, un billet était ainsi intitulé « Amy kills the Garage », en référence à Amy Hood, directrice financière de Microsoft. Sur cette publication depuis supprimée, certains commentaires faisaient l’éloge de ces structures, qui permettaient notamment de rencontrer du monde et de créer des connexions professionnelles. Toujours selon nos confrères, un commentaire indiquait : « Les espaces Garage étaient l’un des derniers trucs cools chez Microsoft ».

Signal a corrigé dans RingRTC, sa bibliothèque d’appels, une faille qui empêchait le raccrochage de clore réellement l’appel. Le correctif date du 4 septembre, mais la divulgation publique n’est intervenue que le 20 octobre 2026.

La faille est estampillée CVE-2026-113380 et réside donc dans RingRTC, la bibliothèque logicielle créée par Signal (en open source) responsable des appels vocaux et vidéo. Elle affecte toutes les versions antérieures à la 2.72.0 et est critique, avec un score CVSS v4.0 de 9,3 sur 10.

Avec une version vulnérable, un pirate peut exploiter la faille en saturant la file d’attente de la machine à états finis (FSM) d’un appel pour empêcher le raccrochage local de démonter l’appel. Selon les cas, cela signifie que la piste audio, voire vidéo, continue. Le chiffrement de bout en bout n’est pas affecté, car le défaut porte sur la fermeture de l’appel, pas sur la protection des conversations.

Selon les notes du chercheur a priori à l’origine de la découverte, trois problèmes se cumulent, comme relevé par SecurityWeek. Ils sont loin d’être anodins :

• le raccrochage n’était pas un arrêt immédiat mais un évènement de plus dans la file d’attente ;
• il n’y avait aucune limitation de débit sur les évènements provenant du pair distant ;
• l’évènement de raccrochage n’avait aucune priorité.

Le correctif du 4 septembre ajoute ainsi un indicateur de terminaison séparé, avec sa propre priorité, et limite à 5 secondes les attentes lors de l’arrêt pour que le nettoyage continue même si certaines opérations échouent.

Cependant, la situation sur les nouvelles versions des différentes applications n’est pas claire. On ignore quand le correctif a été déployé, ni même s’il a bien été distribué. Nous avons contacté la fondation Signal et mettrons à jour cet article en cas de réponse.

Le gestionnaire de mots de passe 1Password ajoute une nouvelle corde à son arc. Dans un billet publié le 22 octobre, l’entreprise a présenté une nouvelle plateforme baptisée « 1Password for Agents » pour fluidifier l’utilisation des identifiants stockés dans la base, mais sans les voir.

Dans le scénario décrit par 1Password, un agent arrive sur un formulaire de connexion. Il interroge alors le gestionnaire de mots de passe, déclenchant une demande d’approbation par l’utilisateur. Si ce dernier confirme, 1Password remplit lui-même les champs d’identifiants, l’agent n’ayant pas accès à ces informations.

Pour réaliser l’opération, l’agent s’authentifie auprès de 1Password via une clé unique propre. Quand la connexion est faite, le gestionnaire supprime l’identifiant de la page pour que l’agent ne puisse jamais le voir ou le réutiliser. Dans le cas où plusieurs identifiants correspondent à un même formulaire, l’utilisateur est invité à choisir l’agent à utiliser. Ce dernier n’accède pas non plus au reste du coffre.

Ce mécanisme est clairement une évolution du complément 1Password for Claude lancé en juillet. Cette fois cependant, il s’agit d’une plateforme disposant d’intégrations pour Muse de Meta, Claude Duet d’Anthropic, ChatGPT Work et Dots d’OpenAI, Grok Bot de SpaceXSI (anciennement SpaceXAI, encore plus anciennement xAI) et Townie de Town. Selon les cas, la compatibilité est en cours de déploiement ou doit arriver « bientôt ». 1Password prévoit également l’intégration dans Instinct, Browserbase, Browser Use, Dana, KERNEL, Perplexity, Ramp, Tomo et Wajo.

1Password prévient toutefois que ce mécanisme ne sert qu’à protéger les identifiants, pas à contrôler l’agent lui-même. L’entreprise ne peut pas agir sur ce que l’agent fera avec ces identifiants, mais le problème était exactement le même en entrant manuellement les mots de passe pour réaliser une opération.