Si vous vous êtes intéressé aux outils d'attribution des coûts de l'IA ou d'observabilité cloud, vous avez sans doute croisé le terme eBPF. On le retrouve dans les plateformes de sécurité, les outils réseau, les moniteurs de performance et, de plus en plus, dans l'attribution des coûts de l'IA. Mais que signifie-t-il concrètement, et en quoi est-il utile pour mesurer les dépenses liées à l'IA ?
eBPF, en clair
eBPF est l'acronyme d'extended Berkeley Packet Filter. Ce nom est un héritage de ses origines (il servait initialement à filtrer les paquets réseau), mais la technologie a évolué bien au-delà : elle permet aujourd'hui d'exécuter de petits programmes sandboxés directement dans le noyau Linux, sans modifier son code source ni installer de module noyau.
Concrètement, eBPF permet à un logiciel d'observer ce qui se passe sur une machine au niveau le plus bas : chaque appel système, chaque paquet réseau, chaque processus, chaque interaction GPU, en temps réel. Et ce, en toute sécurité. Les programmes eBPF s'exécutent dans un environnement vérifié et sandboxé : ils ne peuvent ni faire planter le noyau ni introduire de failles de sécurité. Pour une explication technique détaillée du chargeur et de l'architecture de vérification, l'introduction eBPF.io reste la référence publique la plus complète.
Un capteur eBPF est le logiciel qui tire parti de cette capacité. C'est un programme léger qui s'attache aux événements du noyau et diffuse en continu les données qu'il observe, généralement vers une couche de collecte ou d'analyse hébergée ailleurs. Imaginez un capteur intégré au système d'exploitation lui-même, capable d'observer une activité qu'aucun outil applicatif ne peut voir.
Capteurs eBPF, modules noyau et agents
Avant eBPF, atteindre ce niveau de visibilité impliquait généralement l'une de ces deux approches : écrire un module noyau sur mesure, ou déployer un agent lourd greffé sur la couche applicative.
Les modules noyau voient tout ce qu'un capteur eBPF peut voir, mais ils comportent de vrais risques. Un bug dans un module noyau peut faire planter la machine entière, car le module s'exécute avec un accès total et non contrôlé à la mémoire du noyau. Ces modules doivent aussi être recompilés et testés pour chaque version du noyau, ce qui représente une charge de maintenance récurrente que peu d'équipes souhaitent assumer.
Les agents applicatifs évitent ce risque, mais au prix de zones aveugles. Un agent installé dans une application ne voit que ce que cette application accepte d'exposer. Il ne peut ni observer le trafic transitant par un driver GPU partagé, ni un socket réseau du noyau, ni un processus dont il n'a jamais eu connaissance.
Le capteur eBPF se situe entre les deux, en cumulant les meilleurs atouts. Il s'exécute dans le noyau, et voit donc tout ce qu'un module noyau verrait, mais chaque programme eBPF est validé par le vérificateur du noyau avant de pouvoir s'exécuter : impossible pour lui de faire planter le système ou de lire une mémoire non autorisée. Cette combinaison — visibilité totale et risque maîtrisé — explique pourquoi eBPF est devenu le choix par défaut pour l'observabilité, la sécurité et, désormais, l'attribution des coûts.
Pourquoi l'observation au niveau du noyau change la donne
La plupart des outils de monitoring et d'attribution fonctionnent au niveau applicatif. Ils dépendent d'une instrumentation : un tag sur une ressource, un SDK enveloppant un appel d'API, une ligne de log qu'un ingénieur a pensé à ajouter. Cela fonctionne bien tant que ce que l'on mesure est statique et bien défini.
L'infrastructure d'IA n'est ni statique ni bien définie. C'est précisément là que les pratiques FinOps traditionnelles commencent à montrer leurs limites ; voir comment le FinOps s'adapte (ou non) aux workloads d'IA pour en savoir plus sur cette évolution. Un cluster GPU partagé sert plusieurs produits simultanément. Un compte d'API de modèle managé reçoit les requêtes de dizaines d'équipes. Une passerelle LLM agrège le trafic issu d'agents, de pipelines et d'utilisateurs humains dans un unique flux sortant, souvent en supprimant au passage l'identité de l'appelant. Aucune de ces activités ne porte de tag. Aucune ne passe par un SDK que vous contrôlez.
Un capteur eBPF n'a besoin de rien de tout cela. Comme il opère au sein du système d'exploitation, il voit directement la consommation réelle : le processus, le conteneur, le pod, le cycle GPU, le token. Il ne demande rien à l'application. Il observe le système lui-même.
Prenons un scénario courant : une équipe d'ingénierie fait transiter tout le trafic modèle par une seule passerelle LLM pour gérer les limites de débit et le failover entre fournisseurs. Du point de vue de la passerelle, chaque requête se ressemble : une clé d'API, un flux sortant. La facture émise par le fournisseur du modèle reflète ce même aplatissement. Impossible de savoir, à partir de la seule facture, si tel dollar provient d'une fonctionnalité destinée aux clients, d'une automatisation interne ou d'un script de test devenu incontrôlable. Un capteur eBPF résout ce problème en observant le trafic au moment où il quitte réellement la machine, avant que la passerelle ne l'agrège, et en rattachant chaque requête au processus qui l'a émise.
Fonctionnement d'un capteur eBPF, étape par étape
- Attachement. Le capteur s'attache à des événements précis du noyau — appels système, activité réseau ou ordonnancement GPU, selon ce qu'il est conçu pour observer.
- Capture. À mesure que ces événements surviennent, le capteur collecte les points de données pertinents : identifiants de processus, utilisation des ressources, timing, etc.
- Vérification. En amont, le vérificateur eBPF du noyau Linux contrôle le programme pour s'assurer qu'il peut s'exécuter sans risque. C'est ce qui distingue eBPF d'un module noyau traditionnel, bien plus risqué.
- Streaming. Le capteur diffuse en continu ses observations vers une couche de collecte externe au noyau, où elles peuvent être croisées avec d'autres données, comme les relevés de facturation des fournisseurs.
- Mapping. Ces données croisées sont ensuite rattachées au workload responsable : quel agent, quelle fonctionnalité, quel client.
L'ensemble du processus se déroule en continu et en temps réel, sans modification de code, sans édition de manifeste, ni instrumentation d'aucune sorte.
Capteurs eBPF et attribution des coûts de l'IA
C'est ici qu'eBPF prend tout son sens pour la Tokenomics, la discipline qui consiste à comprendre le coût de chaque token et sa valeur. Les workloads d'IA évoluent trop vite et de manière trop imprévisible pour qu'une attribution basée sur l'instrumentation puisse suivre le rythme. Un agent peut engendrer un millier de sous-agents en une nuit. Le temps qu'une équipe d'ingénierie encapsule un nouveau schéma d'appel dans un SDK, la facture est déjà tombée.
Un capteur eBPF contourne complètement ce problème. Puisqu'il mesure depuis l'intérieur du système d'exploitation, en amont de tout proxy, de toute abstraction, de toute frontière de responsabilité, il capture chaque token, chaque requête modèle et chaque cycle GPU en temps réel. Ces données peuvent ensuite être croisées avec les facturations des fournisseurs (Anthropic, OpenAI, Google Gemini, AWS Bedrock), en isolant automatiquement les tokens mis en cache, les tokens de raisonnement, les tokens d'entrée et les tokens de sortie.
Résultat : une attribution qui ne dépend ni des tags, ni des SDK, ni de modifications de code, déployée en quelques minutes plutôt qu'en plusieurs mois. Cette granularité constitue également la base pour mesurer précisément le ROI de l'IA. Sans savoir ce que coûte réellement une fonctionnalité, tout calcul de ROI relève de la supposition.
Questions fréquentes
Un capteur eBPF peut-il fonctionner en production en toute sécurité ? Oui. Chaque programme eBPF passe par le vérificateur intégré au noyau avant d'être autorisé à se charger. Le vérificateur s'assure que le programme se termine toujours, ne lit pas de mémoire hors de ses limites, et ne peut ni faire planter ni déstabiliser le noyau. Le profil de risque est fondamentalement différent de celui d'un module noyau traditionnel, qui bénéficie d'un accès sans restriction et d'aucun contrôle de sécurité intégré.
Un capteur eBPF nécessite-t-il des modifications de code ou de l'instrumentation ? Non. C'est précisément son atout majeur. Un capteur eBPF observe l'activité au niveau du noyau : il n'a donc besoin ni de tag, ni de SDK, ni de modification de code pour voir ce qui se passe. Il fonctionne de la même manière quel que soit le langage ou la façon dont l'application a été écrite.
Combien de temps faut-il pour déployer un capteur eBPF ? Le déploiement se mesure généralement en minutes, pas en semaines. Comme il n'y a ni étape d'instrumentation, ni modification de manifeste, ni besoin de retoucher le code applicatif, un capteur peut être installé et commencer à observer le trafic quasi immédiatement. Avec Attribute™ by DoiT, la plupart des clients obtiennent des données attribuées dans la journée.
Un capteur eBPF peut-il voir à l'intérieur d'un GPU partagé ou d'une passerelle LLM ? Oui, et c'est précisément ce qui le distingue des approches par tag ou SDK. Comme le capteur observe le trafic au niveau du système d'exploitation, avant qu'il ne traverse une passerelle, un proxy ou une ressource partagée, il peut retracer l'activité jusqu'au processus d'origine, même lorsqu'elle est agrégée ou anonymisée en aval.
eBPF sert-il uniquement à des cas d'usage réseau et sécurité ? Non. eBPF est né comme une technologie réseau (l'acronyme signifie extended Berkeley Packet Filter), mais il s'est depuis étendu à l'observabilité, à la sécurité et désormais à l'attribution des coûts. Tout cas d'usage qui bénéficie d'une observation directe de l'activité système, sans dépendre de la remontée d'informations par l'application, est un candidat pour une approche eBPF.
Quelle est la différence entre un capteur eBPF et un programme eBPF ? Un programme eBPF est l'unité de code sous-jacente qui s'exécute au sein du noyau : un petit fragment de logique vérifié, attaché à un point d'accroche précis. Un capteur eBPF est le système plus large construit par-dessus, incluant la logique de collecte et de mapping qui transforme les observations brutes du noyau en données exploitables.
C'est sur cette base qu'est construit Attribute™ by DoiT. Découvrez à quoi ressemble une attribution des coûts de l'IA au niveau du noyau dans votre propre environnement.