Linux : Linus Torvalds utilise Claude Code
Linus Torvalds a utilisé Claude Code pour un correctif du noyau Linux. Résultats, limites et implications : découvrez ce que cette expérience change vraiment.
Linus Torvalds confie une partie du code Linux à l'IA : ce que cela change vraiment
Linus Torvalds a utilisé Claude Code pour produire une série de correctifs destinés au noyau Linux. Le symbole est fort : un mainteneur très exigeant du logiciel libre passe par un assistant d'intelligence artificielle pour travailler sur du code système. Mais ce qui compte, ce n'est pas seulement l'outil. C'est le problème visé, les résultats chiffrés et les limites qu'il mentionne lui-même.
Les correctifs visent à réduire une contention dans le cache de pages de Linux, qui peut ralentir certains accès concurrents à de petits morceaux de fichiers. Dans un test précis, le débit a presque triplé avec huit threads. Attention toutefois : ce chiffre ne veut pas dire que Linux est devenu trois fois plus rapide partout. On parle d'une charge étroite, mesurée sur une machine donnée, avec des compromis de gestion mémoire à examiner.
En clair : cette expérience montre ce que l'IA peut apporter quand on lui confie un travail bien cadré, et aussi ce qu'elle ne peut pas « garantir » toute seule. On détaille le mécanisme technique, les résultats, les risques encore ouverts, et comment cela s'inscrit dans la manière de travailler de Torvalds.
Ce que Claude Code a contribué à produire
Dans sa soumission Git, Linus Torvalds indique que le code, les programmes de test, une revue préparatoire et une première version du texte de présentation ont été faits avec l'aide de Claude Code, sous sa direction. Autrement dit, ce n'est pas une histoire « on demande, on colle, et ça passe ». Torvalds décrit un travail assisté par un modèle, mais gardé sous contrôle humain.
C'est important dans un projet comme Linux. Un correctif ne se juge pas seulement au fait qu'il compile, ni à un benchmark isolé. Il doit s'intégrer à du code existant, respecter les règles de concurrence, se comporter correctement sur différentes architectures et rester maintenable par d'autres contributeurs. Donc l'auteur d'une proposition doit pouvoir expliquer ce qu'elle change, comment elle a été testée et quels risques persistent.
« Écrit avec l'IA » ne veut pas dire « validé par l'IA »
L'assistant a aidé sur plusieurs étapes, mais la responsabilité de la proposition reste entière. Torvalds a défini le problème, dirigé le travail et cadré les limites de la solution. On retrouve ce schéma dans d'autres outils de développement : un compilateur produit du code machine, un moteur de recherche aide à retrouver une implémentation, et un assistant peut suggérer ou modifier du code. Aucun de ces outils ne remplace la validation du résultat dans son contexte.
Dans des systèmes critiques, on ne peut pas s'en remettre à la confiance envers l'outil. Il faut relire les changements, tester les chemins concernés et comprendre les effets secondaires. Un correctif qui améliore un scénario peut en dégrader un autre. Ici, Torvalds signale un gain net sur des lectures concurrentes de petite taille, mais aussi une régression dans un cas lié à une page utilisateur qui n'est pas encore mappée.
La formulation la plus juste n'est donc pas « l'IA a écrit le correctif », mais plutôt : Claude Code a assisté la préparation d'une série de correctifs expérimentaux, sous la direction de Torvalds, et ces changements doivent encore être évalués selon les procédures habituelles du noyau.
Pourquoi le cas est remarquable
Ce qui rend l'annonce intéressante, c'est qu'elle porte sur du code nouveau pour le noyau, pas sur de la documentation ou un simple travail de recherche de bogue. Torvalds a déjà montré qu'il s'intéressait à l'IA pour aider à coder, relire et maintenir. Il a aussi insisté sur la prudence nécessaire quand on touche à des logiciels essentiels.
Pour autant, son approche n'est pas incohérente : un outil peut rendre certaines tâches plus rapides ou plus confortables, sans devenir une autorité technique. L'IA peut proposer une piste ; le fait que cette piste soit correcte reste une question d'ingénierie. Et dans un projet qui tourne sur des serveurs et toutes sortes de matériels, on ne peut pas abaisser la barre sous prétexte que « ça vient de quelque chose de plausible ».
La source de l'annonce et des détails techniques est l'article de ZDNET consacré à l'utilisation de Claude Code par Linus Torvalds.
Le goulot d'étranglement dans le cache de pages
Le correctif vise le cache de pages : une partie du noyau qui garde en mémoire des données issues de fichiers récemment utilisés. L'idée est classique : si la donnée est dans le cache, il n'y a pas besoin de relire sur le stockage, donc les accès deviennent plus rapides.
Le problème apparaît dans certains scénarios où plusieurs threads accèdent en même temps à de petites portions d'un même fichier déjà présent en mémoire.
Pour gérer ces données, Linux s'appuie notamment sur des folios, des unités de mémoire qui regroupent une ou plusieurs pages. Dans le chemin décrit, les threads prennent puis libèrent des références vers le folio. La mise à jour du compteur de références doit être atomique : plusieurs cœurs ne peuvent pas modifier cette donnée partagée en parallèle « chacun de leur côté ».
Quand les cœurs se disputent une même ligne de cache
Une opération atomique sur une donnée partagée oblige les cœurs à se coordonner. Quand plusieurs processeurs veulent modifier la même ligne de cache, le processeur doit gérer la cohérence : le travail utile (lire quelques octets) peut alors devenir minoritaire par rapport au coût de synchronisation pour accéder aux métadonnées.
Ce genre de déséquilibre passe parfois sous le radar. Une opération de comptage ressemble à quelque chose de léger. Mais si elle se répète très souvent, au même endroit en mémoire, et depuis plusieurs cœurs, elle finit par créer une vraie contention. Et le coût ne vient pas forcément d'une fonction « lourde » ou d'un algorithme manifestement inefficace : il peut émerger du fait que plusieurs threads font la même chose en même temps.
Dans le test rapporté, huit threads font des appels pread() de 16 octets sur la même page, sur un ordinateur portable équipé d'un Intel Core i7-8565U à quatre cœurs et huit threads. Les mesures de lignes de cache modifiées partagées, avec l'indicateur HITM, attribuent 99,92 % des accès inter-cœurs à la ligne concernée. C'est un test très ciblé : ça ne décrit pas automatiquement les performances de « Linux en général ».
Le principe du correctif proposé
La série de correctifs change le moment où la mémoire retirée du cache de pages peut être réutilisée. Au lieu de la rendre immédiatement à l'allocateur, la réutilisation est retardée jusqu'à ce qu'une période de grâce RCU soit terminée.
RCU, pour read-copy-update, est un mécanisme de synchronisation utilisé dans le noyau. Il permet à certains lecteurs d'accéder à des structures sans prendre systématiquement un verrou lourd, en décalant la récupération de la mémoire jusqu'à ce que les lecteurs concernés aient fini. Dans cette proposition, le délai aide le chemin de lecture protégé par RCU à copier les données directement dans un tampon utilisateur sans prendre une référence au folio à chaque opération.
Le compromis est celui qu'on rencontre souvent en optimisation : on réduit le coût sur le chemin le plus fréquent, mais on reporte une partie du travail à plus tard. Ici, on cherche à éviter les mises à jour répétées du compteur partagé pendant les lectures. En contrepartie, les pages ne deviennent pas immédiatement disponibles pour être réaffectées. Donc l'amélioration d'un chemin se paye par une contrainte supplémentaire sur la gestion de la mémoire.
Des gains mesurés, mais des compromis non résolus
Les chiffres annoncés sont convaincants dans le test concerné. Avec huit threads, le débit passe d'environ 9,9 à 10,4 millions de lectures par seconde, puis à quelque 30 à 33 millions (selon la mesure détaillée dans le billet de correction). Le nombre de cycles processeur par lecture descend d'environ 2 950 à 725. En mono-thread, l'amélioration reste plus faible : on passe d'environ 452 à 454 cycles par lecture à 408 à 409.
Ces résultats cadrent bien avec l'idée du correctif : quand plusieurs threads se disputent la même ligne de cache, réduire les mises à jour partagées peut libérer du temps processeur. En revanche, le gain mono-thread limité rappelle que ce n'est pas « toutes les lectures de fichiers » qui gagnent, mais surtout la forme de contention observée dans ce scénario.
Ce que les benchmarks permettent de conclure
On peut retenir deux points : sur cette machine et cette charge, le nouveau chemin améliore fortement le débit de lectures concurrentes de 16 octets sur une même page ; dans ces mesures, le coût par lecture baisse aussi. Et c'est suffisant pour justifier d'autres tests et une revue plus poussée.
Ce qu'on ne peut pas conclure : que Linux dans son ensemble sera « trois fois plus rapide », que toutes les applications profiteront du changement, ni que le correctif est prêt à être intégré sans discussion. Les performances dépendent du matériel, du nombre de cœurs, de la configuration des sockets, du type de charge et de ce que les applications font vraiment. Torvalds le souligne aussi : une machine avec plus de processeurs, ou plusieurs sockets, pourrait donner un autre ordre de grandeur. Il indique en plus que des mesures plus larges n'ont pas été faites.
Ce n'est pas une simple réserve de langage. Ça change la lecture de l'annonce. Un benchmark étroit sert à isoler un mécanisme et à vérifier une hypothèse : il ne remplace pas une campagne de validation sur d'autres machines, d'autres usages et sur les effets côté système.
Le coût de la mémoire différée
Le point le plus important reste la récupération des pages. En retardant la réutilisation jusqu'à la fin de la grâce RCU, le noyau peut garder de la mémoire « indisponible » plus longtemps. Le correctif ne supprime donc pas un coût : il déplace le compromis entre rapidité du chemin de lecture et moment où la mémoire peut être réaffectée.
Torvalds décrit ce segment comme la partie la moins résolue de la série. C'est un signal à prendre au sérieux : une optimisation peut être acceptable dans certains contextes, mais poser problème quand la pression mémoire est forte.
Il y a aussi une autre régression rapportée : dans un cas où la lecture vise une page utilisateur qui n'est pas encore mappée, le nouveau chemin déclenche une exception infructueuse supplémentaire avant de revenir à l'implémentation existante. Même si ce cas semble moins fréquent que le chemin optimisé, il doit être compris et mesuré. Les correctifs bas niveau s'évaluent sur un ensemble de comportements, pas sur un seul benchmark.
Au 13 octobre mentionné dans la source, la branche n'était pas encore présente dans la version principale de Linux 7.3-rc6. L'intégration éventuelle, et son calendrier, restaient donc incertains. Il faut donc parler d'une proposition prometteuse mais encore expérimentale, pas d'une fonctionnalité déjà déployée.
Ce que l'expérience dit de l'IA en développement
L'évolution de Torvalds ne tient pas en une bascule « contre » vers « pour ». Il a commencé par voir l'IA comme un outil pour aider les développeurs : repérer des bogues, accélérer certaines tâches de maintenance. Puis son intérêt s'est élargi à la revue de code et à l'aide à la programmation, d'abord sur un projet personnel avant d'envisager une proposition liée au noyau.
Ce qu'on apprend ici dépasse le débat abstrait « l'IA aide-t-elle ou non ? ». En pratique, la valeur d'un assistant dépend de la tâche, de la qualité de la vérification et du coût d'une erreur. Générer un prototype de visualiseur audio personnel et proposer une modification de la gestion mémoire d'un noyau n'impliquent pas les mêmes risques ni les mêmes exigences de validation.
Un assistant utile quand le problème est bien cadré
Dans ce cas, l'outil intervient sur une tâche assez clairement définie : explorer une optimisation de performance, produire des tests et aider à préparer une série de correctifs. Le gain potentiel n'est pas uniquement « écrire plus vite ». Un assistant peut aider à parcourir plusieurs pistes, formaliser des variantes et rendre une première exploration moins coûteuse.
Mais cette accélération ne marche que si la personne sait faire la différence entre « ça ressemble à une bonne idée » et « c'est correct ». En particulier en bas niveau, où des erreurs de concurrence peuvent être rares, dépendantes du matériel, et difficiles à reproduire, l'expertise humaine reste nécessaire pour définir les invariants, choisir les tests et interpréter les résultats. Et un code qui a l'air plausible n'est pas une preuve de sûreté.
Pour une équipe française ou européenne, la méthode peut être concrète : cadrer précisément les entrées envoyées à l'outil, vérifier les règles de confidentialité du service utilisé, soumettre les changements à une revue indépendante, et conserver des tests reproductibles. Les contraintes de propriété intellectuelle, de sécurité et de conformité ne disparaissent pas parce que l'outil accélère la production.
La responsabilité ne se délègue pas au modèle
La leçon pratique n'est pas « laissez l'IA écrire le code ». C'est plutôt : utilisez-la là où elle peut aider (exploration, génération de tests, documentation, revue ou écriture assistée), mais imposez un niveau de contrôle proportionné à l'impact possible d'une erreur. Pour un changement à faible risque, une revue standard peut suffire. Pour un changement au niveau du noyau, il faut des tests, une analyse des régressions et un échange clair sur les compromis.
Le travail présenté par Torvalds illustre bien cette logique : les gains sont situés dans un périmètre, et les limites sont nommées avant qu'elles deviennent des « détails secondaires ». On a donc une base plus crédible pour évaluer l'apport réel de l'IA que de se limiter à compter des lignes de code ou du temps économisé.
Au final, la vraie question pour les développeurs n'est pas « est-ce que l'IA remplace le métier ? ». C'est plutôt : quelles étapes peut-on confier sans affaiblir le contrôle - et à quoi doit ressembler cette vérification. La réponse dépend du produit, du contexte réglementaire et du coût d'une défaillance. Mais dans tous les cas, la responsabilité revient à l'équipe qui livre le code.
Conclusion : un outil de plus, pas une validation automatique
Le recours à Claude Code par Linus Torvalds est une étape symbolique : l'IA entre désormais dans l'exploration de code pour un logiciel aussi critique que le noyau Linux. Ce qui rend le cas intéressant, c'est qu'il ne s'arrête pas à une démonstration. On a des gains mesurés sur une charge ciblée, et aussi des questions concrètes sur la mémoire, les régressions et l'intégration.
La conclusion pratique tient en peu de choses : oui, l'IA peut aider à faire de l'ingénierie sérieuse. Mais elle ne rend pas la validation « moins nécessaire ». Au contraire, plus le système est critique, plus il faut savoir ce qui a été mesuré, ce qui n'a pas été testé, et qui assume la décision finale.
Si vous évaluez des assistants de code dans votre équipe, commencez par un problème bien délimité, mesurez ce qui change, et imposez une revue adaptée au risque. C'est moins spectaculaire que la promesse de « code autonome », mais c'est souvent comme ça qu'un outil devient vraiment utile.