Ginux : le fondateur de Rocky Linux crée un noyau compatible Linux en 11 jours avec l'IA

Onze jours. C'est le temps qu'il a fallu à un agent de codage, piloté au quotidien par un expert humain, pour produire un noyau de système d'exploitation capable de démarrer l'espace utilisateur de Rocky Linux 10, sans s'appuyer sur le noyau Linux. Le projet s'appelle Ginux, et il ne vient pas d'un laboratoire d'IA : il vient de Gregory Kurtzer, l'un des cofondateurs de la distribution Linux CentOS, fondateur de Rocky Linux et de l'éditeur de logiciels CIQ. Le noyau en lui-même n'est pas destiné à la production, et son auteur le dit sans détour. Ce qui mérite l'attention des équipes, c'est la méthode qu'il décrit pour encadrer l'agent, et ce qu'elle dit du rôle de l'humain quand on confie un projet logiciel complexe à une IA.

Ce que Gregory Kurtzer a présenté le 27 octobre

Le 27 octobre 2026, Gregory Kurtzer a publié sur Zenodo, l'archive ouverte de publications scientifiques, un rapport technique consacré à Ginux, accompagné du code source sur GitHub. Ginux est un noyau x86-64 indépendant, écrit principalement en Rust. Ce n'est pas un fork de Linux : c'est un noyau distinct, qui fournit lui-même sa gestion de la mémoire, son ordonnanceur, son modèle de processus, son système de fichiers virtuel et sa pile réseau. Il implémente l'interface binaire de Linux (l'ABI, le « contrat » que respectent les programmes compilés pour Linux) afin d'exécuter certains programmes Linux non modifiés.

La démonstration est concrète. Ginux démarre directement via UEFI, à partir d'une image unique GINUX.EFI, sans noyau Linux hôte. Il lance un espace utilisateur Rocky Linux 10, tiré de l'image de conteneur officielle de la distribution, avec systemd jusqu'à la cible multi-user.target, qui correspond à un système multi-utilisateur opérationnel, et exécute aussi certains programmes Alpine Linux tels quels. Le site d'actualité open source It's FOSS et le média spécialisé IT-Connect ont relayé l'annonce, le premier dès le 27 octobre, le second le 29.

Côté chiffres, le dépôt fait état d'environ 139 000 lignes de code d'implémentation et de tests conservées, produites en onze jours, pour l'essentiel par une seule tâche persistante confiée à OpenAI Codex, l'agent de codage d'OpenAI. Le modèle utilisé est GPT-5.6 Sol, que nous avions présenté dans notre article sur GPT-5.6 et ses variantes Sol, Terra et Luna, et non GPT-6.1, pourtant déjà disponible au moment de l'annonce. L'historique compte plus de 1 000 commits. Le code est publié sous licence Apache 2.0 et le rapport sous licence CC BY 4.0. Le nom, lui, est une plaisanterie assumée : Ginux mélange Linux, GPT et Greg.

La vraie nouveauté : une méthode, pas un noyau

Kurtzer donne un nom à sa façon de travailler : Human-Directed Agentic Engineering (HDAE), l'ingénierie agentique dirigée par l'humain. Le partage des rôles est net. L'humain définit l'architecture, les contraintes, les jalons, les critères d'acceptation et les points d'arrêt. L'agent, lui, tourne en boucle autonome à l'intérieur de chaque jalon : il implémente, démarre le système, teste, diagnostique et corrige, jusqu'à franchir la porte fixée. À la limite du jalon, il s'arrête et attend la validation humaine avant d'attaquer le suivant.

Cette boucle rappelle la technique que nous décrivions dans notre article sur la Ralph Wiggum AI Loop, où un agent relance son travail jusqu'à atteindre un objectif vérifiable. La différence tient à l'encadrement : chez Ginux, des documents d'architecture et de décision maintiennent l'agent aligné sur des choix posés par un expert, et chaque étape se termine sur une validation explicite.

Des critères d'acceptation qui s'exécutent

Le point le plus instructif du projet tient dans la forme des critères d'acceptation. Ce ne sont pas des phrases dans un cahier des charges, mais des portes exécutables : des cibles de build comme make test-linux-runtime, make test-alpine, make test-rocky-shell, make test-multi-domain, make test-rocky-systemd, make test-storage ou make check. L'agent sait s'il a franchi la porte, et l'humain sait précisément ce qu'il valide : ce que couvrent les tests, ni plus ni moins.

Autre choix structurant : faire tourner de vraies charges de travail (un espace utilisateur Rocky Linux, des programmes Alpine) comme tests d'intégration, en complément des tests synthétiques. D'après le dépôt, ces usages réels ont fait remonter des défauts que les tests synthétiques ne voyaient pas. Le projet pose aussi une limite honnête : un test réussi prouve que ce flux-là fonctionne, pas que n'importe quel binaire Linux tournera.

Ce que Ginux n'est pas (encore)

Le rapport comme le dépôt sont explicites : Ginux est un prototype de recherche expérimental, pas un remplaçant de Linux. La seule cible validée est une machine virtuelle QEMU (un logiciel libre d'émulation de machines) de type Q35. Il n'existe pas de profil pour du matériel physique, pas de prise en charge des GPU ni des disques NVMe, et aucun audit de sécurité indépendant n'a été mené. Sur le point d'étape évalué par le rapport (l'état du code au 23 octobre 2026), la suite de tests agrégée make test ne passe pas entièrement : une sonde de cycle de vie du superviseur système après execve() (l'appel système qui lance un nouveau programme) reste en échec, et cet échec est consigné noir sur blanc dans le dépôt.

La compatibilité avec Linux est elle aussi partielle. Sur les 375 appels système de l'interface Linux 6.12 x86-64, le dépôt en classe 82 comme complets, 245 comme partiels et 48 comme refusés par choix de conception. Chaque appel a donc un statut explicite, ce qui ne veut pas dire que tous fonctionnent comme sous Linux.

Les résultats eux-mêmes appellent une lecture prudente, et le rapport le reconnaît : il s'agit d'un seul projet, sans groupe témoin ni reproduction indépendante, et c'est Kurtzer qui a fixé l'architecture puis jugé si le comportement observé était acceptable. Le nombre de lignes, de commits ou de jours décrit le projet, sans mesurer la qualité du code ni le travail humain équivalent.

Kurtzer va plus loin dans le dépôt : le projet ne reproduit ni la large compatibilité de Linux, ni sa prise en charge matérielle, ni sa relecture, son écosystème d'éditeurs, sa communauté ou sa maintenance sur le long terme. C'est précisément ce qui sépare un prototype spectaculaire d'un produit. Côté Linux, la question de l'IA se pose d'ailleurs en termes de responsabilité, comme nous le racontions avec la position de Linus Torvalds sur l'IA dans le noyau : l'IA peut écrire, un humain signe.

Ce que ça change pour les équipes qui confient du code à un agent

Ginux ne dit pas qu'un agent remplace une équipe. Il illustre, sur un cas, où se déplace le travail humain : de l'écriture du code vers la spécification, les critères d'acceptation et la validation. Et il rappelle une condition que le rapport technique pose lui-même : la méthode repose sur l'expertise du domaine et sur une validation exécutable. Kurtzer a cofondé CentOS puis fondé Rocky Linux, deux distributions Linux de référence, avant de lancer Ginux, et le dépôt précise que le travail a été dirigé par quelqu'un qui maîtrise les systèmes. C'est ce bagage qui permet de poser l'architecture, de choisir les tests et de repérer quand l'agent fait fausse route.

Transposée à un logiciel métier, un ERP ou une application interne, la leçon que nous en tirons est très concrète. Avant de lancer un agent, il faut savoir décrire le résultat attendu sous une forme vérifiable par une machine : des tests qui rejouent les vrais parcours des utilisateurs, sur des données réalistes, avec des jalons courts et un point d'arrêt où quelqu'un relit et décide. C'est le même travail qu'un bon cadrage de projet, rendu exécutable. Sans lui, un agent rapide risque surtout de produire beaucoup de code difficile à valider.

Le dépôt publie d'ailleurs les « skills » HDAE utilisés pour guider l'agent, exposés à la fois à Codex et à Claude Code : le processus démarre par une série de questions pour formaliser l'intention et l'architecture, propose des jalons avec leurs portes exécutables, et attend une approbation avant chaque étape. Pour une équipe qui veut tester l'approche, c'est un point de départ documenté et réutilisable sous licence Apache 2.0.

Reste la distance entre le prototype et la production. Un noyau qui démarre dans QEMU en onze jours n'a pas encore traversé ce qui fait la valeur d'un logiciel dans la durée : l'audit de sécurité, la couverture des cas réels, la relecture humaine et la maintenance. La vitesse de construction peut changer d'échelle ; la responsabilité de ce qui part en production, elle, reste entière.