Les services natifs du cloud provider pour les métriques et les alertes, OpenTelemetry pour les traces.
Un article paru il y a quelques semaines dans l’International Journal of Computer Techniques propose cette stratégie d’observabilité pour le serverless. On le doit à une ancienne de Microsoft, qui fut notamment directrice scientifique au sein de l’activité Azure AI.
Son analyse porte plus précisément sur un sous-ensemble du calcul sans serveur : le FaaS (functions as a service). Dans ces environnements, les ressources sont généralement éphémères, distribuées et à haute concurrence. Les points d’intégration peuvent par ailleurs être nombreux… et inclure des services managés « en boîte noire » qui exigent de l’instrumentation.
Natif, full OpenTelemetry ou hybride ?
Les conclusions n’ont pas valeur de vérité absolue : l’expérimentation a été effectuée à petite échelle – de sorte qu’on peut la reproduire en local ou dans un compte de test – et tous les paramètres étaient sous contrôle.
Le cas d’usage exploré reposait sur des traces synthétiques de type e-commerce. Le workflow – présenté uniquement à haut niveau – comprenait 4 étapes : passerelle API -> fonction A -> fonction B (appel HTTP à une API externe non spécifiée) -> DynamoDB. Il s’agissait d’y adosser diverses stratégies d’observabilité, en mesurant 4 indicateurs :
Allongement médian de la durée d’exécution des fonctions
Proportion de traces complètes
Délai médian pour découvrir la cause racine sur des simulations d’erreurs à partir de la télémétrie disponible
Coût par million de requêtes (base : tarification publique de X-Ray et CloudWatch + estimations pour un back-end Jaeger autohébergé)
La première stratégie évaluée reposait intégralement sur les outils d’observabilité d’AWS (CloudWatch pour métriques et alertes, X-Ray pour les traces). La deuxième était full OpenTelemetry. La troisième, hybride, associait CloudWatch (télémétrie pilotée par les SLO) et OpenTelemetry (back-end Jaeger/Tempo ou managé), avec un échantillonnage adaptatif.
Overhead
Traces complètes
MTRC
Coût
Natif
9 – 12 ms
82 %
18 min
6,20 $
OTel
18 – 25 ms
95 %
9 min
4,80 $
Hybride
11 – 15 ms
93 %
10 min
5,10 $
La méthode native est celle qui entraîne le moins de surcharge. Mais elle produit le plus de traces incomplètes, sauf à ajouter de l’instrumentation. Et s’il simplifie l’exploitation, X-Ray implique un certain verrouillage (limites de portabilité et de conservation de la télémétrie).
En centralisant sur OpenTelemetry, les traces sont plus « riches ». Mais l’overhead augmente. Comme les coûts, en plus des compétences nécessaires.
L’approche hybride orientée SLO (on ne collecte en haute fidélité que pour les éléments critiques de ce point de vue) n’est ni la plus « légère », ni la plus précise, ni la plus économique. Mais elle constitue un compromis.
À consulter en complément, une étude universitaire qui pointe – et chiffre – divers facteurs techniques et contractuels générateurs de surcoûts sur les principales plates-formes serverless.
Capturer sélectivement des paquets réseau sans tout transmettre vers l’espace utilisateur : telle fut la première raison d’être de BPF (Berkeley Packet Filter). C’était dans les années 90, sur les systèmes UNIX-BSD. La technologie permettait, à l’appui d’un jeu d’instructions virtuel RISC-like et d’un interpréteur, d’injecter des programmes dans le noyau pour en étendre les capacités à l’exécution.
Les premiers usages au-delà du réseau avaient émergé au début des années 2010. À commencer par l’outil seccomp-bpf, servant à filtrer les syscalls. Les travaux de modernisation lancés dans ce contexte aboutirent à eBPF (extended BPF). Cette nouvelle incarnation fut intégrée à Linux en 2014. À la clé, entre autres, des instructions et des structures de données supplémentaires, davantage de registres, un compilateur JIT et des points d’attache additionnels pour les programmes. La promesse demeurait : apporter de l’extensibilité au kernel sans passer par des modules ou changer le code source.
Sur ce socle, des projets sont d’abord nés dans le domaine du traçage. Des couches d’abstraction ont pris corps en parallèle, comme la boîte à outils BCC (BPF Compiler Collection), associant front-end Python/Lua et back-end C pour faciliter l’écriture de programmes. Tandis que le compilateur fut intégré dans LLVM.
Cilium, une couche d’abstraction devenue référente
Facebook fut l’un des premiers à industrialiser eBPF, avec un équilibreur de charge L4 pour ses datacenters : Katran, aujourd’hui open source. La possibilité d’attacher eBPF très en amont sur le chemin de réception – en l’occurrence, au niveau du piote NIC – permet d’effectuer le load balancing à la source, sans NAT (paquets traités avant interception par le noyau).
Google a quant à lui contribué à faire avancer les choses dans le champ de la sécurité. Dans le cadre de l’extension de son offre Kubernetes vers les infrastructures sur site (sous les marques Anthos et GDC), il a donné naissance au frameworkBPF LSM. Celui-ci adapte le principe des modules de sécurité à l’écosystème eBPF, en permettant d’utiliser les mêmes hooks (points d’attache) que SELinux.
Pour rendre la technologie plus accessible, le projet Cilium fut lancé en 2016. Avec, pour le porter, une société aujourd’hui référente dans l’écosystème eBPF : Isovalent, qui appartient à Cisco depuis 2024. Il assurait initialement la mise en réseau de conteneurs. Dans ces environnements où les adresses IP tournent beaucoup, ses tables de hachage en ont fait une alternative plus « élastique » à Iptables/netfilter.
Et vint l’observabilité
Après la mise en réseau vint l’observabilité, favorisée par la multiplicité des points d’attache exploitables. En plus de ceux prédéfinis (appels système, entrées/sorties de fonctions, tracepoints…), on peut utiliser des sondes noyau (kprobes) et utilisateur (uprobes). Mais aussi des fonctions arbitraires, en les étiquetant. L’exécution est orientée événements : les programmes eBPF se déclenchent lorsque le noyau ou une application passe par ces hooks.
Ce modèle ouvre la porte à la collecte de données sans instrumentation (pas de modification du code des applications ou des agents d’observabilité) et consommant potentiellement moins de ressources système. Cilium l’implémente via une plate-forme intégrée : Hubble, qui cartographie les services et donne une visibilité des flux grâce aux identités de workloads. Il y a ajouté une brique pour sécuriser l’exécution : Tetragon, qui met en œuvre des politiques de contrôle d’accès sur les fonctions noyau, les syscalls, etc.
S’économiser l’instrumentation… dans certains cas
Datadog aussi a un usage assez transversal d’eBPF : analyse de performance des applications (Universal Service Monitoring), visibilité sur le trafic réseau (Cloud Network Monitoring), détection des menaces (Workload Protection), supervision d’intégrité des fichiers (application de règles pour limiter les envois)…
« Sans eBPF, on aurait probablement besoin de consentir un effort de modification de la configuration des agents », fait remarquer Pejman Tabassomi, Field CTO EMEA, concernant le monitoring réseau. Sur la partie APM (surveillance des performances des applications), l’approche traditionnelle d’instrumentation « permet d’aller loin dans les détails, mais c’est contraignant parce qu’on est dépendant d’un framework ou d’un runtime», explique l’intéressé. eBPF « permet d’arriver à un objectif par tout à fait identique mais comparable, sans avoir à recourir à une librairie », déclare-t-il.
Pas tout à fait identique, donc. « Il y a une sorte de compromis entre le niveau d’introspection et la facilité de mise en œuvre », résume Pejman Tabassomi. Il l’illustre par un cas d’observation des temps de réponse entre deux services. Pour mesurer le nombre et la durée des appels, eBPF peut suffire. En revanche, s’il y a besoin de comprendre les lignes de code qui peuvent poser problème, les appels de fonctions et de méthodes qui sont en cause, « à ce moment-là, on va plutôt faire de l’APM. » Non sans surveiller des initiatives communautaires tel le profiler de code en cours de développement dans l’univers OpenTelemetry.
Chez Splunk, « l’histoire avec eBPF a démarré lors du rachat de Flowmill » en 2020, fait savoir Stéphane Estevez, EMEA Market Advisor pour l’observabilité. Cet outil de monitoring réseau a alimenté la stratégie « full OpenTelemetry » de l’éditeur. « Être chez Cisco nous a donné l’accès à Isovalent pour l’observabilité et la sécurité », précise Stéphane Estevez. Tetragon, par exemple, alimente des dashboards TCP et DNS dans la composante Network Explorer.
Chez IBM, Instana est le principal terrain d’implémentation d’eBPF. La technologie présente une utilité particulière pour la détection des crashs système, selon Éric Cattoir, membre d’une équipe au niveau EMEA qui couvre les sujets regroupés sous la bannière IT Automation. En écho à Pejman Tabassomi, il déclare, sur le volet instrumentation : « Ça rend la vie plus facile pour notre produit : on a moins à suivre l’évolution des technologies (nouvelles versions de langages, de compilateurs…) ». Instana a toujours eu une approche d’auto-instrumentation, rappelle-t-il, « mais c’est difficile à mettre en place pour certains langages : eBPF facilite cela en permettant d’obtenir de manière standard des informations de profilage ».
On trouve aussi de l’eBPF dans le produit SevOne (observabilité réseau), pour la couche overlay de Kubernetes.
Des programmes composables et portables
Avec les années, les programmes eBPF sont devenus composables : ils peuvent appeler des fonctions (forme de gosub)… et d’autres programmes en remplaçant le contexte d’exécution (goto). Un mécanisme CO-RE (« Compile Once, Run Everywhere ») a été instauré à partir d’un format spécifique de métadonnées (BTF, BPF Type Format) pour procurer une portabilité entre les versions du kernel. Et des passerelles se sont créées avec l’espace utilisateur, à travers une des structures de données que gère eBPF : les magasins clé-valeur dits maps. Des outils sont par ailleurs apparus pour exécuter des programmes en userspace (rBPF, uBPF, bpftime). Ils ont accompagné l’émergence de langages de jaut niveau tel bpftrace – inspiré de DTrace, avec LLVM en back-end et BCC pour interagir avec le sous-système eBPF.
Ce programme eBPF basique (codé en C) écrit un message dans le noyau.
Sauf à activer le mode sans privilèges avec accès limité au noyau, les processus qui chargent des programmes eBPF doivent s’exécuter en mode admin ou avoir la capacité CAP_BPF. La mémoire est protégée en lecture seule et les accès sont masqués pour limiter les effets secondaires observables de l’exécution spéculative. Si une entité tente de modifier le programme, le noyau plante.
Le code passe dans tous les cas par un vérificateur statique. Lequel contrôle, en particulier, que le programme est d’une complexité finie, qu’il se terminera bien et qu’il n’entraînera pas de deadlock ni d’accès mémoire hors limites. Dans la pratique, l’outil reste sujet aux faux positifs. Jusqu’à Linux 5.3, les boucles étaient d’ailleurs proscrites dans les programmes eBPF, le vérificateur étant jugé capable de les évaluer efficacement.
Une fondation où convergent les Big Tech
Depuis 2021, il existe une Fondation eBPF. Google, Meta et Isovalent en sont membres platine. CrowdStrike – qui exploite la techno pour détecter les mouvements de données non autorisés – l’est aussi. Ainsi que Huawei, Intel, Microsoft – qui développe eBPF pour Windows tout en l’exploitant en remplacement du fournisseur d’événements AuditD dans Defender pour Linux – et Red Hat. Datadog est membre argent. Netflix, qui avait pris très tôt le train eBPF, l’est aussi.
Architecture cible d’eBPF pour Windows
Conjointement aux initiatives du marché, cette fondation soutient des projets académiques, à l’instar d’eBPF Governor, alternative aux sous-systèmes de gestion de l’alimentation sur Linux. Des recherches sont également en cours sur la vérification formelle des programmes, en complément à la réécriture du vérificateur en Rust.
Plusieurs projets devenus référents dans l’écosystème eBPF sont maintenant sous l’aile de la CNCF (Cloud Native Computing Foundation). Outre Cilium, on peut citer Falco (détection de menaces), confié en 2018 par Sysdig. Dans le champ de l’observabilité, il y a Pixie, que New Relic a reversé à la CNCF en 2021, quelques mois après en avoir fait l’acquisition (il en propose aujourd’hui une version SaaS).
Pièce maîtresse du réseau mondial de Cloudflare, eBPF a aussi investi les clouds hyperscale. À l’instar de Google sur GKE, AWS s’en sert sur son Kubernetes managé (Caretta pour la cartographie réseau, Hubble pour l’analyse du trafic). Il l’a aussi intégré dans CloudWatch (composante Network Flow Monitor) et de GuardDuty (EC2 Runtime Monitoring). Microsoft l’exploite pour contourner Iptables sur les data planes de offre AKS (Azure Kubernetes Services).
Pour le monitoring, Dynatrace a choisi de s’appuyer sur Inspektor Gadget, framework CNCF qui encapsule les programmes eBPF sous forme d’images OCI. Il le met à contribution dans un module de découverte de services.
Chez Elastic, eBPF alimente le profilage continu, ainsi que la protection de Linux et de Kubernetes dans le cadre de l’offre SIEM/XDR.
La Commission européenne travaillerait sur un nouveau cadre législatif visant à renforcer la souveraineté technologique de l’Union, dans un contexte de tensions commerciales croissantes avec les États-Unis. Selon plusieurs responsables européens, l’objectif ne serait pas d’exclure les entreprises américaines du marché européen, mais de réduire les dépendances stratégiques …
Running modern versions of Adobe Photoshop on Linux has long been difficult, mainly because the installation process depends on Adobe Creative Cloud, which has historically failed to work properly through Wine. That situation may now be changing. According to a recent update shared by an independent developer known as PhialsBasement, Photoshop 2021 and 2025 can now be installed and run on Linux in a stable way, thanks to a set […]
Après une journée difficile, Microsoft confirme le rétablissement de ses services cloud ce vendredi, malgré quelques lenteurs résiduelles possibles durant les opérations de maintenance.
« Et puis il y a eu ce post LinkedIn qui a attiré l’attention d’Octave Klaba […] »
Jérôme Masurel, président de 50 Partners, contextualise ainsi l’acquisition de SEALD par OVHcloud. L’accélérateur connaît bien cette entreprise francilienne : il avait participé, en 2018, à sa levée d’amorçage.
Depuis lors, SEALD est resté sur le même créneau : le chiffrement de bout en bout. Sa technologie se décline en logiciels bureautiques et sous forme de SDK. Elle avait obtenu le visa CSPN en décembre 2020 (trois ans de validité).
Les premières briques de SEALD posées en Californie
Créé en 2016, SEALD s’est d’abord appelé STASH. Ce pendant quelques semaines, le temps qu’une agence marketing française portant le même nom lui adresse une mise en demeure.
Les quatre fondateurs étaient alors dans leur vingtaine. Trois d’entre eux avaient convergé à UC Berkeley, dans le cadre d’un programme en partenariat avec l’École polytechnique. Les jalons de SEALD furent posés sur place par Timothée Rebours (32 ans aujourd’hui), qui prendrait la présidence de l’entreprise. Aux côtés de trois directeurs généraux : Mehdi Kouen (33 ans, CTO), Maxime Huber (34 ans, CPO) et Dan Lousqui (37 ans, directeur de la sécurité informatique).
Quelques semaines avant l’obtention de la CSPN, SEALD avait fait partie des finalistes du prix de l’innovation des Assises de la sécurité. Plus récemment (2023), il a figuré dans les lauréats de l’appel à projets « Suites bureautiques collaboratives cloud », en consortium avec Linagora, WaToo, Wimi et XWiki. Entre-temps, il y avait eu une alerte : une continuation d’activité malgré la perte de la moitié du capital.
Framatome et Stellantis comme références
La déclinaison « bureautique » de SEALD est basée sur une application desktop (Windows, Mac, Linux) qui permet de chiffrer des fichiers, d’assurer leur suivi et de contrôler les accès. La technologie couvre aussi les e-mails et leurs pièces jointes, en éventuelle conjonction avec les moteurs de DLP.
La version « bibliothèque logicielle » permet d’intégrer du chiffrement côté client dans des apps web, mobiles et de bureau. La promesse par rapport aux bibliothèques open source : supprimer les difficultés de gestion des clés, des appareils multiples, des droits d’accès sur les données, etc. Des SDK sont disponibles pour JavaScript, Android, iOS et Flutter.
Framatome y a fait appel pour sécuriser une application interne collectant des données sensibles. L’opérateur télécoms belge Proximus, pour une application de téléconsultation médicale (Doktr). Recare, pour son outil de bed management (orchestration des transferts interhospitaliers). Lovehoney Group, pour protéger une messagerie de couple basée sur CometChat. Stellantis et Lefebvre Sarrut font aussi partie des clients.
Le ticket d’entrée est à 250 €/mois pour 5000 utilisateurs protégés. Au-delà, SEALD facture un supplément dégressif par utilisateur (0,04 €jusqu’à 20 000 ; 0,03 € jusqu’à 50 000 ; 0,02 € au-delà).
« Ensemble, nous allors démocratiser [la] sécurité dans les services [collaboratifs] (et pas que…) », commente Octave Klaba.
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.
Connexion
