“Unikernels were hard. Key word: were. Now we have AI.”
En octobre 2026, Geoffrey Huntley formulait ce constat sans détour au cours d’un échange technique. Face à lui, Justin Cormack, l’un des premiers artisans au cœur de MirageOS. Dix ans plus tôt, pour exécuter des applications directement sur des machines virtuelles, l’équipe devait extraire des pilotes de NetBSD et porter à la main des milliers de lignes de code C de bas niveau vers l’espace utilisateur.
Un unikernel repose sur une architecture à espace d’adressage unique : l’application constitue elle-même le système d’exploitation. L’image ne comporte ni processus distincts, ni shell interactif. Pour acheminer des paquets réseau ou résoudre un nom de domaine, les développeurs ne peuvent s’en remettre à l’environnement hôte. Tous les pilotes et piles de protocoles doivent être compilés directement au sein du binaire.
Pendant une décennie, la rudesse des chaînes d’outils et la pauvreté de l’écosystème ont confiné cette approche aux marges de l’industrie. Aujourd’hui, les grands modèles de langage ont balayé le coût de création de bibliothèques sur mesure. Pour autant, l’abaissement de cette barrière n’a nullement résolu les controverses de sécurité inhérentes au modèle.
Figure : Illustration conceptuelle représentant un unikernel sous la forme d’un cœur numérique épuré. Source : ghuntley.com
Les poids des modèles absorbent le fardeau des pilotes écrits à la main
Aux yeux de Huntley, le secteur logiciel a trop longtemps ployé sous des dogmes figés : Nix est complexe, Bazel est difficile, les unikernels sont inaccessibles. Ces obstacles n’étaient pourtant que des barrières de connaissances dressées par des détails d’implémentation.
Les poids des modèles ont digéré la théorie des types et des décennies de littérature académique. L’échafaudage de bas niveau qui réclamait jadis des mois de labeur se matérialise aujourd’hui en quelques requêtes textuelles. Les ingénieurs chevronnés n’ont plus à retranscrire manuellement des pilotes C ligne par ligne.
Il n’a fallu qu’une semaine à Huntley pour concevoir le prototype Spaceleans. Il a porté le modèle d’acteurs virtuels distribués Orleans de Microsoft vers OCaml, encapsulant l’ensemble dans une image unikernel. Le système fusionne plusieurs machines physiques en un unique tas adressable où les instances d’acteurs peuvent être réhydratées à la demande depuis le stockage.
Pour faire tourner le prototype, il devait reconstituer tout le socle d’exécution. Grâce à la génération de code automatisée, il a écrit une pile réseau complète, un résolveur DNS et un client HTTP en sept jours. Il y a ensuite greffé la synchronisation horaire NTP, des clients pour LLM et le traçage distribué. Un travail d’infrastructure système qui monopolisait jadis une équipe entière a été assemblé par un développeur solitaire en quelques jours.
L’argument récurrent du manque d’écosystème s’effondre devant la génération de code. Auparavant, l’adoption d’un unikernel achoppait sur l’absence de SDK tiers, comme des interfaces de paiement éprouvées en OCaml. Enclencher des boucles d’agents permet désormais de transposer des bibliothèques Go en modules OCaml en quelques heures.
Répliquer des chaînes d’outils dédiées en quelques heures avec Rust
La pratique d’ingénierie de Cormack témoigne d’une trajectoire similaire. Lorsqu’il assemblait des images Linux dédiées à une seule application, il visait un minimalisme radical. Classiquement, pour formater un disque, il fallait embarquer l’imposant paquet xfsprogs dans l’image de compilation, uniquement pour exécuter une commande unique.
Il a préféré confier à un modèle l’écriture en Rust d’un outil mkfs.xfs dédié. L’utilitaire natif a servi d’oracle de référence (golden oracle) : le code généré a été comparé octet par octet à la sortie native et validé sur plusieurs tailles de blocs. L’analyse des arguments et l’écriture des structures sur le disque n’ont nécessité que quelques heures de travail.
Ce flux de travail transforme en profondeur la fabrication des outils système spécialisés. Tailler dans les utilitaires de base représentait autrefois une lourde charge de maintenance, contraignant les équipes à tolérer des espaces utilisateurs boursouflés. L’alliance de la génération de code et des tests différentiels contre oracle ramène le coût de conception d’outils sur mesure à un niveau négligeable.
Les architectures cloud-natives modernes allègent encore les contraintes pesant sur le système de fichiers local. Des architectures comme turbopuffer emploient directement le stockage objet comme niveau de persistance primaire, cantonnant les disques NVMe locaux au rôle de cache de blocs éphémère. Dès lors que la durabilité est confiée au cloud, le besoin de systèmes de fichiers journalisés complexes disparaît localement, permettant de gérer des états massifs sur de simples magasins d’objets.
Figure : Visuel de la vidéo de discussion « Unikernels in 2026 ». Source : YouTube / Chaîne de Geoffrey Huntley
Dépouiller l’OS de sa coquille n’élimine pas la surface d’attaque
L’effondrement des barrières techniques a exacerbé les controverses autour de la sécurité. Huntley considère les systèmes d’exploitation multi-utilisateurs comme des reliques de l’époque des terminaux passifs. Les microservices dédiés n’ont que faire d’interfaces génériques ; sans shell ni interpréteur système, l’assaillant se retrouve privé de point d’ancrage pour rebondir, neutralisant de fait les scans automatisés massifs.
Cormack a immédiatement tempéré cet enthousiasme. Il a souligné que l’argument de la « réduction de surface d’attaque » tourne trop souvent au slogan creux au sein de la communauté. Retirer /bin/sh d’un conteneur est une opération triviale, mais le moteur d’exécution applicatif conserve intrinsèquement des capacités d’interprétation complètes. Même si l’écriture sur le disque est verrouillée, la corruption mémoire et les chaînes ROP permettent toujours de détourner le flux d’exécution du programme.
Huntley a concédé que les premières conceptions regroupaient application et noyau dans le même anneau de privilèges. Il a cependant fait valoir qu’en 2026, restaurer l’isolation des anneaux n’est qu’à « une consigne de prompt » de distance, et que cette approche reste de toute façon bien plus robuste que de s’en remettre à la conformité hasardeuse des cgroups de systemd. Cormack n’a pas prolongé le débat sur ce terrain, préférant rappeler combien la notion de surface d’attaque est galvaudée.
Même l’isolation fournie par l’hyperviseur fait face à des risques tangibles d’évasion. La semaine même où l’entretien était enregistré, des chercheurs en sécurité ont touché une prime de 50 000 dollars d’un fournisseur cloud pour une faille d’évasion dans KVM. De telles vulnérabilités ébranlent le socle de l’hébergement mutualisé. Viser une sécurité critique exige de se tourner vers des systèmes formellement vérifiés comme seL4 ; placer une foi aveugle dans des images autonomes ne fait que déplacer le risque de sécurité.
La latence de compilation locale bride la cadence d’inférence
Le choix du langage de programmation conditionne directement l’efficacité des cycles automatisés. Huntley plébiscite OCaml : la netteté des interfaces offre des fenêtres de contexte resserrées, et le compilateur valide les types en quelques secondes.
À l’inverse, Cormack a rencontré d’importantes frictions dans l’écosystème Rust. La rigueur du système de types de Rust convient parfaitement au raisonnement des modèles, mais la lourdeur de la compilation brise la cadence d’itération. Lors de l’exploration de code bas niveau, les hallucinations restent inévitables ; l’attente prolongée entre deux builds renchérit considérablement le coût des allers-retours.
Sur des bases de code comprenant des millions de lignes, la compilation est allée jusqu’à saturer la machine. Quatre agents d’IA compilant du Rust de front ont immédiatement asphyxié les files d’attente CPU et les accès disque. Sur des serveurs pourtant véloces, le temps passé à attendre rustc a fréquemment dépassé celui consacré à la génération des jetons.
Cette réalité renverse la logique d’ingénierie établie. Les développeurs humains acceptaient des compilations lentes comme gage de robustesse à l’exécution. Dans les boucles itératives orchestrées par des agents, la latence de compilation s’impose désormais comme le goulot d’étranglement qui entrave l’évolution des systèmes.
L’effacement des frictions d’ingénierie met à nu les choix d’architecture
Le concept d’espace d’adressage unique est loin d’être dépassé. Nourris de théorie des types et de littérature académique, les modèles comblent les lacunes d’implémentation à grande vitesse. La génération automatique de pilotes et de piles réseau réduit les délais de mise en œuvre de plusieurs mois à quelques jours.
Mais l’évaporation des frictions de développement ne change rien aux principes fondamentaux de l’architecture informatique. Une fois l’échafaudage retiré, les développeurs restent confrontés à la réalité nue de l’unikernel : un bac à sable à processus unique, dépourvu de séparation d’anneaux matériels et hautement exposé aux défauts de sécurité mémoire.
L’IA s’est contentée de brader le coût d’entrée. Si les développeurs n’ont plus à redouter l’écriture manuelle des pilotes, ils doivent affronter les périls inhérents à un domaine de privilège unique. Renoncer à l’écosystème mature d’introspection et de débogage des systèmes d’exploitation traditionnels demeure un arbitrage d’ingénierie qui exige toute leur lucidité.
Liens de référence :
- Ignore Previous Directions : Unikernels in 2026 (Justin Cormack)
- Geoffrey Huntley : Unikernels were hard. Key word: were.
- Notes de conception du projet Spaceleans et rétrospective MirageOS
