Hausse tarifaire subie, migration impossible, verrou contractuel, fournisseur incontournable… La dépendance numérique est une réalité devenue ingouvernable. Il est temps que cela change. L’Indice de résilience numérique veut concrétiser cette dépendance sous forme de score comparable, veut transformer ces “accidents” en risques pilotables, ramener la quête d’autonomie à une quête de résilience menée grâce à […]
Au tour d’Argo et de cert-manager de dépasser les 50 % de taux d’usage en production.
C’est tout du moins ce que donne à voir le dernier sondage annuel de la CNCF (Cloud Native Computing Foundation). L’échantillon comprend 628 répondants, interrogés en septembre 2025.
L’édition précédente avait recueilli 750 réponses à l’automne 2024. Six projets CNCF dépassaient alors les 50 % de taux d’usage en production : Kubernetes, Helm, etcd, Prometheus, CoreDNS et containerd.
Les 10 projets de l’écosystème Kubernetes les plus utilisés en production
34 projets ont désormais atteint le plus haut stade de maturité à la CNCF. Le sondage s’en est tenu au 30 premiers à y être arrivés (de Kubernetes en mars 2018 à CubeFS en décembre 2024).
Taux d’usage en prod 2024
Taux d’usage en prod 2025
Évolution
Nature du projet
Sandbox
Incubation
Gradué
Kubernetes
85 %
87 %
+ 2 pts
Orchestrateur de conteneurs
Mars 2016
Mars 2018
Helm
77 %
81 %
+ 4 pts
Gestionnaire de paquets
Juin 2018
Mai 2020
etcd
70 %
81 %
+ 11 pts
Magasin clé-valeur distribué
Décembre 2018
Novembre 2020
Prometheus
73 %
77 %
+ 4 pts
Monitoring
Mai 2016
Août 2018
CoreDNS
59 %
76 %
+ 17 pts
Serveur DNS
Février 2017
Février 2018
Janvier 2019
containerd
62 %
74 %
+ 12 pts
Runtime
Mars 2017
Février 2019
cert-manager
48 %
58 %
+ 10 pts
Gestionnaire de certificats TLS
Novembre 2020
Septembre 2022
Septembre 2024
Argo
43 %
52 %
+ 9 pts
Déploiement GitOps
Mars 2020
Décembre 2022
Fluentd
39 %
41 %
+ 2 pts
Journalisation
Novembre 2016
Avril 2019
Istio
31 %
36 %
+ 5 pts
Maillage de services
Septembre 2022
Juillet 2023
Les projets classés 11 à 20
Taux d’usage en prod 2024
Taux d’usage en prod 2025
Évolution
Nature du projet
Sandbox
Incubation
Gradué
CRI-O
25 %
34%
+ 9 pts
Interface de runtime
Avril 2019
Juillet 2023
Envoy
22 %
33 %
+ 11 pts
Proxy
Septembre 2017
Novembre 2018
Harbor
20 %
32 %
+ 12 pts
Registre
Juillet 2018
Novembre 2018
Juin 2020
Cilium
20 %
29 %
+ 9 pts
Mise en réseau
Octobre 2021
Octobre 2023
Open Policy Agent
18 %
25 %
+ 7 pts
Moteur de politiques
Mars 2018
Avril 2019
Janvier 2021
Flux
17 %
23 %
+ 6 pts
Déploiement GitOps
Juillet 2019
Mars 2021
Novembre 2022
Jaeger
14 %
22 %
+ 8 pts
Traçage distribué
Septembre 2017
Octobre 2019
KEDA
16 %
22 %
+ 6 %
Autoscaler piloté par les événements
Mars 2020
Août 2021
Août 2023
Falco
8 %
13 %
+ 5 pts
Détection d’intrusions
Octobre 2018
Janvier 2020
Février 2024
Rook
6 %
12 %
+ 6 pts
Orchestration du stockage
Janvier 2018
Septembre 2018
Octobre 2020
Les projets classés 21 à 30
Taux d’usage en prod 2024
Taux d’usage en prod 2025
Évolution
Nature du projet
Sandbox
Incubation
Gradué
Linkerd
8 %
11 %
+ 3 pts
Maillage de services
Janvier 2017
Avril 2018
Juillet 2021
CloudEvents
5 %
9 %
+ 4 pts
Spécification pour la description de données d’événements
Mai 2018
Octobre 2019
Janvier 2024
KubeEdge
6 %
5 %
– 1 pt
Kubernetes pour l’edge
Mars 2019
Septembre 2020
Septembre 2024
SPIFFE
5 %
5 %
=
Framework de gestion des identités
Mars 2018
Octobre 2019
Janvier 2024
Dapr
3 %
5 %
+ 2 pts
Runtime piloté par les événements
Novembre 2021
Octobre 2024
CubeFS
2 %
3 %
+ 1 pt
Stockage distribué
Décembre 2019
Juin 2022
Décembre 2024
SPIRE
3 %
3 %
=
Mise en œuvre de référence de SPIFFE
Mars 2018
Juin 2020
Août 2022
Vitess
1 %
3 %
+ 2 pts
Base de données compatible MySQL
Février 2018
Novembre 2019
TUF
2 %
2 %
=
Framework de sécurisation des systèmes de mise à jour logicielles
Octobre 2017
Décembre 2019
TiKV
1 %
2 %
+ 1 pt
Base de données clé-valeur
Août 2018
Septembre 2020
Pour quelques projets, le taux d’expérimentation (pilotes/tests) a aussi augmenté. En tête de liste :
KEDA (+ 5 pts, à 16 %)
Open Policy Agent (+ 3 pts, à 20 %)
Harbor (+ 3 pts, à 12 %)
À consulter en complément sur le sujet Kubernetes :
La principale contrainte pour traiter des données à haut débit n’est plus le calcul ni le stockage, mais le réseau.
En 2017, les équipes d’AWS avaient contextualisé ainsi un article présentant les choix de conception de la base de données Aurora, lancée deux ans plus tôt.
Voilà cet article cité dans un autre, émanant de l’université technique de Munich. Ses auteurs ont analysé l’évolution des spécifications matérielles du cloud public entre 2015 et 2025. S’ils mentionnent le cas Aurora, c’est parce que, selon eux, le postulat d’alors ne tient plus. Sur la période en question, à coût normalisé, la bande passante réseau proposée par AWS a crû sans commune mesure avec les performances CPU et NVMe. Dans ce contexte, Aurora, conçu pour minimiser le trafic réseau, gagnerait peut-être à être réarchitecturé…
Une analyse axée bases de données
L’analyse n’est pas exhaustive, reconnaissent ses auteurs.
En premier lieu, elle est centrée sur les instances EC2 d’AWS, malgré quelques éléments de comparaison avec d’autres clouds publics et avec les infrastructures sur site.
Ensuite, elle se focalise sur un cas d’usage « base de données ». Aussi, les instances avec accélérateurs et FPGA ont été exclues. Et celles dotées de GPU ont été abordées séparément. N’ont pas non plus été prises en compte les instances à capacité extensible (familles T et flex).
Quant aux prix, la tarification retenue est celle à la demande dans la région us-east-1 (la principale du cloud AWS, et la moins chère). Les instances Spot ne sont pas entrées en ligne de compte en raison de leurs tarifs très variables en fonction de la demande. Les savings plans et les instances réservées n’ont pas non plus été inclus, au motif que les remises sont « largement similaires » entre types d’instances (en les retirant, on ne distord donc pas significativement la structure tarifaire d’ensemble).
L’aspect optimisation logicielle a par ailleurs été laissé de côté.
Ces restrictions appliquées, le périmètre d’analyse a englobé 742 instances, groupées en 98 familles.
CPU : une stagnation pas spécifique aux cloud providers
Comme pour les serveurs on-prem, la gamme de CPU s’est nettement diversifiée en 10 ans. En première ligne, les puces Arm : depuis 2024, plus de la moitié des instances que lance AWS sont équipées en Graviton.
En parallèle, le nombre de cœurs a largement augmenté. Exemple : la famille c4, lancée en 2015, en proposait jusqu’à 18, quand la c7a, introduite en 2023, monte à 192.
La progression du ratio coût-performance se révèle plus limitée. En tout cas sur la foi de trois benchmarks, exécutés sur diverses instances 2xlarge optimisées pour le calcul :
SPECint 2018
TPC-H in-memory (facteur d’échelle de 10) sur Umbra
TPC-C sur Leanstore (25 entrepôts)
Les résultats sont normalisés par rapport au coût et à la performance de l’instance c4.2xlarge. Bilan : sur SPECint, le ratio est multiplié par 3 environ sur la période. On serait plutôt à x2 sans les instances Graviton, vers lesquelles ont d’ailleurs basculé des fournisseurs comme Snowflake.
Sur la partie base de données in-memory, la progression est similaire (entre x2 et x2,5). La latence de la mémoire et du cache a possiblement beaucoup d’influence, reconnaissent les auteurs de l’étude, qui n’ont pas analysé ces dimensions.
Cette relative stagnation n’apparaît pas pour autant liée aux marges que prennent les cloud providers. En tout cas sur la foi d’une analyse sur les CPU serveur d’AMD sortis entre 2017 et 2025. Sur la base des prix publics, du nombre de cœurs, des fréquences d’horloge et des métriques IPC communiquées, le rapport coût-performance ne double même pas (x 1,7).
Mémoire : peu de gains en capacité comme en bande passante
À coût normalisé, la capacité de DRAM a très peu progressé. Seul changement majeur : l’introduction, en 2016, d’une famille d’instances optimisées pour la mémoire, avec environ 3,3 fois plus de GiB-heures/$ que les meilleures instances optimisées pour le calcul.
La bande passante absolue par socket mono-CPU a significativement augmenté (de 93 à 492 GiB/s). Mais une fois normalisée, le gain n’est que de x2.
Un bond en avant sur le réseau… avec les instances optimisées
En valeur absolue, le plafond de bande passante sur EC2 est passé de 10 Gbit/s en 2015 à 600 Gbit/s en 2025. Surtout, le rapport coût-performance normalisé a décuplé. En toile de fond, la mise à disposition d’instances optimisées pour le réseau. La c5n, première du genre basée sur le système Nitro, fut ajoutée au catalogue en 2018.
Si on exclut ces instances optimisées, le rapport bande passante par dollar a peu évolué entre 2015 et 2025.
Stockage : comparaison défavorable pour AWS
L’analyse s’est focalisée sur les instances avec stockage NVMe local. La première famille du genre (i3) fut introduite en 2016. La première avancée notable en termes de capacité de stockage par dollar fut le lancement de la famille i3en en 2019. Le ratio avait alors doublé. Il a peu évolué depuis.
Même réflexion si on considère le coût des I/O : les i3 demeurent les plus avantageuses, tant en lecture séquentielle qu’aléatoire.
Cette stagnation dans le cloud public contraste avec les tendances de l’on-prem : à coût normalisé, la capacité par dollar a triplé et le coût des I/O a été divisé par 5. L’arrivée de PCIe4 puis de PCIe5 a joué.
Des opportunités dans le hardware spécialisé
Un indicateur est ici analysé : le volume d’opérations 32 bits en virgule flottante à coût normalisé.
Avec les GPU, le rapport coût-performance a été multiplié par environ 4,7 entre les familles d’instances p3 et g6e.
Depuis 2019, AWS a lancé deux générations d’instances inf et trn dotées d’ASIC dédiés au machine learning. Les trn2 délivrent deux fois plus de flops/s par device que les g6e ; et le ratio coût-performance est multiplié par 15,7 par rapport aux p3.
La spécialisation du hardware peut donc se révéler avantageuse… y compris pour le traitement de données (l’étude fait référence à divers travaux* sur ce sujet).
Caches NVMe, cycles processeur… Des questions d’architecture émergent
Combinée à la démultiplication des débits réseau, la stagnation des performances du stockage pose des questions pour des solutions comme Snowflake, qui utilisent des caches NVMe plutôt que de lire directement sur S3.
Autre combinaison, autre enjeu : tandis que la bande passante réseau croît et que la vitesse des processeurs stagne, le budget en cycles CPU par paquet décline. Exploiter pleinement les ressources disponibles pourrait exiger des modifications majeures touchant par exemple au contournement du noyau.
Avec les instances Arm, l’amélioration du rapport coût-performance se constante autant sur le calcul (c8g) que sur le réseau (c8gn), la capacité mémoire (x2gd) et la capacité NVMe (is4gen).
Voir au-delà des hyperscalers
La tendance est la même dans les autres clouds… sauf que, de manière générale, les VM – Arm ou x86 – peuvent être notablement moins chères que chez les hyperscalers. Oracle et OVHcloud sont cités à ce sujet, sur la foi d’une comparaison pour des instances à CPU AMD 16 cœurs, 128 GiB de RAM et sans fonctionnalités spécifiques de type grande bande passante réseau. Hetzner l’est aussi, avec son instance CCX53, 3,7 fois moins chère que la m6a.8xlarge d’AWS. En contrepartie, ces fournisseurs ont un écosystème moins fourni, une couverture géographique plus limitée, une facturation parfois moins granulaire et un éventail plus restreint d’instances spécialisées (susceptibles de faire baisser les coûts pour certains cas d’usage).
Entre les « trois grands », il y globalement peu d’écart… avec quelques exceptions (AWS a l’avantage sur la bande passante réseau avec les instances c7gn/c8gn, Microsoft ne facture pas le trafic entre zones de disponibilité au sein d’une même région, etc.).
Un outil interactif pour dépasser l’analyse statique
Vu la nature multidimensionnelle de l’univers des instances cloud, une analyse statique est intrinsèquement limitée, admettent les auteurs de l’étude. Ils fournissent donc un outil interactif open source associant moteur SQL et visualisation R. Le service fonctionne intégralement dans le navigateur (pas de dépendance serveur). La base sous-jacente est téléchargeable (fichier DuckDB).
Ces quelques mots du directeur technique et juridique de Microsoft France avaient fait grand bruit en juin dernier. L’intéressé était auditionné au Sénat dans le cadre d’une commission d’enquête sur la commande publique. On venait de lui demander, en substance, s’il pouvait affirmer que les données des citoyens français confiées à son entreprise ne seraient jamais transmises, à la suite d’une injonction du gouvernement américain, sans l’accord explicite des autorités françaises.
AWS ne garantit pas non plus d’immunité totale avec son nouveau « cloud souverain européen ». Il prend, dans les grandes lignes, les mêmes engagements qu’avec son cloud commercial. D’une part, faire au mieux pour rediriger les requêtes gouvernementales directement vers les clients ou, sinon, les notifier autant qu’il est possible. De l’autre, contester ces requêtes s’il y a conflit avec la législation de l’UE ou d’un État membre. Et dans tous les cas, divulguer le strict minimum.
En principe, le contenu des clients et les métadonnées créées par leurs soins (rôles, autorisations, étiquettes de ressources, configurations) ne sortent pas de l’UE. Sauf si un client le demande… ou, donc, si c’est nécessaire pour répondre à une requête gouvernementale fondée.
De « résidents » à « citoyens » de l’UE : une politique RH en transition
Ce « contrat de confiance » lui a valu de décrocher la qualification C5 (le « SecNumCloud allemand ») en combinaison avec d’autres promesses. Parmi elles, l’autonomie opérationnelle : les systèmes et services critiques doivent pouvoir fonctionner même sans connectivité au backbone AWS. Un exercice sera réalisé au moins une fois par an, parallèlement à la définition de stratégies de réponse à incident (SOC dédié) et de reprise après sinistre (y compris en cas d’isolation géopolitique).
Le « cloud souverain européen » a des systèmes indépendants d’IAM, de facturation et de mesure de l’utilisation. Sur la partie réseau, les points de présence Direct Connect sont dans l’UE et l’instance Route 53 est dédiée, avec uniquement des TLD européens pour les serveurs de noms. Une extension territoriale est prévue via des zones locales AWS (Belgique, Pays-Bas, Portugal) qui seront connectées au datacenter principal sur réseau privé.
Tous les membres du personnel d’exploitation sont établis dans l’UE. Interpellé à ce sujet, AWS a entamé une transition pour dépasser cette notion de résidence, en introduisant un critère de citoyenneté dans son processus de recrutement.
Un préavis contractuel d’un an
Concernant les mesures techniques concourant à la « souveraineté », la journalisation est locale, comme les opérations cryptographiques et la gestion des certificats (ce cloud a sa propre racine de confiance). Les clés de chiffrement utilisées sur les services sont sécurisées au niveau logiciel ; celles destinées à la récupération après sinistre le sont au niveau physique (conservation hors ligne).
AWS conserve une réplique du code source nécessaire pour opérer les services. Cette réplique est chiffrée, soumise à des contrôles d’intégrité, cryptographiquement vérifée et mise à jour via un processus de réplication contrôlé.
Sauf si le client s’y oppose, les contrats sont gouvernés par les lois d’un État membre de l’UE. Préférentiellement l’Allemagne, semble-t-il, l’addendum de l’AWS European Sovereign Cloud invitant à s’adresser aux tribunaux de Munich en cas de litige.
On nous promet un préavis d’au moins un an avant toute modification importante des statuts de la société mère – de droit allemand et « contrôlée localement ». Sauf si cette modification est nécessaire pour se conformer à la législation applicable. Ou si le comité consultatif considère, à l’unanimité, que cela n’affecte pas significativement l’indépendance opérationnelle, les contrôles de résidence des données, les structures de gouvernance ou bien les obligations d’AWS.
Deux Français au comité consultatif…
À l’origine, on nous avait annoncé que ce comité se composerait de 4 membres, dont 1 non affilié à Amazon. Ils sont finalement 5, dont 2 non affiliés. Parmi eux, deux ressortissants français : Stéphane Ducable et Philippe Lavigne.
Stéphane Ducable est vice-président des politiques publiques d’AWS pour la région EMEA. Il fut membre fondateur du CISPE, au conseil d’administration duquel il représenta Amazon jusqu’en 2025. Ancien VP adjoint des affaires publiques chez Alcatel, il est aussi passé chez Microsoft. Entre autres comme responsable des affaires extérieures à Bruxelles, ainsi que directeur régional des affaires générales à Singapour puis au Japon).
Philippe Lavigne, général à la retraite, fut notamment chef d’état-major de l’armée de l’air et de l’espace (2018-2021) et commandant suprême allié pour la transformation de l’OTAN (2021-2024).
Les trois autres membres :
Ian McGarry
Ressortissant irlandais. Directeur d’Amazon CloudWatch chez AWS. Ancien d’Ericsson et d’Oracle.
Sinead McSweeney
Ressortissante irlandaise. Ancienne transcriptrice parlementaire puis conseillère politique au sein du Gouvernement (auprès du ministre de la Justice, notamment). Ensuite directrice des relations publiques pour le service de police d’Irlande du Nord. Puis, chez Twitter, responsable des politiques publiques EMEA puis monde.
Barbara Scarafia
Ressortissante allemande. Avocate de formation. Entrée chez Amazon en 1999 comme directrice juridique pour l’Allemagne. Aujourd’hui directrice juridique associée pour l’Europe.
… et un à la direction générale
La société mère a deux DG : Stéphane Israël et Stefan Hoechbauer. Le premier dirige les opérations. Le second supervise les décisions relatives à la gouvernance d’entreprise et à la conformité.
Stéphane Israël, 55 ans, arrive du Boston Consulting Group, où il aura passé moins d’un an.
L’intéressé fut d’abord auditeur puis conseiller référendaire à la Cour des comptes (2001-2007).
Chez EADS (2007-2012), il entra comme conseiller business du P-DG Louis Gallois et termina directeur du volet services du programme européen Copernicus au sein de la filiale satellites.
Directeur de cabinet d’Arnaud Montebourg en 2012-2013, il entra ensuite en fonction chez Arianespace (P-DG entre 2013 et 2017, puis président exécutif jusqu’en 2024). Il préside aujourd’hui la Fondation de l’ENS.
Stefan Hoechbauer, ressortissant allemand, est vice-président des ventes mondiales d’AWS pour l’Allemagne et l’Europe centrale. Il est un ancien de SAP, de PeopleSoft et d’Oracle. Ainsi que de Salesforce, où il fut vice-président exécutif et P-DG pour la zone DACH (Allemagne, Autriche, Suisse).
La nomination de Stéphane Israël avait été officialisée fin septembre 2025. Son binôme annoncé était alors Kathrin Renz. Mais l’ancienne de Siemens (directrice du développement, notamment) et de Nokia (présidente de la branche Enterprise, en particulier) a quitté AWS en décembre.
Une entité dédiée avec une gouvernance spécifique, du personnel résidant dans l’UE, une infrastructure capable de fonctionner pour l’essentiel sans connexion au backbone… Autant d’engagements qui viennent avec le nouveau « cloud souverain européen » d’AWS.
On pourrait s’attendre, dans ce contexte, à des prix plus élevés que pour les régions cloud commerciales. Il apparaît globalement que non, en tout cas par rapport à la région AWS Paris, sur la foi de la tarification publique. En voici une brève revue. Les comparatifs, notamment pour les instances, s’alignent sur la moins chère et la plus chère des options disponibles au catalogue du « cloud souverain européen » d’AWS. Pour la lisibilité, nous arrondissons au centime tout prix supérieur ou égal à 0,10 €/$.
Services de calcul
1. EC2
Les tarifs horaires listés ici valent pour des instances avec système d’exploitation Linux.
Le Go-seconde est à 0,0000164477 €/mois pour les 6 premiers milliards ; à 0,0000148029 € pour les 9 milliards suivants ; à 0,0000131582 € au-delà.
Il faut ajouter 0,20 € par million de requêtes.
– Dans la région AWS Paris
Le Go-seconde est à 0,0000166667 $/mois pour les 6 premiers milliards ; à 0,000015 $ pour les 9 milliards suivants ; à 0,0000133334 $ au-delà.
Il faut ajouter 0,20 $ par million de requêtes.
Version Arm
– Sur l’offre de cloud souverain
Le Go-seconde est à 0,0000131582 €/mois pour les 7,5 premiers milliards ; à 0,0000118424 € pour les 9 milliards suivants ; à 0,0000105265 € au-delà.
Il faut ajouter 0,20 € par million de requêtes.
– Dans la région AWS Paris
Le Go-seconde est à 0,0000133334 $/mois pour les 7,5 premiers milliards ; à 0,0000120001 $ pour les 9 milliards suivants ; à 0,0000106667 $ au-delà.
Il faut ajouter 0,20 $ par million de requêtes.
3. Fargate
Version Linux/x86
– Sur l’offre de cloud souverain
0,0459480875 €/vCPU/heure et 0,0050428421 €/Go/heure
– Dans la région AWS Paris
0,0486 $/vCPU/heure et 0,0053 $/Go/heure
Version Linux/Arm
– Sur l’offre de cloud souverain
0,0367604437 €/vCPU/heure et 0,0040362474 €/Go/heure
– Dans la région AWS Paris
0,03888 $/vCPU/heure et 0,00424 $/Go/heure
4. EKS (Elastic Kubernetes Service)
Pour le support de la version standard de Kubernetes, il faut compter 0,098685 €/cluster-heure sur l’offre souveraine, contre 0,10 $ dans la région AWS Paris.
Pour le support étendu des versions de Kubernetes, c’est 0,59 €/cluster-heure sur l’offre souveraine, contre 0,60 $ dans la région AWS Paris.
Services de stockage
1. EBS
Volumes à usage général (gp3)
– Sur l’offre de cloud souverain
Stockage : 0,0939488388 €/Go-mois
IOPS : 3000 gratuites puis 0,0059211453 €/IOPS-mois
Débit : 125 Mo/s gratuits puis 0,047 €/Mo-mois
– Dans la région AWS Paris
Stockage : 0,0928 $/Go-mois
IOPS : 3000 gratuites puis 0,0058 $/IOPS-mois
Débit : 125 Mo/s gratuits puis 0,046 $/Mo-mois
Sur l’offre souveraine : 0,0177634359 €/Go-mois de stockage provisionné.
Dans la région AWS Paris : 0,0174 $/Go-mois.
Snapshots
– Sur l’offre de cloud souverain
Standard : 0,0532903077 €/Go/mois (restauration gratuite) Archive : 0,0133225769 €/Go/mois (restauration : 0,0319741846 € par Go)
– Dans la région AWS Paris
Standard : 0,053 $/Go/mois (restauration gratuite) Archive : 0,01325 $/Go/mois (restauration : 0,0318 $ par Go)
2. EFS
Régional avec débit élastique
– Sur l’offre de cloud souverain
Stockage
0,36 €/Go-mois (Standard)
0,019737151 €/Go-mois (Standard avec accès peu fréquent)
0,0098685755 €/Go-mois (Archive)
Débit et accès
Lecture : 0,039474302 €/Go
Écriture : 0,0690800285 €/Go
Frais supplémentaires de 0,0118422906 €/Go en lecture pour l’accès peu fréquent ; de 0,0355268718 €/Go pour le niveau archive.
– Dans la région AWS Paris
Stockage
0,33 $/Go-mois (Standard)
0,02 $/Go-mois (Standard avec accès peu fréquent)
0,01 $/Go-mois (Archive)
Débit et accès
Lecture : 0,03 $/Go
Écriture : 0,07 $/Go
Frais supplémentaires de 0,011 $/Go en lecture pour l’accès peu fréquent ; de 0,033 €/Go pour le niveau archive.
Régional avec modes de débit hérités
– Sur l’offre de cloud souverain
Stockage
0,36 €/Go-mois (Standard)
0,0262504108 €/Go-mois (Standard avec accès peu fréquent)
Débit et accès
0,0592 €/Go-mois en sauvegarde tiède ; 0,0118 €/Go-mois à froid
Lectures en accès peu fréquent : 0,0118422906 €/Go-mois
– Dans la région AWS Paris
Stockage
0,33 $/Go-mois (Standard)
0,0261 $/Go-mois (Standard avec accès peu fréquent)
Débit et accès
0,055 $/Go-mois en sauvegarde tiède ; 0,011 $/Go-mois à froid
Lectures en accès peu fréquent : 0,011 $/Go-mois
3. S3
Niveau standard
Sur l’offre de cloud souverain 0,02417801 €/Go pour les 50 premiers To/mois
0,0231911524 € pour les 450 To suivants
0,0222042949 € au-delà
Dans la région AWS Paris
0,024 $/Go pour les 50 premiers To/mois
0,023 $/Go pour les 450 To suivants
0,022 $/Go au-delà
Intelligent tiering
En accès fréquent, les prix sont les mêmes qu’au niveau Standard. Pour le reste :
Sur l’offre de cloud souverain
Accès peu fréquent : 0,0133225769 €/Go
Archive : 0,0049342878 €/Go
Dans la région AWS Paris
Accès peu fréquent : 0,0131 $/Go
Archive : 0,005 $/Go
Requêtes de récupération
– Sur l’offre de cloud souverain
Niveau standard
PUT/COPY/POST/LIST : 0,005329 € par millier de requêtes
GET/SELECT : 0,0004243 € par millier de requêtes
Niveau standard avec accès peu fréquent
PUT/COPY/POST/LIST : 0,0085814 € par millier de requêtes
GET/SELECT : 0,0008581 € par millier de requêtes
– Dans la région AWS Paris
Niveau standard
PUT/COPY/POST/LIST : 0,005 $ le millier de requêtes
GET/SELECT : 0,0004 $ le millier de requêtes
Niveau standard avec accès peu fréquent
PUT/COPY/POST/LIST : 0,01 $ le millier de requêtes
GET/SELECT : 0,001 $ le millier de requêtes
4. AWS Backup
Les prix sont au Go-mois.
Sauvegarde
Cloud souverain
Paris
Sauvegarde EFS
0,0592 € (à chaud)
0,0118 € (à froid)
0,55 $ (à froid)
0,11 $ (à chaud)
Instantané EBS
0,0533 € (à chaud)
0,0133 € (à froid)
0,053 $ (à chaud)
0,01325 $ (à froid)
Instantané base de données RDS
0,10 €
0,10 $
Instantané cluster Aurora
0,0223 €
0,022 $
Table DynamoDB
0,01208 € (à chaud)
0,0362 € (à froid)
0,011886 $ (à chaud)
0,03566 $ (à froid)
Backup S3
0,0592 € depuis le stockage tiède
0,0231911524 € depuis le stockage tiède à faible coût
0,055 $
Instantané cluster Redshift
0,02417801 € (50 premiers To)
0,0231911524 € (450 To suivants)
0,0222042949 € (au-delà)
0,024 $ (50 premiers To)
0,023 $ (450 To suivants)
0,022 $ (au-delà)
Restauration
Cloud souverain
Paris
EFS
0,0237 € (tiède)
0,0355 € (froid)
0,022 $ (tiède)
0,033 $ (tiède)
EBS
Gratuit (tiède)
0,032 € (froid)
Gratuit (tiède)
0,0318 $ (froid)
RDS
Gratuit (tiède)
Gratuit (tiède)
Aurora
Gratuit (tiède)
Gratuit (tiède)
DynamoDB
0,1812 € (tiède)
0,2416 € (froid)
0,17829 $ (tiède)
0,23772 $ (froid)
S3
0,0237 € (tiède)
0,022 $ (tiède)
Redshift
Gratuit (tiède)
Gratuit (tiède)
Services d’analytique
1. Athena
Une fois n’est pas coutume, sur le prix des requêtes SQL, l’écart de prix est notable : 4,94 € par To analysé sur l’offre de cloud souverain, contre 7 $ dans la région AWS Paris.
2. Redshift
Sur l’offre de cloud souverain, le stockage managé revient à 0,0252635533 €/Go-mois. Il faut compter 0,025 $/Go-mois dans la région AWS Paris.
Sur l’offre de cloud souverain, il en coûte 4,94 €/To pour Spectrum. C’est 5,50 $/To dans la région AWS Paris.
3. Glue
Les tâches Spark / Spark Streaming, Python Shell et les sessions interactives coûtent 0,43 €/DPU-heure sur l’offre de cloud souverain.
Elles coûtent 0,44 $/DPU-heure dans la région AWS Paris.
Services d’IA
1. Bedrock
Modèles Nova
– Sur l’offre de cloud souverain
Deux modèles Amazon sont proposés : Nova Lite et Nova Pro.
Les tarifs de Nova Lite
Input : 0,0000769749 € pour 1000 jetons (0,0000192437 € depuis le cache ; 0,0000384874 € en batch)
Output : 0,0003078996 € pour 1000 jetons (0,0001539498 € en batch)
Les tarifs de Nova Pro
Input : 0,0010362004 € pour 1000 jetons (0,0002590501 € depuis le cache ; 0,000518002 € en batch)
Output : 0,0041448017 € pour 1000 jetons (0,0020724009 € en batch)
– Dans la région AWS Paris
Nova Lite : 0,000088 $ pour 1000 jetons d’entrée et 0,000352 $ pour 1000 jetons de sortie.
Nova Pro : 0,00118 $ en entrée et 0,00472 $ en sortie
Guardrails
– Sur l’offre de cloud souverain
Filtres de contenu et sujets refusés (niveau classique) : 0,26 € pour 1000 unités de texte
Filtres d’informations sensibles et vérification de l’ancrage contextuel : 0,17 € pour 1000 unités de texte
– Dans la région AWS Paris
Filtres de contenu et sujets refusés (niveau classique) : 0,15 $ pour 1000 unités de texte
Filtres d’informations sensibles et vérification de l’ancrage contextuel : 0,10 $ pour 1000 unités de texte
Demandes impliquant des clés RSA 2048 : 0,03 € les 10 000
Demandes ECC GenerateKeyDataPair : 0,10 € les 10 000
Demandes asymétriques sauf RSA 2048 : 0,15 € les 10 000
Demandes RSA GenerateDataKeyPair : 12 € les 10 000
– Dans la région AWS Paris
Demandes impliquant des clés RSA 2048 : 0,03 $ les 10 000
Demandes ECC GenerateKeyDataPair : 0,10 $ les 10 000
Demandes asymétriques sauf RSA 2048 : 0,15 $ les 10 000
Demandes RSA GenerateDataKeyPair : 12 $ les 10 000
2. Secrets Manager
Sur l’offre de cloud souverain, c’est 0,39 €/secret-mois et 0,049343 € pour 10 000 appels API.
Dans la région AWS Paris, c’est 0,40 $/secret-mois et 0,05 $ pour 10 000 appels API.
3. WAF
Cloud souverain
Paris
ACL web
4,93 €/mois
5 $/mois
Règle
0,99 €/mois
1 $/mois
Demandes
0,59 € le million
0,60 $ le million
Protection DDoS
0,15 € le million de demandes
0,15 $ le million de demandes
4. GuardDuty
Analyse d’événements CloudTrail Management
Cloud souverain : 4,54 €/million-mois
Paris : 4,40 $
Analyse des journaux de flux VPC et de requêtes DNS
Cloud souverain
1,13 €/Go (500 premiers Go/mois)
0,57 €/Go (2000 Go suivants)
0,29 €/Go (7500 Go suivants)
0,17 €/Go (au-delà)
Paris
1,10 $/Go (500 premiers Go/mois)
0,55 $/Go (2000 Go suivants)
0,28 $/Go (7500 Go suivants)
0,17 $/Go (au-delà)
Protection S3
Cloud souverain
1,03 € par million d’événements (500 premiers millions/mois)
0,51 € par million pour les 4500 millions/mois suivants
0,26 € par million au-delà
Paris
1 $ par million d’événements (500 premiers millions/mois)
0,50 $ par million pour les 4500 millions/mois suivants
0,25 $ par million au-delà
Protection EKS
Cloud souverain
2,20 € par million d’événements (100 premiers millions/mois)
1,11 € par million pour les 100 millions suivants
0,28 € au-delà
Paris
2,29 $ par million d’événements (100 premiers millions/mois)
1,15 $ par million pour les 100 millions suivants
0,29 $ au-delà
Surveillance de l’exécution d’EKS, ECS et EC2
Cloud souverain
1,89 € par processeur virtuel (500 premiers/mois)
0,95 € pour les 4500 suivants
0,32 € au-delà
Paris
2,04 $ par processeur virtuel (500 premiers/mois)
1,20 $ pour les 4500 suivants
0,34 $ au-delà
Analyse de volumes EBS
Sur l’offre de cloud souverain, c’est 0,039474302 €/Go.
Dans la région AWS Paris, c’est 0,04 $/Go.
Analyse de scans d’objets S3
Cloud souverain : 0,13 €/Go et 0,30 € pour 1000 objets.
AWS Paris : 0,14 $/Go et 0,33 $/1000 objets.
Analyse du journal d’activité Lambda
Cloud souverain
1,13 €/Go (500 premiers Go-mois)
0,57 €/Go (2000 Go suivants)
0,29 €/Go (7500 Go suivants)
0,17 €/Go (au-delà)
Paris
1,10 $/Go (500 premiers Go-mois)
0,55 $/Go (2000 Go suivants)
0,28 $/Go (7500 Go suivants)
0,17 $/Go (au-delà)
Valkey : 0,0996726126 €/Go-heure + 0,0027 € par million d’unités de traitement
Memcached et Redis OSS : 0,15 €/Go-heure et 0,004 € par million d’unités de traitement
– Dans la région AWS Paris
Valkey : 0,098 $/Go-heure + 0,0027 $ par million d’unités de traitement
Memcached et Redis OSS : 0,15 $/Go-heure et 0,004 $ par million d’unités de traitement
En cas de litige, prière de vous adresser aux tribunaux de Munich.
AWS impose cette règle aux clients de son « cloud souverain européen ». Il faut dire que l’offre a son épicentre en Allemagne. L’entité qui la porte y est basée, comme l’infrastructure initiale.
Plus de deux ans après son annonce, la démarche se concrétise : le lancement commercial vient d’être acté.
AWS fait une promesse d’équivalence fonctionnelle avec le reste de son cloud. Il ne faut toutefois pas s’attendre à retrouver immédiatement les mêmes services. En voici quelques-uns effectivement disponibles. Avec, pour chacun, les principales fonctionnalités utilisables… et celles qui ne le sont pas encore.
Compute
Sur EC2, AWS a activé, entre autres, les hôtes dédiés, les réservations de capacité, les groupes de placement de clusters et de partitions, l’hibernation, les instances Spot et les Savings Plans, l’optimisation CPU, ainsi que l’importation/exportation de VM.
En revanche, pas de SEV-SNP, de Credential Guard, d’enclaves Nitro, de configuration de la bande passante des instances, de blocs de capacité ML et de mise à l’échelle prédictive. Sur EC2 Image Builder, la gestion de cycle de vie n’est pas activée, comme la détection de vulnérabilité et l’intégration CloudFormation.
Sur Lambda, on peut notamment utiliser l’invocation asynchrone, la console d’édition de code, les extensions et SnapStart. Les images de conteneurs sont supportées, comme les puces Graviton.
Il faudra en revanche attendre pour les fonctions Lambda durables.
Stockage
AWS Backup gère pour le moment Aurora, CloudFormation, DynamoDB, EBS, EC2, EFS, RDS, Redshift et S3.
Aurora DSQL est sur la feuille de route, comme DocumentDB, FSx pour Lustre/ONTAP/OpenZFS, Neptune, RDS multi-AZ, Redshift Serverless, Storage Gateway, VMware et Windows VSS.
Sur EBS (Elastic Block Storage), l’essentiel des fonctionnalités sont disponibles : chiffrement, clonage, gestion du cycle de vie des données, corbeille, snapshots, etc.
Sur EFS (Elastic File Storage), les politiques de cycle de vie sont activées, comme le pilote CSI, l’IPv6, le mode Max I/O et plusieurs classes de stockage (Archive, Standard, Standard Infrequent Access).
En revanche, pas de classes de stockage One Zone et One Zone Infrequent Access. Ni de réplication intercomptes ou d’intégrations avec ECS et Lambda.
Sur la partie FSx, la version Lustre n’a pas de chiffrement au repos, de support des EFA (Elastic Fabric Adapter), ni des classes de stockage HDD et SSD.
Pour les versions ONTAP et OpenZFS, pas d’intégration AD, de chiffrement au repos, d’IPv6, de WORM, de classe SSD et de certains déploiements (multi-AZ, scale-out, haute disponibilité en mono-AZ).
S3 version European Sovereign Cloud gère les écritures et les copies conditionnelles, les listes de contrôle d’accès, les opérations par lots, les politiques et clés de buckets, la réplication interrégions, le tiering intelligent, l’inventaire et le cycle de vie, le verrouillage et l’étiquetage d’objets, ainsi que Glacier et Storage Lens.
Il faudra attendre pour les tables et les vecteurs S3, les autorisations d’accès individuelles, les métadonnées, la fonction Select et la classe de stockage Express One Zone.
Réseau
Sur API Gateway, REST est activé. Pas encore HTTP, ni WebSockets.
Les fonctionnalités principales de Cloud Map sont disponibles, dont l’intercomptes, la gestion des endpointsdual-stack et les attributs de services. Même réflexion pour Direct Connect, qui ne gère toutefois pas encore PrivateLink, comme beaucoup d’autres services.
Avec Route 53 aussi, l’essentiel du socle est disponible, à l’exception des domaines et – pour le DNS public – de la signature DNSSEC.
Sur les VPC, le blocage de l’accès public est activé, comme les journaux de flux, la gestion des adresses IP et la mise en miroir du trafic. La brique Route Server ne l’est pas, comme l’analyse de la connectivité et des accès réseau.
Bases de données
Aurora n’est pas encore disponible pour DSQL. Il l’est en revanche pour MySQL et PostgreSQL, y compris en version serverless. Les déploiements blue-green sont pris en charge, comme les proxys RDS et la connexion zero-ETL avec Redshift.
Les briques essentielles de DocumentDB sont disponibles. Pas de clusters globaux, cependant, ni de clusters élastiques.
Sur DynamoDB, on peut bénéficier du contrôle d’accès à base de rôles et d’attributs, des points de restauration, de l’importation/exportation S3, des index secondaires globaux ou locaux, des classes de stockage Standard et Standard Infrequent Access et du débit à la demande ou provisionné.
Le service de cache Accelerator n’est pas disponible.
ElastiCache est disponible en serverless, avec le support du JSON. Mais pour le moment sans tiering des données ni data store global.
Les principales fonctionnalités de Neptune sont accessibles, mais pas les instances serverless ni celles optimisées I/O.
Sur RDS pour MariaDB, MySQL, PostgreSQL et SQL Server, les déploiements blue-green sont pris en charge, ainsi que les lectures optimisées (sauf pour Postgre) et les proxys RDS. Les réplicas en lecture interrégions sont sur la roadmap, comme la connexion zero-ETL avec Redshift (mais pas pour MariaDB).
Analytics
Le « gros » d’Athena est disponible : console, contrôle d’accès granulaire, requêtes fédérées, réservation de capacité, etc. Même chose pour EMR, mais sans les versions EKS et serverless. Et pour Kinesis Data Strams (contrôle d’accès basé sur les attributs, accès intercomptes, quotas de service, connectivité et sécurité réseau).
Data Firehose accepte OpenSearch, Redshift, S3, Snowflake, Iceberg et HTTP en destination. Il gère l’IPv6, la transformation de données, l’ingestion PUT et le partitionnement dynamique.
L’intégration avec Secrets Manager n’est pas encore activée, ni Splunk comme destination.
Le Flink managé d’AWS est largement opérationnel, mais sans possibilité d’apporter ses propres clés. Sur le Kafka managé, c’est le serverless qui manque, ainsi que les briques Connect et Replicator.
Le cœur fonctionnel de Glue est disponible (console, connecteurs, jobs, sessions interactives).
Quantité de fonctionnalités d’OpenSearch Service sont disponibles : support du 3-AZ, détection d’anomalies, recherche asynchrone, recherche entre clusters, dictionnaires personnalisés, SAML, chiffrement au repos et en transit, supervision/alertes, compression HTTP, gestion de l’état des index, snapshots quotidiens, domaines VPC…
Il y a aussi des manques : serverless, alertes interclusters, recherche interrégions, réplication entre clusters, plug-in tiers, authentification Kibana avec Cognito, requêtage SQL, requêtes directe sur Security Lake, recherche par similarité cosinus…
Sur Redshift, l’optimisation automatique des tables et la gestion automatique des workloads sont activées. Idem pour les requêtes entre bases de données, les snapshots et les points de restauration, les procédures stockées et les fonctions définies par l’utilisateur.
Il faudra patienter pour la version serverless, l’édition et la fédération de requêtes, ainsi que l’intégration avec Bedrock.
IA/ML
Bedrock est signalé comme disponible. Mais beaucoup de composantes manquent à l’appel : agents, RAG, marketplace, évaluations, apprentissage par renforcement, gestion et optimisation des prompts…
SageMaker AI est disponible pour l’inférence et l’entraînement, avec SDK Python, JupyterLab, registre de modèles, pipelines, recherche et conteneurs deep learning.
Pas de personnalisation des modèles, ni de batching pour l’entraînement.
Conteneurs
ECR (Elastic Container Registry) est disponible avec chiffrement double couche, scan d’images, IPv6, réplication intercomptes et intégrations CloudTrail/CloudWatch.
ECS (Elastic Container Service) l’est avec gestion de Fargate et de l’attachement de tâches EBS. Pas de déploiements blue-green, en revanche, ni de découverte de services.
Les nœuds hybrides et les groupes de nœuds managés sont disponibles sur EKS (Elastic Kubernetes Service). Comme IPv6, OIDC et les add-on.
Fargate n’est pas encore pris en charge.
Sécurité, identité, conformité
L’essentiel des fonctionnalités de Cognito sont disponibles. Même chose pour GuardDuty, mais sans la console ni la connexion avec Detective et Security Hub.
Sur Certificate Manager, la supervision des certificats est disponible comme la validation DNS, l’émission et l’exportation de certificats publics, leur importation, le renouvellement managé et la création de certificats TLS privés via l’autorité de certification AWS.
La validation HTTP n’est pas disponible. Il en va de même pour la validation e-mail.
Avec Directory Service, la suprervision, l’administration et le partage d’annuaire sont activés. Même chose pour le MFA, les politiques de mots de passe, l’extension de schéma et les snapshots quotidiens.
La remontée des métriques de contrôleurs de domaine dans CloudWatch n’est pas disponible. Comme la gestion des utilisateurs et des groupes.
Sur la partie IAM, la composante STS (Security Token Service) est disponible. Comme la récupération de compte et la centralisation des accès root.
Les passkeys ne le sont pas encore. La fédération non plus. Idem pour la gestion de principaux et la simulation de politiques.
En version « cloud souverain européen », AWS KMS gère les magasins de clés externes, mais pas les magasins personnalisés.
Sur Secrets Manager, l’essentiel est activé : récupération par lots, rotation automatique, contrôle d’accès avec IAM, métriques CloudWatch, réplication interrégions, génération de mots de passe, étiquetage et chiffrement des secrets…
La sécurité post-quantique pour TLS fait exception. Il faudra aussi attendre pour pouvoir déployer Secrets Manager avec AppConfig.
Le WAF (v2) est bien disponible, mais il manque notamment la protection contre le DDoS, les bots et la fraude. Ainsi que les intégrations App Runner, AppSync et Amplify.
Gestion, gouvernance
Le service AWS Auto Scaling gère, entre autres cibles, les services ECS, les clusters EMR, les réplicas Aurora, les ressources personnalisées, les tables et les index secondaires globaux DynamoDB et les groupes de réplication ElastiCache (Redis OSS et Valkey).
Les clusters Neptune sont sur la feuille de route, comme les flottes AppStream et les tables Keyspaces pour Cassandra.
Le cœur fonctionnel de CloudFormation est disponible (hooks, générateur IaC, StackSets, quotas de service…), mais la synchro Git ne l’est pas.
Avec CloudTrail, on accède à l’historique d’événements, à la piste d’audit et au serveur MCP. Pas aux insights ni aux événements agrégés.
Sur CloudWatch, métriques, dashboard et alarmes sont activés, comme l’extension Lambda Insights. Pipeline, signaux d’applications et RUM ne le sont pas. Sur la partie logs, pas mal d’éléments manquent encore : observabilité de la GenAI, indexation de champs, enrichissement, intégration des tables S3, centralisation entre comptes et régions…
RHEL, Ansible, OpenShift… En matière de cloud « souverain », l’offre de Red Hat est traditionnellement au cœur de la proposition de valeur d’IBM.
Elle pourrait l’être encore plus mi-2026. À cette échéance est prévu le lancement commercial d’une solution appelée IBM Sovereign Core.
La preview technique doit démarrer en février. Aucune feuille de route n’est publiée pour l’heure. IBM communique néanmoins un schéma donnant une idée de ce qui pourrait, à terme, composer l’offre.
La solution fonctionnera en mode déconnecté (air-gapped), avec un plan de contrôle géré par le client ou par un partenaire local. Les premiers officiellement dans la boucle sont Cegeka (pour le Benelux) et Computacenter (pour l’Allemagne).
La télémétrie restera en local, comme l’authentification, l’autorisation et le chiffrement. Le centre de conformité sera livré avec des politiques alignées sur les cadres de souveraineté nationaux – tout en permettant de personnaliser les règles.
AWS et SAP occupent aussi le terrain
Le discours d’IBM se porte nettement sur l’aspect « IA souveraine ».
SAP a choisi la même approche avec son offre EU AI Cloud, annoncée fin novembre 2025. Elle est à la croisée de la stratégie promue depuis quelques années sous la marque SAP Sovereign Cloud et des efforts du groupe allemand en matière d’intégration de modèles et de services IA. La « souveraineté » est promise à 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 »)
Pour le déploiement, quatre options, pas toutes disponibles en fonction des marchés : sur l’infra SAP, chez le client (en managé), chez des hyperscalers et chez Delos Cloud – filiale de SAP – pour le secteur public.
Dans la catégorie hyperscalers, il y aura notamment le « cloud souverain européen » d’AWS, qui vient d’en annoncer la disponibilité générale. L’épicentre se trouve en Allemagne. Des zones locales y seront connectées sur réseau privé. Les premières sont prévues en Belgique, aux Pays-Bas et au Portugal.
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…
Connexion
