Un signal d’alarme venu du cœur de Linux
Linus Torvalds n’a jamais eu la réputation d’enrober ses critiques. Sa dernière sortie sur l’intelligence artificielle, relayée par The Register, TechRadar, Tom’s Hardware et ZDNet, ne vise pourtant pas l’IA en tant que telle. Elle vise un usage précis : les rapports de vulnérabilités générés ou assistés par des outils d’IA, envoyés en masse à la liste de sécurité du noyau Linux, souvent sans vérification suffisante, sans correctif et avec beaucoup de doublons.
Le point de départ est un message de Torvalds publié le 17 mai 2026 dans l’annonce de Linux 7.1-rc4, archivée par LWN. Après les notes habituelles sur les pilotes, le réseau, les systèmes de fichiers et les architectures, le créateur de Linux s’arrête sur un sujet devenu explosif : selon lui, le flot continu de rapports IA a rendu la liste de sécurité « presque entièrement ingérable ». Le problème n’est pas seulement le volume, mais la répétition : différents chercheurs, utilisant les mêmes outils sur le même code, signalent les mêmes bogues, parfois déjà corrigés depuis des semaines.
Torvalds résume l’absurdité du mécanisme : une liste privée empêche les rapporteurs de voir que d’autres ont déjà signalé le même problème. Les mainteneurs passent donc leur temps à rediriger les messages vers les bons développeurs, à indiquer que le correctif existe déjà, ou à demander des précisions que certains auteurs ne sont pas capables de fournir. Dans cette mécanique, l’IA ne remplace pas le travail humain : elle déplace le coût vers les mainteneurs.
Une relation « amour-haine », mais pas un rejet
L’affaire serait facile à caricaturer : le vétéran du logiciel libre contre la nouvelle génération d’outils génératifs. Ce n’est pas ce que Torvalds dit. D’après TechRadar et ZDNet, qui rapportent ses propos à l’Open Source Summit North America, Torvalds décrit plutôt une relation d’« amour-haine » avec l’IA. Il la juge utile, intéressante, et même comparable, dans une certaine mesure, aux anciens sauts d’abstraction qui ont marqué la programmation : assembleurs, compilateurs, assistants modernes.
Sa formule la plus révélatrice est simple : l’IA est un excellent outil, mais elle reste un outil. Ce qui l’agace, ce sont les discours affirmant que 99 % du code serait écrit par l’IA, comme si la responsabilité intellectuelle du logiciel pouvait disparaître derrière une statistique marketing. Pour Torvalds, l’IA change la productivité, pas les fondamentaux : il faut comprendre le résultat, pouvoir le maintenir, le tester et l’expliquer.
Cette nuance est capitale. Dans le noyau Linux, l’IA n’est pas bannie. Les règles récentes du projet sur les assistants de codage prévoient même explicitement un usage acceptable : les contributions doivent respecter les exigences de licence, un humain doit signer le Developer Certificate of Origin, et l’assistance significative d’un outil doit être indiquée au moyen d’un tag « Assisted-by ». Autrement dit, Linux ne dit pas « pas d’IA » ; Linux dit « pas d’irresponsabilité ».
Le vrai bogue : l’absence de coût pour le bruit
Le cas de la liste de sécurité Linux illustre un problème plus large dans l’écosystème open source : l’IA abaisse radicalement le coût de génération d’un rapport plausible, mais elle ne baisse pas autant le coût de sa validation. Un message peut être produit en quelques secondes. Le vérifier peut prendre des heures.
Le noyau Linux a donc mis à jour sa documentation de sécurité. Elle insiste désormais sur plusieurs exigences : indiquer les versions affectées, vérifier que le problème existe encore sur une version récente, fournir une description technique, un reproducteur, les conditions de déclenchement et, idéalement, une proposition de correctif. La documentation précise aussi qu’un problème découvert par un outil largement disponible, et donc trivial à retrouver par d’autres, n’a pas nécessairement vocation à rester dans un canal privé.
C’est là que Torvalds touche un point sensible : si un bogue est trouvé par un outil IA accessible et reproductible, il est probablement déjà connu de plusieurs autres personnes ou susceptible de l’être très vite. Le traiter comme un secret rare, via une liste confidentielle, amplifie les doublons au lieu de protéger les utilisateurs. La bonne contribution n’est donc pas « mon IA a trouvé quelque chose » ; c’est « j’ai compris le problème, je l’ai reproduit, j’ai vérifié l’état du code, et voici une piste de correction ».
Linux n’est pas un cas isolé
Ce qui arrive au noyau Linux s’inscrit dans une tendance déjà visible ailleurs. Le projet curl, maintenu par Daniel Stenberg, a mis fin à son programme de primes aux bogues à la fin janvier 2026. Dans son billet, Stenberg explique que le taux de rapports confirmés est tombé sous les 5 % en 2025, après une explosion de rapports qualifiés d’« AI slop ». Le projet avait pourtant payé plus de 100 000 dollars de récompenses et confirmé 87 vulnérabilités depuis le lancement de son programme moderne en 2019.
L’Open Source Security Foundation a aussi ouvert un chantier public sur ces rapports IA de mauvaise qualité. L’initiative décrit une situation quasi « DDoS » pour les mainteneurs : beaucoup de volume, des rapports parfois rédigés avec assurance, mais peu de compréhension, peu de preuves et peu de disponibilité pour répondre aux questions. L’objectif de l’OpenSSF n’est pas d’interdire l’IA, mais d’établir des pratiques : responsabilité humaine, divulgation de l’usage des outils, pas d’agents autonomes ouvrant des contributions sans supervision, et même niveau d’exigence pour les contributions assistées.
Cette approche rejoint celle du noyau Linux. Le problème n’est pas qu’un outil trouve un bogue. Le problème est qu’un humain s’en serve pour externaliser son travail de validation vers une communauté déjà saturée.
L’IA peut aussi être une alliée de la sécurité
Il serait pourtant dangereux de tirer une conclusion simpliste : « l’IA nuit à la sécurité ». L’OpenSSF a accueilli OSS-CRS, issu de l’AI Cyber Challenge de la DARPA, comme infrastructure ouverte pour orchestrer des systèmes capables de trouver des vulnérabilités, confirmer des problèmes et proposer des correctifs. L’organisation souligne que ces systèmes peuvent produire des résultats concrets, mais insiste sur le rôle du contrôle humain : une revue manuelle de 630 correctifs générés par IA a montré qu’une proportion importante, entre 20 % et 40 %, était sémantiquement incorrecte malgré le passage de validations automatisées.
C’est exactement la tension que Torvalds incarne. L’IA est assez bonne pour produire des signaux utiles. Elle n’est pas assez fiable pour supprimer la responsabilité humaine. Entre ces deux pôles se trouve toute la difficulté de l’ingénierie logicielle moderne.
Les études sur les assistants de codage reflètent ce paradoxe. Des travaux de Microsoft Research sur GitHub Copilot ont montré des gains de productivité mesurables dans un cadre contrôlé. Mais d’autres recherches récentes sur le code généré par IA et les correctifs automatisés soulignent la persistance de vulnérabilités, d’erreurs de contexte et de correctifs apparemment valides mais réellement dangereux. En clair : l’IA accélère. Elle ne garantit pas la qualité.
La leçon pour l’industrie open source
La leçon principale n’est pas technique, elle est organisationnelle. Les projets open source ne manquent pas seulement d’outils ; ils manquent de bande passante humaine. Chaque rapport faible consomme une ressource rare : l’attention d’un mainteneur expérimenté. Dans les grands projets comme Linux, cette ressource est déjà sous pression. Dans les petits projets, elle peut disparaître en quelques semaines de surcharge.
L’industrie devra donc traiter les contributions assistées par IA comme une question de gouvernance. Cela implique des politiques explicites, des formulaires de signalement plus stricts, des exigences de reproductibilité, des seuils de qualité, des limites de fréquence et des mécanismes de réputation. Les plateformes de bug bounty et d’hébergement de code devront aussi porter une partie du coût : si elles encouragent la génération massive de rapports, elles doivent aider à filtrer, dédupliquer et responsabiliser les auteurs.
La contribution assistée par IA devrait devenir un contrat clair : l’outil peut suggérer, chercher, rédiger ou accélérer ; l’humain doit vérifier, comprendre, tester, corriger et répondre. Sans ce contrat, l’IA devient une machine à transférer du travail non payé vers les mainteneurs.
Le futur : moins de magie, plus de responsabilité
Torvalds ne ferme pas la porte à l’IA. Il rappelle simplement que le logiciel critique n’est pas une démonstration marketing. Dans le noyau Linux, un rapport n’a de valeur que s’il réduit l’incertitude. Un correctif n’a de valeur que s’il peut être défendu. Une contribution n’a de valeur que si quelqu’un en assume la responsabilité.
C’est probablement la ligne qui s’imposera dans l’open source mature : accepter l’IA comme multiplicateur de capacité, mais refuser qu’elle devienne un multiplicateur de bruit. La prochaine étape ne sera pas de savoir si les développeurs utilisent l’IA. Ils l’utiliseront. La vraie question sera : quelles communautés sauront transformer l’assistance algorithmique en contributions vérifiées, et lesquelles se laisseront submerger par des rapports plausibles, mais inutiles ?
La réponse de Torvalds est brutale, mais elle a le mérite d’être opérationnelle : si votre IA trouve un bogue, ne vous contentez pas d’envoyer une alerte. Comprenez-le. Reproduisez-le. Vérifiez qu’il n’est pas déjà corrigé. Écrivez un correctif si possible. Ajoutez de la valeur au-dessus de ce que la machine a produit. Dans l’open source, l’avenir de l’IA ne se jouera pas seulement dans les modèles, mais dans la qualité des humains qui les utilisent.