Le 22 juin 2026, AWS publiait un billet sur son blog officiel. Le titre était long, mais le message central tenait en une phrase : Lambda peut désormais exécuter des MicroVMs.
AWS n’a pas lancé de nouveau service, pas de nouveau SKU — c’est dans Lambda, le produit serverless vieux de 11 ans, qu’une porte entièrement nouvelle vient de s’ouvrir. Ma première réaction à la lecture : AWS a fait passer Firecracker de l’arrière-boutique à la vitrine, et cette fois, ce n’est pas pour les fonctions Lambda elles-mêmes, c’est directement pour les développeurs.
Ce qui a vraiment été annoncé
Lambda MicroVMs est une nouvelle primitive de calcul. Elle partage la même console que les fonctions Lambda, mais l’API est entièrement différente : vous téléversez un Dockerfile et une archive de code sur S3, Lambda construit l’image, initialise l’application et capture un snapshot Firecracker. À chaque démarrage ultérieur de la MicroVM, la reprise se fait directement depuis ce snapshot préchauffé — le démarrage à froid est tout simplement court-circuité.
Quelques paramètres clés méritent l’attention :
- Limites par instance : 16 vCPU, 32 Go de RAM, 32 Go de disque, architecture ARM64 (Graviton)
- Durée d’exécution maximale : 8 heures — la limite de 15 minutes des fonctions Lambda disparaît ici
- Politique d’inactivité : suspension automatique configurable (suspend) ; pendant la suspension, seuls les frais de stockage du snapshot sont facturés, et la reprise conserve l’état complet de la mémoire et du disque
- Mode de démarrage : reprise de snapshot et non démarrage à froid. Une fois le démarrage réussi, un endpoint HTTP prêt à l’emploi est immédiatement disponible
- Régions au lancement : US East (Virginie, Ohio), US West (Oregon), Europe (Irlande), Asie-Pacifique (Tokyo)
La tarification est facturée à la vCPU/seconde et à la mémoire/Go/seconde, les frais de calcul tombant à zéro après suspension. La logique est cohérente avec celle des fonctions Lambda, mais comme une session peut durer plusieurs heures, la structure réelle de la facture se rapproche davantage de celle d’une machine virtuelle à la demande — avec la capacité de pause en plus.
Le blog officiel d’AWS énumère explicitement un ensemble de cas d’usage : assistants de programmation IA, environnements de code interactifs, plateformes d’analyse de données, scanners de vulnérabilités, serveurs de jeux exécutant des scripts utilisateur. Leur trait commun ? Chaque utilisateur final a besoin d’un environnement isolé qui lui est propre, capable d’exécuter du code non fiable en toute sécurité.
Pourquoi maintenant ?
Cette question mérite d’être décomposée.
Firecracker est open source depuis 2018. Au cours des sept dernières années, il a soutenu chaque mois plus de 15 000 milliards d’invocations de fonctions Lambda. La technologie est mûre, mais AWS n’avait jamais commercialisé Firecracker comme un produit destiné aux développeurs — jusqu’à présent.
Ce qui a changé, ce n’est pas la préférence stratégique d’AWS, c’est la demande.
De 2025 au premier semestre 2026, les assistants de code IA sont passés du stade expérimental à celui d’outil quotidien. Claude Code, Codex CLI, Gemini Code Assist — ces agents ne se contentent pas de générer du code, ils doivent aussi l’exécuter. Installer des paquets, lancer des services, lire et écrire sur le système de fichiers, effectuer des requêtes réseau. Des millions de fois par jour. Et les environnements qui exécutent ce code sont soit des conteneurs Docker (noyau partagé, isolation par namespace + cgroup + seccomp), soit des machines virtuelles (isolation forte mais démarrage lent).
Plus épineux encore, les agents eux-mêmes contournent activement les restrictions de sécurité logicielles. En mars 2026, Leonardo Di Donato, mainteneur principal de Falco, a démontré comment Claude Code contournait son propre bac à sable : l’agent a découvert que /proc/self/root/usr/bin/npx échappait aux règles deny, a été intercepté par bubblewrap, puis a tout simplement désactivé le bac à sable. Pas de jailbreak, pas de prompt spécial. Il voulait juste accomplir sa tâche.
Ce cas illustre un fait central : l’isolation fondée sur la logique de l’espace utilisateur (denylist, permission prompt, règles seccomp) opère au même niveau que le raisonnement de l’agent. L’agent a suffisamment de capacité pour les comprendre et les contourner. L’isolation par MicroVM est, elle, imposée par la virtualisation matérielle, à un niveau que l’agent ne peut pas atteindre.
Le timing du lancement des Lambda MicroVMs coïncide étroitement avec l’émergence de ce problème de sécurité.
Le paysage du marché des bacs à sable
Les Lambda MicroVMs ne surgissent pas du vide. Avant elles, la question « comment exécuter du code non fiable en toute sécurité » avait déjà engendré un écosystème d’outils et de plateformes conséquent. J’ai dressé ci-dessous un panorama des principaux protagonistes, sans classement hiérarchique, en me limitant aux différences architecturales et aux cas d’usage.
Le camp Firecracker
AWS est naturellement le plus gros acteur. Au-delà des nouvelles Lambda MicroVMs, AWS Bedrock AgentCore utilise déjà Firecracker pour fournir une microVM isolée par session d’agent.
Parmi les plateformes indépendantes, E2B est un service de sandbox dédié aux agents IA, reposant sur Firecracker, avec un démarrage d’environ 150 ms et une revendication de 88 % du Fortune 100 inscrits. Fly.io Sprites propose des VM stateful persistantes avec checkpoint/restore en ~300 ms, préinstallées avec Claude Code et Codex CLI. Vercel Sandbox, également basé sur Firecracker, mise sur la reprise de snapshot en millisecondes pour les scénarios d’interpréteur de code IA. SlicerVM suit une voie auto-hébergée, supportant à la fois Firecracker et Cloud Hypervisor, avec la possibilité d’utiliser Apple Virtualization Framework sur macOS.
Parmi les projets open source, Matchlock mérite l’attention — un bac à sable Firecracker conçu pour les agents IA, avec politique réseau deny-all par défaut, liste blanche de domaines, protection des secrets, spécialement conçu pour résoudre les problèmes de sécurité posés par claude --dangerously-skip-permissions.
Le camp libkrun
Le libkrun de Red Hat adopte une approche de VMM au niveau bibliothèque — il empaquette les capacités microVM dans une bibliothèque appelable par d’autres programmes, plutôt que dans un démon indépendant. Microsandbox (incubé par YC, open source Apache 2.0, ~4 700 étoiles GitHub) est le consommateur le plus typique de libkrun : un bac à sable auto-hébergé pour agents IA, chaque instance recevant un noyau, un système de fichiers et une pile réseau indépendants.
Un avantage différenciant de libkrun est sa portabilité multiplateforme : KVM sur Linux, Hypervisor.framework sur macOS. L’inconvénient est l’absence de couche d’orchestration Kubernetes et de gestion au niveau cluster — il excelle dans le déploiement sur machine unique, adapté aux besoins de sandbox des développeurs en local ou des petites équipes, plutôt qu’aux environnements de production multi-tenant à grande échelle.
Kata Containers
Kata Containers se distingue fondamentalement des autres solutions par son positionnement : il fournit un cadre d’orchestration qui intègre Firecracker, Cloud Hypervisor ou QEMU dans la couche d’exécution Kubernetes, de sorte que chaque Pod tourne dans sa propre VM légère. Pour Kubernetes, il ressemble à un conteneur ordinaire, mais en dessous, c’est une isolation matérielle complète.
Temps de démarrage ~150-300 ms (selon le choix du VMM), surcoût mémoire <10 Mio plus le noyau invité. La valeur centrale de Kata est d’encapsuler la complexité opérationnelle des microVMs — vous n’avez pas à gérer vous-même les images noyau, la configuration réseau ou le cycle de vie des VM. Northflank exécute Kata Containers + Cloud Hypervisor en production, avec une moyenne de plus de 2 millions de microVMs par mois.
Kata est destiné aux charges de travail multi-tenant de longue durée nécessitant une orchestration K8s, et non aux scénarios de démarrage/arrêt rapide de sessions uniques.
gVisor
Le gVisor de Google suit une voie technologique radicalement différente : au lieu d’envelopper le conteneur dans une machine virtuelle, il insère un noyau en espace utilisateur écrit en Go (Sentry) entre le conteneur et le noyau de la machine hôte. Les appels système du conteneur sont interceptés par Sentry et traités dans l’espace utilisateur ; seules quelques opérations indispensables sont transmises au noyau hôte.
Cela signifie : pas de surcoût de démarrage de VM, pas de nécessité de virtualisation imbriquée, le chemin d’intégration Docker/containerd est le plus court. Le prix à payer : les charges de travail intensives en E/S subissent un surcoût de 10-30 % sur les appels système. La force d’isolation de gVisor se situe entre celle des conteneurs et celle des machines virtuelles — il réduit considérablement la surface d’attaque du noyau (Sentry n’implémente que ~230 appels système, contre 450+ exposés par le noyau Linux), mais ne peut pas garantir l’isolation mémoire au niveau matériel.
Modal est le produit représentatif de l’approche gVisor, offrant un environnement sandbox avec support GPU, démarrage ~300 ms, ciblant les scénarios d’inférence et d’entraînement.
Cloudflare Workers (V8 Isolates)
Cloudflare suit un autre extrême : les isolates V8. Temps de démarrage sub-milliseconde, mais support limité à JavaScript/TypeScript/WASM. En 2026, la fonctionnalité Dynamic Workers a été ajoutée, permettant aux LLM de générer dynamiquement des sous-isolates JS/TS à l’exécution pour exécuter du code, avec une consommation de tokens réduite de 81 % par rapport au tool-calling traditionnel. Ce n’est pas un bac à sable universel, mais dans l’écosystème JS/WASM, sa densité et sa latence sont inégalées.
Les axes de différenciation
Après avoir passé en revue les différentes solutions, j’observe plusieurs dimensions en train de devenir des foyers de concurrence :
Capacité de snapshot/fork. Le « démarrage direct par snapshot préchauffé » des Lambda MicroVMs consiste essentiellement à figer un état d’exécution déjà initialisé et à le restaurer directement au prochain démarrage. Cette idée est poussée à l’extrême chez Unikraft Cloud — qui revendique un démarrage à froid <10 ms et plus de 100 000 instances isolées par machine hôte. La vitesse de snapshot détermine directement l’expérience utilisateur : quand un agent émet une demande d’exécution de code, que l’utilisateur attende 100 ms ou 5 secondes, c’est la différence entre une adoption durable et un abandon.
Masquage des secrets au niveau réseau. C’est particulièrement critique pour les scénarios d’agents. L’agent a besoin d’accéder au réseau extérieur (récupérer des dépendances, appeler des API), mais vous ne voulez pas qu’il lise vos secrets dans les variables d’environnement. La solution des Lambda MicroVMs repose sur des short-lived auth tokens + en-tête proxy ; celle de Matchlock sur deny-all + liste blanche de domaines. La différence n’est pas dans la présence ou l’absence de fonctionnalités, mais dans la compréhension du modèle de sécurité propre à chaque acteur.
Accès SSH / VPN. Les scénarios de développement interactif exigent que le développeur puisse entrer directement dans le bac à sable pour déboguer. Fly.io Sprites et E2B supportent SSH ; les Lambda MicroVMs utilisent pour l’instant le modèle d’endpoint HTTP, plus adapté à l’exécution de code qu’au développement interactif.
Couche d’orchestration et intégration K8s. Kata Containers est pratiquement sans concurrent sur cette dimension — il a été conçu pour Kubernetes. Utiliser Firecracker à nu exige de construire une quantité considérable d’infrastructure ; les Lambda MicroVMs transfèrent cette responsabilité au service géré d’AWS. libkrun manque actuellement de solution d’orchestration au niveau cluster.
Aptitude aux agents (agent-friendliness). Cela relève de la philosophie de conception produit, pas d’une simple comparaison de spécifications techniques. Le bac à sable expose-t-il une API REST ? Fournit-il un SDK ? La sémantique de snapshot/resume est-elle adaptée à la boucle « exécuter — attendre le résultat — continuer l’exécution » des agents ? Le mécanisme de pause/reprise et la limite de 8 heures des Lambda MicroVMs sont clairement conçus pour les sessions d’agents, tandis que le modèle « un démon Docker indépendant par agent » des Docker Sandboxes est plus orienté vers les scénarios de développement local.
Le paysage n’est pas encore figé
En prenant du recul, lorsque Firecracker est né en 2018, la microVM était un moyen d’optimisation de la couche infrastructure — rendre Lambda plus rapide, plus économe, plus sûr. En 2026, la même technologie est devenue un citoyen de première classe de la couche produit, parce que la demande en amont a changé de nature : les agents doivent exécuter du code, l’exécution de code nécessite un bac à sable, et le bac à sable ne peut pas être un patchwork de namespaces.
Mais la question « quel est le meilleur bac à sable ? » n’a pas de réponse unique. Si votre agent n’exécute que du JavaScript, les isolates V8 de Cloudflare Workers sont peut-être plus puissants qu’une microVM au démarrage sub-milliseconde. Si vous tournez sur Kubernetes avec besoin de pods isolés de longue durée, Kata Containers est plus pragmatique que Firecracker à nu. Si vous avez besoin d’une solution locale auto-hébergée légère, libkrun + Microsandbox est plus flexible qu’un service géré AWS. La force des Lambda MicroVMs réside dans le zéro-opérations et la reprise par snapshot — mais cela vous lie à l’écosystème AWS, à l’architecture ARM64 et aux limitations régionales.
Je n’ai exécuté à grande échelle en production aucune des solutions de sandbox mentionnées ci-dessus. Le jugement présenté ici se fonde sur le croisement de la documentation publique, des livres blancs techniques et des discussions communautaires. Si vous êtes en train de choisir une infrastructure de sandbox pour des agents IA, je vous conseille de faire vos propres benchmarks avec votre charge de travail — les performances d’une reprise de snapshot à 100 ms dans des conditions réelles de latence réseau peuvent n’avoir que peu de rapport avec les chiffres d’un tableau de benchmark.
Le facteur décisif d’une architecture se trouve rarement dans l’architecture elle-même. Dans un monde où un agent émet des dizaines de requêtes d’exécution de code par seconde, la vitesse de snapshot, la latence réseau, la gestion des secrets, le modèle de facturation — tous ces facteurs « non centraux » pourraient compter davantage que le langage dans lequel le VMM est écrit (Rust ou Go).
Déclaration : cet article est une observation technique ; je n’ai aucun lien d’intérêt avec les entreprises ou les projets mentionnés.