Linus Torvalds valide les règles du code IA pour Linux : la responsabilité incombe à l'humain

Linus Torvalds et les mainteneurs de Linux ont adopté les premières règles officielles pour le code écrit avec l'aide de l'IA. La politique n'interdit ni Copilot, ni Claude, ni d'autres outils, mais rend l'humain entièrement responsable de chaque ligne, de chaque bug et de chaque risque de licence.

Ce qui change

La documentation du noyau comporte désormais une section dédiée, AI Coding Assistants. L'équipe Linux y reconnaît formellement que les développeurs utiliseront de toute façon des outils génératifs ; il importe donc davantage au projet de fixer des règles claires que d'imposer des interdictions symboliques.

Le principe de base est simple : l'IA est un outil, pas un auteur. Tout patch qui entre dans le noyau doit donc continuer à passer par le processus habituel de relecture, de discussion et de vérification manuelle.

Les nouvelles règles exigent que tout le code reste compatible avec la licence GPL-2.0-only et que les fichiers utilisent des identifiants SPDX corrects. Elles précisent aussi qu'un agent IA n'a pas le droit d'ajouter un Signed-off-by : cette balise est liée au Developer Certificate of Origin et constitue une attestation juridique émanant d'un humain. Seul un développeur en chair et en os peut signer un tel patch, et c'est lui qui assume l'entière responsabilité de la contribution.

Comment soumettre des patchs désormais

En pratique, pour les développeurs, il ne s'agit pas d'une révolution mais d'une couche de transparence supplémentaire. Le simple fait d'utiliser l'IA n'est plus considéré comme une infraction, à condition que la personne puisse expliquer ce que l'outil a fait exactement et comment le résultat a été vérifié.

Autrement dit, un modèle peut aider à écrire un patch ou une description, mais ne peut pas remplacer l'auteur, qui comprend le code, le teste et est prêt à défendre les modifications devant les mainteneurs.

• Relire manuellement tout le code généré, sans se fier à la sortie du modèle
• S'assurer que les fragments ne violent pas les exigences de licence du noyau
• Ajouter son propre Signed-off-by, en attestant le DCO au nom d'un humain
• Indiquer Assisted-by avec le nom de l'outil et la version du modèle
• Ne pas faire passer pour une contribution de l'IA des outils ordinaires comme git, gcc, make ou un éditeur

Cette approche n'est pas sortie de nulle part. Des mois de débats autour de l'« AI slop » et de la qualité des patchs envoyés par des personnes qui comprennent à peine ce que le modèle a généré ont conduit à figer ces règles. Les cas où la participation de l'IA n'était pas révélée d'emblée ont fait particulièrement réagir : le patch ressemblait au travail ordinaire d'un développeur expérimenté, mais on découvrait ensuite qu'une part importante du texte et du code avait été écrite par un LLM.

Le principal problème non résolu

Malgré son aspect pratique, la nouvelle politique ne lève pas la question la plus délicate : l'origine du code. La documentation demande à l'humain de vérifier la pureté de licence de la sortie de l'IA, mais ne fournit aucun moyen de prouver d'où vient précisément une ligne donnée. Si un modèle génère un fragment trop proche d'un code tiers sous des conditions incompatibles, la mention Assisted-by ne réglera pas le problème. L'expéditeur du patch restera responsable, même s'il ne peut matériellement pas retracer tout le parcours d'entraînement du modèle.

Il existe une seconde faille : la politique aide très peu contre les auteurs de mauvaise foi. Torvalds a dit clairement que la documentation est écrite pour les participants de bonne foi, et que ceux qui envoient du code poubelle ne le signaleront pas honnêtement comme généré par IA. Autrement dit, Linux n'a pas choisi l'interdiction mais la responsabilité personnelle : si le code est bon, il sera examiné ; s'il s'agit d'une hallucination, d'une régression ou d'un patch mal compris, celui qui a appuyé sur envoyer devra en répondre.

«

La documentation est faite pour les participants de bonne foi », a expliqué Torvalds à propos de son approche des patchs IA.

Ce que cela signifie

Linux n'a pas déclaré la guerre aux outils d'IA et n'a pas fait semblant que le problème n'existait pas. Le projet a choisi un modèle adulte : on peut utiliser l'IA, on ne peut pas la dissimuler, on ne peut pas signer à la place du modèle, et les conséquences juridiques et techniques incombent à l'humain.

Pour toute l'industrie de l'open source, c'est un signal important : la prochaine grande querelle ne portera pas sur l'autorisation de l'IA, mais sur la manière de prouver l'origine et la qualité du code généré.