Les services natifs du cloud provider pour les métriques et les alertes, OpenTelemetry pour les traces.
Un article paru il y a quelques semaines dans l’International Journal of Computer Techniques propose cette stratégie d’observabilité pour le serverless. On le doit à une ancienne de Microsoft, qui fut notamment directrice scientifique au sein de l’activité Azure AI.
Son analyse porte plus précisément sur un sous-ensemble du calcul sans serveur : le FaaS (functions as a service). Dans ces environnements, les ressources sont généralement éphémères, distribuées et à haute concurrence. Les points d’intégration peuvent par ailleurs être nombreux… et inclure des services managés « en boîte noire » qui exigent de l’instrumentation.
Natif, full OpenTelemetry ou hybride ?
Les conclusions n’ont pas valeur de vérité absolue : l’expérimentation a été effectuée à petite échelle – de sorte qu’on peut la reproduire en local ou dans un compte de test – et tous les paramètres étaient sous contrôle.
Le cas d’usage exploré reposait sur des traces synthétiques de type e-commerce. Le workflow – présenté uniquement à haut niveau – comprenait 4 étapes : passerelle API -> fonction A -> fonction B (appel HTTP à une API externe non spécifiée) -> DynamoDB. Il s’agissait d’y adosser diverses stratégies d’observabilité, en mesurant 4 indicateurs :
Allongement médian de la durée d’exécution des fonctions
Proportion de traces complètes
Délai médian pour découvrir la cause racine sur des simulations d’erreurs à partir de la télémétrie disponible
Coût par million de requêtes (base : tarification publique de X-Ray et CloudWatch + estimations pour un back-end Jaeger autohébergé)
La première stratégie évaluée reposait intégralement sur les outils d’observabilité d’AWS (CloudWatch pour métriques et alertes, X-Ray pour les traces). La deuxième était full OpenTelemetry. La troisième, hybride, associait CloudWatch (télémétrie pilotée par les SLO) et OpenTelemetry (back-end Jaeger/Tempo ou managé), avec un échantillonnage adaptatif.
Overhead
Traces complètes
MTRC
Coût
Natif
9 – 12 ms
82 %
18 min
6,20 $
OTel
18 – 25 ms
95 %
9 min
4,80 $
Hybride
11 – 15 ms
93 %
10 min
5,10 $
La méthode native est celle qui entraîne le moins de surcharge. Mais elle produit le plus de traces incomplètes, sauf à ajouter de l’instrumentation. Et s’il simplifie l’exploitation, X-Ray implique un certain verrouillage (limites de portabilité et de conservation de la télémétrie).
En centralisant sur OpenTelemetry, les traces sont plus « riches ». Mais l’overhead augmente. Comme les coûts, en plus des compétences nécessaires.
L’approche hybride orientée SLO (on ne collecte en haute fidélité que pour les éléments critiques de ce point de vue) n’est ni la plus « légère », ni la plus précise, ni la plus économique. Mais elle constitue un compromis.
À consulter en complément, une étude universitaire qui pointe – et chiffre – divers facteurs techniques et contractuels générateurs de surcoûts sur les principales plates-formes serverless.
Capturer sélectivement des paquets réseau sans tout transmettre vers l’espace utilisateur : telle fut la première raison d’être de BPF (Berkeley Packet Filter). C’était dans les années 90, sur les systèmes UNIX-BSD. La technologie permettait, à l’appui d’un jeu d’instructions virtuel RISC-like et d’un interpréteur, d’injecter des programmes dans le noyau pour en étendre les capacités à l’exécution.
Les premiers usages au-delà du réseau avaient émergé au début des années 2010. À commencer par l’outil seccomp-bpf, servant à filtrer les syscalls. Les travaux de modernisation lancés dans ce contexte aboutirent à eBPF (extended BPF). Cette nouvelle incarnation fut intégrée à Linux en 2014. À la clé, entre autres, des instructions et des structures de données supplémentaires, davantage de registres, un compilateur JIT et des points d’attache additionnels pour les programmes. La promesse demeurait : apporter de l’extensibilité au kernel sans passer par des modules ou changer le code source.
Sur ce socle, des projets sont d’abord nés dans le domaine du traçage. Des couches d’abstraction ont pris corps en parallèle, comme la boîte à outils BCC (BPF Compiler Collection), associant front-end Python/Lua et back-end C pour faciliter l’écriture de programmes. Tandis que le compilateur fut intégré dans LLVM.
Cilium, une couche d’abstraction devenue référente
Facebook fut l’un des premiers à industrialiser eBPF, avec un équilibreur de charge L4 pour ses datacenters : Katran, aujourd’hui open source. La possibilité d’attacher eBPF très en amont sur le chemin de réception – en l’occurrence, au niveau du piote NIC – permet d’effectuer le load balancing à la source, sans NAT (paquets traités avant interception par le noyau).
Google a quant à lui contribué à faire avancer les choses dans le champ de la sécurité. Dans le cadre de l’extension de son offre Kubernetes vers les infrastructures sur site (sous les marques Anthos et GDC), il a donné naissance au frameworkBPF LSM. Celui-ci adapte le principe des modules de sécurité à l’écosystème eBPF, en permettant d’utiliser les mêmes hooks (points d’attache) que SELinux.
Pour rendre la technologie plus accessible, le projet Cilium fut lancé en 2016. Avec, pour le porter, une société aujourd’hui référente dans l’écosystème eBPF : Isovalent, qui appartient à Cisco depuis 2024. Il assurait initialement la mise en réseau de conteneurs. Dans ces environnements où les adresses IP tournent beaucoup, ses tables de hachage en ont fait une alternative plus « élastique » à Iptables/netfilter.
Et vint l’observabilité
Après la mise en réseau vint l’observabilité, favorisée par la multiplicité des points d’attache exploitables. En plus de ceux prédéfinis (appels système, entrées/sorties de fonctions, tracepoints…), on peut utiliser des sondes noyau (kprobes) et utilisateur (uprobes). Mais aussi des fonctions arbitraires, en les étiquetant. L’exécution est orientée événements : les programmes eBPF se déclenchent lorsque le noyau ou une application passe par ces hooks.
Ce modèle ouvre la porte à la collecte de données sans instrumentation (pas de modification du code des applications ou des agents d’observabilité) et consommant potentiellement moins de ressources système. Cilium l’implémente via une plate-forme intégrée : Hubble, qui cartographie les services et donne une visibilité des flux grâce aux identités de workloads. Il y a ajouté une brique pour sécuriser l’exécution : Tetragon, qui met en œuvre des politiques de contrôle d’accès sur les fonctions noyau, les syscalls, etc.
S’économiser l’instrumentation… dans certains cas
Datadog aussi a un usage assez transversal d’eBPF : analyse de performance des applications (Universal Service Monitoring), visibilité sur le trafic réseau (Cloud Network Monitoring), détection des menaces (Workload Protection), supervision d’intégrité des fichiers (application de règles pour limiter les envois)…
« Sans eBPF, on aurait probablement besoin de consentir un effort de modification de la configuration des agents », fait remarquer Pejman Tabassomi, Field CTO EMEA, concernant le monitoring réseau. Sur la partie APM (surveillance des performances des applications), l’approche traditionnelle d’instrumentation « permet d’aller loin dans les détails, mais c’est contraignant parce qu’on est dépendant d’un framework ou d’un runtime», explique l’intéressé. eBPF « permet d’arriver à un objectif par tout à fait identique mais comparable, sans avoir à recourir à une librairie », déclare-t-il.
Pas tout à fait identique, donc. « Il y a une sorte de compromis entre le niveau d’introspection et la facilité de mise en œuvre », résume Pejman Tabassomi. Il l’illustre par un cas d’observation des temps de réponse entre deux services. Pour mesurer le nombre et la durée des appels, eBPF peut suffire. En revanche, s’il y a besoin de comprendre les lignes de code qui peuvent poser problème, les appels de fonctions et de méthodes qui sont en cause, « à ce moment-là, on va plutôt faire de l’APM. » Non sans surveiller des initiatives communautaires tel le profiler de code en cours de développement dans l’univers OpenTelemetry.
Chez Splunk, « l’histoire avec eBPF a démarré lors du rachat de Flowmill » en 2020, fait savoir Stéphane Estevez, EMEA Market Advisor pour l’observabilité. Cet outil de monitoring réseau a alimenté la stratégie « full OpenTelemetry » de l’éditeur. « Être chez Cisco nous a donné l’accès à Isovalent pour l’observabilité et la sécurité », précise Stéphane Estevez. Tetragon, par exemple, alimente des dashboards TCP et DNS dans la composante Network Explorer.
Chez IBM, Instana est le principal terrain d’implémentation d’eBPF. La technologie présente une utilité particulière pour la détection des crashs système, selon Éric Cattoir, membre d’une équipe au niveau EMEA qui couvre les sujets regroupés sous la bannière IT Automation. En écho à Pejman Tabassomi, il déclare, sur le volet instrumentation : « Ça rend la vie plus facile pour notre produit : on a moins à suivre l’évolution des technologies (nouvelles versions de langages, de compilateurs…) ». Instana a toujours eu une approche d’auto-instrumentation, rappelle-t-il, « mais c’est difficile à mettre en place pour certains langages : eBPF facilite cela en permettant d’obtenir de manière standard des informations de profilage ».
On trouve aussi de l’eBPF dans le produit SevOne (observabilité réseau), pour la couche overlay de Kubernetes.
Des programmes composables et portables
Avec les années, les programmes eBPF sont devenus composables : ils peuvent appeler des fonctions (forme de gosub)… et d’autres programmes en remplaçant le contexte d’exécution (goto). Un mécanisme CO-RE (« Compile Once, Run Everywhere ») a été instauré à partir d’un format spécifique de métadonnées (BTF, BPF Type Format) pour procurer une portabilité entre les versions du kernel. Et des passerelles se sont créées avec l’espace utilisateur, à travers une des structures de données que gère eBPF : les magasins clé-valeur dits maps. Des outils sont par ailleurs apparus pour exécuter des programmes en userspace (rBPF, uBPF, bpftime). Ils ont accompagné l’émergence de langages de jaut niveau tel bpftrace – inspiré de DTrace, avec LLVM en back-end et BCC pour interagir avec le sous-système eBPF.
Ce programme eBPF basique (codé en C) écrit un message dans le noyau.
Sauf à activer le mode sans privilèges avec accès limité au noyau, les processus qui chargent des programmes eBPF doivent s’exécuter en mode admin ou avoir la capacité CAP_BPF. La mémoire est protégée en lecture seule et les accès sont masqués pour limiter les effets secondaires observables de l’exécution spéculative. Si une entité tente de modifier le programme, le noyau plante.
Le code passe dans tous les cas par un vérificateur statique. Lequel contrôle, en particulier, que le programme est d’une complexité finie, qu’il se terminera bien et qu’il n’entraînera pas de deadlock ni d’accès mémoire hors limites. Dans la pratique, l’outil reste sujet aux faux positifs. Jusqu’à Linux 5.3, les boucles étaient d’ailleurs proscrites dans les programmes eBPF, le vérificateur étant jugé capable de les évaluer efficacement.
Une fondation où convergent les Big Tech
Depuis 2021, il existe une Fondation eBPF. Google, Meta et Isovalent en sont membres platine. CrowdStrike – qui exploite la techno pour détecter les mouvements de données non autorisés – l’est aussi. Ainsi que Huawei, Intel, Microsoft – qui développe eBPF pour Windows tout en l’exploitant en remplacement du fournisseur d’événements AuditD dans Defender pour Linux – et Red Hat. Datadog est membre argent. Netflix, qui avait pris très tôt le train eBPF, l’est aussi.
Architecture cible d’eBPF pour Windows
Conjointement aux initiatives du marché, cette fondation soutient des projets académiques, à l’instar d’eBPF Governor, alternative aux sous-systèmes de gestion de l’alimentation sur Linux. Des recherches sont également en cours sur la vérification formelle des programmes, en complément à la réécriture du vérificateur en Rust.
Plusieurs projets devenus référents dans l’écosystème eBPF sont maintenant sous l’aile de la CNCF (Cloud Native Computing Foundation). Outre Cilium, on peut citer Falco (détection de menaces), confié en 2018 par Sysdig. Dans le champ de l’observabilité, il y a Pixie, que New Relic a reversé à la CNCF en 2021, quelques mois après en avoir fait l’acquisition (il en propose aujourd’hui une version SaaS).
Pièce maîtresse du réseau mondial de Cloudflare, eBPF a aussi investi les clouds hyperscale. À l’instar de Google sur GKE, AWS s’en sert sur son Kubernetes managé (Caretta pour la cartographie réseau, Hubble pour l’analyse du trafic). Il l’a aussi intégré dans CloudWatch (composante Network Flow Monitor) et de GuardDuty (EC2 Runtime Monitoring). Microsoft l’exploite pour contourner Iptables sur les data planes de offre AKS (Azure Kubernetes Services).
Pour le monitoring, Dynatrace a choisi de s’appuyer sur Inspektor Gadget, framework CNCF qui encapsule les programmes eBPF sous forme d’images OCI. Il le met à contribution dans un module de découverte de services.
Chez Elastic, eBPF alimente le profilage continu, ainsi que la protection de Linux et de Kubernetes dans le cadre de l’offre SIEM/XDR.
La 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.
« 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.
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.
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.
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.
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 :
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é.
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.
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 Cie. 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.
Agent 365 transforme les agents IA en “ressources gérées” : registre centralisé, permission fine, supervision en temps réel et intégration sécurisée dans l’écosystème Microsoft.
Intelligence artificielle, automatisation et intégration multiplateforme : les solutions de travail collaboratif changent de dimension. Pour les managers IT, ces évolutions représentent à la fois une opportunité de productivité et un défi d’intégration.
Consciente des enjeux de sécurité et de gouvernance, OpenAI adopte une approche progressive pour l’ouverture de son navigateur ChatGPT Atlas aux entreprises.
Le Desktop as a Service (DaaS) est désormais compétitif par rapport aux PC traditionnels. Gartner estime que les offres cloud, combinées à des clients légers, peuvent alléger fortement les dépenses des petites et moyennes entreprises — sans sacrifier la sécurité ni la flexibilité.
Microsoft a pris des nouveaux engagements sur la distribution et la commercialisation de Teams au sein de l'Union Européenne. En voici les grands axes.
Connexion
