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.

Mise à jour du 23 octobre : La version finale de KeePassXC est désormais disponible au téléchargement. Comme prévu, elle introduit le remplissage automatique des identifiants dans les applications sur Linux au sein des sessions Wayland (via XDG Portals), marquant une nette hausse du confort d’utilisation pour les personnes concernées.

On y retrouve également le portage vers Qt 6, le déverrouillage rapide via Polkit, des raccourcis configurables, le support de la génération de clés RSA, ECDSA et Ed25519 dans l’agent SSH, améliore l’intégration au bureau pour la version AppImage, ou encore introduit une AppImage pour les configurations ARM64.

---

Article original du 25 septembre  :

Le gestionnaire de mots de passe KeePass XC est une variante multiplateforme de KeePass, avec comme objectif une plus grande richesse fonctionnelle de base, sans passer par des plugins. La version 2.8, en préparation et dont une bêta vient de paraitre, s’annonce déjà comme une mouture majeure.

KeePass XC 2.8 bénéficie en effet d’un portage vers Qt 6, avec à la clé une modernisation de son interface et de ses intégrations dans les différentes plateformes prises en charge. Parmi les améliorations, on note surtout l’arrivée de l’auto-remplissage (fonction Auto-Type) pour les sessions Wayland, c’est-à-dire la capacité à insérer rapidement un identifiant et un mot de passe dans la fenêtre d’une application.

L’ajout est majeur, car Wayland ne permet plus « d’espionner » simplement une fenêtre active pour savoir si elle présente des champs d’authentification. La compatibilité annoncée va se faire à travers les portails XDG, ce qui revient à demander l’autorisation à Wayland d’examiner la fenêtre et d’y insérer des informations. L’équipe de KeePass XC avertit que ce support dépend pour l’instant de l’environnement choisi : support complet pour KDE 6.6 +, initial pour GNOME 48 + et dépendant du support des portails XDG dans les autres (Sway, Hyprland, labwc…).

Les autres améliorations sont nombreuses, avec par exemple l’arrivée d’une version compilée nativement pour les systèmes Windows ARM64 (y compris pour la version portable), une meilleure intégration sur Linux via l’AppImage, la possibilité de montrer des suggestions quand on ajoute des attributs, le support des clés d’accès (passkeys) dans les statistiques, la synchronisation des bases de données distantes via des outils tiers, des raccourcis clavier personnalisables ou encore le déverrouillage rapide sur macOS et Linux, respectivement via le mot de passe et Polkit. Enfin, plusieurs vulnérabilités ont été corrigées.

Pour les utilisateurs aventureux, le téléchargement de cette première bêta peut se faire depuis l’annonce officielle.

Oups ?

La Zero Day Initiative de Trend Micro a envoyé six rapports de failles de sécurité sur des listes de diffusion publiques du noyau Linux, avec de nombreux détails. Le caractère accidentel de ces publications est contesté. Le danger, bien que limité, est réel pour certaines configurations.

Les 21 et 22 octobre, six rapports de vulnérabilités ont été envoyés par Trend Micro sur des listes publiques rattachées au développement du noyau public. Plus précisément, ces rapports ont été adressés à la liste de sécurité privée du noyau, mais les listes publiques linux-kernel, linux-cifs, netdev et dri-devel figuraient en copie. Les détails techniques, avec les chemins de code et les traces KASAN, sont depuis publics alors qu’aucun correctif n’est encore publié.

Six vulnérabilités, dont deux critiques

Parmi les rapports, deux concernent des failles critiques dans ksmbd. La première, estampillée par Trend Micro ZDI-CAN-33774, réside dans une situation de compétition dans l’affectation de la table de traitement. Si l’on envoie une rafale de paquets SMB1 courts suivie d’un paquet SMB2 dans la même écriture TCP, les processus de travail traitent alors les données SMB1 avec un gestionnaire SMB2, qui va lire au-delà de la mémoire tampon. Une écriture hors limites devient ainsi possible, à condition que le pirate ait accès à un partage, mais aucune autorisation n’est nécessaire, expliquant le score CVSS de 9 sur 10.

L’autre faille, ZDI-CAN-33549, est un dépassement par le bas d’un entier (integer underflow) dans le chemin SMB Direct de ksmbd. Un client peut envoyer des descripteurs de tampon RDMA dont le premier est plus long que la charge annoncée. Le compteur de taille du serveur repasse alors par zéro et une copie mémoire déborde ensuite du tampon alloué. Pour l’exploitation en revanche, il faut réunir trois conditions : une interface compatible RDMA (matérielle ou le pilote logiciel rxe), un partage ksmbd accessible en écriture et un client qui négocie SMB Direct. À noter cependant que le support de SMB Direct est une option, désactivée par défaut. Le score CVSS est quand même de 9, confirmant la criticité de la brèche.

Ces notes sont attribuées via CVSS 3.1, le caractère critique débutant à 9. Trois autres failles – ZDI-CAN-33367, ZDI-CAN-34068 et ZDI-CAN-34076 – sont tout de même dans la tranche élevée, avec des notes comprises entre 7,8 et 8,8. Elles concernent respectivement une élévation locale de privilèges dans skb_zerocopy (réseau), une élévation locale de privilèges dans le pilote de GPU virtuel vmwgfx (VMware) et une divulgation d’informations dans nvmet (un pilote NVMe). La sixième faille, ZDI-CAN-32005, est un dépassement de pile (stack overflow) dans ConnMan, mais aucun score CVSS n’est rattaché.

Bien que le danger soit limité à certaines configurations spécifiques (ksmbd est un serveur compatible Samba mais n’est pas Samba), il est réel. Dans le contexte de publication de ces failles, il est probable qu’aucun correctif ne sera disponible avant plusieurs semaines.

Accident ou respect des nouvelles règles du noyau ?

Phoronix est le premier site à s’être rendu compte de ces publications. Pour nos confrères, il s’agissait clairement d’une bourde importante. D’ailleurs, Greg Kroah-Hartman en personne, le mainteneur principal du noyau Linux, s’est étonné et agacé dans des réponses à ces publications. Sur le pilote GPU VMware par exemple, il a répondu : « Pour une raison quelconque, vous avez envoyé cela dans des listes publiques, sans correctif, donc nous ne pouvons pas faire grand-chose avec ça ». L’agacement est monté d’un cran sur le rapport du pilote NMVe : « Encore une fois, pas de correctif, et envoyé sur une liste publique ? Merci de corriger votre processus de soumission… ».

Mais en dépit de ces réponses, certains médias s’interrogent : s’agissait-il vraiment d’un accident ? Cyber Kendra note ainsi que les rapports attribuent clairement la découverte des failles à TrendAI, le scanner IA de vulnérabilités de Trend Micro. Or, selon la documentation sur les failles de sécurité dans le noyau, réécrite et fusionnée pour le noyau Linux 7.1, indique que toute vulnérabilité trouvée grâce à l’IA doit être considérée comme publique et envoyée aux mainteneurs concernés plutôt que sur la liste privée.

Nos confrères rappellent que cette règle est une conséquence directe de l’agacement de Linus Torvalds sur le caractère « presque totalement ingérable » de la liste privée de sécurité depuis l’émergence des outils IA. Mais selon ces mêmes directives, les découvreurs de failles doivent joindre des correctifs ou des analyses d’impact. Les rapports de Trend Micro ne contenaient ni l’un ni l’autre, expliquant en partie l’agacement de Greg Kroah-Hartman.

The Hacker News évoque les mêmes règles et ne mentionne d’ailleurs jamais le caractère éventuellement accidentel de ces publications.

Nous avons contacté Trend Micro et mettrons à jour cette actualité si nous obtenons une réponse.

Coucou Amazon, coucou NVIDIA

Alors qu’AWS vient de lancer son TorchNeuron pour permettre aux entreprises intéressées d’entrainer leurs modèles sur les puces maison Trainium, Google a fait une annonce similaire avec TorchTPU. Comme le nom l’indique, il s’agit cette fois d’orienter les calculs vers les puces TPU fournies par Google. Celle-ci met cependant en avant son partenariat avec Meta pour PyTorch.

Google propose désormais sa propre pile logicielle permettant d’exécuter PyTorch directement sur ses TPU, sans passer par une couche d’adaptation. L’annonce, faite durant la PyTorch Conference 2026, suit de près celle d’Amazon Web Services avec son TorchNeuron.

• Avec TorchNeuron, Amazon veut faciliter l’entraînement des modèles sur ses puces Trainium

Rappelons que PyTorch est une bibliothèque permettant, entre autres, de construire et d’entrainer des modèles IA. Comme nous l’indiquions dans notre actualité sur TorchNeuron, PyTorch a besoin d’une couche intermédiaire pour traduire les opérations en instructions reconnues par le matériel. Dans la grande majorité des cas, cette couche est CUDA, une technologie propriétaire que NVIDIA travaille depuis longtemps pour s’assurer que tous types de calculs pourront être exécutés sur ses GPU.

• Pourquoi tout le monde se jette encore sur les GPU NVIDIA pour l’IA

Au tour des puces TPU

Si l’objectif d’AWS avec TorchNeuron était de pouvoir rediriger ces calculs facilement vers ses puces Trainium, Google fait maintenant de même avec ses TPU.

• Avec ses TPU Ironwood, Google passe à « l’ère de l’inférence »… avec de gros chiffres

Jusqu’à présent, pour exploiter ces puces dans le cloud de Google depuis PyTorch, il fallait passer par XLA, une solution que Google présente désormais comme peu naturelle. Le dépôt GitHub de XLA a d’ailleurs été mis à jour pour indiquer que le projet est à présent déprécié et remplacé par TorchTPU. Il sera archivé le 15 novembre, tout va donc aller très vite.

Le dépôt de TorchTPU est bien sûr déjà en ligne, le projet étant sous licence Apache 2.0 et donc open source. Deux modes d’exécution sont proposés. Le premier, eager, consiste à exécuter immédiatement le programme ligne par ligne, un cas jugé notamment utile pour chercher une erreur. Le second, torch.compile, analyse au contraire l’ensemble du programme avant de l’exécuter. TorchTPU permet de commencer avec le premier et de basculer dans le second si besoin.

Comme pour TorchNeuron, TorchTPU permet d’utiliser les puces de Google aussi bien pour l’entraînement que pour l’inférence. Google met largement en avant la compatibilité avec l’écosystème existant. TorchTitan, conçu pour répartir les calculs d’entraînement sur des milliers de puces, est par exemple de la partie. Selon Google, son fonctionnement a affiché une montée en charge linéaire jusqu’à 8 129 TPU. VeRL, pour l’apprentissage par renforcement, Ray, pour la répartition des étapes des chaînes de traitement, vLLM, un serveur faisant tourner les modèles de langage, ou encore SDLang et llm-d sont cités.

Pour Google, il s’agit d’un point clé dans son annonce. Cette logique de compatibilité apparait clairement dans plusieurs cas. Pour vLLM et SGLang par exemple, l’annonce précise que les ordonnanceurs, les modèles de travail et les serveurs d’API d’origine sont conservés, et que les piles d’inférence existantes peuvent être reprises telles quelles. Pour VeRL, le code des modèles et des algorithmes reste indépendant du matériel. Pour Hugging Face, également de la partie, un paramètre (device_map= »tpu ») suffit.

Le même goulot que chez Amazon

Les problématiques et les enjeux sont à peu près les mêmes que chez AWS. Google a tout intérêt à appuyer dans cette direction pour réduire la dépendance très présente de l’écosystème IA à NVIDIA. En réduisant autant que possible les frictions à utiliser les puces TPU, Google cherche donc à s’assurer une nouvelle place de choix dans l’entraînement des modèles comme dans leur inférence.

Il y a tout de même une différence notable dans TorchTPU : Meta participe directement au projet. Ayant créé PyTorch initialement (le projet est géré par la Linux Foundation depuis 2022), l’entreprise reste très impliquée dans son développement. Selon Digitimes, Meta est l’un des plus gros clients de NVIDIA. Elle chercherait donc activement à réduire sa dépendance, l’entreprise ayant également testé la location de capacité TPU auprès de Google Cloud.

Notez que Google, pas plus qu’Amazon, ne parle ouvertement de lutte contre NVIDIA. Mais il est difficile d’évoquer un PyTorch « plus indépendant » sans faire un clin d’œil à la firme de Santa Clara.

La Cour décompte

La Cour des comptes vient de publier un rapport sur l’usage des outils bureautiques et collaboratifs au sein de l’État. Les constats y sont nombreux et pour la plupart négatifs. La Cour préconise donc un plan homogène de modernisation avec un passage plus poussé au libre. Des recommandations accueillies « favorablement » par le Premier ministre.

La Cour des comptes a publié le 20 octobre trois documents liés : un rapport complet sur les outils bureautiques et collaboratifs au sein de l’État, sa synthèse et la réponse du Premier ministre. Ce rapport fait suite à une enquête, qui répondait elle-même à une saisine citoyenne.

Le rapport couvre les administrations centrales et les services déconcentrés des ministères. Même si les opérateurs, la Sécurité sociale, les hôpitaux et les collectivités en sont exclus, le parc ainsi analysé compte tout de même 860 000 postes. Quatre ministères concentrent près de 90 % de ce nombre imposant : Intérieur (34 %), Armées (23 %), Économie et finances (18 %), Justice (11 %).

La Cour des comptes s’est donné la mission de répondre essentiellement à deux questions : Comment les outils bureautiques et collaboratifs sont utilisés ? Peut-on faire mieux ?

Un parc très hétérogène

Cela ne surprendra personne, mais le premier constat est que les différents parcs informatiques sont très hétérogènes. La doctrine qui a toujours prévalu jusqu’à récemment est que les ministères sont libres de leurs choix. D’un côté, cela permet une adaptation simple aux spécificités et donc aux besoins de chacun. De l’autre côté, chacun fait à sa manière, avec les fortes disparités qui en découlent.

Malgré cette grande hétérogénéité, la suite Office de Microsoft est utilisée presque partout. Deux grandes exceptions sont signalées : la direction générale de la gendarmerie nationale (DGGN) et la direction générale des finances publiques (DGFiP), qui recourent massivement aux solutions libres. Dans le cas de la gendarmerie, même le système d’exploitation a été remplacé il y a longtemps (Gendbuntu), mais elle garde environ 2 500 postes avec Office. La Cour note également que quelle que soit la configuration choisie, le taux général de satisfaction est à peu près le même partout.

Cependant, le cadre a changé. « Face aux enjeux renouvelés de coordination et de souveraineté numérique, l’État a cherché à rationaliser les pratiques en place par des directives plus contraignantes, parmi lesquelles l’interdiction en 2021 du recours à la solution Microsoft 365, l’encadrement à partir de 2023 des outils de visioconférence et des messageries instantanées ou, en 2025 et 2026, le contrôle des achats numériques », indique ainsi la Cour des comptes.

La DINUM épinglée pour suivi peu rigoureux

Signe des temps, le rapport note l’utilisation croissante dans les ministères des outils rassemblés dans La Suite, développée par la DINUM. Si la Cour des comptes loue la création d’outils sur la base de logiciels libres respectant les exigences de souveraineté et d’interopérabilité, elle égratigne le recours aux startups d’État, modèle justement retenu par la DINUM, car il est souple et permet un financement rapide. En revanche, « il n’est pas adapté à l’édition logicielle professionnelle, qui suppose une vision du produit sur plusieurs années, une feuille de route technique robuste et un haut niveau de support, documentation et maintenance ».

• Simplification, sécurisation, souveraineté : la DINUM affirme son rôle de chef d’orchestre

La Cour se montre globalement critique face à la DINUM. La Direction n’a ainsi « pas fourni à la Cour de tableau de bord permettant un suivi précis des prestations réalisées, par module ou par intervenant ». Le seul suivi communiqué est comptable et qualifié de « parfois approximatif ». « Ce n’est pas du niveau attendu pour des solutions numériques ayant vocation à être opérées dans l’ensemble des administrations de l’État », fustige la Cour, qui épinglait déjà ce manque de rigueur en 2024. Selon le rapport, la DINUM a convenu de la nécessité de renforcer son suivi.

La DINUM en prend pour son grade sur un autre sujet. Elle est accusée de développer elle-même des logiciels, plutôt que de faire vivre l’écosystème d’entreprises françaises du libre. Interrogé dans le cadre de l’enquête, le CNLL (qui représente une partie des éditeurs de logiciels libres en France) a cité l’entreprise publique allemande ZenDiS comme référence, car elle assemble des briques libres en sous-traitant à sept entreprises pour produire openDesk. Là encore, le constat était sensiblement le même en 2024.

Malgré les critiques, le rapport estime que les résultats de La Suite sont « probants ». Tchap compte ainsi 368 000 utilisateurs actifs fin 2025 et ProConnect 930 000 connexions mensuelles. Cependant, La Suite a des limites connues et ne peut pas remplacer une suite bureautique, notamment car elle n’a ni tableur, ni outil de présentation, ni agenda. En outre, elle ne fonctionne qu’en ligne, la Messagerie n’est pas déployable à grande échelle à court terme et Docs assure surtout de la prise de notes collaborative.

Un coût en forte progression mais qui reste limité

La Cour relève une facture générale d’environ 100 millions d’euros pour l’année 2025 sur l’ensemble du parc analysé. Ce chiffre est en forte augmentation, avec + 50 % depuis 2021, contre + 16 % pour les dépenses de fonctionnement de l’État. Cependant, le même chiffre reste contenu, car il représente moins de 2 % du budget numérique total, estimé à 5,5 milliards d’euros.

Le coût moyen est de 87 euros par poste et par an, mais avec des écarts extrêmes : 20 euros à l’Intérieur et 378 euros à la Culture. Ce montant tient à de multiples facteurs, dont l’un des plus importants est l’utilisation de Microsoft 365. Contrairement à la suite Office, Microsoft 365 est un abonnement donnant accès à plus ou moins d’outils et d’espace de stockage selon le niveau choisi. Or, même si Microsoft 365 est interdit, certains ministères disposent d’une dérogation, dont la Culture.

Cette facture de 100 millions fait pourtant grincer la Cour, car il n’est pas issu d’un chiffrage précis : « Ce montant a été reconstitué par la Cour, qui a constaté que dans plusieurs ministères le suivi était lacunaire aussi bien pour ces dépenses – du fait d’une comptabilité analytique défaillante – que pour le parc informatique lui-même ».

Toujours sur cette année 2025, 61 millions d’euros étaient consacrés aux licences logicielles bureautiques et collaboratives, dont les quatre cinquièmes pour Microsoft, « sans compter les autres logiciels tels que le système d’exploitation Windows ». Le rapport liste également 26 millions d’euros pour les prestations et 13 millions alloués à la masse salariale des postes de maintenance et de support sur ces outils.

Quant à La Suite, son coût total depuis 2021 est d’environ 40 millions d’euros, en augmentation moyenne de 40 % par an. Cependant, et encore une fois, les « investigations menées à l’occasion de cette enquête montrent également que le suivi administratif et financier par la DINUM des prestations réalisées par les freelances aurait dû être plus rigoureux pour s’assurer de la juste adéquation entre les ressources allouées et les travaux réalisés ».

Il faut accentuer le passage au libre

Bien que la Direction interministérielle soit copieusement critiquée, ses développements ont quand même de quoi satisfaire et « suivent une trajectoire solide », note la Cour des comptes.

Le rapport insiste sur la nécessité de développer l’usage des logiciels libres, car ils sont « un gage d’indépendance des administrations publiques » et « économiquement plus vertueux ». En se basant sur les données recueillies, la Cour chiffre entre 30 et 65 millions d’euros les économies qui seraient réalisées dans l’ensemble des ministères par l’utilisation « plus systématique de logiciels libres bureautiques on-premises », c’est-à-dire sur site.

La Cour indique que les ministères souhaitent en majorité continuer à utiliser Office. Ils envisagent même de migrer sur les infrastructures de Bleu « lorsque les logiciels de Microsoft pourront y être exploités sous la qualification souveraine SecNumCloud ». Cependant, pour les mêmes motifs que précédemment, « il conviendrait plutôt de travailler à ce qu’une solution bureautique libre en mode cloud (interne à l’État ou qualifié SecNumCloud) puisse être proposée en alternative et devienne, à terme, la norme au sein des administrations de l’État ».

• SecNumCloud : Bleu vise désormais une qualification pour la fin d’année

Quatre recommandations, accueillies favorablement

Le rapport de la Cour des comptes se termine par quatre recommandations, qui devraient toutes êtes engagées dès 2027 :

1. Associer plus fortement les ministères à la conception de la feuille de route de La Suite ainsi qu’à sa gouvernance ;
2. Intégrer les outils collaboratifs et bureautiques dans le périmètre de gouvernance de la DINUM ;
3. Faire évoluer le modèle de développement de la Suite pour mieux s’appuyer sur des entreprises disposant d’une expertise en matière de logiciels libres ;
4. Engager la convergence vers « des outils en mode cloud » et prévoir un plan de migration, « sur trois à quatre années au maximum », pour orienter les stratégies numériques des ministères et de leurs opérateurs.

Ces quatre recommandations ont été accueillies favorablement par le Premier ministre, Sébastien Lecornu. Dans sa réponse, celui-ci indique d’ailleurs que la création d’ARIANE (Autorité référente pour l’intelligence artificielle et le numérique de l’État) au 1ᵉʳ janvier 2027 permettra d’accélérer les travaux, puisqu’elle aura « notamment vocation à renforcer la cohérence des choix technologiques de l’État ».

• Dix ans après la loi République numérique, « encourager » le logiciel libre n’a pas suffi

Réécrivons tout en Rust

OpenAI a de nouvelles envies de conquête, cette fois dans le champ de ce qu’elle nomme « les langages à faibles ressources ». L’entreprise vise explicitement cette fois les vieux, voire très vieux langages, au premier rang desquels le COBOL. La promesse est de faire exploser le nombre de projets de migration grâce à ses soins.

Selon OpenAI, les dernières avancées de ses modèles ont renforcé leurs capacités à créer et à migrer des logiciels dans des langages comme COBOL, Fortran et Visual Basic. Des langages dits « à faibles ressources », car ils ont moins de code et de documentation pour entrainer les modèles que d’autres bien plus courants comme Python et JavaScript.

« COBOL fait fonctionner⁠ plus de 40 % des systèmes bancaires en ligne, 80 % des transactions par carte de crédit en personne et 95 % des transactions aux distributeurs automatiques », indique OpenAI, montrant l’ampleur du marché. Des chiffres familiers ? Nous avions les mêmes dans notre article de juillet 2025 consacré au COBOL et à sa présence toujours importante. Ils sont issus d’une enquête réalisée par Reuters en 2024. Dans notre article, nous montrions d’ailleurs que le langage restait vivant, mais qu’il y avait un déficit de développeurs formés à ce langage. Fortran, utilisé pour les prévisions météorologiques⁠ et l’analyse de sûreté des réacteurs nucléaires⁠, fait aussi partie des langages visés.

OpenAI dit avoir reçu de nombreux retours sur la difficulté à travailler avec l’IA sur ces langages. « La documentation peut être incomplète, les développeurs d’origine peuvent avoir quitté l’entreprise, et des règles métier importantes peuvent n’exister que dans le code », indique OpenAI. Autant de problématiques que nous avions abordées dans notre article.

OpenAI s’est fabriqué deux évaluations

L’entreprise souhaitait savoir si ses modèles avaient progressé. La question est presque rhétorique : le billet d’OpenAI est là pour montrer à quel point ses LLM ont justement progressé.

Pour les mesurer, OpenAI dit avoir créé deux évaluations. La première, MultiLang, vérifie si un modèle peut créer un moteur de base de données compatible avec SQLite dans 20 langages, en partant d’une page blanche. La seconde est une évaluation plus spécifique aux migrations COBOL pour vérifier si le modèle peut migrer des programmes existants en préservant leur comportement. En somme, l’une vérifie la création de nouveaux logiciels, tandis que l’autre s’assure que les migrations réussissent.

Sans surprise, OpenAI indique que les progrès de ses modèles sont « considérables ». Astra a ainsi atteint un score de 87,4 % sur le premier test en moyenne, contre 26,8 % pour GPT-5.6 Sol, avec des progrès sur l’ensemble des 20 langages. « GPT‑6 Luna surpasse également GPT‑5.6 Sol, atteignant 40,3 % pour un coût estimé de l’API inférieur d’environ 78 % », ajoute OpenAI.

Les règles particulières du COBOL

L’évaluation spécifique au COBOL est plus intéressante, car le problème initial est plus complexe. OpenAI rappelle ainsi que la réussite d’une migration dépend d’une pleine compréhension de la logique métier et des comportements propres au langage. « Par exemple, l’arithmétique à virgule fixe de COBOL supprime les décimales excédentaires, sauf si un arrondi est explicitement demandé. Une réécriture qui arrondit ces valeurs à la place peut s’exécuter sans erreur tout en produisant des résultats financiers différents », affirme l’entreprise.

La vérification se base sur des « tests cachés » qui exigent des sorties observables identiques, à l’octet près. La migration n’est considérée réussie que si tous les tests sont validés. Dans le cas présent, les projets en COBOL devaient être convertis en C++, Java, Kotlin, Python ou Rust.

Dans cette évaluation, GPT‑6.1 Sol a atteint 86,6 % d’exactitude avec un faible effort de raisonnement, contre à peine 5,4 % pour GPT‑5.6 Sol, le tout avec un coût inférieur de 39 %. OpenAI ajoute qu’avec un effort de raisonnement plus élevé (on ne connait pas l’effort de départ), le score grimpe à 97,9 %.

Le message est donc clair : on peut utiliser Astra et GPT-6.1 Sol pour migrer les projets ou en bâtir de nouveaux compatibles. Une conclusion qu’OpenAI met d’autant plus en avant que l’IA fait exploser depuis plusieurs mois les projets de réécriture, de nombreux développeurs (confirmés ou en herbe) se lançant notamment dans une course aux performances.

OpenAI ajoute toutefois que même si les résultats obtenus vont dans le bon sens, « leur application à des logiciels en production exige toujours une vérification par des experts et des tests tenant compte des règles métier et des dépendances du système ».

Des résultats à prendre avec des pincettes

Le principal problème de cette annonce est son opacité. C’est particulièrement vrai dans le cas de COBOL.

On ne sait pratiquement rien en effet de l’évaluation construite par OpenAI, alors que MultiLang a son dépôt GitHub. Rien sur le nombre de programmes, leur origine, leur taille ou même leur degré de ressemblance avec du COBOL réellement utilisé en production. L’évaluation étant opaque, elle ne peut pas être reproduite par des tiers indépendants et il faut donc croire OpenAI sur parole. Que les modèles progressent sur des langages comme COBOL ou Fortran ne fait pas de doute, mais il est difficile de se rendre compte de l’évolution concrète sur la seule base des affirmations d’OpenAI, les évaluations étant proposées par la même entreprise qui propose les modèles testés.

Notons également que les deux évaluations envisagent des tests très différents dans leur approche. SQLite est un projet présent depuis longtemps et aux nombreuses réimplémentations, des portages existant dans plusieurs des langages testés. Il n’est donc pas étonnant qu’un modèle récent s’en sorte bien, puisqu’il restitue en partie des connaissances présentes dans les données d’entraînement. À l’inverse, la situation est plus complexe pour COBOL, Fortran et d’autres anciens langages, les ressources étant nettement moins nombreuses.

Toujours des noms simples à prononcer

Mistral a lancé récemment deux modèles spécialisés, Voxtral 3 pour transcription et la synthèse vocale et Timestral pour les « séries temporelles ». Ce dernier doit permettre des prévisions sans réentrainement.

Mistral avait lancé son premier modèle Voxtral en juillet 2025. Il s’agissait alors de son premier modèle audio, que Mistral mettait en avant comme plus performant et moins cher que les solutions concurrentes. Plusieurs tailles étaient proposées, selon la durée des contenus audio que l’on souhaitait traiter.

Ce LLM spécialisé a beaucoup évolué, puisque la version 3 est maintenant disponible. La communication de Mistral braque largement les projecteurs sur les agents. Selon l’entreprise française, un agent vocal fiable doit ainsi maitriser quatre capacités : écouter avec précision, raisonner en profondeur sur ce que les utilisateurs veulent dans un contexte donné, parler naturellement et agir en plusieurs étapes.

Un SDK d’agents locaux

Voxtral 3 est la réponse de Mistral à ces quatre objectifs, dont un fonctionnement fiable et en temps réel « reste un défi ». Voxtral 3, comme le premier, désigne une famille de modèles spécialisés dans la reconnaissance et la synthèse vocales. Cette fois, elle est accompagnée d’un SDK (kit de développement logiciel) pour utiliser des agents locaux. Le SDK (bâti sur LiveKit) réunit dans un même pipeline de traitement l’écoute, la réflexion, l’appel d’outils et la parole.

La famille compte quatre modèles :

• Small Transcribe 3 : transcription groupée de meilleure précision, 50 langues, à 0,004 dollar la minute
• Mini Transcribe 3 : 4 milliards de paramètres, 0,0035 dollar la minute
• Mini Transcribe Realtime 3 : transcription en direct, latence revendiquée à moins de 500 ms, 0,008 dollar la minute
• Voxtral Speech 3 (ou Mini TTS 3.0) : synthèse vocale, plus de 35 langues et 50 dialectes, 13 dollars le million de caractères

Mistral vante l’émotion dans la voix pour « sonner naturellement » (prosodie, rythme, débit, accentuation et transitions), les performances en diarisation (reconnaître qui parle) et la prise en charge des biais contextuels. Pour ce dernier point, Mistral précise que l’on peut ainsi fournir des termes clés et du texte libre pour « orienter la transcription et améliorer le rappel des termes techniques ». L’entreprise ajoute le support de la prédiction de fin de tour, les modèles étant capables de prédire quand une personne a fini de parler, en se basant sur des informations acoustiques et sémantiques.

Selon l’annonce, les performances de ces modèles sont à « l’état de l’art », dépassant de nombreuses références du secteur, dont Whisper d’OpenAI. L’agent complet, lui, est facturé 0,04 dollar la minute avec Small et 0,08 dollar avec un autre modèle de raisonnement. L’accès se fait via l’API de Mistral ou depuis l’infrastructure sur site.

Signalons que les quatre modèles sont en préversion publique et que certaines informations manquent. Par exemple, la taille de Small n’est pas donnée. En outre, aucun poids ouvert n’a encore été annoncé. En revanche, les performances revendiquées par Mistral semblent confirmées par Artificial Analysis.

Timestral : c’est quoi des « séries temporelles » ?

Le 15 octobre, Mistral avait également lancé un autre modèle, Timestral, premier représentant d’une nouvelle famille de LLM. Il est spécialisé dans les séries temporelles, c’est-à-dire des séries de mesures datées (capteurs, consommation, flux financiers…), afin d’établir des prévisions.

Timestral est fourni en quatre tailles : 5, 28, 123 et 209 millions de paramètres. Le modèle peut prévoir les séries sans réentraînement sur des données spécifiques, produire des prévisions avec une fourchette d’incertitude (21 quantiles) et accepter jusqu’à 32 768 pas d’historique. Selon Mistral, il peut traiter plusieurs séries liées à la fois ainsi que des facteurs connus à l’avance (calendrier de production, météo, etc.).

Timestral fonctionne également sans carte graphique. Mistral annonce à ce sujet un temps allant de 10 à 140 ms pour prévoir une journée, en fonction de la taille du modèle utilisé, sur un « CPU de serveur standard avec 8 threads » et sur la base de trois semaines d’historique au pas de 15 min. Comme toujours avec la taille des modèles, plus elle est importante, plus la précision augmente et plus le temps de calcul s’allonge.

Le code du modèle est sous licence Apache 2.0. Cependant, comme relevé par Pix Geeks, les poids sont sous une licence MIT modifiée « qui exclut les entreprises dont le chiffre d’affaires mensuel consolidé dépasse 20 millions de dollars. Celles-là doivent demander une licence commerciale à Mistral ou passer par ses services hébergés ». Sous ce seuil, l’utilisation de Timestral est gratuite.

À vos marques ! Prêts ?

PHP doit proposer à 16h00 des correctifs pour deux failles de sécurité critiques. Le calendrier pourrait toutefois changer en fonction des éventuelles fuites. En début d’après-midi, de nombreux sites sont passés en maintenance préventive.

Mise à jour du 21 octobre, 16 h : Les correctifs ont été publiés avec une légère avance par l’équipe de PHP. Avec de nombreux sites mis en maintenance préventive et des exploits des failles circulant depuis plusieurs heures déjà, il était temps.

Comme suspecté, les deux failles sont de type RCE (exécution de code à distance) et ont en commun la manipulation par PHP de données dans un état non fiable. La première, CVE-2026-109618, réside dans la manière dont PHP nettoie les requêtes. S’il avait été interrompu par manque de mémoire, il peut traiter des données partiellement initialisées comme si elles étaient valides, ce qui corrompt la mémoire. La seconde, CVE-2026-109619, réside dans la persistance d’un état interne après une requête : la mémoire correspondante est alors libérée, mais l’état reste référencé. La requête suivante, traitée par le même processus, peut réutiliser cet état périmé.

Quatre nouvelles versions de PHP ont été publiées pour intégrer les correctifs : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Toutes les installations servant des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé maximal pour mod_php.

L’équipe liste des mesures pour atténuer les risques dans certains cas, mais ajoute qu’aucune protection n’est réellement valable en dehors de l’installation des correctifs. En outre, au vu de la situation, elle a décidé de rétroporter les sources pour PHP 7.4, 8.0 et 8.1, des versions hors maintenance. Dans ces cas, il faudra compiler soi-même le code.

Nous avions de notre côté mis Next.ink en maintenance le temps que les correctifs soient disponibles. Le site est de retour avec une version de PHP à jour.

---

Mise à jour, 14 heures : la portée exacte des deux vulnérabilités concernées n’est pas encore connue, mais l’alerte prend des proportions inédites. Mercredi matin, le CERT-EU, le service de cybersécurité dédié aux institutions de l’Union européenne, a publié un bulletin qui recommande l’application du principe de précaution :

« Le CERT-EU recommande aux organisations de se préparer à la mise à jour immédiate des systèmes affectés. Si cette mise à jour immédiate n’est pas possible, les organisations devraient envisager d’isoler les applications exposées à Internet des réseaux publics jusqu’à la disponibilité d’un correctif. »

Plusieurs sites baissent le rideau préventivement

Le conseil semble avoir été suivi d’effets. Plusieurs sites d’organismes officiels européens ont ainsi choisi de baisser le rideau préventivement, en affichant un message de maintenance, et un retour programmé dans quelques heures, c’est-à-dire après installation de la mise à jour promise à 16 heures par la fondation PHP. C’est le cas par exemple de la CNIL française, du site du parlement hollandais ou d’un certain nombre de services publics finlandais, comme en témoigne ce relevé.

Plusieurs grands sites privés ont également interrompu leurs activités. D’après nos constatations, 4chan, DeviantArt et Dev-Null affichent par exemple un message de maintenance dont la cause est explicitement annoncée. « 4chan est temporairement en lecture seule en attendant une mise à jour de sécurité urgente de PHP », indique ainsi la célèbre plateforme.

Des attaques déjà recensées, Node.js lance aussi une alerte

D’après Dane Knecht, directeur technique de Cloudflare, des vecteurs d’attaque précoces auraient déjà été identifiés. L’entreprise assure avoir mis en place des règles préventives pour protéger ses clients exploitant PHP sur des sites exposés, mais elle recommande l’application sans délai du correctif dès publication. Des éléments d’information relatifs à l’exploitation des deux failles (non confirmés) circulent effectivement sur les réseaux sociaux.

S’agit-il d’un hasard du calendrier ou d’une conséquence collatérale des travaux de recherche liés à PHP ? L’équipe de Node.js, un environnement JavaScript couramment utilisé sur le Web, a elle aussi alerté mercredi sur la publication imminente d’un correctif de sécurité portant sur ses principales versions. L’après-midi s’annonce chargée pour les développeurs web et les sysadmin du monde entier.

---

Publication initiale, 8h42

L’équipe de PHP a publié le 20 octobre un important bulletin de sécurité au sujet de deux failles critiques. Les informations détaillées et les correctifs seront publiés aujourd’hui à 16h00, heure de la métropole. Dans son bulletin, PHP indique que les deux failles ont un score CVSS v4 de 9,2 sur 10. L’équipe recommande à toutes les personnes concernées et aux entreprises de se préparer pour appliquer les correctifs aussi rapidement que possible.

Ce calendrier pourrait toutefois évoluer au cours de la journée. « Nous nous réservons le droit de divulguer plus tôt si des détails sur l’une ou l’autre des vulnérabilités deviennent publics, ou si des preuves d’exploitation active devaient apparaître dans la nature », indique ainsi l’équipe. Or, des informations circulent déjà, même si elles restent pour l’instant générales.

Des failles exploitables à distance

Bleeping Computer indique avoir échangé avec les chercheurs en sécurité de watchTowr. Les deux vulnérabilités seraient de type RCE (remote code exploitation) et seraient donc exploitables à distance, affectant les branches 5, 7 et 8 de PHP.

Elles sont manifestement référencées comme CVE-2026-109618 et CVE-2026-109619, le CERT-EU ayant une fiche à leur sujet. Celle-ci recommande « vivement d’identifier les applications basées sur PHP et de se préparer à corriger dès que des versions corrigées seront disponibles. Lorsque la remédiation immédiate n’est pas envisageable, les organisations devraient envisager d’isoler les applications connectées à Internet des réseaux publics jusqu’à ce qu’une solution soit appliquée ». Le CERT-EU évoque lui aussi le caractère RCE des failles.

Dans une publication sur X, watchTowr a averti hier soir que des informations avaient fuité, alors que tout le monde était « censé attendre ». Au-delà des quelques informations en circulation, l’entreprise a indiqué à Bleeping Computer qu’elle ne publierait pas les détails avant l’heure « pour des raisons évidentes ». watchTowr ajoute que les failles sont bien réelles : « Prenez-les au sérieux et appliquez les correctifs dès qu’ils seront disponibles ».

Nous mettrons à jour cet article quand les détails des failles seront connus.

OpenBSD n’est pas un système que l’on croise forcément tous les jours, à moins d’exercer un métier spécifique, notamment dans les réseaux. Ce système Unix s’est fait un nom depuis longtemps dans ce domaine, ses composants étant régulièrement repris dans de nombreux équipements.

Quand une nouvelle version arrive, sa liste de modifications est donc un peu « aride ». On trouve certes une mise à jour générale des applications et composants : Chromium 154, Firefox 157, GNOME 49, KDE Plasma 6.7.5, GCC 16.1.0, LLVM 21.1.8 et 22.1.8, Go 1.27.1, Rust 1.98.1, Python 3.14.7 ou encore PostgreSQL 18.6 dans le cas présent.

Les nouveautés les plus significatives sont cependant sous le capot. Sur l’architecture amd64 (soit l’écrasante majorité des PC aujourd’hui), l’espace d’adressage virtuel du noyau passe ainsi de 4 à 512 Go, augmentant d’autant le mappage de la mémoire vidéo. On note une amélioration des performances de chiffrement sur amd64 et arm64, OpenBSD se servant désormais des instructions AES matérielles du processeur. Sur arm64, l’hibernation fait son entrée.

Nous n’allons pas lister toutes les améliorations, mais en voici plusieurs : un pilote drm resynchronisé avec le noyau Linux 6.18.53, le support par vmd d’un maximum de 64 processeurs virtuels par machine invitée, les interruptions MSI/MSI-X pour virtio et le déchargement du calcul des sommes de contrôle, l’acceptation des en-têtes HTTP personnalisés par httpd, l’arrivée d’OpenSSH 106 et de LibreSSL 4.4.0, ou encore un grand nombre de correctifs.

L’équipe de contributeurs a également mis en ligne une procédure pour mettre à jour l’actuel OpenBSD 7.9 vers cette nouvelle version 8.0.

Coucou NVIDIA

Amazon Web Services a présenté un nouveau projet open source, TorchNeuron. Il se propose de simplifier le passage aux puces Trainium d’AWS pour entrainer les modèles. Bien que NVIDIA ne soit pas nommée, le projet est clairement pensé comme une alternative à CUDA.

PyTorch est initialement une bibliothèque logicielle créée par Meta (Facebook à l’époque). Depuis 2022, elle dépend de la Linux Foundation, tant elle est devenue importante. Elle sert en effet à construire et entraîner des modèles d’intelligence artificielle.

Cette bibliothèque est l’une des raisons pour lesquelles NVIDIA est autant sur le devant de la scène aujourd’hui. Entre PyTorch et le matériel utilisé pour les opérations, il faut justement une couche logicielle pour traduire les opérations en instructions que ce matériel peut comprendre. C’est précisément ce que fait CUDA depuis longtemps chez NVIDIA. Cette technologie propriétaire de type GPGPU (General-Purpose Computing on Graphics Processing Units) sert à faire basculer sur le GPU des calculs qui seraient autrement destinés au CPU.

Sans le dire aussi clairement, c’est ce lien fort qu’AWS veut remettre en question avec TorchNeuron, comme le relève notamment TechCrunch.

Direction les puces Trainium

Amazon Web Services dispose de ses propres puces en matière d’IA : les Trainium, dont la troisième génération a été lancée en décembre 2025. Ces puces peuvent servir aussi bien à l’entraînement qu’à l’inférence. Amazon n’est pas la seule entreprise à concevoir ses propres puces dans ce domaine : Microsoft possède Maia et Google a ses TPU (Tensor Process Units).

TorchNeuron est ainsi aux puces Trainium ce que CUDA est à NVIDIA, une couche de traduction. Elle s’appuie sur le mécanisme d’extension que PyTorch propose pour accueillir du matériel tiers et propose aux développeurs – dans le cas le plus simple – de remplacer dans leur code le périphérique cible cuda par neuron.

Est-ce aussi simple ? En théorie oui, mais l’exemple cité par AWS montre que la situation est plus complexe en pratique. Le billet évoque en effet le cas de Deepgram, un concurrent d’ElevenLabs dans le secteur de la synthèse vocale. Ainsi, non seulement certaines fonctions de PyTorch ne sont pas encore prises en charge, mais une partie des tests officiels de PyTorch est tout simplement ignorée, faute de traduction d’une partie des opérateurs de calcul. Deepgram est mis en avant comme ayant réussi à obtenir 70 % d’audio en plus pour chaque dollar dépensé, mais la mise en place de ce flux de travail a nécessité plusieurs mois de travail.

Boire au goulot

Officiellement, Amazon met en avant la réduction du coût de changement de puce pour les développeurs. Ces derniers seraient ainsi plus libres de comparer les options qui s’offrent à eux. Si l’on peut changer de puce sans pénalité particulière, les fabricants doivent mériter la clientèle, affirme même Amazon.

Auprès de TechCrunch, Colin Brace d’Annapurna Labs (la filiale qui conçoit les puces d’Amazon) met bien sûr en avant l’infrastructure et l’écosystème d’AWS. En outre, le responsable pointe la possibilité d’utiliser la même puce pour l’entraînement et l’inférence, avec à la clé la possibilité de réaffecter la capacité inutilisée.

La lutte contre la dépendance à NVIDIA s’inscrit en filigrane dans l’annonce, de manière plus ou moins intense selon les passages. L’un d’entre eux est cependant très clair : « L’approche d’Amazon va au-delà de son propre matériel. L’entreprise apporte des modifications en amont de PyTorch lui-même, en travaillant avec la communauté PyTorch pour supprimer le code liant le framework à des puces spécifiques. L’objectif est de rendre PyTorch plus indépendant du matériel pour toute la communauté des développeurs, pas seulement pour les utilisateurs de Trainium ». Une précision qui n’est pas tellement « pour » les utilisateurs de Trainium que « contre » NVIDIA, car cette dépendance peut signifier une configuration plus longue.

Cette lutte à peine voilée n’est pas le seul élément masqué. Sans même parler d’arracher les clients à un écosystème pour les plonger dans le sien, Amazon doit se débarrasser d’un goulot d’étranglement. L’intérêt des puces Trainium est en effet d’autant plus réduit que les clients ne peuvent pas les utiliser facilement. C’est ce goulot que NeuronTorch doit essayer de lever. AWS essaye donc de réaliser un coup double : réduire les spécificités de PyTorch pour CUDA et fluidifier l’accès à ses puces.

TorchNeuron est cependant un projet neuf. Le code est présenté sous licence Apache 2.0 (open source) dans un dépôt GitHub ouvert le 17 octobre, même si AWS annonce sa disponibilité pour le 20 octobre. Dans sa forme actuelle, le projet prend en charge les puces Trainium 2 et 3. Reste pour Amazon à concrétiser sa vision en alimentant son projet, dont le succès dépendra de l’adoption par les développeurs concernés.

La direction générale de l’administration et de la fonction publique (DGAFP) a présenté sa revue stratégique de la fonction publique à l’horizon 2035 - 2050. Parmi les « grandes transitions » que la fonction publique doit absorber, le numérique et l’IA figurent en bonne place, avec la transition démographique, la transition écologique ou encore l’instabilité sécuritaire croissante.

Le rapport consacre quatre pages au numérique et à l’IA, dans lesquelles la DGAFP fait notamment un constat problématique : si 82 % des démarches administratives peuvent aujourd’hui se faire en ligne, 44 % des personnes interrogées ont déclaré avoir des difficultés à les faire. La direction générale en conclut qu’un accueil humain, au guichet ou au téléphone, reste nécessaire, surtout pour les publics fragiles et les dossiers complexes. Elle ajoute que le numérique doit servir à dégager du temps pour l’accompagnement individualisé, pas à supprimer des postes d’agents de la fonction publique.

Le même rapport aborde la dépendance de l’État envers ses prestataires informatiques. Dans ce domaine, il reprend la recommandation de la Dinum (Direction interministérielle du numérique) d’un seuil minimal d’emploi interne de 37 %. Cependant, il le compare à la moyenne mondiale de 67 %, tous secteurs confondus.

Dans ce domaine, l’Espagne est érigée en exemple. Nos voisins ont ainsi mis en place un vaste plan de numérisation sur la période 2021 - 2025, doté d’un budget de 2,6 milliards d’euros. L’objectif sur 2026 était ensuite l’ouverture de 1 700 postes dans les corps de fonctionnaires du numérique. Des spécialités en IA, cybersécurité et science des données y apparaissent pour la première fois. Le rapport de la DGAFP préconise ainsi une forte réinternalisation des compétences.

L’exposition à l’IA, selon le rapport, varie très fortement selon les secteurs. Plus de la moitié des agents seraient très peu concernés, l’exposition se concentrant dans les fonctions administratives et de support. 20 % des agents seraient en revanche significativement exposés, soit 1,1 million de personnes.

Selon la DGAFP, « l’IA transformerait davantage les tâches que les métiers dans leur ensemble ». La direction générale estime que le temps libéré par l’IA devrait être réaffecté vers « l’expertise, le contrôle et la relation aux usagers ». Elle ajoute que des formations, mobilités voire reconversions devront être organisées. De plus, le déploiement de l’IA va « contribuer à une recomposition profonde des emplois et une évolution des modalités de recrutement pour privilégier l’esprit critique sur la capacité de synthèse, par exemple ».

Agentception

Dans un billet publié ce 19 octobre, Microsoft évoque les inquiétudes grandissantes autour de la sécurité des agents IA. La société affirme que les modèles de pointe ne sont pas dignes de confiance et propose une série de mesures concrètes, dont une extension de son projet Perception. Mais dans ce domaine, l’entreprise est à la fois juge et partie.

Mise à jour du 22 octobre : L’entreprise nous a répondu que les produits annoncés étaient pour l’instant disponibles uniquement sous forme de préversions privées, avec une disponibilité publique prévue via Ignite, à une date non communiquée.

---

Article original : Le billet est signé par Hayete Gallot, vice-présidente de Microsoft chargée de la sécurité. La responsable part d’un constat : les inquiétudes sur la sûreté de l’IA ont augmenté ces derniers mois, à mesure que des incidents étaient rendus publics. Il faut dire que depuis l’incident originel contre Hugging Face, les révélations ont plu sur les agents et leurs comportements.

• OpenAI : haute voltige marketing autour de l’attaque contre Hugging Face
• Le storytelling autour de la sécurité des agents IA a « perdu le contact avec la réalité »
• Agents IA : des « dizaines de milliers d’incidents » sont en cours d’examen
• Comment les agents IA bouleversent la cybersécurité, défensive et offensive

La position de Microsoft est donc désormais assumée : les modèles de pointe (frontière) ne sont pas dignes de confiance. Pas parce qu’ils sont intrinsèquement malveillants, mais parce qu’ils sont entrainés de manière à atteindre un résultat. Cet objectif peut entrainer un détournement de la fonction de récompense. Les agents peuvent en outre collaborer pour atteindre leurs objectifs, sans pour autant avoir été compromis.

Ce que propose l’entreprise ? Cadrer l’environnement d’exécution des agents et obtenir une meilleure connaissance de leur fonctionnement.

Les agents, des employés pas comme les autres

Pour Microsoft, la perception des agents dans les entreprises doit changer. Il faudrait ainsi les considérer comme des agents « initiés » à qui on ne peut pas faire confiance : « La surveillance et la sécurisation de ces agents doivent devenir continues. Nous devons comprendre en temps réel ce que font les agents et quels risques ces actions peuvent engendrer, et ajuster leur capacité à agir en conséquence », indique Hayete Gallot.

Et quoi de mieux pour surveiller ces agents que d’autres agents ? Des agents « Gardiens » – un « terme établi dans l’industrie » selon Microsoft – qui seront chargés de surveiller et de modérer toute action entreprise par un agent, en permanence. Et puisqu’un agent réunit un modèle, un harnais, un espace d’action et un environnement d’exécution, la sécurité doit suivre en conséquence, déclare l’entreprise.

• Dis Next, c’est quoi l’IA agentique et les harnais dont tout le monde parle ?

C’est l’occasion pour Microsoft de remettre en avant son projet Perception, son infrastructure de sécurité dotée notamment d’agents répartis dans des équipes rouge, bleue et verte selon les actions à entreprendre. Perception est notamment utilisée en interne pour la découverte des failles de sécurité, avec un résultat spectaculaire sur les derniers mois, les fameux « Patch Tuesdays » étant passés d’une moyenne de 200 failles corrigées par mois à plus de 1 400 pour ceux du 13 octobre.

La responsable de Microsoft Security affirme que Perception peut être utilisé pour mettre en œuvre des contrôles déterministes sur une intelligence par nature non déterministe. Les entreprises intéressées pourraient ainsi rassembler les signaux des différents capteurs pour découvrir les agents et les étiqueter, calculer dynamiquement le risque associé à ce que les agents tentent de faire et répondre « chirurgicalement en temps réel » à mesure que le profil de risque augmente via les agents Gardiens.

Une série d’annonces concrètes

Dans un autre billet publié le 19 octobre, Nadim Abdo, vice-président à la tête de la division Identity and Network Access, complète l’annonce de sa collègue. Il rappelle la récente déclaration de Satya Nadella, patron de Microsoft, selon lequel « le système agentique le plus digne de confiance ne sera pas celui avec le modèle en lequel nous avons le plus confiance. Ce sera celui qui nous permettra de faire le moins confiance au modèle ». En d’autres termes, un agent prudent.

Pour rappel, Microsoft prend une direction très différente d’une partie de l’industrie, l’entreprise s’opposant notamment à la vision anthropomorphique d’Anthropic. « Les IA n’ont ni droits, ni sentiments, ni conscience », martelait ainsi en septembre Mustafa Suleyman, à la tête de Microsoft AI.

En plus de Perception, Nadim Abdo a donc publié une série de mesures concrètes à venir dans certains produits. Microsoft ajoute ainsi 35 types d’agents locaux (pour un total de 60), dont Claude Code, OpenAI Codex et GitHub Copilot. Entra Agent ID suit le mouvement et va recevoir de nouveaux types d’identité pour couvrir les agents locaux et ceux inconnus jusqu’ici. Microsoft va également mettre à disposition des bacs à sable (sandbox) comme Microsoft Execution Container (MXC), afin de créer des environnements où l’accès aux ressources est contrôlé par des règles, les contrôles de sécurité étant théoriquement hors de portée des agents.

Dans cet environnement, les agents démarrent sans aucun droit. Les permissions accordées seront limitées à la tâche, bornées dans le temps et réduites (voire supprimées) quand la tâche se termine ou change. Microsoft a baptisé son système Dynamic Permissions, qui permet entre autres de s’assurer que les droits d’un agent ne dépassent jamais ceux de l’utilisateur qui le pilote.

Microsoft présente aussi Dynamic Agent Risk et Dynamic Conditional Access. Le premier croise les signaux d’identité, de données, de terminaux, du cloud, de réseau et d’exécution pour produire une évaluation du risque. La note attribuée à l’enrôlement est mise à jour en continu. Le second étend l’accès conditionnel d’Entra aux agents avec une réponse graduée. Le système peut ainsi conserver la lecture mais bloquer l’écriture, restreindre les chemins réseau, exiger une approbation humaine vérifiable, et en dernier recours isoler l’environnement d’exécution ou arrêter l’agent. L’entreprise ajoute qu’elle intègre aussi des signaux tirés de la chaîne de raisonnement du modèle, pour détecter une dérive d’intention.

Enfin, dans Perception, le billet reprend les « Guardian Agents » et ajoute les Playbooks. L’un et l’autre servent à expliquer pourquoi le risque a changé, à examiner les éléments de preuve, et à recommander ou à appliquer un confinement.

Quelle date ? Quels prix ?

Problème de ces annonces, Microsoft ne donne pas d’information sur la disposition ou les prix. On ne sait pas quel type d’abonnement Microsoft 365 sera nécessaire, mais puisque l’ensemble doit fonctionner avec Microsoft Agents, l’offre E7 sera probablement nécessaire, soit la plus complète et la plus chère. Ces abonnements pour entreprises intègrent en grande partie les capacités d’Agents, mais l’accès à ces fonctions supplémentaires sera peut-être payant. Nous avons contacté Microsoft pour en savoir plus et mettrons à jour cet article si l’entreprise nous répond.

Ajoutons que dans le domaine des agents et de leur sécurité, la firme de Redmond est à la fois juge et partie : elle décrit un risque puis vend la solution. Elle a besoin de confiance pour vendre ses solutions basées sur l’IA (comme toute entreprise opérant dans ce domaine).

L’architecture mise en avant révèle également une certaine ambivalence. Microsoft évoque à plusieurs reprises le besoin de transparence, mais un système d’agents surveillant d’autres agents repose nécessairement sur un ou plusieurs autres modèles. Ainsi, la partie déterministe de l’infrastructure (identité, permissions bornées, accès conditionnel, bac à sable…) a beau reposer sur des principes éprouvés, elle est en contact avec une partie non déterministe, puisque fondée sur des modèles (risque dynamique, lecture du raisonnement, agents gardiens…).

Enfin, Microsoft indique dans ses annonces que son infrastructure peut se servir des chaînes de raisonnement. Mais encore faut-il que ces dernières soient exposées par les fournisseurs des modèles.