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
Des checkpoints, du replay… et ça donne des fonctions Lambda « durables ».
AWS a mis cette option en lumière lors de sa conférence re:Invent 2025. La promesse : des exécutions qui peuvent durer jusqu’à 1 an, avec une reprise fiable après interruption ou mise en pause.
Un SDK à intégrer dans le code des fonctions permet d’implémenter les primitives qui gèrent ce mécanisme. Les mises en pause peuvent se faire pour une durée déterminée. On peut aussi conditionner la reprise à un événement donné.
La facturation se fait sur trois plans :
Opérations « durables » (étapes, pauses, callbacks) : 8 $ le million
Données écrites : 0,25 $/Go
Données conservées : 0,15 $/Go/mois
Lambda en un peu moins serverless
Autre option mise en avant : les instances Lambda managées. Il s’agit ici de choisir les configurations EC2 sur lesquelles exécuter les fonctions.
On crée pour cela des « fournisseurs de capacités ». Ces fournisseurs s’exécutent dans le compte AWS, au sein d’un VPC (et au moins d’un sous-réseau). On peut en paramétrer certains aspects :
Architecture CPU
Types d’instances autorisées (liste blanche, liste noire ou sans restriction)
Nombre maximal d’instances
Mode de mise à l’échelle (manuelle ou automatique)
Clé de chiffrement EBS (éventuellement personnalisée)
Un autre modèle de concurrence…
Lorsqu’on publie une version d’une fonction associée à un fournisseur de capacité, Lambda lance des instances managées (3 par défaut, pour la résilience). Ou bien il en utilise des existantes si les ressources sont suffisantes pour accueillir l’environnement d’exécution.
De même, un environnement d’exécution peut gérer plusieurs invocations en parallèle (64 maximum). Le modèle de concurrence est donc différent de celui de Lambda « standard » (une invocation = un environnement).
… de sécurité…
Ce système suppose que la sûreté des threads, la gestion d’état et l’isolation du contexte doivent être gérés différemment en fonction du contexte.
Les fournisseurs de sécurité constituent en fait la limite de confiance. Avec les instances Lambda managées, les fonctions s’exécutent effectivement dans des conteneurs, lesquels ne fournissent pas le même niveau de sécurité que la techno de micro-VM Firecracker utilisée en standard.
… de scaling…
Avec les instances Lambda managées, pas de démarrage à froid. La mise à l’échelle est asynchrone, sur la base de signaux de consommation CPU. Dans cet esprit, l’option est donc à réserver aux workloads dont le trafic est prévisible. AWS ne garantit d’ailleurs pas la stabilité si la charge fait plus que doubler dans un intervalle de 5 minutes.
Quatre paramètres influent sur la mise à l’échelle :
Quantités de mémoire et de vCPU allouées à une fonction
Concurrence maximale par environnement
Cible d’utilisation de ressources
Types d’instances autorisés
… et de tarification
Les instances Lambda managées sont facturées au prix d’EC2 à la demande… avec 15 % de frais supplémentaires. L’option permet néanmoins d’exploiter d’éventuelles remises (savings plans, instances réservées…). Il faut ajouter des frais de 0,20 $ par million de requêtes.
Plus besoin de shards ni de requêtes fédérées : vous pouvez consolider vos données vectorielles en un seul index.
AWS en fait l’un des arguments de S3 Vectors, lancé en disponibilité générale lors de la re:Invent.
Avec S3 Vectors, la promesse d’un index unique
Le service était en previewdepuis juillet. Il apporte une gestion native des vecteurs dans S3, avec un type de bucket spécifique. Sur le papier, c’est une alternative moins onéreuse à Aurora Serverless et OpenSearch Serverless, en contrepartie de temps de réponse allongés (« sous la seconde », affirme AWS).
La préversion permettait de stocker jusqu’à 50 millions de vecteurs par index (et 10 000 index par bucket). Avec la version commerciale, on passe à 2 milliards, d’où l’argument de la consolidation. Autre seuil relevé : le nombre maximal de résultats par requête (100 désormais, contre 30 en preview). Quant à la latence, elle est maintenant « fréquemment sous les 100 ms ».
S3 Vectors a une intégration avec Bedrock Knowledge Bases (RAG) et avec Amazon OpenSearch (utilisation comme moteur sur les clusters managés ou injection d’un snapshot dans la version serverless).
L’accélération GPU activée sur OpenSearch
En parallèle, une option d’accélération GPU fait son entrée sur l’OpenSearch d’AWS. Promesse : construire des bases vectorielles « jusqu’à 10 fois plus vite » pour un quart du prix traditionnel, grâce à un usage optimisé de l’infra. En complément, il devient possible de régler les niveaux de rappel et de latence souhaités.
Une mémoire épisodique pour les agents Bedrock
À l’occasion de la re:Invent, il y a aussi du nouveau dans Bedrock AgentCore. Cette offre, lancée à l’été 2025, est dans la lignée de Bedrock Agents. Elle en a étendu les capacités (gestion native de MCP et contrôle plus fin de la mémoire, par exemple) et en a désagrégé la plupart en modules indépendants, par ailleurs « détachés » de Bedrock de sorte qu’ils prennent en charge des technologies non disponibles sur la plate-forme.
Voilà Bedrock AgentCore doté d’une forme de mémoire épisodique. Avec cette stratégie, les agents capturent des « épisodes structurants » (contexte, processus de raisonnement, actions, résultats). Ils sont censés pouvoir ainsi agir de façon plus cohérente lorsqu’ils rencontrent des situations similaires.
AWS dote aussi AgentCore de la diffusion audio bidirectionnelle. Lors des interactions vocales, l’agent peut être interrompu et s’adapter au nouveau contexte sans avoir à terminer son action au préalable.
Un service managé de supervision est également ajouté, mais pour le moment en preview. On peut y intégrer des évaluations personnalisées en plus de celles livrées pour analyser des indicateurs tels que la précision, l’utilité, la concision et la sûreté. Les résultats sont délivrés dans CloudWatch.
Autre preview : celle de la fonctionnalité Policy in AgentCore. Elle permet d’intercepter les appels d’outils sur la passerelle et de leur appliquer des stratégies définies en langage naturel ou avec Cedar.
Les derniers modèles Mistral et Gemma ajoutés sur Bedrock
AWS a aussi profité de la re:Invent pour rappeler les derniers ajouts de modèles ouverts sur Bedrock. Parmi eux :
Mistral Large 3, Ministral 3 (3B, 8B, 14B), Magistral Small 1.2, Voxtral Mini 1.0, Voxtral Small 1.0
Gemma 3 (4B, 12B, 27B)
Kimi K2 Thinking (de Moonshot AI)
MiniMax M2 (de MiniMax AI)
Nemotron Nano 2 9B et une version « vision » 12B (de NVIDIA)
GPT-OSS-safeguard 20B et 120B (modèles de modération de contenu)
Qwen3-Next-80B-A3B et Qwen3-VL-235B-A22B
Nova Sonic : une deuxième génération plus polyglotte
Amazon enrichit aussi sa propre famille de modèles Nova. Avec notamment Nova 2 Sonic.
La première génération de ce modèle de reconnaissance et de synthèse vocales avait été lancée en avril. La deuxième gère mieux les entrées alphanumériques, les énoncés courts, les accents, le bruit de fond et l’audio qualité téléphonie (8 kHz). Avec elle arrivent les « voix polyglottes » (capacité à changer de langue au milieu d’une conversation), les appels d’outils asynchrones et un réglage de sensibilité pour la détection de voix (ce qui laisse plus ou moins de temps à l’utilisateur pour finir sa phrase).
AWS lance Nova dans le bain de l’automatisation web
Sous la marque Nova Forge, AWS permet de continuer l’entraînement de ses propres modèles à partir de divers checkpoints, en utilisant des jeux de données spécialisés « sur étagère » ou en en important. L’ensemble repose sur l’outillage SageMaker AI et permet d’effectuer éventuellement de l’apprentissage par renforcement.
On trouve aussi un modèle Amazon (Nova 2 Lite) à la base de Nova Act, service d’automatisation agentique pour les navigateurs web. Il est intégré avec le framework d’ochestration Strands Agents.
Les données synthétiques sous l’angle privacy
Les serveurs de tracking MLflow qu’on peut greffer depuis l’an dernier à SageMaker pour superviser les expérimentations ML disposent désormais d’une option serverless. Avec la possibilité de partager des instances entre domaines et comptes AWS.
Le service Clean Rooms (salles blanches de données) permet quant à lui maintenant de créer des jeux de données synthétiques (tabulaires, destinées à entraîner des modèles de régression et de classification ; pas des LLM). Le système utilise un modèle qui reproduit les patterns statistiques du dataset d’origine tout en éliminant les données identifiantes. En ce sens, il est présenté comme une alternative aux techniques d’anonymisation.
AI Factories : AWS s’approprie aussi la notion
AWS s’approprie le concept des AI Factories en lançant une offre sous ce nom. On n’en sait pas grand-chose à l’heure actuelle, sinon qu’elle doit permettre de déployer des clusters IA managés (puces Trainium et NVIDIA + services AWS) dans les datacenters des clients, « comme une région AWS privée ». Premier client référent : l’entreprise saoudienne HUMAIN, qui va installer sur place une « zone IA » avec jusqu’à 150 000 GPU.
Des fonctions Lambda « durables »
Les fonctions Lambda durables ne sont pas spécifiques aux workloads IA, mais elles sont susceptibles de faciliter leur exécution.
Par « durables », il faut entendre « dont la durée de vie peut atteindre 1 an ». Elle peuvent effectivement être mises en pause jusqu’à ce que des conditions spécifiques soient remplies (typiquement, des événements externes). Seul le temps de calcul actif est facturé.
Un SDK s’intègre au code des fonctions pour pouvoir implémenter ces pauses. Ainsi que des « étapes » permettant de ne pas reprendre l’exécution depuis le début en cas d’échec.
Les grandes entreprises combinent plusieurs clouds pour répartir les workloads, optimiser les coûts, rapprocher les données des utilisateurs et limiter les risques de dépendance à un seul fournisseur. Jusqu’ici, relier ces environnements impliquait soit l’usage d’Internet public sans garanties de bande passante, soit des montages de connectivité privée complexes, longs à déployer et coûteux à exploiter.
L’alliance entre AWS et Google Cloud combine le nouveau service AWS Interconnect- multicloud et Google Cloud Cross-Cloud Interconnect pour proposer une connectivité privée et automatisée entre les deux environnements. Elle fournit une connectivité entre VPC AWS et VPC/VPC‑SC Google Cloud, intégrée de manière native aux consoles et APIs des deux fournisseurs.
Google Cloud avait déjà positionné Cross-Cloud Interconnect comme brique clé de son architecture “Cross-Cloud Network”, permettant de relier Google Cloud à AWS, Azure, Oracle Cloud Infrastructure et d’autres MSP via des liens privés à haut débit.
Les deux acteurs mettent en avant une automatisation poussée : les clients peuvent réserver de la capacité dédiée à la demande et établir la connectivité en quelques minutes, sans gérer directement le câblage, les circuits ni l’infrastructure physique sous‑jacente.
L’annonce inclut une spécification ouverte pour l’interopérabilité réseau entre clouds décrite comme un standard commun de connectivité privée qui vise à réduire la complexité de l’adressage, du routage et de la gestion des politiques réseau entre environnements AWS et Google Cloud.
L’objectif est de permettre à d’autres fournisseurs de cloud d’implémenter le même modèle, afin d’étendre ce socle d’interopérabilité au‑delà du seul duo AWS–Google Cloud. Cette ouverture pourrait favoriser l’émergence d’un écosystème où les clouds majeurs s’alignent sur des standards communs de connectivité privée, à l’image de ce qui existe déjà pour certains protocoles réseau et interfaces de peering.
Caractéristiques techniques mises en avant
Sur le plan technique, Cross-Cloud Interconnect fournit des liaisons privées avec des capacités de 10 ou 100 Gbit/s dans de nombreux sites mondiaux, gérées par Google côté physique, avec des métriques de performance détaillées (latence, pertes de paquets, temps de trajet aller‑retour).
Les documents techniques de Google décrivent un modèle de double attachement (primaire et redondant) et l’utilisation de BGP pour l’échange de routes entre Google Cloud et AWS, avec des exigences de haute disponibilité.
AWS Interconnect-multicloud, en préview, est présenté comme un service managé offrant des connexions privées simples, résilientes et à haut débit vers d’autres clouds, intégrées avec les outils réseau et d’observabilité AWS.
L’intégration avec Cross-Cloud Interconnect vise à abstraire la gestion des ports, des circuits et des délais de provisioning, en exposant une expérience de type “cloud‑native” dans les deux consoles.
Cas d’usage et bénéfices clients
L’alliance cible des scénarios où les données ou applications sont réparties entre AWS et Google Cloud, par exemple pour des plateformes analytiques, des charges IA/ML, ou l’intégration de SaaS opérant sur plusieurs clouds.
Un exemple cité concerne l’intégration de Salesforce Data 360, qui nécessite des ponts privés robustes entre différents environnements pour alimenter des cas d’usage d’IA et d’analytique sur des données réparties.
Pour les clients, les bénéfices mis en avant sont la réduction du temps de mise en service des liaisons, la simplification opérationnelle (moins de gestion d’infrastructure physique) et de meilleures garanties de performance que l’Internet public. L’approche standardisée doit aussi faciliter la gouvernance réseau et la sécurité dans des environnements multicloud complexes, où les architectures doivent concilier segmentation, conformité et performance de bout en bout.
Sous le feu des critiques des associations professionnelles et scrutés par les régulateurs, les deux grands CSP américains engagent un mouvement vers un modèle où la connectivité inter‑cloud devient un service managé de première classe, au même titre que le compute ou le stockage, plutôt qu’un assemblage de liens télécoms et de configurations spécifiques.
Reste à observer dans quelle mesure les autres fournisseurs adopteront la spécification proposée et comment les intégrateurs réseau et opérateurs télécoms adapteront leurs offres face à cette montée en puissance de la connectivité multicloud native.
Le plan de contrôle de Route 53 n’est plus tout à fait monorégion.
AWS l’a effectivement répliqué en partie. Et ainsi réduit la dépendance à la région cloud us-east-1.
En toile de fond, l’incident d’octobre. Il a pris racine dans cette région cloud, (re)mettant en lumière le point faible qu’elle constitue. Entre autres, donc, parce que quantité de services y ont leur plan de contrôle.
Une récupération « accélérée »…
La réplication partielle de celui de Route 53 se traduit par une option de « récupération accélérée ». On peut l’activer pour chaque zone hébergée publique (conteneur d’enregistrements définissant l’acheminement du trafic d’un domaine spécifique sur le réseau Internet). Une copie de la zone est alors conservée dans la région us-west-1.
… avec un RTO de 60 minutes
En cas d’indisponibilité prolongée dans la région us-east-1, une bascule est censée s’effectuer… dans un délai de 60 minutes. On n’a alors pas accès à l’ensemble des méthodes API. Mais les principales sont disponibles : listage des zones, des enregistrements et des ensembles de délégation, soumission et suivi de changements, etc.
En période de bascule, il n’est pas possible de créer de zones, ni d’en supprimer. On ne peut pas non plus (dés)activer la signature DNSSEC. Et les connexions AWS PrivateLink ne fonctionnent pas. Par après, pour supprimer une zone, il faut d’abord désactiver l’option de « récupération accélérée ». Laquelle, pour préciser, ne concerne pas le volet DNS privé de Route 53.
Une panne AWS en US-EAST-1 liée à la résolution de noms perturbe des services dans le monde, Amazon confirme une reprise progressive et un suivi public détaillé.
Aujourd’hui, dans Affaires Sensibles, le naufrage de l’USS Indianapolis, le 30 juillet 1945 : la pire catastrophe de l’histoire de la marine américaine
Connexion
