Avec 83 % des dépenses IT des grandes entreprises captées par des fournisseurs étrangers et une part de marché européenne marginale sur la plupart des segments critiques (OS, cloud, IA générative), l’UE fait face à des risques majeurs de souveraineté et de sécurité.
Ce dossier décrypte les données chiffrées de cette dépendance, analyse la matrice des risques économiques et géopolitiques associés, et illustre concrètement ces enjeux à travers le cas du secteur de l’énergie, où la cybersécurité repose massivement sur des solutions non européennes.
>Dépendances numériques de l’UE : une matrice des risques
L’étude commandée par le Parlement européen propose une matrice d’évaluation du « risque de souveraineté », sur trois axes (contrôle juridique, autonomie technique, indépendance stratégique) comportant chacun trois dimensions
La qualification SecNumCloud 3.2 de l’offre PREMI3NS de S3NS, fin 2025, a déclenché une vague de controverses dans le paysage IT.
Suffisamment pour que Vincent Strubel, le directeur général de l’ANSSI, prenne la plume pour publier une longue tribune sur LinkedIn. Un exercice de déminage pédagogique pour répondre aux « interrogations voire (aux) incompréhensions sur ce que fait et ne fait pas la qualification SecNumCloud ».
« Ce n’est pas une médaille en chocolat »
Premier rappel du patron de l’agence nationale de cybersécurité : SecNumCloud n’est ni une décision arbitraire, ni un choix politique. La qualification découle d’un processus formalisé d’évaluation sur la base d’exigences strictes. « Les règles, le processus et le niveau d’exigence sont les mêmes pour tous », martèle Vincent Strubel.
La procédure ? Longue et exigeante. Près de 1 200 points de contrôle vérifiés in situ par un évaluateur indépendant, sous le regard scrutateur de l’ANSSI qui « ne se prive pas de demander parfois à l’évaluateur d’approfondir son travail ou de réévaluer de manière plus stricte ses conclusions ». Un référentiel actualisé constamment depuis plus de dix ans. « Bref, ce n’est pas une médaille en chocolat, et ce n’est pas pour tout le monde », résume le directeur.
Se protéger du CLOUD Act… et du « kill switch »
Les risques liés au droit extra-territorial ? C’est le sujet qui monopolise l’attention. Vincent Strubel rappelle l’enjeu : éviter que les données hébergées dans le cloud ne tombent sous le coup du CLOUD Act américain ou de la loi chinoise sur le renseignement de 2017, qui permettent aux autorités d’exiger l’accès aux données de clients européens.
La parade de SecNumCloud : un prestataire européen qui contrôle seul les données. Même si l’offre est « hybride » et repose sur une technologie américaine, « le fournisseur de la technologie cloud est soumis aux lois américaines, mais n’a pas accès aux données et ne peut par conséquent pas donner suite à une injonction », explique le patron de l’ANSSI.
Autre protection : le scénario du « kill switch », cette coupure brutale du service imposée à certains clients. Vincent Strubel cite l’exemple récent de magistrats de la Cour Pénale Internationale privés d’accès aux services numériques américains. Avec SecNumCloud, le sous-traitant non européen « ne dispose pas de la capacité à couper le service à tel ou tel client, car ce n’est pas lui qui administre la solution ».
L’autarcie complète, une illusion
Vincent Strubel le reconnaît sans détour : SecNumCloud ne signifie pas l’absence de dépendance. Une offre « hybride » est « sans doute plus exposée à ce risque, « mais imaginer qu’il existe des offres 100% européennes relève de la pure vue de l’esprit qui ne résiste pas à la confrontation aux faits ».
Tous les fournisseurs de cloud dépendent de composants électroniques et logiciels non maîtrisés à 100% en Europe. L’open source ? « Une plus grande liberté d’action », certes, mais « pas la panacée » : aucun acteur ne peut prétendre maîtriser entièrement toute la stack technologique du cloud.
« Si nous sommes un jour privés de l’accès à la technologie américaine, chinoise, ou plus généralement non européenne, nous aurons un problème global de dégradation du niveau de sécurité », prévient le directeur de l’ANSSI. Un problème qui dépasserait largement les seules offres hybrides.
Les cyberattaques, la vraie menace
Vincent Strubel le martèle : les critères liés à la nationalité du prestataire ne représentent
« qu’une petite partie des exigences » du référentiel. La vraie menace ? Les cyberattaques, qui demeurent « la menace la plus tangible pesant sur les usages sensibles du cloud ».
Les prestataires, « quelle que soit leur nationalité », sont des «cibles à très haute valeur ajoutée » qui « subissent en permanence des tentatives d’attaque, y compris particulièrement avancées, dont certaines réussissent forcément ». Hyperscalers américains comme acteurs européens, personne n’est épargné.
D’où des exigences techniques drastiques : cloisonnement fort entre clients, chaîne d’administration isolée, gestion sécurisée des mises à jour, chiffrement systématique. « Ces exigences ne sont généralement pas toutes satisfaites par une offre de cloud standard, quelle que soit son origine », note le directeur de l’ANSSI.
Le référentiel prend même en compte le risque humain : corruption, contrainte ou infiltration d’employés du prestataire. Un chapitre entier y est consacré.
« Souverain », mais pas baguette magique
SecNumCloud est-il un label de souveraineté ? Vincent Strubel botte en touche : « Il est difficile de répondre à cette question, vu que le concept de souveraineté numérique n’est quasiment jamais défini, et que tout le monde lui donne un sens différent ».
Pour l’ANSSI, la souveraineté numérique couvre trois enjeux : ne pas être une victime facile des cyberattaques, faire appliquer nos règles plutôt que subir celles des autres, et disposer d’une liberté de choix technologique. SecNumCloud répond aux deux premiers et contribue au troisième.
« Les offres qualifiées SecNumCloud sont donc, sans le moindre doute, souveraines, et cette qualification est un levier indispensable pour défendre notre souveraineté numérique », affirme Vincent Strubel. Mais il avertit aussitôt : cette qualification « ne va pas faire naître des solutions alternatives ou des briques technologiques maîtrisées »». « C’est un outil de cybersécurité, pas de politique industrielle. »
Hybride ou non, même combat
Le directeur de l’ANSSI tord le cou à une idée reçue : les offres « hybrides » qualifiées « satisfont exactement les mêmes exigences que les autres ». La distinction entre hybride et non-hybride ? « Assez artificielle », tranche-t-il. « Il n’y a pas d’un côté des offres totalement dépendantes de fournisseurs non européens et de l’autre des offres 100% européennes. »
Certains réclament un label light, reprenant uniquement les critères capitalistiques sans les exigences techniques. Vincent Strubel balaie l’idée : « Du point de vue de la cybersécurité, ça n’aurait aucun sens de couvrir uniquement certaines menaces, et pas d’autres.» Une solution doit couvrir tous les risques, « car les attaquants visent toujours le maillon faible ».
Son image choc : « Un cloud échappant au droit non européen, mais à la merci des cyberattaques, ça n’a pas plus de sens qu’une maison avec des volets blindés et des barreaux aux fenêtres, mais dont la porte serait fermée par un rideau.»
Même refus pour un label purement technique : impossible de couvrir les risques juridiques par la seule technique. Le chiffrement des données, par exemple, « ne protège pas du CLOUD Act : le prestataire de cloud a forcément, tôt ou tard, accès à la clé de chiffrement ».
Urgence pour le système de découverte de services : la capacité actuelle du plan de contrôle pourrait être épuisée à l’horizon 2025.
LinkedIn avait fait ce constat à l’été 2022. En conséquence, il avait lancé un chantier de modernisation.
Élasticité, compatibilité… Le plan de contrôle ZooKeeper arrivait à ses limites
Le plan de contrôle reposait alors sur ZooKeeper. Il avait une structure plate. Les applications serveur y enregistraient leurs points de terminaison en tant que nœuds éphémères, sous forme d’URI D2 (Dynamic Discovery). Les applications clientes lui adressaient des requêtes en lecture pour suivre les clusters qui les intéressaient.
Cette approche présentait des limites en termes d’élasticité. ZooKeeper étant un système à cohérence forte, toutes les lectures et les écritures, ainsi que les vérifications d’intégrité des nœuds, passaient par la même file d’attente. Les requêtes étaient donc susceptibles de s’accumuler jusqu’au moment où certaines ne pourraient plus être traitées. En parallèle, des sessions pourraient être fermées en cas de timeout sur la vérification d’intégrité. S’ensuivraient une perte de capacité côté serveur et, in fine, des indisponibilités d’applications.
Autre limite : les entités D2 étant liées à des schémas spécifiques à LinkedIn, elles étaient incompatibles avec des data planes modernes comme gRPC et Envoy. De plus, l’implémentation de la logique de lecture/écriture dans les conteneurs applicatifs était focalisée sur Java. Par ailleurs, l’absence d’une couche intermédiaire entre le registre de services et les instances applicatives empêchait de développer des techniques de gestion RPC centralisées, par exemple pour le load balancing.
Kafka côté serveur, gRPC côté client
Le nouveau plan de contrôle introduit des composantes Kafka et Observer.
Kafka réceptionne les requêtes en écriture des serveurs et les informations d’intégrité sous forme d’événements, appelés URI de découverte de services.
La brique Observer consomme ces URI et les conserve en mémoire. Les applications clientes s’y abonnent en ouvrant un flux gRPC. Elles envoient leurs requêtes via le protocole xDS.
Les configurations D2 restent stockées dans ZooKeeper. Elles sont converties en entités xDS par les propriétaires d’applications puis distribuées à l’« observateur » de la même manière que les URI.
Les readiness probes de Kubernetes en ligne de mire
Dans cette architecture, l’élasticité et la disponibilité ont la priorité sur la cohérence. L’observateur, écrit en Go avec une concurrence forte, peut gérer 40 000 flux clients et 10 000 mises à jour par seconde tout en consommant 11 000 événements Kafka par seconde, selon LinkedIn.
Pour gagner encore en élasticité, il serait possible, au-delà d’augmenter le nombre d’observateurs, d’en créer deux types. D’un côté, des instances consommant les événements Kafka. De l’autre, des instances répondant aux requêtes des clients.
Comme il utilise xDS, le plan de contrôle est compatible avec Envoy ; ce qui ouvre la porte à un support multilangage. Et avec l’introduction de cette couche intermédiaire, il devient possible d’intégrer des fonctionnalités autour des maillages de services. Voire d’exploiter les readiness probes de Kubernetes pour faire passer les serveurs en mode passif et ainsi fiabiliser le système.
La latence P50 amenée sous la seconde
Le déploiement a été compliqué par la variété des clients (dépendances, accès réseau, SSL…). Pour beaucoup, il était difficile de prévoir le niveau de compatibilité.
Il a de surcroît fallu mener le chantier parallèlement sur les lectures et sur les écritures. Dans les grandes lignes, sans les unes, la migration des autres était bloquée. L’infrastructure d’origine a donc été conservée, dans une approche dual mode, Kafka étant la source primaire et ZooKeeper le backup (utilisé en cas d’absence de données Kafka). Une tâche cron a permis de jauger le niveau de dépendance des applications à ZooKeeper et de prioriser les migrations en conséquence.
Pour les lectures, les principaux éléments évalués côté client furent le délai entre l’envoi d’une requête d’abonnement et la réception des données, les erreurs de résolution de ces requêtes, ainsi que la cohérence entre la data de ZooKeeper et celle de Kafka. Côté observateur, LinkedIn a examiné le type, le nombre et la capacité des connexions clients, le délai entre la réception des requêtes et l’envoi des données vers la file d’attente, ainsi que les taux d’utilisation de ressources.
Pour les écritures, ont principalement été mesurés :
Latence et pertes de connexion sur ZooKeeper et kafka
Score de similarité des URI entre ZooKeeper et Kafka
Délai de propagation du cache (temps entre réception des données et mise à jour du cache)
LinkedIn affirme que 50 % des clients obtiennent désormais les données en moins de 1 seconde et 99 % en moins de 5 secondes. Sur le plan de contrôle ZooKeeper, les latences P50 et P99 étaient respectivement à 10 et 30 secondes.
À consulter en complément, d’autres retex impliquant Kafka et/ou ZooKeeper :
Le déploiement instantané, c’est pratique, mais rarement indispensable.
Cloudflare contextualise ainsi sa décision d’appliquer aux changements de configuration le même processus de contrôle que pour le code.
Lors de mises à jour logicielles, chaque version binaire a plusieurs étapes de validation à franchir. Toute équipe possédant un service doit définir un plan de déploiement, des indicateurs de réussite/échec et les actions à entreprendre en cas de problème. Un système automatisé exécute ce plan et déclenche si nécessaire une restauration, en alertant éventuellement l’équipe.
Ce mécanisme sera également appliqué aux changements de configuration d’ici à fin mars sur toute la prod, nous promet-on.
En toile de fond, les deux pannes importantes survenues le 18 novembre et le 5 décembre 2025. L’un et l’autre furent déclenchées par un changement de configuration (dans le classificateur de bots pour la première ; dans un outil de sécurité pour la seconde).
Isoler les défaillances
Cloudflare a un autre engagement d’ici à fin mars : réviser les contrats d’interface entre chaque produit et service critique, pour mieux anticiper et isoler les défaillances.
L’incident de novembre est un exemple en la matière. Deux interfaces-clés auraient pu être gérées différemment, estime Cloudflare. D’une part, celle qui lisait le fichier de configuration (il aurait dû exister un ensemble de valeur par défaut validées permettant au trafic de continuer à circuler). De l’autre, celle située entre le logiciel central et le module de gestion des bots (en cas de défaillance de ce dernier, le trafic n’aurait pas dû être bloqué par défaut).
Éliminer – ou contourner – les dépendances circulaires
Cloudflare entend aussi supprimer les dépendances circulaires, ou tout du moins permettre de les « contourner » rapidement en cas d’incident. Exemple : lors de l’incident de novembre, l’indisponibilité de Turnstile (alternative aux CAPTCHA) a empêché les clients d’accéder au tableau de bord à moins qu’ils eussent une session active ou un jeton d’API.
En parallèle, il est question de faire évoluer les procédures internes de type break glass (élévations temporaires de privilèges) pour avoir accès aux bons outils le plus rapidement possible.
Un « code orange » pour la deuxième fois
Pour mettre en place ce plan de résilience, Cloudflare a décrété un « code orange ». Cette procédure permet de réorienter la plupart des ressources techniques vers la résolution d’un incident. Elle a été mise en œuvre une fois par le passé. C’était fin 2023, après une panne de courant dans un des principaux datacenters de Cloudflare (PDX01, dans l’Oregon), hébergeant le plan de contrôle de nombreux services. Le déclencheur : des opérations de maintenance réalisées par l’exploitant du réseau électrique et qui avaient entraîné un défaut de terre dans l’installation.
Alphabet, maison mère de Google, vient d’annoncer l’acquisition d’Intersect pour 4,75 milliards $ en cash, auxquels s’ajoute la reprise de la dette existante. Cette opération représente l’une de ses transactions les plus importantes et marque un tournant dans sa stratégie de développement de centres de données dédiés à l’IA.
L’enjeu est de taille : permettre à Google d’accéder à davantage d’électricité pour ses infrastructures, alors que le réseau électrique américain, vieillissant, peine à absorber une demande énergétique qui explose pour la première fois depuis des décennies. L’IA constitue le principal moteur de cette croissance fulgurante.
« Intersect nous aidera à accroître nos capacités, à opérer avec plus d’agilité dans la construction de nouvelles centrales électriques en phase avec la nouvelle charge des centres de données, et à repenser les solutions énergétiques pour stimuler l’innovation et le leadership des États-Unis » déclare Sundar Pichai, directeur général de Google et d’Alphabet.
Un portefeuille énergétique impressionnant
Aux termes de cet accord, Alphabet achète les projets énergétiques et de centres de données d’Intersect, qu’ils soient en développement ou en construction. L’entreprise possède 15 milliards $ d’actifs en exploitation ou en construction.
Elle exploite actuellement environ 7,5 gigawatts de capacité solaire et de stockage, et prévoit de développer 8 gigawatts supplémentaires. Pour référence, un gigawatt équivaut approximativement à la production d’un réacteur nucléaire et peut alimenter environ 750 000 foyers. L’essentiel de cette capacité est concentré au Texas.
Son PDG, Sheldon Kimber, avait d’ailleurs surnommé le Texas le « Disneyland de l’énergie » en raison de ses abondantes ressources éoliennes et solaires. Parmi ses projets phares dans cet État figure « Quantum », un système de stockage d’énergie propre construit directement à côté d’un campus de centres de données pour Google.
L’opération s’inscrit dans une stratégie plus large d’Alphabet dans le secteur énergétique. Google, en partenariat avec TPG Rise Climate, avait déjà soutenu Intersect lors d’une levée de fonds de plus de 800 millions $ en décembre 2024.
Une structure d’acquisition sur mesure
Dans le cadre de cet accord, Alphabet acquiert la plateforme de développement et les effectifs d’Intersect, y compris les actifs en développement déjà sous contrat avec Google. Intersect conservera sa propre marque et restera dirigée par Sheldon Kimber.
Les actifs opérationnels existants de la société au Texas, ainsi que ses actifs opérationnels et en développement en Californie, ne seront pas inclus dans l’acquisition et continueront de fonctionner comme une entreprise indépendante, soutenue par ses investisseurs actuels. TPG Rise Climate conservera une participation dans ces actifs.
Intersect explorera également un éventail de technologies émergentes pour accroître et diversifier l’approvisionnement énergétique, tout en soutenant les investissements de Google dans ses centres de données américains.
« En acquérant un développeur et pas seulement un contrat d’achat d’électricité, Google s’offre la flexibilité nécessaire pour construire où et quand il le souhaite » estime Ben Hertz-Shargel, analyste du cabinet Wood Mackenzie cité par Bloomberg.
Alibaba, géant chinois du numérique et de l’infrastructure cloud, poursuit sa stratégie IA « full stack » articulée autour de ses modèles Qwen (LLM) et Wan (génération visuelle/vidéo). Le groupe lance Wan2.6, un modèle concurrent de Veo3 et Sora 2 qui promet d’abaisser la barrière d’entrée de la vidéo IA en combinant génération d’images, de […]
Et si nous développions un portail collaboratif communautaire ?
OPENALIS.NET est un projet 100% open source en recherche d'un coup de boost pour arriver sur le marché FR très prochainement.
Un premier tour de table sera mené à partir de la fin du premier trimestre 2026 en fonction des retours de potentiels investisseurs afin de créer une nouvelle structure proposant LE portail collaboratif libre FR à la fois pour les particuliers et les entreprises.
(NdM.:LE ça semble ambitieux pour un nouveau projet avec Cozy/Twake, Nextcloud, Yunohost, etc. en libre sur des secteurs similaires)
Un accès simple pour tout le monde et une plateforme crédible pour les entreprises.
(Le nom du projet est voué à changer par la suite.)
Lors du dernier salon de l'OSXP sur Paris, OPENALIS.NET a reçu un accueil très chaleureux.
Avec plusieurs centaines de participants à cette campagne nous pourrions changer définitivement la donne en termes d'alternative souveraine sur notre sol et partout ailleurs.
Le vrai « AWS re:Invent » se joue souvent loin des keynotes “agents partout”. Plusieurs annonces « invisibles » reconfigurent déjà l’architecture et l’exploitation au quotidien.. Un second regard sur l’un des évènements IT majeurs de l’année 2025… Chaque année, AWS re:Invent s’impose comme la grand-messe du cloud. Et comme depuis quelques années le même scénario se […]
La plateforme data est devenue l’infrastructure critique pour industrialiser l’IA générative sans perdre le contrôle des données propriétaires, de la gouvernance et de la sécurité. Databricks accélère ce mouvement avec une seconde levée de fonds XL en 2025, une Série L qui semble préparer une prochaine introduction en bourse. Depuis l’explosion de l’IA générative, les […]
Chez les principaux fournisseurs de bases de données cloud, il n’est plus si rare que des produits se chevauchent.
La synthèse du dernier Magic Quadrant dédié à ce marché en témoigne. La majorité des « leaders » (5 sur 9) ont droit à une remarque à ce sujet :
Alibaba Cloud
Chevauchement entre AnalyticDB et Hologres (analytique) comme entre DMS et DataWorks (intégration de données).
AWS
Grand choix de SGBD et d’options d’intégration… au prix de chevauchements et de conflits.
Google
Plusieurs solutions pour Postgre (Cloud SQL, AlloyDB, Spanner) entre lesquelles il faut faire la balance.
IBM
Chevauchements sur la partie entrepôt de données, entre les offres Db2 Warehouse, Neterra watsonx.data.
Microsoft
Concurrence entre Azure Synapse, Microsoft Fabric et Azure Databricks.
Gérer les coûts reste un défi
Autre sujet largement partagé parmi les « leaders » : la gestion des coûts.
Elle est difficile chez AWS faute de tarification unifiée entre services.
Elle l’est aussi pour beaucoup de clients de Databricks, malgré des avancées sur l’outillage FinOps.
Chez Google, elle a tendance à se complexifier avec l’intégration de nouvelles fonctionnalités.
Concernant Oracle, la clientèle se plaint toujours des prix et de la difficulté de contractualisation, même si la tendance s’atténue avec le passage au cloud et son modèle de facturation à l’usage.
Concernant Snowflake, Gartner a un jugement plus spécifique : le côté « user-friendly » est susceptible de favoriser le développement d’un état d’esprit « black box », et par là même de limiter la capacité à optimiser les workloads.
Plusieurs de ces fournisseurs avaient déjà été épinglés à ce sujet il y a un an, dans l’édition précédente de ce Magic Quadrant.
Databricks, à cause de la difficulté à prédire les coûts avec le modèle fondé sur des unités de consommation.
Google, parce que le suivi des dépenses pouvait se révéler délicat, a fortiori lorsqu’on interfaçait aux bases de données des services fondés sur des unités de consommation.
Oracle, perçu, de par son historique, comme un fournisseur aux offres onéreuses.
Alibaba, chez qui la variété des modèles de pricing, combinée à une facturation découplée pour certaines ressources au nom de la flexibilité, pouvait s’avérer difficile à maîtriser.
20 fournisseurs, 9 « leaders »
D’une année à l’autre, les critères à respecter ont peu évolué. Il fallait toujours, entre autres, gérer au moins un cas d’usage parmi :
Transactionnel
Transactions « légères » (gros volumes à haute concurrence et basse latence)
Gestion d’état d’applications
Data warehouse
Lakehouse
Analyse d’événements
Une fois encore, Gartner n’a évalué que les offres managées, fournies en cloud public ou privé. Il n’a pas pris en compte les bases de données hébergées sur du IaaS.
Les 20 fournisseurs classés sont les mêmes que l’an dernier. Et les 9 « leaders » d’alors le sont restés. Dans l’ordre alphabétique : Alibaba Cloud, AWS, Databricks, Google, IBM, Microsoft, MongoDB, Oracle et Snowflake.
Sur l’axe « exécution », reflétant la capacité à répondre à la demande, la situation est la suivante :
Rang
Fournisseur
Évolution annuelle
1
AWS
=
2
Google
=
3
Microsoft
+ 1
4
Oracle
– 1
5
Databricks
=
6
Snowflake
+ 1
7
MongoDB
– 1
8
IBM
+ 2
9
Alibaba Cloud
– 1
10
InterSystems
– 1
11
Huawei Cloud
=
12
SAP
=
13
Teradata
=
14
Cloudera
=
15
Couchbase
+ 3
16
SingleStore
+ 1
17
EDB
+ 3
18
Redis
– 3
19
Neo4j
– 3
20
Cockroach Labs
– 1
Sur l’axe « vision », reflétant les stratégies :
Rang
Fournisseur
Évolution annuelle
1
Google
=
2
Databricks
+ 3
3
Microsoft
– 1
4
Oracle
– 1
5
AWS
– 1
6
Snowflake
+ 2
7
Alibaba Cloud
+ 3
8
IBM
– 1
9
SAP
– 3
10
Teradata
– 1
11
MongoDB
=
12
Cloudera
=
13
InterSystems
+ 2
14
Neo4j
=
15
Huawei Cloud
+ 1
16
EDB
+ 4
17
Couchbase
=
18
SingleStore
=
19
Redis
– 6
20
Cockroach Labs
– 1
Alibaba Cloud, distingué pour son approche « data + IA »…
Les principales offres d’Alibaba Cloud sur ce marché sont PolarDB et ApsaraDB (transactionnel), AnalyticDB et MaxCompute (analytique), Tair et Lindorm (clé-valeur).
L’a dernier, le groupe chinois avait été salué pour sa présence sectorielle importante et différenciée, le développement de son écosystème de partenaires et le poids de sa communauté open source.
Cette année, Gartner apprécie la tarification, jugée attractive. Ainsi que la fiabilité de l’architecture serverless. Désormais étendue à tous les SGBD, elle se distingue par son architecture découplant calcul, mémoire et stockage en environnement hybride. Bon point également pour l’approche « data + IA » qui permet de développer et de déployer des applications en n’utilisant que des technologies d’Alibaba Cloud.
… mais pas pour la configuration de PolarDB
L’an dernier, Gartner avait pointé, au-delà de la gestion des coûts, le risque géopolitique associé à Alibaba Cloud. Ainsi que la disponibilité encore limitée de ses servies hors de l’Asie (moins de régions et de zones de disponibilité que la concurrence).
Cette année encore, la faible présence hors Asie est signalée. Elle peut se traduire par un moins grand nombre d’intégrations d’outils tiers et de ressources en anglais (documentation, formation, support). Attention aussi à la configuration de PolarDB, jugée complexe par les nouveaux utilisateurs, notamment sur l’équilibre coût/performance et la gestion du stockage multicouche. Il faut y ajouter les chevauchements de produits sus-évoqués.
AWS a un catalogue d’une ampleur sans égale…
Aurora, Redshift, DynamoDB et SageMaker font partie des principaux produits d’AWS sur ce marché.
L’an dernier, Gartner avait salué la couverture fonctionnelle d’AWS et sa capacité à créer du liant entre ses solutions. Il avait aussi noté l’exhaustivité des partenariats et de la présence géographique.
Ce dernier point vaut toujours et s’assortit d’un bon historique de disponibilité de l’infrastructure ainsi que d’une approche « proactive » de dialogue avec le client pour l’optimisation des coûts. AWS a, plus globalement, un catalogue d’une ampleur sans égale sur ce marché, avec SageMaker comme point central de gouvernance data/IA.
… mais des dépendances pour l’orchestration hybride
L’intégration entre les services d’AWS peut être complexe, avait souligné Gartner l’an dernier. Le cabinet américain avait aussi constaté que la prise en charge des déploiements hybrides/multicloud était limitée malgré la disponibilité de connecteurs natifs et le support de moteurs comme Spark (les clients tendent à utiliser des orchestrateurs tiers, avait-il expliqué).
Ce dernier constat est toujours d’actualité : beaucoup de clients dépendent de solutions tierces pour l’orchestration hybride/multicloud. S’y ajoutent les deux éléments sus-évoqués : gestion des coûts difficile et chevauchements entre produits.
Databricks, rapide pour innover…
Outre Data Intelligence Platform (qui inclut Unity Catalog), Databricks propose du data warehouse avec Databricks SQL, du transactionnel avec Lakebase, ainsi que de l’intégration et de l’engineering avec Lakeflow.
L’an dernier, Gartner avait salué les investissements dans la GenAI (dont l’acquisition de MosaicML), traduits par le développement de ses propres LLM. Il avait aussi donne un bon point au catalogue Unity (qui venait d’être basculé en open source) et au format Delta Lake (concurrent d’Iceberg).
Cette année, Databricks est salué pour sa « vision lakehouse », bien qu’il ne soit plus seul sur ce marché. Il l’est aussi pour sa cadence d’innovation, entre la composante Agent Bricks (qui a reçu des fonctionnalités importantes presque tous les mois), l’acquisition de Tabular (qui a accompagné la prise en charge d’Iceberg sur tout le portefeuile) et l’introduction de capacités low code dans Lakeflow. Bon point également pour l’engagement sur des standards ouverts (Delta Lake, Iceberg, Spark, Postgre…) qui favorisent la portabilité.
… mais pas si simple à prendre en main
L’an dernier, Gartner avait pointé le manque d’intuitivité de l’UI, qui changeait fréquemment tout en manquant de documentation et de capacités low code. Il y avait ajouté l’aspect FinOps, sus-évoqué.
Cette année, le cabinet américain met un bémol à la logique d’ouverture : certains clients s’inquiètent d’un éventuel verrouillage au niveau de l’orchestration et de Delta Live Tables (devenu Lakeflow Spark Declarative Pipelines). Il souligne par ailleurs la tendance des clients à juger que l’usage de la solution exige un haut niveau de compétence technique. En parallèle, le sujet FinOps reste valable (voir ci-dessus).
Google, bien positionné sur l’IA…
Entre autres produits positionnés sur ce marché, Google a Spanner, BigQuery, AlloyDB, Cloud SQL, Firestore, Memorystore et Bigtable.
L’an dernier, Gartner avait salué les contributions open source (à PostgreSQL en particulier). Il avait fait de même pour les avancées dans la GenAI (intégration de Gemini + support transversal de la recherche vectorielle via LangChain) et pour la fondation data/IA unifiée avec Dataplex pour la gouvernance.
Cette fondation data/IA a à nouveau droit à un bon point ; dans les grandes lignes, pour les mêmes motifs. Gartner note plus globalement la capacité de l’offre SGBD de Google à couvrir les cas d’usage dans l’IA agentique. Et apprécie en particulier l’exhaustivité des modèles de données pris en charge par Spanner (relationnel, clé-valeur, graphe, vectoriel).
… mais moins sur le partage de données
Le réseau de partenaires doit encore se développer, avait estimé Gartner l’an dernier. Il avait aussi pointé l’aspect FinOps et souligné que Google proposait moins d’options que la concurrence pour l’intégration native d’applicaitons et le master data management.
Cette année, outre la gestion des coûts et les chevauchements sus-évoqués, un point de vigilance va à la marketplace de données et aux capacités de partage. Elle se révèlent moins avancées que chez certains concurrents, malgré des améliorations sur les clean rooms et l’interopérabilité entre clouds.
IBM étend sa présence multicloud…
Les principaux SGBD cloud d’IBM sont Db2 (transactionnel + analytique) et watsonx.data (lakehouse).
L’an dernier, Big Blue s’était distingué sur sa stratégie sectorielle (solutions spécifiques adaptées sur la gouvernance, la sécurité et la conformité). Ainsi que sur sa capacité à combiner les expertises en open source et en data management au service des déploiements hybrides. Son offre est bien adaptée aux applications critiques, avait ajouté Gartner.
Cette année encore, la stratégie sectorielle est saluée. L’extension de la présence cloud l’est aussi (mise à disposition de Db2 chez les hyperscalers et acquisition de DataStax, qui a une forte présence multicloud). Bon point également pour l’approche « bien définie » d’IBM concernant l’intégration des SGBD dans les frameworks de data management.
… mais a toujours du mal à faire passer son message
IBM a du mal à se différencier dans la communication, par ailleurs pas uniforme entre équipes commerciales, avait expliqué Gartner l’a dernier. Il avait aussi rappelé que le déploiement géographique de l’offre n’atteignait pas encore celui des autres hyperscalers.
Les difficultés de communication restent d’actualité, occasionnant un certain manque de notoriété sur le segment. En parallèle, IBM demeure perçu comme un vendeur « legacy », ce qui est susceptible de détourner certains acheteurs. Gartner y ajoute, comme sus-évoqué, les chevauchements entre certains produits.
Une offre exhaustive chez Microsoft…
Entre autres produits, Microsoft évolue sur ce marché avec Azure SQL Database, Azure Database pour PostgreSQL et MySQL, ainsi qu’Azure Cosmos DB.
L’an dernier, Gartner avait salué l’exhaustivité de l’offre et le niveau d’intégration avec les autres services Microsoft. Il avait aussi apprécié les possibilités d’usage de l’IA pour le data management. Et les avancées sur la gestion du multicloud, exemplifiées par l’interconnexion Azure-Oracle comme par les « raccourcis » dans OneLake pour les analyses fédérées.
Bon point cette année encore pour l’exhaustivité de l’offre, qui « gère presque tous les modèles de données et cas d’usage sectoriels ». L’engagement de Microsoft sur PostgreSQL est également salué. Comme les innovations sur la partie IA (embeddings in-database, indexation de vecteurs, jonctions entre Copilot et Fabric…).
… mais une offre Fabric qui manque encore de maturité
Le chevauchement de certaines offres avait déjà été signalé l’an dernier, en sus de craintes des clients sur la pérennité d’Azure Synapse Analytics et d’Azure Database face à Microsoft Fabric. Ce dernier manquait encore de maturité, avait expliqué Gartner : les capacités d’intégration, de gouvernance et de gestion des métadonnées étaient moins « robustes » que chez d’autres « leaders ». Le déploiement pouvait par ailleurs se révéler complexe, en particulier pour le DR, la sécurité et la gestion des coûts.
Outre le chevauchement de certains produits, Gartner pointe à nouveau le manque de maturité de Microsot Fabric. Les inquiétudes des clients touchent autant aux fonctions data warehouse que gouvernance, entre souveraineté, dimensionnement des ressources, prix, gestion des métadonnées et data quality. Attention aussi aux investissements consentis pour intégrer le transactionnel dans Fabric : sur le court terme, ils peuvent engendrer des enjeux de performance.
MongoDB demeure un standard pour le modèle document…
Outre son édition communautaire et son produit sur site (Enterprise Advanced), MongoDB propose son SGBD Atlas chez AWS, Google et Microsoft.
L’an dernier, Gartner avait salué une offre « bien considérée » pour ses capacités de traitement à haut volume, son élasticité et la flexibilité du schéma. Il avait aussi souligné la souplesse et la rapidité d’implémentation, contribuant à la popularité auprès des développeurs.
Ce dernier élément vaut toujours et engendre un vivier de compétences d’autant plus grand. S’y ajoute la richesse des options de déploiement, accentuée par un programme de partenariats jugé « robuste ». MongoDB est plus globalement parvenu à établir une forme de standard pour qui souhaite un modèle orienté document.
… mais manque d’un storytelling sur la convergence transactionnel-analytique
Si MongoDB associe transactionnel et analytique, son offre se limite à du non relationnel, avait signalé Gartner l’an dernier. La concurrence s’accentue de la part de fournisseurs de SGBD qui incluent l’approche document en plus d’autres modèles, avait-il souligné ; sans compter ceux qui proposent une compatibilité MongoDB.
Cette remaruqe sur la concurrence accrue reste valable. Le cabinet américain y ajoute la courbe d’apprentissage nécessaire pour prendre en main le modèle MongoDB. Et le manque d’un storytelling complet l’intégration du transactionnel et de l’analytique.
Oracle, salué pour sa richesse fonctionnelle…
Autonomous AI Lakehouse, Autonomous JSON Database et Exadata Database Service font partie des SGBD cloud au catalogue d’Oracle.
L’an dernier, Gartner avait salué l’exhaustivité de l’offre (fonctionnalités + support de modèles modèles de données et de l’architecture lakehouse). Ainsi que le niveau de gestion du multicloud (offres Database@ + interconnexion avec les principaux hyperscalers) et la capacité à diffuser rapidement des nouveautés (GenAI, low code, consensus RAFT).
Cette année encore, la richesse fonctionnelle est saluée (bases de données distribuées, recherche vectorielle, framework agentique…). La diversité des options de déploiement l’est aussi. Comme l’adéquation de l’offre d’oracle aux applications critiques.
… mais peu adopté pour les déploiements lakehouse
Oracl reste perçu comme onéreux et a du travail pour « cloudifier » sa base client, avait noté Gartner l’an dernier. Il avait aussi appelé les acheteurs à s’assurer de bien interpréter l’approche « une base de données pour tout » et ce qu’elle impliquait en matière de livraison de fonctionnalités.
Cette dernière remarque est reconduite : vigilance sur cette approche, qui s’oppose aux architecture combinant les SGBD et les systèmes de data management. La question du prix – sus-évoquée – reste sensible et les clients continuent à prioriser des produits concurrents pour les déploiements lakehouse.
Snowflake a amélioré sa couverture fonctionnelle…
L’an dernier, Snowflake s’était distingué par son UI adaptée à divers profils d’utilisateurs, sa prise en charge de multiples formats sur la couche de stockage et l’extension de l’architecture lakehouse avec Iceberg et Polaris.
Cette année encore, Gartner donne un bon à l’UI. Il relève aussi l’extension fonctionnelle de l’offre (data engineering avancé via Openflow, ML/IA avec Snowpark et Cortex AI, support de Postgre apporté par l’acquisition de Crunchy Data). Et l’amélioration de la scalabilité avec les entrepôts de génération 2 (meilleur rapport qualité-prix que la gen 1 pour les workloads complexes).
… mais reste focalisé sur le batch et l’analytique
L’an dernier, Gartner avait pointé une prise en charge limitée des scénarios hybrides. Il y avait ajouté la complexité dans le partage des données entre organisations utilisatrices de Snowflake et les défis d’usabilité que posait l’intégration avec le stockage sur site via les tables externes.
Ces deux derniers aspect demeurent. D’une part, la performance n’est pas la même avec les tables externes qu’avec le stockage natif ou les tables Iceberg. De l’autre, sur le partage, il est nécessaire de bien planifier des éléments tels que les permissions, le repartage et les restrictions régionales. Gartner y ajoute l’aspect FinOps (voir ci-dessus). Et le fait que l’architecture est focalisée sur le batch et l’analytique plutôt que sur le transactionnel ou le temps réel (même s’il existe les tables hybrides et une intégration avancée de PostgreSQL).
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.
Connexion
