eBPF basics : observabilité kernel-level — tutoriel 2026

Introduction

Imaginez que vous puissiez brancher un oscilloscope directement sur le système nerveux de votre serveur — observer chaque appel système, chaque paquet réseau, chaque accès mémoire — sans recompiler le kernel, sans charger de module risqué, sans redémarrer la machine. C’est exactement ce que permet eBPF (extended Berkeley Packet Filter), la technologie qui a silencieusement révolutionné l’infrastructure Linux depuis 2014 et qui est aujourd’hui au cœur des outils de production les plus sérieux de la planète.

eBPF fonctionne comme une machine virtuelle JIT (Just-In-Time) intégrée au kernel Linux. Vous écrivez un petit programme en C restreint (ou en langage de haut niveau via bpftrace), vous le soumettez au vérificateur statique du kernel — un outil formel qui garantit que votre code ne peut ni boucler indéfiniment, ni accéder à une zone mémoire invalide, ni faire planter le système — et si la vérification passe, le programme est compilé en bytecode natif et accroché à un point d’observation précis : entrée/sortie d’un syscall, événement réseau, probe noyau, probe utilisateur, etc. Le tout s’exécute dans un sandbox intégré au kernel avec des performances proches du code natif.

Ce qui rend eBPF particulièrement intéressant pour les équipes qui gèrent des serveurs en production en 2026, c’est sa triple utilité. En observabilité, il permet de tracer finement les appels système, les latences I/O, les connexions TCP sans instrumenter le code applicatif. En réseau, il alimente des solutions comme Cilium qui remplacent kube-proxy dans Kubernetes avec des performances sans commune mesure. En sécurité, des outils comme Tetragon interceptent les comportements suspects au niveau kernel, là où aucun rootkit ne peut se cacher.

Dans ce tutoriel, vous allez installer bcc et bpftrace sur un VPS Ubuntu, écrire vos premiers scripts d’observation, tracer des connexions TCP en production, puis découvrir Cilium, Tetragon et Pixie — les trois outils eBPF les plus utilisés dans les clusters Kubernetes modernes.

Prérequis

Avant de commencer, vérifiez que votre environnement répond aux exigences minimales. eBPF dans sa forme moderne — notamment avec BTF (BPF Type Format) et CO-RE (Compile Once, Run Everywhere) qui permettent la portabilité des programmes entre kernels — nécessite un Linux kernel version 5.8 minimum. Sur Ubuntu 22.04 LTS (Jammy), le kernel fourni est 5.15 ou supérieur, ce qui couvre toutes les fonctionnalités abordées ici. Sur Ubuntu 24.04 (Noble), vous êtes en kernel 6.8, encore mieux.

• OS : Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS (serveur ou desktop)
• Kernel : Linux ≥ 5.8 — vérifier avec uname -r
• Accès : root ou sudo (les programmes eBPF nécessitent CAP_BPF ou root)
• RAM : 2 GB minimum, 4 GB recommandé (Hetzner CX22 convient parfaitement)
• Outils : git, curl, apt — pré-installés sur Ubuntu standard
• Niveau : intermédiaire — vous savez ce qu’est un syscall et une interface réseau
• Temps estimé : environ 30 minutes pour les étapes 1 à 4, 1 heure pour aller jusqu’à Tetragon

Une note importante : si vous utilisez un VPS avec un kernel personnalisé chez certains hébergeurs (OVH VPS anciennes gammes, certains VPS Kimsufi), vérifiez que le kernel expose bien le filesystem /sys/kernel/btf/vmlinux. Sans BTF, bpftrace fonctionne en mode dégradé et certains scripts ne marcheront pas. Sur Hetzner, les noyaux stock Ubuntu sont livrés avec BTF activé.

Étape 1 — eBPF use cases : observabilité, réseau, sécurité

Avant de plonger dans l’installation, il est utile de comprendre les trois grands domaines d’application d’eBPF, car cela vous aidera à choisir le bon outil selon votre besoin concret. Les trois use cases ne se chevauchent pas — ils sont complémentaires et la plupart des équipes SRE les utilisent en parallèle.

Observabilité kernel-level est le cas d’usage historique. Plutôt que d’ajouter des `print` dans votre code ou d’instrumenter votre application avec un agent APM lourd (Datadog, New Relic consomment facilement 200 à 400 MB de RAM), eBPF vous permet de tracer depuis l’extérieur : quels syscalls sont appelés, combien de fois, avec quelle latence, depuis quel processus. L’application ne sait pas qu’elle est observée. Le surcoût CPU est typiquement inférieur à 1 % pour la majorité des use cases de traçage. C’est la promesse de zero-instrumentation observability qui a rendu eBPF célèbre.

Networking eBPF est le cas d’usage qui a explosé avec Kubernetes. Le CNI (Container Network Interface) Cilium utilise eBPF pour programmer le kernel directement — pas de iptables, pas de kube-proxy, pas de couche de virtualisation réseau additionnelle. Les paquets sont traités dans le kernel XDP (eXpress Data Path) au niveau de la carte réseau, avant même que la pile réseau classique ne les voie. Les benchmarks publiés par Isovalent (créateur de Cilium) montrent des améliorations de latence de 20 à 40 % par rapport à kube-proxy sur des clusters de taille moyenne.

Security observability est le cas d’usage le plus récent et le plus stratégique. Tetragon, également développé par l’équipe Cilium, attache des programmes eBPF aux fonctions critiques du kernel pour détecter les comportements anormaux en temps réel : exécution d’un binaire depuis /tmp, modification de /etc/passwd, tentative d’accès à un fichier de credentials depuis un conteneur. Contrairement aux solutions basées sur audit.d ou syscall hooks classiques, Tetragon peut agir — pas seulement alerter — en terminant le processus malveillant avant qu’il ne cause des dégâts.

Étape 2 — Installation de bcc et bpftrace

bcc (BPF Compiler Collection) et bpftrace sont les deux piliers de l’écosystème eBPF côté outils de traçage. bcc est une collection d’outils prêts à l’emploi écrits en Python qui utilisent LLVM pour compiler du C en bytecode eBPF à la volée. bpftrace est un langage de haut niveau inspiré d’AWK et de DTrace, conçu spécifiquement pour écrire des scripts de traçage en quelques lignes. Sur Ubuntu 22.04 et 24.04, l’installation via apt est la voie la plus simple et la plus maintenue.

# Mettre à jour la liste des paquets
sudo apt update

# Installer bpftrace (inclut le runtime et les dépendances LLVM)
sudo apt install -y bpftrace

# Installer bcc-tools (collection d'outils comme tcplife, execsnoop, biolatency)
sudo apt install -y bpfcc-tools linux-headers-$(uname -r)

# Vérifier que bpftrace est opérationnel
sudo bpftrace --version

# Vérifier que BTF est disponible (crucial pour bpftrace sans debuginfo)
ls /sys/kernel/btf/vmlinux && echo "BTF OK" || echo "BTF absent - mode dégradé"

Après l’installation, bpftrace --version devrait afficher quelque chose comme bpftrace v0.21.x (la version disponible dans Ubuntu 22.04 LTS est 0.14, dans Ubuntu 24.04 c’est 0.21). La présence de /sys/kernel/btf/vmlinux confirme que votre kernel expose les informations de type BTF — sans ce fichier, bpftrace ne peut pas accéder aux structures de données internes du kernel de façon portable. Si ce fichier est absent, vous pouvez toujours utiliser les outils bcc-tools qui n’en dépendent pas systématiquement.

Les outils bcc-tools sont installés dans /usr/sbin/ sous Ubuntu avec le suffixe -bpfcc. Ainsi tcplife devient tcplife-bpfcc, execsnoop devient execsnoop-bpfcc, etc. C’est un point source de confusion fréquente — nous y reviendrons dans la section erreurs fréquentes.

Étape 3 — Premier script bpftrace : compter les syscalls

Le meilleur premier programme eBPF est aussi le plus simple : compter combien de fois chaque syscall est appelé sur votre système en temps réel. C’est l’équivalent eBPF du classique strace -c, mais au lieu de tracer un seul processus en l’attachant, on observe l’ensemble du système sans perturber quoi que ce soit. Ce script illustre parfaitement la puissance d’eBPF : en trois lignes, on obtient une vue qui demandait auparavant des outils de profiling complexes.

# Lancer le comptage des syscalls pendant 10 secondes
# tracepoint:syscalls:sys_enter_* attrape l'entrée de tous les syscalls
sudo bpftrace -e '
  tracepoint:syscalls:sys_enter_* {
    @[probe] = count();
  }
  interval:s:10 {
    print(@);
    clear(@);
    exit();
  }
'

Ce script attache une sonde sur le tracepoint d’entrée de chaque syscall (sys_enter_* est un wildcard qui matche tous les syscalls disponibles). À chaque déclenchement, il incrémente un compteur indexé par le nom de la sonde dans une map eBPF nommée @. Après 10 secondes, la clause interval imprime la map triée par fréquence et quitte. Vous verrez typiquement sys_enter_epoll_wait, sys_enter_futex, sys_enter_read en tête sur un serveur web actif. Si sys_enter_open ou sys_enter_stat apparaissent en masse, cela peut indiquer un processus qui scanne le filesystem — information précieuse pour le diagnostic de performance.

Pour aller un peu plus loin, voici un script qui filtre par processus et mesure la latence des syscalls write :

# Mesurer la latence du syscall write par processus
sudo bpftrace -e '
  tracepoint:syscalls:sys_enter_write {
    @start[tid] = nsecs;
  }
  tracepoint:syscalls:sys_exit_write / @start[tid] / {
    @latency_ns[comm] = hist(nsecs - @start[tid]);
    delete(@start[tid]);
  }
' --duration 5

Ce second script utilise hist() pour construire un histogramme de latence en nanosecondes, groupé par nom de processus (comm). Le résultat, affiché en format ASCII art à la fin des 5 secondes, vous montre immédiatement si certains processus ont des écritures anormalement lentes — signe de saturation I/O ou de contention disque. C’est le genre d’information qu’on ne peut pas obtenir avec top ou iostat.

Étape 4 — Tracer les connexions TCP avec tcplife

tcplife est l’un des outils les plus utiles du kit bcc. Il accroche des probes eBPF sur les fonctions kernel qui gèrent le cycle de vie des connexions TCP (tcp_set_state, tcp_close) et, à chaque fermeture de connexion, affiche un résumé : adresses source/destination, ports, durée de vie de la connexion, octets envoyés et reçus. C’est exactement ce dont vous avez besoin pour comprendre qui parle à qui sur votre serveur, identifier les connexions qui durent anormalement longtemps, ou détecter des fuites de connexions dans une application Node.js ou Python.

# Lancer tcplife avec le suffixe Ubuntu
sudo tcplife-bpfcc

# Filtrer uniquement les connexions sur le port 443 (HTTPS)
sudo tcplife-bpfcc -p 443

# Afficher uniquement les connexions d'un PID spécifique
sudo tcplife-bpfcc --pid $(pgrep nginx | head -1)

# Format large avec timestamps absolus
sudo tcplife-bpfcc -w

La sortie ressemble à ceci (reconstituée) :

PID   COMM       LADDR            LPORT RADDR            RPORT TX_KB RX_KB MS
1234  nginx      10.0.0.1         443   41.82.45.12      52341  12    3     245
1234  nginx      10.0.0.1         443   197.255.88.4     61023  0     0     12
5678  node       10.0.0.1         3000  127.0.0.1        34512  450   12    8900

Cette vue vous dit, ligne par ligne, qu’une connexion HTTPS d’un client ivoirien (41.82.x.x) a duré 245 ms et transféré 12 KB, qu’une autre depuis une IP sénégalaise a été fermée immédiatement (12 ms, 0 KB — probablement un scan ou un keepalive), et que votre application Node.js a une connexion interne qui dure depuis 8,9 secondes et a transféré 450 KB — ce qui mérite investigation. Toutes ces informations sont disponibles sans modifier une seule ligne de votre application.

Pour aller plus loin avec bcc-tools, les outils execsnoop-bpfcc (trace tous les exec), opensnoop-bpfcc (trace tous les open de fichiers) et biolatency-bpfcc (histogramme de latence des I/O disque) forment un trio essentiel pour le diagnostic de performance en production.

Étape 5 — Cilium : eBPF networking pour Kubernetes

Cilium est le CNI (Container Network Interface) Kubernetes le plus avancé de 2026, et son avantage concurrentiel repose entièrement sur eBPF. Là où les CNI traditionnels (flannel, calico en mode iptables) utilisent des milliers de règles iptables pour router le trafic entre pods — règles qui s’accumulent et ralentissent le kernel proportionnellement au nombre de services — Cilium programme directement le kernel via eBPF pour prendre les décisions de routage dans un chemin de données ultra-optimisé. Le résultat : des performances réseau qui restent stables même à grande échelle, et une visibilité réseau inégalée via Hubble, l’interface d’observabilité de Cilium.

# Installation de Cilium sur un cluster k3s existant
# Prérequis : kubectl configuré, helm installé

# Ajouter le repo Helm Cilium
helm repo add cilium https://helm.cilium.io/
helm repo update

# Installer Cilium en remplaçant kube-proxy
helm install cilium cilium/cilium --version 1.16.0 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=$(kubectl get nodes -o jsonpath='{.items[0].status.addresses[0].address}') \
  --set k8sServicePort=6443

# Vérifier que les pods Cilium sont Running
kubectl -n kube-system get pods -l k8s-app=cilium

# Installer le CLI cilium pour vérifier le statut
cilium status --wait

Une fois installé, Cilium remplace intégralement kube-proxy et prend en charge le routage, le load balancing des Services, les NetworkPolicies, et l’observabilité réseau. La commande cilium status doit afficher KubeProxyReplacement: True. Pour activer Hubble, l’interface d’observabilité réseau de Cilium qui vous donne une vue en temps réel des flux entre vos microservices, ajoutez --set hubble.enabled=true --set hubble.ui.enabled=true à la commande Helm. Vous obtenez alors un graphe de dépendances de vos services mis à jour en temps réel, directement depuis les données eBPF, sans aucun sidecar à injecter.

Étape 6 — Tetragon : security observability au niveau kernel

Tetragon est le composant de sécurité de l’écosystème Cilium. Là où Hubble observe les flux réseau, Tetragon observe les événements kernel : exécutions de processus, accès aux fichiers, appels réseau, chargement de modules. La particularité de Tetragon par rapport aux solutions HIDS traditionnelles comme Falco (qui utilise aussi des mécanismes kernel mais différents) est sa capacité à appliquer des politiques en temps réel — pas seulement détecter et alerter, mais bloquer activement un comportement malveillant avant qu’il ne se produise.

# Installer Tetragon dans un cluster Kubernetes avec Cilium
helm repo add cilium https://helm.cilium.io/
helm install tetragon cilium/tetragon \
  --namespace kube-system

# Vérifier que Tetragon tourne sur chaque nœud
kubectl -n kube-system get pods -l app.kubernetes.io/name=tetragon

# Installer le CLI tetra pour lire les événements
KUBEARCH=amd64; curl -L --remote-name-all \
  https://github.com/cilium/tetragon/releases/latest/download/tetra-linux-${KUBEARCH}.tar.gz
tar -xvf tetra-linux-${KUBEARCH}.tar.gz
sudo mv tetra /usr/local/bin/

# Observer tous les événements de sécurité en temps réel
kubectl exec -n kube-system ds/tetragon -c tetragon -- \
  tetra getevents -o compact

Les événements Tetragon sortent en JSON structuré avec des champs process_exec, process_kprobe, process_exit. Chaque événement contient la chaîne de parenté complète du processus (pod → conteneur → PID → processus parent), ce qui permet d’identifier immédiatement si un shell a été lancé depuis un conteneur applicatif — comportement anormal qui indique souvent une compromission. Pour définir une TracingPolicy (politique Tetragon qui déclenche une alerte ou un kill sur un comportement précis), vous créez une ressource Kubernetes de type TracingPolicy avec les kprobes ciblées. La documentation officielle sur github.com/cilium/tetragon/tree/main/examples/tracingpolicy contient des exemples prêts à l’emploi pour les scénarios les plus courants.

Étape 7 — Pixie : auto-instrumentation sans code

Pixie est un projet CNCF (sandbox) développé par New Relic puis open-sourcé, qui pousse le concept d’observabilité eBPF à son extrême : sans modifier votre code, sans déployer de sidecar, sans configurer quoi que ce soit dans votre application, Pixie collecte automatiquement les traces HTTP/gRPC, les requêtes SQL, les métriques JVM, les profils CPU — tout cela en utilisant des programmes eBPF qui s’accrochent aux fonctions des runtimes (Node.js, Python, Go, Java) et des bibliothèques réseau. En 2026, Pixie supporte le profiling continu en production sans impact significatif sur les performances.

# Installer le CLI Pixie
bash -c "$(curl -fsSL https://withpixie.ai/install.sh)"

# Authentifier (nécessite un compte px.dev gratuit)
px auth login

# Déployer Pixie dans le cluster Kubernetes courant
px deploy

# Vérifier le déploiement
px demo deploy px-sock-shop  # application de démo fournie par Pixie

# Lancer un script PxL pour voir les requêtes HTTP en temps réel
px run px/http_data

Pixie expose ses données via PxL (Pixie Language), un langage de requête similaire à Python qui s’exécute directement dans le cluster. Le script px/http_data affiche en temps réel toutes les requêtes HTTP avec leur latence, status code, taille de réponse et service source/destination — le tout sans avoir touché une seule ligne de code de vos applications. Pour les équipes qui n’ont pas accès au code source ou qui gèrent des microservices écrits dans plusieurs langages, c’est une capacité d’observabilité qui change radicalement le diagnostic en production.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les équipes techniques en Afrique de l’Ouest — que vous gériez l’infrastructure d’une fintech à Dakar, d’une plateforme e-learning à Abidjan, ou d’un ERP à Lomé — eBPF représente un levier d’optimisation particulièrement pertinent compte tenu des contraintes locales spécifiques.

La contrainte la plus immédiate est le budget infrastructure. Un Hetzner CX22 (4 GB RAM, 2 vCPU AMD, 40 GB NVMe) coûte environ 4,85 €/mois soit moins de 3 200 FCFA. C’est le serveur de référence pour beaucoup de startups de la région. Sur cette machine, déployer un agent APM traditionnel comme Datadog Agent ou New Relic Infrastructure consomme entre 150 et 400 MB de RAM en permanence, soit 10 à 20 % de la RAM disponible — rien que pour l’observabilité. bpftrace et bcc-tools, eux, ne consomment de la RAM que pendant l’exécution active d’un script, et leur impact est proche de zéro au repos. Sur un VPS à 4 GB, cette différence n’est pas anecdotique : elle peut faire la différence entre une application stable et des OOMKills intempestifs sous charge.

Le debug de performance en production est une autre situation où eBPF brille particulièrement. Dans des environnements où la connectivité est parfois instable et les fenêtres de maintenance courtes, pouvoir diagnostiquer un problème de latence TCP en 2 minutes avec tcplife-bpfcc sans toucher au code et sans redémarrer l’application est un avantage opérationnel considérable. Un développeur qui sait utiliser bpftrace peut identifier une fuite de connexions base de données, une saturation de file d’attente, ou un processus zombie qui consomme des ressources — le tout depuis sa session SSH, sans déployer quoi que ce soit.

Sur le plan de la conformité OHADA et traçabilité, les entreprises soumises à l’Acte Uniforme OHADA sur le droit des sociétés commerciales ont des obligations croissantes de traçabilité des accès aux données sensibles — état des comptes, données clients, fichiers de paie. Tetragon permet d’implémenter cette traçabilité au niveau le plus bas possible (kernel), ce qui rend l’audit trail pratiquement inviolable depuis l’espace utilisateur. Un programme malveillant ou un employé malintentionné ne peut pas effacer les traces kernel sans droits root sur le système eBPF lui-même. C’est un argument solide pour les audits DSI et pour les discussions avec les commissaires aux comptes qui s’intéressent de plus en plus à la traçabilité des SI.

Enfin, pour les équipes qui utilisent k3s plutôt que k8s full (la distribution Kubernetes légère adaptée aux ressources limitées, très utilisée dans la région), Cilium et Tetragon fonctionnent parfaitement avec k3s. L’installation Cilium décrite à l’étape 5 a été validée sur k3s. La commande k3s server --disable-kube-proxy --flannel-backend=none désactive les composants réseau par défaut de k3s pour laisser la place à Cilium.

Tutoriels frères

• Bun + Hono : API REST ultra-performante sans Node.js — tutoriel 2026 — construire le backend léger que vous observerez avec eBPF
• VictoriaMetrics : monitoring selfhost haute performance — tutoriel 2026 — stocker les métriques que bpftrace collecte
• Authelia : SSO et 2FA pour vos services selfhost — protéger l’accès à Hubble et Pixie UI

Pour aller plus loin

• Retour au pilier : Web 2026 sans framework lourd : HTMX, Hotwire, Alpine.js
• ebpf.io — site officiel de la fondation eBPF (Linux Foundation), avec la documentation de référence, les projets du landscape et les cas d’usage documentés
• brendangregg.com/ebpf.html — Brendan Gregg est l’ingénieur de Netflix qui a popularisé eBPF pour le profiling de performance ; ses outils, articles et flamegraphs sont devenus des références mondiales
• github.com/cilium/tetragon — code source et exemples de TracingPolicy pour Tetragon
• px.dev/docs — documentation complète de Pixie avec les scripts PxL de référence
• Prochain tutoriel recommandé : VictoriaMetrics pour stocker et interroger les métriques collectées par vos scripts eBPF

FAQ

Q : eBPF fonctionne-t-il sur tous les VPS, ou faut-il un serveur dédié ?

R : eBPF fonctionne sur les VPS à condition que le kernel exposé soit ≥ 5.8 et que l’hyperviseur n’ait pas désactivé les syscalls BPF. La majorité des VPS Hetzner, OVH (gammes récentes), DigitalOcean et Linode fonctionnent correctement. Certains VPS OpenVZ (technologie de virtualisation ancienne) ne supportent pas eBPF car le kernel est partagé. Vérifiez avec uname -r et ls /sys/kernel/btf/vmlinux.

Q : eBPF peut-il ralentir ma production ?

R : Le surcoût eBPF est typiquement inférieur à 1-3 % CPU pour des scripts de traçage simples. Les outils bpftrace et bcc sont conçus pour être sûrs et bornés — le vérificateur kernel refuse les programmes qui pourraient boucler infiniment. Pour les charges très élevées (> 100 000 req/s), il est recommandé de tester d’abord sur staging, mais sur des serveurs standards de PME, l’impact est imperceptible.

Q : Quelle est la différence entre eBPF et strace ?

R : strace utilise le mécanisme ptrace du kernel qui stop-and-inspect chaque syscall du processus tracé, causant un surcoût de 50 à 100x sur le processus. eBPF s’exécute directement dans le kernel avec un surcoût de 1 à 5 % au maximum. strace est utile pour déboguer un processus en développement, eBPF est conçu pour la production. De plus, strace ne peut observer qu’un seul processus à la fois, eBPF peut observer tout le système simultanément.

Q : Puis-je utiliser eBPF pour détecter des intrusions sur un VPS sans Kubernetes ?

R : Absolument. Tetragon peut s’installer en mode standalone (sans Kubernetes) avec un simple binaire. Pour un VPS classique, Falco (qui utilise aussi des mécanismes kernel comparables) est une alternative bien documentée. bpftrace lui-même peut servir de base pour des scripts de détection sur mesure — par exemple, alerter quand un processus tente d’ouvrir /etc/shadow ou d’écrire dans /tmp suivi d’un exec.

Q : eBPF est-il compatible avec les conteneurs Docker (sans Kubernetes) ?

R : Oui. bpftrace et bcc-tools s’exécutent sur le nœud hôte et voient tous les processus, y compris ceux dans les conteneurs Docker. Vous pouvez filtrer par namespace, PID ou nom de conteneur. Cilium en revanche est exclusivement conçu pour Kubernetes. Pour Docker seul, les outils bcc-tools couvrent 90 % des besoins d’observabilité réseau et système.

Q : Comment apprendre à écrire des programmes eBPF custom en C ?

R : La voie recommandée en 2026 est d’utiliser libbpf avec CO-RE plutôt que le BCC Python+C d’avant. Le livre Learning eBPF de Liz Rice (O’Reilly, 2023, disponible gratuitement sur ebpf.io) est la meilleure introduction. Pour la pratique, le dépôt libbpf-bootstrap sur GitHub fournit des templates prêts à compiler. La courbe d’apprentissage est modérée si vous connaissez déjà le C et les bases du kernel Linux.

Q : eBPF est-il disponible sur macOS ou Windows ?

R : eBPF est natif Linux uniquement. Microsoft a développé eBPF for Windows (projet open source) mais il est encore en phase expérimentale en 2026. Sur macOS, des outils comme dtrace offrent une philosophie similaire mais l’écosystème est beaucoup moins riche. Pour les développeurs qui travaillent sur Mac et déploient sur Linux, l’approche recommandée est de tester les scripts eBPF directement sur le VPS Linux via SSH.