Le couperet est tombé : IBM arrête le support du CDKTF (Cloud Development Kit pour Terraform).
Cette boîte à outils permet de générer des fichiers de configuration en utilisant des langages impératifs (TypeScript, Python, Java, C# et Go). Elle s’inspire de l’AWS Cloud Development Kit – et en réutilise des bibliothèques.
IBM estime que le projet n’a pas trouvé sa place. Il est vrai que la traction sur les canaux communautaires et au-delà est restée minimale.
Le CDKTF n’a en tout cas jamais été stabilisé. Jusqu’à la dernière version, sortie en juin 2025, les changements non rétrocompatibles sont demeurés monnaie courante.
Un tout autre contexte qu’OpenTofu
Dans ce contexte, IBM s’affirme d’autant plus ouvert à l’idée d’un fork (le code est sous licence MPL). Ce n’est effectivement pas la même histoire qu’avec OpenTofu. Ce projet concurrent de Terraform avait émergé à l’été 2023. HashiCorp, alors encore indépendant, venait de changer la lience de ses produits. Exit la MPL (Mozilla Public License), place à la BSL (Business Source License), qui a eu pour principal effet d’interdire d’« embarquer » ou d’« héberger » les éditions communautaires desdits produits dans le cadre de toute offre commerciale destinée à un usage en prod.
Lancé sous l’impulsion d’entreprises dont le modèle économique reposait au moins en partie sur Terraform, OpenTofu avait été stabilisé début 2024. Entre-temps, une autre initiative avait vu le jour : OpenBao, pensé comme un substitut à Vault, autre produit HashiCorp.
IBM est offciellement devenu propriétaire de HashiCorp en février 2025, quasiment un an après avoir annoncé son projet d’acquisition. En attendant un éventuel fork du CDKTF, il invite à utiliser la commande cdktf synth –hcl pour convertir les fichiers .tf en HCL (HashiCorp Configuration Language).
Chez VMware, fini le catalogue de prix unifié pour l’EMEA (Europe, Moyen-Orient, Afrique).
Il y a désormais deux catalogues. Respectivement pour l’Espace économique européen (UE + Islande, Liechtenstein et Norvège) et pour les autres pays de cette zone.
VVF et vSphere Enterprise+ maintenus dans l’UE, mais jusqu’à quand ?
La différence n’est pas des moindres : hors de l’EEE, les offres VVF (vSphere Foundation) et VSEP (vSphere Enterprise+) ne sont plus commercialisées.
Ne restent que VSS (vSphere Standard) et VCF (Cloud Foundation).
Le premier change de modèle : il devient un SKU sans durée déterminée, à 70 $/cœur/an – soit le tarif jusque-là appliqué pour un an d’engagement.
Le second voit son prix augmenter de 350 à 400 $/cœur/an.
En parallèle, le module complémentaire Private AI Foundation n’est plus disponible.
La nouvelle politique commerciale hors EEE impose par ailleurs le fameux minimum de 72 cœurs.
Ce minimum s’entend par ligne de commande – en d’autres termes, par édition de produit VMware. Broadcom l’appliquait déjà depuis avril… en dehors de l’EMEA. L’examen de son cas par la Commission européenne a probablement motivé cette exception et la décision de la faire perdurer dans l’EEE.
VCF comme offre unique : on y va tout droit
vSphere Enterprise+ avait disparu de la gamme VMware une première fois, quelques semaines après la fusion avec Broadcom. Il avait finalement été réintroduit en novembre 2024, sans vSAN (stockage) ni NSX (réseau).
Depuis, on l’a continûment dit en sursis. Comme vSphere Standard, qui n’est déjà plus vendu en APAC (Asie-Pacifique) depuis avril 2025 – et qui semble désormais ne plus l’être non plus en Amérique du Nord.
Ces offres sont d’autant plus sur la sellette qu’il n’est pas prévu qu’elles prennent en charge vSphere 9. Jusqu’à nouvel ordre, elles sont cantonnées au maximum à vSphere 8 (Update 3), dont le support général se termine en octobre 2027.
Les perspectives n’étaient pas beaucoup plus positives pour VVF. Surtout que VCF 9 a apporté plusieurs capacités favorisant les migrations depuis d’autres produits VMware, notamment pour l’importation NSX.
L’échéance approche : le 16 décembre 2025, la Matmut éteindra sa plate-forme data sur site.
Ce socle Spark-Hadoop avait été constitué en 2017, avec la stack open source Cloudera. Sur le papier, il est resté à son statut de PoC. Dans les faits, il est devenu de la prod.
En 2022, à l’arrivée d’un nouveau CDO, deux visions de modernisation se sont confrontées.
Le CTO prônait une plate-forme unifiée, avec un outil proche de ceux déjà en place. Une option qui assurerait un support éditeur large, mais induirait des efforts supplémentaires de développement pour les équipes data, de gestion pour les équipes de production, et de formation pour l’usage par toutes les entités.
Le CDO portait l’idée d’une plate-forme full open source – toujours on-prem – avec une multitude de fournisseurs. Il en découlerait le besoin d’assurer un support pour pléthore de services, en plus de l’aspect formation (sur des nouveaux outils : ML, orchestrateur…).
Chez S3NS, pas d’immunité au CLOUD Act… mais du chiffrement que la Matmut maîtrise
Dans ce contexte, la Matmut a étudié la possibilité d’aller chez un hyperscaler. Elle s’est tournée vers S3NS et son offre « Contrôles locaux » (récemment renommée CRYPT3NS).
Cette offre utilise des HSM (modules de sécurité matériels) fournis et hébergés par Thales. Elle « n’empêchera pas une instance américaine de demander à Google de dumper les données », a reconnu Jean-Jacques Mok, directeur de programme cloud au sein de la Direction du numérique et de l’innovation de la Matmut, lors du salon DEVOPS REX. Ce dump n’est toutefois pas fait en live, tempère-t-il : les données sont récupérées à froid. « Et ça tombe bien : c’est ce qui est crypté par le boîtier HSM. »
« Globalement, Google aura répondu aux injonctions, poursuit l’intéressé. Charge [aux États-Unis] de s’amuser ensuite à décrypter les données, [sachant que] les clés ne sont pas hébergées chez Google. » C’est effectivement la Matmut qui en a la maîtrise. Jean-Jacques Mok en donne une illustration : lorsqu’un des deux boîtiers HSM de la Matmut est tombé en panne, il a dû se rendre chez S3NS, qui ne pouvait pas lui-même en initialiser un autre.
Un socle BigQuery-Dataflow-Cloud Composer
La plate-forme montée chez S3NS s’articule autour de BigQuery, avec Dataflow pour les trasnsformations et Cloud Composer – version packagée d’Airflow – pour l’orchestration. « On a un peu déshabillé la mariée , admet Jean-Jacques Mok. C’est tout l’intérêt d’un cloud provider : on est venu chercher uniquement les services dont on avait besoin. »
Pour structurer les données, la Matmut est restée sur du classique : l’architecture médaillon (bronze = données brutes ; argent = données nettoyées ; or = données spécialisées). Il y a ajouté une zone vermeille ; qui, par rapport à la zone argent, est agnostique de la source des données.
Une autre zone, dite zone relais, a été mise en place. Une exigence « portée par les execs ». S’y trouvent toutes les données maîtres à envoyer vers le cloud.
La fin promise du « pot à bonbons »…
Le projet a duré environ un an et demi. « On [n’était] pas sur du lift & shift, mais sur une transformation de l’organisation data », précise Pascal Deshayes, président de TerraOps, qui a accompagné le projet (l’ESN a son siège à Rouen, comme la Matmut). Ne serait-ce que de par la transition depuis un système intégralement sur site, avec, entre autres, un CI/CD « pas du tout automatisé ».
Il a fallu faire avec les limites de l’offre « Contrôles locaux », tant en termes de versions que de nombre de services managés utilisables. Un avantage, néanmoins : la facilité de prise en main par les consultants habitués à GCP.
« Maintenant qu’on a des utilisateurs et de la donnée, il faut qu’on soit capable de maîtriser cette consommation », explique Jean-Jacques Mok. Aujourd’hui, l’IT à la Matmut est encore un « pot à bonbons », concède-t-il : « Tout le monde pioche dedans jusqu’à ce qu’il n’y [ait plus de budget]. »
… et des accès en « open bar »
L’offre « Cloud de confiance » – celle pour laquelle S3NS postule à la qualification SecNumCloud – est en ouverture généralisée depuis quelques mois. La Matmut ne l’a pas encore adoptée. Elle y est toutefois appelée : c’est l’une des conditions qui ont permis d’aller vers ces services.
Avec RGPD, DORA et CSRD en toile de fond, la migration est aussi l’occasion de mieux encadrer le lignage des données et les accès. « Sur l’ancienne plate-forme, c’était complètement open bar, déclare Jean-Jacques Mok. Là, on revient à un cadre plus standard : tu n’accèdes qu’à la donnée [qui t’est autorisée] et surtout, tu vas demander [aux propriétaires] le droit de la consommer ».
La Matmut ne le cache pas : quitter un mode Spark-Hadoop pour un monde orienté services managés basés sur BigQuery implique de retravailler le plan de carrière de certaines personnes. « Il faut qu’ils comprennent que le modèle SAS ne va pas durer éternellement », glisse Jean-Jacques Mok…
Langage commun, standardisation des processus, portabilité… Autant de notions dont Gaspard Plantrou, chef produit de Numspot, use pour vanter « l’indépendance numérique portée par Kubernetes ».
Cette grammaire se retrouve dans la dernière annonce de l’entreprise. Laquelle a décidé d’aller au-delà du socle OUTSCALE, en fournissant un plan de contrôle « à la Red Hat » unifiant la gestion des environnements d’infrastructure.
Kubernetes sera la base de cette plate-forme qui englobera des services managés et des fonctions data/IA (modèles, agents et RAG), avec une console et des API unifiées. Une marketplace de services préconfigurés y sera adossée. Numspot compte la déployer en Europe auprès de fournisseurs d’infrastructure, en s’alignant sur les référentiels nationaux équivalents à SecNumCloud. Une vente en marque blanche est envisagée. Des discussions sont en cours avec des sociétés en Allemagne, en Espagne et en Italie.
L’ensemble doit prendre forme au deuxième semestre 2026. Numspot promet une capacité d’adaptation « dynamique » du niveau de confiance. À commencer sur son infra chez OUTSCALE, composée d’une région eu-west « souveraine » et d’une région cloud-gov en cours de qualification SecNumCloud (J1 validé au printemps, audit J2 récemment finalisé).
Une dizaine de clients/projets référents
Pour le moment, 3 ans après sa création, Numspot a à son catalogue les services suivants :
Gestion : console et IaC
Calcul : VM et GPU NVIDIA
Réseau : VPC, IP publiques, VPN, DirectLink, load balancer
Stockage : bloc, objet, snapshots
Base de données : PostgreSQL
Conteneurs : Kubernetes et OpenShift
Sécurité/identité : IAM
Une brique d’observabilité (logging et métriques) est sur la roadmap. On y trouve aussi un registre de conteneurs, un catalogue d’images de VM, du BYOK, du MongoDB et du Redis-like, du KMS, un WAF et du CI/CD (GitLab).
Numspot liste 25 partenaires dont 10 éditeurs (ALLONIA, CEO-Vision, Cleyrop, CobolCloud, Denodo, Docaposte, Energisme, Red Hat, Veeam et VirtualBrowser). Il nomme une dizaine de clients/projets référents, dans la finance/assurance, la santé et le secteur public :
CISIRH (Centre interministériel de services informatiques relatifs aux ressources humaines)
CNP Assurances
Docaposte
Domelior (services de soins à domicile ; petite entreprise bretonne)
ERAFP (complémentaire de la fonction publique)
Maisons France services
M.I.A. Seconde (application d’adaptive learning pour les professeurs en seconde générale)
Pavillon de la Mutualité (groupe d’offre de soins mutualiste en Nouvelle-Aquitaine)
Perfecto Groupe (agence de com francilienne)
Service civique national
Union Retraite (GIP qui réunit les organismes de retraite obligatoire, de base et complémentaire)
Face à l’essor fulgurant de l’IA, les services publics ne peuvent plus rester à la porte du cloud, surtout quand les données les plus sensibles sont en jeu. Le défi : construire un cloud souverain européen qui combine niveau de sécurité maximal, agilité technologique et capacité à faire tourner des workloads d’IA à l’échelle. La […]
La bataille du cloud se joue aussi sur le CPU. Pour les hyperscalers et pour AWS en particulier, précurseur avant tout le monde, les processeurs ne sont pas que des composants essentiels à toute infrastructure informatique. Ils sont un levier direct pour vendre moins cher et consommer moins à l’échelle planétaire. Avec son nouveau Graviton5, […]
Pour accéder au catalogue Gaia-X du CISPE, attention à ne pas suivre le lien que l’association affiche sur la page d’accueil de son site.
Nous en avons fait l’amère expérience. Ledit lien pointe vers une ancienne version du catalogue… qui n’est que partiellement fonctionnelle. Certains filtres sont inopérants (localisation des services, par exemple) tandis que d’autres ne renvoient aucun résultat (tri par fournisseur, par certification, par label Gaia-X). De nombreuses fiches sont par ailleurs en doublon voire plus ; et sur chacune, le JSON source est inaccessible (erreur 503). Les contenus mêmes ne sont plus à jour, reflétant les principes de Gaia-X tels qu’ils étaient essentiellement fin 2022.
Une maintenance depuis la France
À la « bonne » adresse, la spécification Gaia-X référente est celle de mars 2025. L’enregistrement des services passe toujours par le CISPE (démarche gratuite pour les membres et les affiliés). L’exploitation et la maintenance du catalogue restent à la charge de Cloud Data Engine, SASU francilienne née en 2023, quelques semaines avant le passage en prod.
Les services listés respectent un socle minimal d’exigences – dit « conforité standard » – attendues pour pouvoir participer à l’écosystème Gaia-X. Ils peuvent être labellisés à trois niveaux supplémentaires.
Le premier comporte des exigences en matière de droit applicable, de gouvernance et de transparence. Il est obtenu sur la base d’une autocertification.
Le deuxième requiert une possibilité de traiter les données en Europe uniquement. Le troisième ajoute des critères pour assurer l’immunité aux lois extra-européennes. L’un et l’autre impliquent un audit tiers sur la protection des données et la cybersécurité ; pas sur la portabilité et la soutenabilité.
De premières offres labellisées Gaia-X niveau 3
À l’occasion du Sommet Gaia-X 2025, le CISPE a mis en lumière l’intégration d’un premier bouquet d’offres de services labellisées au niveau 3. Au nombre de 9, elles émanent de 5 fournisseurs. Dont 3 français :
Cloud Temple (IaaS open source, IaaS bare metal et PaaS OpenShift)
OVHcloud (Hosted Private Cloud by VMware)
Thésée Datacenter (hébergement dans ses deux datacenters des Yvelines)
Les étiquettes désignant les autres niveaux de conformité n’ont encore été attachées à aucun service (elles l’étaient pour quelques-uns dans l’ancienne version du catalogue).
Cloud Temple rejoint Ikoula, OVHcloud et Thésée Data Center
Côté certifications, certaines étiquettes n’ont, là aussi, pas encore été massivement attribuées. Illustration avec le code de conduite SWIPO, actuellement associé à seulement 4 services.
D’autres étiquettes, à l’instar de C5 (le « SecNumCloud allemand »), ne retournent quasiment pas de résultats, faute de fournisseurs nationaux référencés dans le catalogue. Pour le moment ils sont 13 :
Quatre français (Cloud Temple, Ikoula, OVHcloud, Thésée Data Center)
Deux espagnols (Gigas Hosting, Jotelulu)
Cinq italiens (Aruba, CoreTech, Netalia, Opiquad, Seeweb)
Un néerlandais (Leaseweb)
Un américain (AWS)
Cloud Temple – non membre du CISPE, comme OVHcloud et Thésée Data Center – et Seeweb étaient les seuls de ces fournisseurs à ne pas figurer dans l’ancienne version du catalogue*.
Les quelque 600 services référencés sont presque tous localisés dans l’UE. Les 15 exceptions (États-Unis, Canada, Australie, Singapour) sont liées à OVHcloud.
Les tags relatifs aux catégories de services visent large. « Authentification », par exemple, est attribué autant au remote desktop et au PBX virtuel de Jotelulu qu’à l’hébergement web et au Veeam d’OVHcloud.
* Son intégration « a posteriori » se ressent : elle ne respecte par l’ordre alphabétique (Cloud Temple est positionné après CoreTech dans la liste déroulante du filtre fournisseurs).
Bonsoir ! Un nouvel entretien pour que vous passiez un bon week-end enrichissant en matière d’IT et de cloud, celui de Christophe Le Lesur, co-CEO de Cloud Temple… Mais qu’est-ce donc que ce co-CEO ? Je vous en dis bien plus dans cet article :)
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 […]
Connexion
