Il n’y aura plus de nouvelles fonctionnalités sur Heroku.
Le produit passe en mode maintenance… sans changements sur le cœur fonctionnel ni sur la tarification, nous assure-t-on. En revanche, l’offre Enterprise et le support associé ne sont plus commercialisés. Les contrats existants iront à terme et restent renouvelables.
Sous l’aile de Salesforce (propriétaire d’Heroku depuis 2011), les investissements vont s’orienter vers « des éléments [susceptibles de] délivrer la plus grande valeur sur le long terme, [notamment] aider à construire et à déployer [l’IA] ». Voilà un peu plus d’un an que le PaaS a pris ce virage, avec une nouvelle architecture fondée sur Kubernetes.
Le dernier sondage annuel Stack Overflow donne un indicateur de popularité pour Heroku. Dans la catégorie des plates-formes cloud, lorsqu’on demande aux répondants quelles technologies ils utilisent activement et souhaitent continuer à utiliser, 5,4 % répondent Heroku. Contre 8,2 % en 2024, 12,02 % en 2023, 19,98 % en 2022 et 24 % en 2021.
Ses principaux concurrents (Fly.io, Railway, Render…) n’ont pas dépassé les 2-3 % ces dernières années.
Le cloud n’est pas cher par nature : il devient cher quand personne ne se sent propriétaire de la facture. Mettez les développeurs dans la boucle, avec une visibilité exploitable, et le gaspillage commence à reculer. Une culture FinOps élargie aux développeurs, renforcée par l’IA et l’automatisation, transforme la dépense en décision. Le cloud reste […]
La bataille des modèles se déplace là où tout se décide : vos données et vos workflows. Quand Snowflake et ServiceNow signent en direct avec OpenAI et Anthropic, l’IA n’est plus un gadget propriétaire, c’est une couche d’exécution qui verrouille gouvernance, contexte et automatisation dans le cloud du quotidien en s’appuyant sur les grands modèles […]
L’ancien temps est révolu. Celui où vous deviez configurer indépendamment chaque brique de votre infrastructure, effectuer manuellement le déploiement de vos environnements, et gérer jour après jour le cycle de vie de vos machines. Place à une gestion beaucoup plus agile et automatisée avec Dell Automation Platform (DAP) et Dell Private Cloud (DPC).
Le portail : Zero Touch Onboarding
Mettons-nous en situation pour comprendre concrètement à quoi ressemble le quotidien d’un administrateur dans ce nouveau modèle de gestion IT. Imaginons que vous souhaitiez déployer une infrastructure de cloud privé, mêlant des environnements VMware, pour héberger vos applications existantes, et des clusters OpenShift pour les applications cloud natives.
Vous avez commandé les serveurs Dell PowerEdge et les baies Dell PowerStore dont vous aviez besoin, puisque rappelons-le, l’approche composable vous permet de déployer indépendamment des ressources de calcul ou de stockage pour être au plus proche de vos exigences réelles. Lorsque vos équipements arrivent, vous les connectez à votre réseau… et c’est à peu près tout.
Il vous suffit ensuite d’accéder au portail Dell Automation Platform pour découvrir que vos nouveaux équipements ont été automatiquement onboardés. Le portail est le plan de contrôle qui va donner toute la visibilité sur l’inventaire matériel, l’état de santé des composants et la conformité du parc. Vous n’avez plus qu’à les assigner à l’orchestrateur pour que leurs ressources rejoignent le pool global et puissent être automatiquement allouées à vos futurs workloads. Bienvenue dans le Zero Touch Onboarding.
Le catalogue : des blueprints prêts à l’emploi
Vos ressources sont prêtes à être consommées. Dell Private Cloud lui, est prêt à entrer en jeu. Car c’est ici que l’intégration des deux solutions va apporter toute sa valeur. Dell Private Cloud va proposer un catalogue de « blueprints », c’est-à-dire un ensemble de fichiers YAML/Python basés sur le standard TOSCA (Topology and Orchestration Specification for Cloud Applications) qui décrit la topologie (serveurs, stockage, réseau, hyperviseur, etc.), les dépendances et les paramètres nécessaires.
Des blueprints existent pour déployer un cloud privé, des infrastructures IA ou encore des environnements Edge. Il est également possible de créer ses propres blueprints. Dans notre cas, vous allez pouvoir rattacher vos licences dans DAP, puis sélectionner les blueprints « Dell Private Cloud deploying VMware » et « Dell Private Cloud deploying Red Hat OpenShift », et laisser DAP faire le reste.
L’orchestrateur : des dizaines d’étapes manuelles automatisées en quelques minutes
Une fois le blueprint sélectionné dans l’interface de DPC, c’est l’orchestrateur de DAP qui entre en scène en arrière-plan. L’orchestrateur constitue le plan de gestion et va exécuter le scénario de déploiement complet décrit dans le blueprint. Par exemple : création d’un cluster vSphere sur PowerEdge, configuration du stockage Dell, mapping des LUN, intégration aux outils de management, etc. Il élimine ainsi le risque d’erreur humaine et remplace des dizaines d’étapes manuelles par un workflow unique et automatisé, déroulé en seulement quelques minutes.
Mais son rôle ne s’arrête pas là : il assure également la gestion du « Jour 2 ». Si une mise à jour de firmware est nécessaire ou si vous devez étendre votre cluster, l’orchestrateur pilote l’opération en toute transparence, garantissant que votre infrastructure reste toujours performante et sécurisée.
Plein cap sur l’après HCI
Dell Automation Platform et Dell Private Cloud sont donc les deux piliers de la nouvelle infrastructure composable qui vient bousculer l’hyperconvergence. Ensemble, les deux logiciels vont permettre aux entreprises de considérablement simplifier et accélérer la modernisation de leur IT, en automatisant les opérations de déploiement, de configuration et de gestion.
Mais ils vont en plus garantir la pérennité des investissements. Grâce à l’agnosticité vis‑à‑vis des systèmes d’exploitation et hyperviseurs tiers, qui évite tout verrouillage technologique, la même infrastructure Dell PowerEdge peut être réutilisée et accueillir de nouvelles images au fil du temps. C’est une nouvelle ère qui commence en 2026.
Il y a dix ans, l’hyperconvergence (ou HCI, pour HyperConverged Infrastructure) bousculait les codes du datacenter. En fusionnant le calcul et le stockage au sein d’une même plateforme, des solutions comme Dell VxRail ont tenu une promesse forte : briser les silos historiques de l’architecture 3-tiers traditionnelle.
Cette architecture a séduit par sa simplicité d’administration et son déploiement rapide. Pour beaucoup d’entreprises, l’hyperconvergence était la réponse idéale à la complexité de gestion des environnements virtualisés. Mais en 2026, l’intégration monolithique qui faisait la force du HCI commence à montrer des limites face aux nouveaux enjeux des entreprises
Objectifs 2026 : réduire la dépendance et les coûts
Le paysage IT a changé ces dernières années et pousse les DSI à réévaluer la pertinence du modèle HCI. Ces derniers souhaitent en premier lieu se libérer du « vendor lock-in », autrement dit, de la dépendance à un fournisseur, qui peut être importante dans un environnement hyperconvergé qui impose un hyperviseur spécifique. Les évolutions récentes des modèles de souscription logicielle ont mis en exergue cette problématique : l’augmentation des coûts de licence « au cœur » ou « au processeur » amène les entreprises à optimiser le nombre de serveurs physiques pour réduire leur facture logicielle.
L’autre enjeu majeur est le besoin croissant d’agilité. L’évolutivité de l’hyperconvergence est basée sur un modèle scale-out, qui consiste à ajouter des nœuds additionnels lorsque les besoins augmentent. Ce qui revient donc à augmenter simultanément les capacités de calcul et de stockage. À l’ère de l’IA et des Data Lakes, les besoins en stockage croissent souvent beaucoup plus vite que les besoins en puissance de calcul. Le résultat peut être un surprovisionnement coûteux pour l’entreprise. L’arrivée massive des containers et des charges de travail gourmandes en GPU renforce également la nécessité d’une infrastructure plus modulaire que ce que permettent les clusters HCI actuels.
L’évolutivité du 3-tiers et la simplicité du HCI (sans les coûts)
Le 3 tiers d’hier est-il donc redevenu la bonne solution d’aujourd’hui ? Pas tout à fait. Car en cassant les silos IT, l’hyperconvergence a apporté une simplicité de gestion des différentes briques qu’il est crucial de conserver. C’est ici que l’infrastructure composable entre en jeu, en proposant une architecture de cloud privé, qui sépare physiquement les ressources, comme dans le modèle 3-tiers, mais conserve une couche logicielle d’orchestration et d’automatisation, comme avec l’hyperconvergence.
Cette couche logicielle, incarnée par Dell Automation Platform (DAP), va donc offrir la même simplicité de gestion « en un clic » que le HCI, mais sur des composants que l’on peut faire évoluer indépendamment. L’ensemble des ressources sont ensuite réunies dans un pool logique unique qui permet à l’administrateur de composer à la demande l’infrastructure dont il a besoin. Et pour simplifier le déploiement, il peut sélectionner dans un catalogue des « blueprints », c’est-à-dire des environnements déjà testés et préconfigurés, pour l’IA par exemple, mais aussi créer ses propres blueprints, afin d’automatiser le déploiement d’environnements pensés spécifiquement pour ses besoins
VMware et OpenShift : deux mondes, une seule infrastructure
Cette infrastructure composable (on parle aussi parfois de d’infrastructure « désagrégée ») présente trois bénéfices majeurs par rapport à l’hyperconvergence. D’abord, elle offre une plus grande granularité en permettant d’ajuster indépendamment la puissance de calcul et la capacité de stockage, ce qui élimine le surprovisionnement et garantit une plus grande adéquation entre les investissements et les besoins.
Autre point fort, cette approche est totalement agnostique et permet de faire cohabiter machines virtuelles, conteneurs ou serveurs bare metal. Avec une infrastructure composable, vous pouvez connecter une seule baie de stockage de type Dell PowerStore, à dix serveurs Dell PowerEdge différents, dont cinq tournent sous VMware et cinq autres sous Red Hat OpenShift par exemple, le tout piloté par la console unique de DAP.
Moins de serveurs, moins de licences, donc moins de coûts. En associant granularité et agnosticisme, l’infrastructure composable génère d’importantes économies. D’après une étude réalisée par le cabinet Principled Technologies, une infrastructure composable permet de réduire le TCO de plus de 20 % sur 5 ans par rapport au HCI. Une belle revanche !
Pas besoin de scripts ; juste des fichiers de configuration décrivant l’état des hôtes.
Telle était la promesse de CFEngine lorsqu’il émergea dans les années 90. Avec son langage dédié, l’outil devait faciliter la maintenance des environnements BSD et System V (UNIX) en les organisant en classes. Il s’agissait déjà de répondre à la fragmentation des systèmes d’information…
Liste de contrôle d’accès NT. Issu de la documentation de CFEngine 1.6, sorti en 2000.
Dans les années 2000, Puppet et Chef sont arrivés sur le même créneau, chacun avec son langage basé sur Ruby. L’un et l’autre fonctionnaient en mode pull, le client contactant régulièrement le serveur pour récupérer la configuration. On ne parlait pas encore de DevOps, mais d’automatisation du travail des sysadmins.
Architecture simplifiée de Puppet telle que présentée en 2010.
Au début des années 2010, AWS pousse le templating JSON/YAML avec CloudFormation. Ansible décline le concept en playbooks. Terraform l’adopte avec son propre langage (HCL) et le porte à l’échelle de déploiements multifournisseurs.
Template CloudFormation créant une instance EC2. Exemple donné début 2011, quelques semaines après le lancement du service.Exemple de configuration Terraform que HashiCorp donnait en 2014, peu après le lancement du produit.Playbook Ansible donné en référence en 2015, juste avant que la start-up se vende à Red Hat.
Face aux limites des langages dédiés et de l’option « tout YAML » apparaissent des outils comme Pulumi, qui adaptent les langages impératifs (Go, Python…) à la gestion d’infrastructure.
La recette IaC déclinée sur l’observabilité…
Avec ce bagage, l’approche « as code » s’est développée sur d’autres pans des systèmes informatiques : documentation, sécurité, politiques organisationnelles… ou encore observabilité. Dashboards, alertes, logs, traces, métriques, SLO/SLI, etc. deviennent autant d’éléments « codifiés » sur le même plan que l’infra ; et, in fine, déployés en parallèle, avec un repo Git comme « source de vérité ».
Corollaire de cette convergence, l’observability as code (OaC) porte globalement les mêmes promesses que l’infrastructure as code (IaC). À commencer par les bénéfices de l’automatisation.
Sur le papier, outre la réduction du potentiel d’erreurs humaines, on a des configurations reproductibles favorisant la cohérence entre environnements et la mise à l’échelle dans le contexte d’architectures dynamiques (microservices, workloads IA). On crée par ailleurs une boucle de rétroaction avec l’IaC, en bénéficiant de la traçabilité de Git – lequel permet aussi, en théorie, une reconstruction rapide de la stack d’observabilité.
… avec un bouquet d’abstractions
En parallèle de leurs API, les principales solutions d’observabilité sont pilotables via Terraform, grâce à un provider. Elles proposent aussi d’empaqueter des configurations en charts Helm et d’utiliser des CRD pour définir des artefacts en tant qu’objets Kubernetes standards.
À cheval entre ces deux univers, il y a le projet Upjet. Celui-ci transforme les providers Terraform en providers Crossplane, tout en générant les contrôleurs de réconciliation et la documentation API avec des exemples de manifestes.
Du côté de Grafana, on expérimente actuellement une fonctionnalité Git Sync. Elle assure une synchronisation bidirectionnelle l’UI et le Git, avec la possibilité d’imposer que les changements réalisés sur l’interface passent par des PR. Pour le moment, certains artefacts ne sont pas pris en charge (alertes, panels…) et seul GitHub est géré (authentification par PAT uniquement).
Grafana a aussi, dans sa boîte à outils, un SDK Foundation orienté sur les langages à typage fort (on définit des dashboards en chaînant des appels de méthodes). Il a également une bibliothèque qui met en œuvre Jsonnet. Cette extension de JSON a été influencée par plusieurs langages de configuration utilisés chez Google. Elle facilite les regroupements logiques de configurations avec ajustement des variables à la volée pour contextualiser les artefacts.
À partir de Jsonnet, Prometheus a créé les mixins. Ce format encapsule des alertes/règles et des dashboards Grafana en compagnie du code avec lequel ils sont déployés.
Autre langage qui a ses racines chez Google : CUE (Configure, Unify, Execute). Il s’est en l’occurrence inspiré du langage utilisé pour configurer Borg, le prédécesseur de Kubernetes. En son cœur, une technique communément exploitée en linguistique informatique pour gérer grammaires et lexiques : l’unification de graphe. Types et valeurs sont fusionnés en un seul concept et ordonnés en une hiérarchie unique.
Associatif, CUE est aussi commutatif et idempotent : peu importe leur ordre, les valeurs produisent toujours le même résultat. On s’en servira typiquement pour la validation de schémas ou de données. Les types agissent alors comme des contraintes, réconciliables depuis plusieurs sources sans avoir à effectuer d’importations.
Des stacks open source aux plates-formes d’observabilité
À petite échelle, un pattern traditionnel de déploiement de l’OaC repose sur la pile open source* Prometheus/Grafana/Loki/Jaeger. Souvent en monorepo avec un dossier pour les artefacts d’observabilité, un déploiement Helm ou CI/CD simple et une synchro par Git Sync ou API/webhooks.
À un deuxième niveau, chaque équipe possède son repo et sa configuration d’observabilité (« You build it, you run it »). Le déploiement peut impliquer Kustomize. Cet outil de gestion intégré à Kubernetes se distingue de Helm en permettant de surcharger toute valeur d’une configuration de base.
À ce même niveau, on voit souvent apparaître une gestion GitOps (réconciliation automatisée avec Flux ou Argo CD). Et le recours au collecteur OpenTelemetry pour standardiser la collecte sans modifier la couche d’instrumentation.
Viennent ensuite les plates-formes d’observabilité. À ce niveau, les identités machine se généralisent dans les pipelines. Et, avec elles, les systèmes de promotion automatisée, le contrôle de cardinalité (liste blanche de tags, politiques d’échantillonnage avec des outils comme Cribl et Vector) voire l’exploitation d’eBPF.
« Tout le monde échantillonne la data. La seule raison pour laquelle on le fait, c’est le coût de stockage », explique à ce sujet Stéphane Estevez, EMEA Market Advisor observabilité chez Splunk. Sa société, poursuit-il, a l’avantage de la taille : « Par rapport à nos concurrents, nos économies d’échelle ne sont pas les mêmes. On peut se permettre d’être compétitif tout en garantissant toutes les données ».
Vodafone en est arrivé à ce dernier stade. Il a plus précisément mis en place des modules d’observabilité Terraform. Ses développeurs consomment en self-service (ils n’ont qu’à déclarer les variables) et peuvent les modifier par PR.
Vu le nombre de développeurs, de services et d’artefacts d’observabilité, il a fallu diviser le fichier d’état (Terraform mettait sinon 17 minutes à s’exécuter).
Accepter la codebase comme « source de vérité »
Que ce soit pour créer un dashboard lors d’un incident ou modifier des seuils afin de « faire taire » des alertes, dans une approche OaC, l’utilisation de l’UI soulève la question de la réconciliation avec la partie as code. Une des réponses consiste à n’autoriser que ce qui passe par cette dernière, au minimum en production. Une autre, à verrouiller les états pour éviter les corruptions.
« Si on pousse la logique OaC, il faut accepter que la source de vérité, c’est ce qui est dans la codebase », confirme Pejman Tabassomi, Field CTO EMEA de Datadog.
Quant à enrichir l’OaC avec du machine learning, ce n’est pas forcément si évident. IBM, qui a son Cloud Pak for AIOps (évolutions des outils de Tivoli), en témoigne par la voie d’Éric Cattoir. L’intéressé fait partie d’une équipe technique au niveau EMEA couvrant les sujets regroupés sous la marque IT Automation. « On a essayé de faire des modèles basés sur l’analyse des logs, explique-t-il. On s’est aperçu que cette fonctionnalité dépend beaucoup de la structure et de la stabilité des fichiers. Chez certains clients, ça a nécessité beaucoup de rééducation des modèles, car il y avait trop de variabilité entre leurs systèmes ».
* Dans le domaine de l’open source, le projet Perses, en sandbox à la CNCF, pousse une spécification ouverte pour la visualisation des données d’observabilité. Pour le moment, métriques Prometheus, traces Tempo, logs Loki et profilage Pyroscope. Il inclut un vérificateur statique, un opérateur Kubernetes et un CLI pour réaliser des actions dans les pipelines CI/CD. Des SDK Go et CUE implémentent l’approche « as code ».
La startup spécialisée dans la recherche par intelligence artificielle vient de conclure un accord stratégique avec Microsoft. Ce partenariat, qui pourrait redéfinir le marché du cloud, intervient dans un contexte de tensions avec Amazon.
Microsoft a publié ses résultats financiers pour le trimestre clos fin décembre 2025, et le contraste est frappant entre les scores de la division gaming… et le reste de la société ! Tandis que le groupe affiche une croissance solide portée par le cloud et l’intelligence artificielle, Xbox …
En ce moment, je me pose plein de questions, comme vous, j’imagine, concernant les choix importants qu’on nous demande de réaliser dans notre profession, avec une certaine pression, voire une pression certaine… Quelle solution matérielle choisir pour notre stockage primaire ? Quelle taille et quel type pour nos clusters Compute, et comment les dimensionner ? Quels environnements de sauvegarde ? Et comme si cela ne suffisait pas, il faut aussi choisir notre trajectoire en matière d’hyperviseurs et de logiciels d’administration …
Une alternative open source à NextCloud développée en Go. Pour l'avoir vu fonctionner sur un NAS (relativement costaud tout de même), c'est très fluide.
OVHcloud pousse ses pions dans les labos et les campus européens via OCRE : moins de paperasse, plus de cloud, et un angle “souveraineté” qui tombe à pic. Au menu, une quarantaine de services, du PaaS et un discours data protection taillé pour les contraintes des institutions publiques. Cloud souverain et OCRE se croisent rarement […]
Azure passe la seconde. Après avoir récemment lancé son CPU maison de seconde génération « Cobalt 200 », Microsoft a dévoilé cette semaine la seconde génération de son propre accélérateur d’inférence IA : le Maia 200. Et attention, ça décoiffe… Dans la bataille pour la suprématie de l’infrastructure IA, les hyperscalers ont compris qu’ils ne pouvaient plus dépendre […]
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 Commission européenne travaillerait sur un nouveau cadre législatif visant à renforcer la souveraineté technologique de l’Union, dans un contexte de tensions commerciales croissantes avec les États-Unis. Selon plusieurs responsables européens, l’objectif ne serait pas d’exclure les entreprises américaines du marché européen, mais de réduire les dépendances stratégiques …
Running modern versions of Adobe Photoshop on Linux has long been difficult, mainly because the installation process depends on Adobe Creative Cloud, which has historically failed to work properly through Wine. That situation may now be changing. According to a recent update shared by an independent developer known as PhialsBasement, Photoshop 2021 and 2025 can now be installed and run on Linux in a stable way, thanks to a set […]
Après une journée difficile, Microsoft confirme le rétablissement de ses services cloud ce vendredi, malgré quelques lenteurs résiduelles possibles durant les opérations de maintenance.
« 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.
Hausse tarifaire subie, migration impossible, verrou contractuel, fournisseur incontournable… La dépendance numérique est une réalité devenue ingouvernable. Il est temps que cela change. L’Indice de résilience numérique veut concrétiser cette dépendance sous forme de score comparable, veut transformer ces “accidents” en risques pilotables, ramener la quête d’autonomie à une quête de résilience menée grâce à […]
Connexion
