ZDNet AI→ original

Linus Torvalds a validé les règles du code AI pour Linux : la responsabilité incombe à l'humain

Linux a pour la première fois fixé des règles pour le code AI dans le noyau : l'usage de Copilot, Claude et d'autres outils est autorisé, mais uniquement…

Traité par IA depuis ZDNet AI ; édité par Hamidun News
Linus Torvalds a validé les règles du code AI pour Linux : la responsabilité incombe à l'humain
Source : ZDNet AI. Collage: Hamidun News.
◐ Écouter l'article

Linus Torvalds et les mainteneurs de Linux ont établi les premières règles officielles pour le code écrit avec assistance IA. La politique n'interdit pas Copilot, Claude et autres outils, mais place l'entière responsabilité sur l'humain pour chaque ligne, bug et risque de licence.

Ce Qui a Changé

Une nouvelle section sur les Assistants de Codification IA est apparue dans la documentation du noyau. L'équipe Linux reconnaît formellement que les développeurs utiliseront les outils génératifs de toute façon, donc le projet considère qu'il est plus important d'établir des règles claires que d'imposer des interdictions symboliques. Le principe de base est simple : l'IA est considérée comme un outil, pas un auteur. Cela signifie que tout patch entrant dans le noyau doit toujours passer par le processus normal d'examen, de discussion et de vérification manuelle.

Les nouvelles règles exigent que tout code reste compatible avec la licence GPL-2.0-only, et que les fichiers utilisent les identificateurs SPDX corrects. Séparément, il est stipulé qu'un agent IA n'a pas le droit d'ajouter une étiquette Signed-off-by : cette étiquette est liée au Developer Certificate of Origin et représente une confirmation juridique d'un humain. Seul un développeur réel peut signer un tel patch, et lui seul assume l'entière responsabilité de la contribution.

Comment Soumettre des Patches Maintenant

Pour les développeurs en pratique, cela signifie non pas une révolution, mais une couche supplémentaire de transparence. En soi, le fait d'utiliser l'IA n'est plus considéré comme une violation si une personne peut expliquer ce que l'outil a fait et comment le résultat a été vérifié. En bref, 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 avant les mainteneurs.

  • Vérifier manuellement tout code généré plutôt que de faire confiance à la sortie du modèle
  • S'assurer que les fragments ne violent pas les exigences de licence du noyau
  • Ajouter votre propre Signed-off-by, confirmant le DCO au nom d'un humain
  • Spécifier Assisted-by avec le nom de l'outil et la version du modèle
  • Ne pas présenter les contributions IA comme des outils ordinaires comme git, gcc, make ou des éditeurs

Cette approche n'est pas venue de nulle part. La raison d'établir fermement ces règles a été des mois de débat autour du "AI slop" et de la qualité des patches soumis par des personnes ayant une compréhension minimale de ce que le modèle avait réellement généré. Une controverse particulière a surgi quand la participation de l'IA n'a pas été divulguée immédiatement : formellement, un patch ressemblait à un travail ordinaire d'un développeur expérimenté, mais plus tard il s'est avéré que des portions importantes de texte et de code avaient été écrites par un LLM.

Le Principal Problème Non Résolu

Malgré son caractère pratique, la nouvelle politique ne résout pas la question la plus inconfortable : la provenance du code. La documentation exige qu'une personne vérifie la propreté des licences de la sortie IA, mais ne fournit aucun moyen de prouver d'où vient une ligne spécifique. Si un modèle a généré un fragment trop similaire au code d'une autre personne avec des conditions incompatibles, l'étiquette Assisted-by ne résoudra pas le problème. L'expéditeur du patch reste responsable même s'il ne peut physiquement pas retracer l'ensemble du chemin d'entraînement du modèle.

Il y a une deuxième faille : la politique aide à peine à lutter contre les auteurs malhonnêtes. Torvalds a directement dit que la documentation est écrite pour les participants de bonne foi, et les gens qui envoient du code poubelle ne marqueront pas honnêtement comme généré par l'IA. En d'autres termes, Linux a choisi non pas un chemin d'interdiction, mais un chemin de 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, la personne qui a appuyé sur envoi en est responsable.

«

La documentation est nécessaire pour les participants de bonne foi », a expliqué Torvalds son approche des patches IA.

Ce Que Cela Signifie

Linux n'a pas déclaré la guerre aux outils IA et n'a pas fait semblant que le problème n'existe pas. Le projet a choisi un modèle adulte : l'IA peut être utilisée, mais ne peut pas être cachée, ne peut pas signer les patches, et les conséquences juridiques et techniques reposent sur l'humain. Pour toute l'industrie open source, c'est un signal important : le prochain grand débat ne sera pas sur la permission de l'IA, mais sur la façon de prouver la provenance et la qualité du code généré.

ZK
Hamidun News
Actualités IA sans bruit. Sélection éditoriale quotidienne de plus de 400 sources. Produit de Zhemal Khamidun, Head of AI chez Alpina Digital.

Vous voulez cesser de lire sur l'IA et commencer à l'utiliser?

AI News est un fil d'actualité IA. Hamidun Academy vous apprend à utiliser l'IA dans votre travail.

Qu'en pensez-vous ?
Chargement des commentaires…