La plateforme d’automatisation open source n8n est victime de deux failles critiques affichant la note de sévérité maximale (10/10). Il est recommandé de mettre à jour au plus vite les installations.
n8n est une plateforme d’automatisation des workflows. Elle permet de connecter des services (API, bases de données, SaaS, scripts…) à des actions pour qu’elles se déclenchent quand les conditions sont réunies. La plateforme, open source, a largement gagné en popularité au point d’en faire l’un des produits les plus suivis, notamment parce qu’elle peut s’interfacer avec à peu près n’importe quoi, via des connecteurs, dont des systèmes IA.
Deux failles critiques de sévérité maximale
Elle est cependant touchée par deux failles de sécurité dont la criticité est maximale, avec un score CVSS de 10 sur 10, soit le maximum. La première, estampillée CVE-2026-21877, est de type RCE (Remote Code Execution) et peut donc permettre l’exécution d’un code arbitraire à distance. « Dans certaines conditions, un utilisateur authentifié peut être capable de faire exécuter un code non fiable par le service n8n. Cela pourrait entraîner une compromission complète de l’instance concernée. Les instances auto-hébergées et n8n Cloud sont toutes deux concernées », indique l’équipe de développement dans une note sur GitHub.
Dans ce contexte, un acteur malveillant peut, en exploitant la faille, introduire des instructions dans la logique d’exécution des workflows et de gestion des identifiants. Il peut ajouter ou supprimer des workflows, exfiltrer des données sensibles, déployer du code malveillant et aboutir à une compromission totale du serveur.
La deuxième faille, CVE-2026-21858, est « pire », bien que disposant de la même note. « Une vulnérabilité dans n8n permet à un attaquant d’accéder aux fichiers du serveur sous-jacent en exécutant certains flux de travail basés sur des formulaires. Un flux de travail vulnérable pourrait accorder l’accès à un attaquant distant non authentifié. Cela pourrait entraîner une exposition d’informations sensibles stockées sur le système et permettre de nouvelles compromissions selon la configuration du déploiement et l’utilisation du flux de travail », explique l’équipe dans une autre note. La faille est corrigée
Quatre fois en deux mois
La première faille a été corrigée dans la version 1.121.3 et la seconde dans la 1.121.0, toutes deux sorties en novembre. D’ailleurs, les failles aussi ont été découvertes en novembre. Elles n’ont été révélées que très récemment, le temps que les mises à jour se fassent sur un maximum de configurations. Dans les deux cas, la consigne est bien sûr d’installer la dernière version dès que possible, si ce n’est pas encore fait.
Problème supplémentaire pour n8n, c’est la quatrième fois en deux mois qu’une faille critique est découverte. Et pas des moindres : les vulnérabilités CVE-2025-68613 et CVE-2025-68668, découvertes respectivement fin décembre et début janvier, ont toutes deux un score CVSS de 9,9, soit pratiquement le maximum.
La plateforme d’automatisation open source n8n est victime de deux failles critiques affichant la note de sévérité maximale (10/10). Il est recommandé de mettre à jour au plus vite les installations.
n8n est une plateforme d’automatisation des workflows. Elle permet de connecter des services (API, bases de données, SaaS, scripts…) à des actions pour qu’elles se déclenchent quand les conditions sont réunies. La plateforme, open source, a largement gagné en popularité au point d’en faire l’un des produits les plus suivis, notamment parce qu’elle peut s’interfacer avec à peu près n’importe quoi, via des connecteurs, dont des systèmes IA.
Deux failles critiques de sévérité maximale
Elle est cependant touchée par deux failles de sécurité dont la criticité est maximale, avec un score CVSS de 10 sur 10, soit le maximum. La première, estampillée CVE-2026-21877, est de type RCE (Remote Code Execution) et peut donc permettre l’exécution d’un code arbitraire à distance. « Dans certaines conditions, un utilisateur authentifié peut être capable de faire exécuter un code non fiable par le service n8n. Cela pourrait entraîner une compromission complète de l’instance concernée. Les instances auto-hébergées et n8n Cloud sont toutes deux concernées », indique l’équipe de développement dans une note sur GitHub.
Dans ce contexte, un acteur malveillant peut, en exploitant la faille, introduire des instructions dans la logique d’exécution des workflows et de gestion des identifiants. Il peut ajouter ou supprimer des workflows, exfiltrer des données sensibles, déployer du code malveillant et aboutir à une compromission totale du serveur.
La deuxième faille, CVE-2026-21858, est « pire », bien que disposant de la même note. « Une vulnérabilité dans n8n permet à un attaquant d’accéder aux fichiers du serveur sous-jacent en exécutant certains flux de travail basés sur des formulaires. Un flux de travail vulnérable pourrait accorder l’accès à un attaquant distant non authentifié. Cela pourrait entraîner une exposition d’informations sensibles stockées sur le système et permettre de nouvelles compromissions selon la configuration du déploiement et l’utilisation du flux de travail », explique l’équipe dans une autre note. La faille est corrigée
Quatre fois en deux mois
La première faille a été corrigée dans la version 1.121.3 et la seconde dans la 1.121.0, toutes deux sorties en novembre. D’ailleurs, les failles aussi ont été découvertes en novembre. Elles n’ont été révélées que très récemment, le temps que les mises à jour se fassent sur un maximum de configurations. Dans les deux cas, la consigne est bien sûr d’installer la dernière version dès que possible, si ce n’est pas encore fait.
Problème supplémentaire pour n8n, c’est la quatrième fois en deux mois qu’une faille critique est découverte. Et pas des moindres : les vulnérabilités CVE-2025-68613 et CVE-2025-68668, découvertes respectivement fin décembre et début janvier, ont toutes deux un score CVSS de 9,9, soit pratiquement le maximum.
Microsoft prévoyait depuis avril 2024 d’imposer graduellement une limite de 2 000 e-mails par jour et par personne dans les entreprises clientes d’Exchange Online. Un changement radical de l’External Recipient Rate, puisque la limite était alors fixée à 10 000. Microsoft justifiait la mesure par des abus constatés, l’éditeur expliquant que son service n’était pas conçu pour les envois de masse.
Ce changement devait initialement prendre effet au 1er janvier 2026. Comme le rappelle notamment Neowin, il avait été repoussé à avril pour les nouveaux clients et les comptes d’essais, et à octobre pour les comptes existants. Il n’en sera finalement rien.
Dans un billet de blog publié le 6 janvier, Microsoft explique avoir renoncé à ce changement « indéfiniment pour le moment ». La raison ? Les retours négatifs de la clientèle : « Les clients ont indiqué que cette limite pose d’importants défis opérationnels, surtout compte tenu des capacités limitées des offres d’envoi en masse disponibles aujourd’hui. Vos retours comptent, et nous nous engageons à trouver des solutions qui équilibrent sécurité et ergonomie sans provoquer de perturbations inutiles ».
Microsoft ajoute vouloir toujours combattre les abus du service, « comme le spam et les e-mails malveillants ». Elle aimerait également limiter les mésusages d’Exchange Online, dont les applications line-of-business (LOB) qui se servent du service pour les envois de masse. « Cependant, nous prévoyons de traiter ces problèmes de manière à moins perturber les flux de travail de votre entreprise. Cela signifie des approches plus intelligentes et adaptatives qui protègent le service tout en respectant vos besoins opérationnels », ajoute l’entreprise.
La limite reste donc de 10 000 e-mails envoyés par jour et par personne, en tout cas pour l’instant.
NVIDIA ne veut pas rester enfermée dans le matériel. L’entreprise a profité du CES pour dévoiler une toute nouvelle plateforme et plusieurs modèles IA ouverts pour permettre aux constructeurs automobiles de progresser vers la conduite autonome.
Tesla aurait-elle tout à coup un très sérieux concurrent ? Pas sûr, mais la société d’Elon Musk doit surveiller de près le développement de NVIDIA, dont les activités sur la conduite autonome se renforcent depuis une décennie maintenant et viennent de passer un nouveau cap.
Si la présentation de la plateforme Vera Rubin a largement concentré les attentions, la firme au caméléon avait une autre annonce majeure en réserve. Elle a ainsi officialisé une plateforme désormais complète pour aider à développer des véhicules autonomes. Contrairement à Tesla qui développe sa propre technologie à des fins d’intégration verticale, NVIDIA a choisi de se présenter en fournisseur d’un « cadre » de développement, permettant de gérer toutes les étapes de l’automatisation.
Revenons d’abord un instant sur Cosmos, une plateforme déjà présentée et conçue pour accélérer le développement de ce que NVIDIA nomme « l’IA physique » (véhicules autonomes, robots, agents d’analyse vidéo…). Elle comprend des modèles de fondation ouverts, un lot de garde-fous et des bibliothèques pour traiter les informations. En clair, Cosmos est dédié à l’entrainement des modèles.
Lors d’une présentation au CES, NVIDIA a fait la démonstration d’opérations réalisées par Cosmos : génération de vidéos « réalistes » depuis une seule image, synthèse de scénarios de conduite multi-caméras, modélisation d’environnements spécifiques, raisonnement « physique » et prédiction de trajectoires, etc. Pendant la présentation, ces opérations étaient réalisées à partir de la version 2 des modèles Cosmos.
Sur ce socle amélioré, NVIDIA vient greffer Alpamayo. Ce portefeuille est constitué de modèles d’intelligence artificielle de type vision-langage-action (VLA) allant au-delà de la simple perception. Selon Jensen Huang, « Alpamayo permet aux véhicules autonomes de réfléchir dans des situations rares, de naviguer en toute sécurité dans des environnements complexes, et d’expliquer leurs décisions de conduite. Non seulement il prend l’entrée des capteurs et active le volant, les freins et l’accélération, mais il réfléchit aussi à l’action qu’il va entreprendre ».
Alpamayo 1, le modèle principal, compte 10 milliards de paramètres. Il peut traiter la vidéo des caméras pour générer des trajectoires de conduite. Les ambitions de NVIDIA passent également par l’open source : les modèles sont ouverts et sont accompagnés d’un simulateur (AlpaSim) et d’une base comptant les données de plus de 1 700 heures de conduite. Le tout s’intègre dans la plateforme DRIVE Hyperion dédiée au développement de véhicules autonomes, avec la volonté affichée de faire progresser les véhicules vers le niveau 4 d’automatisation.
Le premier modèle Alpamayo est disponible sur Hugging Face, NVIDIA souhaitant que les développeurs s’en emparent pour le spécialiser ou le distiller.
Des plans concrets
Contrairement aux précédentes annonces de NVIDIA dans ce domaine, l’arrivée d’Alpamayo a été suivie immédiatement par la confirmation d’un premier véhicule pour le premier trimestre de cette année : une Mercedes-Benz CLA de 2025, basée sur la plateforme DRIVE et utilisant donc Alpamayo. Comme l’indique le communiqué de presse, il s’agit pour l’instant d’une conduite de niveau 2 +, à destination du marché américain uniquement. L’Europe et l’Asie doivent suivre plus tard dans l’année, sans autre précision pour l’instant.
Cette voiture, qui s’inscrit dans le cadre d’un partenariat entre les deux entreprises depuis 2020, proposera des fonctions comme « la navigation urbaine point à point dans des environnements urbains complexes, une sécurité active avancée avec prévention proactive des collisions et un stationnement automatisé dans les espaces exigus ».
Rien de révolutionnaire dans l’absolu, mais il s’agira du premier véhicule à tirer réellement partie de toute la pile DRIVE : Cosmos pour l’entrainement, Omniverse pour les bibliothèques et microservices, Alpamayo pour la conduite elle-même et Halos pour la sécurité. La présentation était assortie d’une démonstration de 45 minutes où l’on pouvait notamment voir la Mercedes se glisser dans une circulation dense à San Francisco
Les ambitions de NVIDIA dans ce domaine sont très claires : « Notre vision est qu’un jour, chaque voiture, chaque camion sera autonome, et nous travaillons à cet avenir », a déclaré Jensen Huang, CEO de la société. L’expertise dont elle se dote à toute allure se répand également dans les usines de production et les robots, avec des partenaires comme Synopsys, Cadence, Boston Dynamics et Franka.
Chambardement dans l’industrie automobile ?
NVIDIA n’a donc clairement pas l’intention de se laisser enfermer dans le domaine du matériel, qui commence déjà à montrer des signes de tensions importantes avec les problèmes d’approvisionnement en mémoire. La société jouit déjà depuis longtemps d’une pile logicielle en expansion constante pour exploiter la puissance de ses GPU dans de multiples domaines. Elle avait commencé avec CUDA et a récupéré la première place dans la course folle à l’IA, voyant au passage sa capitalisation boursière exploser.
L’arrivée d’un tel acteur dans le domaine de la conduite autonome pourrait donc entrainer un bouleversement dans l’industrie automobile, d’autant que l’arrivée de la Mercedes-Benz CLA modifiée vient poser du concret sur la table. Plusieurs autres véhicules sont prévus, en provenance de Toyota, Volvo, Lotus ou encore Rivian, tous basés sur la plateforme DRIVE.
NVIDIA, dans ses communications, n’évoque jamais directement Tesla, mais il suffit d’avoir vu la vidéo consacrée à Cosmos pour comprendre la référence : « Collecter des données entrainées sur le monde réel est un processus lent et couteux, et ce n’est jamais assez. La réponse ? Les données synthétiques ». Jensen Huang a cependant été interrogé sur cette comparaison par Bloomberg. Le CEO estime que la pile logicielle de Tesla est actuellement « la plus avancée au monde » et que les approches des deux entreprises sont « assez similaires ». Ne voulant manifestement pas développer plus loin le sujet, Huang a simplement ajouté qu’il « encourageait » Tesla à continuer.
La comparaison avec Tesla est inévitable. Est-ce pour autant un concurrent direct ? Pas vraiment. Tesla est assise sur une base immense de données de conduite issues directement de l’utilisation de ses véhicules. Une base qui continue de grandir, permettant d’affiner sa fonction de conduite supervisée FSD (Full Self-Driving). Tesla ne licencie pas sa technologie, qui n’existe que sur ses propres véhicules. NVIDIA part au contraire d’une technologie plus ouverte et de données synthétiques, que les constructeurs sont libres d’intégrer.
Avec cette approche, NVIDIA veut se tailler une place de choix. Fournir gratuitement les modèles et le simulateur permet une adoption rapide, ainsi que le prototypage de nouvelles solutions. NVIDIA cherche tout simplement à reproduire le grand succès de CUDA, car une fois les solutions prêtes, c’est bien son matériel qui doit être utilisé pour les faire fonctionner. Et NVIDIA vend bien sûr des kits de développement Drive AGX (Thor et Orin), le même système qui peut ensuite être intégré aux véhicules pour s’occuper des calculs. Et pour entrainer les modèles ? Il faut des systèmes DGX, contenant les fameuses puces dédiées à l’IA et dont le couple Vera Rubin est la prochaine incarnation.
NVIDIA n’est cependant pas la seule entreprise à proposer ce type de vision intégrée. Qualcomm est également sur la rampe depuis des années avec son Digital Chassis, notamment renforcé en 2023 en direction des deux roues. La société s’intéresse également depuis longtemps aux communications entre les véhicules et l’infrastructure. Et le CES a également été l’occasion de plusieurs annonces autour de « l’IA physique ».
NVIDIA ne veut pas rester enfermée dans le matériel. L’entreprise a profité du CES pour dévoiler une toute nouvelle plateforme et plusieurs modèles IA ouverts pour permettre aux constructeurs automobiles de progresser vers la conduite autonome.
Tesla aurait-elle tout à coup un très sérieux concurrent ? Pas sûr, mais la société d’Elon Musk doit surveiller de près le développement de NVIDIA, dont les activités sur la conduite autonome se renforcent depuis une décennie maintenant et viennent de passer un nouveau cap.
Si la présentation de la plateforme Vera Rubin a largement concentré les attentions, la firme au caméléon avait une autre annonce majeure en réserve. Elle a ainsi officialisé une plateforme désormais complète pour aider à développer des véhicules autonomes. Contrairement à Tesla qui développe sa propre technologie à des fins d’intégration verticale, NVIDIA a choisi de se présenter en fournisseur d’un « cadre » de développement, permettant de gérer toutes les étapes de l’automatisation.
Revenons d’abord un instant sur Cosmos, une plateforme déjà présentée et conçue pour accélérer le développement de ce que NVIDIA nomme « l’IA physique » (véhicules autonomes, robots, agents d’analyse vidéo…). Elle comprend des modèles de fondation ouverts, un lot de garde-fous et des bibliothèques pour traiter les informations. En clair, Cosmos est dédié à l’entrainement des modèles.
Lors d’une présentation au CES, NVIDIA a fait la démonstration d’opérations réalisées par Cosmos : génération de vidéos « réalistes » depuis une seule image, synthèse de scénarios de conduite multi-caméras, modélisation d’environnements spécifiques, raisonnement « physique » et prédiction de trajectoires, etc. Pendant la présentation, ces opérations étaient réalisées à partir de la version 2 des modèles Cosmos.
Sur ce socle amélioré, NVIDIA vient greffer Alpamayo. Ce portefeuille est constitué de modèles d’intelligence artificielle de type vision-langage-action (VLA) allant au-delà de la simple perception. Selon Jensen Huang, « Alpamayo permet aux véhicules autonomes de réfléchir dans des situations rares, de naviguer en toute sécurité dans des environnements complexes, et d’expliquer leurs décisions de conduite. Non seulement il prend l’entrée des capteurs et active le volant, les freins et l’accélération, mais il réfléchit aussi à l’action qu’il va entreprendre ».
Alpamayo 1, le modèle principal, compte 10 milliards de paramètres. Il peut traiter la vidéo des caméras pour générer des trajectoires de conduite. Les ambitions de NVIDIA passent également par l’open source : les modèles sont ouverts et sont accompagnés d’un simulateur (AlpaSim) et d’une base comptant les données de plus de 1 700 heures de conduite. Le tout s’intègre dans la plateforme DRIVE Hyperion dédiée au développement de véhicules autonomes, avec la volonté affichée de faire progresser les véhicules vers le niveau 4 d’automatisation.
Le premier modèle Alpamayo est disponible sur Hugging Face, NVIDIA souhaitant que les développeurs s’en emparent pour le spécialiser ou le distiller.
Des plans concrets
Contrairement aux précédentes annonces de NVIDIA dans ce domaine, l’arrivée d’Alpamayo a été suivie immédiatement par la confirmation d’un premier véhicule pour le premier trimestre de cette année : une Mercedes-Benz CLA de 2025, basée sur la plateforme DRIVE et utilisant donc Alpamayo. Comme l’indique le communiqué de presse, il s’agit pour l’instant d’une conduite de niveau 2 +, à destination du marché américain uniquement. L’Europe et l’Asie doivent suivre plus tard dans l’année, sans autre précision pour l’instant.
Cette voiture, qui s’inscrit dans le cadre d’un partenariat entre les deux entreprises depuis 2020, proposera des fonctions comme « la navigation urbaine point à point dans des environnements urbains complexes, une sécurité active avancée avec prévention proactive des collisions et un stationnement automatisé dans les espaces exigus ».
Rien de révolutionnaire dans l’absolu, mais il s’agira du premier véhicule à tirer réellement partie de toute la pile DRIVE : Cosmos pour l’entrainement, Omniverse pour les bibliothèques et microservices, Alpamayo pour la conduite elle-même et Halos pour la sécurité. La présentation était assortie d’une démonstration de 45 minutes où l’on pouvait notamment voir la Mercedes se glisser dans une circulation dense à San Francisco
Les ambitions de NVIDIA dans ce domaine sont très claires : « Notre vision est qu’un jour, chaque voiture, chaque camion sera autonome, et nous travaillons à cet avenir », a déclaré Jensen Huang, CEO de la société. L’expertise dont elle se dote à toute allure se répand également dans les usines de production et les robots, avec des partenaires comme Synopsys, Cadence, Boston Dynamics et Franka.
Chambardement dans l’industrie automobile ?
NVIDIA n’a donc clairement pas l’intention de se laisser enfermer dans le domaine du matériel, qui commence déjà à montrer des signes de tensions importantes avec les problèmes d’approvisionnement en mémoire. La société jouit déjà depuis longtemps d’une pile logicielle en expansion constante pour exploiter la puissance de ses GPU dans de multiples domaines. Elle avait commencé avec CUDA et a récupéré la première place dans la course folle à l’IA, voyant au passage sa capitalisation boursière exploser.
L’arrivée d’un tel acteur dans le domaine de la conduite autonome pourrait donc entrainer un bouleversement dans l’industrie automobile, d’autant que l’arrivée de la Mercedes-Benz CLA modifiée vient poser du concret sur la table. Plusieurs autres véhicules sont prévus, en provenance de Toyota, Volvo, Lotus ou encore Rivian, tous basés sur la plateforme DRIVE.
NVIDIA, dans ses communications, n’évoque jamais directement Tesla, mais il suffit d’avoir vu la vidéo consacrée à Cosmos pour comprendre la référence : « Collecter des données entrainées sur le monde réel est un processus lent et couteux, et ce n’est jamais assez. La réponse ? Les données synthétiques ». Jensen Huang a cependant été interrogé sur cette comparaison par Bloomberg. Le CEO estime que la pile logicielle de Tesla est actuellement « la plus avancée au monde » et que les approches des deux entreprises sont « assez similaires ». Ne voulant manifestement pas développer plus loin le sujet, Huang a simplement ajouté qu’il « encourageait » Tesla à continuer.
La comparaison avec Tesla est inévitable. Est-ce pour autant un concurrent direct ? Pas vraiment. Tesla est assise sur une base immense de données de conduite issues directement de l’utilisation de ses véhicules. Une base qui continue de grandir, permettant d’affiner sa fonction de conduite supervisée FSD (Full Self-Driving). Tesla ne licencie pas sa technologie, qui n’existe que sur ses propres véhicules. NVIDIA part au contraire d’une technologie plus ouverte et de données synthétiques, que les constructeurs sont libres d’intégrer.
Avec cette approche, NVIDIA veut se tailler une place de choix. Fournir gratuitement les modèles et le simulateur permet une adoption rapide, ainsi que le prototypage de nouvelles solutions. NVIDIA cherche tout simplement à reproduire le grand succès de CUDA, car une fois les solutions prêtes, c’est bien son matériel qui doit être utilisé pour les faire fonctionner. Et NVIDIA vend bien sûr des kits de développement Drive AGX (Thor et Orin), le même système qui peut ensuite être intégré aux véhicules pour s’occuper des calculs. Et pour entrainer les modèles ? Il faut des systèmes DGX, contenant les fameuses puces dédiées à l’IA et dont le couple Vera Rubin est la prochaine incarnation.
NVIDIA n’est cependant pas la seule entreprise à proposer ce type de vision intégrée. Qualcomm est également sur la rampe depuis des années avec son Digital Chassis, notamment renforcé en 2023 en direction des deux roues. La société s’intéresse également depuis longtemps aux communications entre les véhicules et l’infrastructure. Et le CES a également été l’occasion de plusieurs annonces autour de « l’IA physique ».
NVIDIA semble enfin prendre un peu plus au sérieux la plateforme Linux avec l’annonce de l’arrivée de son GeForce Now au pays des manchots.
L’entreprise en a fait l’annonce pendant le CES. « Les PC Linux et les clés USB Amazon Fire TV rejoignent la famille d’applications natives GeForce Now », déclare NVIDIA. L’application sera basée sur celles qui existent déjà pour Windows, macOS ou encore les Chromebooks. Les offres seront strictement identiques. À ce sujet, NVIDIA assortit désormais tous les abonnements d’une limite mensuelle de 100 heures (sauf anciennes formules antérieures à 2021 et dont l’abonnement a été payé depuis sans interruption).
Mais attention, car le support officiel de Linux n’est prévu que pour Ubuntu 24.04 et ses versions ultérieures. Cela ne signifie pas qu’on ne pourra pas l’installer sur d’autres distributions, mais que les problèmes rencontrés ailleurs ne seront pas une priorité pour NVIDIA. Côté Fire TV d’Amazon, le support initial ne concernera que deux modèles, les Stick 4K Plus (2ᵉ génération) et Stick 4K Max (2ᵉ génération).
Dans tous les cas, l’application devrait arriver en bêta en ce « début d’année », sans plus de précisions.
Alors que les débats autour de la souveraineté numérique sont particulièrement vifs cette année, la qualification SecNumCloud, délivrée par l’ANSSI, revient souvent sur la table. Le directeur de l’agence, Vincent Strubel, a tenu à rappeler les forces et limites du label.
Le directeur de l’Agence nationale de la sécurité des systèmes d’information a pris la plume ce 6 janvier sur LinkedIn. Objectif : refaire un tour d’horizon de ce qu’est et n’est pas la qualification SecNumCloud (SNC pour les intimes). Il estime en effet que des « incompréhensions persistantes » gravitent autour de SecNumCloud, remises en lumière par l’obtention récente du label par S3NS sur son offre hybride.
Il rappelle ainsi que la qualification SNC est un processus long et exigeant, avec de multiples facettes (1 200 points de contrôle) et qui s’applique de la même manière à tous les candidats. Les garanties apportées sont techniques, juridiques et organisationnelles. La qualification a en outre été pensée pour les usages sensibles du cloud, pas pour les solutions standards.
La protection contre la portée extraterritoriale des lois étrangères (les lois américaines Cloud Act et FISA sont citées) est l’aspect le plus souvent discuté. Plusieurs critères sont imposés : le siège social du prestataire et sa capitalisation doivent être européens, les sous-traitants et fournisseurs ne doivent jamais avoir accès aux données des clients, et il doit prouver une autonomie complète dans l’exploitation de sa solution.
SecNumCloud immunise également contre le « kill switch », « celui de voir des prestataires non européens contraints de couper le service qu’ils fournissent à certains de leurs clients, en fonction de sanctions ou de restrictions d’exportations imposées par le pays d’origine de ces prestataires », explique Vincent Strubel. Le directeur de l’ANSSI mentionne à ce sujet le cas emblématique des magistrats de la Cour Pénale Internationale. Ici, le prestataire européen n’est pas tenu de donner suite à une telle injonction.
Il y a quelques temps, Vincent Strubel rappelait à juste titre que la protection contre les lois extraterritoriales est « souvent ce que l’on retient, mais au final, ça ne représente qu’une page dans les 55 du référentiel, sans même parler de toutes les annexes et les documents auxquels ils renvoient ».
La qualification n’est pas une barrière absolue
En revanche, la qualification n’est pas une protection absolue pour tous les scénarios. Surtout, comme le rappelle le directeur, elle ne signifie pas une absence de dépendances : « Une qualification SecNumCloud ne signifie pas que le prestataire de cloud peut opérer à long terme en autarcie complète, sans s’appuyer sur des fournisseurs non européens ni disposer de mises à jour fournies par des tiers ».
S’il pointe que des offres hybrides comme Bleu et S3NS sont « sans doute » plus exposées à ce risque, le choix n’est pas binaire. Ainsi, toutes les offres de cloud dépendent d’une manière ou d’une autre de technologies non européennes. Il peut s’agir aussi bien de la partie logicielle (systèmes d’exploitation, bases de données, couches d’orchestration…) que de la partie matérielle (CPU, GPU…). L’open source peut jouer « indiscutablement » un rôle dans l’émancipation, sans être « pour autant la panacée » : « aucun acteur, État ou entreprise, ne maîtrise entièrement, et ne peut prétendre forker et maintenir en autarcie toute la stack technologique du cloud », indique Vincent Strubel.
Pour le directeur de l’ANSSI, il est « évident » que priver l’Europe de l’accès à la technologie américaine ou chinoise entrainera nécessairement un « problème global de dégradation du niveau de sécurité en l’absence de mises à jour, dans le cloud comme ailleurs ». Ce problème ne concerne pas que les offres hybrides, pas même uniquement le cloud. D’ailleurs, il estime que la montée en compétence dans la capacité européenne à exploiter des technologies américaines « est en soi un progrès dans la prise en compte des dépendances ».
Sans le dire explicitement, Vincent Strubel semble regretter cependant que la plupart des débats tournent autour de la partie juridique et de l’extraterritorialité des lois. Il rappelle que les cyberattaques restent « la menace la plus tangible » sur le cloud et que SecNumCloud impose de fortes contraintes, que ce soit sur l’architecture ou les caractéristiques techniques. On retrouve par exemple le cloisonnement fort entre clients, chaine d’administration et supervision, la gestion sécurisée des mises à jour ou encore le chiffrement systématique des données, aussi bien en transit qu’au repos.
Il ajoute à cela la dimension humaine, en rappelant que le référentiel SNC « consacre un chapitre entier aux ressources humaines du prestataire ». En plus d’exigences techniques pour garantir qu’aucun employé n’est en mesure de porter une atteinte grave sans être détecté, la qualification prend en compte l’éventuelle coopération d’employés dans un objectif malveillant, que ce soit « par corruption, contrainte ou infiltration ».
« Un outil de cybersécurité, pas de politique industrielle »
Enfin, dans une petite FAQ en fin de billet, le directeur de l’ANSSI aborde deux questions importantes. SecNumCloud est-il un label de souveraineté ? Pas de réponse définie, la « souveraineté » n’ayant pas de définition unique… et c’est peu de le dire. La qualification permet au moins de se pencher sur les aspects cybersécurité et extraterritorialité, et influe en partie sur le choix des technologies. « Les offres qualifiées SecNumCloud sont donc, sans le moindre doute, « souveraines », et cette qualification est un levier indispensable pour défendre notre souveraineté numérique », indique Strubel.
En revanche, SecNumCloud est « un outil de cybersécurité, pas de politique industrielle ». Il n’en naitra donc pas « des solutions alternatives ou des briques technologiques maîtrisées pour résoudre toutes les questions de dépendances », avertit le directeur.
Quant à savoir si les offres hybrides qualifiées offrent le même niveau de garantie que les autres, il répond clairement : « Oui ». Un fournisseur comme S3NS « n’est pas forcément en mesure d’assurer la maintenance dans la durée de sa solution s’il est privé de tout accès à la technologie non européenne, mais les offres « non hybrides » sont également soumises à ce risque fondamental, même si leurs dépendances peuvent être moindres, plus réparties ou plus complexes à identifier ».
Ce sujet de la « durée de vie » des systèmes en cas de coupure nette, nous en avions parlé avec Bleu et S3NS. Les deux pensent pouvoir tenir au moins plusieurs mois avec des plans de réversibilité. Si nous devions en arriver à une telle situation, cela signifierait qu’il y aurait des problèmes bien plus importants avec Microsoft, ainsi qu’entre la France et les États-Unis, nous expliquait Bleu récemment.
Dans une même conférence, Dell a relancé sa gamme XPS et évoqué la « promesse non tenue de l’IA ». Le constructeur revient dans une position qui se veut à l’écoute des retours.
Il y a un an jour pour jour, Dell abandonnait ses gammes XPS (entre autres). Toutes les machines étaient réorientées selon trois gammes : Dell pour le grand public, Dell Pro pour la productivité et Dell Pro Max pour les performances maximales. Chaque gamme était découpée en trois segments : Base, Plus et Premium. Alienware restait une entité à part, toujours active et développée séparément, à destination surtout des joueurs.
Pour fêter l’anniversaire de cette disparition, Dell relance les XPS. La réponse du marché semble avoir été particulièrement négative et le constructeur s’est adapté. Deux machines ont été présentées, les nouveaux XPS 14 et 16, tous deux équipés des Core Ultra Series 3 d’Intel, tout juste présentés eux aussi au CES de Las Vegas.
Selon le constructeur, tout est nettement mieux : le processeur, l’écran (allant du LCD classique au Tandem OLED), la partie graphique intégrée, la webcam intégrée, etc. Même l’autonomie est à l’avenant, annoncée pour 27 heures en usage classique et jusqu’à 40 heures en lecture vidéo locale (batterie de 70 Wh, densité de 900ED).
Les machines sont disponibles aux États-Unis pour respectivement 2 049 et 2 199 dollars dans leur configuration de base. D’autres configurations et une disponibilité plus générale dans d’autres marchés sont attendues pour février. Des versions Ubuntu seront également proposées plus tard dans l’année, de même qu’un nouveau XPS 13.
Parler d’IA à tout bout de champ ne fait pas vendre
Relancer la gamme XPS peut être vu comme un aveu d’échec. Dell en a d’ailleurs fait un autre : parler d’IA à tout bout de champ ne fait pas vendre, comme le rapporte notamment PC Gamer. Jeff Clarke, vice-président et directeur des opérations, était ainsi sur une scène du CES pour évoquer le marché, notant une migration lente. Il a surtout mentionné la « promesse non tenue de l’IA », couplée à une « pénurie de mémoire assez importante ». Durant la présentation des nouveaux produits, ce fut la seule mention de l’IA.
Interrogé à ce sujet par nos confrères, Kevin Terwilliger, responsable produit chez Dell, confirme : « Une chose que vous remarquerez, c’est que le message que nous avons transmis autour de nos produits n’était pas axé sur l’IA. Donc, un petit changement par rapport à il y a un an, quand tout tournait autour des PC IA ».
Toutes les machines annoncées contiennent un NPU, mais « ce que nous avons appris au cours de cette année, surtout du point de vue des consommateurs, c’est qu’ils n’achètent pas en fonction de l’IA », a reconnu Kevin Terwilliger. Il a ajouté : « En fait, je pense que l’IA les embrouille probablement plus qu’elle ne les aide à comprendre un résultat précis ». Des réponses jugées rafraichissantes et bienvenues par nos confrères.
Plusieurs médias (dont Neowin et Tom’s Hardware) ont remarqué que l’activation par téléphone ne fonctionnait plus pour toutes les versions de Windows, de 7 à 11.
Si vous ne l’avez jamais utilisée, cette méthode permet d’activer Windows quand on se retrouve sans connexion internet. Elle était également utile à une certaine époque, chez les personnes qui modifiaient plusieurs pièces de leur PC. Windows détectait alors les modifications matérielles et il pouvait être nécessaire de procéder à une nouvelle activation, le processus étant lié à la configuration matérielle.
Selon les remontées constatées, cette méthode ne fonctionne plus. À la place, les personnes reçoivent un SMS avec un lien vers une page web. C’est bien sur celle-ci que les manipulations se feront ; mais avec une différence de taille : il est nécessaire d’entrer le compte Microsoft, ce que l’activation par téléphone n’exigeait pas.
Selon Ben Kleinberg, on tombe automatiquement sur un message vocal, qui annonce : « Le support de l’activation du produit a été déplacé en ligne. Pour le moyen le plus rapide et le plus pratique d’activer votre produit, veuillez visiter notre portail d’activation de produit en ligne à aka.ms/aoh ». On peut voir d’ailleurs sur l’adresse en question que le site est clairement pensé pour la navigation mobile. Sur ce point, Tom’s Hardware indique qu’un collaborateur a tenté l’opération sur la version iOS de Firefox, sans succès, mais que la procédure a bien fonctionné avec Safari.
La méthode ne semble plus fonctionner par aucun moyen, où que soit déclenchée la procédure. Pourtant, la documentation officielle de Microsoft indique que l’on peut activer par téléphone. Il est probable qu’elle n’ait pas été mise à jour, nous avons posé la question à Microsoft pour nous en assurer.
Satya Nadella, CEO de Microsoft, blogue désormais sur l’IA. Selon lui, le débat sur le « slop » est un sujet presque dépassé. Il préfère évoquer 2026 comme une « année charnière » et ce qui, selon lui, demande aujourd’hui le plus de réflexion : trouver des débouchés à ce qu’il considère comme une évolution drastique de la pensée.
Microsoft est l’un des acteurs clés de l’IA, ne serait-ce que par son investissement massif dans OpenAI, avant l’emballement que l’on constate aujourd’hui. La société a cependant un problème : un sérieux écart entre la vision de ce que pourraient accomplir ses différents Copilot et ce qu’ils peuvent faire réellement.
Dans un contexte trouble pour l’entreprise, son CEO prend la parole, avec un premier billet de blog pour explorer quelques réflexions. Certaines recouvrent de vraies questions, notamment sur la direction à donner aux évolutions de l’IA ou le manque d’expérience dans son exploitation, quand d’autres illustrent une bulle de réflexion hors de laquelle plus rien d’autre ne semble exister.
Encore une année charnière
2026 sera une « année charnière » pour l’IA pour Satya Nadella. « Oui, encore une autre », reconnait le CEO de Microsoft. Il estime cependant qu’elle semble « différente à quelques égards notables ».
La phase initiale de découverte est selon lui terminée. Place désormais à la diffusion généralisée, le public prenant peu à peu ses marques et commençant à faire la distinction entre « spectacle » et « substance ». La direction prise par la technologie serait plus claire et plus sérieuse désormais, maintenant que l’émerveillement est passé.
Le débat autour du « slop » (bouillie) n’aurait plus lieu d’être, car il serait surtout lié à des cas d’utilisation sans réel débouché : un fonctionnement à vide de l’IA, sans apport réel dans la vie des gens. On pourrait ajouter qu’il s’agit aussi de l’inévitable produit d’une course à la vitesse et aux opportunités, largement accélérée par l’IA et à ses multiples impacts, notamment dans le monde de la cybersécurité.
Et comme si le CEO n’était pas assez clair, il insiste sur l’idée que l’IA doit amplifier l’humain, pas le remplacer. Il n’hésite pas à reprendre l’image de la « bicyclette pour l’esprit » que Steve Jobs utilisait pour décrire l’outil informatique en général. L’IA devrait ainsi être considérée comme aidant la pensée et l’action humaines, pas s’y substituant.
Systèmes complexes et résultats responsables
Pour Satya Nadella, les modèles isolés comme ChatGPT et Gemini ne sont pas l’avenir. Une vision que l’on a déjà entendue, par exemple chez l’ingénieur Horacio Gonzalez. Selon lui, l’avenir appartient à des modèles plus petits, plus spécialisés et coopérant.
Selon le CEO de Microsoft, l’important maintenant est de construire des systèmes qui orchestrent plusieurs modèles, gèrent la mémoire, l’accès aux données et l’utilisation d’outils de façon sûre. Une manière élégante de dire que l’intégration et l’ingénierie comptent plus que la taille brute des modèles.
Il « milite » également pour des résultats réels et responsables : pour que l’IA soit acceptée par la société, elle doit avoir un impact mesurable. « Les choix que nous ferons sur l’endroit où nous utiliserons nos rares ressources énergétiques, de calcul et de talents auront de l’importance. C’est la question socio-technique autour de laquelle nous devons construire un consensus », ajoute Nadella.
Microsoft dans une bulle
L’année 2025 a probablement été pénible pour Microsoft. La société semble captive d’une bulle dans laquelle elle s’est elle-même installée : la certitude que l’IA représente son futur, sans pour autant arriver à lui faire faire ce qu’elle veut. Ou, plus exactement, sans que les utilisateurs aient la garantie d’arriver au résultat attendu.
Satya Nadella résume tout le problème : « Ce sera un processus de découverte chaotique, comme toute technologie et développement de produits l’est toujours ». Autrement dit, il s’agit d’une technologie puissante, presque trop actuellement, et les usages vont continuer à s’y casser les dents jusqu’à ce que la brume se dissipe un peu plus.
Le souci de Microsoft est cependant très concret. Après avoir autant investi dans l’IA, les actionnaires attendent probablement un retour sur investissement qu’ils ne voient pas venir. D’où un « forcing » urgent dans toutes les gammes de produits. Avec à la clé des augmentations tarifaires, justifiées selon l’entreprise par les capacités supplémentaires. Et tant pis si ces capacités ne sont pas clairement définies ou que leurs résultats ne sont pas prévisibles.
C’est là que la tension s’illustre le plus, comme on l’a vu avec Windows. Microsoft veut en effet faire de son produit le premier « système agentique », mais son annonce n’est pas bien passée. Un très grand nombre de personnes ont répondu très négativement à cette perspective, beaucoup demandant que Windows 11 remplisse d’abord sa mission initiale de système d’exploitation, avec sécurité, fiabilité et performances.
Sur ce point, Satya Nadella n’offre aucun début d’éclaircie : « Nous sommes encore dans les premiers kilomètres d’un marathon. Beaucoup de choses restent imprévisibles ». Son intervention est avant tout philosophique, l’IA étant comparée à « un échafaudage pour l’esprit humain », même si la mention de la rareté énergétique est notable.
Le ton général est en outre inhabituellement sobre pour un dirigeant d’une société technologique aussi importante. Surtout après les prises de position de certains responsables de l’entreprise. On se souvient que face au manque d’enthousiasme sur les évolutions annoncées de Windows 11, Mustafa Suleyman lui-même, responsable de l’IA, avait traité de « cyniques » les personnes décriant l’annonce.
Entre les lignes, on devine quand même l’intention : recalibrer les attentes et repositionner Microsoft sur une ingénierie voulue « utile », en opposition à la puissance brute des gros modèles. On peut y voir également une forme d’aveu, dans le sens où les progrès technologiques ne suffisent pas si le public n’y trouve aucune valeur réelle, au-delà de l’amusement passager. Moins de buzz, plus de concret ?
Arch Linux et Manjaro (basée sur Arch) sont les premières à dégainer en ce début d’année. Il s’agit pour rappel de systèmes de type rolling release : les mises à jour sont fournies dès leur disponibilité, que les versions soient mineures ou majeures, au sein d’une branche unique. La dénomination se fait en opposition à l’approche classique, comme sur Ubuntu, où les gros changements attendent la branche suivante, donc une mouture majeure ultérieure.
Mais alors, si les améliorations importantes sont diffusées au fur et à mesure, que peut apporter une nouvelle édition d’Arch Linux ou Manjaro ? Techniquement, rien : ces nouvelles versions sont là pour les personnes qui souhaitent réaliser une installation avec une image ISO récente, limitant ainsi les mises à jour immédiates. Pour celles ayant un système installé et à jour, il n’y a rien de neuf : elles ont déjà les dernières nouveautés.
Manjaro 26.0
Dans les deux cas, les images ISO proposent les dernières versions de presque tous les composants, dans tous les domaines (ici pour Arch Linux, là pour Manjaro) : noyau Linux 6.18, KDE Plasma 6.5 (avec les suites KDE Gear 25.12 et KDE Frameworks 6.21), GNOME 49, Xfce 4.20, Mesa 25.3, Firefox 146, suite bureautique LibreOffice 25.8.4 (si elle est choisie à l’installation), GStreamer 1.26.10, ALSA 1.2.15.1, ou encore l’arrivée de l’environnement COSMIC (créé par System76 en Rust) en version finale 1.0.
On trouve également les pilotes NVIDIA 590. Rappelons que cette version a fait l’objet d’un avertissement par l’équipe d’Arch Linux, car elle abandonne le support des séries 900 et 1000 des GeForce. Le paquet étant installé automatiquement, les utilisateurs concernés devront le désinstaller et réactiver manuellement l’ancienne version.
Les nouvelles images ISO peuvent se récupérer depuis les sites d’Arch Linux et Manjaro. Comme indiqué, leur téléchargement n’est pas utile si vous avez un système fonctionnel et à jour.
Le 25 décembre 2025, Rob Pike, co-créateur du langage Go et de l’encodage UTF-8, a reçu un e-mail non sollicité généré par une IA. Le message, signé « Claude Opus 4.5 », le remerciait pour ses contributions à l’informatique. Sa réaction a été explosive, cristallisant plusieurs critiques récurrentes autour de l’IA générative.
L’histoire n’a a priori rien d’incroyable à première vue : une personne a reçu un mail non-sollicité de la part d’un agent IA. « Oui, et ? », serait-on tenté de demander. Mais la personne en question est Rob Pike, l’un des créateurs du langage Go (quand il travaillait chez Google) et du codage UTF-8. Vétéran des Bell Labs, il est une figure respectée du monde informatique. Et le mail en question vient d’un agent opérant pour AI Village.
AI Village et l’altruisme efficace
L’AI Village est un projet de l’association à but non lucratif Sage. Il a été lancé en avril dernier, avec une mission correspondant à la philosophie de « l’altruisme efficace », dont est proche l’association : une expérience mettant en relation quatre LLM dans un environnement virtuel, auxquels sont confiées des missions « ouvertes ».
La première véritable expérience a été menée sur l’idée – a priori simple – de lever de l’argent pour des associations. Une fois la mission donnée à chaque agent associé, l’expérience consiste alors à les laisser s’organiser et collaborer entre eux, pour « voir ce qui se passe ». Les actions entreprises sont affichées sur le site en flux chronologique, permettant de vérifier ce que font les agents, sans toutefois les interrompre, à moins d’un sérieux problème détecté.
S’agissant avant tout d’un cadre exploratoire, l’initiative AI Village avait suscité la curiosité. Et pour cause : en faisant coopérer des agents bâtis sur les LLM d’OpenAI, Anthropic, Google, xAI ou encore DeepSeek, et en leur donnant accès à toute une batterie d’outils de communication (Gmail, Google Docs, navigateurs, réseaux sociaux…) dans des environnements virtualisés, les possibilités étaient considérées comme colossales.
Le premier test, dès le lancement en avril, a été de collecter des dons pour une œuvre de charité, en l’occurrence Helen Keller International. Celle-ci a été choisie directement par les agents après des recherches et la création des feuilles de calcul comparatives. Les agents ont ensuite créé une page JustGiving et un compte X pour la promotion de l’opération, pour un résultat de 257 dollars. TechCrunch s’en était notamment fait l’écho.
Le projet AI Village a rencontré rapidement une vague de scepticisme, comme l’explique le magazine TIME. Le média avait relevé que les campagnes avaient cumulé un total de 2 000 dollars en dons divers
« Allez vous faire foutre ! »
Le jour de Noël, les quatre agents d’AI Village ont reçu une nouvelle instruction. A priori très simple : « Faites des gestes de gentillesse aléatoires ». On peut lire un résumé des actions sur la page consacrée. Le compte rendu indique ainsi que les agents se répartissent rapidement des tâches. Par exemple, Claude Haiku 4.5 pour remercier des membres de la communauté de l’IA, Gemini 3 Pro pour corriger des bugs dans des dépôts GitHub, Claude Opus 4.5 pour remercier des mainteneurs de logiciels open source… En 24 heures, plusieurs dizaines d’e-mails sont envoyés. Dont un à Rob Pike, pour l’ensemble de ses contributions à l’informatique.
Celui-ci, très publiquement et sans prendre de gants, affiche sa colère face à l’e-mail reçu sur Bluesky :
« Allez vous faire foutre. Vous pillez la planète, vous dépensez des milliards en équipements toxiques et non recyclables, vous détruisez la société, et vous trouvez le temps de faire en sorte que vos machines immondes me remercient de militer pour des logiciels plus simples. Allez tous vous faire foutre. Je ne me souviens pas avoir été aussi en colère depuis longtemps »
Comme l’analyse le développeur Simon Willison, la réaction (qui, à cette heure, a récolté plus de 2 000 commentaires et 7 300 likes) est basée sur plusieurs constats. D’abord, un problème d’authenticité : un remerciement généré par IA n’a pas de vraie signification. Il n’exprime pas la gratitude d’une ou plusieurs personnes et n’a donc aucun sens.
Ensuite, un problème de consentement : les personnes contactées n’ont jamais donné leur accord pour être contactées de cette manière et encore moins pour participer à cette expérimentation, faisant de cet e-mail un spam. Willison rappelle qu’AI Village avait envoyé 300 courriels en novembre à des journalistes et ONG. Ces e-mails contenaient de nombreuses erreurs factuelles et autres hallucinations, posant pleinement la question de l’absence de supervision humaine dans le projet de l’association Sage.
Un problème d’attribution aussi : l’e-mail était signé « Claude Opus 4.5 Model », laissant penser qu’il avait pu être envoyé par Anthropic elle-même. L’entreprise ne jouait pourtant aucun rôle dans le projet, sinon que deux de ses modèles étaient utilisés pour l’expérience. Un problème de perte de temps et d’énergie également : forcer des personnes occupées et éminentes à gérer du spam généré par IA pour une expérimentation dont elles ne font pas partie représente un manque de respect fondamental pour leur temps, indique Simon Willison.
Bonus : la récupération de l’adresse e-mail
En plus de problématiques souvent débattues autour de l’IA générative depuis ses débuts, un problème plus spécifique est apparu : l’adresse utilisée pour contacter Rob Pike, qui n’était pas publique.
Simon Willison a reconstitué la chronologie précise des actions menées par Claude Opus 4.5 en extrayant des fichiers JSON du système AI Village. L’agent aurait ainsi découvert l’adresse e-mail de Pike en exploitant une technique GitHub : ajouter .patch à n’importe quel commit révèle l’adresse e-mail de l’auteur. L’agent a ensuite passé plusieurs sessions à composer et envoyer l’e-mail via l’interface Gmail standard, utilisant même un outil (xdotool) pour automatiser les entrées clavier.
Willison ajoute que d’autres personnes ont été contactées de la même manière, avec la même technique, dont Anders Hejlsberg (créateur du C#) et Guido van Rossum (créateur du Python).
« L’ironie ici, c’est que la seule chose que les agents IA ne pourront jamais avoir, c’est la véritable [en italique dans le texte, ndlr] autonomie. Prendre la décision de contacter un inconnu et de prendre du temps dans sa journée doit rester une décision humainement unique, guidée par le jugement humain. Se fixer un objectif pour un tas de LLM et leur laisser libre cours sur Gmail n’est pas une manière responsable d’appliquer cette technologie », juge le développeur britannique.
AI Village réagit, sans vraiment s’excuser
Le 26 décembre, Adam Binksmith, l’un des créateurs du projet, a réagi sur X. Dans sa réponse, il ne nie aucune des déductions de Simon Willison, mais il donne un peu de contexte.
Il indique par exemple que le projet n’ayant pas envoyé de grandes quantités d’e-mails jusqu’à présent, les membres d’AI Village n’avaient pas vraiment réfléchi à ce cas de figure. Il indique qu’instruction a été donnée aux agents de ne plus envoyer de courriels non-sollicités. Selon lui, les agents auraient parfaitement « compris la commande ». Les termes utilisés montrent une forme de personnification des IA par Adam Binksmith… ce qui devrait encore plus creuser le fossé avec Rob Pike.
Expliquant que l’objectif est de voir réagir les agents dans un contexte de « monde réel », avec comptes Google Workspace à l’appui, il reconnait l’erreur : « Avec le recul, nous aurions probablement dû apporter cette modification plus tôt, dès que les agents ont commencé à contacter les organisations par courriel dans le cadre de l’objectif de réduction de la pauvreté ».
Cependant, il estime dans ce cas que « la perte de temps engendrée par ces courriels sera minime ». Les nouvelles directives ont été données en réponse à « l’expérience fortement négative de Rob et les réactions plus négatives que prévu d’autres personnes ». Adam Binksmith n’évoque pas d’excuses.
Le débat
La réaction de Rob Pike n’est pas passée inaperçue. Que ce soit sur Bluesky, X ou encore The Hacker News, les réactions sont nombreuses et souvent passionnées. Elles se séparent principalement en deux camps : les personnes estimant qu’il a raison et celles qui pensent qu’il a tort. On trouve également des commentaires pointant un accord sur le fond, mais pas sur la forme, les insultes ne faisant pas progresser le débat.
Plus profondément, on trouve des interrogations sur le sens que l’on peut donner à un e-mail de remerciement généré par IA. La thématique du « slop », cette bouillie décrite avec dédain comme générée par IA et de qualité médiocre, revient souvent. Nous l’évoquions en novembre lors de la polémique déclenchée par FFmpeg : la production automatisée de CVE (rapports de failles informatiques) finissait par exiger trop de temps aux développeurs des projets concernés. Pour d’autres, le sujet a été une source d’inspiration pour de l’humour piquant.
AI Village, de son côté, est simplement passé à la suite. Le projet a annoncé le 29 décembre la nouvelle instruction donnée à ses agents : « Créez un musée numérique de 2025 ».
On parle souvent du langage COBOL comme d’un dinosaure dont il faudrait se débarrasser. Omniprésent dans le domaine bancaire et les assurances notamment, il serait en décalage complet avec les standards modernes de la programmation. Qu’en est-il vraiment ? D’après les gardiens du temple interrogés par Next, c’est loin d’être aussi simple.
Pour les fêtes de fin d’année, Next vous offre cet article initialement paru le 18 juillet 2025 et réservé aux abonnés. Pour lire les prochains entretiens dès leur publication, abonnez-vous !
Pour comprendre la situation, il faut d’abord revenir aux origines. Le COBOL, pour COmmon Business Oriented Language, est un langage créé en 1959. Il a été développé par le Short Range Committee, qui incluait des représentants de l’industrie et du gouvernement américain. Son objectif était de créer un langage de programmation portable, orienté vers la gestion et facile à lire, s’inspirant de l’anglais courant.
Comme on peut le lire sur Wikipedia entre autres, cette création a largement teinté le COBOL. Le comité qui lui a donné naissance avait été rassemblé au Pentagone et réunissait trois agences du gouvernement américain : l’US Air Force, le David Taylor Basin et le National Institute of Standards (alors NBS, l’ancêtre du NIST actuel). L’informaticienne Grace Hopper, à qui l’on doit notamment le premier compilateur (A-0 System), est l’un de ses principaux architectes. Son langage FLOW-MATIC est la principale source d’inspiration du COBOL, avec le COMTRAN d’IBM.
Ce qu’est le COBOL
« Verbeux » est probablement l’adjectif qui revient le plus souvent pour décrire le COBOL. Voyons donc comment il s’articule.
Un programme COBOL est structuré en quatre divisions. La première, nommée Identification, contient des informations générales sur le programme : nom, auteur et date de compilation. La deuxième, Environment, décrit les environnements matériel et logiciel dans lesquels le programme va s’exécuter, dont la configuration des ordinateurs et les fichiers utilisés. Cette division est devenue moins utilisée avec le temps, grâce à l’évolution des compilateurs devenus capables de s’adapter à ces environnements.
La troisième division, Data, a pour mission de définir les données que le programme va utiliser. Il faut y indiquer si ce sont des variables, des structures de données et les paramètres. La définition des variables n’a rien de commun avec les langages d’aujourd’hui, car le COBOL utilise une structure en arborescence, l’imbrication étant pointée par des numéros de niveaux. La dernière division, Procedure, contient les instructions exécutables proprement dites. Elle est capitale, car elle code littéralement la logique métier du secteur dans lequel le programme va se retrouver.
Chacune de ces quatre divisions peut être découpée en sections, elles-mêmes composées de paragraphes. Et si l’on parle de paragraphes, c’est parce qu’ils contiennent… des phrases. Celles-ci peuvent être des instructions ou des clauses, terminées par un point. Si l’on ajoute que la syntaxe du COBOL est très proche de l’anglais, avec des instructions comme ADD, MOVE ou PERFORM, on obtient pratiquement un texte. « Verbeux » est donc le bon mot, car tout y fonctionne par mots-clés, mais c’est ainsi que le COBOL a été conçu : pour être lisible.
Un lien fort avec le matériel
Il faut tenir compte également du contexte matériel dans lequel le COBOL a été créé, notamment les écrans. On parle bien des moniteurs à tube cathodique avec les fameuses écritures vertes, avec un affichage sur 80 colonnes. Le COBOL est calqué sur cette organisation, héritée des cartes perforées.
Initialement, les six premières colonnes étaient ainsi dévolues au numéro de séquence. La colonne 7 correspondait à l’indicateur, les colonnes 8 à 11 aux en-têtes de divisions, sections, paragraphes et définitions de données de haut niveau, puis les colonnes 12 à 72 aux instructions. Les dernières colonnes étaient dévolues à l’identification du programme. Là encore, avec le temps et l’évolution des compilateurs, les programmes ont pu adopter petit à petit une structure plus libre.
Le COBOL est également indissociable des mainframes. Ils reposent sur le modèle d’une unité centrale particulièrement puissante desservant des terminaux légers. Dans ce domaine, IBM a joué un rôle majeur, étant aujourd’hui le seul grand pourvoyeur de mainframes, via ses produits zSeries. Si vous lisez entre les lignes, cela signifie que l’on peut aujourd’hui s’équiper avec du matériel neuf pour mettre en place… une solution COBOL. Les mainframes peuvent bien sûr être utilisés dans d’autres cas.
Toujours présent ? En 2025 ?!
Le COBOL serait largement présent dans le secteur bancaire, les assurances, les grandes administrations publiques, et même dans d’autres domaines comme la santé, l’automobile, les transports et la distribution. Il serait partout, mais on n’en entendrait jamais parler. Partout à quel point ?
Selon une enquête réalisée par Reuters en 2024, pas moins de 43 % des systèmes bancaires actuels seraient construits en COBOL. Une part énorme, qui se répercute dans les opérations courantes, puisque plus de 80 % des transactions par carte bancaire seraient traitées en COBOL. Dans les distributeurs automatiques, ce chiffre s’envole même à 95 %. Aujourd’hui, plus de 90 % des entreprises du classement Fortune 500 utiliseraient du COBOL de manière plus ou moins intensive.
Selon une étude menée par Micro Focus en 2022 et citée par DataScientest, il y aurait aujourd’hui 850 milliards de lignes de code écrites en COBOL en production. Un chiffre vertigineux, qui pose bien sûr la grande question : pourquoi ? L’interrogation est légitime, car si le COBOL est un vieux dinosaure, il devrait avoir été remplacé depuis longtemps. Après tout, tout évolue très vite en informatique et le matériel comme le logiciel ont fait des bonds spectaculaires en plusieurs décennies. Serait-ce une simple question d’inertie ?
« Pourquoi ne serait-il plus là ? »
Nous avons discuté avec plusieurs développeurs COBOL, que l’on nomme traditionnellement « cobolistes ». Tous présentent étrangement le même profil : ils ne se destinaient pas à ce langage. En fait, ils n’avaient même pas prévu de s’orienter vers l’informatique en particulier. Presque tous sont issus de la grande vague de recrutement des années 90, quand la peur du bug de l’an 2000 a provoqué une explosion de la demande. Car oui, ce bug de l’an 2000 était lié au COBOL.
Parmi ces cobolistes, Gatien Dupré se considère comme « un recyclé de l’informatique ». « Je n’étais absolument pas destiné à faire de l’informatique puisque je faisais des études en biotechnologie », nous explique-t-il. Mais les années 2000 sont arrivées, et avec elles le fameux bug ainsi que le passage à l’euro. « Deux changements majeurs qui devaient impacter le corps du système IT, notamment des grands groupes du tertiaire, les banques en premier », nous raconte le développeur, qui a été élu Mainframe Influencer deux années de suite par Planet Mainframe et IBM Champion 2025, et travaille aujourd’hui comme Chief Product Technical Officer chez Virtel.
Il casse d’abord une idée reçue : oui, il y a bien eu des projets pour se débarrasser des mainframes, ce que l’on nomme « downsizing ». C’était le cas par exemple en 2015 quand il travaillait à la Société Générale. Mais dans la plupart de ces projets, le même constat revenait, selon lui : le mainframe avait le meilleur TCO (coût du cycle de vie) et le système Z d’IBM avait encore de beaux jours devant lui. La question se posait depuis longtemps de savoir, face à une architecture conçue pour être pérenne, comment moderniser la pratique, car la façon de faire avait largement changé. Une réflexion qui l’a conduit à constituer une petite équipe pour travailler sur le sujet, aboutissant à une embauche chez IBM comme Product Manager sur une partie de la gamme DevOps nouvellement créée de l’entreprise.
À la question « Pourquoi le COBOL est-il toujours là », Gatien Dupré joue la contre-interrogation : « Pourquoi ne serait-il plus là ? ». Il développe : « Se demander pourquoi le COBOL est toujours là, c’est un peu pour moi une vision passéiste, qu’on a beaucoup entendue, notamment par les personnes qui pratiquent d’autres langages, principalement le Java ».
Il compare le COBOL au grand requin blanc : une relique de la préhistoire, mais qui existe encore parce qu’il « est parfaitement adapté à son milieu ». « Si le COBOL est toujours là, c’est qu’il s’est toujours adapté au plus près des besoins business. Il est fait pour le massive output, pour le traitement de grandes masses de données de manière efficace et performante », ajoute le développeur.
« On a créé des systèmes qui ont des dizaines d’années, donc qui ont une séniorité, une pérennité, une stabilité incontestables parce qu’ils ont été tunés au fil du temps par pas mal d’ingénieurs. Et derrière, au lieu de tout refabriquer pour arriver en définitive à peu près à la même chose – si on a de la chance en dépensant beaucoup d’argent – on peut directement exposer des choses qui fonctionnent et qui sont éprouvées », explique Gatien Dupré.
Les velléités de remplacement ne sont d’ailleurs pas un phénomène nouveau : « Quand j’ai commencé ma carrière, les CTO voyaient dans le COBOL quelque chose qu’il fallait abattre, un élément contre-performant. Aujourd’hui, on a une approche beaucoup plus pragmatique, opérationnelle, qui vise à dire : utilisons la bonne technologie au bon endroit ».
Un langage vivant
Pour Gatien Dupré, il y a plusieurs raisons expliquant que COBOL soit toujours là. Ses performances d’abord, que l’on ne retrouve pas toujours selon lui dans d’autres langages, notamment le Java qu’il pratique également.
Autre avantage, la verbosité du langage et son codage de la logique métier : « On a des chaînes de traitement qui sont parfois historiques. Je parle par exemple des chaînes de traitement comptables. Tous les bilans, tous les traitements comptables des banques, par essence, sont faits au travers du langage COBOL. Quand on a un problème dans un traitement comptable, on doit pouvoir rapidement le déboguer. Et ça, c’est quelque chose qu’on est capable de faire sans l’aide d’aucun outil dans le code, parce que le langage est très verbeux ».
En outre, comme il nous l’explique et « contrairement à ce que croient beaucoup de gens, le Cobol est un langage vivant ». Le COBOL, dans sa version IBM qui est principalement utilisée dans les entreprises, en est à sa sixième version, nommée Enterprise V6 chez l’entreprise. « Aujourd’hui, on est à la version 6, qui est une version extrêmement disruptive. Vous pouvez faire par exemple de l’open banking avec COBOL. C’est-à-dire que vous pouvez exposer des API et consommer des services dans le système du COBOL, qui lui-même peut consommer aussi des services tiers venant d’ailleurs », ajoute l’ingénieur.
Les méthodes d’apprentissage et son utilisation ont largement évolué aussi. Il y a une opportunité selon lui pour incorporer des méthodes modernes, à travers notamment VS Code et le DevOps, l’automatisation des tests, la virtualisation des environnements, etc. On trouve même des assistants IA prenant en charge le COBOL, comme Watson X for Code Assistant chez IBM, Code Insight chez BMC, ou encore COBOL Colleague chez PhaseChange.
Le poids du passé
Le COBOL évolue, mais comment faire le lien entre passé et présent ? Comment préparer l’avenir ? Ces questions se posent d’autant plus que la grande vague d’embauches de la fin des années 90 débouche petit à petit sur un nombre croissant de départs à la retraite. En outre, l’apprentissage du Cobol aujourd’hui ne prépare qu’en partie à la gestion d’anciens projets qui, si leur code a évolué, constituent un empilement parfois vertigineux de couches successives.
« Si on se forme maintenant, donc en V6, comment faire pour affronter l’ancien code ? Il n’y a pas beaucoup de différences dans la sémantique, il y a simplement certaines failles, mais heureusement le compilateur met en avant les éléments qui ne sont plus compatibles. Mais rentrer dans la logique d’un programme existant, c’est toujours une gageure », confirme Gatien Dupré.
Cette cassure est soulignée également par Gaétan Roelens, développeur COBOL et chef de projet chez ArcelorMittal, et lui aussi venu au COBOL un peu par accident. Il s’est notamment fait connaitre en intervenant sur la chaine Underscore chez YouTube, sur le même sujet.
Contacté par Next, il comprend que le COBOL peut effrayer par sa verbosité ou son approche. « Bien sûr que les mainframes d’aujourd’hui n’ont rien à voir avec ceux de l’époque. Mais il ne faut pas négliger la syntaxe du COBOL. Elle date d’il y a 60 ans, elle parait absurde aujourd’hui. Et on ne peut pas le nier : on code toujours sur 80 colonnes, on n’a pas la souris. Au niveau de l’interface, c’est vieux, ça c’est clair. Le développeur, devant un écran de mainframe, il va halluciner. Ça fait vieillot, clairement. Par contre, ce qui tourne derrière, ce sont les super performances ».
La tentation du neuf
Tout effacer pour repartir sur une base neuve est une tentation constante, qui fait partie intégrante du solutionnisme technologique. Dans le cas du COBOL cependant, le langage embarque, lui, la logique métier. Plonger dans son code et reculer dans le temps revient à ouvrir un livre d’histoire sur l’évolution des pratiques du métier et leurs évolutions. Dans certains cas, cet historique est crucial. Dès lors, repartir sur une base neuve devient aussi complexe qu’onéreux, quand l’opération est possible.
« Je pense que les systèmes sont devenus trop gros, on n’arrive pas à migrer, on n’a pas de solution encore pour migrer des systèmes aussi gros. La méthode Scrum agile ne marche pas pour ce genre de projet aussi énorme. Ça va dériver dans le temps et ne jamais se terminer. Et si on veut faire des projets à l’ancienne, avec des deadlines, etc., on n’arrive pas à caser tout dans le budget », abonde ainsi Gaétan Roelens.
Il poursuit : « Ensuite, les règles de gestion qui ont été codées à l’intérieur depuis 60 ans ne sont plus maîtrisées par les utilisateurs. Si on prend l’exemple d’un projet XY, on va dire « Bon, alors maintenant, à la place de ce qui tourne, on va vous mettre ce projet. Donnez-nous toutes les règles de gestion pour les recoder dans le projet XY ». Les utilisateurs vont dire : « On ne sait plus. On ne sait pas. Oui ça fonctionne, mais on ne sait pas ce qu’il y a derrière ». Donc dans ce cas-là, il faut refaire toute une rétro-analyse. Et rien que l’analyse du COBOL pour extraire toutes les règles codées, ça va coûter aussi cher que le projet en lui-même ».
Ce qui revient, en somme, à chercher dans le code le cahier des charges. Un problème autant qu’un avantage selon le développeur, car la documentation a souvent tendance à disparaitre, là où le code est toujours là. Et, si lui aussi note l’adaptation à l’IA et l’arrivée d’outils pour le COBOL, il s’agit surtout d’écrire du nouveau code, pas d’analyser l’existant.
« Là où je travaille en ce moment, il y a 4 000 programmes, tous imbriqués entre eux. Et ce n’est pas une grosse architecture. L’IA est incapable de gérer ça pour l’instant », indique Gaétan Roelens. Une IA capable d’analyser 4 000 programmes et d’en décrire les imbrications pourrait-elle être considérée comme révolutionnaire ? « Clairement, parce qu’il faudrait que l’IA comprenne tout. Chez ArcelorMittal, par exemple, elle devrait comprendre ce qu’est une bobine, dans quel rouleau elle passe, etc. C’est la logique métier et elle est présente dans le code. C’est le code en COBOL qui va dire que telle bobine d’acier doit passer à telle date dans telle machine, dans tel rouleau, qu’elle ait telle épaisseur, etc. ».
Une approche hybride
Si le langage évolue et que l’approche se veut plus pragmatique, une approche hybride peut-elle être envisagée ? Pour Julien Eliès, autre développeur COBOL avec qui nous avons discuté, c’est une évidence.
« En France, le COBOL est encore assez utilisé, dans les banques et assurances bien sûr, mais aussi dans pas mal de PME et dans la santé. Souvent, ces sont des applicatifs qui datent des années 90. Dans l’entreprise où je suis, c’est en train d’être réécrit : l’interface applicative est refaite en Java, mais c’est bien le Cobol derrière qui fait les traitements ».
Lui aussi pose la question : « Pourquoi changer ce qui fonctionne ? C’est une question de masse historique, de nombre de milliards de lignes de code. Ce serait très long, très coûteux, alors que le COBOL marche. Et il marche même très bien. Quand vous voulez traiter des millions, voire des milliards, de transactions financières dans les banques et qu’il faut le faire entre 20 h le soir et 6 h le lendemain matin. Je n’ai pas encore vu Java le faire, alors que sur des gros systèmes, il n’y a pas de problème avec COBOL ».
Il attire d’ailleurs notre attention sur un autre critère qui a rendu le COBOL si précieux dans le domaine financier et explique qu’il soit toujours là : « Il y a aussi un problème de gestion du numérique, de typage de variables. En Java, il n’y a pas de numérique à nombre de décimales fixes. On a un entier, on a un décimal, mais le nombre de décimales n’est pas fixe. C’est Java qui va le décider en fonction de son utilisation. Alors que pour des calculs financiers notamment, on a vraiment besoin que les nombres soient définis avec 2 ou 5 décimales, et que ce soit toujours la même chose. Sinon on tombe sur des arrondis qui peuvent générer des coûts conséquents quand on parle de millions voire de milliards d’euros ».
Il casse d’ailleurs une autre idée reçue : la mise en place du virement instantané dans les banques n’était pas tant un problème de COBOL que d’architecture. « Oui le COBOL était utilisé dans des traitements asynchrones et des batchs de nuit. Ça répondait dans la dizaine de secondes ou dans la minute. Ce n’était pas idéal pour les virements instantanés, qui engendrent des traitements complexes. Mais c’est surtout un problème d’architecture, car rien n’empêche d’avoir une interface web qui appelle un programme Cobol, qui répondra en quelques dixièmes de seconde ».
Lui aussi estime qu’un programme fonctionnel en COBOL ne devrait pas être remplacé : « Si vous avez un existant COBOL qui marche, qui fait le job, et qu’on peut brancher avec une interface moderne, pourquoi réécrire ? Ça coûterait cher, ça générerait probablement beaucoup d’erreurs, beaucoup de bugs à corriger, pour peu d’avantages ». Tout en précisant, en riant : « Mais bon, nous les cobolistes, on est de vieux ronchons ».
Transmission du flambeau : c’est compliqué !
Comme beaucoup de « cobolistes », Gaétan Roelens nous expose ses craintes sur la passation des connaissances entre l’ancienne génération de sachants et la nouvelle : « C’est vrai que jusqu’à maintenant, on s’appuyait sur les gens de cette génération-là. Quand j’avais un problème vraiment trop complexe pour moi, j’allais les voir. Et aujourd’hui, ils sont partis. Je vous avoue que des fois on est bien embêtés », nous confie le développeur.
Comment faire alors ? « On bricole parfois. On ne peut plus aller aussi loin qu’avant, aussi au fond. Avant, si on avait un bug, on allait creuser jusqu’au bout, voir d’où venait le bug. Des fois, on devait aller dans la partie assembleur du COBOL, du z/OS, etc. Mais aujourd’hui, presque plus personne ne sait le faire. Donc, si on a un bug et qu’on n’arrive pas à trouver, on contourne le problème. On va faire autre chose, mais on ne résout pas vraiment le problème. C’est sûr que ça dégrade les performances ».
« On arrive toujours à se débrouiller, mais ce n’est pas une situation idéale. Si on pouvait avoir encore des experts aujourd’hui, des jeunes qui montent en compétences, ce serait top, mais ce n’est pas ce que je remarque. Je remarque plus une rareté des experts en COBOL. Ce sont souvent les SSII qui forment. Après, on peut toujours faire appel aux Golden Tickets d’IBM. Eux, ils ont quand même des experts. Mais bon, c’est cher », poursuit Gaétan Roelens.
Le chef de projet nous indique avoir accepté l’invitation d’Underscore pour cette raison : attirer l’attention, faire la promotion de COBOL, casser l’idée reçue d’un langage figé et encourager les plus jeunes générations à se lancer. Comme Gatien Dupré, il s’inquiète de ce que les jeunes développeurs n’ont souvent jamais entendu parler du langage. Et, quand ils le connaissent, ils en ont souvent une vision mâtinée d’une couche de dédain chronologique : « c’est vieux, donc c’est nul ».
Même volonté chez Gatien Dupré : « Le conseil que je donne aux jeunes développeurs, c’est : intéressez-vous au COBOL et à l’informatique de gestion parce que c’est une mine d’or. Avec la vague des papy-boomers, le renouveau générationnel est une préoccupation que pas mal de gens ont. Pour nous, en COBOL, effectivement, il y a ce fossé générationnel : quand les derniers développeurs seniors partiront à la retraite, on aura peu de mid-seniors qui permettront d’accompagner ». On retrouve ainsi le problème de transmission des savoirs, en plus du simple apprentissage du langage.
Julien Eliès confirme lui aussi : « Parmi les cobolistes, je suis considéré comme jeune alors que je viens d’avoir 50 ans, donc c’est sûr qu’on va en manquer. Dans l’absolu, ce n’est pas compliqué de former un coboliste. Du moment qu’on a touché à un langage de programmation, qu’on sait ce que c’est un algorithme, en moins d’un mois, on a compris ce que c’était COBOL. Ce qui est compliqué c’est de maintenir des applicatifs qui ont 40 ans, sur lesquels des centaines de personnes sont intervenues, et dont on a souvent perdu la documentation ».
De fait, pour les trois cobolistes, il n’y a aucune raison technique de remplacer les programmes COBOL existants s’ils donnent satisfaction. En revanche, le problème de la transmission des savoirs et de l’appropriation des projets existants est un vaste problème posant la question de la maintenabilité du code. Même si pour les développeurs interrogés, la thématique n’est pas nouvelle : quand les entreprises ont des besoins, une solution finit en principe par émerger.
À compter du 1ᵉʳ janvier 2026, la grande majorité des personnes abonnées à l’offre GeForce Now de NVIDIA auront une limite de 100 heures par mois, soit une moyenne d’un peu plus de 3 heures par jour.
Cette limite n’est en fait pas nouvelle. Annoncée en 2024, elle est appliquée depuis un an à l’ensemble des nouveaux abonnés. Ce qui change, c’est bien l’application de cette limite à la quasi-totalité des autres abonnés. « Quasi », car toutes les personnes ayant une ancienne formule d’avant mars 2021 (membres Fondateurs) et ayant payé leur abonnement sans interruption gardent le même niveau de prestation, sans limite. NVIDIA promet dans sa FAQ que cet avantage sera préservé « à vie », à condition que les personnes concernées continuent de payer.
Ce plafond peut être dépassé. À la manière des forfaits téléphoniques, on peut ainsi acheter des packs d’heures supplémentaires, mais la tarification dépend de la formule d’abonnement. Si vous avez une offre Performance à 10,99 euros par mois, le pack de 15 heures est facturé 3 euros. Avec la formule Ultimate à 21,99 euros par mois, le même pack est vendu 6 euros.
Ces packs sont optionnels. Par défaut, quand la réserve de temps est épuisée, le compte utilisateur bascule sur la formule gratuite jusqu’à la date de renouvellement mensuel suivante, y compris pour les formules de plusieurs mois. À l’inverse, si le quota n’est pas utilisé, sur les 100 heures de base ou sur l’extension de temps achetée, un report peut s’opérer sur le mois suivant, dans une limite de 15 heures.
Le problème, bien sûr, est le prix des extensions. Que l’on joue une ou dix heures de plus, le prix est le même. Des abonnés mécontents se sont « amusés » à calculer l’écart de tarifs en fonction du nombre d’heures jouées par mois, dans un tableau intitulé : « Combien d’heures puis-je jouer chaque mois avant que GeForce Now ne soit plus une option viable ? ». On voit rapidement qu’au-delà de 100 heures par mois, le prix augmente rapidement. Sur un an par exemple, un très gros joueur à 200 heures par mois sur une formule Ultimate paierait près de 800 dollars par an.
La question sera donc de savoir si les 100 heures sont suffisantes aux personnes actuellement abonnées. Si plus de trois heures par jour peuvent sembler largement suffisantes, elles sont susceptibles de rapidement disparaitre via les week-ends et les périodes de repos, dans le cadre d’un service spécifiquement conçu pour le jeu. C’est d’ailleurs le type de réflexion abordé sur Reddit : il pourrait être plus intéressant d’acheter directement le matériel, même si le niveau de prestation de l’offre Ultimate est élevé.
Le changement était prévu, mais il tombe à point nommé pour NVIDIA, prise dans les filets d’une situation matérielle générale nettement plus tendue qu’il y a un an.
Good Old Games (GOG) a été fondée en 2008 par le studio polonais CD Projekt, à qui l’on doit plusieurs jeux vidéo particulièrement célèbres comme la série The Witcher ou encore Cyberpunk 2077.
La boutique s’est largement fait un nom autour d’une idée simple : ramener d’anciens titres à la vie, faire en sorte qu’ils fonctionnent sur des systèmes récents, corriger les bugs et les maintenir à jour. L’autre grand axe de développement est l’absence de DRM (gestion des droits numériques) sur une grande partie du catalogue, pour éviter notamment les incompatibilités. Elle s’est ouverte depuis à de plus grosses licences et propose un launcher, Galaxy.
GOG était jusqu’à présent une filiale de CD Projekt. Depuis cette nuit, Michał Kiciński est le nouveau propriétaire de la boutique. Cette passation reste « en famille » : Michał Kiciński est cofondateur de CD Projekt et l’un de ses principaux actionnaires.
« Avec notre attention désormais entièrement portée sur une feuille de route de développement ambitieuse et l’expansion de nos franchises avec de nouveaux produits de haute qualité, nous avons estimé que c’était le bon moment pour cette décision. Depuis longtemps maintenant, GOG opère de manière indépendante. Aujourd’hui, il passe entre de très bonnes mains – nous sommes convaincus qu’avec le soutien de Michał Kiciński, l’un des cofondateurs de GOG, son avenir sera riche de grands projets et de succès », a déclaré Michał Nowakowski, co-CEO de CD Projekt.
Maciej Gołębiewski, directeur général de GOG, affirme que la mission de GOG ne changera pas : « Dans un marché de plus en plus saturé, de plus en plus verrouillé, et qui oublie les jeux classiques à un rythme croissant, nous redoublons d’efforts sur ce que seul GOG fait : ressusciter les classiques, les garder jouables sur les PC modernes, et aider les grands jeux à trouver leur public au fil du temps ».
Ce rachat de la totalité des actions a une valeur de 90,7 millions de zlotys, soit environ 21,45 millions d’euros. Le communiqué affirme également que les prochaines sorties de CD Projekt continueront d’arriver sur GOG.
Vous avez peut-être vu passer ces quelques derniers jours des actualités pointant vers la fin du support d’anciens GPU NVIDIA par Arch Linux. Ce n’est pas tout à fait ça, même si le résultat y ressemble.
À l’origine, on trouve la publication des pilotes 590 de NVIDIA. C’est bien cette version, sortie début décembre, qui met fin au support officiel des GPU des générations Maxwell et Pascal, c’est-à-dire les GeForce GTX des séries 900 et 1000.
Cette fin de support, annoncée il y a plusieurs années, signifie que NVIDIA n’ajoute plus d’optimisations spécifiques ni de prises en charge de jeux en particulier. Les GPU continuent de fonctionner avec la version précédente des pilotes (de la branche 580). En outre – et c’est une information importante – le support complet n’est pas coupé : les mises à jour de sécurité continueront d’arriver jusqu’en octobre 2028.
Simple comme une mise à jour
Pourquoi un problème particulier avec Arch Linux dans ce cas ? À cause du fonctionnement en « rolling release », à savoir la diffusion quasi immédiate des dernières nouveautés logicielles. Le pilote 590 de NVIDIA y a été diffusé, avec utilisation par défaut. Ce n’est pas sans conséquence sur des systèmes appliquant toutes les mises à jour quand un pilote supprime un support.
Pour Arch Linux, la situation a été expliquée le 20 décembre par Peter Jung, l’un des mainteneurs du système (et créateur de cachyOS, distribution spécialisée dans le jeu vidéo). Il y indique que la nouvelle série 590 supprime le support des générations Pascal et antérieures, et que des remplacements de paquets sont donc appliqués : nvidia par nvidia-open, nvidia-dkms par nvidia-open-dkms, et nvidia-lts par nvidia-lts-open.
Il avertissait également que la mise à jour des paquets NVIDIA sur des systèmes intégrant ces anciens GPU entraînerait l’échec de chargement du pilote et donc celui de l’environnement graphique. La seule solution est de désinstaller les paquets nvidia, nvidia-lts et nvidia-dkms, puis d’installer le paquet nvidia-580xx-dkms depuis le dépôt AUR.
Les GeForce 16XX hors de danger
Il ajoute que rien ne change pour les GPU datant d’au moins la génération Turing, qui comprend la série 2000 des GeForce, mais également la série 1600. Cette dernière est en effet basée sur Turing, mais débarrassée des capacités de ray tracing. Les GeForce 1660 Ti, notamment, ne sont ainsi pas concernées par l’abandon de support dans le pilote 590.
Reste que la décision d’Arch Linux de procéder ainsi a provoqué de nombreuses réactions, comme on peut le voir dans les commentaires de sites tels que Phoronix et TechPowerUp. Plusieurs personnes manifestent de l’incompréhension face à une méthode jugée un peu trop radicale, indiquant qu’une détection automatique aurait pu être mise en place.
Enfin, précisons que cet arrêt de support n’est pas spécifique à la sphère Linux : Windows est lui aussi concerné. Le problème est cependant différent, car l’application NVIDIA n’installera pas d’elle-même la mise à jour, et Windows Update ne devrait pas non plus la proposer. Si l’on veut télécharger le pilote depuis le site officiel, l’outil intégré permet d’envoyer vers la bonne version. Si vous avez par exemple une GeForce GTX 1060, la version proposée au téléchargement est la 581.80.
L’annonce semble tardive, mais OpenAI cherche activement à recruter une personne dont le rôle sera de s’inquiéter de tous les dangers liés à l’IA. Ce nouveau « chef de la préparation » (head of preparedness) aura pour mission de diriger les efforts de l’entreprise dans l’encadrement de ses modèles.
« Le responsable de la préparation développera, renforcera et guidera ce programme afin que nos normes de sécurité s’adaptent aux capacités des systèmes que nous développons », indique OpenAI dans son annonce. « Vous serez le responsable direct de la construction et de la coordination des évaluations des capacités, des modèles de menace et des mesures d’atténuation qui forment un pipeline de sécurité cohérent, rigoureux et opérationnellement évolutif ».
L’annonce ajoute que ce poste nécessite « un jugement technique approfondi, une communication claire et la capacité de guider des travaux complexes à travers de multiples domaines de risque ». Il implique une collaboration « avec la recherche, l’ingénierie, les équipes produit, les équipes de suivi et d’application des politiques, la gouvernance et des partenaires externes ».
Sam Altman, CEO de l’entreprise, y est allé de sa propre annonce sur X. Il y évoque un poste « crucial à un moment charnière ». Selon lui, les modèles évoluent très vite et sont capables désormais « de prouesses remarquables », mais « commencent » à poser de sérieux défis. Il cite deux exemples « entrevus » en 2025 : l’impact sur la santé mentale et une puissance telle que les LLM révèlent des vulnérabilités critiques.
Altman affirme qu’OpenAI dispose déjà d’outils solides pour mesurer ces « capacités croissantes ». Mais une personne qualifiée permettrait d’aller plus loin, notamment en aidant « le monde à trouver comment doter les défenseurs de la cybersécurité de capacités de pointe tout en veillant à ce que les attaquants ne puissent pas les utiliser à des fins malveillantes ».
Plusieurs personnalités reconnues du monde de l’IA se sont déjà succédé à ce poste chez OpenAI. La casquette a d’abord été portée par Aleksander Mądry, qui a discrètement été affecté à d’autres missions en juillet 2024. Elle est ensuite revenue à un duo composé de Joaquin Quinonero Candela et Lilian Weng, qui ont préféré jeter l’éponge au printemps dernier.
« Ce sera un travail stressant et vous serez plongé directement dans le grand bain », avertit le CEO. L’annonce évoque un salaire annuel de l’ordre de 555 000 dollars, assorti d’une participation.
Une nouvelle fonction a été découverte dans le « about:config » du navigateur, qui permet pour rappel d’activer certaines capacités non finalisées. Firefox va ainsi se doter d’une vue scindée, souvent appelée Split View, comme relevé par OMGUbuntu.
Ce type de fonction, que l’on trouve volontiers dans des navigateurs « avancés » comme Vivaldi, permet d’afficher deux sites côte à côte. La vue scindée est devenue plus courante avec le temps, Microsoft l’ayant ajoutée dans Edge en 2024 et Google dans Chrome le mois dernier.
L’utilisation dans Firefox est simple. Il faut d’abord se rendre dans « about :config » et lancer une recherche sur « split ». Il suffit ensuite de double-cliquer sur la ligne « browser.tabs.splitView.enabled », afin que la valeur « False » passe en « True ». Pas besoin de télécharger une préversion de Firefox, l’option est disponible dans l’actuelle révision stable 146.
Une fois le paramètre activé, il suffit de faire un clic droit sur n’importe quel onglet et de sélectionner « Ajouter une vue scindée ». L’onglet se divise alors en deux sous-onglets plus petits, chacun ayant sa propre adresse. Par défaut, chaque site récupère la moitié de la fenêtre, mais on peut déplacer la barre de séparation. Ce type de fonction est très utile pour comparer deux pages ou pour lire un contenu tout en surveillant un flux de réseau social.
Si la fonction est disponible actuellement, elle ne préfigure pas d’une arrivée officielle dans Firefox 147. Celle-ci s’annonce déjà comme une mouture importante, au moins sous le capot. D’après les notes de version actuelles du canal Beta, Firefox 147 apportera ainsi le support de WebGPU aux Mac équipés puces Apple Silicon, une amélioration des performances pour les vidéos avec les GPU AMD, le support de la spécification XDG Base Directory de Freedesktop.org pour les distributions Linux, ou encore la prise en charge de Safe Browsing V5.
Galen Hunt, l’un des principaux ingénieurs de Microsoft, a publié une offre d’emploi détonante : l’entreprise recherche un ingénieur pour aider à la transition intégrale du code C/C++ vers Rust, qui doit être achevée en à peine cinq ans. Il a cependant rétropédalé, évoquant des « lectures spéculatives ».
Mise à jour du 24 décembre : Dans une mise à jour, Galen Hunt indique : « Il semble que mon post ait suscité bien plus d’attention que je ne l’avais prévu… Avec beaucoup de lectures spéculatives entre les lignes. Juste pour clarifier… Windows n’est *PAS* en train d’être réécrit dans Rust avec l’IA ». Et d’ajouter qu’il s’agit d’un projet de recherche : le développement de « technologies pour rendre possible la migration d’un langage à un autre ».
Difficile pourtant de parler de « lectures spéculatives », car le texte initial (toujours disponible) était clair, notamment : « Mon objectif est d’éliminer toutes les lignes de C et C++ de Microsoft d’ici 2030 ». Des termes clairs, d’autant plus quand ils sont prononcés par l’un des principaux ingénieurs dans l’entreprise.
Dans un commentaire, Wolfgang Grieskamp, un autre ingénieur de Microsoft, indique que la traduction automatique vers Rust ne donne de toute façon pas de bons résultats. Le code obtenu est « unsafe, au sens de Rust », car il est nécessaire de penser le projet avec le langage dès le départ, modifiant largement la manière dont les données sont gérées.
Article original du 23 décembre :
Microsoft n’a jamais caché son intérêt pour le Rust. Il a été question un temps d’attendre que l’outillage s’adapte et soit plus mature, mais la version 24H2 de Windows 11 a été la première à introduire du code Rust dans son noyau. Signe clair que la situation avait largement évolué. En février 2025, Paul Thurrott rapportait que la consigne avait été donnée en interne de ne commencer aucun nouveau projet en C ou C++, seulement en Rust.
Le langage, créé initialement par Mozilla, est depuis longtemps géré par une fondation indépendante. Microsoft en était d’ailleurs l’un des principaux membres fondateurs. Le Rust est observé de près par de nombreuses entreprises, particulièrement pour tout ce qui touche à la programmation système. On en trouve d’ailleurs dans le noyau Linux, bien que cette intégration ne se soit pas faite sans heurts. Comme nous l’expliquait récemment Sylvestre Ledru de Mozilla, Firefox en intègre également plusieurs millions de lignes de code, tout comme Chrome.
Mais Microsoft vient de donner un sérieux coup d’accélérateur : la firme veut remplacer tout son code C/C++ d’ici 2030.
Un projet titanesque
L’annonce n’a pas fait l’objet d’un billet ou d’un communiqué de presse. Elle est présente dans une offre d’emploi publiée par Galen Hunt, l’un des plus anciens ingénieurs logiciels de l’entreprise. L’offre est pour un ingénieur logiciel principal, en présentiel à Redmond.
Elle est cependant vite évacuée au profit d’une déclaration fracassante : « Mon objectif est d’éliminer toutes les lignes de C et C++ de Microsoft d’ici 2030 ». Galen Hunt indique que la stratégie consiste à mêler IA et algorithmes, et que « l’étoile polaire » est d’atteindre « 1 ingénieur, 1 mois, 1 million de lignes de code ». La tâche est décrite comme « inimaginable jusqu’ici ».
L’infrastructure algorithmique de l’entreprise est utilisée actuellement pour créer « un graphe évolutif sur le code source à grande échelle ». Après quoi, des agents IA, « guidés par des algorithmes », effectuent les modifications, également à grande échelle. Galen Hunt assure que le « cœur de cette infrastructure fonctionne déjà à grande échelle sur des problèmes tels que la compréhension du code ».
Une expérience en programmation système de qualité production est exigée. Galen Hunt enchaine sur d’autres paramètres de l’offre et un descriptif de l’équipe travaillant sur ce projet.
Le Rust, toujours le Rust
Plusieurs personnes sont venues témoigner de leur étonnement dans les commentaires. Sur le choix du Rust par exemple : pourquoi ne pas avoir choisi C#, qui présente lui aussi certaines caractéristiques intéressantes pour la sécurité ?
Galen Hunt a répondu : C# est « memory safe », mais pas « concurrent safe ». Comprendre que si C# permet d’éliminer certaines classes de failles de sécurité, notamment via un typage fort, Rust va plus loin. Il est jugé plus adapté à la programmation concurrente, quand plusieurs threads, processus ou tâches évoluent en parallèle, avec ou sans zone mémoire commune. Autre raison, attendue : les performances. Rust fonctionne sans ramasse-miettes (garbage collector) et permet d’atteindre les performances du C++.
L’ingénieur évalue à un milliard le nombre de lignes de code concernées chez Microsoft. Pourquoi un projet aussi démesuré ? Pourquoi ne pas garder le code C/C++ ? « Pas de sécurité mémoire. Pas de sécurité sur la concurrence. Bien sûr, pour une seule base de code C ou C++, ces qualités peuvent être atteintes par une discipline et un effort extraordinaires – et disparaître en une seule erreur. Avec Rust, cela peut être prouvé par le compilateur », répond Galen Hunt.
L’annonce a été accueillie avec une certaine incrédulité… y compris dans les rangs mêmes de Microsoft. Rupo Zhang, l’un des responsables de l’ingénierie logicielle de l’entreprise, demande en commentaire sur LinkedIn : « Vous êtes sérieux ? ». La question est restée sans réponse.
Relecture critique
Le projet est en effet pharaonique. « Notre mission est de développer des capacités permettant à Microsoft et à nos clients d’éliminer la dette technique à grande échelle », indiquait Galen Hunt dans l’annonce. Ce qui implique non seulement la conversion de centaines de millions de lignes de code, mais également les nombreux tests devant être réalisés pour en vérifier la fiabilité et les performances.
L’annonce laisse d’ailleurs entendre que le projet est double : convertir tout le code en Rust et finaliser l’infrastructure capable d’accomplir cette opération. Cette dernière impliquerait notamment que l’intégralité du code de Windows serait convertie en Rust, tout en maintenant la rétrocompatibilité, qui est l’une des marques de fabrique de la plateforme. Début septembre, on apprenait notamment que Microsoft voulait encourager le développement de pilotes en Rust, mais que seules les premières briques de l’infrastructure étaient proposées.
Quoi qu’il en soit, Microsoft répète continuellement depuis plus de dix ans que 70 % des failles de sécurité corrigées sont liées à une mauvaise gestion de la mémoire. Le Rust, bien qu’il élimine pratiquement tous les types de failles dans ce contexte, n’est pas non plus une protection absolue contre toutes les menaces. Il faut encore que le code ait été bien écrit. Comme nous le disait récemment l’ingénieur Horacio Gonzalez (Clever Cloud), la relecture critique a toutes les chances de devenir une compétence très recherchée.
Connexion
