Plutôt qu’un juge humain, une vérification déterministe : le RLVR (Reinforcement Learning with Verifiable Rewards) repose sur ce principe.
DeepSeek-R1 et OpenAI o1, entre autres, en ont démontré les bénéfices. Mais les possibilités de mise à l’échelle sont limitées du fait de la dépendance à des problèmes conçus par l’humain et à des récompenses spécifiques à chaque domaine.
Chez Meta, on est en tout cas parti de ce postulat pour développer SPICE (Self-Play in Corpus Environment).
Un modèle, deux rôles, un corpus documentaire
Cette technique d’apprentissage par renforcement fait jouer au modèle deux rôles antagonistes. L’un consiste à générer les problèmes (« challenger »). L’autre, à les résoudre (« résolveur »).
La génération des problèmes a la particularité d’être ancrée sur un corpus documentaire. Le challenger n’utilise que cette source ; pas ses propres connaissances. Le résolveur n’a pas accès au corpus, ce qui assure une asymétrie de l’information.
Un mécanisme de récompense fait progresser le challenger et le résolveur. Le premier a pour mission de créer des problèmes qui challengent au maximum le second, tout en restant résolvables.
Les documents sont bruts, sans questions ou étiquettes prédéfinies. Les problèmes prennent la forme de QCM (avec 4 réponses) ou de questions ouvertes. Cette diversité est censée permettre une vérification interdomaines sans outils spécialisés.
Les deux rôles sont instanciés avec vLLM, sur la base de l’architecture Oat. Quatre modèles de base sont expérimentés : Qwen3-4B-Base, Qwen3-8B-Base, OctoThinker-3B-Hybrid-Base et OctoThinker-8B-Hybrid-Base. Le renforcement se fait sur 20 000 documents. Il est axé sur deux disciplines : mathématiques (utilisation du datasetNemotron-CC-Math) et raisonnement général (NaturalReasoning). La température est laissée à 1.0.
Ni trop simple, ni trop compliqué : un système de récompense pour trouver le bon équilibre
Avec chaque document, on effectue 1024 tentatives pour générer des questions, puis on en sélectionne aléatoirement une valide. Pour chacune, on retient 8 réponses. On en calcule la variance pour déterminer la récompense du challenger. Cette dernière est maximale lorsque le taux de réussite du résolveur atteint 50 % (témoignant de questions ni trop faciles, ni trop difficiles). Pour vérifier l'équivalence de chaque réponse par rapport à la gold answer (réponse de référence), le frameworksimple-evals est utilisé, avec GPT-4o.
La performance de SPICE est comparée à celles :
Des modèles de base (Base Model)
De systèmes utilisant un challenger "plus fort" (Qwen3-32B-Instruct) et où le modèle n'est entraîné que sur le rôle de résolveur (Strong Challenger)
D'un système antagoniste non ancré sur un corpus (R-Zero)
De ce même type de système, et avec des problèmes portant exclusivement sur la génération de code Python (Absolute Zero)
Entre les modèles de base et SPICE, l'écart va de 5,7 à 11,9 points selon les modèles.
3,2 points en performance globale : la (modeste) contribution du corpus documentaire
On constate une amélioration mutuelle. Pour en témoigner, Meta avance deux indicateurs "en miroir".
D'un côté, à résolveur fixe (checkpoint après 200 étapes), le taux de réussite passe de 55 à 35 % à mesure que le challenger progresse.
De l'autre, à challenger fixe (checkpoint après 200 étapes), le taux de réussite du résolveur passe de 55 à 85 %.
Qualitativement parlant, plus on avance dans l'entraînement, plus les problèmes générés sont complexes.
Sans ancrage sur corpus, la performance globale moyenne atteint 40,7 %. Avec, elle monte à 43,9 % (+ 3,2 points).
NaturalReasoning utilisé seul engendre des gains plus importants que Nemotron-CC-Math seul. Mais combiner les deux datasets produit les meilleurs résultats.
Le gain en mathématiques est plus important avec uniquement des questions ouvertes. Au global, néanmoins, il vaut mieux y associer le format QCM.
La technique de récompense par calcul de variance produit de meilleurs résultats que :
Absolute Zero, où la récompense vaut (1 - taux de réussite moyen du résolveur)
Threshold, où la récompense vaut 1 pour les tâches "relativement résolvable" ; 0 pour celles à 0 ou 100 % de réussite
R-Zero, qui récompense les problèmes produisant des réponses équitablement réparties
Si la GenAI contribue à « raviver » les solutions de gestion des actifs numériques (DAM), elle s’y diffuse de manière très inégale.
Le constat était ressorti, il y a près d’un an, du Magic Quadrant consacré à ce marché.
L’analyse de Gartner dépeignait la situation à octobre 2024.
Au sujet de cette diffusion très inégale de la GenAI, le cabinet américain évoquait les fournisseurs qui n’en proposaient pas encore pour la création de contenu ; ceux qui étaient « en retard » sur ces mêmes capacités ; ceux qui avaient plus globalement « du mal à suivre le rythme » ; et ceux chez qui la GenAI avait un prix non négligeable.
Cette remarque ne figure plus dans la nouvelle édition du Magic Quadrant du DAM. Gartner met, au contraire, l’accent sur la généralisation de certaines briques. Par exemple, la création de contenu assistée par IA. La majorité des fournisseurs classés (13 sur 17) en proposent nativement. Soit grâce à des modèles propriétaires, soit en embarquant des LLM ouverts.
La manipulation de contenu assistée par IA est également devenue standard. En parallèle, les fonctionnalités touchant à la vidéo (création, édition, localisation linguistique) se répandent. On voit aussi émerger une adaptation automatisée des contenus aux canaux de diffusion. Et la possibilité, pour le client, d’apporter ses propres modèles.
L’intégration de MCP, vu comme un levier de standardisation et d’encadrement de la production de contenu, est en revanche encore limitée. Au moment où Gartner a effectué ses relevés, un tiers des offreurs avaient commencé à implémenter le protocole, ou tout moins déclaraient envisager de le faire.
Adobe et Orange Logic, nouveaux « leaders »
Sur le plan fonctionnel, le cahier des charges pour figurer dans le dernier Magic Quadrant du DAM imposait, dans les grandes lignes :
L’ingestion des actifs, leur organisation (tagging et taxonomie) et leur mise à disposition
Gestion des droits numériques
Planification de workflows
Intégration avec des solutions marketing – ce métier étant le premier public
La capacité à répondre effectivement à la demande du marché (expérience client, marketing, qualité des produits/services…) est restituée sur l’axe dit « exécution ». Les fournisseurs s’y positionnent comme suit :
Rang
Fournisseur
Évolution annuelle
1
Aprimo
=
2
Bynder
=
3
Storyteq
=
4
Adobe
+ 4
5
OpenText
+ 4
6
Frontlify
nouvel entrant
7
Smarsheet
– 2
8
Orange Logic
– 4
9
Hyland
– 3
10
Acquia
– 3
11
Cloudinary
=
12
Sitecore
– 2
13
CELUM
– 1
14
PhotoShelter
nouvel entrant
15
MediaValet
– 1
16
Wedia
nouvel entrant
17
Fotoware
– 4
Sur l'axe "vision", qui reflète les stratégies (commercial, marketing, produit, sectorielle, géographique...), la situation est la suivante :
Rang
Fournisseur
Évolution annuelle
1
Storyteq
+ 1
2
Aprimo
- 1
3
Cloudinary
=
4
Orange Logic
+ 4
5
Bynder
- 1
6
Sitecore
- 1
7
Adobe
=
8
OpenText
- 2
9
Acquia
- 1
10
Frontlify
nouvel entrant
11
PhotoShelter
nouvel entrant
12
CELUM
=
13
Wedia
nouvel entrant
14
MediaValet
- 1
15
Hyland
- 6
16
Smartsheet
- 5
17
Fotoware
- 3
Il y a un an, ils étaient trois dans le carré des "leaders" : Aprimo, Bynder et Storyteq. Adobe et Orange Logic les y ont rejoints.
Quels produits pour quels usages ? L'offre d'Adobe suscite des incertitudes
Gartner salue les possibilités d'Adobe Experience Manager Assets sur l'aspect workflows de création (soumission, approbation, intégration de l'IA Firefly). Il apprécie également les fonctionnalités de gouvernance et de contrôle d'accès, basées sur les rôles et les attributs. Et souligne qu'Adobe est l'un des porteurs de la Content Authenticity Initiative. Bon point également pour le réseau de partenaires (ils sont 4200 certifiés).
Le jugement est moins positif quant aux capacités agentiques. Gartner l'illustre par l'absence d'un agent capable de contrôler les actifs à l'ingestion. Il appelle aussi à la vigilance sur la tarification. D'une part, parce que l'accès à des fonctionnalités avancées (rendu temps réel, expériences 3D...) nécessite un add-on. De l'autre, à cause du nombre limité de licences utilisateur incluses de base dans les différents niveaux d'offre. Le cabinet américain note également de potentielles incertitudes sur les produits auxquels recourir en fonction des cas d'usage. Un "manque de clarté" qui peut compliquant l'adoption et la mise en action.
Aprimo et la GenAI : vigilance sur le modèle à la consommation
Il y a un an, Aprimo avait été crédité d'un bon point pour la continuité offerte dans la gestion du contenu entre les outils marketing et les autres logiciels d'entreprise. Gartner avait aussi apprécié ses "starter packs" sectoriels avec workflows et taxonomies préconfigurés. Il avait également salué les capacités de son produit en matière de recherche, de tagging et de templating.
Le focus GenAI avait valu à Aprimo un mauvais point, en ce qu'il était susceptible de limiter les investissements dans le cœur fonctionnel. La tarification de la GenAI était autre point noir : l'add-on donnant accès aux fonctionnalités les plus avancées (entraînement personnalisé pour le tagging, génération d'images, traduction...) pouvait faire augmenter le TCO d'un tiers. Gartner avait aussi regretté le nombre limité d'événements physiques à destination des clients.
Cette fois, l'IA vaut un bon point à Aprimo, entre recherche sémantique, métadonnées prédictives et révision automatisée du contenu. Gartner y ajoute le niveau de performance et de fiabilité de la plate-forme. Ainsi que les fonctionnalités de conformité (certifications sectorielles, pistes d'audit immuables, vérifications assistées par IA).
Le module complémentaire pour la GenAI avancée reste un problème, mais sous un autre angle : son modèle à la consommation, qui rend potentiellement les coûts moins prévisibles. Pour ce qui est de la stratégie AI-first, elle est susceptible de "challenger" les organisations peu matures, tant par la cadence de diffusion de l'IA que par le périmètre concerné. Les clients ayant des besoins hors Amérique du Nord et EMEA resteront par ailleurs vigilants quant à la présence physique limitée d'Aprimo et de ses ressources de support sur les autres plaques géographiques.
Chez Bynder, une double tarification à bien étudier
Il y a un an, l'offre de Bynder avait fait mouche auprès de Gartner sur le plan fonctionnel. Notamment sur la détection de visages et le système de mise en quarantaine des contenus avant approbation. Les capacités d'analyse de l'usage des actifs avaient aussi été saluées. Comme la relation client (événements réguliers, roadmap accessible à tous, webinars lors de la sortie de mises à jour).
Les investissements en IA ont produit moins de fonctionnalités que chez la concurrence, avait regretté Gartner. Il y avait ajouté un manque de transparence sur le packaging des fonctionnalités constituant des add-on. Tout en signalant l'absence de roadmaps sectorielles et d'améliorations ciblées sur des verticales (Bynder a opté pour une approche horizontale avec adaptation aux cas d'usage).
Cette fois, l'un des bons points va aux capacités de création et de mise en œuvre d'agents IA. Qui, combinés à l'API, favorisent la création de contenus par d'autres métiers que le marketing. Bynder se distingue aussi sur la distribution des contenus, autant par leur adaptation à chaque canal que par l'exhaustivité du catalogue de connecteurs. Il a aussi pour la la qualité de son support à l'implémentation (blueprints, formations par rôle, conseils de gouvernance, taxonomies sur étagère, templates personnalisables...).
À un an d'intervalle, Gartner note toujours que la feuille de route sectorielle est limitée. Il trouve aussi à redire sur la partie analytics, du fait que les dashboards doivent être configurés via un mix d'API et d'intégrations pour obtenir des recommandations réellement "activables". Quant à la tarification, basée soit sur le nombre d'assets soit sur le volume de stockage, elle implique de bien évaluer la structure de sa bibliothèque de contenus.
Orange Logic : gare aux délais d'implémentation
Comme Bynder, Orange Logic se distingue sur l'automatisation agentique. Il en est de même sur la recherche conversationnelle - avec exploitation du contexte : profils d'utilisateurs, relations entre assets, analyse des frames dans les vidéos, etc. Gartner salue aussi son concepteur visuel de workflows, jugé convivial (user-friendly).
Comme chez Aprimo, la présence physique est limitée hors Amérique du Nord. Le processus d'implémentation s'avère par ailleurs plus long que chez la concurrence. Et les modules optionnels (3D, gestion des droits, concepteur de sites sans code...), souvent indispensables dans les grandes entreprises, peuvent faire monter la facture.
Avec Storyteq, le modèle à la connexion peut coûter cher
Il y a un an, Gartner avait présenté Storyteq comme le fournisseur proposant le plus de capacités d'assistance par IA pour la création et l'édition de contenus. Il y avait ajouté les fonctionnalités de vision par ordinateur pour améliorer la recherche d'assets et la disponibilité d'un CMS en self-service. Tout en soulignant l'étendue des partenariats conseil et ISV.
Le prix de la GenAI était un point noir, même si la tarification d'ensemble demeurait flexible. Gartner avait aussi fait remarquer les travaux préparatoires que certaines fonctionnalités GenAI supposaient pour pouvoir fonctionner à l'échelle. Et affirmé que la présence physique de Storyteq restait largement concentrée en EMEA, en plus d'un focus historique sur les services d'agence et d'une absence de programme de reconnaissance client.
Cette fois, la stratégie sectorielle fait mouche: Storyteq a des équipes dédiées à la santé, l'automobile, la finance et le retail, entre autres. Il y couple des packs associant workflows, schémas et exemples de conformité. Son offre se distingue aussi sur les services professionnels et le support technique. Ainsi que sur la conception d'agents sans code et l'exploitation de l'IA pour la protection des contenus (gestion dynamique du consentement, détection de données personnelles, audit de conformité continu).
Beaucoup d'intégrations avec des systèmes externes sont facturées à la connexion. Pour qui souhaite organiser un écosystème, les coûts peuvent vite enfler. Pour ce qui est de la présence physique, elle reste largement concentrée en Amérique du Nord et en EMEA, malgré l'acquisition de PureRed. Quant aux investissements marketing, ils sont moins importants que chez la concurrence, résultant en une visibilité limitée.
Au-delà d’Hyper-V et d’ESXi, Akira a aussi chiffré des VM Nutanix.
Le bulletin que la CISA consacre à ce ransomware vient d’être mis à jour pour intégrer cette information… entre autres.
La version initiale datait d’avril 2024. Un an et demi plus tard, les techniques ont évolué sur toute la ligne, de l’accès initial à l’extorsion. Quant au chiffrement de VM Nutanix*, il a été constaté dans le cadre d’un incident survenu en juin 2025. Au début de la chaîne d’attaque, il semble y avoir eu la faille CVE-2024-40766 (contrôle d’accès défaillant dans les pare-feu SonicWall).
Des accès initiaux via Veeam
La version d’avril 2024 évoquait un accès initial via des VPN sans MFA. Essentiellement de marque Cisco, était-il précisé, avec deux vulnérabilités citées. L’une et l’autre localisées dans l’interface web d’ASA (Adaptitve Security Appliance) et de FTD (Firepower Threat Defense). La première (CVE-2020-3259) permet de récupérer du contenu en mémoire sans authentification. La deuxième (CVE-2023-20269) ouvre la voie à des attaques de force brute ou à la mise en place de sessions VPN SSL avec un utilisateur non autorisé.
D’après la nouvelle version du bulletin, à laquelle a contribué l’OFAC (Office anti-cybercriminalité français), l’arsenal d’accès initial s’est diversifié. Avec notamment :
CVE-2020-3580, autre vulnérabilité sur l’interface web d’ASA et FTD, permettant un XSS sans authentification
CVE-2023-28252, faille dans le CLFS (service de journalisation Windows utilisé par les programmes s’exécutant en mode utilisateur ou noyau), utilisée pour l’élévation de privilèges
CVE-2024-37085 (contournement d’authentification dans ESXi via Active Directory)
CVE-2023-27532 et CVE-2024-40711, qui touchent toutes les deux Veeam Backup & Replication (la première permet d’exfiltrer des authentifiants chiffrés depuis la base de données de config ; la deuxième ouvre la porte à une RCE par désérialisation de données malicieuses)
Zemana AntiMalware détourné pour stopper les antivirus
Sur la phase de reconnaissance, la mise à jour du bulletin ajoute peu d’éléments. Sinon l’utilisation de nltest /dclist: et de nltest /DOMAIN_TRUSTS.
Parmi les outils dont se servent les affiliés d’Akira figurent NetScan, Advanced IP Scanner et SoftPerfect. Mimikatz et LaZagne aussi, pour récupérer des authentifiants.
La version initiale signalait le recours à un outil légitime (Zemana AntiMalware) pour stopper les processus liés à des antivirus.
La mise à jour y ajoute l’exploitation d’outils d’accès distant tels AnyDesk et LogMeIn pour établir une persistance et se fondre dans l’activité admin.
La protection des disques virtuels neutralisée
La version initiale du bulletin apportait peu d’informations sur la manière dont les affiliés d’Akira obtenaient des privilèges.
La mise à jour en dit davantage, entre exploitation de services comme Veeam.Backup.MountService.exe et ajout de nouveaux comptes utilisateurs au groupe admin.
Elle mentionne un incident dans lequel la protection VMDK a été contournée en éteignant temporairement la VM du contrôleur de domaine. Les VMDK ont alors été copiés et attachés à une nouvelle VM. Cela a permis d’extraire le fichier NTDS.dit et la hive SYSTEM (groupe logique de clés, sous-clés et valeurs de registre) ; pour, au bout, compromettre un compte d’administrateur de domaine.
Un chiffrement hybride et personnalisable
Quantité d’outils ont été mis à profit pour l’exfiltration de données. 7-zip et WinRAR en font partie, comme FileZilla, RClone et WinSCP.
Pour établir des canaux de commande et de contrôle, AnyDesk, Cloudflare Tunnels, MobaXterm, Ngrok et RustDesk ont été mis à contribution.
Dans certain cas, à peine 2 heures se sont écoulées entre l’accès initial et l’exfiltration.
Le schéma de chiffrement utilisé par Akira était pour l’essentiel déjà établi en avril 2024. Hybride, il associe un cipher ChaCha20 et un système à clé RSA publique. L’ensemble permet un chiffrement total ou partiel, tout en le personnalisant selon le type et la taille de fichiers.
Afin de compliquer la récupération et l’analyse forensique, des commandes PowerShell sont utilisées pour supprimer les copies VSS.
Des options pour ne cibler que les VM
La première version d’Akira était écrite en C++. Sa deuxième incarnation, repérée à l’été 2023, est écrite en Rust. Elle est dotée d’une couche de protection supplémentaire compliquant l’analyse dynamique. Ainsi que d’une gestion des threads, améliorant l’efficacité du processus de chiffrement. Elle peut par ailleurs être déployée exclusivement contre les VM (paramètre vmonly) et stopper ces dernières (stopvm).
Akira est associé aux groupes connus sous le nom de Gold Sahara, Howling Scorpius, Punk Spider et Storm-1567. Il pourrait avoir des liens avec feu Conti.
* Lors d’une récente conférence, Gartner a prédit qu’à l’horizon 2028, 35 % des workloads VMware seraient passés sur une autre plate-forme. Le cabinet américain a suggéré d’envisager en premier lieu Nutanix. Pas tant pour les prix que pour les capacités fonctionnelles.
Istio et Kueue pour certains, Traefik et Volcano pour d’autres ; parfois Kubeflow, parfois KubeRay, ou les deux… Les fournisseurs de plates-formes Kubernetes ont emprunté divers chemins pour démontrer leur conformité à la « spécification IA » élaborée par la CNCF.
Cette spec définit un ensemble de capacités, d’API et de configurations qu’un cluster certifié « conforme Kubernetes » doit proposer pour exécuter de façon fiable des workloads IA/ML. Principal objectif : éviter une fragmentation qui compromettrait la portabilité.
Un premier tour d’autocertification avec 9 éléments obligatoires
Les travaux avaient officiellement démarré cet été. Une v1 a été publiée depuis et un premier round de certification a été lancé. Plus précisément d’autocertification : le processus est pour le moment déclaratif. Une suite de tests automatisés est censée prendre le relais, mais pas avant 2026.
Beaucoup d’éléments inscrits dans la spécification ne sont, en tout cas pour le moment, pas obligatoires. Parmi eux :
Assurer que des pilotes compatibles et les configs runtime correspondantes sont correctement installés et maintenus sur les nœuds dotés d’accélérateurs
Faciliter le tirage de grosses images de conteneurs (par exemple à travers une réplication ou une mise en cache près des nœuds d’exécution)
Permettre la gestion unifiée de jobs indépendants via un mécanisme gérant les API JobSet
Autoriser le déploiement de conteneurs confidentiels dans des environnements d’exécution sécurisés (enclaves matérielles)
Fournir un mécanisme de détection des accélérateurs en erreur, avec éventuellement une remédiation automatisée
9 éléments sont actuellement obligatoires. Dans les grandes lignes :
Prendre en charge l’allocation dynamique des ressources (DRA)
Gérer la Gateway API de Kubernetes, dans une implémentation permettant une « gestion avancée » pour les services d’inférence (distribution pondérée du trafic, routage sur la base des en-têtes, intégration avec les maillages de services…)
Permettre d’installer et d’exploiter au moins une solution de planification des gangs
Gérer la mise à l’échelle verticale des groupes de nœuds contenant des types d’accélérateurs spécifiques
Si présent, assurer un fonctionnement correct de l’HorizontalPodAutoscaler pour les pods qui exploitent des accélérateurs
Exposer, pour les types d’accélérateurs pris en charge, des métriques granulaires, via un endpoint standardisé, et dans un format lisible par la machine (au minimum, taux d’utilisation par accélérateur + occupation mémoire)
Découverte et collecte de métriques de workloads dans un format standard
Isolation des accès aux accélérateurs depuis les conteneurs
Possibilité d’installer et d’exécuter de façon fiable au moins un opérateur IA complexe disposant d’un CRD
Chaque certification vaut pour un an et s’applique à une version spécifique de Kubernetes. En l’état, soit la 1.33 (8 solutions certifiées), soit la 1.34 (11 solutions certifiées).
Les 8 solutions (auto)certifiées sur Kubernetes 1.33
Premier dans l’ordre alphabétique, CoreWeave Kubernetes Services (CKS).
Entre autres commentaires insérés dans sa déclaration de conformité, le « néo-cloud » américain – voir notre article à son sujet – rappelle gérer le planificateur SUNK (Slurm on Kubernetes). Il explique aussi que l’isolation des accès est pour l’instant traitée avec des plug-in, en attendant de passer au DRA lorsque le support fournisseur sera plus mature.
DaoCloud Enterprise n’implémente pas le DRA (il faut dire que les API sont désactivées par défaut sur Kubernetes 1.33, de sorte que la spec n’impose pas la fonctionnalité). Destiné à l’exécution sur site, il ne fournit pas non plus d’autoscaler vertical.
Pour sa plate-forme Gardener, la NeoNephos Foundation (projet de la Fondation Linux Europe) livre une preuve d’implémentation de la Gateway API via Traefik. Et de la planification des gangs via Kueue. L’autoscaling horizontal est géré avec une stack associant Prometheus et DCGM (NVIDIA Datacenter GPU Manager). Comme « opérateur IA complexe », KubeRay a été choisi.
L’entreprise allemande Giant Swarm fournit la plate-forme du même nom. Elle n’a pas ajouté de commentaires à son autocertification. Les renvois vers sa documentation montrent toutefois que Kueue a été sélectionné pour démontrer la conformité sur la partie planification des gangs, et KubeRay en guise d’opérateur IA.
Red Hat est également au rendez-vous, avec la dernière version d’OpenShift (4.20). Lui aussi a opté pour Kueue. Comme opérateur IA, la filiale d’IBM a utilisé Kubeflow Trainer, avec plusieurs CRD (TrainJob, TrainingRuntime, ClusterTrainingRuntime). Elle précise, concernant les métriques d’accélérateurs, propose des opérateurs dédiés pour les GPU AMD en plus des GPU NVIDIA.
SUSE a autocertifié RKE2 (deuxième itération de Rancher Kubernetes Engine). Là aussi sans commentaires supplémentaires, mais avec un renvoi vers une nouvelle section de sa doc consacrée à la conformité vis-à-vis de la spec CNCF. On y découvre que Volcano a été privilégié pour la planification des gangs. Et que pour la collecte de métriques, la solution SUSE AI est mise en avant.
Red Hat a autocertifié un deuxième produit : ROSA (Red Hat OpenShift Service on AWS), dans sa dernière version. Avec, la même base que pour OpenShift, mais des validations spécifiques.
Talos Linux, OS immuable pour Kubernetes, a également été certifié, par son éditeur Sidero Labs. Lequel signale qu’aucun autoscaler vertical spécifique n’est fourni et que le produit n’embarque pas, en standard, d’outils d’observabilité.
Les 11 solutions (auto)certifiées sur Kubernetes 1.34
Premier dans l’ordre alphabétique, ACK (Alibaba Cloud Container Service for Kubernetes). Sa conformité a été démontrée en utilisant à la fois Spark et Ray. Sur la partie métriques, Alibaba a exploité son Prometheus managé.
AKS (Azure Kubernetes Service) a aussi été autocertifié. Microsoft a utilisé Istio, Kueue et DCGM, entre autres. Pour les opérateurs IA, il a fait un choix particulier au-delà de Ray : KAITO (Kubernetes AI Toolchain Operator), projet en sandbox à la CNCF et qui repose sur vLLM.
Baidu a autocertifié sa solution CCE (Cloud Container Engine). Avec Volcano pour l’implémentation Gateway API, du Prometheus managé pour l’autoscaling horizontal… et un déploiement SGLang pour la partie contrôleur IA.
Autocertifié sur Kubernetes 1.33, CKS (CoreWeave Kubernetes Service) l’est aussi sur la version 1.34.
Amazon a essentiellement recouru à ses propres services pour démontrer la conformité d’EKS (Elastic Kubernetes Service). Entre autres, son contrôleur AWS Load Balancer, son planificateur AWS Batch, son outil de supervision CloudWatch et son collecteur de métriques Neuron Monitor.
GKE (Google Kubernetes Engine) est également autocertifié. Comme Amazon, Google met en avant ses propres services… et un tuto, destiné à construire une plate-forme ML associant Ray et Kubeflow.
KKP (Kubermatic Kubernetes Platform) a sa propre stack MLA (« Monitoring Logging & Alerting »), exploitée dans le cadre de son autocertification. Il a aussi son propre contrôleur de passerelle (KubeLB).
Avec LKE (Linode Kubernetes Engine), Akamai a son propre autoscaler vertical. Pour les pods, il passe par l’adaptateur Prometheus. La collecte de métriques relatives aux accélérateurs passe par DCGM. Istio est utilisé comme implémentation référente de la Gateway API.
Istio a aussi été le choix d’Oracle pour démontrer la conformité d’OKE (OCI Kubernetes Engine). On aura noté que pour les métriques de workloads, le groupe américain a son propre projet OCI GPU Scanner, mis à disposition sous licence libre (UPL) et installable soit via Terraform, soit via Helm, soit comme add-on depuis la console OCI.
Autocertifié sur Kubernetes 1.33, Talos Linux l’est aussi sur la version 1.34.
Le dernier dans l’ordre alphabétique est VKS (VMware Kubernetes Service). VMware l’a autocertifié en s’appuyant notamment sur Istio, Kueue, Prometheus, DCGM et KubeRay.
Dans l’écosystème Microsoft évolueront peut-être bientôt des « utilisateurs agentiques » ayant leur identité, leur place dans l’organigramme… et leur licence.
Des informations à ce sujet seront possiblement communiquées la semaine prochaine à la conférence Ignite. En attendant, il y a des faisceaux d’indices. Notamment un message publié début novembre dans le centre d’administration Microsoft 365. Il a disparu depuis, comme l’élement de roadmap associé. On a pu y apercevoir une nouvelle marque : Agent 365.
Les agents en question seraient créés à partir de modèles préconfigurés.
Il appartiendrait aux admins de choisir lesquels de ces modèles publier. Par défaut, l’ensemble des utilisateurs du locataire y auraient accès, à deux endroits : Teams (section Apps) et le magasin d’agents Microsoft 365. Leurs demandes de création d’agents sur la base de ces templates remonteraient aux admins. Qui, en cas d’approbation, auraient à assigner une licence A365 à chaque agent.
Le message publié dans le centre d’administration évoquait un déploiement progressif à partir de mi-novembre, sur desktop (dans Teams et Microsoft 365 Copilot).
Agent 365, une démarche avant tout commerciale
Au vu de ces quelques éléments, l’évolution qui se prépare ne semble pas tant technologique que commerciale. Il se dit d’ailleurs que la marque Agent 365 pourrait prendre le relais de Microsoft 365 Copilot. Potentiellement une manière d’atténuer la confusion que le branding actuel suscite jusqu’en interne.
Après deux ans de commercialisation, l’adoption de Microsoft 365 Copilot apparaît décevante. En tout cas d’après les affirmations d’Ed Zitron. L’intéressé, qui s’est fait une solide réputation de pourfendeur de l’IA générative, affirmait cet été que le taux de transformation au sein de la base Microsoft 365 était inférieur à 2 %. Un chiffre que Microsoft n’a pas démenti.
L’usage – mais pas forcément la conversion – a pu augmenter depuis, entre autres avec la mise à disposition gratuite de quelques fonctionnaltiés Copilot Chat dans Word, Excel, PowerPoint, OneNote et Outlook (essentiellement, des conversations basées sur le web et sur le fichier ouvert).
Divers abonnements initialement autonomes (Copilot pour les ventes, pour le service et pour la finance, par exemple) ont par ailleurs été fusionnés dans Microsoft 365 Copilot.
À consulter en complément sur le sujet Microsoft 365 Copilot :
Le 22 novembre 2023, le premier finalisait l’acquisition du second. Il n’allait pas tarder à en bouleverser la politique commerciale, avec les conséquences que l’on sait.
Quantité de fournisseurs d’offres concurrentes se sont engouffrés dans la brèche, tentant de capter le replatforming des parcs de VM. Red Hat n’y a pas fait exception. Il a évidemment mis en avant la conteneurisation sur OpenShift. Mais aussi la brique de virtualisation intégrée à la plate-forme depuis l’été 2020. Jusqu’à en faire un produit spécifique, lancé début 2025 : OpenShift Virtualization Engine, qui n’inclut pas de droit d’usage de conteneurs applicatifs.
Topologie localnet et instances personnalisées
Au-delà de la stratégie commerciale, OpenShift Virtualization a connu des évolutions fonctionnelles notables depuis la fusion Broadcom-VMware. Six versions mineures sont sorties, à commencer par la 4.15 (publiée le 27 février 2024 ; arrivée en fin de vie le 27 août 2025).
Cette version avait notamment apporté la gestion du branchement à chaud d’interfaces réseau secondaires sur les VM (hors interfaces SR-IOV). Elle avait aussi ajouté la prise en charge de la topologie localnet pour les réseaux secondaires OVN-Kubernetes (connexion à la sous-couche physique).
Autre élément ajouté : le KSM (kernel samepage merging). Cette fonctionnalité s’enclenche lorsqu’un nœud est surchargé. Elle déduplique les données identiques trouvées dans les pages mémoire des VM.
OpenShift Virtualization 4.15 a également permis d’activer l’accès aux logs console des invités et de configurer des clusters pour les workloads DPDK (Data Plane Development Kit, délégation du traitement des paquets TCP à des processus en espace utilisateur) sur SR-IOV. La console web avait été enrichie en parallèle pour permettre l’installation et l’édition de types d’instances personnalisés. Et pour importer des secrets depuis d’autres projets lors de l’ajout d’une clé SSH publique à une VM en cours de création ou d’un secret à une VM existante.
Hotplug de vCPU et accès headless aux VM
Le 27 juin 2024 sortait OpenShift Virtualization 4.16. Cette version est actuellement en phase de maintenance, jusqu’au 27 décembre 2025. Le support étendu durera jusqu’au 27 juin 2026. Avec elle, le hotplug de vCPU est passé en disponibilité générale.
Il est aussi devenu possible d’accéder à une VM à travers des services Kubernetes headless, en utilisant son nom de domaine interne. Et d’activer la featuregate AutoResourceLimits pour gérer automatiquement les limites CPU et mémoire des VM.
OpenShift Virtualization 4.16 a aussi ajouté la possibilité de sélectionner les options sysprep à la création de VM Windows plutôt que par après. Et d’exposer certaines métriques d’hôte ou d’invité au sein des VM, en ligne de commande ou via l’outil vm-dump-metrics.
Gestion de la densité des workloads et exposition de périphériques USB
OpenShift Virtualization 4.17, sorti le 1er octobre 2024, arrivera en fin de vie le 1er avril 2026, sans phase de support étendu.
Avec cette version, Red Hat a certifié la prise en charge de Windows Server 2025 comme OS invité. Il a aussi permis de sélectionner un namespace personnalisé pour ses golden images. Et donné la possibilité d’accroître la densité de workloads dans les VM en surréservant (overcommit) la RAM. Comme d’exposer des périphériques USB dans un cluster, de sorte que les propriétaires de VM peuvent ensuite les assigner.
Le hotplug de CPU et de mémoire depuis la console est passé en disponibilité générale avec OpenShift Virtualization 4.17. Même chose pour la configuration de stratégies d’éviction de VM à l’échelle d’un cluster.
Réseaux définis par l’utilisateur et changement à chaud de type d’instance
Sorti le 25 février 2025, OpenShift Virtualization 4.18 arrivera en fin de maintenance le 25 août 2026. Le support étendu durera jusqu’au 25 février 2027.
Depuis cette version, on peut connecter une VM à un réseau défini par l’utilisateur sur l’interface primaire. On peut aussi changer le type d’instance associé à une VM en cours d’exécution, sans redémarrage.
Autre ajout : la capacité de créer des snapshots de VM auxquelles on ajoute un vTPM. Et de les restaurer à partir de ces snapshots (mais pas d’en créer de nouvelles, ni de les cloner).
La console a quant à elle évolué pour permettre de contrôler simultanément l’état de plusieurs VM. Et de visualiser des métriques de niveau workload pour les ressources disque, CPU et réseau allouées.
Protection des VM et threads I/O multiples pour le stockage flash
OpenShift Virtualization 4.19 fut publié le 17 juin 2025. Il entrera en phase de maintenance le 17 décembre 2025 et n’aura pas de support étendu.
Avec cette version, RHEL 10 rejoint la liste des OS invités certifiés. Red Hat introduit aussi un mécanisme de protection des VM contre la suppression. Et permet de mettre à jour le type de machine pour plusieurs VM à la fois depuis le CLI OpenShift.
La topologie localnet sur OVN-Kubernetes est devenue utilisable pour connecter une VM à un réseau secondaire défini par l’utilisateur. Et il est devenu possible de configurer un manifeste NodeNetworkConfigurationPolicy pour activer l’écoute LLDP sur tous les ports Ethernet d’un cluster.
Autre nouveauté : la possibilité de configurer plusieurs threads I/O pour les VM utilisant de la mémoire flash. Quant à la console, elle a évolué pour proposer davantage d’actions groupées sur les VM (gestion des étiquettes, déplacement dans un autre dossier au sein d’un même namespace…). Des métriques supplémentaires ont par ailleurs été mises à disposition, concernant les migrations, les vNIC et le stockage alloué aux VM.
Topologie NUMA et saut de versions de correction
La dernière version mineure en date (4.20) est sortie le 21 octobre 2025. Elle arrivera en fin de vie le 21 avril 2027, sans support étendu.
Avec elle, Red Hat permet de sauter des versions de correction (pas besoin d’installer toutes les versions intermédiaires lorsqu’on met à jour).
Plusieurs éléments passent en disponibilité générale, dont la possibilité d’exploiter la topologie NUMA (non-uniform memory access) pour les VM. Elle permet de définir des zones au sein desquelles les CPU bénéficient d’un accès plus rapide aux ressources locales que les CPU externes.
Le profil KubeVirtRelieveAndMigrate, qui améliore la stabilité de l’éviction de VM lors des migrations à chaud, est également passé en disponibilité générale. Idem pour la possibilité de déployer OpenShift Virtualization sur OCI et en bare metal sur cluster ARM64.
Dans la console, on peut désormais, lors de migrations à chaud, spécifier le nœud vers lequel déplacer une VM. Parallèlement, la procédure de hotplug de disques s’est enrichie d’une étape optionnelle permettant de sélectionner un type de bus.
Il y a avantage quantique lorsque l’association des méthodes quantiques et classiques est plus performante que les méthodes classiques seules.
Aux dernières nouvelles, c’est la définition que donne IBM.
Il n’en a pas toujours été ainsi. En tout cas dans la communication publique du groupe américain.
Encore récemment, il n’était pas explicitement question d’association classique-quantique. La notion était simplement décrite comme la capacité d’un ordinateur quantique à effectuer un calcul de manière plus précise, économique ou efficace (« more accurately, cheaply, or efficiently« ) qu’un ordinateur classique.
Avantage quantique : une méthodo, puis un tracker
Un livre blanc publié à l’été 2025 avec la start-up française PASQAL a témoigné de l’évolution du discours. Y est formulé le postulat selon lequel atteindre un avantage quantique à court terme suppose une intégration avec les infrastructures HPC.
Rappelant, à ce sujet, avoir publié des plug-in Slurm, les deux entreprises établissent surtout, par l’intermédiaire de ce whitepaper, une méthodologie de validation scientifique de l’avantage quantique.
Ce jalon posé, IBM a créé, avec BlueQubit (USA), Algorithmiq (Finlande) et des chercheurs du Flatiron Institute, un « tracker d’avantage quantique ». Lui et ses partenaires sur ce projet ont soumis diverses expérimentations, réparties en trois catégories :
Estimation des observables quantiques
Algorithmes quantiques variationnels (destinés à résoudre des problèmes combinatoires)
Problèmes pour lesquels la vérification quantique est efficace
À travers son API C, Qiskit se rapproche du HPC
L’un des derniers marqueurs de rapprochement vis-à-vis des environnements HPC fut l’introduction d’une fonction autonome de transpilation de circuits dans l’API C de Qiskit. C’était avec la version 2.2 du SDK, publiée en octobre 2025.
Cette API, introduite au printemps 2025 avec Qiskit 2.0, est dotée d’une interface de fonction étrangère qui permet d’exploiter d’autres langages. En première ligne, C++, particulièrement populaire pour le calcul scientifique. Et, plus globalement, les langages compilés (Qiskit a été développé à l’origine en Python, un langage interprété).
Relay-BP, Samplomatic… Des briques à l’édifice de la correction d’erreurs
Entre les deux, Qiskit 2.1 a introduit la possibilité d’ajouter des flags à des régions spécifiques d’un circuit. Une bibliothèque logicielle – Samplomatic, en bêta – y a été adossée. Elle permet de personnaliser ces régions. Et, au bout, de faciliter la construction de circuits dynamiques (qui incorporent des opérations classiques au cours de leur exécution).
Cette personnalisation est aussi censée faciliter la mise en œuvre de techniques de correction d’erreurs.
Sur ce volet, IBM compte notamment avoir assemblé, pour fin 2025, un prototype de processeur. Appelé Loon, il doit réunir divers composantes-clés dont la faisabilité a déjà été démontrée séparément : connectivité à 6 voies, accroissement des couches de routage à la surface de la puce, coupleurs physiquement plus longs, techniques de réinitialisation plus rapide des qubits…
Parmi les autres composantes-clés annoncées cette année, il y a Relay-BP, un algorithme de décodage d’erreurs. IBM en a récemment annoncé une implémentation sur FPGA AMD. Il annonce « moins de 480 nanosecondes » par tâche de décodage, en reconnaissant qu’il reste du travail dans la perspective d’un passage à l’échelle.
Nighthawk en attendant Starling
Relay-BP est arrivé en avance par rapport à la feuille de route. Il était effectivement prévu pour 2026.
À ce même horizon, IBM entend ajouter à Qiskit des outils de profilage de workloads hybrides (quantique-classique). Il prévoit aussi de lancer Kookabura, puce censée réunir unité de calcul et mémoire quantique.
En attendant, la dernière nouveauté côté processeurs s’appelle Nighthawk. Elle prend la suite de la génération Heron avec moins de qubits pour commencer (120 contre 156), mais autant de portes logiques (5000), davantage de coupleurs (218 vs 176), un taux d’erreur médian réduit… et la perspective de monter en capacité :
Pour 2026 : 7500 portes et jusqu’à 3 x 120 qubits
Pour 2027 : 10 000 portes et jusqu’à 9 x 120 qubits
Pour 2028 : 15 000 portes et jusqu’à 9 x 120 qubits
Un ordinateur quantique tolérant aux erreurs reste visé pour 2029. Avec, en ligne de mire, la puce Starling (100 millions de portes, 200 qubits). Blue Jay (1 milliard de portes, 2000 qubits) est censé suivre en 2030.
IBM prévoit un jeu d’instructions tolérant aux erreurs pour 2028
Depuis 2024, Qiskit est assorti d’un catalogue de fonctions : résolution d’équations différentielles (ColibriTD), de problèmes de classification (Multiverse Computing), de problèmes d’optimisation (Q-CTRL, Kipu Quantum), etc.
Ces fonctions trouveront une continuité sous la forme de bibliothèques d’applications quantiques. Les premières sont prévues pour 2027. IBM promet, pour la même échéance, un accélérateur pour au moins un workflow ayant démontré un avantage quantique. Puis, pour 2028, un jeu d’instructions tolérant aux erreurs.
En parallèle de ce changement de marque, la communication autour du produit évolue. Elle se porte plus sensiblement sur les intégrations avec l’écosystème Chrome.
En la matière, on ne partait pas de zéro. Mi-2024, lorsque Google avait annoncé acquérir Cameyo, des jonctions étaient déjà en place. Essentiellement vis-à-vis de ChromeOS (intégration avec le système de fichiers local, gestion du presse-papiers, livraison d’apps en tant que PWA…).
Est désormais mise en avant l’idée d’expérience unifiée au sein de Chrome Enterprise. Les applications client lourd virtualisées avec Cameyo bénéficieraient, d’un côté, du même contexte de sécurité que le SaaS (filtrage d’URL, DLP, protection contre les menaces…). Et de l’autre, de la même couche IA, à travers l’assistant Gemini for Chrome.
Google érige désormais Cameyo au rang de plate-forme.
La virtualisation Linux, moins mise en avant sous l’ère Google
À l’exception de quelques renvois vers chez Google, le site Internet de Cameyo est demeuré tel qu’il était avant l’acquisition.
Parmi les promesses d’alors, il y avait celle de pouvoir virtualiser des applications Linux et des web apps internes sans avoir besoin d’une licence Windows Server.
Dans le giron de Google, cette possibilité n’est pas exclue, mais elle est nettement moins mise en avant, jusque dans l’assistance en ligne.
Le modèle de licence n’a pas non plus changé (abonnement par utilisateur), mais le nombre minimal d’utilisateurs a augmenté : 50 dorénavant, contre 25 auparavant (voire 15 sur la version autohébergée de Cameyo).
La version managée n’est plus déployable sur Azure : Google Cloud est maintenant l’hébergeur exclusif. Il est, dans ce cadre, responsable du déploiement des VM et de leur mise à l’échelle. Mais pas des logiciels – y compris l’OS – qui fonctionnent sur ces VM.
Des jonctions avec Drive et l’annuaire Google Workspace
Sur GCP, un serveur Cameyo peut exploiter 6 niveaux de capacité, variant en vCPU (1 à 16), en RAM (3,75 à 60 Go) et en réseau (pas d’accès Internet sur les deux premiers niveaux). Des clusters peuvent être mise en place pour l’autoscaling.
Pour l’autohébergement, il faut compter au moins 2 CPU et 8 Go de RAM, avec au minimum Windows Server 2019 (Windows Server 2025 n’est pas encore pris en charge).
D’autres jonctions avec l’écosystème Google ont été établies pour l’authentification des utilisateurs (SSO avec compte Google) et la configuration des permissions (annuaire Google Workspace). Drive a par ailleurs été intégré directement dans les sessions (explorateur et fenêtres de dialogue spécifiques).
Cameyo ne gère pas les applications qui ont besoin d’un accès direct à des périphériques locaux (webcams, imprimantes…). Ni celles qui dépendent de fonctions système (enregistrement d’écran, compression de fichiers…).
Entre Ngrok et Pinggy, pas de jaloux : les attaquants qui s’en sont pris au centre hospitalier Stell de Rueil-Malmaison ont exploité l’un et l’autre de ces services de tunneling.
C’était en mars dernier. Au bout, le déploiement d’un ransomware qui avait chiffré des serveurs Windows. La gestion administrative des patients, entre autres, s’en était trouvée indisponible pendant un temps. Des données personnelles ont par ailleurs possiblement été exfiltrées.
Un compte de test admin de domaine
Le point d’entrée fut un ancien compte de test, réactivé le 4 mars 2025 pour un audit Wi-Fi. Ce compte au mot de passe faible avait des privilèges d’admin de domaine et disposait d’un accès VPN.
L’accès initial, via ce vecteur, a lieu le 17 mars (un lundi). Le 22, une latéralisation est mise en œuvre par connexion RDP sur le contrôleur de domaine. Un mécanisme de persistance est ensuite déployé, en ajoutant Pinggy pour établir une connexion SSH sur le port 443.
Vendredi 28 mars, un canal est mis en place entre le contrôleur de domaine et le serveur de l’attaquant grâce à Ngrok. Le même jour, le ransomware est déployé et exécuté. Le lendemain, les traces de l’attaque sur les systèmes sont supprimées.
Le CH de Rueil-Malmaison passe au tiering AD
Le chiffrement n’est constaté que lundi 31 mars. À partir de là, les flux VPN sont coupés ; les serveurs impactés, isolés. Le lendemain, les sauvegardes sont mises hors réseau en vérifiant leur intégrité. L’ANSSI et le CERT Santé se déplacent sur site.
Le 2 avril, l’analyse des serveurs compromis démarre. Et du matériel (postes, clés 4G…) est demandé à l’ARS.
La reconstruction AD débute le 7, parallèlement à la fin des analyses. Le 10, la bascule est achevée. Le service de sauvegarde est relancé, les services métiers impactés sont restaurés et une formation d’administration sécurisée est dispensée.
La période d’avril-mai est marquée par le rétablissement progressif des services RH et d’admission, ainsi que le déploiement de nouveaux postes. Entre juin et septembre, un modèle par niveaux de privilège est mis en place pour l’AD.
Dans la réglementation européenne, les « données à caractère personnel » seront peut-être bientôt une notion moins absolue.
L’omnibus numérique, que Bruxelles doit présenter la semaine prochaine, va en tout cas dans ce sens. Tout du moins si on en croit le brouillon qui a filtré.
À l’heure actuelle, le RGPD définit les données personnelles comme toute information se rapportant à une personne physique identifiée ou identifiable.
L’omnibus numérique impose d’apprécier la notion du point de vue de chaque entité : des informations n’ont pas de caractère personnel pour qui ne peut pas identifier la personne concernée à l’aide de moyens raisonnables. De même, elles ne le deviendraient pas du point de vue de cette même entité simplement parce qu’un destinataire ultérieur aurait raisonnablement les moyens de réaliser cette identification.
Traitement de catégories particulières de données : une exception à la faveur des systèmes d’IA
L’omnibus numérique modifierait une autre définition inscrite dans le RGPD : celle des « données concernant la santé ». Il ne s’agirait plus que de celles qui révèlent « directement » des informations sur l’état de santé d’une personne.
La même approche serait adoptée pour amender l’article 9 (traitement de catégories particulières de données personnelles). Ne serait plus interdit que le traitement de données personnelles révélant « directement » l’origine raciale ou ethnique, les opinions politiques, les convictions religieuses ou philosophiques, etc.
En l’état, cette interdiction ne s’applique pas si certaines conditions sont remplies. Par exemple, l’obtention d’un consentement explicite ou une nécessité pour la sauvegarde des intérêts vitaux de la personne concernée.
L’omnibus y ajoute deux possibilités, dont une touchant au développement et à l’exploitation de systèmes d’IA. Ce à condition d’avoir mis en place les mesures techniques et organisationnelles appropriées pour éviter autant que possible la collecte de catégories particulières de données personnelles. Et, le cas échéant, de supprimer ces données ou d’éviter qu’elles alimentent des outputs, soient divulguées ou soient rendues accessibles à des tiers.
Un allégement des exigences d’information des personnes concernées
L’omnibus numérique amenderait aussi l’article 13 (informations à fournir lorsque des données personnelles sont collectées auprès de la personne concernée).
Actuellement, les dispositions ne s’appliquent pas lorsque la personne concernée dispose déjà de ces informations.
À l’avenir, elles ne s’appliqueraient pas dès lors que les collectes seraient effectuées dans le cadre d’une relation « claire et délimitée » par un responsable de traitement exerçant une activité « non intensive en données ». Et qu’il existerait des motifs raisonnables de supposer que la personne connaît déjà les finalités et la base juridique du traitement, ainsi que l’identité et les coordonnées du responsable.
Tout cela ne vaudrait pas si les données étaient transmises à d’autres destinataires ou catégories de destinataires, transférées vers des pays tiers, exploitées pour de la décision automatisée, ou si le traitement pose un risque élevé pour les droits et libertés des personnes concernées.
De « interdit sauf si » à « autorisé sauf si » : une tournure plus favorable aux décisions individuelles automatisées
La décision individuelle automatisée (article 22) évoluerait aussi en conséquence de l’omnibus numérique.
Actuellement, il est établi que la personne concernée a le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques la concernant ou l’affectant de manière significative de façon similaire. Ce droit ne s’applique pas lorsque la décision est :
Nécessaire à la conclusion ou à l’exécution d’une contrat
Autorisée par le droit de l’UE ou de l’État membre auquel le responsable de traitement est soumis
Fondée sur le consentement explicite de la personne concernée
Le fond ne changerait pas. Mais la forme, si, au profit d’une rédaction de type « traitement automatisé autorisé sauf si… ».
Violations de données personnelles : notifications restreintes et délai allongé
Un autre assouplissement est prévu sur l’article 33.
Celui-ci impose actuellement aux responsables de traitement de notifier les violations de données personnelles à l’autorité de contrôle référente sous 72 heures.
L’omnibus numérique cette obligation aux violations engendrant un risque élevé pour les droits et libertés de personnes physiques. Il porterait par ailleurs le délai à 96 heures.
Les autorités de contrôle n’établiraient plus leur liste d’AIPD
La conception de listes des types d’opérations de traitement exigeant une AIPD (analyse d’impact préalable) est actuellement à la charge des autorités de contrôle, qui les communiquent aux Comité européen de la protection des données.
L’omnibus numérique supprimerait cet échelon : la liste serait directement élaborée par ledit comité, qui la transmettrait à la Commission européenne.
Traitements de données au travail : un cadre précisé pour les données des terminaux
L’article 88, relatif au traitement des données dans le cadre des relations de travail, n’évoluerait pas en lui-même. Mais trois articles 88a, 88b et 88c viendraient le compléter.
L’article 88a encadrerait le traitement de données personnelles stockées sur ou provenant de terminaux. Il l’autoriserait s’il est nécessaire pour :
Acheminer une communication électronique
Fournir un service explicitement demandé par la personne concernée
Agréger des infos sur l’usage d’une service en ligne afin de mesurer son audience
Maintenir ou restaurer la sécurité d’un service demandé par la personne concernée ou du terminal utilisé pour fournir ce service
Pour toutes autres finalités, les traitements auraient à respecter les bases légales énoncées à l’article 6 du RGPD et éventuellement l’article 9 (catégories particulières de données personnelles). Un éventuel consentement devrait pouvoir être manifesté par un clic sur un bouton « ou par des moyens équivalents ». Le responsable de traitement aurait à respecter ce choix pour au moins 6 mois.
Une (énième) perspective d’expression automatisée du consentement
L’article 88b ouvre la voie à une expression du consentement de manière automatisée et lisible par la machine. Une solution que l’UE explore depuis bien longtemps : un amendement de 2009 à la directive ePrivacy avait déjà encouragé un tel mécanisme, notamment par l’intermédiaire des paramètres de navigateur web.
Une fois les normes harmonisées établies, les responsables de traitement auraient 6 mois pour faire en sorte que leurs services gèrent ces signaux. Les médias – tels que définis dans l’European Media Freedom Act de 2024 – n’y seraient pas tenus, « vu l’importance que les revenus publicitaires représentent pour eux ».
En cas d’adoption insuffisante par les fournisseurs de navigateurs web et de systèmes d’exploitation, la Commission européenne aurait le pouvoir de les contraindre par actes délégués.
L’article 88c concernerait les traitements dans le contexte du développement et de l’exploitation de systèmes d’IA. Ils les autoriserait s’ils sont nécessaires au sens de l’article 6(1)(f). C’est-à-dire au nom des intérêts légitimes du responsable de traitement ou d’un tiers, à moins que ne prévalent les intérêts ou les libertés et droits fondamentaux de la personne concernée.
L’échéance approche : le 19 novembre, la Commission européenne devrait présenter son « omnibus numérique ».
Un brouillon, non daté, a filtré avant l’heure. Il est proposé d’y amender 5 textes :
Data Act (règlement 2023/2854)
RGPD (règlement 2016/679)
AI Act (règlement 2024/1689)
ePrivacy (directive 2002/58/EC)
SRI 2 (directive 2022/2555)
Il s’agit aussi d’en abroger 4 :
Data Governance Act (règlement 2022/868)
Directive Open Data (2019/1024)
Règlement sur la libre circulation des données à caractère non personnel au sein de l’UE (2018/1807, dit FFDR)
Règlement promouvant l’équité et la transparence pour les entreprises utilisatrices de services d’intermédiation en ligne (2019/150, dit P2B)
Le Data Act va « absorber » plusieurs autres textes
Data Governance Act, directive Open Data et règlement FFDR seraient consolidés au sein du Data Act. Une démarche d’autant plus logique, à en croire Bruxelles, que ces textes se chevauchent sans que leurs interactions soient toujours claires. Le FFDR, par exemple, a en partie été remplacé par le chapitre VI du Data Act (relatif au changement de services de traitement de données). Quant au chapitre II du Data Governance Act (réutilisation de certaines catégories de données détenues par des organismes du secteur public), il complète les dispositions de la directive Open Data.
La proposition d’omnibus numérique identifie quatre éléments « importants » pour assurer un équilibre entre disponibilité des données et droits/intérêts de leurs détenteurs :
Nécessité de renforcer les garde-fous contre le risque de fuite de secrets commerciaux vers des pays tiers dans le contexte des dispositions sur le partage de données des produits connectés
Risque d’ambiguïtés juridiques au vu du périmètre étendu du cadre business-to-government
Risque d’incertitude en lien avec les exigences essentielles pour les smart contracts exécutant des accords de partage de données
Insuffisance de prise en compte, dans le cadre du changement de fournisseur de traitement de données, des services adaptés aux besoin d’un client ou fournis par des PME/small caps
Vers la fin des exigences sur les smart contracts
Les exigences concernant les smart contracts se trouvent au chapitre VIII du Data Act (« Interopérabilité »). Elles touchent au contrôle de l’accès, à l’archivage des données, à la résiliation en toute sécurité, etc. L’omnibus numérique les supprimerait.
Données IoT : une protection renforcée du secret des affaires
Le chapitre II du Data Act régit le partage de données relatives aux produits connectés et aux services connexes. Actuellement, il permet à un détenteur de données de refuser de les communiquer au nom du secret des affaires s’il démontre qu’il existe un risque de préjudice économique grave.
L’omnibus numérique ajouterait un motif de refus supplémentaire : l’existence d’un risque élevé d’acquisition ou d’usage par des pays tiers qui ne garantissent pas un niveau de protection des données équivalent à celui de l’UE.
Un régime « spécial très grandes entreprises » pour l’open data public
Une simplification du cadre business-to-government serait effectuée au niveau du chapitre V du Data Act. Celui-ci régit la mise à disposition de données au bénéfice d’organismes du secteur public, de la Commission européenne, de la BCE ou d’un organe de l’UE « sur le fondement d’un besoin exceptionnel ».
L’omnibus numérique préciserait le champ d’application en remplaçant « besoin exceptionnel » par « urgence publique ».
La fusion des dispositions de la directive Open Data et du Data Governance Act en un chapitre sur la réutilisation des données du secteur public s’accompagnerait d’évolutions. Parmi elles, la possibilité de facturer plus l’accès aux très grandes entreprises – en première ligne, les « contrôleurs d’accès » tels que définis dans le DMA – et d’y assortir des conditions spécifiques.
En parallèle, les règles du Data Governance Act concernant certaines catégories de données protégées seraient introduites dans le Data Act sous forme simplifiée, avec une clarification sur les règles applicables dans les cas où des données personnelles ont été rendues anonymes.
Des facilités pour les PME qui fournissent de services traitement de données…
Le changement de fournisseur de traitement de données est encadré par le chapitre VI du Data Act.
L’omnibus numérique créerait un régime spécifique plus « léger » pour les services « personnalisés » (non commercialisés sur étagère et qui ne fonctionneraient pas sans une adaptation préalable aux besoins de l’utilisateur) à l’exception du IaaS. Ceux faisant l’objet d’un contrat signé avant le 12 septembre 2025 ne seraient soumis à aucune des obligations du chapitre (information, bonne foi, transparence sur les accès internationaux…) sauf celle relative à la suppression progressive des frais de changement.
Ce régime s’appliquerait aussi aux services fournis – dans le cadre de contrats signés avant cette même date – par des PME et des small caps. Ces dernières auraient la possibilité d’inclure, dans les contrats à durée déterminée, des pénalités de résiliation anticipée.
… et pour les fournisseurs de services d’intermédiation de données
L’omnibus numérique incorporerait dans le Data Act deux régimes actuellement inscrits dans le Data Governance Act. D’une part, le chapitre III, qui impose une notification des autorités compétentes par les prestataires de services d’intermédiation de données. De l’autre, le chapitre IV, qui établit un mécanisme d’enregistrement volontaire des organismes altruistes en matière de données au sein de registres publics nationaux.
Vu la nature émergente des services d’intermédiation de données, leurs prestataires ne devraient pas être obligés de notifier les autorités, estime Bruxelles. Le brouillon de l’omnibus numérique va dans ce sens. Il élimine par ailleurs l’obligation de séparation juridique vis-à-vis d’autres services, la remplaçant par une exigence de séparation fonctionnelle.
En ce qui concerne les organisations altruistes en matière de données, les obligations de transparence et de reporting seraient supprimées.
Règlement FFDR : un seul principe préservé
Du règlement FFDR ne serait conservé qu’un principe : celui qui interdit les exigences de localisation des données sauf si elles sont justifiées par des motifs de sécurité publique.
Ainsi en a décidé le Collins.
Le dictionnaire britannique qualifie d’argotique (slang) ce terme qui désigne « l’usage de l’intelligence artificielle en langage naturel pour aider à l’écriture de code infomatique ». Il l’attribue à Andrej Karpathy, membre fondateur d’OpenAI et ancien directeur de l’IA de Tesla. Il a également des entrées pour vibe coder (nom) et vibe-code (verbe).
Sur la shortlist figuraient aussi, entre autres :
taskmasking
« Fait de donner une fausse impression d’être productif au bureau ».
broligarchy
« Petite clique d’hommes très riches qui exercent une influence politique ». En première ligne, les milliardaires de la tech présents à l’investiture de Donald Trump pour son deuxième mandat de président des États-Unis.
clanker
« Terme péjoratif pour un ordinateur, un robot ou une source d’intelligence artificielle ». Il trouve son origine dans la franchise Star Wars et dérive du nom clank, qui désigne un cliquetis, un « bruit sec et métallique »
Les « mots de l’année » du Collins ont régulièrement trait aux technologies :
Geek en 2013 (Bitcoin et phablet étaient sur la shortlist)
Fake news en 2017
NFT en 2021 (crypto, metaverse et hybrid working étaient sur la shortlist)
AI en 2023
Je prompte, tu promptes, il prompte…
En France, les dictionnaires de référence n’ont pas encore intégré le vibe coding.
Parmi les mots nouveaux du Petit Robert 2026 (publié en mai 2025) figure l’hypertrucage.
Cette recommandation officielle pour « deepfake » vient du Canada, mais elle « se fait une place en français », nous assure-t-on. Preuve en serait de son emploi dans la version française de l’AI Act.
En parallèle, le mot hallucination voit son sens enrichi (« réponse fausse produite par une intelligence artificielle générative, avec une apparence de vérité »).
Le Petit Robert 2026 a également accueilli « apprentissage profond » (recommandation officielle pour deep learning), « clonage de voix »… et le verbe prompter.
Le substantif prompt était arrivé l’année précédente. Comme « solutionnisme (technologique) »/ »technosolutionnisme« , défini comme une « idéologie qui consiste à rechercher des solutions technologiques aux problèmes (sociaux, écologiques, etc.) sans en examiner les causes profondes ».
L’édition 2024 du Petit Robert avait accueilli métavers et minage (au sens de « validation, en échange d’une rémunération, d’un ensemble de transactions effectuées en cryptomonnaie avant inscription sur une blockchain »). Ainsi que disquette, au sens (familier) de « phrase, formule peu flatteuse, souvent lourde, destinée à séduire quelqu’un » (ou de « parole trompeuse ; mensonge »).
Le modèle de langage est entré dans le Petit Larousse
« Prompter » n’est pas encore dans le Petit Larousse, mais « prompt » y est entré cette année. Comme « modèle de langage« . Et l’adjectif haptique, se référant à une « technologie qui reproduit en temps réel la sensation du toucher dans un environnement virtuel »).
L’édition 2025 du Petit Larousse avait accueilli les noms bot et cyberattaque, l’expression « détox digitale » et le verbe cracker (« faire sauter illégalement les dispositifs de protection d’un système informatique »), venu compléter le substantif cracke(u)r. En 2024, « instagrammable », entre autres, avait fait son entrée.
Intelligence artificielle, automatisation et intégration multiplateforme : les solutions de travail collaboratif changent de dimension. Pour les managers IT, ces évolutions représentent à la fois une opportunité de productivité et un défi d’intégration.
« Bleu et S3NS existent grâce à la circulaire ‘cloud au centre’. […] EDF ne fait que déployer la stratégie de l’État voulue par les ministres de l’époque.«
Alain Garnier, patron de Jamespot, exprime un certain fatalisme quant à la décision du groupe industriel de recourir à ces deux fournisseurs dans la perspective de compléter son cloud privé.
Yann Lechelle, ancien DG de Scaleway, lui fait écho. Il voit, en Bleu et S3NS, des joint-ventures « coercitives » au bénéfice du modèle « cloud de confiance » annoncé en 2021 par Bruno Le Maire. « Le montage répond au cahier des charges qui n’apporte qu’une réponse (très) partielle à notre situation« , ajoute l’intéressé. Non sans affirmer que si la souveraineté de la donnée est garantie (en supposant que la qualification SecNumCloud soit atteinte), la souveraineté technologique ne l’est pas.
SecNumCloud ne résout pas tout…
On retrouve ce discours chez Alain Issarni. « Comment parler de souveraineté quand la technologie sous-jacente reste à ce point contrôlée par les GAFAM ? » se demande l’ancien patron de NumSpot. EDF est, estime-t-il, dans la lignée de l’État français, « qui, sur le Health Data Hub, a refusé pendant 5 ans toute sortie d’Azure« . Il redoute que le groupe tombe dans « le même piège » que l’US Navy, qui a récemment admis qu’il lui faudrait 3 ans pour sortir du cloud de Microsoft, faute de réversibilité réelle.
Une qualification SecNumCloud ne suffit pas à effacer les dépendances structurelles, clame Alain Issarni : que se passe-t-il si Google ou Microsoft décide de couper les mises à jour ? Et comment assurer la souveraineté des « escortes numériques » (accès niveau 3), alors même que le département de la Défense des États-Unis a condamné ce modèle, jugeant Microsoft incapable d’en assurer le contrôle ?
… notamment l’exposition au FISA
« Le plan que j’imaginais se met en place« , commente Tariq Krim. Le fondateur de Netvibes et ancien vice-président du Conseil national du numérique fait référence à un billet qu’il avait publié en juin 2025 : « Comment l’État a confisqué le marché de la souveraineté numérique ».
Dns ce billet, Tariq Krim postule qu’à la fin du premier mandat d’Emmanuel Macron, trois crises (« Covid, polarisation Trump I et émotion autour de l’hébergement du HDH chez Microsoft ») ont servi de prétexte à l’État pour reprendre la main sur la « souveraineté » en écartant les acteurs historiques.
Un glissement sémantique de « souveraineté numérique » à « cloud de confiance » a neutralisé la dimension géopolitique. Trois pôles ont alors façonné la doctrine actuelle, « chacun selon son intérêt » :
La DGE et l’ANSSI ont élaboré SecNumCloud, qui a verrouillé l’accès au marché
Bercy a suivi les recommandations des grands groupes, qui réclamaient un Office 365 souverain
La présidence de la République souhaite continuer à soutenir une start-up nation très dépendante des GAFAM
Le « cloud de confiance », tel que promu par l’État, ne protège pas du FISA (Foreign Intelligence Surveillance Act), déclare Tariq Krim. Il rappelle la récente extension de la portée de cette loi américaine, qui englobe désormais la surveillance des infrastructures en plus de tout logiciel connecté à un réseau, y compris lorsqu’il est déployé sur site. Lors d’une audition au Sénat, l’ANSSI a expliqué disposer d’une solution pour garantir une immunité, mais elle n’en a pas fait de démo publique.
Michel-Marie Maudet fait remarquer qu’EDF lui-même met des guillemets autour de « cloud de confiance ». « Ce n’est pas anodin« , affirme le directeur général de LINAGORA. Il regrette à la fois, un « message désastreux envoyé au marché » et une « erreur stratégique majeure » pour le CSF « Logiciels et solutions numériques de confiance ».
Parler d’un marché des solutions de gestion du travail collaboratif a-t-il encore un sens ?
Gartner le fait encore dans le cadre de son Magic Quadrant. L’an dernier, il avait toutefois reconnu que les frontières s’estompaient avec des offres issues de segments adjacents (gestion de projets, intranets, outils de développement, suites bureautiques cloud…) tendant à développer de telles capacités.
La même dynamique est évoquée cette année, mais dans le sens inverse : à mesure que l’IA les gagne, les solutions de gestion du travail collaboratif entrent en concurrence avec des applications métier qui relèvent d’autres segments dans la nomenclature du cabinet américain.
Ce phénomène est aussi porté par la multiplication de ce que Gartner appelle des « accélérateurs de cas d’usage ». En quelque sorte, des kits de démarrage associant modèles de données, workflows et configurations prêts à l’emploi. Une proposition de valeur qui réduisent, tout du moins sur le papier, le besoin en applications spécialisées.
9 fournisseurs… tous « leaders » ou presque
D’une année à l’autre, les critères d’inclusion au Magic Quadrant ont peu évolué. Sur le volet fonctionnel, il fallait toujours, dans les grandes lignes, couvrir au minimum les aspects planification, collaboration (y compris création de contenu), workflows et automatisation, reporting et analytics, en fournissant également lesdits « accélérateurs de cas d’usage ». Un élément s’est ajouté : « assistance intelligente ». Y sont regroupées des capacités fondées sur l’IA générative, dont la création et l’édition de contenu, l’aide à l’utilisation des produits et l’optimisation de workflows.
Les offreurs sont évalués sur deux axes. L’un prospectif (« vision »), centré sur les stratégies (sectorielle, géographique, commerciale, marketing, produit…). L’autre censé refléter la capacité à répondre effectivement à la demande (« exécution » : expérience client, performance avant-vente, qualité des produits/services…).
Les 9 fournisseurs classés sont les mêmes que l’an dernier. En 2024, ils étaient 5 dans le carré des « leaders »… et les 4 autres n’en étaient pas si loin. Un an plus tard, ils sont 7 « leaders » et les 2 autres en sont encore plus proches.
La situation sur l’axe « exécution » :
Rang
Fournisseur
Évolution annuelle
1
monday.com
+1
2
Smartsheet
– 1
3
Asana
=
4
Adobe
=
5
Airtable
+ 1
6
Wrike
– 1
7
Atlassian
=
8
ClickUp
=
9
Quickbase
=
L’expérience client et la qualité des produits ont eu un poids élevé dans la notation. La viabilité (santé financière et probabilité d’investissement continu dans la solution), un poids moyen. L’exécution commerciale et marketing, un poids bas.
Sur l’axe « vision » :
Rang
Fournisseur
Évolution annuelle
1
monday.com
=
2
Asana
=
3
Smartsheet
=
4
Airtable
=
5
Wrike
=
6
ClickUp
+ 1
7
Quickbase
+ 2
8
Atlassian
=
9
Adobe
– 3
La stratégie produit a eu un poids élevé dans la notation. L’innovation, un poids moyen. La compréhension du marché, un poids bas, comme les stratégies commerciale, marketing et géographique. La stratégie sectorielle n’a pas été notée.
Du channel aux solutions sectorielles, des éléments « en développement » chez Airtable
Airtable se distingue autant sur la composante low-code que sur la scalabilité de son socle HyperDB. Gartner salue aussi l’innovation en matière d’IA, avec une approche associant chatbot global et agents embarqués au sein des applications.
À grande échelle, il peut s’avérer difficile de maintenir une gouvernance cohérente des applications personnalisés. Attention aussi à la courbe d’apprentissage pour qui est néophyte des concepts de base de données. Gartner souligne aussi qu’Airtable développe actuellement sa présence hors de son cœur de marché (présence physique, channel, datacenters) et sur les solutions sectorielles.
Avec Asana, attention à la courbe d’apprentissage
Bon point pour Asana sur la notoriété de marque, la communauté et le taux d’adoption pour certains usages (planification du travail, en particulier). Gartner apprécie aussi l’architecture Work Graph, entre le modèle de données qui la porte et les agents IA qui y sont greffés. Il note également l’exhaustivité de l’offre sur la gestion de tâches et des projets ainsi que sur le suivi d’objectifs et résultats.
De par son exhaustivité, Asana est susceptible de présenter une certaine courbe d’apprentissage. Gartner relève aussi une marge de progression sur l’approche sectorielle : certains cas d’usage peuvent ne pas être efficacement couverts. Le cabinet américain remarque également que la croissance des revenus d’Asana a ralenti, tandis que l’effectif n’a pas augmenté. Potentiellement le signe, estime-t-il, d’une dépendance au modèle product-led (le produit comme moyen privilégié d’acquisition, par opposition au sales-led ou au marketing-led).
Atlassian : des faiblesses sur la gestion des actifs et du temps
Atlassian se distingue par son niveau de présence sur le marché ; et par sa notoriété, notamment chez les développeurs et l’IT. Il a aussi pour lui son écosystème (partenaires, marketplace fournie, certification de produits tiers…). Et sa tarification, jugée transparente et compétitive.
Certains produits ayant tendance à se chevaucher (Gartner cite Trello et Jira), l’offre d’Atlassian peut s’avérer difficile à appréhender. S’y ajoute une approche commerciale et marketing moins développée que chez les concurrents sur l’aspect sectoriel. Au niveau fonctionnel, il existe des faiblesses sur la gestion d’actifs, l’allocation de ressources et le suivi du temps.
ClickUp, pas déployé à la même échelle que les concurrents directs
Gartner note la croissance notable de la clientèle de ClickUp et du nombre d’utilisateurs actifs. Il souligne aussi la facilité d’utilisation, tant au niveau de l’interface que de par la flexibilité offerte sur la gestion de tâches, avec une configuration initiale minimale. Bon point également sur la convergence « travail-connaissances-communication », qui minimise le changement de contexte.
Hors de l’Union européenne, la présence géographique de ClickUp est limité. Ses plus gros déploiements sont plus petits que ceux des concurrents directs (moindres volumes de données et d’utilisateurs simultanés). Quant au réseau de partenaires, il est « en évolution », tout comme le ciblage de secteurs et de métiers (pas de programme commercial dédié).
Tarification, cœur fonctionnel… Les contreparties des « accélérateurs » de monday.com
monday.com jouit d’une notoriété portée par son niveau d’offre gratuit, son UX jugée intuitive et son ciblage efficace de relais d’influence dans plusieurs secteurs. Autre élément de distinction : ses « accélérateurs » (CRM, développement logiciel, service management…), qui comment à concurrencer des apps métier. Gartner apprécie aussi les investissements dans la gestion du cycle de vie des données et la personnalisation par API.
Point fort, les « accélérateurs » sont en même temps susceptibles de limiter les investissements dans le cœur fonctionnel. Ils entraînent aussi, avec leur tarification spécifique, une complexité pour qui recherche une solution multiusage. Gartner recommande par ailleurs de vérifier la disponibilité d’expertise sur les plaques géographiques où monday.com est essentiellement en indirect.
Smartsheet : les complexités du nouveau modèle de licence
Bon point sur le plan fonctionnel pour Smartsheet, qui s’avère adapté aux workflows complexes nécessitant de l’élasticité. Les briques de gestion de projet, de gestion de ressources et de reporting tendent à être appréciées des grandes entreprises. Autres points forts : la notoriété (Smartsheet est le fournisseur le plus souvent benchmarké dans les requêtes faites à Gartner) et la partie collaboration de contenu (versioning, pistes d’audit, fonctionnalité de révision avec fils de discussion).
L’an dernier, Gartner rappelait que Smartsheet allait redevenir une entreprise privée et appelait à porter attention aux impacts sur la visibilité de la stratégie, de la roadmap et des résultats. Il n’en dit pas moins cette année, même si la transition a été bouclée depuis (janvier 2025). Dans cet intervalle, la croissance des revenus et de l’effectif a été plus faible que chez les principaux concurrents. Quant à la transition vers le modèle à l’abonnement par utilisateur, elle a engendré des complexités de réconciliation et de gestion des licences ; complexités renforcées par la suppression de l’option free collaborator.
La marketplace de Wrike, en défaut de capacités-clés
L’acquisition de Klaxoon a renforcé les capacités de Wrike sur la collaboration visuelle et ouvert la voie au développement d’agents IA autour de cette brique. Gartner apprécie aussi les possibilités en matière de gestion des données (synchronisation des systèmes tiers, moteur no code avec connecteurs préconstruits…). Et la tarification, jugée transparente, compétitive et particulièrement accessible aux petites équipes comme aux déploiements multiusages.
Comme chez Smartsheet, la dynamique business n’est pas positive, tant sur la croissance des revenus et de la clientèle que sur la visibilité globale. La présence physique reste limitée dans certaines régions géographiques et le réseau de partenaires n’est pas le plus étendu sur ce marché. Des services-clés manquent par ailleurs sur la marketplace (publication en self-service, évaluations et discussions d’utilisateurs).
L’IA générative n’est plus seulement utilisée dans la phase de développement des malwares : elle l’est aussi lors de leur exploitation.
Google s’en fait l’écho… et en donne 5 exemples. Parmi eux, un dropper VBScript qu’il a appelé PROMPTFLUX.
Un dropper réécrit son code grâce à Gemini
Identifié début juin, le malware fait appel à la dernière version de Gemini Flash 1.5 – via l’API, la clé étant intégrée en dur – pour l’aider à obscurcir son code. Et ainsi maximiser ses chances d’éviter la détection par les antivirus.
Des variants ont été découverts. Dont un qui, toutes les heures, demande à Gemini de réécrire l’intégralité de son code source. Et de sauvegarder chaque nouvelle version dans le dossier de démarrage, afin d’établir une persistance.
PROMPTFLUX a aussi les attributs d’un ver, capable en l’occurrence de se propager sur des partages réseau et des supports amovibles. Il ne semble cependant pas à même de compromettre un réseau ou même un appareil. Certaines de ses fonctions sont effectivement commentées, dont celle par laquelle il modifie son code grâce aux éléments fournis par Gemini. Mais la présence de cette fonction, comme d’ailleurs de la journalisation des réponses IA, illustre clairement sa finalité.
Un dataminer génère des commandes Windows via Qwen
Autre exemple : PROMPTSTEAL. Lui aussi identifié en juin, il a été utilisé par APT28 (groupe à la solde de la Russie) contre l’Ukraine.
Il s’agit d’un dataminer Python déguisé en programme de création d’images. Il contient un script compilé qui fait appel à Qwen2.5-Coder-32B-Instruct via l’API Hugging Face, probablement grâce à un jeton volé. Objectif : générer des commandes Windows destinées à collecter des infos système et à copier des documents dans un dossier spécifique en vue des les exfiltrer.
Quand les outils IA de l’hôte ciblé servent à rechercher des secrets
Google évoque aussi PROMPTLOCK, un ransomware codé en Go. Jugé expérimental, il exploite un LLM (non spécifié) pour générer des scripts Lua. Il inclut des capacités de découverte de système de fichiers, d’exfiltration de données et de chiffrement sur Windows comme sur Linux.
FRUITSHELL et QUIETVAULT, au contraire, on été observés dans des opérations.
Le premier, disponible publiquement, est un reverseshell écrit en PowerShell. Il embarque des prompts censés lui éviter la détection par les systèmes de sécurité reposant sur des LLM.
Le second, codé en JavaScript, est censé exfiltrer des tokens GitHub et NPM en les poussant sur un repo public. Pour recherche d’autres secrets, il se nourrit des outils IA en ligne de commande disponibles sur l’hôte.
Prière de ne plus faire passer Comet pour Google Chrome.
Amazon l’intime à Perplexity… entre autres doléances consignées dans une lettre de mise en demeure rendue publique.
En toile de fond, la confrontation de deux conceptions du commerce agentique, à cheval entre liberté et protection du consommateur.
(In)satisfaction client et (in)sécurité
Amazon appelle Perplexity à cesser, sans délai, d’utiliser les agents IA de son navigateur Comet pour « s’introduire secrètement » dans son périmètre e-commerce. Il lui demande d’identifier lesdits agents de manière transparente, au nom du droit des fournisseurs de services à superviser l’activité agentique.
Ce droit de supervision doit permettre d’empêcher les comportements qui dégradent l’expérience d’achat et la confiance du client avec, tout en créant des risques pour ses données.
Avec la technologie de Perplexity, l’expérience d’achat n’est pas adéquate, affirme Amazon : Comet ne peut pas sélectionner le meilleur prix, la meilleure méthode de livraison et les recommandations. Il ne donne pas non plus la possibilité d’ajouter des produits à des commandes déjà effectuées.
Quant à la sécurité des données des clients, c’est portes ouvertes, d’après Amazon. Preuve en serait des conditions d’utilisation et la notice de confidentialité de Perplexity, qui lui donnent le droit de collecter mots de passe, clés de sécurité, méthodes de paiement, historiques d’achats et autres données sensibles… tout en excluant toute responsabilité.
Amazon pointe des contournements répétés
Les premiers faits que le groupe américain juge répréhensibles remontent au moins à novembre 2024. À partir de là, à travers la fonctionnalité « Buy with Pro », des commandes ont été réalisées au nom d’utilisateurs, en exploitant une poignée de comptes Amazon – dont des comptes Prime – gérés par Perplexity.
En plus de violer les conditions d’utilisation de Prime, cette pratique aurait engendré une mauvaise expérience client. Par exemple en compliquant les retours de produits.
Perplexity avait fini par accepter d’y mettre un terme. Et, plus globalement, de ne pas déployer d’autres agents dans le Store jusqu’à négociation d’un accord. Il aurait, depuis, renié cette promesse, en changeant de tactique, avec des agents qui se connectent aux comptes des utilisateurs.
Amazon explique avoir découvert cette activité en août. N’étant pas parvenu à faire entendre raison à Perplexity, il avait coupé l’accès à Comet… qui, dans les 24 heures, avait contourné le blocage. Les relances ultérieures n’ont pas plus porté leurs fruits, Perplexity continuant à « déguiser » ses agents en instances Chrome.
Pour Amazon, cette opacité est d’autant plus troublante que les preuves de vulnérabilité de Comet aux injections de prompts se sont accumulées ces derniers temps.
Le groupe américain regrette aussi d’avoir dû dédier des ressources aux investigations et à implémentation de contre-mesures. Soulignant que le risque s’accroîtra probablement maintenant que Comet est ouvert au grand public, il réclame des mesures injonctives et une compensation financière. Non sans prétendre qu’il y a infraction aux Codes pénaux des États-Unis et de Californie.
Perplexity brandit la liberté du consommateur
En réponse, Perplexity ne mâche pas ses mots : cette offensive juridique est « une menace pour tous les internautes ».
De son avis, Amazon devrait se montrer favorable à Comet : une expérience d’achat plus simple signifie davantage de transactions et des clients plus heureux. S’il ne réagit pas ainsi, c’est parce que « son intérêt est de vous servir de la publicité, des résultats sponsorisés, et influencer vos décisions d’achat avec […] des offres embrouillantes ».
Rappelant en filigrane que les authentifiants qu’utilise Comet ne sont jamais stockés sur ses serveurs, Perplexity appelle à ne pas confondre « expérience du consommateur » avec « exploitation du consommateur ». Les utilisateurs veulent des assistants IA qui travaillent pour eux pour pour personne d’autre, ajoute-t-il. Non sans laisser comprendre qu’Amazon, dans sa volonté de travailler à terme avec des fournisseurs d’agents, chercherait d’abord à en encadrer le fonctionnement.
Or, l’IA agentique est justement l’occasion, pour les utilisateurs, de reprendre le contrôle de leurs expériences en ligne, veut croire Perplexity. En ce sens, et au nom de la liberté de choix, une entreprise n’aurait aucunement le droit de discriminer les utilisateurs sur la base des IA qu’ils choisissent pour les représenter.
Perplexity veut croire que de telles aspirations font de lui une cible idéale à intimider. Il invite en tout cas Amazon à ne pas oublier les combats qu’il a lui-même menés pour en arriver là, précisément au nom de la liberté du consommateur et avec la même conviction d’avoir un « produit qui change le monde ». Et de conclure : « Le commerce agentique est une évolution naturelle et les gens en sont demandeurs. Nous exigeons de pouvoir l’offrir.«
Un gatekeeper remis en cause ?
Certains auront fait remarquer que Perplexity est gonflé, vu le contenu de ses propres conditions d’utilisation (l’usage de spiders, de crawlers, de scrapers et autres robots ou « processus automatisés » y est très largement proscrit).
D’autres se réjouissent au contraire de cette résistance, y voyant un moyen de remettre en cause le monopole qu’Amazon aurait sur la recherche de produits sur sa marketplace. Et par là même la position de force dans laquelle il est vis-à-vis des vendeurs tiers.
En intercalant des IA entre lui et le client, Amazon verrait plus globalement son rôle de gatekeeper un tant soit peu remis en cause. Au risque de perdre, infine, du business.
Entre autres arguments, circule aussi celui selon lequel les logiciels avec lesquels l’utilisateur accède à un service ne regardent que lui. À l’inverse, certains estiment que tout propriétaire de site(s) e-commerce doit pouvoir ne pas autoriser des IA dans son écosystème.
Databricks voisinera bientôt avec Snowflake dans le périmètre SAP Business Data Cloud.
L’éditeur allemand avait lancé cette offre SaaS en février 2025. La promesse : pouvoir créer des produits de données entièrement gérés, autour d’un catalogue unifié.
Datasphere, Analytics Cloud et Business Warehouse en sont les principales composantes. Avec, par-dessus, la brique Insight apps (devenue Intelligent applications) : des apps low code embarquant leurs dashboards et leurs modèles sémantiques.
Databricks intégré depuis mai 2025 ; Snowflake pour début 2026
À cet assemblage s’est ajouté, début mai, SAP Databricks*, une édition spécifique déployée en tant qu’extension Business Data Cloud. Puis est arrivé un connecteur (Business Data Cloud Connect) pour faire la jonction avec les instances Databricks externes – là aussi sans ETL, grâce notamment aux partages Delta.
Le même type d’approche va être mis en place avec Snowflake. L’édition spécifique est prévue pour le premier trimestre 2026. Le connecteur, pour le premier semestre.
En attendant, l’éventail des sources de données s’est élargi avec, en particulier, SAP Customer Data Plaform (intégré en juillet) et SuccessFactors (octobre). L’offre a par ailleurs été déployée sur Azure (4 régions dont Amsterdam) et GCP (4 régions dont Francfort) en plus d’AWS (7 régions dont Francfort).
SAP étend ainsi le terrain de jeu potentiel de Joule… et probablement de ses technologies d’automatisation, comme Signavio.
* SAP Databricks fait l’impasse sur certaines fonctionnalités (la fédération de lakehouses, entre autres), tandis que des briques sont remplacées par celles du groupe allemand (la BI par Analytics Cloud, par exemple).
Lorsque vous créez vos index, pensez aux vecteurs binaires.
Une forme de consensus s’est dessinée à ce sujet sur Hacker News, en réaction au retour d’expérience d’un ingénieur américain. L’intéressé y pointe les limites de pgvector… et suggère de lui préférer une base de données vectorielle.
À chaque index ses inconvénients
L’extension donne, rappelle-t-il, le choix entre deux types d’index : IVFFlat (Inverted File with Flat quantization) et HNSW (Hierarchical Navigable Small World). Le premier partitionne l’espace vectoriel en clusters. Le second construit un graphe.
Avec IVFFlat, la création d’index est plus rapide, en plus d’une consommation mémoire inférieure. Et les performances sont acceptables pour de nombreux cas d’usage.
Il est toutefois impératif de spécifier au préalable le nombre de clusters. Ce nombre a une nette influence sur la latence des requêtes. Comme sur la qualité du rappel, qui peut par ailleurs varier en fonction de la distribution des données.
Avec HNSW, le rappel est meilleur sur la plupart des datasets. La performances des requêtes est globalement plus consistante et le système passe bien à l’échelle.
La construction des index nécessite cependant beaucoup de mémoire et peut se révéler lente (plusieurs heures quand on atteint des millions de vecteurs).
Reconstructions et mises à jour
Avec IVFFlat, la clusterisation de nouveaux vecteurs se base sur la structure existante (distribution telle qu’elle était quand on a construit l’index). Avec le temps, il peut en résulter une sous-optimisation. D’où la nécessité de reconstruire régulièrement l’index. Et donc de tolérer une dégradation de la qualité de recherche voire une indisponibilité. Ou bien d’accepter de mettre en place un mécanisme de contournement, tels le provisionnement d’une grande quantité de RAM ou la mise en place d’un index séparé depuis lequel on réalise un échange atomique. S’y ajoute le besoin de gérer les insertions effectuées dans ce laps de temps.
Avec HNSW, chaque insertion exige de mettre à jour le graphe. Donc d’effectuer une traversée pour intégrer le nœud et actualiser les connexions, au risque d’engendrer des contentions de verrou si le taux d’écritures est suffisamment élevé.
Le dilemme du filtrage des recherches
Autre aspect à prendre en compte : les métadonnées, stockées dans d’autres tables ou tout du moins dans d’autres colonnes, et qu’il faut garder synchronisées. Pas si évident avec des reconstructions qui peuvent durer.
Quant aux filtres, faut-il les appliquer avant ou après la recherche vectorielle ? L’une et l’autre méthode ont leurs avantages… et leurs inconvénients.
L’option « avant » fonctionne bien lorsque le filtre est très sélectif. Elle assure une bonne qualité de rappel (k résultats garantis), mais la recherche peut s’avérer lente.
L’option « après » est au contraire adaptée aux filtres permissifs. Elle permet une recherche rapide, mais la qualité de rappel est variable (souvent 0 résultat ou en tout cas moins que k).
D’autres questions se posent si on souhaite appliquer plusieurs filtres. Dans quel ordre le faire ? Faut-il mélanger les deux options ?… PostgreSQL a bien un planificateur, mais pas optimal, son modèle de coût n’ayant pas été élaboré pour la recherche vectorielle. Les choses ne s’arrangent pas à mesure qu’on insère de nouveaux vecteurs, à moins d’enclencher un ANALYZE, qui coûte des ressources, sans pouvoir appréhender totalement la distribution des données.
On en arrive ainsi à devoir réécrire les requêtes pour différents types d’utilisateurs, partitionner les données dans des tables distinctes ou encore à filtrer dans le code de l’application quitte à récupérer plus de données que nécessaire.
L’option pgvectorscale
Les bases de données vectorielles ont résolu ces problèmes, affirme l’ingénieur : planification adaptée, recherche hybride native, indexation en temps réel sans pics de conso mémoire, scaling et monitoring spécifiques… Il mentionne OpenSearch, dont le plug-in k-NN permet de spécifier la stratégie de filtrage ; Pinecone, qui gère automatiquement la sélectivité des filtres ; Weaviate, qui embarque des optimisations pour les patterns de filtrage communs. Et d’appeler à mesurer le coût d’opportunité de pgvector ; en l’occurrence, le temps qu’on consacre à sa maintenance plutôt qu’à d’autres projets.
Il y a sinon, dans le domaine open source, pgvectorscale. Cette version « enrichie » de pgvector ajoute un nouveau type d’index basé sur l’algorithme DiskANN de Microsoft et plus efficace en mémoire. Elle apporte également une méthode de compression améliorée par rapport à la quantification binaire standard.
Il s’agit néanmoins d’une dépendance supplémentaire à gérer et elle n’est pas disponible, entre autres, pour RDS.
Discourse allie pgvector et vecteurs binaires
Le dilemme entre pré- et post-filtrage a été résolu dans la version 0.8.0 avec les scans itératifs, fait remarquer ingénieur chez Discourse. Son entreprise, affirme-t-il, utilise pgvector en production, sur des milliers de bases de données.
Un de ses pairs, travaillant pour un fournisseur de solutions cyber, s’en étonne : à une telle échelle, dans sa société, PostgreSQL a montré ses limites. Une base de données spécialisée (Vespa) lui a donc été préférée. Elle opère un map-reduce sur tous les nœuds de graphe, limitant le nombre de traversées à effectuer.
Si Discourse n’a pas ce souci, c’est parce que chaque forum a sa base de données. Il existe donc une sorte de « sharding gratuit », où chaque instance a en moyenne moins d’un million de topics.
L’entreprise utilise aussi beaucoup la quantification : avant indexation, elle convertir les vecteurs à virgule flottante en vecteurs binaires (chaque dimension est réduite à 1 bit). La majeure partie de leur utilisée est conservée, et la qualité de rappel avec.
OpenAI a un nouveau fournisseur d’infrastructure : AWS.
Le créateur de ChatGPT s’est engagé dans un contrat à 38 Md$. Se projetant sur un horizon de 7 ans, il évoque l’accès à « des centaines de milliers » de GPU et une possibilité d’extension à « des dizaines de millions » de CPU.
L’annonce mentionne les configurations UltraServer dotées en NVIDIA GB200 et GB300. Pas celles qui exploitent les puces d’AWS. Aucun timing n’est communiqué, si ce n’est l’ambition d’avoir déployé toute la « capacité cible » (non spécifiée) avant fin 2026, pour ensuite aller éventuellement au-delà.
Quitte avec Microsoft, OpenAI promet des montagnes de gigawatts
En toile de fond, l’accord signé la semaine passée avec Microsoft. Il a permis la transformation d’OpenAI en PBC (public benefit corporation, société à but lucratif encadrée par une mission d’intérêt général).
Le deal apparaît globalement bénéfique à Microsoft. Notamment en ce qu’il conserve 27 % du capital de la PBC (participation valorisée à 135 Md$) et qu’OpenAI s’est engagé à investir 250 Md$ dans Azure jusqu’en 2032.
Les concessions ont été à la hauteur de l’enjeu. Cette restructuration met effectivement un terme au plafonnement des profits d’OpenAI, ouvrant la voie à de nouvelles levées de capitaux. Elle élimine aussi les contraintes sur le choix des fournisseurs d’infrastructure, Microsoft ayant renoncé à son droit de premier refus.
Dans ce contexte, Sam Altman n’a pas tardé à annoncer l’ambition d’investir 1400 Md$ pour développer 30 GW de capacité. L’intéressé espère pouvoir, à terme, ajouter 1 GW par semaine, en réduisant le coût du gigawatt à 20 Md$ (contre 50 à 60 Md$, si on en croit les estimations du patron de NVIDIA).
CoreWeave, Google, Oracle… La diversification avait déjà démarré
Microsoft fut le fournisseur d’infrastructure exclusif d’OpenAI jusqu’en janvier 2025. Avec l’annonce de Stargate, le partenariat avait été révisé : OpenAI allait pouvoir acquérir de la capacité supplémentaire auprès d’autres acteurs.
Un contrat de 5 ans avec Coreweave avait été officialisé en mars, pour un montant de 11,9 Md$ (enveloppé portée depuis à 22 Md$). Dans ce cadre, OpenAI a obtenu pour 350 M$ en actions Coreweave.
En mai, OpenAI avait signé avec Google. On ne sait pas grand-chose du deal, sinon qu’il concerne à la fois ChatGPT et l’API.
En juillet, un accord fut annoncé avec Oracle pour développer 4,5 GW de capacité supplémentaire dans le cadre de l’initiative Stargate. Ce sur trois nouveaux sites, au Nouveau-Mexique, au Texas et « dans le Midwest ». On a appris, depuis, qu’il s’agissait d’un contrat à 300 Md$ sur 5 ans, censé démarrer en 2027.
De 4,5 GW, on est passé à environ 7 GW au mois de septembre avec l’officialisation de deux autres sites (Ohio, Texas) que doit porter SoftBank. Ils sont censés pouvoir atteindre 1,5 GW sous 18 mois. Cela s’ajoute au premier datacenter Stargate, en service depuis mi-2025 à Abilene (Texas) et sujet à une extension de 600 MW.
Louer plutôt qu’acheter, et concevoir ses propres puces
Également en septembre, OpenAI a signé avec NVIDIA. Il s’est engagé à déployer au moins 10 GW de capacité. À commencer par des puces Vera Rubin (qui succèdent aux Grace Blackwell) au deuxième semestre 2026. En parallèle, NVIDIA investira jusqu’à 100 Md$ dans OpenAI.
À contre-courant du modèle actuel, ces puces seront peut-être… louées. Il se dit que NVIDIA pourrait monter une entité à cet effet. Elle achèterait ses propres GPU et des équipements réseau pour ensuite faire de la location sur 5 ans.
Parallèlement à ses contrats d’infra, OpenAI veut concevoir ses propres puces accélératrices. Il a récemment déclaré qu’elles s’incarneraient dans des racks développés par Broadcom, qui fournira les solutions de mise en réseau. Une lettre d’intention a été signée, pour 10 GW de capacité. Sans faire le lien avec l’officialisation, quelques semaines en amont par Broadcom, d’un contrat à 10 Md$…
Quand le fournisseur finance son client
Nombre de ces accords sont qualifiables de « circulaires ». Dans certains cas, parce que OpenAI est financé par des acteurs auxquels il achète du compute. Le partenariat avec Microsoft, par exemple, a suivi cette logique.
À l’inverse, il arrive qu’OpenAI finance ses fournisseurs, en échange d’une prise de participation. L’accord avec Coreweave suit ce modèle. Même chose pour celui avec AMD, annoncé début octobre. OpenAI s’est engagé à déployer 6 GW de capacité ; à commencer, au deuxième semestre 2026, par des GPU Instinct MI450. En parallèle, il pourrait acquérir jusqu’à 160 millions d’actions AMD, soit environ 10 % du capital.
Avec Oracle, il existe une forme de réciprocité plus indirecte : le montant du contrat avec OpenAI (300 Md$) pourrait couvrir ses dépenses d’exploitation à l’horizon 2030.
De la circularité, il y en a aussi dans la relation avec SoftBank. D’un côté, le groupe japonais a investi dans OpenAI (il a emmené, cette année, un tour de table de 40 Md$). De l’autre, il participe à la construction des datacenters de Stargate… sur lesquels vont tourner ChatGPT et Cie.
Les datacenters en ébullition
Intensive en capital, l’activité d’OpenAI n’est pas pour autant rentable à l’heure actuelle.
La barre des 10 Md$ d’ARR (revenu annuel récurrent) a été franchie au premier semestre 2025.
Sur cette période, les pertes auraient atteint 13,5 Md$.
Sur le seul troisième trimestre, elles auraient dépassé les 10 milliards.
Le modèle est assumé, et les fonds d’investissement continuent pour le moment à l’alimenter. Jusqu’au niveau du parc de datacenters. Témoin Blue Owl. Dans la continuité d’un accord à 20 Md$ avec Oracle dans le cadre de Stargate, le fonds américain vient de former un joint-venture avec Meta. Il en possède 80 %, en échange d’un ticket à 27 Md$ pour développer le datacenter Hyperion en Louisiane.
Les hyperscalers renforcent eux-mêmes leurs investissements dans les datacenters… et dans les sources d’énergie annexes. Les démarches de Microsoft pour relancer la centrale nucléaire de Three Mile Island (Pennsylvanie) en sont emblématiques. L’entreprise s’est engagée à acheter, pour 20 ans à partir de 2028, l’intégralité de la production, estimée à 835 MW. Auparavant, AWS avait mis la main sur un campus de datacenters jouxtant une centrale nucléaire dont il entend exploiter 960 MW.
Aux États-Unis, les investissements dans les datacenterspourraient pour la première fois dépasser, en 2025, l’investissement dans l’immobilier de bureau.
D’après de récentes statistiques du département du Commerce, les achats de logiciels et d’équipements informatiques compte pour un quart de la croissance économique.
Connexion
