Du code « jetable »

Gregory Kurtzer, créateur de CentOS et Rocky Linux, a créé un noyau compatible Linux, nommé Ginux. Loin d’être une proposition concrète, le projet était surtout une expérience : était-il possible de proposer un noyau compatible principalement développé par IA ?

L’expérience fait parler d’elle depuis plusieurs jours. Gregory Kurtzer est loin d’être un inconnu, il est connu pour avoir créé CentOS, une distribution Linux 100 % compatible avec Red Hat Enterprise Linux (RHEL), dont elle est une reconstruction. Apparue en 2003, CentOS attire l’attention, jusqu’à ce que Red Hat commence à sponsoriser la distribution en 2014. Dans les années suivantes, Red Hat embauche progressivement les développeurs travaillant sur CentOS, jusqu’à récupérer la gestion du projet.

Décembre 2020, patatras : Red Hat met fin à CentOS et pousse Stream, sa variante conçue pour intégrer les nouveautés. Le positionnement est alors clair : Fedora pour son aspect laboratoire, CentOS Stream pour intégrer les nouveautés en vue d’une utilisation professionnelle, RHEL pour l’offre commerciale. Gregory Kurtzer, frustré par le nouveau positionnement de Red Hat, crée alors Rocky Linux, à nouveau une reconstruction de RHEL, avec la même compatibilité complète.

• Red Hat met fin à CentOS et pousse Stream, colère au sein de la communauté

Alors quand le développeur annonce avoir créé un noyau compatible Linux, développé avec l’IA, le sujet attire l’attention. Mais pas toujours pour les « bonnes » raisons.

Un noyau compatible, pas un fork

Le projet Ginux est surtout une expérience. Il la présente sur X le 27 octobre comme « un nouveau noyau de système d’exploitation compatible avec Linux qui démarre Rocky Linux 10 avec systemd, le tout en utilisant l’ingénierie agentique dirigée par l’humain (HDAE) ».

Le noyau est conçu pour l’architecture x86-64 et est indépendant. Il ne s’agit pas d’un fork du noyau actuel. Le code utilisé est principalement écrit en Rust. Ginux propose sa propre gestion mémoire, son processus de démarrage, son ordonnanceur, son modèle de processus, ses systèmes de fichiers, son réseau, ses périphériques et sa couche de compatibilité Linux.

Sa particularité est d’implémenter l’interface binaire (ABI) de Linux afin de faire tourner les exécutables Linux existants, sans modification. Gregory Kurtzer indique que cette compatibilité est partielle : sur 375 appels système recondensés dans l’ABI Linux 6.12 en x86-64, 82 sont entièrement implémentés, 245 le sont partiellement et 48 sont refusés volontairement.

Dans l’architecture choisie par le développeur, les charges de travail sont réparties dans des environnements nommés « domaines ». Chacun dispose de ses processus, espaces d’adressage, systèmes de fichiers, points de montage, privilèges et cycle de vie. Il présente ces frontières comme plus marquées que les espaces de noms Linux et les conteneurs OCI (Open Container Initiative).

Des limites assumées

Gregory Kurtzer affirme que son projet a pris 11 jours. Il tâche de rester « humble » dans l’annonce en précisant plusieurs points. D’abord, le nom Ginux fait référence aussi bien à Greg qu’à GPT. Dans le README du projet sur GitHub, l’auteur plaisante : pour s’assurer que son égo reste contenu, le G est officiellement une référence à GPT, puisque le projet a été entièrement réalisé avec GPT-5.6 Sol.

En outre, Ginux ne fonctionne pour l’instant qu’au sein d’une machine virtuelle QEMU. Il n’y a donc ni profil matériel physique, ni support des GPU et disques NVMe, ni audit de sécurité indépendant. Le code est publié sous licence Apache 2.0 comme prototype de recherche.

Le développement cible principalement QEMU/KVM avec une configuration x86-64 Q35, et le dépôt documente aussi une exécution en émulation QEMU sur Apple Silicon. Kurtzer reconnaît que la couverture ABI est incomplète et le matériel peu pris en charge. Réseau, systèmes de fichiers, application des limites de ressources et sécurité demandent encore un travail décrit comme « considérable ».

Dans la méthode HDAE évoquée, c’est lui-même qui a fixé l’architecture, les contraintes, les jalons et les critères d’acceptation. L’agent, lui, menait la boucle d’implémentation : il était chargé d’écrire, démarrer, tester, diagnostiquer, corriger, recommencer face à des vérifications exécutables. C’est l’ensemble de ces actions qui ont alimenté une tâche unique confiée à GPT-5.6 Sol, produisant finalement 139 000 lignes de code et de tests, réparties sur un millier de validations Git environ.

Une expérience, pas un concurrent

En quelques jours, le projet a généré une attention croissante. Face à un nombre croissant de questions sur la possibilité que Ginux puisse concurrencer le noyau Linux, Gregory Kurtzer est intervenu le 29 octobre pour expliquer que « les gens passent à côté du but de Ginux » et que ce dernier n’a pas été conçu pour rivaliser avec Linux : « Ce serait idiot ! ».

Il considère le code produit comme jetable, car Ginux en tant que tel n’était pas le but de l’expérience. Il s’agissait bien du processus de création, c’est-à-dire confier à un agent un travail de longue haleine, guidé par une infrastructure, pour répondre à la question : « L’IA, dirigée par un ingénieur expérimenté, pouvait-elle construire et valider un système logiciel extraordinairement complexe ? ».

Il répète d’ailleurs que l’article de recherche documente la méthodologie, les résultats et les limitations, pas le noyau comme possibilité alternative. Il estime que les questions posées sur la méthode sont plus intéressantes que le résultat. Par exemple : « Combien de temps faut-il pour reproduire un problème, identifier la cause racine, implémenter une correction et valider le résultat ? Quelle intervention humaine est réellement requise ? ».

« Parce que la vraie question n’a jamais été de savoir si l’IA pouvait remplacer Linux. Même si elle peut remplacer certains aspects de sa fonction, elle ne peut pas reproduire la communauté, les normes, la collaboration, l’alignement ou la stabilité », affirme-t-il. Dans une autre publication le 30 octobre, il détaille d’ailleurs comment il a collecté les retours pour déclencher de nouveaux travaux, pour continuer à tester sa méthode.

Ginux est donc davantage une démonstration de faisabilité qu’un produit. Rien n’empêche bien sûr la communauté de s’emparer du projet et de le poursuivre. Rien ne permet d’affirmer que ce noyau alternatif, s’il était développé plus avant, offrirait des avantages concrets et mesurables par rapport au noyau Linux.

Si l’expérience a fait parler, c’est aussi parce que la question de l’IA agite largement le domaine du logiciel libre. La récente enquête publiée par Linux Foundation a montré en partie l’ampleur de ce questionnement, avec des développeurs et mainteneurs de projets dans une position ambivalente, entre abaissement du ticket d’entrée et besoins accrus de vérifier toute la production de code. Dans cette optique, l’expérience de Kurtzer donne un aperçu de ce qu’une IA, employée par un développeur expérimenté, peut accomplir quand elle est strictement encadrée.

• IA : la Linux Foundation constate l’épuisement croissant des contributeurs

Au feu !

Face à l’ampleur de la polémique, Proton a bien été obligée de réagir. L’entreprise suisse subit les foudres des utilisateurs et un torrent de réactions négatives suite aux révélations de 404 Media sur ses méthodes internes et son utilisation forcenée de l’IA.

Deux articles de 404 Media ont provoqué une crise au sein de Proton. Le 26 octobre, nos confrères révélaient le contenu d’un e-mail envoyé aux employés pour les avertir qu’ils allaient être « réinterrogés » au cours d’entretien sur la manière dont l’IA avait transformé leur travail. Le message laissait clairement entendre que leur emploi était menacé s’ils ne l’utilisaient pas assez. Le 29 octobre, deuxième article, cette fois pour détailler l’ambiance interne, avec un Andy Yen (CEO) très offensif, voire insultant avec les développeurs.

• Chez Proton, le rouleau compresseur de l’IA écrase tout

Le point le plus inquiétant pour les utilisateurs, comme vu sur Reddit et X notamment, semblait l’accélération de la production de code par IA au détriment de la sécurité. 404 Media avait mis en avant un échange sur Slack dans lequel un développeur demandait du temps pour réaliser des tests de pénétration sur du nouveau code. Andy Yen y répondait en critiquant la requête et en évoquant une « mentalité de loser ».

Proton cherche maintenant à éteindre l’incendie

Au soir du 30 octobre, plusieurs publications sont apparues. D’abord, un nouvel article de 404 Media pour indiquer que les « réentretiens » n’auraient finalement pas lieu. Selon nos confrères, Andy Yen a confirmé ce changement lors d’une réunion interne, estimant que le débat avait servi le but poursuivi : que l’IA devienne un sujet actif et que les développeurs se lancent dans une formation personnelle.

Il faut également éteindre publiquement l’incendie. Sur X et LinkedIn, dans la nuit du 30 au 31 octobre, le compte officiel Proton a publié un long message pour aborder plusieurs points de tension. Ainsi, l’entreprise n’installerait aucun logiciel sur les postes des développeurs pour surveiller leur utilisation de l’IA, une rumeur qui proviendrait d’un « malentendu sur le fonctionnement des logiciels MDM », ces derniers étant destinés à gérer des parcs d’appareils de manière centralisée.

« Ensuite, notre utilisation de l’IA ne se fera jamais au détriment de la sécurité. Au cours de l’année écoulée, contrairement à ce qui a été allégué, des couches supplémentaires de révision de sécurité ont été ajoutées pour faire face à la menace posée par des IA hostiles qui scrutent le code open source de Proton à la recherche de vulnérabilités. Notre code est open source, et sa sécurité reste ouverte à la vérification de tous », affirme l’entreprise.

Proton dit également vouloir faire preuve de transparence. Elle veut « ouvrir le capot » pour montrer comment elle utilise l’IA en interne. Elle compte par exemple publier des informations sur ses outils et rendre leur code open source, « y compris sur des versions plus avancées de Lumo avec des capacités accrues, qui n’ont jamais été mises à disposition en dehors de l’entreprise ». Lumo est pour rappel le chatbot maison, qui doit permettre d’utiliser l’IA sans envoyer d’informations chez les grandes entreprises américaines.

La société suisse promet en outre de communiquer des informations sur la manière dont les révisions de code et de sécurité sont réalisées. Elle veut se montrer transparente sur ses politiques en IA, y compris les domaines dans lesquels elle est autorisée ou interdite. « Au lieu de pouvoir seulement voir le code open source final que nous produisons pour vérifier la sécurité, vous pourrez également évaluer comment ce code a été produit », ajoute Proton, qui confirme à nouveau que les employés ne seront pas réinterrogés sur leur utilisation de l’IA.

Oui, mais…

Bien que l’entreprise cherche à contrôler autant les dégâts que possible, on peut relever plusieurs problèmes. D’abord, son amende honorable n’a été publiée que sur deux réseaux sociaux, X et LinkedIn. Le texte n’a pas fait l’objet d’une communication plus officielle, sur le blog de l’entreprise par exemple.

Ensuite, les bonnes volontés de Proton ne sont accompagnées d’aucune date. L’éditeur s’engage donc sur plusieurs processus, mais sans calendrier.

Sur la présence d’un logiciel qui analyserait l’utilisation de l’IA, la situation reste floue. On se souvient que Brad Butler, directeur technique, a indiqué que 90 % du code produit en octobre avait été généré par IA (a priori par Claude). La mesure semble donc exister quelque part, peut-être au niveau de GitHub via la console de Copilot.

La promesse de transparence autour de Lumo devra également être confrontée à la réalité, car ce n’est pas la première fois que Proton s’engage sur ce sujet. L’European Open Source AI Index avait en effet critiqué en aout 2025 la présentation initiale de Lumo comme « open source ». Selon cet index, seuls les codes des applications mobile et web sont ouverts.

• Proton lance son assistant IA Lumo et déménage ses installations en Allemagne

Surtout, l’entreprise a désormais deux problèmes sérieux d’image. D’abord, sur son activité elle-même : Proton se présente depuis toujours comme l’alternative sécurisée aux grands groupes américains. Les extraits de conversations publiés par 404 Media ne vont pas exactement dans ce sens.

Ensuite, que ce soit sur X, Reddit ou LinkedIn, de nombreuses personnes remettent en question le rôle d’Andy Yen à la tête de l’entreprise, beaucoup appelant désormais à sa démission. Il est accusé d’avoir installé un climat délétère au sein de Proton, la course à la croissance et aux profits mettant en danger les fondements de l’offre logicielle. D’autres encore estiment que si l’IA est désormais incontournable, Andy Yen reste responsable de son utilisation forcée au point de mettre en danger les emplois et de ses insultes aux personnes qui réclament du temps pour tester le code produit.