Dix ans déjà que « La bonne alternance » a émergé chez France Travail, dans la lignée de « La bonne boîte ».

Ces services font chacun intervenir un algorithme qui analyse les recrutements passés pour prédire ceux à venir. Ils ont fait partie des premiers cas d’usage de l’IA au sein de l’établissement public.

Depuis, deux programmes se sont organisés. D’abord, « Intelligence emploi », mis en œuvre en 2019 et 2022. Il a permis la constitution d’une plate-forme technologique sur base open source et d’une équipe au sein de la DSI. Ensuite, « Data IA », engagé depuis 2024. Il est motivé par l’IA générative, le renforcement du pilotage de la donnée et l’élargissement des missions de France Travail avec la loi plein emploi.

La Cour des comptes s’est intéressée au déploiement de l’IA par l’agence d’emploi publique sur la période 2017-2025. Voici quelques éléments tirés de son rapport.

87 cas d’usage

La Cour des comptes a relevé 87 cas d’usage déployés ou testés sur la période en question.

Parmi eux, 27 sont utilisés à grande échelle. 16 sont en test. 25 sont en cours de conception. 17 ont été abandonnés au stade du test ou après déploiement. Plusieurs sont les variantes d’un même outil. Notamment de ChatFT (chatbot généraliste).

L’essentiel de ces 87 cas d’usage – 61, dont 26 déployés – ont pour seuls bénéficiaires directs les agents de France Travail. L’illustration, selon la Cour des comptes, d’une volonté de développer d’abord une culture de l’IA en interne.

Les principaux cas d’usage dont les demandeurs d’emploi sont bénéficiaires directs visent à :

• Faciliter le remplissage du profil dans l’espace personnel
• Suggérer des métiers en fonction des compétences
• Lire automatiquement les documents téléchargés et extraire des informations

Ces cas d’usage présentent des résultats plutôt positifs. Parmi eux, l’analyse automatique des CV, qu’utilisent 75 % des demandeurs d’emploi.

Des 6 cas d’usage bénéficiant directement aux entreprises, 3 ont été abandonnés en 2017. L’un touchait à l’analyse prédictive de l’attractivité des offres d’emploi.
Les deux seuls actuellement déployés consistent à :

• Prévoir le délai de pourvoi d’une offre à 30 jours (peu utilisé)
• Présenter, sur un site public, des données générales sur l’emploi à l’échelon territorial (peu de valeur ajoutée dans les projets de recrutement)

9 % d’utilisateurs quotidiens de l’IA

L’effectif de France Travail avoisine 54 000 agents.

Sur 34 945 ayant répondu à une enquête interne menée en mars 2025, 9 % ont déclaré utiliser chaque jour l’IA mise à leur disposition. 18 % ont affirmé s’en servir plusieurs fois par semaine. 39 % ont dit ne pas y recourir.

ChatFT est accessible à tout le personnel depuis novembre 2024. À fin juin 2025, 37 600 agents l’avaient utilisé au moins une fois. Ce mois-là, 17 400 s’en étaient servis au moins trois journées distinctes.
Sur la fin de la phase de test, une étude interne sur environ 700 conversations avait révélé que l’usage principal consistait à formuler des réponses à des e-mails (51 % des conversations), loin devant la recherche d’informations générales (10 %).

108 millions d’euros de coûts

En retenant une estimation basse des coûts de développement, France Travail a mobilisé 93 M€ pour l’IA entre 2017 et 2024.

Période	Montant des dépenses
Avant 2018	3 M€
Intelligence emploi 2018-2022	64 M€
Data IA 2019-2022	9 M€
Data IA 2023-2024	16 M€
Autres dépenses non rattachées	1 M€

Les « autres dépenses non rattachées » correspondent aux budgets pour une application « Reconnaissance des émotions ».

On en arrive aux 93 M€ sus évoqués. En y ajoutant le budget prévisionnel de 15 M€ pour 2025, le coût total du développement de l’IA sur la période considérée s’élève à 108 M€. La Cour des comptes compare ce montant aux 66 M€ que le ministère de l’Économie et des Finances a engagés sur 2015-2023 et explique la différence par un plus grand nombre de relations directes avec les usagers.

120 M€ de gains d’efficience

On atteint ce montant en retenant une estimation haute des gains réalisés depuis 2017. Cela inclut trois gains directs attendus :

• Cas d’usage du programme « Intelligence emploi » : 205 ETP par an à partir de 2023
• Service « Upload simplifié » (reconnaissance de documents) : 350 ETP/an à partir de 2024
• Service MatchFT (préqualification de profils par échange de SMS avec une IA) : 100 ETP en 2025

Soit, sur l’ensemble de la période étudiée, un total de 1415 ETP, que la Cour des comptes estime valorisables à 85 M€.

Les gains « indirects » liés à une charge de travail évitée par les conseillers seraient de 375 ETP. D’un côté, pour l’analyse automatique de CV, 27 ETP e 2023 et 48 par an à partir de 2024. De l’autre, 84 ETP par an à partir de 2023 pour le service « Lego », qui identifie les offres d’emploi illégales et empêche leur diffusion. L’ensemble serait valorisable à 23 M€.

Il faut y ajouter les coûts évités du fait du remplacement de logiciels par certains cas d’usage. En première ligne, la reconnaissance automatique de documents avec « Upload simplifié ».

14,4 M€ de dépassement pour « Intelligence emploi »

Le budget prévu pour ce programme était de 49,5 M€.
Le budget exécuté s’est élevé à 63,9 M€ (29 M€ de masse salariale, 33,9 M€ de dépenses de fonctionnement et 1 M€ de dépenses d’investissement).

France Travail justifie ce dépassement par l’allongement de 10 mois de la durée du projet, essentiellement en raison :

• De la crise Covid
• Du développement de cas d’usage initialement non prévus (Lego, analyse des CV, aide à la recherche d’info sur les sites de Pôle emploi…)
• De la comptabilisation de dépenses liées aux capacités techniques communes à d’autres développements de solutions d’IA non intégrées au programme

Dès janvier 2020, donc avant l’épisode Covid, la Dinum avait alerté quant au montant de dépenses de prestations intellectuelles envisagé (22,7 M€). Elle l’avait jugé « surdimensionné pour une démarche exploratoire dont le retour sur investissement n’est pas garanti ».
Les prestations extérieurs ont, en définitive, coûté 33,9 M€.

La Dinum avait aussi anticipé, à raison, le potentiel incertain d’appropriation, par les conseillers, du cas d’usage « Gestion automatisée des mails et assistant virtuel ». Pôle emploi avait refusé d’y mettre un terme, au motif que des gains d’efficience et de satisfaction pourraient être constatés à court terme.

205 ETP gagnés avec « Intelligence emploi »

En 2018, Pôle emploi prévoyait un gain annuel de 164 ETP à l’horizon 2022 (87 grâce à « Contact via mail » et 77 par l’utilisation d’un chatbot).

Le gain a finalement atteint 205 ETP (107 grâce à « Contact via mail », le reste via Lego). Objectif dépassé, donc ; mais qui, a posteriori, apparaît peu ambitieux. La Cour des comptes en veut pour preuve le ROI significativement plus faible que pour une sélection de projets IA du ministère de l’Économie et des Finances.

Ces gains ne se sont pas traduits par une réduction nette des effectifs, mais par des « redéploiements intra-postes ».

De 18 à 4 mois pour déployer un cas d’usage

Avant le premier programme, il fallait 18 mois pour déployer un cas d’usage. Il en faut maintenant 4. En parallèle, le recours à des intervenants extérieurs est passé de 60 % des prestations globales sur 2019-2020 à 40 % sur 2021-2022.

Des six cas d’usage principaux réalisés sur la durée du programme « Intelligence emploi », trois étaient consacrés essentiellement à faciliter le travail des conseillers. Un déséquilibre entre les publics ciblés qui allait s’accentuer avec le programme « Data IA ».

Avant le lancement du programme « Intelligence emploi », France Travail avait détecté plus de 80 cas d’usage potentiels. 90 % se sont révélés inadéquats. Essentiellement du fait de difficultés au niveau de la data ou de l’intégration au SI, ou à cause d’une surestimation de la valeur.

30 minutes de moins pour remplir un profil

Les cas d’usage mis en place lors du premier programme ont entraîné des gains d’efficience assez limités. Quelques minutes par jour pour la gestion des e-mails, par exemple.

La valeur ajoutée réside surtout dans le service rendu. L’analyse automatique du CV réduit ainsi de 45 à 15 minutes le temps nécessaire au demandeur d’emploi pour remplir son profil de compétences.

779 ETP à libérer sur 2025-2027

Le travail de transformation engagé pour répondre à l’élargissement des missions de France Travail est formalisé dans un programme, prolongé dans un plan d’efficience sur 3 ans (2025-2027).

Aux dernières nouvelles, ce plan vise à dégager un gain équivalant au minimum à 3192 ETP. L’IA doit y concourir à hauteur de 779 ETP.
En avril 2025, il était question de 822, dont 78 % provenant de trois cas d’usage :

• Aide rédactionnelle via ChatFT (226 ETP)
• Préparation d’entretiens via Néo, moteur de recherche d’infos dans les dossiers des demandeurs d’emploi (241 ETP)
• Alimentation plus facile de la GED via Panoptes (157 ETP), dont « Upload simplifié » est la déclinaison sur le site Internet de France Travail (en agence, cela s’appelle « Scanner », la version proposée aux services de l’État se nommant « Scanlab »)

Une analyse éthique pour 18 cas d’usage

Le respect des engagements pris dans la charte éthique publiée en avril 2022 n’est pas garanti, note la Cour des comptes. Seuls 18 cas d’usage ont fait l’objet d’un début d’analyse éthique formalisé.

Le recours à l’IA s’inscrit dans un contexte de numérisation de la relation avec France Travail. Entre 2017 et 2024, le nombre de visites annuelles en agence a chuté de 42 %. Tandis que le volume d’e-mails a augmenté de 72 %.

Illustration générée par IA

The post 10 chiffres sur le déploiement de l’IA chez France Travail appeared first on Silicon.fr.

Microsoft, désormais au niveau de Google et d’Amazon sur les puces IA ?

La deuxième génération des accélérateurs Maia – tout juste annoncée – s’accompagne en tout cas d’un comparatif de performance. Cela n’avait pas été le cas pour la première, présentée fin 2023.

D’une génération à l’autre, on est passé de 5 à 3 nm, de la HBM2 à la HBM3… et d’une approche généraliste à un message centré sur l’inférence, avant tout à faible précision (4 et 8 bits).

Vu ce focus, on aurait pu penser que Microsoft ferait la comparaison avec les puces Inferentia2 d’Amazon. Mais celles-ci ont, il est vrai, un certain âge (introduites fin 2022). L’accélérateur Maia 200 est donc opposé aux Trainium3 (dévoilées en décembre 2025 ; dédiées à l’entraînement). Ainsi qu’à la dernière génération de TPU de Google (Ironwood, introduite en avril 2025).

	Maia 200	Trainium3 (specs disponibles ici)	TPUv7x (specs disponibles ici)
Mémoire HBM	216 Go	144 Go	192 Go
Bande passante HBM	7 To/s	4,9 To/s	7,4 To/s
Bande passante scale-up	2,8 To/s	2,56 To/s	1,2 To/s
BF16	1268 Tflops	671 Tflops	2307 Tflops
FP8	5072 Tops	2517 Tops	4614 Tops
FP4	10 145 Tops	2517 Tops	n/a

Microsoft annonce une enveloppe thermique de 750 W pour Maia 200, tandis que les puces d’Amazon et de Google fonctionnent à environ 1000 W. Au final, il prétend que son accélérateur est « 40 % moins cher que les autres »…

Les puces Maia, pas exposées directement au client

Maia 100 n’est pas exposé directement aux clients finaux : il porte des services comme Copilot et Azure OpenAI, ainsi que des workloads HPC. La même stratégie se dessine avec les accélérateurs Maia 200. La division Microsoft Superintelligence en sera la première utilisatrice. On nous parle aussi d’une exploitation dans le cadre de Microsoft 365 et d’Azure AI Foundry. Mais pas d’une mise à disposition dans l’offre de compute.

Physiquement parlant, les premières puces seront localisées dans la région US Central (Iowa). La région US West 3 (Arizona) suivra. Elles sont déployables en configuration à refroidissement liquide ou à air.

De Maia 100 à Maia 200, on retrouve une couche réseau basée sur Ethernet, avec un protocole type RoCE. Une topologie intranœud est mise en place, connectant des groupes de 4 puces « en direct », sans switch. Un cluster peut accueillir au maximum 6144 puces.

La couche mémoire évolue, avec un partitionnement de la SRAM (272 Mo par puce) en deux niveaux logiques, chacun ayant son sous-système DMA. Le premier (TSRAM) alimente les tiles (plus petite unité autonome de calcul et de stockage local, embarquant moteurs matriciel et vectoriel) ; le deuxième (CSRAM), les clusters.
Cette approche favorise diverses stratégies de data management en fonction des noyaux. Les kernels d’attention, par exemple, peuvent épingler des tenseurs en TSRAM pour minimiser l’overhead. Tandis que les pipelines cross-kernel peuvent exploiter la CSRAM comme tampon pour le chaînage à haut débit.

Illustrations © Microsoft

The post Puces IA : face à Amazon et Google, Microsoft se replace appeared first on Silicon.fr.

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.

Illustration © Aryan – Adobe Stock

The post Serverless : faut-il privilégier l’observabilité native ? appeared first on Silicon.fr.

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 framework BPF 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.

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.

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.

Illustration principale © kwanchaift – Adobe Stock

The post Observabilité : eBPF, un atout dans la main des DevOps appeared first on Silicon.fr.

La nouvelle a quelques mois, mais voilà qu’elle dépasse l’île de Guam : Microsoft a fourni des clés BitLocker au FBI.

Sur place, 7 individus sont inculpés de fraude organisée à l’assurance-chômage dans le cadre d’un programme fédéral instauré lors de la crise Covid.

En octobre 2025, la presse locale s’était fait l’écho d’un mandat de la justice. Le destinataire : Microsoft, qui s’y est conformé… en communiquant les clés de récupération BitLocker pour trois ordinateurs saisis 6 mois plus tôt.

Le déchiffrement semble avoir fonctionné, apprend-on désormais. En tout cas à en croire les propos rapportés d’une des avocates de la défense. Le procureur lui aurait fourni des éléments comprenant des informations issues de l’ordinateur de sa cliente et incluant des références aux clés en question.

Les serveurs de Microsoft, option de sauvegarde « par défaut »

Microsoft a confirmé avoir accédé à cette demande – et précisé qu’il en reçoit une vingtaine de ce genre par an. Son message, en substance : utilisateurs, vous êtes les mieux placés pour décider comment vous gérez vos clés BitLocker.

La sauvegarde sur les serveurs de Microsoft n’est effectivement pas la seule option… même si elle est généreusement mise en avant sur les éditions « grand public » de Windows. Il est également possible de la sauvegarder dans un fichier texte, de la créer sur un média amovible (format .bek) ou simplement de choisir de l’imprimer. En environnement d’entreprise, on peut la stocker dans Active Directory.

Cette clé – un mot de passe de 48 chiffres, répartis en 8 groupes – est le dernier étage d’un mécanisme de chiffrement en enveloppe. Elle protège une autre clé (dité « clé principale de volume ») qui en protège elle-même une autre (dite « clé de chiffrement de volume »). L’une et l’autre demeurent sur le lecteur chiffré.

Depuis Windows 11 24H2, BitLocker s’active automatiquement pour qui utilise l’expérience de paramétrage par défaut du système. Si un compte Microsoft est disponible, y sauvegarder la clé de récupération BitLocker est la première option proposée. Elle n’apparaît pas si on opte pour un compte local – ce qui est néanmoins de plus en plus difficile, en tout cas sur les éditions Famille et Pro.

Illustration générée par IA

The post Microsoft confirme avoir transmis des clés BitLocker aux forces de l’ordre appeared first on Silicon.fr.

« 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.

Illustration générée par IA

The post SEALD absorbé par OVHcloud : ce qu’apporte cette acquisition appeared first on Silicon.fr.

Ceci n’est pas un concurrent du programme CVE de MITRE, mais un complément.

En façade, telle a toujours été la position du CERT luxembourgeois depuis l’annonce du projet GCVE (Global CVE Allocation System). C’était en avril 2025. On nous promettait alors le développement d’un système décentralisé : les autorités de numérotation allaient pouvoir attribuer des identifiants et gérer la divulgation sans passer par un organisme central.

Neuf mois plus tard, l’initiative, cofinancée par l’UE, a effectivement pris corps… dans une certaine mesure. Une base de vulnérabilités vient notamment d’y être adossée. Plusieurs bonnes pratiques ont par ailleurs été publiées pour assurer le fonctionnement du système. Et une vingtaine d’entités, de natures assez diverses, ont été désignées autorités de numérotation.

Autorité	Identifiant
CIRCL (CERT luxembourgeois)	1
EUVD	2
Red Hat	3
Swisscom	79
VulDB	100
Ericsson	101
EAGC	102
Schutzwerk	103
AboutCode Europe	104
OPC Foundation	105
SK-CERT	106
Thales PSIRT	107
Securin	108
Concinnity Risks	109
Vulnetix	110
Mogwai Labs	111
CERT-QC	112
VulnCheck	404
DFN-CERT Services	680
Austin Hackers Anonymous	1337
Pentagrid	2342
Cisco Talos	31337

Cette diversité reflète les critères d’admission : en théorie, quiconque a une politique de divulgation publique de vulnérabilités peut prétendre devenir autorité de numérotation.

L’identifiant 1 a été réservé au CIRCL, porteur du projet. Le 2, à la base EUVD (EU Vulnerability Database), opérée par l’ENISA (Agence européenne pour la sécurité). L’identifiant 0 est quant à lui dédié au mapping des CVE.

GCVE, contre les aléas géopolitiques

L’annuaire des autorités de numérotation est publié au format JSON. Ces dernières ont deux options pour communiquer les données sur les vulnérabilités. D’un côté, un endpoint statique fournissant un fichier. De l’autre, une API REST avec des points de terminaison recent et latest, éventuellement assortis de filtres (sources et nombre de résultats). Le projet GCVE n’impose pas de format, mais recommande de s’aligner sur CVE Record.

Les bonnes pratiques publiées concernent la vérification de l’intégrité du fichier d’annuaire, la divulgation coordonnée de vulnérabilités et l’attribution d’identifiants. Trois autres sont à l’état de brouillon. Elles abordent les formats de déclaration des vulnérabilités et le protocole de publication décentralisée.

Un outil open source sert d’implémentation de référence pour ces bonnes pratiques : vulnerability-lookup… qu’on doit aussi au CIRCL. C’est sur lui que repose la base GCVE*. L’EUVD aussi, d’ailleurs.

Pas d’opposition frontale avec MITRE, donc, mais un enjeu de résilience non dissimulé. Il s’agit à la fois d’éviter le « point de défaillance unique »… et de moins dépendre des aléas géopolitiques. En toile de fond, l’avenir un temps très incertain du programme CVE. L’an dernier, le gouvernement américain l’avait refinancé in extremis.

* Base hébergée dans les datacenters du CERT luxembourgeois.

Illustration générée par IA

The post L’Europe tient son programme CVE décentralisé appeared first on Silicon.fr.

Pour faire tomber la barrière de la langue, il y a OpenAI.

ServiceNow présente les choses ainsi. En toile de fond, un accord sur 3 ans qui le verra, entre autres, exploiter GPT-5.2 pour développer des technologies de compréhension et de synthèse vocales. Au bout, nous promet-on, il y aura des agents multilingues qui fonctionneront sans passer par la modalité texte.

Les modèles GPT seront également mis à contribution sur la partie computer use (« agent utilisateur d’ordinateur »). En ligne de mire, notamment, l’orchestration des outils bureautiques et l’automatisation des systèmes hérités (ServiceNow évoque les mainframes).

Les modèles OpenAI, déjà bien ancrés dans ServiceNow

Dans la pratique, ServiceNow a déjà établi de multiples passerelles avec OpenAI.

Sur sa plate-forme, les fonctionnalités conversationnelles, génératives et agentiques sont majoritairement regroupées sous la marque Now Assist.

Les produits Now Assist s’installent comme des plug-in. Ils donnent accès à trois types de composantes : des skills génératives, des agents et des flux agentiques. Ces briques ciblent généralement un usage au sein d’une application. Par exemple, pour les skills, la génération de documentation sur la partie gestion du travail collaboratif. Pour les workflows agentiques, l’obtention de conseils de gouvernance dans la CMDB.

Certains flux agentiques opèrent au niveau de la plate-forme : enquêter sur des incidents, créer des tâches à partir d’images, proposer des réponses à un sondage…

Par défaut, Now Assist repose sur un service interne, qui associe des modèles maison spécialisés* et des modèles ouverts « sélectionnés, configurés ou améliorés par ServiceNow, sa communauté ou ses partenaires ».

Pour certaines skills, il est possible de basculer sur des fournisseurs alternatifs : Google (Gemini 2.5 Flash et 2.5 Pro), Anthropic (Claude 3.7 Sonnet sur Amazon Bedrock)… ou OpenAI (GPT-4.1 et GPT-4.1-mini sur Azure OpenAI).

Avec toute application est installé un « contrôleur d’IA générative ». Il permet d’interfacer des LLM externes par API, au niveau des concepteurs de flux, d’agents et de scripts. En standard, cela donne quatre possibilités :

• Générer du texte à propos d’un topic ServiceNow
• Résumer un topic
• Créer un use case et un prompt associé
• Faire de l’analyse de sentiment

Ce contrôleur fait la passerelle avec OpenAI et Azure OpenAI. Ainsi qu’avec Google, Aleph Alpha, Amazon (Bedrock) et IBM (watsonx). Il inclut aussi un connecteur générique.

* En tête de liste, un modèle 12B à usage général (création de flux, modération, écriture de code…) fondé sur Mistral Nemo Instruct.

Illustration générée par IA

The post ServiceNow et OpenAI embrayent sur le vocal… et le legacy appeared first on Silicon.fr.

Terraform est efficace pour gérer de l’infrastructure ; pas des workflows data.

À force de s’en servir en conjonction avec Snowflake, Accor en est arrivé à ce constat. Entre absence de validation locale, gestion manuelle des dépendances et nécessité d’outils externes pour contrôler la qualité des données, la mise à l’échelle et la collaboration s’en trouvaient limitées.

Le groupe hôtelier a fini par basculer vers une stack associant dbt Core pour les transformations et un Airflow managé (Astro) pour l’orchestration, avec la bibliothèque Cosmos – proposée par le fournisseur d’Astro – pour faire la passerelle. Cette dernière déduit automatiquement le lignage des tâches et déclenche les contrôles de data quality immédiatement après la matérialisation d’une table ou d’une vue lors d’un dbt run.

Une déploiement Airflow « léger » qui rafraîchit uniquement les DAG

Le passage au tandem dbt-Airflow a impliqué un changement des pratiques de data engineering. Entre autres, passer d’étapes séparées pour la création et le peuplement de tables à une action unique utilisant exclusivement la commande SQL SELECT.

Chaque équipe possède son repo et déploie indépendamment. Tout part d’un template géré avec Copier. L’ensemble est réconcilié dans le projet principal, poussé vers Astro. Les scripts CI/CD sont centralisés dans un dépôt étiqueté.

Par défaut, Astro reconstruit l’image Docker à chaque modification. Le déploiement : dure alors environ 5 minutes. Il existe toutefois un mode « léger » dont Accor a tiré parti. Celui-ci synchronise simplement les DAG (graphes acycliques dirigés, représentant les tâches à exécuter) et évite ainsi un rebuild.

Pour exploiter ce mécanisme, le pipeline CI/CD place chaque projet dbt dans le répertoire dags/ du projet principal. Le déploiement dure alors environ 1 minute. Il couvre 95 % des exécutions. L’autre option reste utilisée pour l’upgrade des dépendances et les changements sur l’image de base (i.e. modification des fichiers include, requirements.txt ou Dockerfile).

Imbriquer chaque projet dbt dans le répertoire dags/ permet à Cosmo de générer automatiquement les tâches Airflow correspondantes. Et de construire des DAG sans intervention manuelle. Les tests peuvent se faire en local, avec dbt run et dbt test.

Accor vise un pipeline pour chaque équipe

Avec une telle configuration multilocataire, les cycles d’upgrade d’Airflow peuvent ralentir. Il n’y a, par ailleurs, pas moyen de prioriser des jobs. Et l’existence d’un seul chemin CI/CD vers la prod pose la question du point unique de défaillance, en plus des risques de conflit de noms et de bibliothèques.

Accor réfléchit donc à donner à chaque équipe son pipeline et à découpler la propriété du code. Tout en permettant l’hibernation des workflows à faible trafic.

Illustration générée par IA

The post Accor a écarté Terraform de sa stack data engineering appeared first on Silicon.fr.

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 :

Les premières distros Kubernetes « certifiées IA »
L’arrivée à maturité de Knative, couche serverless pour Kubernetes
Les choix de Databricks pour le load balancing Kubernetes
Michelin a réinternalisé son Kubernetes après 3 ans chez VMware

The post Kubernetes : les projets CNCF les plus déployés en production appeared first on Silicon.fr.

Infrastructures, licences, accès aux données, ingénierie… L’IA a des coûts évidents. Mais entre évolution des compétences, refonte des processus et gestion des risques, elle implique aussi des coûts cachés.

Ces derniers pourraient représenter une charge supplémentaire de l’ordre de 30 à 40 % des coûts génériques. Telle est en tout cas l’estimation d’IBM. Le Cigref y fait référence dans une note consacrée à l’évaluation du ROI des solutions d’IA générative et agentique.

Se concentrer sur l’utilisation du temps libéré

L’association mentionne une autre donnée chiffrée : les IA horizontales – les « assistants » – feraient gagner 50 minutes par jour à certains profils. Cela ne dit rien, néanmoins, de la manière dont ce temps libéré est utilisé.

Le Cigref appelle justement à se concentrer sur cet aspect. Il s’agit « que les gains de productivité d’aujourd’hui ne deviennent pas une fin en soi, mais le levier d’une compétitivité pour demain ». On distinguera, dans ce cadre, ce qui relève de la modernisation (efficience opérationnelle) et ce qui relève de la véritable transformation.

Dans cet esprit, des entreprises font la différence entre les hard savings (économies tangibles, mesurables dans un compte de résultat) et les soft savings (porteuses de gains futurs : réduction des erreurs, accélération des workflows…).

Entre arbres de valeur et suivi des nouvelles activités

Pour se focaliser sur la création de valeur rendue possible, le Cigref suggère l’approche « gestion de portefeuille ». Les cas d’usage n’y sont pas évalués isolément, mais au sein d’un ensemble équilibré d’initiatives, chacune ayant ses métriques de succès.

Concernant les actions de transformation prérequises (modernisation des logiciels, gouvernance des données, etc.), la métrique est le time-to-market pour de futurs cas d’usage, et la réduction des risques.

Pour les IA horizontales, des entreprises ont prévu de traiter l’enjeu de réallocation du temps par l’intermédiaire d’enquêtes qualitatives à propos de la nature des nouvelles activités.
L’une d’entre elles a décidé, pour les IA verticales, de coconstruire des arbres de création de valeur avec les métiers. L’objectif stratégique est décliné en leviers opérationnels sur lesquels l’IA peut agir. L’impact est ainsi mesuré sur des KPI existants.

Quelques éléments à intégrer dans l’évaluation des coûts et des bénéfices

Le Cigref distingue quatre catégories de coûts :

• Liés aux IA (matériel, licences, ingénierie, intégration, services…)
• Maintenance et supervision
• Gestion des risques et des échecs
• Transformation (modernisation de logiciels, refonte de processus métier, reskilling…)

Quatre catégories également pour ce qui est des éléments à prendre en compte dans l’estimation des bénéfices (opérationnels, organisationnels, stratégiques, financiers).

Sur le volet opérationnel, aux gains de productivité et à l’optimisation du temps d’implémentation s’ajoute la détection proactive des fraudes et des anomalies.

En matière organisationnelle, il y a l’exploitation et la valorisation des données (amélioration des modèles prédictifs, passage à l’échelle rendu possible…). Il y a aussi l’attractivité de l’organisation (mise en place de principes éthiques, engagement des employés…). La réduction du nombre d’outils par personne participant à un processus de décision fait partie des autres indicateurs pertinents.

Côté stratégique, le Cigref évoque, d’une part, l’expérience client (réduction du temps de réponse, personnalisation des interactions…). De l’autre, l’engagement et l’innovation (réduction du lead time, création de modèles économiques…).

La partie financière se partage entre génération de revenus (diminution du churn, optimisation du pricing…) et réduction des coûts et des risques.

L’ensemble peut être industrialisé en s’inspirant des modèles de centre d’excellence IA ou d’AI Factory. À condition notamment de définir des standards et de fournir des outils d’observabilité.

À consulter en complément :

Pourquoi il devient difficile de choisir une solution de gouvernance des données
L’Agentic AI Foundation veut des standards de l’IA autonome
En France, l’Autorité de la concurrence s’intéresse à l’aval de la chaîne GenAI
De prompt en vibe coding, le lexique de l’IA générative entre dans l’usage

Illustration générée par IA

The post ROI de l’IA générative : la tentation du prisme court-termiste appeared first on Silicon.fr.

La contribution financière de l’UE à EuroHPC peut désormais officiellement dépasser les 4 Md€.

En toile de fond, l’élargissement des missions de cette coentreprise.
Établie en 2021, elle fut d’abord chargée de développer un réseau de supercalculateurs.
En 2024, son périmètre d’activité avait été étendu aux « fabriques d’IA » (AI Factories). Des entités définies comme fournissant des « supercalculateurs optimisés par l’IA », conçus « principalement pour entraîner des modèles d’IA à usage général et à grande échelle ainsi que des applications d’IA émergentes ».

Depuis quelques jours, ce périmètre englobe les « gigafabriques d’IA » (AI GigaFactories). Elles sont définies comme des installations « [dotées] d’une capacité suffisante pour gérer l’ensemble du cycle de vie […] de très grands modèles et applications d’IA ».

La Commission européenne avait ouvert la voie à cette extension des responsabilités d’EuroHPC en juin 2025. Les AI GigaFactories embarqueraient « plus de 100 000 puces avancées » (en équivalent H100), contre 25 000 pour les plus grandes AI Factories, avait-elle affirmé.

Dans ce contexte, la notion de consortium, présente à la marge en 2021 et précisée dans une certaine mesure en 2024, devient centrale. Avec elle arrive la notion de gigafabrique multisite, étendue sur un ou plusieurs pays mais fonctionnant en tout cas comme une « entité technique intégrée » – avec au moins un site « correspondant à l’échelle d’une GigaFactory ».

L’informatique quantique en filigrane

En parallèle, le développement d’un écosystème d’informatique quantique apparaît dans les missions, les objectifs et les piliers d’activité d’EuroHPC.

L’enveloppe financière dédiée à la coentreprise augmente en conséquence. Elle passe de 3 081 300 000 € à 4 122 300 000 €, à raison de :

• 760 000 € de plus sur le programme Horizon Europe (dont 160 k€ pour le quantique)
• 161 000 € sur le programme pour une Europe numérique
• 120 000 € sur le mécanisme pour l’interconnexion en Europe

Le soutien des piliers d’activité – administration exceptée – via d’autres programmes de l’UE reste possible.

Pour les AI Factories, l’UE finance jusqu’à la moitié des dépenses d’investissement et des coûts d’exploitation. Il en va de même pour les ordinateurs et les simulateurs quantiques. Mais pas pour les AI GigaFactories : c’est au maximum 17 % des CAPEX. Un ou plusieurs États participants doivent apporter un montant au minimum équivalent. Les investissements restants sont à la charge du consortium, tout comme l’entièreté des OPEX. Au cas où une AI Factory deviendrait une AI GigaFactory, le soutien financier reçu en première phase serait reporté sur la seconde (pas de cumul, donc).

* États membres de l’UE + Albanie, Islande, Israël, Macédoine du Nord, Moldavie, Monténégro, Royaume-Uni, Serbie, Suisse et Turquie.

Illustration générée par IA

The post L’Europe enclenche le passage à l’échelle de ses « fabriques d’IA » appeared first on Silicon.fr.

Les années passent… et il y a encore du NTLMv1 qui traîne.

Mandiant a récemment émis un rappel à ce sujet… et l’a accompagné de rainbow tables. Il y en a pour environ 100 Go de données, sous licence CC BY 4.0, téléchargeables via la console Google Cloud ou l’outil gsutil (elles sont dans des buckets GCP).

Promesse : grâce à ces tables, récupérer des clés en moins de 12 heures avec du matériel grand public coûtant moins de 600 $. Une méthode alternative aux attaques par force brute avec hashcat et C^ie. Lesquelles sont moins efficaces à mesure que la longueur des secrets augmente.

Pour quelques rainbow tables de plus

Les rainbow tables de Mandiant semblent cibler les mots de passe de 7 caractères de longueur.

Le projet RainbowCrack – une référence dans le domaine, intégré à notamment à Kali Linux – va jusqu’à 10 avec ses propres tables. Il annonce des taux de réussite entre 96,8 % et 99,9 %.

Plage de caractères	Nombre de caractères	Taux de réussite	Poids
Ascii 32 à 95	7	99,9 %	52 Go
Ascii 32 à 95	8	96,8 %	460 Go
Majuscules, minuscules, chiffres	8	99,9 %	127 Go
Majuscules, minuscules, chiffres	9	96,8 %	690 Go
Minuscules, chiffres	9	99,9 %	65 Go
Minuscules, chiffres	10	96,8 %	316 Go

NTLM, un grand chantier pour Microsoft

De longue date, la v1 du protocole NTLM est considérée comme insuffisamment sécurisé. Le guide de l’ANSSI sur l’administration des environnements Active Directory résume sa faiblesse : il permet d’obtenir des condensats (hashs) par simple capture du trafic réseau. Dans la pratique, les attaques forceront typiquement l’authentification depuis un objet AD à haut niveau de privilèges, comme un contrôleur de domaine.

NTLMv1 a officiellement été supprimé des OS Microsoft avec Windows 11 24H2 et Windows Server 2025. Mais il y a des restes dans certains scénarios. Entre autres lors de l’utilisation de MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2) dans un environnement joint à un domaine. Solution recommandée : déployer Credential Guard… et exploiter les fonctionnalités d’audit, renforcées pour l’occasion.

L’objectif de Microsoft est de désactiver complètement le protocole à terme, pour aller vers Kerberos. Il a fallu adapter ce dernier afin de lui apporter certaines caractéristiques spécifiques de NTLM – qui ont d’ailleurs favorisé son intégration « en dur » par certaines applications. Par exemple, l’absence d’exigence de connexion réseau locale à un contrôleur de domaine. La fonctionnalité dite IAKerb a été introduite à ces fins. Elle permet l’authentification sur un contrôleur de domaine via un serveur mandataire.

Illustration générée par IA

The post Face à la persistance de NTLMv1, Mandiant publie ses rainbow tables appeared first on Silicon.fr.

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).

* Boeschen et al., 2024 : « GOLAP: A GPU-in-Data-Path Architecture for High-Speed OLAP »
Kabic et al., 2025 : « Powerful GPUs or Fast Interconnects: Analyzing Relational Workloads on Modern GPUs »
Wu et al., 2025 : « Terabyte-Scale Analytics in the Blink of an Eye »

Illustration générée par IA

The post Dans le cloud public, le rapport coût-performance stagne appeared first on Silicon.fr.

En matière de cyber, selon qu’on est CEO ou CISO, on privilégiera la prévention des pertes financières ou la résilience opérationnelle.

Rien d’exceptionnel dans ce constat. Mais il trouve une illustration notable dans le dernier rapport Global Cybersecurity Outlook du Forum économique mondial. D’une année à l’autre, les principales inquiétudes exprimées ont effectivement divergé entre les deux fonctions.

En 2025, les ransomwares étaient en tête de liste chez les CEO comme chez les CISO. Les premiers citaient ensuite fraude / phishing et perturbations de la supply chain. Les seconds faisaient de même, mais dans l’ordre inverse.

Cette année, les ransomwares restent la principale préoccupation des CISO (devant les perturbations de la supply chain et l’exploitation de vulnérabilités logicielles). Ils ne sont, en revanche, plus dans top 3 chez les CEO, qui s’inquiètent en premier lieu de la fraude et du phishing ; puis des vulnérabilités de l’IA et des logiciels.

Des différences entre organisations, il y en a aussi en fonction du niveau de cyberrésilience estimé. Les répondants* qui le jugent élevé ont tendance à craindre avant tout les perturbations de la supply chain. Et, au contraire, à mettre les vulnérabilités IA en dernier sur leur liste. Cependant, si on restreint cet échantillon aux CEO, les vulnérabilités deviennent la crainte numéro un…
Cet « effet CEO » est moins significatif parmi les organisations dont le niveau de cyberrésilience est jugé insuffisant.

La GenAI, désormais crainte en premier lieu pour les fuites de données

Si on zoome sur la GenAI, les inquiétudes des CEO sont plus proches de celles de l’échantillon dans son ensemble.

(Une seule réponse possible)	Fuites de données	Développement des capacités des attaquants	Sécurité technique des systèmes d’IA	Complexification de la gouvernance	Risques de supply chain logicielle	Propriété intellectuelle et responsabilité
Ensemble	34 %	29 %	13 %	12 %	7 %	4 %
CEO	30 %	28 %	15 %	13 %	9 %	6 %

Sur l’ensemble de l’échantillon, l’item « fuites de données » est nettement plus sélectionné que l’an dernier (+ 12 points).

Lorsqu’on leur demande quels risques sont en croissance, les répondants choisissent majoritairement les vulnérabilités de l’IA (87 %). Viennent ensuite :

• Fraude / phishing (77 %)
• Perturbations de supply chain (65 %)
• Vulnérabilités logicielles (58 %)
• Ransomwares (54 %)
• Menaces internes (32 %)
• Déni de service (28 %)

Face au risque de supply chain, la fonction sécurité souvent impliquée dans le processus d’approvisionnement

Concernant le risque sur la supply chain, la hiérarchie des méthodes de gestion est similaire entre niveaux de cyberrésilience, mais avec un écart de 20 à 30 points.

	Évaluation de la maturité cyber des fournisseurs	Implication de la fonction sécurité dans les processus d’achat	Paetages d’informations sur la menace avec les partenaires	Cartographie du niveau d’exposition des partenaires	Simulation d’incidents et/ou d’exercices de récupération avec les partenaires
Ensemble	68 %	65 %	38 %	33 %	27 %
Haute résilience	74 %	76 %	53 %	44 %	44 %
Résilience insuffisante	48 %	53 %	31 %	23 %	16 %
CEO, haute résilience	59 %	70 %	30 %	48 %	44 %
CEO, résilience insuffisante	31 %	31 %	38 %	31 %	6 %

L’adoption de l’IA dans la cyber sert le plus souvent la détection du phishing et des autres menaces sur la messagerie électronique (52 % des sondés ont sélectionné cette réponse parmi 3 maximum). Suivent :

• Détection et réponse aux intrusions ou anomalies (46 %)
• Automatisation des opérations (43 %)
• Analyse du comportement des utilisateurs et détection des menaces internes (40 %)
• Tri du renseignement sur les menaces et priorisation des risques (39 %)
• Autres objectifs (8 %)

Dans 64 % des organisations ici représentées, les outils IA sont évalués avant déploiement (révision unique pour 24 %, périodique pour 40 %). Ce taux passe à 45 % chez celles où le niveau de cyberrésilience est jugé insuffisant.

Le manque de connaissances et/ou de compétences est le premier obstacle à l’adoption de ces outils. 54 % des répondants le citent. Ils sont 41 % à évoquer la nécessité d’une validation humaine des réponses de l’IA avant implémentation.

* 804 répondants dont 544 C-Levels parmi lesquels 316 CISO et 105 CEO.

Illustration générée par IA

The post Cybersécurité : entre CISO et CEO, les priorités divergent appeared first on Silicon.fr.

À l’échelle mondiale, les organisations apparaissent plutôt confiantes quant à leur cyberrésilience.

Ce constat était ressorti de la première édition du rapport Global Security Outlook réalisé par le Forum économique mondial avec Accenture. C’était en 2022. Les deux tiers des répondants (67 %) estimaient que leur organisation atteignait les exigences minimales. Près d’un sur cinq (19 %) jugeait qu’elle les dépassait. Ils n’étaient que 14 % à déclarer un niveau insuffisant de cyberrésilience.

Depuis, en quatre autres éditions, le niveau de confiance est resté élevé. En 2026, il repart même globalement à la hausse.

	Insuffisant	Remplit les exigences minimales	Dépasse les exigences
2022	14 %	67 %	19 %
2023	21 %	51 %	28 %
2024	25 %	36 %	39 %
2025	22 %	69 %	9 %
2026	17 %	64 %	19 %

La cyberrésilience des États, jugée moins positivement

Pour cette édition 2026, 804 réponses ont été retenues, issues de 92 pays. 544 proviennent de C-levels parmi lesquels 316 CISO* et 105 CEO. Le reste de l’échantillon est constitué par des membres de la société civile et du monde académique, ainsi que des « leaders en cybersécurité » du secteur public.

Si on trie les réponses par secteurs, le secteur privé apparaît plus confiant quant à sa cyberrésilience.

	Insuffisant	Remplit les exigences minimales	Dépasse les exigences
Secteur privé	11 %	67 %	22%
Secteur public et « grandes organisations internationales »	23 %	54 %	24 %
ONG	37 %	55 %	8 %

Les répondants ne jugent pas aussi positivement la cyberrésilience du pays où leur organisation est basée. Ils sont en tout cas 37 % à se dire confiants quant à la capacité de réponse aux incidents touchant des infrastructures critiques (contre 42 % en 2025). Et 31 % à se déclarer non confiants (contre 26 % en 2025).
Si on s’en tient aux CEO du secteur privé, le taux de répondants confiants est un peu plus élevé (43 %, pour 31 % de non confiants).

Le risque géopolitique fait croître les budgets cyber… dans une certaine mesure

Quand on leur demande comment la géopolitique fait évoluer la stratégie de cyberrésilience de leur organisation, les répondants sélectionnent le plus souvent l’item « focus accru sur la threat intelligence liée aux acteurs étatiques » (36 %). Arrivent ensuite :

• Interactions accrues avec les agences gouvernementales ou les groupes de partage de renseignements (33 %)
• Augmentation du budget cyber (21 %)
• Changement – ou intention de changer – de fournisseurs (19 %)
• Arrêt des activités dans certains pays (14 %)

Si on zoome sur les CEO, par niveau de résilience estimé :

	Acteurs étatiques	Gouvernements	Budget	Fournisseurs	Activités
Haute résilience	52 %	48 %	30 %	30 %	19 %
Résilience insuffisante	13 %	6 %	13 %	13 %	6 %

Des défis corrélés au niveau de résilience estimé

Lorsqu’on leur demande de sélectionner au maximum trois éléments qui constituent un défi à la cyberrésilience, les sondés choisissent :

• À 61 %, l’évolution rapide du paysage de la menace et les technologies émergentes
• À 46 %, les vulnérabilités tierces et sur la supply chain
• À 45 %, le manque de compétences
• À 31 %, les systèmes hérités
• À 30 %, le manque de fonds
• À 24 %, le manque de visibilité sur les environnements IT/OT/IoT
• À 24 %, les complexités de conformité et de gouvernance
• À 22 %, une planification insuffisante de la réponse à incident

Dans le secteur privé, on invoque prioritairement le paysage de la menace (59 %), les vulnérabilités tierces (53 %), le manque de compétences (38 %) et le manque de fonds (26 %).
Dans le secteur public et les grandes organisations, la hiérarchie est similaire, sinon que le manque de compétences est nettement plus cité (57 %). Même constat dans les ONG (51 %), où les répondants sont également nombreux à déplorer le manque de fonds (62 %).

Sur l’ensemble de l’échantillon, par niveau de résilience estimé :

	Évolution des menaces	Vulnérabilités tierces	Compétences	Legacy	Fonds	IT/OT/IoT	Gouvernance	Réponse aux incidents
Haute résilience	67 %	71 %	35 %	22 %	14 %	17 %	31 %	15 %
Résilience insuffisante	41 %	23 %	53 %	35 %	52 %	28 %	15 %	37 %

Si on s’en tient aux CEO, toujours par niveau de résilience estimé, l’argument des fonds est plus souvent invoqué :

	Évolution des menaces	Vulnérabilités tierces	Compétences	Legacy	Fonds	IT/OT/IoT	Gouvernance	Réponse aux incidents
Haute résilience	56 %	78 %	19 %	15 %	15 %	19 %	41 %	15 %
Résilience insuffisante	13 %	31 %	56 %	25 %	63 %	56 %	25 %	19 %

* Dont au moins, côté français, Christophe Blassiau (CISO groupe de Schneider Electric), qui a participé à des focus groups en complément au volet qualitatif de l’étude. 

The post Cyberrésilience : des organisations plus confiantes en elles-mêmes qu’envers les États appeared first on Silicon.fr.

« Non, je ne peux pas le garantir ».

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.

Illustration principale générée par IA
Portraits © DR, Amazon Web Services

The post Cloud européen d’AWS : la gouvernance et les engagements juridiques appeared first on Silicon.fr.

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.

Instances à la demande

Type d’instance	Cloud souverain	Paris
Usage général	t4g.nano (2 vCPU + 0,5 GiB + EBS + 5 Gbit) : 0,0047 € m7i.48xlarge (192 vCPU + 768 GiB + EBS + 50 Gbit) : 11,44 €	t4g.nano : 0,0047 $ m7i.48xlarge : 11,29 $
Optimisé calcul	c6g.medium (1 vCPU + 2 GiB + EBS + 10 Gbit) : 0,0383 € c7i.48xlarge (192 vCPU + 384 GiB + EBS + 50Gbit) : 9,65 €	c7i.48xlarge : 10,18 $
Optimisé mémoire	r6g.medium (1 vCPU + 8 GiB + EBS + 10 Gbit) : 0,06 € r7i.metal-48xl (192 vCPU + 1536 GiB + EBS + 50 Gbit) : 15,12 €	r6g.medium : 0,06 $
Optimisé stockage	i4i.large (2 vCPU + 16 GiB + SSD NVMe 468 + 10 Gbit) : 0,20 € i4i.metal (128 vCPU + 1024 GiB + 8 SSD NVMe 3750 + 75 Gbit) : 12,93 €	i4i.large : 0,20 $ i4i.metal : 12,74 $

Instances dédiées à la demande

Type d’instance	Cloud souverain	Paris
Usage général	t3.nano (2 vCPU + 0,5 GiB + EBS + 5 Gbit) : 0,0059 € m7i.metal-48xl (192 vCPU + 768 GiB + EBS + 50 Gbit) : 11,44 €	t3.nano : 0,0059 $ m7i.metal-48xl : 11,29 $
Optimisé calcul	c6g.medium : 0,41 € c7i.metal-48xl (192 vCPU + 384 GiB + EBS + 50 Gbit) : 9,65 €	c6g.medium : 0,043 $ c7i.metal-48xl : 10,18 $
Optimisé mémoire	r6g.medium : 0,0636 € r7i.48xlarge (192 vCPU + 1536 GiB + EBS + 50 Gbit) : 15,12 €	r6g.medium : 0,063 $ r7i.48xlarge : 14,92 $
Optimisé stockage	i4i.large : 0,22 € i4i.32xlarge (128 vCPU + 1024 GiB + 8 SSD 3750 + 75 Gbit) : 12,92 €	i4i.large : 0,22 $ i4i.32xlarge : 12,74 $

 

2. Lambda

Version x86

– Sur l’offre de cloud souverain

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

Volumes provisionnés (io2)

– Sur l’offre de cloud souverain

Stockage : 0,15 €/Go-mois
IOPS : 0,077 €/IOPS provisionnées par mois jusqu’à 32 000 ; 0,054 € jusqu’à 64 000 ; 0,038 € au-delà

– Dans la région AWS Paris

Stockage : 0,15 $/Go-mois
IOPS : 0,077 $/IOPS provisionnées par mois jusqu’à 32 000 ; 0,053 $ jusqu’à 64 000 ; 0,037 $ au-delà

Volumes froids (sc1)

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

2. SageMaker AI

	Cloud souverain	Paris
JupyterLab	ml.t3.medium (2 vCPU + 4 GiB) : 0,056842995 €/heure ml.m7i.48xlarge (192 vCPU + 768 GiB) : 13,73 €/heure	ml.t3.medium : 0,057 $/heure ml.m7i.48xlarge : 13,55 $
Entraînement	ml.t3.large (2 vCPU + 8 GiB) : 0,11 €/heure ml.m7i.48xlarge : 13,73 €/heure	ml.t3.large : 0,11 $/heure ml.m7i.48xlarge : 13,46 $/heure
Inférence (temps réel)	ml.m6g.large (2 vCPU + 8 GiB) : 0,11 €/heure ml.m7i.48xlarge : 13,73 €/heure	ml.m6g.large : 0,22 $/heure ml.m7i.48xlarge : 13,46 $/heure

Services de sécurité/identité/conformité

1. KMS

– Sur l’offre de cloud souverain

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à)

Services de bases de données

1. DocumentDB

	Cloud souverain	Paris
Instances à usage général	dg.t4g.medium (2 vCPU + 4 GiB) : 0,088 €/heure (Standard) ou 0,097 € (version optimisée E/S) db.t3.medium (2 vCPU + 4 GiB) : 0,091 € (Standard) ou 0,10 € (E/S)	dg.t4g.medium : 0,085 $ (Standard) ou 0,094 $ (E/S) db.t3.medium : 0,088 $ (Standard) ou 0,097 $ (E/S)
Instances optimisées mémoire	db.r6g.large (2 vCPU + 16 GiB) : 0,313 € (Standard) ou 0,344 € (E/S) db.r8g.16xlarge (64 vCPU + 512 GiB) : 10,52 € (Standard) ou 11,57 € (E/S)	db.r6g.large : 0,30 $ (Standard) ou 0,33 $ (E/S)
Instances NVMe	db.r6gd.large (4 vCPU + 32 GiB + SSD 237) : 0,764 € db.r6gd.16xlarge (64 vCPU + 512 GiB + 2 SSD 1900) : 12,23 €	db.r6gd.16xlarge : 11,87 $
Stockage	0,12 €/Go-mois (Standard) ou 0,35 €/Go-mois (E/S)	0,12 $/Go-mois (Standard) ou 0,35 $/Go-mois (E/S)
I/O	0,22 € par million de demandes (Standard)	0,23 $ par million de demandes (Standard)

2. DynamoDB

	Cloud souverain	Paris
Lectures/écritures	0,75 € par million d’unités d’écriture 0,15 € par million d’unités de lecture	0,74 $ par million d’unités d’écriture 0,15 $ par million d’unités de lecture
Stockage	Standard : 0,30 €/Go-mois au-delà de 25 Go Standard avec accès peu fréquent : 0,12 €/Go-mois	Standard : 0,30 $/Go-mois au-delà de 25 Go Standard avec accès peu fréquent : 0,12 $/Go-mois
Sauvegarde à la demande	0,12 €/Go-mois (à chaud) 0,0362374092 €/Go-mois (à froid)	0,12 $/Go-mois (à chaud) 0,03566 $/Go-mois (à froid)
Restauration de table	0,18 €/Go-mois (à chaud) 0,24 €/Go-mois (à froid)	0,18 $/Go-mois (à chaud) 0,24 $/Go-mois (à froid)
Export/import S3	Import : 0,18 €/Go Export : 0,12 €/Go	Import : 0,18 $/Go Export : 0,12 $/Go

3. ElastiCache

Version serverless

– Sur l’offre de cloud souverain

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

Nœuds à la demande

	Cloud souverain	Paris
Standards	cache.t4g.micro (2 vCPU + 0,5 GiB + 5 Gbit) : 0,01421007487 €/heure cache.m7g.16xlarge (64 vCPU + 210 GiB + 22,5 Gbit) : 4,73 €/heure	cache.t4g.micro : 0,0144 $/heure cache.m7g.16xlarge : 4,64 $/heure
Optimisés mémoire	cache.r7g.large (2 vCPU + 13 GiB + 12,5 Gbit) : 0,21 €/heure cache.r7g.16xlarge (64 vCPU + 419 GiB + 30 Gbit) : 6,63 €/heure	cache.r7g.large : 0,20 $/heure cache.r7g.16xlarge : 6,52 $/heure

Illustration générée par IA

The post Le « cloud souverain européen » d’AWS, combien ça coûte ? appeared first on Silicon.fr.

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 endpoints dual-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…

Illustration générée par IA

The post AWS lance son « cloud souverain européen » : les services disponibles appeared first on Silicon.fr.

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.

Illustration principale génrée par IA

The post IBM prépare une nouvelle nuance de « cloud souverain » sur base OpenShift appeared first on Silicon.fr.