Des checkpoints, du replay… et ça donne des fonctions Lambda « durables ».
AWS a mis cette option en lumière lors de sa conférence re:Invent 2025. La promesse : des exécutions qui peuvent durer jusqu’à 1 an, avec une reprise fiable après interruption ou mise en pause.
Un SDK à intégrer dans le code des fonctions permet d’implémenter les primitives qui gèrent ce mécanisme. Les mises en pause peuvent se faire pour une durée déterminée. On peut aussi conditionner la reprise à un événement donné.
La facturation se fait sur trois plans :
Opérations « durables » (étapes, pauses, callbacks) : 8 $ le million
Données écrites : 0,25 $/Go
Données conservées : 0,15 $/Go/mois
Lambda en un peu moins serverless
Autre option mise en avant : les instances Lambda managées. Il s’agit ici de choisir les configurations EC2 sur lesquelles exécuter les fonctions.
On crée pour cela des « fournisseurs de capacités ». Ces fournisseurs s’exécutent dans le compte AWS, au sein d’un VPC (et au moins d’un sous-réseau). On peut en paramétrer certains aspects :
Architecture CPU
Types d’instances autorisées (liste blanche, liste noire ou sans restriction)
Nombre maximal d’instances
Mode de mise à l’échelle (manuelle ou automatique)
Clé de chiffrement EBS (éventuellement personnalisée)
Un autre modèle de concurrence…
Lorsqu’on publie une version d’une fonction associée à un fournisseur de capacité, Lambda lance des instances managées (3 par défaut, pour la résilience). Ou bien il en utilise des existantes si les ressources sont suffisantes pour accueillir l’environnement d’exécution.
De même, un environnement d’exécution peut gérer plusieurs invocations en parallèle (64 maximum). Le modèle de concurrence est donc différent de celui de Lambda « standard » (une invocation = un environnement).
… de sécurité…
Ce système suppose que la sûreté des threads, la gestion d’état et l’isolation du contexte doivent être gérés différemment en fonction du contexte.
Les fournisseurs de sécurité constituent en fait la limite de confiance. Avec les instances Lambda managées, les fonctions s’exécutent effectivement dans des conteneurs, lesquels ne fournissent pas le même niveau de sécurité que la techno de micro-VM Firecracker utilisée en standard.
… de scaling…
Avec les instances Lambda managées, pas de démarrage à froid. La mise à l’échelle est asynchrone, sur la base de signaux de consommation CPU. Dans cet esprit, l’option est donc à réserver aux workloads dont le trafic est prévisible. AWS ne garantit d’ailleurs pas la stabilité si la charge fait plus que doubler dans un intervalle de 5 minutes.
Quatre paramètres influent sur la mise à l’échelle :
Quantités de mémoire et de vCPU allouées à une fonction
Concurrence maximale par environnement
Cible d’utilisation de ressources
Types d’instances autorisés
… et de tarification
Les instances Lambda managées sont facturées au prix d’EC2 à la demande… avec 15 % de frais supplémentaires. L’option permet néanmoins d’exploiter d’éventuelles remises (savings plans, instances réservées…). Il faut ajouter des frais de 0,20 $ par million de requêtes.
Plus besoin de shards ni de requêtes fédérées : vous pouvez consolider vos données vectorielles en un seul index.
AWS en fait l’un des arguments de S3 Vectors, lancé en disponibilité générale lors de la re:Invent.
Avec S3 Vectors, la promesse d’un index unique
Le service était en previewdepuis juillet. Il apporte une gestion native des vecteurs dans S3, avec un type de bucket spécifique. Sur le papier, c’est une alternative moins onéreuse à Aurora Serverless et OpenSearch Serverless, en contrepartie de temps de réponse allongés (« sous la seconde », affirme AWS).
La préversion permettait de stocker jusqu’à 50 millions de vecteurs par index (et 10 000 index par bucket). Avec la version commerciale, on passe à 2 milliards, d’où l’argument de la consolidation. Autre seuil relevé : le nombre maximal de résultats par requête (100 désormais, contre 30 en preview). Quant à la latence, elle est maintenant « fréquemment sous les 100 ms ».
S3 Vectors a une intégration avec Bedrock Knowledge Bases (RAG) et avec Amazon OpenSearch (utilisation comme moteur sur les clusters managés ou injection d’un snapshot dans la version serverless).
L’accélération GPU activée sur OpenSearch
En parallèle, une option d’accélération GPU fait son entrée sur l’OpenSearch d’AWS. Promesse : construire des bases vectorielles « jusqu’à 10 fois plus vite » pour un quart du prix traditionnel, grâce à un usage optimisé de l’infra. En complément, il devient possible de régler les niveaux de rappel et de latence souhaités.
Une mémoire épisodique pour les agents Bedrock
À l’occasion de la re:Invent, il y a aussi du nouveau dans Bedrock AgentCore. Cette offre, lancée à l’été 2025, est dans la lignée de Bedrock Agents. Elle en a étendu les capacités (gestion native de MCP et contrôle plus fin de la mémoire, par exemple) et en a désagrégé la plupart en modules indépendants, par ailleurs « détachés » de Bedrock de sorte qu’ils prennent en charge des technologies non disponibles sur la plate-forme.
Voilà Bedrock AgentCore doté d’une forme de mémoire épisodique. Avec cette stratégie, les agents capturent des « épisodes structurants » (contexte, processus de raisonnement, actions, résultats). Ils sont censés pouvoir ainsi agir de façon plus cohérente lorsqu’ils rencontrent des situations similaires.
AWS dote aussi AgentCore de la diffusion audio bidirectionnelle. Lors des interactions vocales, l’agent peut être interrompu et s’adapter au nouveau contexte sans avoir à terminer son action au préalable.
Un service managé de supervision est également ajouté, mais pour le moment en preview. On peut y intégrer des évaluations personnalisées en plus de celles livrées pour analyser des indicateurs tels que la précision, l’utilité, la concision et la sûreté. Les résultats sont délivrés dans CloudWatch.
Autre preview : celle de la fonctionnalité Policy in AgentCore. Elle permet d’intercepter les appels d’outils sur la passerelle et de leur appliquer des stratégies définies en langage naturel ou avec Cedar.
Les derniers modèles Mistral et Gemma ajoutés sur Bedrock
AWS a aussi profité de la re:Invent pour rappeler les derniers ajouts de modèles ouverts sur Bedrock. Parmi eux :
Mistral Large 3, Ministral 3 (3B, 8B, 14B), Magistral Small 1.2, Voxtral Mini 1.0, Voxtral Small 1.0
Gemma 3 (4B, 12B, 27B)
Kimi K2 Thinking (de Moonshot AI)
MiniMax M2 (de MiniMax AI)
Nemotron Nano 2 9B et une version « vision » 12B (de NVIDIA)
GPT-OSS-safeguard 20B et 120B (modèles de modération de contenu)
Qwen3-Next-80B-A3B et Qwen3-VL-235B-A22B
Nova Sonic : une deuxième génération plus polyglotte
Amazon enrichit aussi sa propre famille de modèles Nova. Avec notamment Nova 2 Sonic.
La première génération de ce modèle de reconnaissance et de synthèse vocales avait été lancée en avril. La deuxième gère mieux les entrées alphanumériques, les énoncés courts, les accents, le bruit de fond et l’audio qualité téléphonie (8 kHz). Avec elle arrivent les « voix polyglottes » (capacité à changer de langue au milieu d’une conversation), les appels d’outils asynchrones et un réglage de sensibilité pour la détection de voix (ce qui laisse plus ou moins de temps à l’utilisateur pour finir sa phrase).
AWS lance Nova dans le bain de l’automatisation web
Sous la marque Nova Forge, AWS permet de continuer l’entraînement de ses propres modèles à partir de divers checkpoints, en utilisant des jeux de données spécialisés « sur étagère » ou en en important. L’ensemble repose sur l’outillage SageMaker AI et permet d’effectuer éventuellement de l’apprentissage par renforcement.
On trouve aussi un modèle Amazon (Nova 2 Lite) à la base de Nova Act, service d’automatisation agentique pour les navigateurs web. Il est intégré avec le framework d’ochestration Strands Agents.
Les données synthétiques sous l’angle privacy
Les serveurs de tracking MLflow qu’on peut greffer depuis l’an dernier à SageMaker pour superviser les expérimentations ML disposent désormais d’une option serverless. Avec la possibilité de partager des instances entre domaines et comptes AWS.
Le service Clean Rooms (salles blanches de données) permet quant à lui maintenant de créer des jeux de données synthétiques (tabulaires, destinées à entraîner des modèles de régression et de classification ; pas des LLM). Le système utilise un modèle qui reproduit les patterns statistiques du dataset d’origine tout en éliminant les données identifiantes. En ce sens, il est présenté comme une alternative aux techniques d’anonymisation.
AI Factories : AWS s’approprie aussi la notion
AWS s’approprie le concept des AI Factories en lançant une offre sous ce nom. On n’en sait pas grand-chose à l’heure actuelle, sinon qu’elle doit permettre de déployer des clusters IA managés (puces Trainium et NVIDIA + services AWS) dans les datacenters des clients, « comme une région AWS privée ». Premier client référent : l’entreprise saoudienne HUMAIN, qui va installer sur place une « zone IA » avec jusqu’à 150 000 GPU.
Des fonctions Lambda « durables »
Les fonctions Lambda durables ne sont pas spécifiques aux workloads IA, mais elles sont susceptibles de faciliter leur exécution.
Par « durables », il faut entendre « dont la durée de vie peut atteindre 1 an ». Elle peuvent effectivement être mises en pause jusqu’à ce que des conditions spécifiques soient remplies (typiquement, des événements externes). Seul le temps de calcul actif est facturé.
Un SDK s’intègre au code des fonctions pour pouvoir implémenter ces pauses. Ainsi que des « étapes » permettant de ne pas reprendre l’exécution depuis le début en cas d’échec.
Alphabet, maison mère de Google, a retiré sa plainte antitrust déposée auprès de la Commission européenne contre les pratiques cloud de Microsoft, une semaine après l’ouverture par Bruxelles de trois enquêtes de marché sur AWS et Microsoft Azure dans le cadre du Digital Markets Act (DMA).
Désormais, Google affirme vouloir contribuer aux travaux des autorités dans ce cadre plus large, et indique rester engagé dans le dialogue avec les décideurs publics pour faire évoluer les règles de concurrence et les conditions de licences dans le cloud.
Google avait saisi la Commission européenne en 2024 en accusant Microsoft d’utiliser des conditions de licences logicielles pour enfermer les clients dans sa plateforme Azure. La plainte mettait en avant des pénalités financières, des restrictions d’usage de Windows Server et des obstacles d’interopérabilité pour les entreprises souhaitant exécuter les logiciels Microsoft sur des clouds concurrents ou migrer leurs charges de travail hors d’Azure.
Ces griefs faisaient écho à des préoccupations déjà exprimées par l’association professionnelle CISPE, soutenue par Amazon, qui avait elle-même déposé puis retiré une plainte contre Microsoft après un accord transactionnel en 2024.
Enquêtes de l’UE sur le cloud
Les enquêtes ouvertes par la Commission visent à déterminer si AWS et Azure doivent être désignés comme « contrôleurs d’accès » (gatekeepers) pour leurs services cloud, alors même qu’ils ne remplissent pas automatiquement tous les seuils chiffrés prévus par le DMA. Bruxelles veut évaluer si certaines caractéristiques du secteur (effets de verrouillage, coûts de sortie, barrières techniques au multicloud) renforcent le pouvoir de marché de ces hyperscalers au détriment de la concurrence.
Une troisième enquête examinera si les dispositions actuelles du DMA suffisent à traiter les pratiques susceptibles de limiter la contestabilité et l’équité dans le cloud, ou si des ajustements réglementaires sont nécessaires. La Commission a indiqué que ces travaux s’inscrivent dans un effort plus large pour adapter les outils de concurrence numérique aux spécificités de l’informatique en nuage dans l’UE.
Les grandes entreprises combinent plusieurs clouds pour répartir les workloads, optimiser les coûts, rapprocher les données des utilisateurs et limiter les risques de dépendance à un seul fournisseur. Jusqu’ici, relier ces environnements impliquait soit l’usage d’Internet public sans garanties de bande passante, soit des montages de connectivité privée complexes, longs à déployer et coûteux à exploiter.
L’alliance entre AWS et Google Cloud combine le nouveau service AWS Interconnect- multicloud et Google Cloud Cross-Cloud Interconnect pour proposer une connectivité privée et automatisée entre les deux environnements. Elle fournit une connectivité entre VPC AWS et VPC/VPC‑SC Google Cloud, intégrée de manière native aux consoles et APIs des deux fournisseurs.
Google Cloud avait déjà positionné Cross-Cloud Interconnect comme brique clé de son architecture “Cross-Cloud Network”, permettant de relier Google Cloud à AWS, Azure, Oracle Cloud Infrastructure et d’autres MSP via des liens privés à haut débit.
Les deux acteurs mettent en avant une automatisation poussée : les clients peuvent réserver de la capacité dédiée à la demande et établir la connectivité en quelques minutes, sans gérer directement le câblage, les circuits ni l’infrastructure physique sous‑jacente.
L’annonce inclut une spécification ouverte pour l’interopérabilité réseau entre clouds décrite comme un standard commun de connectivité privée qui vise à réduire la complexité de l’adressage, du routage et de la gestion des politiques réseau entre environnements AWS et Google Cloud.
L’objectif est de permettre à d’autres fournisseurs de cloud d’implémenter le même modèle, afin d’étendre ce socle d’interopérabilité au‑delà du seul duo AWS–Google Cloud. Cette ouverture pourrait favoriser l’émergence d’un écosystème où les clouds majeurs s’alignent sur des standards communs de connectivité privée, à l’image de ce qui existe déjà pour certains protocoles réseau et interfaces de peering.
Caractéristiques techniques mises en avant
Sur le plan technique, Cross-Cloud Interconnect fournit des liaisons privées avec des capacités de 10 ou 100 Gbit/s dans de nombreux sites mondiaux, gérées par Google côté physique, avec des métriques de performance détaillées (latence, pertes de paquets, temps de trajet aller‑retour).
Les documents techniques de Google décrivent un modèle de double attachement (primaire et redondant) et l’utilisation de BGP pour l’échange de routes entre Google Cloud et AWS, avec des exigences de haute disponibilité.
AWS Interconnect-multicloud, en préview, est présenté comme un service managé offrant des connexions privées simples, résilientes et à haut débit vers d’autres clouds, intégrées avec les outils réseau et d’observabilité AWS.
L’intégration avec Cross-Cloud Interconnect vise à abstraire la gestion des ports, des circuits et des délais de provisioning, en exposant une expérience de type “cloud‑native” dans les deux consoles.
Cas d’usage et bénéfices clients
L’alliance cible des scénarios où les données ou applications sont réparties entre AWS et Google Cloud, par exemple pour des plateformes analytiques, des charges IA/ML, ou l’intégration de SaaS opérant sur plusieurs clouds.
Un exemple cité concerne l’intégration de Salesforce Data 360, qui nécessite des ponts privés robustes entre différents environnements pour alimenter des cas d’usage d’IA et d’analytique sur des données réparties.
Pour les clients, les bénéfices mis en avant sont la réduction du temps de mise en service des liaisons, la simplification opérationnelle (moins de gestion d’infrastructure physique) et de meilleures garanties de performance que l’Internet public. L’approche standardisée doit aussi faciliter la gouvernance réseau et la sécurité dans des environnements multicloud complexes, où les architectures doivent concilier segmentation, conformité et performance de bout en bout.
Sous le feu des critiques des associations professionnelles et scrutés par les régulateurs, les deux grands CSP américains engagent un mouvement vers un modèle où la connectivité inter‑cloud devient un service managé de première classe, au même titre que le compute ou le stockage, plutôt qu’un assemblage de liens télécoms et de configurations spécifiques.
Reste à observer dans quelle mesure les autres fournisseurs adopteront la spécification proposée et comment les intégrateurs réseau et opérateurs télécoms adapteront leurs offres face à cette montée en puissance de la connectivité multicloud native.
Le plan de contrôle de Route 53 n’est plus tout à fait monorégion.
AWS l’a effectivement répliqué en partie. Et ainsi réduit la dépendance à la région cloud us-east-1.
En toile de fond, l’incident d’octobre. Il a pris racine dans cette région cloud, (re)mettant en lumière le point faible qu’elle constitue. Entre autres, donc, parce que quantité de services y ont leur plan de contrôle.
Une récupération « accélérée »…
La réplication partielle de celui de Route 53 se traduit par une option de « récupération accélérée ». On peut l’activer pour chaque zone hébergée publique (conteneur d’enregistrements définissant l’acheminement du trafic d’un domaine spécifique sur le réseau Internet). Une copie de la zone est alors conservée dans la région us-west-1.
… avec un RTO de 60 minutes
En cas d’indisponibilité prolongée dans la région us-east-1, une bascule est censée s’effectuer… dans un délai de 60 minutes. On n’a alors pas accès à l’ensemble des méthodes API. Mais les principales sont disponibles : listage des zones, des enregistrements et des ensembles de délégation, soumission et suivi de changements, etc.
En période de bascule, il n’est pas possible de créer de zones, ni d’en supprimer. On ne peut pas non plus (dés)activer la signature DNSSEC. Et les connexions AWS PrivateLink ne fonctionnent pas. Par après, pour supprimer une zone, il faut d’abord désactiver l’option de « récupération accélérée ». Laquelle, pour préciser, ne concerne pas le volet DNS privé de Route 53.
Chez Veeam, l’heure est aux intégrations natives avec les hyperviseurs.
La feuille de route est en tout cas bien remplie : de 7 hyperviseurs, on pourrait passer à 13 en 2026.
Le premier environnement géré fut VMware, dès la première version sortie en 2008. Hyper-V s’y était ajouté en 2011.
Le troisième sur la liste fut Nutanix AHV. Le plug-in existe depuis 2018. Avec la dernière version de Veeam (v13, lancée ce mois-ci), l’appliance a été intégrée dans le serveur de backup. La distribution des workers a été améliorée (images déployées au besoin) et il est devenu possible de déployer un agent léger persistant sur les VM – ce qui élimine la nécessité d’un compte à privilèges.
La prise en charge de Red Hat Virtualization est assurée depuis 2021. Aux dernières nouvelles, elle le sera au moins jusqu’à fin 2026 (Red Hat a abandonné cette solution au profit d’OpenShift). Oracle Linux Virtualization Manager, autre solution basée sur KVM, est quant à lui intégré depuis 2024.
Pour l’un et l’autre, la dernière version de Veeam intègre aussi l’appliance dans le serveur de backup. Le placement des workers est amélioré (priorisation de ceux situés dans le même cluster que la VM) et il devient possible de les connecter à plusieurs réseaux. La stratégie de conservation basée sur les points de restauration est remplacée par une stratégie basée sur le temps, ouvrant la voie à de l’immuabilité.
Proxmox en 2024, Scale Computing cette année
Autre hyperviseur géré depuis 2024 : Proxmox VE. Veeam 13 y apporte – sur le papier – un élément important : la sauvegarde au niveau des applications (app-aware) par intégration avec le VSS, pour Active Directory, Exchange, SharePoint, SQL Server, Oracle et PostgreSQL. Elle généralise par ailleurs la disponibilité des fonctions de détection de malwares (analyse des activités suspectes sur le système de fichiers, recherche de menaces, scans YARA après sauvegarde…).
Le dernier hyperviseur ajouté sur la liste le fut en septembre 2025 : HyperCore, de Scale Computing. Ses principales capacités à l’heure actuelle :
Sauvegarde complète ou incrémentale
Sélection de VM, de tags et de clusters comme sources
Exclusions possibles niveau VM et disque
Notification par e-mail pour chaque job
Niveau de compression et taille de bloc personnalisables
Restauration vers/depuis AHV, Proxmox, KVM, AWS, Azure et Google Cloud
XCP-ng, HPE VM Essentials et OpenShift Virtualization prévus pour 2026
Des intégrations avec 4 hyperviseurs supplémentaires sont prévues pour le premier semestre 2026.
Parmi eux, XenServer (que Citrix a décidé de relancer face à VMware) et son forkXCP-ng.
Le plug-in pour XCP-ng (version 8.3 et ultérieures) est en bêta publique depuis fin septembre. Il est préinstallé dans une version spécifique de l’ISO Veeam Backup and Restore 12.3.2. Les possibilités sont proches de celles offertes par le plug-in HyperCore, mais VeeamZIP n’est pas encore géré, comme l’exclusion de VM ou de disques.
VM Essentials, de HPE, est aussi prévu pour le premier semestre. Veeam avait officialisé son intention de développer un plug-in en juin 2025. Une bêta devrait être disponible en décembre.
Un hyperviseur chinois est également sur la liste : Sangfor, proposé par un fournisseur de solutions hyperconvergées sur base KVM.
L’échéance n’est pas aussi précise concernant OpenShift Virtualization : ce sera pour 2026, nous promet-on simplement.
On en arrivera ainsi à 12 hyperviseurs. Si Veeam en compte 13, c’est qu’il inclut un projet d’API « universelle » censée favoriser l’intégration d’autres solutions…
Prenez une offre de « cloud souverain » et greffez-y de l’IA : chez SAP, cela donne EU AI Cloud.
La partie « cloud souverain » est promue depuis quelques années sous la marque SAP Sovereign Cloud.
Le volet IA consiste notamment en l’intégration de modèles génératifs dans l’offre SAP BTP (Business Technology Platform). Une démarche qui s’étend actuellement aux services adossés à ces modèles. Par exemple, Mistral AI Studio et Le Chat, ou la plate-forme Cohere North.
L’approche « cloud distribué », mais sous l’angle IA
Sous la bannière EU AI Cloud, SAP promet la possibilité d’exploiter ces modèles et services sur des infrastructures « souveraines » à quatre niveaux :
Données (localisation)
Exploitation (opérations sensibles effectuées en local avec du personnel situé sur place ou dans un « pays de confiance »)
Technique (plans de contrôle locaux)
Juridique (entités locales ou établies dans des « pays de confiance »)
Quatre options de déploiement.sont proposées : sur l’infrastructure SAP, chez le client (en managé), chez des hyperscalers*… et chez Delos Cloud – filiale du groupe allemand – pour le secteur public.
En fonction des territoires, ces modes de déploiement ne sont pas tous disponibles. En France, c’est pour le moment sur site ou sur le IaaS SAP. Une option de déploiement alternative est « en cours d’évaluation », nous assure-t-on.
Des licences au CLOUD Act, un « cloud souverain » qui interroge
Les fondements de SAP Sovereign Cloud sont à trouver dans l’offre NS2 (National Security Services), exploitée depuis une vingtaine d’années aux États-Unis.
Malgré cette expérience, on est encore loin d’une parité fonctionnelle entre le « cloud souverain » et le cloud commercial, a récemment admis le responsable de l’offre SAP Sovereign Cloud au Royaume-Uni.
En France, l’USF (association professionnelle des utilisateurs SAP francophones) se demande ce que l’option de déploiement sur site apportera par rapport à l’offre SAP CDC qui existait précédemment. Elle s’interroge aussi quant aux risques liés au CLOUD Act au niveau du IaaS SAP. Tout en appelant à des clarifications sur la gouvernance du modèle de Delos Cloud, qui semble se rapprocher fortement de la future offre de Bleu.
Son homologue allemande – le DSAG – attend une « transparence totale » sur le contenu des services et leur date de disponibilité. Elle affirme par ailleurs que la question des licences dans les environnements hybrides est cruciale.
* SAP a récemment confirmé que l’offre AWS European Sovereign Cloud sera une option de déploiement. Le cloud d’Amazon est déjà proposé en Australie et en Nouvelle-Zélande (depuis 2023), au Royaume-Uni (2024), ainsi qu’en Inde et au Canada (2025).
Entre États membres de l’UE, le principe de minimisation des données peut être diversement interprété.
Le projet HealthData@EU Pilot, destiné à poser les jalons du futur Espace européen de données de santé (EHDS, European Health Data Space), en a fait l’expérience. En particulier sur l’un des 5 cas d’usages qu’il a explorés entre 2022 et 2024. Il s’agissait de créer des modèles prédisant le risque de développer des maladies cardio-vasculaires à partir des historiques de parcours de soins.
Quatre pays ont été impliqués : Danemark, Finlande, Norvège… et France, avec un nœud localisé à l’université de Bordeaux.
En Norvège, des inquiétudes furent soulevées quant au risque de réidentification de personnes, vu la quantité et le niveau de détail des variables demandées. En conséquence, il a été décidé de se passer de dates exactes et de réduire la granularité de codes de diagnostic.
En France, la CNIL a considéré qu’accéder à des données concernant l’ensemble de la population n’était pas justifié par le cas d’usage. Elle a demandé que l’échantillon soit limité à 12 millions d’individus, soit le plus gros volume que le Health Data Hub (français) avait exploité jusque-là pour une étude.
Les problèmes d’accès aux données ont contribué à l’allongement du projet HealthData@EU Pilot, qui devait à l’origine s’échelonner sur 2 ans. Au-delà des interprétations divergentes du principe de minimisation, les exigences concernant les documents à soumettre étaient variables. La diversité des statuts des acteurs impliqués n’a pas aidé. Tout comme l’absence de processus clairs pour encadrer l’accès de certains organismes de santé à des données ne relevant pas de ce domaine (données socio-économiques, par exemple).
Ces jalons posés, le développement de l’EHDS se poursuit, avec une feuille de route jusqu’à début 2027, à raison d’une release tous les 4 mois environ.
L’infrastructure doit connecter 3 catégories de participants :
Les États membres, dont chacun désigne un point de contact national (qui établit un catalogue national de métadonnées) et nomme un ou plusieurs organismes chargés d’examiner les demandes d’accès aux données de santé
Les institutions, organismes et agences de l’UE, représentés par un service de la Commission européenne (l’UHDAS, Union Health Data Access Service) qui a lui aussi un rôle d’examinateur de demandes
D’autres participants autorisés (consortiums d’infrastructure numérique ou de recherche, organisations internationales…)
Au cœur de l’infrastructure EHDS est la plate-forme centrale, qui agrège les métadonnées des catalogues nationaux. Elle est hébergée sur AWS, exploitant, entre autres services, EFS (stockage fichier), KMS (chiffrement), ECR (registre de conteneurs), OpenSearch et DocumentDB.
Le demandes d’accès sont soumises par l’intermédiaire de la plate-forme centrale, avec un formulaire commun. Les échanges reposent sur eDelivery – implémentation du protocole de messagerie AS4 qui constitue aujourd’hui un « bloc de base » de l’Europe numérique.
DCAT-AP, Piveau-Hub, Simpl… Des briques européennes pour structurer l’EHDS
Pour harmoniser la description des datasets, a été développée une extension de la spécification DCAT-AP. Cette dernière se base sur un standard W3C (l’ontologie RDF Data Catalogue Vocabulary). Elle alimente quantité de portails de données de l’Union européenne. Il en existe d’autres extensions, par exemple pour les données statistiques et les données géographiques.
Pour assurer l’interopérabilité avec les autres data spaces européens, une autre brique financée par la Commission européenne est mise à contribution : le middlewareSimpl. Il a déjà été expérimenté dans le cadre d’un projet qui associait l’EHDS et 5 autres data spaces européens (marchés publics, données linguistiques, Destination Earth, etc.).
D’autres briques européennes portent l’EHDS, dont EU Login (authentification ; avec Keycloak pour l’autorisation), eTranslation (traduction machine), Europa Analytics, Corporate Notification Service et Interoperability Test Bed (tests de conformité). Le catalogue de métadonnées s’appuie sur Piveau-Hub, dont l’interface a été adaptée aux guidelines de l’ECL (Europa Component Library).
L’estimation des coûts et les indicateurs de qualité des datasets seront pour 2026
Depuis la v4, sortie en mai 2025, l’UI est multilingue (toutes les langues officielles de l’UE + norvégien et islandais, sur l’ensemble des contenus statiques).
La v5 (septembre 2025) a ajouté la possibilité de demander l’accès partiel à un jeu de données. Elle a aussi introduit un back-end Drupal pour la gestion du contenu statique, un explorateur de spec HealthDCAT-AP, un assistant de description de datasets et une traduction automatique des jeux de données entrants et des demandes.
Avec la v6 (janvier 2026), il est prévu de pouvoir réceptionner, sur la plate-forme centrale, les mises à jour du statut des demandes. Un registre européen des décisions d’accès est également dans les cartons, ainsi que la possibilité de demander la modification d’une autorisation d’accès comme de faire appel d’une décision négative.
La v7 (mai 2026) est censée permettre d’appliquer des contraintes de temps sur des statuts spécifiques. Ainsi que de calculer les frais associés à des demandes. Doit par ailleurs y être adjoint un registre des sanctions et pénalités infligées.
Un indicateur de qualité et d’utilité des datasets est sur la roadmap pour la v8 (septembre 2026). Même chose pour l’assignation de rôles d’autorisation spécifiques au sein d’une organisation.
L’EHDS est architecturé en microservices avec API REST. OpenSearch est utilisé pour indexer les données (un éditeur de requêtes SPARQL est disponible sur la plate-forme centrale) ; PostgreSQL, pour stocker les statistiques ; MongoDB, pour conserver les informations sur les fichiers uploadés.
Quand on a déjà du SAM, à quoi bon acquérir une solution de gestion du SaaS ?
Dans sa synthèse du dernier Magic Quadrant consacré à ce marché, Gartner ne tranche pas la question. Il note néanmoins qu’existe, chez les acheteurs, une forme de « résistance à l’ajout d’un autre outil »…
Ces acheteurs évoluent le plus souvent dans les achats et l’exploitation informatique. Tels sont en tout cas les principaux profils que les fournisseurs ciblent, plutôt que les métiers de la sécurité/conformité IT et de la gestion des actifs informatiques.
Le message communiqué l’an dernier quant à la faible maturité du marché reste d’actualité. Comme le conseil qui en découle : négocier des contrats de 2 ans maximum, vu le manque de garanties sur la viabilité de nombreux offreurs. Cette situation les expose à des acquisitions… y compris par des acteurs du SAM.
De la gestion des contrats aux scores de risque, de nombreuses briques facultatives
D’une année à l’autre, le cahier des charges fonctionnel pour figurer dans ce Magic Quadrant a peu évolué.
Illustration sur la découverte de l’usage du SaaS. Seule l’intégration avec des outils de sécurité a été ajoutée sur la liste des options. Il s’agissait toujours d’en proposer au moins trois, entre celle-ci et :
Extension de navigateur
Agent
Système de gestion financière ou des dépenses
SSO
Outil de gestion des terminaux
Messagerie électronique
OAuth
Connexion API directe
Comme l’an dernier, il fallait assurer un minimum d’orchestration de workflows sans code pour l’automatisation de tâches courantes dont l’onboarding/offboarding employé. Étaient également attendues, sur le volet optimisation des dépenses, des possibilités d’identification des apps redondantes, de révocation/réallocation de licences et – nouveauté – de délégation d’ownership aux métiers hors IT, avec contrôle d’accès basé sur les rôles.
Les intégrations ITSM étaient facultatives. Comme les scores de risque et de conformité, les rapports d’adoption, la gestion des contrats et des fournisseurs, la GenAI pour les admins ou les procédures de traitement des demandes d’applications par les employés.
17 fournisseurs, 5 « leaders »
L’évaluation des fournisseurs s’est faite sur deux axes. L’un prospectif (« vision »), portant sur les stratégies (sectorielle, géographique, commerciale, marketing, produit…). L’autre centré sur la capacité à répondre effectivement à la demande (« exécution » : expérience client, performance avant-vente, qualité des produits/services…).
La situation sur l’axe « exécution » :
Rang
Fournisseur
Évolution annuelle
1
Zylo
=
2
Torii
=
3
Flexera
+ 1
4
BetterCloud
+ 3
5
Zluri
– 2
6
1Password
+ 3
7
Lumos
– 1
8
ServiceNow
– 3
9
Calero
+ 1
10
CloudEagle.ai
+ 2
11
Auvik
nouvel entrant
12
USU
– 1
13
Axonius
nouvel entrant
14
Josys
=
15
Corma
nouvel entrant
16
Viio
nouvel entrant
17
MegaZoneCloud
nouvel entrant
Sur l’axe « vision » :
Rang
Fournisseur
Évolution annuelle
1
Zylo
=
2
Torii
=
3
BetterCloud
+ 1
4
Flexera
+ 2
5
Zluri
– 2
6
Lumos
– 1
7
Calero
+ 3
8
1Password
+ 1
9
CloudEagle.ai
+ 3
10
ServiceNow
– 1
11
Viio
nouvel entrant
12
Josys
+ 1
13
Axonius
nouvel entrant
14
Auvik
nouvel entrant
15
USU
– 4
16
Corma
nouvel entrant
17
MegaZoneCloud
nouvel entrant
L’an dernier, trois fournisseurs étaient classés « leaders » : Torii, Zluri et Zylo. Ils le restent, rejoints par BetterCloud et Flexera.
FinQuery et Oomnitza ont disparu des radars, ne vendant plus de plate-forme autonome de gestion du SaaS. Productiv aussi est sorti, parce qu’il ne respectait pas complètement le critère d’orchestration de workflows. Quant à Trelica, il a été acquis par 1Password (que nous ne signalons ainsi pas, dans les tableaux ci-dessus, comme un nouvel entrant).
Les « leaders » mis à part, la quasi-totalité des offreurs sont dans la catégorie « acteurs de niche », témoin de la faible maturité du marché.
Plage de support limitée chez BetterCloud
BetterCloud se distingue par son adaptation à l’évolution des besoins. Les acquisitions de G2 Track et de Tricent ont enrichi son offre, respectivement sur la gestion des dépenses et la gouvernance du partage de fichiers. Gartner salue aussi un ciblage efficace des acheteurs IT, finance et sécurité, avec une stratégie de ristournes flexible. Bon point également pour la cadence de livraison de nouvelles fonctionnalités.
BetterCloud ne permet pas de choisir la localisation des données et n’assure de support que du lundi au vendredi entre 8 heures et 20 heures (heure de l’Est*). Sa tarification est plus élevée que la moyenne du marché (modèle à trois niveaux et module complémentaire pour la gouvernance). Gartner note aussi l’absence d’extension de navigateur pour la découverte de l’usage du SaaS.
Flexera n’a pas fini d’intégrer Snow Software
Flexera bénéficie d’une présence physique mondiale (États-Unis, Canada, Brésil, Royaume-Uni, Suède, Australie, Inde) et d’un réseau d’intégrateurs étendu. Gartner apprécie sa capacité de ciblage commercial, tant d’un point de vue sectoriel que géographique. Ainsi que ses prix, généralement plus bas que chez la concurrence et assortis d’une politique de ristournes flexible. Bon point également pour le marketing, qui, entre webinaires et événements physiques, alimente la notoriété de Flexera, y compris sur le SAM.
En attendant que soit finalisée l’intégration de Snow Software, Flexera ne propose pas de moyen de mesurer ou de stimuler l’adoption du SaaS. Gartner signale aussi l’inconsistance du support et de la qualité des partenaires intégrateurs. Il y ajoute le nombre limité d’intégrations directes par API.
La résidence des données, absente chez Torii…
Torri est crédité d’un bon point pour son recueil du feed-back, et par là même pour sa roadmap. Il l’est aussi pour sa cadence de livraison d’améliorations fonctionnelles. Et pour sa tendance à « anticiper » le besoi. En tout cas à introduire des capacités avant que la demande soit généralisée. Gartner en veut pour preuve l’usage de la GenAI pour, entre autres, traiter les contrats, enrichir les profils d’applications et concevoir des automatisations.
Comme chez BetterCloud, pas de choix de l’emplacement des données (Amérique du Nord uniquement). Si le licensing est flexible, Torii propose, avec son niveau Enterprise, l’une des offres les plus onéreuses de tout le Magic Quadrant. Plus « petit » que les autres « leaders », il n’a pas la même capacité pour passer à l’échelle ses équipes commerciales.
… et coûteuse chez Zluri
La tarification de base de Zluri est parmi les plus avantageuses du Magic Quadrant et elle s’assortit d’une stratégie intéressante de remise sur volume. Comme chez Flexera, le marketing est jugé efficace. L’intégration de l’IA l’est aussi (traitement des contrats, analyse de l’activité des utilisateurs, dimensionnement des licences…), d’autant plus qu’elle favorise la prise en main de la solution.
Zluri permet de choisir la localisation des données… mais c’est plus cher (le prix dépend, en particulier, de la taille de l’entreprise et du volume de données). Les avis sont de plus variés quant à la qualité du support et à l’efficacité de la solution. Par ailleurs, les éléments qui figurent en tête de la feuille n’apparaissent pas alignés sur les principales demandes des clients.
Avec Zylo, des coûts potentiellement difficiles à prévoir
Bon point marketing pour Zylo également, de son podcast et sa chaîne YouTube à son SaaS Management Index annuel. Gartner salue aussi la qualité de l’expérience client, entre customer success managers et méthodes de maximisation de la valeur. Il note aussi l’enrichissement de la bibliothèque d’applications (chacune incluant des informations financières, fonctionnels et de risque) et les capacités « exhaustives » de mesure d’adoption.
Chez Zylo, les données sont localisées exclusivement en Amérique du Nord. Et le personnel, exclusivement aux États-Unis (élément à prendre d’autant plus en compte dans le contexte géopolitique que l’on connaît). Vigilance aussi sur la tarification : il peut être difficile de la comprendre… et de prévoir les coûts. À noter également l’absence d’approche sectorielle sauf pour gouvernements et pharma.
* Fuseau horaire du Québec et de New York, entre autres. 6 heures de décalage avec Paris.
Google Cloud vient de conclure un contrat de plusieurs millions de dollars avec l’Agence de communication et d’information de l’OTAN (NCIA) pour fournir « des capacités cloud souveraines et hautement sécurisées » selon la filiale d’Alphabet. L’intégration de cette technologie doit intervenir dans les mois à venir.
L’accord repose sur Google Distributed Cloud air-gapped, une solution de la gamme Sovereign Cloud de Google. Un choix qui garantit à l’OTAN un niveau élevé de sécurité, d’autonomie et de résilience, quel que soit le volume ou la complexité des données traitées, selon l’hypersacler.
Tara Brady, président de Google Cloud EMEA, affirme que Google Cloud « s’engage à soutenir la mission principale de l’OTAN », en particulier la construction d’une infrastructure numérique robuste et l’adoption des innovations technologiques les plus avancées.
Antonio Calderon, directeur technique de la NCIA, souligne que l’agence cherche à exploiter les technologies de nouvelle génération, y compris l’IA, pour renforcer les capacités opérationnelles et protéger l’environnement numérique de l’Alliance.
Le Google Distributed Cloud air-gapped proposé à l’OTAN est conçu pour les environnements nécessitant des contrôles de la résidence et de la sécurité des données. Entièrement isolée, la plateforme garantit que les données sensibles de la NCIA restent sous contrôle direct et sur territoire souverain de l’OTAN. Elle offrira également des capacités analytiques avancées afin d’améliorer l’efficacité opérationnelle de l’Alliance, de ses alliés et de ses partenaires.
Depuis quelques jours, la communauté Arduino grince des dents : les nouvelles Conditions d’utilisation et la Politique de confidentialité, fraîchement mises en ligne après l’acquisition par Qualcomm, changent sensiblement la donne. Entre collecte élargie de données, droits très étendus sur les contenus publiés et restrictions de rétro-ingénierie, beaucoup s’interrogent : l’esprit open-source d’Arduino est-il en […]
Après les nombreux billets relatant mes pérégrinations à quasi chaque VMworld entre 2012 et 2020, me voilà reparti à la recherche du Graal de l’IT, cette fois dans une nouvelle dimension : le cloud public européen et souverain.
J'ai un peu le même ressenti que celui exprimé dans cet article. Dans l'idée j'adore ce qu'est NextCloud et c'est heureux qu'il existe pour offrir une véritable alternative ouverte aux GAFAMs, mais j'ai toujours eu cette impression de lourdeur qui me bloque un peu.
J'ai un peu le même ressenti que celui exprimé dans cet article. Dans l'idée j'adore ce qu'est NextCloud et c'est heureux qu'il existe pour offrir une véritable alternative ouverte aux GAFAMs, mais j'ai toujours eu cette impression de lourdeur qui me bloque un peu.
Connexion
