IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Linus Torvalds fustige les rapports de bogues générés par l'IA qui perturbent le développement du noyau Linux avec la version 7.1 RC4, notamment un flot chaotique de rapports en double générés par l'IA

Le , par Alex

18PARTAGES

3  0 
Linus Torvalds fustige les rapports de bogues générés par l'IA qui perturbent le développement du noyau Linux avec la version 7.1 RC4, notamment un flot chaotique de rapports en double générés par l'IA

Linus Torvalds met en garde contre le fait que les rapports de bogues générés par l'IA submergent la liste de diffusion sur la sécurité Linux de doublons et de bruit. La liste de diffusion sur la sécurité Linux est désormais « presque totalement ingérable », a averti le responsable principal Linus Torvalds. « Le flot continu de rapports générés par l'IA a rendu la liste de sécurité pratiquement ingérable, avec d'énormes doublons dus au fait que différentes personnes trouvent les mêmes choses avec les mêmes outils », a-t-il déclaré. Torvalds a souligné que ces rapports constituent « un gaspillage de temps totalement inutile », car la plupart des bogues détectés par les outils d’IA sont « par définition, loin d’être secrets », et que les signaler « ne fait qu’aggraver les doublons ».

Le noyau Linux est un noyau libre et open source de type Unix utilisé dans de nombreux systèmes informatiques à travers le monde. Le noyau a été créé par Linus Torvalds en 1991 et a rapidement été adopté comme noyau du système d'exploitation GNU, conçu pour remplacer librement Unix. Depuis la fin des années 1990, il est intégré à de nombreuses distributions de systèmes d'exploitation, dont beaucoup sont appelées Linux. Android, utilisé dans de nombreux appareils mobiles et embarqués, est l'un de ces systèmes d'exploitation basés sur le noyau Linux.

Linus Benedict Torvalds, né le 28 décembre 1969, est un ingénieur logiciel finlandais et américain, créateur et développeur principal du noyau Linux depuis 1991. Il a également créé le système de contrôle de version distribué Git. Torvalds a été l'un des lauréats du Prix Millennium Technology 2012 « en reconnaissance de sa création d'un nouveau système d'exploitation open source pour ordinateurs ayant conduit au noyau Linux largement utilisé ». En 2006, environ 2 % du noyau Linux avait été écrit par Torvalds. Malgré les milliers de personnes qui y ont contribué, son pourcentage reste l'un des plus élevés. Cependant, il a déclaré en 2012 que sa contribution personnelle consistait désormais principalement à fusionner du code écrit par d'autres, avec peu de programmation. Il conserve la plus haute autorité pour décider quel nouveau code est intégré au noyau Linux standard.


Les mainteneurs jouent un rôle essentiel dans l'univers de l'open source. Ces bénévoles consacrent leur temps et leur expertise à maintenir des projets utilisés par des millions de personnes à travers le monde. Pourtant, un phénomène inquiétant perturbe leur travail : une multiplication des rapports de bogues de mauvaise qualité générés par des intelligences artificielles (IA). Les soumissions de vulnérabilités logicielles générées par des modèles d'IA ont inauguré une « nouvelle ère de rapports de sécurité bâclés pour l'open source » et les développeurs qui maintiennent ces projets souhaiteraient que les chasseurs de bogues s'appuient moins sur les résultats produits par les assistants d'apprentissage automatique.

Seth Larson, développeur de sécurité en résidence à la Python Software Foundation, avait notamment exhorté les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. En 2024, il a déclaré : « Récemment, j'ai remarqué une augmentation des rapports de sécurité de qualité extrêmement médiocre, spammés et hallucinés par LLM dans les projets open source. Ces rapports semblent à première vue potentiellement légitimes et nécessitent donc du temps pour être réfutés ». Larson a estimé que les rapports de mauvaise qualité doivent être traités comme s'ils étaient malveillants.

Récemment, Linus Torvalds a fait des déclarations similaires. En effet, la liste de diffusion sur la sécurité Linux est désormais « presque totalement ingérable », depuis que les chercheurs ont commencé à utiliser l’IA pour l’inonder de rapports inutiles, a averti le responsable principal Linus Torvalds. Après avoir qualifié la dernière version candidate de « relativement normale » dans son dernier billet hebdomadaire sur l’état du noyau, abordant des sujets tels que les pilotes, la mise en réseau, le noyau central et bien d’autres, Torvalds a souligné que « certaines mises à jour de la documentation mériteraient d’être mises en avant ».

« Le flot continu de rapports générés par l'IA a rendu la liste de sécurité pratiquement ingérable, avec d'énormes doublons dus au fait que différentes personnes trouvent les mêmes choses avec les mêmes outils », a-t-il déclaré. « Les gens passent tout leur temps à simplement transférer des informations aux bonnes personnes ou à dire « cela a déjà été corrigé il y a une semaine/un mois » et à renvoyer vers la discussion publique ». Torvalds a souligné que ces rapports constituent « un gaspillage de temps totalement inutile », car la plupart des bogues détectés par les outils d’IA sont « par définition, loin d’être secrets », et que les signaler « ne fait qu’aggraver les doublons ».

Au-delà de ses critiques, Torvalds a également donné quelques conseils concrets, invitant les chercheurs à utiliser l’IA « d’une manière productive et qui améliore l’expérience » : « La documentation est peut-être un peu moins directe que moi, mais c’est l’essentiel », a-t-il conclu. « Si vous voulez vraiment apporter une valeur ajoutée, lisez la documentation, créez aussi un correctif, et ajoutez une réelle valeur *en plus* de ce que l’IA a fait. Ne soyez pas le genre de personne qui passe en coup de vent pour « envoyer un rapport au hasard sans véritable compréhension ». »

Cette déclaration rappelle un rapport de CodeRabbit, qui a révélé que le code généré par l'IA présente nettement plus de défauts que le code écrit par des humains dans les principales catégories de qualité logicielle. Le rapport a révélé que les pull requests générées par l'IA contiennent en moyenne environ 1,7 fois plus de problèmes que celles écrites uniquement par des humains. Il a également identifié des taux plus élevés de défauts critiques et majeurs dans le code impliquant des outils d'IA.


Voici la déclaration de Linus Torvalds :

Vous connaissez tous la chanson désormais : une nouvelle semaine, une nouvelle version candidate.

La situation semble rester relativement normale (où « normale » désigne la « nouvelle normalité », avec tout de même pas mal de changements). Les pilotes représentent environ la moitié du patch, les pilotes GPU occupant comme d’habitude la première place. Mais on trouve un peu de tout dans le domaine des pilotes.

Le reste concerne principalement les réseaux, le noyau central, les systèmes de fichiers et les mises à jour des architectures.

Certaines mises à jour de la documentation méritent d'être soulignées : le flot continu de rapports AI a rendu la liste de sécurité pratiquement ingérable, avec d'énormes doublons dus au fait que différentes personnes trouvent les mêmes choses avec les mêmes outils. Les gens passent tout leur temps à simplement transférer les informations aux bonnes personnes ou à dire « ça a déjà été corrigé il y a une semaine/un mois » en renvoyant vers la discussion publique.

Tout cela n'est qu'une agitation totalement inutile, et nous affirmons clairement que les bogues détectés par l'IA ne sont, par définition, pas secrets, et que les traiter sur une liste privée est une perte de temps pour toutes les personnes concernées — et ne fait qu'aggraver ces doublons, car les rapporteurs ne peuvent même pas voir les rapports des uns et des autres.

Les outils d'IA sont formidables, mais seulement s'ils aident réellement, plutôt que de causer des tracas inutiles et un travail fictif sans intérêt. N'hésitez pas à les utiliser, mais faites-le de manière productive et de façon à améliorer l'expérience.

La documentation est peut-être un peu moins directe que moi, mais c'est là l' essentiel. Donc, pour que ce soit bien clair : si vous avez trouvé un bug à l'aide d'outils d'IA, il y a de fortes chances que quelqu'un d'autre l'ait trouvé aussi. Si vous voulez vraiment apporter une valeur ajoutée, lisez la documentation, créez un correctif vous aussi, et ajoutez une réelle valeur *en plus* de ce que l'IA a fait. Ne soyez pas le genre de personne qui « envoie un rapport au hasard sans vraiment comprendre ». D'accord ?

Linus

Source : Message de Linus Torvalds

Et vous ?

Pensez-vous que cette déclaration est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Linus Torvalds refuse de transformer la documentation du kernel en champ de bataille idéologique « anti-IA » : arrêtez de faire toute une histoire de « l'IA slop » dans la documentation du noyau

Un mainteneur propose d'ajouter un « kill switch » au noyau Linux après la divulgation récente de plusieurs vulnérabilités critiques, mais son impact sur la stabilité du système suscite un débat

Linux fixe les règles en matière de code généré par IA : Oui à Copilot, les humains endossent les erreurs. Après des mois de débats acharnés, Torvalds et les mainteneurs parviennent à un accord.
Vous avez lu gratuitement 3 094 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de fr1man
Expert confirmé https://www.developpez.com
Le 28/05/2026 à 13:32
@Artaeus
Parce que vous croyez que seuls les mauvais développeurs introduisent des bugs ?
C'est un peu simpliste comme raisonnement.
5  1 
Avatar de imperio
Membre chevronné https://www.developpez.com
Le 28/05/2026 à 11:46
Citation Envoyé par Artaeus Voir le message
Ce projet, c'est réinventer la roue (mais en version bien plus lente) ...

La manière dont cette priorité de "passer en Rust" est poussée m'interroge beaucoup sur des conflits d'intérêt et des non-dit en coulisse.
Faire des économies d'argent sur le long-terme en enlevant toute une catégorie de bugs et attirer des contributeurs plus jeunes sur le noyau pour assurer sa pérennité dans le temps.

C'est pas comme si Rust était testé dans le kernel depuis plusieurs années pour voir si ça valait le coup et leur convenait après tout... Et le plus beau : tous ces débats sont publics. Faut arrêter de chercher des complots à un moment...
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 28/05/2026 à 11:50
La priorité n'est pas de passer en Rust, Greg Kroah-Hartman est clair là dessus dans la conférence. Il dit que Rust est a préférer pour les nouveaux driver / sous-systèmes, mais il n'est pas question de demander aux mainteneurs de recoder ce qui existe déjà en Rust. Si un module est remplacé, comme l'Android Binder qu'il donne en exemple, c'est que c'est une volonté du mainteneur, en l’occurrence Google.
3  0 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 28/05/2026 à 14:01
Citation Envoyé par Artaeus Voir le message
Les bons dev, jeunes ou anciens, sécurisent leur code.
Maladroit! Vous êtes en train de sous-entendre que les concepteurs des applis qu'on utilise tout le temps et qui présentent régulièrement des bugs sont des grosses brêles...

Citation Envoyé par Artaeus Voir le message
Avec l'explosion des couts matériels, la priorité doit-être la rapidité (comme ça a toujours été le cas).
Ça tombe bien! La sémantique du langage Rust, et notamment la sémantique de prêt, associée aux capacités d’optimisation du compilateur de Rust permettent de très bonnes optimisation du code. Par exemple, la sémantique de prêt offre un contrôle de l'aliasing de la mémoire probablement plus précis qu'un mot clef comme 'restrict' en C. On pourrait aussi évoquer les facilités à paralléliser le code...
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 30/05/2026 à 15:04
Citation Envoyé par Bardaz Voir le message
Je ne sors pas ça du chapeau, faites une recherche, même rapide sur la partie financière de Rust et sur les protocoles de décisions des instances des différents langages. La plupart des personnes se concentrent sur la partie technique à juste titre c'est la première à interroger mais il ne faut aucunement s'arrêter là. Il faut avouer que c'est pas un aspect très apétant pour des devs mais faut bien s'y coller pour comprendre pourquoi les bigs techs et le gouvernement US soutient à fond.
Il faudrait que tu sois plus précis car ce que tu reproches au Rust, comparé au C et C++, n'est pas très clair .
Les protocoles de décision en ce qui concerne l'évolution de Rust sont connus et relativement ouverts. Il ne faut pas croire que c'est très différent coté C ou C++, les comités de normalisation du langage ont beau répondre à une norme ISO, ils ont tout autant leur problèmes de jeu de pouvoir.

Citation Envoyé par calvaire Voir le message
c'est juste que je vois passer beaucoup de news sur le net de certains qui veulent absolument tous recoder un truc (même quand ça marche très bien depuis des années) en rust.
Meme antropic fait sa pub en codant en rust un compilateur c. L’intérêt technique de ce truc et nul, ils ont choisit volontairement pour faire de la pub de coder en rust parmi les 10aines d'autres langages populaire qui existe.
Les tentatives de porter, sans de très bonnes raisons, un outil C qui marche bien en Rust ne sont pas légion. Si tu as l'impression qu'on en parle beaucoup, c'est la plupart du temps parce que les supporters du C et du C++ remontent en boucle les mêmes cas particuliers. Généralement les gens qui connaissent Rust sont les premiers à recommander de ne pas le faire, à moins que le besoin d'un réécriture se fasse vraiment sentir.

En ce qui concerne Anthropic, je suppose que tu parles de Bun, mais c'est une suite d'outils pour le langage TypeScript, écrite en Zig. Pas de rapport avec C. Je dirais même qu'une partie de la problématique est inversée, vue que Zig est un langage bien plus niche que le Rust.
Cependant, c'est vrai que cette migration n'était pas pas indispensable, surtout que ça a été fait de manière précipitée à coup d' IA générative quasiment pas supervisée, ce qui est critiqué en premier lieu par la communauté Rust.
2  0 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 02/06/2026 à 13:19
Citation Envoyé par Uther Voir le message
Les tentatives de porter, sans de très bonnes raisons, un outil C qui marche bien en Rust ne sont pas légion. Si tu as l'impression qu'on en parle beaucoup, c'est la plupart du temps parce que les supporters du C et du C++ remontent en boucle les mêmes cas particuliers. Généralement les gens qui connaissent Rust sont les premiers à recommander de ne pas le faire, à moins que le besoin d'un réécriture se fasse vraiment sentir.
Ces montages en boucles viennent aussi de certains préjugés. C'est à croire que certains pensent que les personnes qui programment en Rust ont découvert la programmation avec Rust et veulent refaire le monde en oubliant le passé... Et bien non, beaucoup d'entre nous ont un historique de programmation, et les bons réflexes qu'on avait en faisant du C ou du C++ à une certaine époque, puis en utilisant d'autres langages, n'ont pas disparu depuis qu'on fait du Rust.
2  0 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 29/05/2026 à 14:44
Citation Envoyé par Mingolito Voir le message
Il y a un conflit de génération, les anciens codeur C++ de l'équipe seront bientôt séniles ou morts, et les jeunes ne veulent pas coder en C++ c'est trop compliqué, mais en Rust peut être. Donc l'idée est de remplacer l'équipe C++ mourante par une équipe plus jeune, sur Rust.
Il faut quand même reconnaitre que le code Rust sera plus facile à lire et induira moins de risques de vulnérabilités que le C++. Google est déjà en train de faire le pas avec des résultats probants :

Google a adopté Rust pour des raisons de sécurité et a constaté une réduction de 1 000 fois des vulnérabilités liées à la sécurité de la mémoire

« Les équipes Rust chez Google sont deux fois plus productives que celles qui se servent de C++ »
Le langage développé par Google, c'est surtout Go. Mais il est vrai que Google met particulièrement en avant Rust, le langage qui a été créé par Mozilla notamment pour d'anciens projets expérimentaux comme servo.

Mais je me réfère plutôt à la liste des financeurs de la fondation Rust, pour mesurer l'adoption progressive du langage.


J'avais noté précédemment l'arrivée d'arm comme financeur Platinum du langage, mais je note aussi que Canonical, le commanditaire de l'OS Ubuntu, est désormais financeur Gold.

Et non, il n’y a pas de complot contre les langages C/C++ : il s’agit simplement d’une montée d’intérêt progressive, venant de différents acteurs indépendants, sans implication particulière au départ dans ce projet.

2  1 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 29/05/2026 à 16:03
Citation Envoyé par UneMouchePasse Voir le message
Chacun voit midi à sa porte, perso la secte C\C++ bloquée dans les années 2000 je la trouve encore bien présente. Enfin elle est bientôt à la retraite.
Je suis vieux et j'aime bien Rust! On n'est pas dans une guerre générationnelle, quand même!
1  0 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 01/06/2026 à 9:40
Citation Envoyé par calvaire Voir le message
Il y'a 10ans je disais la même chose avec la "secte" javascript, tous le monde voulaient tous recoder en javascript.
Je ne code pas en javascript/typescript, mais cela reste incontournable dans le developpement web, me semble-t-il.

Citation Envoyé par calvaire Voir le message
Tous ça sait d'ailleurs terminé à du web assembly.
Cela cible des choses différentes. C'est très bien pour faire des modules bas niveau ou pour compiler de l'existant, Rust, C/C++ ou Zig notamment.

Citation Envoyé par calvaire Voir le message
Perso je conseil plutôt de partir sur du des technos de niche à forte valeur : Scala, Clojure ou Zig
On est vraiment dans des technos de niche, là.
Et pour ce qui est de Scala, on est davantage dans l'effet de mode que JavaSctipt qui a une porté universelle dans le monde web. Heureusement qu'il lui reste une implémentation importante dans le domaine des grandes données et du distribué JVM.
J'aime bien ce langage ceci étant, et il a contribué à mon basculement dans le monde Rust (et oui...).
1  0 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 01/06/2026 à 11:16
Citation Envoyé par calvaire Voir le message
Je parle d'un point de vue carrière/business, pas de la technique dont je m'en fou.
J'ai compris cela. Mais l'impact futur de langages de niche comme Scala reste difficile à évaluer, me semble-t-il. Je ne fonderais pas une carrière là-dessus au delà du moyen terme.
Scala ne s'est pas vraiment sorti du monde JVM (les alternatives js et LLVM proposées n'ont pas beaucoup d'impact), ce que je trouve un peu embêtant. L'écosystème JVM va rester longtemps, mais sa place s'érode.

Citation Envoyé par calvaire Voir le message
il y a une vraie déconnexion je trouve entre la hype technique autour de Rust et la réalité du marché de l'emploi local.
Alors cet hypothétique "forcing" de Rust n'est qu'une broutille dont il est inutile de s'inquiéter.

Citation Envoyé par calvaire Voir le message
tout ne tourne pas autour de l'argent dans la vie
Cela ne fait pas trop sens de devenir développeur pour l'argent, surtout face aux capacités de codage émergentes des IA. Il y a des formations qui payent mieux.

Citation Envoyé par calvaire Voir le message
Mais n'allez pas faire du rust en croyant que vous allez avoir un meilleur salaire a l'heure ou j'écris ces lignes.
Cette question ne se pose pas pour ma part. Mais je suis assez d'accord sur ce point, et à l'heure actuelle.
2  1