La Commission européenne lance trois enquêtes de marché sur les offres d’AWS et Microsoft Azure dans le cadre du Digital Markets Act (DMA) dont l’objectif est de limiter le pouvoir des grandes entreprises technologiques, désignées comme « contrôleurs d’accès » , et de garantir des conditions de concurrence équitables pour les rivaux plus petits.
Les investigations se décomposent en trois volets distincts :
Désignation en tant que « contrôleurs d’accès ». A travers deux enquêtes, la Commission va évaluer si Amazon Web Services (AWS) et Microsoft Azure doivent être désignés comme « contrôleurs d’accès » pour leurs services cloud.Si cette désignation est confirmée, ces services cloud seraient ajoutés à la liste des services de plateforme essentiels pour lesquels Amazon et Microsoft sont déjà considérés comme contrôleurs d’accès.
Efficacité du DMA dans le cloud. Cette troisième enquête vise à évaluer l’efficacité des obligations actuelles du DMA pour lutter contre les pratiques déloyales ou anticoncurrentielles dans le secteur du Cloud. L’examen porte notamment sur les obstacles à l’interopérabilité, l’accès limité aux données pour les entreprises utilisatrices, les services de vente liée et de groupage, ainsi que les clauses contractuelles potentiellement déséquilibrées.
Le DMA, entré en vigueur en 2023, définit un « contrôleur d’accès » comme une entreprise proposant un service de plateforme essentiel, avec plus de 45 millions d’utilisateurs actifs mensuels et une capitalisation boursière d’au moins 75 milliards € (86,87 milliards $). AWS est le plus grand fournisseur de cloud au niveau mondial, avec 30 %de parts de marché, suivi par Microsoft Azure (20%) et Google Cloud (13 %).
Les entreprises désignées comme « contrôleurs d’accès » sont tenues de rendre leurs services interopérables avec ceux de leurs concurrents et ne peuvent pas favoriser leurs propres services au détriment de ceux de leurs rivaux. En cas de violation du DMA, les entreprises encourent des amendes pouvant atteindre 10 % de leur chiffre d’affaires annuel mondial.
La cheffe de l’antitrust de l’UE, Teresa Ribera, a déclaré que la Commission cherchera également à déterminer si « les règles existantes du règlement sur les marchés numériques doivent être mises à jour afin que l’Europe puisse suivre le rythme de l’évolution rapide des pratiques dans le secteur de l’informatique en nuage ».
Un porte-parole de Microsoft a indiqué que l'entreprise était prête à contribuer à l'enquête.
Du côté d'AWS, on estime que « désigner les fournisseurs de cloud comme contrôleurs d'accès ne vaut pas le risque d'étouffer l'invention ou d'augmenter les coûts pour les entreprises européennes ».
La Commission veut conclure les deux enquêtes sur la désignation d’AWS et Azure dans un délai de 12 mois. L'enquête sur l'application du DMA aux marchés du cloud donnera lieu à la publication d'un rapport final dans un délai de 18 mois.
Et le plus puissant des supercalculateurs est… toujours El Capitan.
À 5 mois d’intervalle, les positions sont restées figées dans le peloton de tête du TOP500. Pour trouver le premier mouvement, il faut descendre à la 15e place. En juin, elle était occupée par un système localisé au Japon (ABCI 3.0, de l’Institut national des sciences et technologies). Elle l’est désormais par un système situé aux États-Unis (Discovery 6, d’ExxonMobil).
22 des supercalculateurs classés se trouvent sur le territoire français. Les voici, avec leur Rmax (performance maximale pour le plus gros problème tournant sur la machine) et leur Rpeak (performance théorique).
EXA1-HE (26e)
C'est la dernière extension du supercalculateur EXA1, localisé à Bruyères-le-Châtel (Essonne) et utilisé pour la simulation nucléaire au sein de la branche militaire du CEA. Elle a été livrée en 2024.
Architecture BullSequana XH3000 avec puces NVIDIA GH200 (72 cœurs à 3 GHz). Rmax : 90,79 petaflops (Rpeak : 171,26 Pflops) sur 548 352 cœurs. Consommation : 1,77 MW.
Les classements précédents d'EXA1-HE au TOP500 :
Juin 2024 : 17e (configuration à 389 232 cœurs)
Novembre 2024 : 22e
Juin 2025 : 23e (passage à 548 352 cœurs)
Jean Zay H100 (40e)
Extension GPU installée en 2024 sur ce supercalculateur mis en service 5 ans plus tôt à l'IDRIS (plateau de Saclay, Essonne).
Architecture BullSequana avec CPU Intel Xeon Platinum 8468 (Sapphire Rapids ; 48 cœurs à 2,1 GHz) et GPU NVIDIA H100 SXM5-80.
Rmax : 52,18 Pflops (Rpeak : 71,42 Pflops) sur 227 136 cœurs.
Les classements précédents de Jean Zay H100 au TOP500 :
Novembre 2024 : 27e
Juin 2025 : 35e
Adastra (45e)
Ce supercalculateur a été acquis par la France via GENCI en 2022 et inauguré en 2023. Il se trouve au CINES (Montpellier).
Base HPE Cray EX235a, avec CPU AMD EPYC 3e génération (64 cœurs à 2 GHz) et GPU AMD Instinct MI250X.
Rmax : 46,1 Pflops (Rpeak : 61,61 Pflops) sur 319 072 cœurs. Consommation : 921 kW.
Les classements précédents d'Adastra au TOP500 :
Juin 2022 : 10e
Novembre 2022 : 11e
Juin 2023 : 12e
Novembre 2023 : 17e
Juin 2024 : 20e
Novembre 2024 : 30e
Juin 2025 : 40e
EXA1-HF (77e)
Cette partition d'EXA1 est en service depuis 2021.
Base BullSequana XH2000, avec CPU AMD EPYC 7763 (3e génération ; 64 cœurs à 2,45 GHz).
Rmax : 23,24 Pflops (Rpeak : 31,76 Pflops) sur 810 240 cœurs. Consommation : 4,96 MW.
Les classements précédents d'EXA1-HF au TOP500 :
Juin 2022 : 17e
Novembre 2022 : 20e
Juin 2023 : 22e
Novembre 2023 : 30e
Juin 2024 : 36e
Novembre 2024 : 55e
Juin 2025 : 70e
Pangea III (104e)
Ce supercalculateur de TotalEnergies localisé à Pau est en service depuis 2019.
Base IBM Power System AC922, avec CPU POWER9 (18 cœurs à 3,45 GHz) et GPU NVIDIA Volta GV100.
Rmax : 17,86 Pflops (Rpeak : 25,03 Pflops) sur 291 024 cœurs. Consommation : 1,37 MW.
Les classements précédents de Pangea III au TOP500 :
11e puis 15e en 2019
15e puis 18e en 2020
21e puis 29e en 2021
33e puis 37e en 2022
39e puis 48e en 2023
60e puis 75e en 2024
Juin 2025 : 92e
Tera 1000-2 (146e)
Cette partition fut mise en service en 2017-2018 sur le supercalculateur Tera 1000 du CEA (localisation : Bruyères-le-Châtel).
Base BullSequana X1000, avec CPU Intel Xeon Phi 7250 (Knights Landing ; 68 cœurs à 1,4 GHz).
Rmax : 11,97 Pflops (Rpeak : 23,4 Pflops) sur 561 408 cœurs. Consommation : 3,18 MW.
Les classements précédents de Tera 1000-2 au TOP500 :
14e puis 16e en 2018
18e puis 17e en 2019
20e puis 24e en 2020
34e puis 42e en 2021
45e puis 49e en 2022
54e puis 65e en 2023
82e puis 101e en 2024
Juin 2025 : 123e
ROMEO 2025 (172e)
Supercalculateur de l'université de Reims Champagne-Ardenne, installé en 2024 et inauguré cette année.
Base BullSequana XH3000, avec puces NVIDIA GH200.
Rmax : 9,86 Pflops (Rpeak : 16,32 Pflops) sur 47 328 cœurs. Consommation : 160 kW.
Les classements précédents de ROMEO 2025 au TOP500 :
Novembre 2024 : 122e
Juin 2025 : 148e
Taranis (199e)
Supercalculateur de Météo France installé en 2020 à Toulouse et inauguré en 2021.
Base BullSequana XH2000, avec CPU AMD EPYC 7742 (2e génération ; 64 cœurs à 2,25 GHz).
Rmax : 8,19 Pflops (Rpeak : 10,32 Pflops) sur 294 912 cœurs. Consommation : 1,67 MW.
Les classements précédents de Taranis au TOP500 :
Novembre 2020 : 30e
49e puis 58e en 2021
63e puis 69e en 2022
78e puis 92e en 2023
115e puis 141e en 2024
Juin 2025 : 168e
Belenos (210e)
Supercalculateur "jumeau" de Taranis, inauguré en parallèle, également à Toulouse.
Même architecture et même configuration processeur.
Rmax : 7,68 Pflops (Rpeak : 10,47 Pflops). Consommation : 1,66 MW.
Les classements précédents de Belenos au TOP500 :
29e puis 34e en 2020
55e puis 64e en 2021
71e puis 78e en 2022
87e puis 103e en 2023
125e puis 152e en 2024
Juin 2025 : 180e
Joliot-Curie Rome (222e)
Partition du supercalculateur Joliot-Curie, installé depuis 2019 au TGCC (Bruyères-le-Châtel).
Base BullSequana XH2000, avec CPU AMD EPYC Rome 7H12 (3e génération ; 64 cœurs).
Rmax : 6,99 Pflops (Rpeak : 12,94 Pflops) sur 197 120 cœurs. Consommation : 1,44 MW.
Les classements précédents de Joliot-Curie Rome au TOP500 :
Novembre 2019 : 59e (configuration à 160 000 cœurs)
33e puis 38e en 2020 (configuration à 197 120 cœurs)
59e puis 69e en 2021
77e puis 83e en 2022
92e puis 109e en 2023
132e puis 162e en 2024
Juin 2025 : 191e
SELENA (262e)
Ce supercalculateur EDF est entré en production cette année.
Base BullSequana XH3000, avec CPU AMD EPYC 9354 (4e génération ; 32 cœurs à 3,25 GHz).
Rmax : 5,42 Pflops (Rpeak : 5,5 Pflops) sur 107 940 cœurs. Consommation : 1,16 MW.
Topaze GPU (278e)
Partition GPU de Topaze, supercalculateur en service depuis 2021 au CCRT (CEA, Bruyères-le-Châtel).
Base BullSequana XH2000, avec CPU AMD EPYC 7763 (3e génération ; 64 cœurs à 2,45 GHz) et GPU NVIDIA A100.
Rmax : 5,07 Pflops (Rpeak : 6,23 Pflops) sur 42 000 cœurs.
Les classements précédents de Topaze GPU au TOP500 :
Novembre 2021 : 198e (configuration à 26 880 cœurs)
217e puis 241e en 2022
280e puis 317e en 2023
175e puis 208e en 2024 (configuration à 42 000 cœurs)
Juin 2025 : 244e
Jean Zay (292e)
Partition étendue (GPU).
Base HPE SGI 8600, avec CPU Intel Xeon Gold 6248 (Cascade Lake ; 20 cœurs à 2,5 GHz) et GPU NVIDIA Tesla V100 SXM2.
Rmax : 4,48 Pflops (Rpeak : 7,35 Pflops) sur 93 960 cœurs.
Les classements précédents de cette partition au TOP500 :
42e puis 46e en 2019
54e puis 64e en 2020
92e puis 105e en 2021
114e puis 124e en 2022
135e puis 166e en 2023
190e puis 223e en 2024
Juin 2025 : 260e
CRONOS (300e)
Autre supercalculateur d'EDF, passé en production en 2021.
Base BullSequana X, avec CPU Intel Xeon Platinum 8260 (Cascade Lake ; 24 cœurs à 2,4 GHz).
Rmax : 4,3 Pflops (Rpeak : 7,14 Pflops) sur 81 600 cœurs. Consommation : 1,23 MW.
Les classements précédents de CRONOS au TOP500 :
Novembre 2020 : 67e
96e puis 109e en 2021
118e puis 128e en 2022
139e puis 170e en 2023
194e puis 230e en 2024
Juin 2025 : 269e
Joliot-Curie SKL (319e)
Partition de Joliot-Curie qui doit être démantelée cette année.
Base BullSequana X1000, avec CPU Intel Xeon Platinum 8168 (Skylake ; 24 cœurs à 2,7 GHz).
Rmax : 4,07 Pflops (Rpeak : 6,64 Pflops) sur 79 488 cœurs. Consommation : 917 kW.
Les classements précédents de Joliot-Curie SKL au TOP500 :
34e puis 40e en 2018
47e puis 52e en 2019
61e puis 72e en 2020
101e puis 113e en 2021
124e puis 133e en 2022
154e puis 183e en 2023
207e puis 245e en 2024
Juin 2025 : 285e
hotlum (339e)
Supercalculateur installé en 2022 chez HPE.
Base Cray EX, avec CPU AMD EPYC 7763 (3e génération ; 64 cœurs à 2,45 GHz).
Rmax : 3,81 Pflops (Rpeak : 4,58 Pflops) sur 116 736 cœurs.
Les classements précédents de hotlum au TOP500 :
146e puis 159e en 2022
187e puis 222e en 2023
252e puis 291e en 2024
Juin 2025 : 331e
THX.A.B (362e)
Supercalculateur installé en 2022 chez Atos.
Base BullSequana XH2000, avec CPU Intel Xeon Platinum 8358 (Ice Lake ; 32 cœurs à 2,6 GHz) et GPU NVIDIA A100 SXM4-64.
Rmax : 3,5 Pflops (Rpeak : 4,98 Pflops) sur 25 056 cœurs. Consommation : 86 kW.
Les classements précédents de THX.A.B en TOP500 :
146e puis 159e en 2022
187e puis 222e en 2023
252e puis 291e en 2024
Juin 2025 : 331e
Topaze CPU (377e)
Partition CPU de Topaze.
Base BullSequana XH2000, avec CPU AMD EPYC 7763 (3e génération ; 64 cœurs à 2,45 GHz).
Rmax : 3,26 Pflops (Rpeak : 4,34 Pflops) sur 110 592 cœurs.
Les classements précédents de Topaze CPU au TOP500 :
Novembre 2021 : 140e
154e puis 170e en 2022
201e puis 237e en 2023
267e puis 306e en 2024
Juin 2025 : 346e
Jean Zay (420e)
Partition CPU de Jean Zay.
Base HPE SGI 8600, avec CPU Intel Xeon Gold 6248 (Cascade Lake ; 20 cœurs à 2,5 GHz).
Rmax : 3,05 Pflops (Rpeak : 4,87 Pflops) sur 61 120 cœurs.
Les classements précédents de cette partition au TOP500 :
72e puis 79e en 2019
91e puis 108e en 2020
140e puis 163e en 2021
178e puis 203e en 2022
237e puis 273e en 2023
309e puis 350e en 2024
Juin 2025 : 391e
KAIROS (422e)
Supercalculateur installé cette année à l'université de Toulouse.
Base BullSequana XH3000, avec puces NVIDIA GH200 (72 cœurs à 3 GHz).
Rmax : 3,05 Pflops (Rpeak : 3,42 Pflops) sur 13 056 cœurs. Consommation : 46 kW.
AMD Ouranos (428e)
Supercalculateur installé cette année chez Atos.
Base BullSequana XH3000, avec CPU AMD EPYC 4e génération (24 cœurs à 1,8 GHz) et GPU AMD Instinct MI300A.
Rmax : 2,99 Pflops (Rpeak : 3,97 Pflops) sur 16 632 cœurs. Consommation : 48 kW.
Les classements précédents d'AMD Ouranos au TOP500 :
Juin 2025 : 399e
Spartan3 (462e)
Supercalculateur installée en 2021 chez Atos.
Base BullSequana XH2000, avec CPU AMD EPYC 7763 (3e génération ; 64 cœurs à 2,45 GHz).
Rmax : 2,75 Pflops (Rpeak : 3,61 Pflops) sur 92 160 cœurs.
Les classements précédents de Spartan3 au TOP500 :
Le « Projet Kuiper », qui n’était qu’un nom de code interne inspiré de la ceinture d’astéroïdes située au-delà de Neptune, devient Amazon Leo, en référence à l’orbite terrestre basse (Low Earth Orbit) où évoluent ses satellites.
Ce changement de marque intervient à un moment charnière : Amazon a déjà déployé plus de 150 satellites en orbite et compte déjà des clients professionnels tels que JetBlue, L3Harris ou Sky Brasil. Le groupe prévoit plus de 80 missions supplémentaires pour constituer sa constellation complète, avec l’objectif d’atteindre 1 600 satellites d’ici la fin juillet 2026.
Une offre à trois niveaux
L’offre d’Amazon Leo se décline en trois formules: Leo Nano ( vitesses jusqu’à 100 Mbps), Leo Pro ( jusqu’à 400 Mbps) et Leo Ultra (jusqu’à 1 Gbps). Aucune grille tarifaire n’est communiquée.
La France doit faire partie des premiers pays où le service sera commercialisé, avec un lancement envisagé dès fin 2025 ou début 2026.
Amazon Leo arrive sur un marché où SpaceX dispose d’une avance considérable. Starlink compte déjà plus de 10 000 satellites en orbite et dessert plus de 2 millions de clients. Amazon a d’ailleurs dû faire appel à SpaceX pour certains de ses lancements : 3 missions via Falcon 9 ont permis de placer 72 satellites en orbite, illustrant le paradoxe de devoir collaborer avec son principal concurrent.
Un recours devant le Conseil d’État
L’arrivée d’Amazon Leo en France ne se fait pas sans opposition. Le syndicat CFE-CGC Télécoms a déposé un recours en annulation devant le Conseil d’État contre la décision (n° 2025-1347) de l’autorité de régulation des télécoms qui a accordé, en juillet, une autorisation d’utilisation de fréquences radioélectriques à Amazon Kuiper.
Le syndicat, représentant les personnels du secteur des télécommunications, soulève plusieurs préoccupations majeures.
Sur la concurrence et la souveraineté, la CFE-CGC Télécoms estime que l’ARCEP n’a pas mesuré la menace que représente Amazon Kuiper sur l’équilibre du marché français.
Le syndicat dénonce une distorsion de concurrence car les constellations satellitaires comme Starlink et Amazon Leo peuvent rentabiliser leurs satellites à l’échelle de plusieurs pays et ne sont pas soumises aux mêmes obligations que les opérateurs terrestres français.
Sur l’impact économique, elle estime que le déploiement de ces réseaux satellitaires fragilise les gros investissements réalisés par les opérateurs français, notamment dans la fibre optique, et met en péril l’emploi et l’expertise technique dans l’hexagone. Enfin, le syndicat déplore l’absence d’analyse par le régulateur de l’impact environnemental des constellations satellitaires, notamment concernant l’envoi de satellites en orbite basse, leur faible durée de vie et la problématique croissante des débris spatiaux.
« Ce recours gracieux est un signal d’alerte pour forcer le législateur à réguler les services satellitaires car c’est tout l’écosystème français des Télécoms qui est en jeu. Ne rien demander aux acteurs américains et laisser peser sur les opérateurs français taxes et obligations nous semble en effet irresponsable » déclare Kathleen Beaude, Présidente, et Sébastien Crozier, Vice-Président du syndicat.
Au-delà du cas français, la multiplication des constellations de satellites soulève des inquiétudes croissantes. Avec des milliers de satellites déployés par Starlink, Amazon Leo, OneWeb et d’autres projets, les spécialistes alertent sur les risques accrus de collisions, l’explosion du nombre de débris spatiaux, les menaces pour les missions habitées et les perturbations pour les observations astronomiques.
Blue, opérateur de cloud souverain, annonce l’acquisition d’Openhost, une société basée à Nantes spécialisée dans les solutions Microsoft 365 et Azure.
Cette opération va enrichir l’offre de cloud hybride de Blue, qui combine l’hébergement privé dans son nouveau centre de données à Nantes avec la possibilité d’un débordement vers le cloud public Azure.
L’acquisition, avec 13 collaborateurs d’Openhost certifiés Microsoft, apporte à Blue une équipe spécialisée dans l’orchestration d’architectures hybrides. Celles-ci comprennent des charges de travail privées hébergées dans le datacenter nantais de Blue (certifié ISO 27001 et Hébergeur de Données de Santé) et un débordement vers le cloud public Microsoft Azure « on premise » en fonction des besoins.
Blue a pour objectif d’atteindre 55 millions € de chiffre d’affaires en 2025, contre 45 millions € en 2024, avec l’ouverture de son nouveau centre de données à Nantes (fin de 2025) en complément de son datacenter à Rennes.
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
La succession de Tim Cook entre-elle dans une phase décisive chez Apple ? La réponse est Oui selon le Financial Times, qui cite plusieurs sources proches des discussions internes, le conseil d’administration et les cadres dirigeants du groupe ont intensifié leurs travaux de planification en vue d’un départ du CEO dès l’année prochaine.
John Ternus, responsable de l’ingénierie matérielle, se profile comme le successeur le plus probable, bien qu’aucune décision définitive n’ait été prise à ce stade. Cette accélération des préparatifs ne serait pas motivée par des difficultés opérationnelles : Apple anticipe au contraire une forte dynamique commerciale pour l’iPhone lors des fêtes de fin d’année. Sollicité par le Financial Times, le groupe n’a pas souhaité commenter.
John Ternus, successeur favori
Selon le quotidien britannique, Apple devrait attendre la publication de ses résultats de fin janvier avant toute annonce officielle. Cette chronologie permettrait à la nouvelle direction de prendre ses marques avant deux rendez-vous majeurs : la conférence développeurs de juin et la présentation traditionnelle de l’iPhone en septembre. Ce calendrier reste toutefois susceptible d’évoluer.
Ces discussions interviennent dans un contexte de mouvement au sein de l’équipe dirigeante. Luca Maestri a quitté son poste de directeur financier début 2024, tandis que Jeff Williams, directeur des opérations, a annoncé son départ prévu pour juillet, rapporte le Financial Times.
La nomination éventuelle de John Ternus replacerait un profil technique à la tête du groupe, alors qu’Apple peine à conquérir de nouveaux marchés et affiche un retard face à ses concurrents dans le domaine de l’intelligence artificielle. Tim Cook a toujours privilégié une succession interne et évoqué l’existence de plans détaillés sur le sujet.
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 :
L’Union européenne ouvre un test de marché pour évaluer les engagements présentés par SAP dans le cadre d’une enquête antitrust lancée en septembre dernier, visant des soupçons de distorsion de concurrence concernant les services de maintenance et de support pour ses logiciels installés sur site (on-premise).
L’autorité de régulation européenne s’interrogeait notamment sur quatre pratiques susceptibles d’avoir contribué à exclure la concurrence. (lire notre article sur le sujet).
Face à ces accusations, SAP a soumis cette semaine des propositions pour répondre à ses préoccupations :
> L’octroi d’un plus grand choix aux clients dans la sélection de leurs fournisseurs de services de support logiciel
> Une flexibilité accrue concernant les licences logicielles
> La suppression de certains frais de licence
Un test de marché décisif
« Dans nos remèdes proposés, nous clarifions leur fonctionnement dans le cadre de notre engagement plus large en faveur de la transparence et du choix des clients. Nous n’anticipons pas que cette procédure aura des impacts significatifs sur notre performance financière. » indique SAP dans un communiqué.
Le lancement d’un test de marché auprès des concurrents et des clients de SAP doit évaluer si les propositions de l’éditeur allemand suffisent à dissiper les inquiétudes concurrentielles. Si aucune objection majeure n’est soulevée durant cette phase, les régulateurs européens devraient abandonner la menace de sanctions financières.
La sanction maximale prévue est une amende d’un montant équivalent à 10 % de son chiffre d’affaires mondial (34 Md€ en 2024).
Il y aura bien un procès opposant Apple et OpenAI à Elon Musk.
Le juge Mark Pittman, du tribunal fédéral de Fort Worth au Texas, a décidé que la plainte intentée par X et xAI contre Apple et OpenAI pourra se poursuivre. Déposée en août dernier, elle réclame plusieurs milliards de dollars de dommages et intérêts. Le juge a demandé aux deux parties de soumettre de nouveaux documents pour défendre leurs positions respectives dans cette affaire.
Elon Musk accuse Apple d’avoir violé les lois antitrust en intégrant exclusivement ChatGPT dans les fonctionnalités Apple Intelligence sur ses plus récents iPhone, iPad et Mac. Selon les plaignants, cette décision d’Apple inhibe la concurrence et l’innovation dans l’industrie de l’IA, tout en privant les consommateurs de choix.
La plainte affirme que ce choix d’Apple inhibe la concurrence et l’innovation dans l’industrie de l’IA, tout en privant les consommateurs de choix. Elle dénonce aussi le placement de ChatGPT dans la liste des « Must-Have Apps » de l’App Store contribuant à marginaliser les concurrents.
Les arguments de la défense rejetés
Apple et OpenAI avaient demandé le rejet pur et simple de cette action en justice, mais leurs arguments n’ont pas convaincu le magistrat. Dans son ordonnance, le juge Pittman précise que sa décision ne devait pas être considérée comme un jugement sur le fond des allégations, et qu’il examinera les litiges factuels à un stade ultérieur de la procédure.
Les avocats d’Apple ont fait valoir que l’accord avec OpenAI n’est pas exclusif, soulignant que d’autres chatbots restent disponibles via les navigateurs et applications.
De son côté, OpenAI accuse Elon Musk de mener « une campagne de guerre judiciaire ». Le milliardaire poursuit séparément OpenAI et ses dirigeants devant un tribunal fédéral en Californie.
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.
Pour une entreprise, les données représentent la base de son activité, la confiance de ses clients, ainsi que la souveraineté numérique de son pays. Or, ces mêmes données peuvent échapper à son contrôle, non pas à cause d’une violation ou d’une erreur humaine, mais simplement parce que l’entreprise a accepté les conditions générales d’un fournisseur de cloud plusieurs années auparavant. Bien qu’elle puisse accéder à ses données et les utiliser, elle n’a désormais plus aucun contrôle sur l’écosystème qui les entoure, ni sur leur évolution et leurs changements.
Loin d’être une simple hypothèse, ce cas de figure est une réalité quotidienne pour des milliers d’entreprises partout en Europe et dans d’autres pays. Cette situation soulève alors une question cruciale : comment garantir aux entreprises la maîtrise de leurs données et la liberté de choix dans un tel contexte ?
La promesse du multicloud : entre attentes et réalité
Face à ce constat, les entreprises, notamment les PME, se sont tournées vers le multicloud. En effet, travailler avec plusieurs fournisseurs permet de gagner en flexibilité, sécurité et portabilité des workloads. L’idée consiste donc à migrer les applications existantes puis à les optimiser pour le cloud.
Or, dans la pratique, cette promesse n’est pas souvent tenue. Les entreprises sont confrontées à la nécessité de « transférer » leurs applications monolithes sur site vers le cloud, tout en composant avec de nouvelles applications cloud-first créées par une toute nouvelle génération d’ingénieurs et des silos de données fédérés et distribués.
Au cœur du problème se trouve également quelque chose de plus fondamental qu’une simple part de marché : il s’agit de l’érosion de la liberté de choix et, par conséquent, de l’érosion de la souveraineté. Cette dépendance croissante vis-à-vis des plateformes externes nuit à l’innovation.
En parallèle, les DSI sont chargés de vérifier le respect de la conformité pour les écosystèmes tiers, ce qui enferme les autorités chargées de la réglementation dans des interfaces propriétaires. L’avenir du numérique se confond alors étrangement avec le passé et se retrouve monopolisé par une poignée de personnes à la logique interne obscure et aux motivations incompatibles avec celles de la société.
Sécurité nationale, innovation et éthique : des enjeux globaux
Cette dépendance vis-à-vis de quelques fournisseurs soulève alors trois grand enjeux.
C’est d’abord une question de sécurité nationale. Les pays européens prennent conscience que dépendre d’hyperscalers étrangers pour entraîner et déployer leurs modèles d’IA représente un risque pour leur souveraineté. Plusieurs questions se posent alors : que se passerait-il en cas de changements géopolitiques ? Que se passerait-il si l’accès d’un gouvernement aux données de ses propres citoyens est restreint en raison d’obligations légales étrangères ?
C’est aussi une question d’innovation. En effet, les start-ups ne peuvent pas se permettre de payer des frais de sortie qui pénalisent l’exploration et les universités ne devraient pas avoir à adapter leurs recherches aux contraintes commerciales d’un seul fournisseur. Si l’IA est l’équivalent du « moteur à vapeur » du XXIe siècle, il est essentiel de veiller à ce que son carburant, à savoir les données et la puissance de calcul, reste à la fois accessible et portable.
Enfin, c’est une question d’éthique. L’une des plus grandes erreurs dans la gouvernance de l’IA est l’idée que l’éthique peut être superposée à des systèmes fermés. Que les biais des modèles, l’équité algorithmique et l’explicabilité peuvent être réglementés, tout en déployant les modèles les plus sensibles via des API tierces exécutées dans des environnements « Black Box ».
La véritable gouvernance de l’IA commence par la gouvernance des infrastructures. Cela signifie qu’il faut savoir où les modèles sont hébergés, qu’il faut enregistrer et auditer chaque inférence, mais aussi s’assurer que les modèles ne franchissent pas les frontières et ne transgressent pas les règles locales en matière de résidence des données. Or, le fait d’être lié à un seul fournisseur ou de dépendre de services managés purs qui fonctionnent comme des boîtes noires rend tout cela possible.
Vers un cloud souverain et portable
La prochaine évolution technologique est une plateforme qui ne se contente pas de promettre la portabilité, mais qui la met en œuvre. Là où les moteurs de calcul suivent les données et pas l’inverse. Et surtout, là où l’IA peut être exécutée de manière privée, sécurisée et en toute simplicité. Il n’est pas question d’abandonner le cloud, loin de là. Sa flexibilité, son évolutivité et son potentiel de démocratisation sont révolutionnaires. Mais les révolutions doivent être encadrées et le cloud doit avant tout être un choix.
Aujourd’hui, les entreprises sont confrontées à un choix difficile : continuer à dépendre des fournisseurs, accepter l’augmentation des coûts et la réduction de l’autonomie qui en découle, ou basculer vers un environnement où l’infrastructure est fluide, où l’IA peut être souveraine et où le cloud est une capacité qui leur appartient.
Les DSI, les CTO et les CDO doivent être les garants du contrôle absolu des données au sein de l’entreprise, tant du point de vue budgétaire que de celui de la conformité. Une chose est sûre : le droit de traiter les données doit rester entre les mains des personnes qui sont propriétaires de ces données.
*Sergio Gago est Chief Technology Officer chez Cloudera
Si aucun fournisseur d’infrastructure n’est totalement à l’abri d’un feu de datacenter ou d’une catastrophe naturelle majeure, la cyberattaque est aujourd’hui la menace n°1 pour les données. Les sauvegardes sont un moyen de redémarrer le SI… si celles-ci n’ont pas été elles-mêmes détruites par l’attaquant !
« Si les sauvegardes peuvent permettre à une entreprise de repartir, il faut encore que celles-ci soient saines , au risque de repartir sur un PRA déjà infecté. Il est donc aujourd’hui indispensable d’intégrer des solutions de sécurité dans les outils de sauvegarde » explique Maxime Baudout, Manager de l’équipe Infrastructure de Jiliti.
Maxime Baudout, Manager de l’équipe Infrastructure de Jiliti
« On retrouve de plus en plus de fonctions cyber intégrées dans les outils gérant les PRA. Cela va du chiffrement de bout en bout lors d’un PRA externalisé pour garantir que les données ne seront pas lues par le prestataire, à des outils avancés d’inspection des données. » ajoute-t-il.
Illustration de cette convergence entre outils de sauvegarde et cyber, Acronis qui propose désormais une plateforme MSP multi-tenant, pour assurer la sauvegarde des données et la reprise d’activité, l’activité historique de l’éditeur, mais aussi de la cybersécurité avec la protection de la messagerie, de la protection endpoint avec un EDR, du RMM management et du DLP.
Le Cloud, un coup de jeune pour les PRA
L’autre grande tendance forte qui pousse à la refonte des PRA, c’est bien évidemment le Cloud.
Stéphanie Ledoux, PDG et fondatrice d’Alcyconie.
« Les PRA modernes s’appuient de plus en plus sur des solutions hybrides combinant cloud, automatisation, et orchestration des processus de bascule » explique Stéphanie Ledoux, PDG et fondatrice d’Alcyconie. « L’automatisation des tests, la réplication temps réel des données critiques et l’utilisation de plateformes d’orchestration permettent de réduire le temps de bascule et de simplifier les tests réguliers — une étape encore trop souvent négligée. »
Et d’ajouter qu’une approche modulaire des PRA par service ou par périmètre critique doit faciliter aussi leur actualisation. « Ces technologies transforment le PRA en un processus dynamique et non plus en un simple document figé. »
Outre les ressources internes, il est devenu nécessaire d’intégrer à ces PRA les données stockées sur les infrastructures IaaS, PaaS et même SaaS.
« Un plan de reprise d’activité efficace doit pouvoir s’appliquer à l’ensemble de l’infrastructure informatique, quels que soient les environnements utilisés » résume Richard Cassidy, Field CISO EMEA de Rubrik. « Notre solution prend en charge les infrastructures sur site, les environnements cloud, hybrides et SaaS (tels que Microsoft 365 ou Salesforce). L’organisation des sauvegardes est structurée selon des règles de gouvernance adaptées aux priorités de l’entreprise, ce qui permet d’optimiser les processus de sauvegarde, de limiter les coûts d’exploitation et de moderniser les architectures existantes. »
L’éditeur pointe l’intérêt d’une solution Cloud offrant une gestion centralisée et une automatisation basée sur des règles préétablies. Un moyen aussi de contenir les coûts liés à la mise en œuvre d’un PRA. Cette approche contribue à simplifier les opérations informatiques, en s’affranchissant des contraintes associées à des outils anciens ou à des infrastructures complexes. »
Le stockage Cloud S3 est aujourd’hui totalement supporté par les principaux logiciels de sauvegarde et un PRA 100 % Cloud et managé apparaît comme une solution particulièrement intéressante pour les ETI et PME dont les moyens de sauvegarde ne sont pas toujours très fiables.
———————————————————————
Régis Karakozian, directeur Cloud chez KDDI France.
Régis Karakozian, directeur Cloud chez KDDI France
« L’analyse d’impact métier est cruciale »
« Avant tout, il est crucial d’opérer une analyse d’impact métier (BIA) pour identifier les services critiques, les priorités de reprise, et les délais tolérables d’interruption (RPO/RTO). Cette étape doit se faire en étroite collaboration avec les directions métier, car un PRA n’est pas qu’une question IT.
La documentation du plan, son automatisation, ainsi que la régularité des tests sont aussi essentielles. Un PRA n’a de valeur que s’il est testé régulièrement (au moins 1 fois par an), maintenu à jour et capable d’être activé rapidement. Il faut également prévoir une communication de crise, incluant les parties prenantes internes et externes. »
————————————————————————
Maxime Baudout, Manager de l’équipe Infrastructure de Jiliti
Maxime Baudout, Manager de l’équipe Infrastructure de Jiliti
« L’automatisation permet d’orchestrer un PRA de bout en bout.»
« Les nouvelles technologies ont fait fortement évoluer la gestion des PRA. L’évolution la plus intéressante est pour moi l’automatisation qui permet d’orchestrer un PRA de bout en bout. Cela permet de tester beaucoup plus facilement son PRA et de limiter les erreurs humaines. »
« Le second point clé est l’utilisation du Cloud et de l’hybridation. Il est maintenant facile d’avoir sa production On-Premise et son PRA dans le cloud, ou son infrastructure cloud et le PRA dans un autre Cloud. Cela permet de simplifier grandement les besoins en infrastructure et de limiter les investissements tout en répondant aux exigences réglementaires qui imposent d’avoir son PRA dans un environnement isolé de la production ou distant de X kilomètres. »
—————————————————————————–
Stéphanie Ledoux, PDG et fondatrice d’Alcyconie.
Stéphanie Ledoux, PDG et fondatrice d’Alcyconie
« Externaliser la solution ne doit jamais signifier externaliser la responsabilité de la continuité.»
« Un PRA 100% Cloud, 100% managé peut être pertinent, à condition de bien maîtriser les risques associés. Le cloud managé apporte agilité, scalabilité et externalisation des contraintes techniques. Mais attention aux dépendances critiques, à la localisation des données, à la conformité réglementaire et à la capacité réelle du fournisseur à garantir la disponibilité en cas de crise. Le tout managé ne dispense pas de conserver la gouvernance, le pilotage des tests et la maîtrise des scénarios. »
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.
Should I stay or should I go ? Voilà plusieurs mois que la question trotte dans la tête de Yann LeCun, scientifique en chef de l’intelligence artificielle chez Meta depuis 2013.
Selon le Financial Times (FT), le lauréat du prix Turing aurait informé ses proches de son intention de partir dans les prochains mois. Il serait également en discussions préliminaires pour lever des fonds destinés à sa future startup, selon des sources proches du dossier citées par le FT.
Une issue qui n’est pas vraiment une surprise tant le chercheur franco-américain, considéré comme l’un des pères fondateurs de l’IA moderne, apparait éloigné de la nouvelle stratégie souhaitée par Mark Zuckerberg pour coller à la roue d’OpenAI.
En effet, le fondateur de Meta a décidé de délaisser les travaux de recherche fondamentale menés par le laboratoire FAIR (Fundamental AI Research Lab), dirigé par LeCun, au profit d’un déploiement accéléré de modèles et produits d’IA commerciaux. Cette réorientation fait suite à la performance décevante du modèle Llama 4, qui s’est révélé inférieur aux offres concurrentes de Google, OpenAI et Anthropic.
Une réorganisation qui bouleverse les hiérarchies
L’été dernier, Mark Zuckerberg a recruté Alexandr Wang, fondateur de la startup Scale AI, pour diriger une nouvelle équipe dédiée à la « superintelligence ». Cette embauche s’est accompagnée d’un investissement de 14,3 milliards $ pour acquérir 49% de Scale AI. Conséquence directe : LeCun, qui reportait jusqu’alors au directeur produit Chris Cox, se retrouve désormais sous la supervision de Wang, âgé de 28 ans.
Le patron de Meta a parallèlement constitué une équipe exclusive, baptisée TBD Lab, chargée de développer la prochaine génération de grands modèles de langage. Pour attirer des talents d’OpenAI et de Google, des packages de rémunération atteignant 100 millions $ ont été proposés. En juillet, Shengjia Zhao, co-créateur de ChatGPT chez OpenAI, a été embauché comme scientifique en chef du laboratoire Superintelligence.
Un désaccord fondamental sur l’avenir de l’IA
Cette réorganisation met en lumière une divergence stratégique profonde. LeCun défend depuis longtemps la thèse selon laquelle les grands modèles de langage (LLM), au cœur de la nouvelle stratégie de Mark Zuckerberg, sont certes utiles mais ne permettront jamais d’atteindre des capacités de raisonnement et de planification comparables à celles des humains.
Le scientifique concentre ses travaux au sein de FAIR sur une génération entièrement nouvelle de systèmes d’IA : les « modèles du monde ». Ces architectures visent à comprendre le monde physique en apprenant à partir de vidéos et de données spatiales plutôt que de simples contenus textuels. LeCun estime toutefois qu’une décennie pourrait être nécessaire pour développer pleinement cette technologie. Son prochain projet entrepreneurial portera précisément sur l’approfondissement de ces recherches selon le FT.
Le départ annoncé de Yann LeCun n’est pas le premier des « vétérans de l’IA » à quitter Meta. En mai, c’est Joelle Pineau, vice-présidente de la recherche en IA, qui avait rejoint la startup canadienne Cohere. En octobre, ce sont environ 600 personnes de son unité de recherche qui avaient été licenciées.