Linus Torvalds assume l'IA dans le noyau Linux : l'IA écrit, un humain signe

Le 9 août 2026, en publiant la septième version candidate de Linux 7.2, Linus Torvalds a lâché une phrase qui résume l'année du noyau Linux : ce volume de correctifs, c'est la nouvelle normalité, et il vient en grande partie de la relecture par des outils IA. Le créateur et mainteneur en chef du noyau ne s'en réjouit pas particulièrement. Il constate.

Moins de deux ans plus tôt, le même homme expliquait que l'IA était « 90 % de marketing et 10 % de réalité ». Entre les deux, le projet a fait quelque chose que beaucoup d'équipes produit repoussent encore : il a arrêté de débattre pour savoir si l'IA avait le droit d'écrire du code, et il a écrit noir sur blanc qui en répond. Cette règle tient en quelques lignes, elle est publique, et elle est transposable à peu près partout.

Ce que Torvalds vient d'acter

Deux annonces successives ont posé le décor. Le 2 août 2026, la sixième version candidate de Linux 7.2 sortait avec un volume inhabituel : selon Phoronix, site spécialisé dans le suivi du noyau Linux, Torvalds la qualifiait de plus grosse rc6 depuis des années en nombre de commits. Une semaine plus tard, la rc7 confirmait la tendance : beaucoup de petits correctifs, éparpillés dans les pilotes, les systèmes de fichiers et le code d'architecture, sans gros morceau isolé pour expliquer le total.

La publication tech britannique The Register a relayé le commentaire de Torvalds sur cette rc7 : il ne se dit pas enchanté par la taille de l'ensemble, mais c'est ainsi, la nouvelle normalité, avec beaucoup de correctifs dont une bonne partie provient de la relecture par divers outils IA. Autrement dit, l'IA ne fait pas qu'écrire du code dans le noyau : elle relit celui des autres à grande échelle, elle remonte des défauts que personne n'avait vus, et le travail humain de validation qui en découle est devenu un poste de charge permanent.

De « 90 % de marketing » à « ceux que ça dérange peuvent forker »

La bascule n'a pas été instantanée. En octobre 2024, en marge de l'Open Source Summit Europe à Vienne, Torvalds déclarait détester le cycle de hype au point de ne pas vouloir y aller, et estimait l'industrie de l'IA à 90 % de marketing pour 10 % de réalité. Propos rapportés le jour même par The Register et confirmés par Tom's Hardware, média américain spécialisé dans le matériel et les technologies.

Première inflexion en janvier 2026 : un développeur du noyau proposait de durcir la documentation contre le code de mauvaise qualité produit par IA. Torvalds a coupé court, jugeant qu'il n'y avait aucun intérêt à en faire un sujet et que la documentation du projet s'adressait aux gens de bonne foi, pas à une posture. L'épisode est documenté par The Register et repris par PC Gamer.

Puis vient juillet 2026. Un fil de discussion sur la liste de développement du noyau oppose des contributeurs autour des outils de relecture de code assistés par IA. Torvalds tranche, et la formule fait le tour du secteur :

« Je sais que certains détestent vraiment l'IA, mais c'est un domaine où je suis prêt à taper du poing sur la table en tant que mainteneur principal. Linux n'est pas un de ces projets anti-IA, et si quelqu'un a un problème avec ça, il peut faire ce qu'on fait en open source : forker le projet. Ou simplement partir. »

Il ajoute que dans la communauté du noyau, on fait de l'open source parce que ça produit une meilleure technologie, pas pour des raisons quasi religieuses, et que les décisions se prennent sur le mérite technique, pas sur la peur des nouveaux outils. Ces propos sont rapportés par The Register le 15 juillet 2026 et repris presque mot pour mot par The New Stack, publication spécialisée dans les pratiques de développement, le lendemain.

La règle du noyau : l'IA écrit et relit, un humain déclare et signe

Ce qui rend la position de Torvalds opérationnelle plutôt que rhétorique, c'est qu'elle s'appuie sur une règle écrite. La documentation officielle du projet Linux consacre désormais une page aux assistants de code IA, à l'intérieur du processus de contribution existant, sans charte séparée ni comité dédié. Elle dit trois choses simples.

D'abord, un assistant n'envoie jamais un correctif lui-même : la procédure décrite s'arrête à la remise du résultat à un humain, qui relit avant toute soumission. Ensuite, quand un outil IA a participé (rédaction, analyse via des outils d'inspection de code comme coccinelle, sparse, smatch ou clang-tidy), la contribution porte une étiquette Assisted-by qui nomme l'outil et sa version. C'est de la traçabilité pure : on sait ce qui a aidé à produire le patch. Enfin, cette étiquette n'engage personne juridiquement. Seule l'étiquette Signed-off-by le fait, et le texte est catégorique : les agents IA ne doivent pas ajouter de Signed-off-by, parce que seuls des humains peuvent certifier légalement le Developer Certificate of Origin, l'attestation d'origine que signe tout contributeur du noyau.

La documentation détaille alors ce que la personne qui soumet le code prend sur elle : relire l'intégralité du code généré par IA, vérifier la conformité aux licences, apposer sa propre signature et assumer la pleine responsabilité de la contribution. Le partage est net. La machine produit et documente sa participation, l'humain valide et engage son nom.

Le revers assumé : quand l'IA sature la liste de sécurité

Assumer l'IA ne veut pas dire tout accepter, et c'est la nuance qui rend cette histoire utile. En mai 2026, Torvalds constatait publiquement que le flot continu de rapports générés par IA avait rendu la liste de sécurité du noyau quasi ingérable. Le mécanisme est bête : des chercheurs indépendants passent les mêmes outils sur le même code, trouvent les mêmes failles, et les signalent en double sur une liste privée où personne ne voit ce qui a déjà été remonté. Les mainteneurs passent leur temps à réorienter des messages ou à répondre que le problème est corrigé depuis des semaines. L'épisode est rapporté par The Register et Tom's Hardware.

Sa demande n'a pas été d'arrêter d'utiliser l'IA. Elle a été d'ajouter de la valeur humaine par-dessus la détection automatisée : vérifier, proposer un correctif, ne pas se contenter de transmettre une sortie d'outil. Deux mois avant le « ceux que ça dérange peuvent forker », le même mainteneur critiquait donc frontalement un usage mal cadré de l'IA. Ce n'est pas une conversion, c'est un cadrage.

Ce que ça change pour une équipe qui laisse déjà des agents IA travailler

Si des agents IA ouvrent déjà des pull requests chez vous, relisent du code ou rédigent de la documentation, le noyau Linux vient de vous fournir un précédent solide et gratuit. Le débat interne « est-ce qu'on autorise l'IA » se referme, parce que l'un des projets les plus scrutés de l'open source y a répondu. Reste la question qui compte vraiment, et elle est de gouvernance des agents IA, pas d'outillage.

Trois enseignements se transposent directement. Le premier : séparer la traçabilité de la responsabilité. Savoir quel outil et quelle version ont produit un bout de code est une information de journal, utile pour comprendre une régression six mois plus tard ; elle n'a rien à voir avec le fait de désigner une personne qui répond du code livré. Confondre les deux, c'est se retrouver avec une production dont personne n'est comptable.

Le deuxième : inscrire la règle dans le processus existant. Linux n'a pas créé de charte IA, ni de comité. La politique vit dans la documentation de contribution, au même endroit que le reste, sous forme d'une étiquette dans le message de commit, au même titre qu'une étape de la chaîne d'intégration continue. C'est ce qui la rend applicable. Une règle qui vit dans un document séparé que personne n'ouvre ne produit aucun effet, comme le rappelle n'importe quel audit et étude de cadrage sur un projet existant.

Le troisième est le plus concret, et c'est celui que la taille des dernières versions candidates illustre : l'IA déplace le goulot d'étranglement vers la relecture humaine. Plus de code proposé, plus de bugs signalés, plus de correctifs à valider. Si la capacité de relecture ne suit pas, le gain de vitesse à l'écriture se transforme en file d'attente, exactement comme sur la liste de sécurité du noyau en mai. La question à se poser n'est donc pas « combien de code l'IA nous fait-elle gagner » mais « qui a le temps et la légitimité de valider ce qu'elle produit ». C'est une question d'organisation, que nous croisons chez Koul dès que des agents IA rejoignent une équipe de développement et se mettent à ouvrir des tickets et des pull requests comme un coéquipier de plus.

Chez Koul, l'IA écrit, notre expertise valide

Nous ne regardons pas cette histoire depuis l'extérieur. Chez Koul, l'IA fait partie de notre manière d'écrire du code au quotidien : elle accélère la rédaction, propose des correctifs, repère des angles morts. Mais elle ne signe rien.

Ce qui part en production passe par une relecture humaine, faite par des développeurs qui savent lire ce que l'IA a produit et juger si c'est bon. C'est cette expertise technique, pas l'outil, qui reste le vrai gage de qualité, exactement comme dans le noyau Linux.

Pour aller plus loin

• Automatisation et IA : cadrer l'usage des agents dans vos équipes.
• Shadow AI en entreprise : le risque inverse, l'IA utilisée sans être déclarée ni tracée.
• Installer et configurer Hermes Agent : ce que donne un agent IA branché sur un vrai dépôt.
• Reprise et modernisation : remettre à niveau un projet existant avec une gouvernance IA claire.
• Notre méthode : comment nous cadrons un projet avant d'écrire la première ligne.

Linux 7.2 doit sortir en version stable le 16 août 2026, sauf imprévu. Le vrai livrable de l'année, pour tous les autres, tient peut-être moins dans le code que dans cette phrase de la documentation du projet : un agent IA n'a pas le droit de signer.