Discussion :

[Bardaz]

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...

Encore une fois on se trompe de débat il ne porte pas du tout sur la qualité du code Rust, son exécution ou tout aspect technique. Comme tu le dis pas de complots tout est public. La question se pose sur la gouvernance et les logiques de pouvoir coté Rust VS l'existant. Là il est grand temps que le débat se pose car c'est ici que tout se joue dans le tuilage. Le remplacement des développeurs impliquent de céder une partie du "pouvoir" majoritairement à des big techs logées aux USA là où avec C et C++ les instances sont internationales, les devs seniors pléthore et surtout organisés !

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.

[calvaire]

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.

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 parmis les 10aines d'autres langages populaire qui existe.

Il y'a 10ans je disais la même chose avec la "secte" javascript, tous le monde voulaient tous recoder en javascript. On a eu des hyperviseurs/émulateurs en javascript, des système d'exploitation web comme firefox os...etc.
Tous ça sait d'ailleurs terminé à du web assembly.


Perso j'ai toujours suivie le conseil de Warren Buffett, tant en finance que dans ma carrière pro et dans ma vie perso:

C'est lorsque mon chauffeur de taxi me dit d'acheter une action que je sais qu'il faut la vendre.

ce qui explique que j'ai jamais appris le js ou le rust

Les stats semble me donner tort mets de ce que je con,state du marché du travail en Europe et en asie il y'a décalage très réel entre les statistiques globales et la réalité du terrain.
Quand les comparatifs (comme l'enquête Stack Overflow) placent Rust au sommet, les chiffres sont massivement tirés vers le haut par trois facteurs précis :
Les rôles à l'étranger (notamment US en remote) où les salaires à 180k – 230k sont fréquents.
Le secteur de la Web3 / Blockchain, très friand de Rust, qui a longtemps surpayé ses ingénieurs (parfois en jetons/tokens).
La rareté des profils seniors : beaucoup de développeurs apprennent Rust en dilettante, mais les vrais experts capables de gérer de la programmation système complexe sont rares.

Mais ailleurs, sur un poste de "dev" classique en CDI, la grille salariale locale reprend souvent le dessus, et Rust ne fait pas de miracle absolu face à la réalité du marché.
Perso je conseil plutôt de partir sur du des technos de niche à forte valeur : Scala, Clojure ou Zig

[Uther]

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.

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.

[fdecode]

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.

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.

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...).

[calvaire]

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...).

Je parle d'un point de vue carrière/business, pas de la technique dont je m'en fou.
De ce que je constate c'est qu'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. En dehors des licornes ou des contrats d'envergure internationale en remote, les salaires en Europe restent calqués sur du C/C++ traditionnel. Vu la courbe d'apprentissage du langage (la gestion de la mémoire, le borrow checker.....), le retour sur investissement est difficile à justifier.

Si le but est d'optimiser sa carrière et sa rémunération en choisissant une niche, le paradigme fonctionnel reste bien plus standard et rentable. Miser sur la stack Scala (avec ZIO) ou Clojure offre un bien meilleur levier de négociation financière, car les profils qualifiés y sont extrêmement rares et recherchés.
C'est pour moi le but 1er pour apprendre/se former sur des nouvelles technos car sinon je n'en vois pas l’intérêt... mais comme d'hab je vais avoir des réponses avec des vieux poncifs de type pour la culture/curiosité, tout ne tourne pas autour de l'argent dans la vie et blablabla.

Maintenant je ne suis pas medium, je parle des grilles de salaire des entreprises que je connais bien en zone europe/asia pour 2025/2026, dans 5ans ca peut changer. Mais n'allez pas faire du rust en croyant que vous allez avoir un meilleur salaire a l'heure ou j'écris ces lignes.

[fdecode]

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.

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.

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.

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.

[Mathis Lucas]

Zig interdit les contributions de code généré par l'IA, car elles sont « systématiquement de mauvaise qualité »
le projet affirme qu'il veut préserver le temps précieux des réviseurs humains

Le président de la fondation Zig a instauré une interdiction stricte concernant l'usage de l'IA pour les contributions au code source du langage. Andrew Kelley qualifie ces soumissions automatisées de déchets numériques dépourvus de valeur, car elles surchargent inutilement les réviseurs humains déjà très sollicités. Contrairement aux Big Tech, ce projet open source privilégie le mentorat et le développement des compétences personnelles plutôt que la productivité pure. Cette politique radicale vise à protéger la qualité logicielle tout en évitant le temps perdu à corriger des erreurs générées par des machines. Zig n'est pas le premier à emprunter ce chemin.

Zig est un langage de programmation système conçu pour apporter des améliorations polyvalentes au langage de programmation C. Il s'agit d'un logiciel libre et open source, publié sous licence MIT. Les différences avec le langage C concernent le flux de contrôle, les appels de fonction, l'importation de bibliothèques, la déclaration de variables et la prise en charge de l'Unicode. De plus, le langage Zig n'utilise ni macros ni instructions de préprocesseur.

Parmi les fonctionnalités empruntées aux langages modernes, on trouve l'ajout de types de données de programmation générique à la compilation, et un petit ensemble de nouvelles directives de compilation permettant d'accéder aux informations sur ces types à l'aide de la réflexion.

Perte de temps critique pour les mainteneurs très sollicités

Zig est géré par une association à but non lucratif de type 501(c)(3) et un réseau de contributeurs. Tout développeur peut soumettre du code à son référentiel, à condition de respecter un code de conduite. Zig vient d'ajouter une nouvelle règle interdisant la soumission de code généré par l'IA. La politique prévient : aucun contenu généré par une IA, aucune paraphrase issue d'une IA, aucun élément édité, issu d'une réflexion ou débogué par une IA.

Andrew Kelley, le président de la fondation Zig, justifie cette décision en qualifiant les contributions faites par l'IA de déchets systématiques n'ayant aucune valeur. Selon lui, ces soumissions ont en réalité une valeur négative, car elles gaspillent le temps de la petite équipe chargée d'examiner le code. Le processus de révision constitue le principal goulot d'étranglement du projet, l'équipe étant déjà débordée par le nombre élevé de requêtes en attente.

Ces ajouts générés par l'IA ralentissent considérablement le groupe et proviennent généralement de contributeurs de passage qui ne s'investiront pas durablement dans le projet. « Les gens nous envoient des contributions qui n'ont absolument aucune valeur. Elles ont même une valeur négative, car elles font perdre du temps à l'équipe en révision », a déclaré Andrew Kelley dans un récent épisode du podcast de la société de logiciels JetBrains.

Au moment de l'enregistrement, Andrew Kelley a indiqué que Zig comptait 200 pulls requests en attente. « Nous avons fait perdre du temps à tout le monde », a-t-il déclaré. Bien que Zig soit relativement modeste comme langage de programmation, son impact a été considérable. Ce langage a notamment servi à créer Bun, qui a ensuite été racheté par Anthropic. L'interdiction de l'IA a par la suite provoqué de vives tensions entre Bun et Zig.

Priorité à l'apprentissage plutôt qu'à la productivité intense

Le code généré par l'IA fait fureur dans la Silicon Valley, porté par des outils comme Claude Code d'Anthropic ou Codex d'OpenAI. Certain l'utilisent pour éditer leur code, d'autres pour le rédiger entièrement. Les Big Tech se sont fixé des objectifs ambitieux quant à la part de code produite par l'IA. Mais contrairement aux géants de la tech qui cherchent à maximiser leur efficacité grâce à l'IA, la mission fondamentale de Zig repose sur le mentorat.

Zig n'a pas pour mission d'atteindre une efficacité maximale. « Nous essayons tous de nous améliorer en programmation. Les personnes qui envoient des pulls requests générées par l'IA ne contribuent pas à cet objectif », a déclaré le président Andrew Kelley. Ces développeurs IA sont des « contributeurs occasionnels », c'est-à-dire ceux qui peuvent soumettre une ou deux demandes de fusion, mais qui ne rejoindront jamais l'équipe principale.

Bref, l'IA est banni. Andrew Kelley a expliqué que s'il avait déclaré que seules les pulls requests de « bonne qualité » générées par l'IA seraient acceptées, les réviseurs auraient dû les évaluer une par une. « Si je dis qu'aucune ne sera acceptée, alors c'est une politique très facile à appliquer », a-t-il déclaré.

Plusieurs projets ont interdit les rapports générés par l'IA

L'adoption des outils d'IA par les plateformes telles que HackerOne pose un problème majeur à la communauté des logiciels libres : la multiplication de rapports de vulnérabilités générés par des outils d'IA, souvent erronés ou trompeurs, qui submergent les mainteneurs. Les fabricants de modèles d'IA s'attendent à ce que l'IA aide les développeurs à détecter les bogues beaucoup plus rapidement afin de jouir de plus de temps pour innover.

Mais il s'avère que ces rapports sont en majorité le résultat des hallucinations de l'IA, et donc inutiles. Seth Larson, développeur de sécurité en résidence à la Python Software Foundation, a soulevé la question dans un billet de blogue en décembre 2024. Il a exhorté les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. Selon lui, les systèmes d'IA actuels ne sont pas fiables dans ce contexte.

« J'ai remarqué une augmentation des rapports de sécurité de qualité extrêmement médiocre, spammés et hallucinés par les LLM dans les projets open source. À première vue, ces rapports de bogue semblent potentiellement légitimes et nécessitent donc du temps pour être réfutés », écrivait-il, rappelant les résultats similaires obtenus par le projet cURL en janvier 2024. Début 2025, c'est le créateur du projet cURL qui a exprimé son ras-le-bol.

Dans certains cas, les auteurs des signalements erronés sont des personnes novices qui testent des IA sur du code. Ou pire, elles utilisent les rapports générés par l'IA pour tenter d'obtenir des récompenses financières via des programmes de primes aux bogues sans fournir de véritables contributions.

Par exemple, quatre rapports de vulnérabilité malavisés ont été publiés par une personne apparemment à la recherche d'une réputation ou d'une prime de détection de bogues. « L'une des façons de s'en rendre compte, c'est que le rapport est toujours très agréable. Formulé de manière agréable, en anglais parfait, poli, avec de jolis points... un humain ordinaire ne le ferait jamais de cette manière dans son premier rapport », a déclaré Daniel Stenberg.

Vouch : un système de gestion de la confiance communautaire

Ces dernières années, le nombre de personnes utilisant les outils d'IA pour générer du code au lieu de l'écrire eux-mêmes a augmenté. Cependant, une grande partie du code généré par l'IA est de mauvaise qualité. En conséquence, le coût croissant de l'élimination du code de mauvaise qualité généré par l'IA est devenu un problème épineux pour les projets open source disposant déjà de peu de ressources et reposant sur la coopération communautaire.

Pour remédier à ce problème, le développeur de logiciels Mitchell Hashimoto a lancé un système appelé « Vouch » qui élimine les personnes soumettant du code de mauvaise qualité et maintient la qualité des projets open source. Il se dit lasser de jouer au chat et à la souris avec les rapports de mauvaise qualité.

Vouch introduit un modèle de confiance explicite. Un contributeur ne peut soumettre une pull request que s’il a été préalablement approuvé par un contributeur déjà reconnu comme fiable. « La légitimité n’est plus implicite, mais formalisée, ce qui inverse la logique par défaut de l’ouverture totale ». Vouch repose sur des actions GitHub. Une action vérifie automatiquement si l’auteur d’une pull request figure dans la liste des contributeurs approuvés.

D’autres actions GitHub permettent d’ajouter ou de retirer des contributeurs, en s’appuyant sur des décisions humaines documentées dans le dépôt. Les informations de confiance sont stockées dans un fichier texte unique, versionné avec le projet. Ce choix favorise la transparence, l’auditabilité et l’automatisation.

Vouch permet de réutiliser ces listes entre projets, ouvrant la voie à des réseaux de confiance partagés entre dépôts ayant des exigences similaires. La mise en œuvre est générique et peut être utilisée par n'importe quel projet sur n'importe quelle forge de code, mais le développeur fournit une intégration GitHub prête à l'emploi via les actions GitHub et l'interface CLI. Le projet Vouch vise à faire face à l'afflux de pulls requests de mauvaise qualité.

Source : Andrew Kelley, président de la fondation Zig

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'interdiction de l'IA par le projet open source Zig ?

Voir aussi

Vouch : un système visant à maintenir la qualité de l'open source face à l'afflux de pulls requests de mauvaise qualité générées par l'IA, il permet de gérer la confiance dans les contributeurs à un projet

Le projet open source cURL interdit les rapports de bogue inutiles générés par l'IA : « nous n'avons toujours pas vu un seul rapport de sécurité valide rédigé avec l'aide de l'IA »

Les mainteneurs de logiciels libres sont noyés dans des rapports de bogues inutiles rédigés par l'IA. « Ces systèmes ne sont pas encore capable de comprendre le code », estime un développeur

[Uther]

Je parle d'un point de vue carrière/business, pas de la technique dont je m'en fou.

Sauf que le sujet c'était précisément l'intérêt technique de Rust dans le cadre du noyau Linux. Tu as tout a fait le droit de te foutre du coté technique, mais là c'est le sujet de base.

Si le but est d'optimiser sa carrière et sa rémunération en choisissant une niche, le paradigme fonctionnel reste bien plus standard et rentable. Miser sur la stack Scala (avec ZIO) ou Clojure offre un bien meilleur levier de négociation financière, car les profils qualifiés y sont extrêmement rares et recherchés.

De nos jours Scala et Clojure sont tellement niche que ça me parait risqué comme plan carrière, c'est possiblement bien payé, encore faut il trouver un poste intéressant avec. Et dans le cadre du sujet, à savoir le noyau Linux, ces langages sont juste inenvisageables car pas assez bas niveau.
Un intérêt de Rust est justement qu'il permet d’intégrer le paradigme fonctionnel bien mieux que C et C++ dans des domaines où la plupart des langage fonctionnels sont inenvisageables

[fdecode]

Un intérêt de Rust est justement qu'il permet d’intégrer le paradigme fonctionnel bien mieux que C et C++ dans des domaines où la plupart des langage fonctionnels sont inenvisageables

Je ne me suis pas senti trop dépaysé en passant à Rust après quelques temps à travailler avec Scala (version 2).
Pour ce qui est du fonctionnel, j'avais justement apprécié les capacités de pattern matching de Rust, se basant essentiellement sur la structure de donnée, et donc favorisant une optimisation du code par le compilateur (sans surcharge d'abstraction à l'exception de certains tests conditionnels ou certaines gestions de l'énumération dans le matching).
A contrario, le pattern matching de Scala passe beaucoup par des unapply, et n'est pas aussi direct. Même les 'case class' de Scala restent des classes JVM, et cela est un peu plus lourd que les structures Rust qui sont directement matchables tout en étant très simples et proches du C.
Alors Scala est plus concis du point de vue de la programmation fonctionnelle, certes, mais je m'y retrouve bien en Rust.
Les deux langages proposent des mécanismes haut niveau, incluant:
- le fonctionnel,
- Des mécanismes de trait différents, mais sur lequel Rust fait reposer sa programmation par héritage (programmation orientée traits, à comportements orthogonaux aux données).
- Des langages fortement typés mais avec un mécanisme important d'inférence de type (Rust étant plus limité que Scala sur ce point mais avec plus de lisibilité; il faut très bien connaitre ses règles de sucre grammatical en Scala...),
- Un fort impact de la généricité par des variables de type et cette généricité est bien maîtrisée (rien à voir avec un template). Le conditionnement des types en Rust est incroyable, et je pense que ça va plus loin que Scala. Par contre, Scala permet des variables de type du second ordre... Même si les GAT (Generic Associated Types) de Rust offrent quelques possibilités.
- Des systèmes de macros agissant sur l'AST,
- Une programmation multithread/asynchrone facile (e.g. Scala: Future basé GC et les mécanismes de multithread de la JVM ; Akka/Pekko ; Flink, Spark, ... ; je ne connais pas ZIO /**/ Rust: noGC ; multithread ou async (concurrence) ; channels ; rayon ; tokio ; ractor ...).
Les deux langages sont élégants de mon point de vue, et la concision de Scala est imbattable. Et on n'oubliera pas le côté DSL-friendly de Scala grâce à ses sucreries grammaticales (à l'excès parfois).
Mais ce qui avait emporté mon choix, c'est que Rust m'a offert des fonctionnalités qui me paraissent proches de Scala tout en étant bas niveau et avec un travail direct en mémoire, grâce à la sémantique de prêt... Honnêtement, ça m'avait impressionné à l'époque.

[fdecode]

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.

[Patrick Ruiz]

Godot n'acceptera plus les contributions de code générées par l'IA
Les décisions similaires s’enchaînent dans la filière du logiciel au motif que « ces contributions sont systématiquement de mauvaise qualité »

Godot n’acceptera plus les contributions de code générées par l’intelligence artificielle. Des décisions similaires s’enchaînent dans la filière du logiciel et s’appuient sur certaines études parmi lesquelles celle de CodeRabbit sur 470 pull requests open source publiées sur GitHub, qui a révélé que le code généré par l'IA comportait plus de bogues et d'erreurs que le code produit par l'homme. Selon cette étude, les pull requests effectuées à l'aide de l'IA présentaient en moyenne 10,83 problèmes, contre 6,45 pour celles rédigées uniquement par des développeurs humains.

Après des mois de discussions, la Fondation Godot et ses responsables mettent un terme à cette situation. Dans un article de blog, la Fondation a annoncé que les directives de Godot destinées aux contributeurs seraient bientôt modifiées afin d’interdire le code rédigé par l’IA, les pull requests soumises par des agents IA et le texte généré par l’IA dans les communications entre humains.

« Il est temps pour nous de reconnaître que ces problèmes ne disparaîtront pas et que nous devons donc prendre des mesures pour alléger la charge qui pèse sur les responsables de maintenance, tout en veillant à conserver un parcours permettant d’accompagner les nouveaux contributeurs pour qu’ils deviennent les futurs responsables de maintenance », a déclaré la Fondation Godot.

La Fondation estime que l'accumulation de pull requests Godot en attente de révision n'est pas entièrement négative : c'est le signe que l'intérêt pour l'utilisation et la contribution à Godot est en hausse. Mais l'afflux de contributions rédigées ou soumises par l'IA sape la motivation des responsables du projet à se confronter au travail déjà fastidieux que représente la révision des pull requests.

« Si vos commentaires sur les pull requests sont simplement absorbés par une machine et ne servent pas à encadrer un futur responsable potentiel, il devient beaucoup plus difficile de justifier de consacrer son temps libre à l'examen de ces pull requests », a déclaré la Fondation.

Alors que le problème devient de plus en plus insoutenable, la Fondation Godot indique qu'elle est en train de mettre à jour ses politiques de contribution, en mettant l'accent sur « la mise en place de barrières contre les contributions bâclées et sans effort », l'encouragement des responsables de maintenance à réviser le code, la formation des nouveaux contributeurs pour qu'ils deviennent de futurs responsables de maintenance et, surtout, l'exigence que toutes les contributions proviennent d'êtres humains responsables de leur code — et capables de le corriger en cas d'échec.

For years we've been overwhelmed by the volume of code contributions we have to review, especially from new contributors. AI has made the problem much worse.

We are taking steps to reduce the burden on maintainers while still welcoming new contributors:https://t.co/LcBXAjm2qB

— Godot Engine (@godotengine) June 30, 2026

Plusieurs projets ont interdit les rapports générés par l'intelligence artificielle

L'adoption des outils d'IA par les plateformes telles que HackerOne pose un problème majeur à la communauté des logiciels libres : la multiplication de rapports de vulnérabilités générés par des outils d'IA, souvent erronés ou trompeurs, qui submergent les mainteneurs. Les fabricants de modèles d'IA s'attendent à ce que l'IA aide les développeurs à détecter les bogues beaucoup plus rapidement afin de jouir de plus de temps pour innover.

Mais il s'avère que ces rapports sont en majorité le résultat des hallucinations de l'IA, et donc inutiles. Seth Larson, développeur de sécurité en résidence à la Python Software Foundation, a soulevé la question dans un billet de blogue en décembre 2024. Il a exhorté les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. Selon lui, les systèmes d'IA actuels ne sont pas fiables dans ce contexte.

« J'ai remarqué une augmentation des rapports de sécurité de qualité extrêmement médiocre, spammés et hallucinés par les LLM dans les projets open source. À première vue, ces rapports de bogue semblent potentiellement légitimes et nécessitent donc du temps pour être réfutés », écrivait-il, rappelant les résultats similaires obtenus par le projet cURL en janvier 2024. Début 2025, c'est le créateur du projet cURL qui a exprimé son ras-le-bol.

Dans certains cas, les auteurs des signalements erronés sont des personnes novices qui testent des IA sur du code. Ou pire, elles utilisent les rapports générés par l'IA pour tenter d'obtenir des récompenses financières via des programmes de primes aux bogues sans fournir de véritables contributions.

Par exemple, quatre rapports de vulnérabilité malavisés ont été publiés par une personne apparemment à la recherche d'une réputation ou d'une prime de détection de bogues. « L'une des façons de s'en rendre compte, c'est que le rapport est toujours très agréable. Formulé de manière agréable, en anglais parfait, poli, avec de jolis points... un humain ordinaire ne le ferait jamais de cette manière dans son premier rapport », a déclaré Daniel Stenberg.

Open source game engine puts its foot down against AI code 🦿#godot #ai #news #pcgaming #pcgamer pic.twitter.com/7vYvrPDdpp

— PC Gamer (@pcgamer) July 1, 2026

En gros, l’IA n’est plus perçue comme un progrès maîtrisé, mais comme une couche imposée, parfois maladroite, souvent envahissante, et surtout déconnectée des usages réels, mais chez Microsoft on n’est pas du même avis

Le PDG de Microsoft, Satya Nadella, a publiquement rejeté l'utilisation du terme « slop ». Il préfère encourager l'industrie à considérer l'intelligence artificielle comme un amplificateur cognitif ou un tuteur pour le potentiel humain plutôt qu'un substitut.

« Nous devons dépasser les arguments opposant contenu de faible qualité et sophistication et développer un nouvel équilibre en termes de « théorie de l'esprit » qui tienne compte du fait que les humains sont équipés de ces nouveaux outils d'amplification cognitive dans leurs relations les uns avec les autres. C'est la question de conception de produit dont nous devons débattre et à laquelle nous devons répondre », déclare-t-il.

Source : Godot (note d’interdiction des contributions de code générées par l’IA)

Et vous ?

Êtes-vous en accord avec la perception selon laquelle l’IA n’est pas un progrès maîtrisé, mais une couche imposée, parfois maladroite, souvent envahissante et surtout déconnectée des usages réels ? Cette perception cadre-t-elle avec vos expériences en tant que développeurs informatique ? Partagez vos anecdotes

Voir aussi :

Vouch : un système visant à maintenir la qualité de l'open source face à l'afflux de pulls requests de mauvaise qualité générées par l'IA, il permet de gérer la confiance dans les contributeurs à un projet

Le projet open source cURL interdit les rapports de bogue inutiles générés par l'IA : « nous n'avons toujours pas vu un seul rapport de sécurité valide rédigé avec l'aide de l'IA »

Les mainteneurs de logiciels libres sont noyés dans des rapports de bogues inutiles rédigés par l'IA. « Ces systèmes ne sont pas encore capable de comprendre le code », estime un développeur

[Patrick Ruiz]

Linus Torvalds s’exprime sur la plus-value de l’IA dans le noyau Linux et dit « Oui à l'IA, mais l’expertise des développeurs humains est requise pour corriger les patchs et les rapports de bogue générés »

C’est l’économie de sa récente sortie lors de l’Open Source Summit en Inde. Elle s’avère être une redite de prises de positions précédentes dans lesquelles il souligne qu’il voit l’intelligence artificielle comme un meilleur outil pour les revues que pour la génération de code et que, dans un cas comme dans l’autre, l’apport des développeurs humains est nécessaire pour corriger les productions de l’intelligence artificielle. Sa sortie intervient dans un contexte de divisions dans la filière autour de la mise à contribution de l’intelligence artificielle. En effet, certains projets optent pour l’interdiction des outils dits d’intelligence artificielle.

En droite ligne avec sa sortie lors du récent Open Source Summit en Inde, Linux autorise l'utilisation de l’intelligence artificielle pour générer le code du noyau. Précision à ce propos : la communauté ne le considère pas comme la propre contribution du mainteneur. En d’autres termes, ce dernier endosse les éventuelles erreurs de l’intelligence artificielle mise à contribution dans le cadre de la génération de code du noyau. En sus, les mainteneurs ont entre autres pour charge d’assurer la révision de l'intégralité du code. C’est un accord entre Linus Torvalds et les mainteneurs après des mois de débats acharnés. Linus Torvalds reste ainsi cohérent avec sa posture selon laquelle l’IA reste un outil à utiliser avec des pincettes.

Linus Torvalds a déjà formulé des plaintes pour ce qui est des 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. Lors du récent Open Source Summit, il ajoute que le contenu de ces rapports de bogue est tel qu’il nécessite une revue humaine dans bien des cas. En gros, l’apport des développeurs humains reste requis pour ce qui est de la génération et de la revue de code produit par l’intelligence artificielle.

A l’inverse du noyau Linux, plusieurs projets interdisent désormais les contributions de code ainsi que les rapports générés par l’intelligence artificielle

Après des mois de discussions, la Fondation Godot et ses responsables mettent un terme à cette situation. Dans un article de blog, la Fondation a annoncé que les directives de Godot destinées aux contributeurs seraient bientôt modifiées afin d’interdire le code rédigé par l’IA, les pull requests soumises par des agents IA et le texte généré par l’IA dans les communications entre humains.

« Il est temps pour nous de reconnaître que ces problèmes ne disparaîtront pas et que nous devons donc prendre des mesures pour alléger la charge qui pèse sur les responsables de maintenance, tout en veillant à conserver un parcours permettant d’accompagner les nouveaux contributeurs pour qu’ils deviennent les futurs responsables de maintenance », a déclaré la Fondation Godot.

La Fondation estime que l'accumulation de pull requests Godot en attente de révision n'est pas entièrement négative : c'est le signe que l'intérêt pour l'utilisation et la contribution à Godot est en hausse. Mais l'afflux de contributions rédigées ou soumises par l'IA sape la motivation des responsables du projet à se confronter au travail déjà fastidieux que représente la révision des pull requests.

« Si vos commentaires sur les pull requests sont simplement absorbés par une machine et ne servent pas à encadrer un futur responsable potentiel, il devient beaucoup plus difficile de justifier de consacrer son temps libre à l'examen de ces pull requests », a déclaré la Fondation.

Alors que le problème devient de plus en plus insoutenable, la Fondation Godot indique qu'elle est en train de mettre à jour ses politiques de contribution, en mettant l'accent sur « la mise en place de barrières contre les contributions bâclées et sans effort », l'encouragement des responsables de maintenance à réviser le code, la formation des nouveaux contributeurs pour qu'ils deviennent de futurs responsables de maintenance et, surtout, l'exigence que toutes les contributions proviennent d'êtres humains responsables de leur code — et capables de le corriger en cas d'échec.

For years we've been overwhelmed by the volume of code contributions we have to review, especially from new contributors. AI has made the problem much worse.

We are taking steps to reduce the burden on maintainers while still welcoming new contributors:https://t.co/LcBXAjm2qB

— Godot Engine (@godotengine) June 30, 2026

L'adoption des outils d'IA par les plateformes telles que HackerOne pose un problème majeur à la communauté des logiciels libres : la multiplication de rapports de vulnérabilités générés par des outils d'IA, souvent erronés ou trompeurs, qui submergent les mainteneurs. Les fabricants de modèles d'IA s'attendent à ce que l'IA aide les développeurs à détecter les bogues beaucoup plus rapidement afin de jouir de plus de temps pour innover.

Mais il s'avère que ces rapports sont en majorité le résultat des hallucinations de l'IA, et donc inutiles. Seth Larson, développeur de sécurité en résidence à la Python Software Foundation, a soulevé la question dans un billet de blogue en décembre 2024. Il a exhorté les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. Selon lui, les systèmes d'IA actuels ne sont pas fiables dans ce contexte.

« J'ai remarqué une augmentation des rapports de sécurité de qualité extrêmement médiocre, spammés et hallucinés par les LLM dans les projets open source. À première vue, ces rapports de bogue semblent potentiellement légitimes et nécessitent donc du temps pour être réfutés », écrivait-il, rappelant les résultats similaires obtenus par le projet cURL en janvier 2024. Début 2025, c'est le créateur du projet cURL qui a exprimé son ras-le-bol.

Dans certains cas, les auteurs des signalements erronés sont des personnes novices qui testent des IA sur du code. Ou pire, elles utilisent les rapports générés par l'IA pour tenter d'obtenir des récompenses financières via des programmes de primes aux bogues sans fournir de véritables contributions.

Par exemple, quatre rapports de vulnérabilité malavisés ont été publiés par une personne apparemment à la recherche d'une réputation ou d'une prime de détection de bogues. « L'une des façons de s'en rendre compte, c'est que le rapport est toujours très agréable. Formulé de manière agréable, en anglais parfait, poli, avec de jolis points... un humain ordinaire ne le ferait jamais de cette manière dans son premier rapport », a déclaré Daniel Stenberg.

Source : Keynote : Linus Torvalds in conversation with Dirk Hohndel at Open Source Summit India 2026

Et vous ?

Peut-on réellement faire confiance au code généré par l'IA sans relecture humaine ?

Comment intégrer efficacement l’IA dans une chaîne DevOps sans compromettre la qualité ou la sécurité ?

L’IA est-elle capable de générer un code maintenable à long terme, ou produit-elle surtout du “jetable” ?

Faut-il former tous les développeurs à l’ingénierie de prompt et à la relecture de code IA ?

Va-t-on vers une disparition progressive des développeurs juniors au profit d’IA copilotes ? Comment adapter la formation des futurs ingénieurs à un monde où l’IA code une grande partie des projets ?

Les développeurs de demain seront-ils des "relecteurs de code IA" ou des "concepteurs augmentés" ?

Quelles compétences humaines deviendront les plus valorisées face à l’automatisation du codage ?

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.

[Alex]

Linus Torvalds invite les détracteurs de l'IA à créer un fork de Linux ou à s'en aller : Linux n'est ni « anti-IA » ni un « militant social », réplique-t-il à certains développeurs du noyau opposés à l'IA

La position de Linus Torvalds vis-à-vis de l’IA semble s’assouplir. Après avoir souligné qu’en 2024, la technologie de l’IA relevait à 90 % du marketing et à 10 % de la réalité factuelle, Torvalds vient de déclarer que Linux n’est pas un projet « anti-IA », et que toute personne qui y voit un problème peut soit s’en détourner, soit créer un fork du noyau. Torvalds a admis que l’IA n’était pas parfaite, mais il estime que quiconque souligne les problèmes de cette technologie ferait mieux de se regarder dans le miroir et de se pointer du doigt en même temps. Les commentaires de Torvalds suggèrent que l’IA a déjà dépassé le stade expérimental pour Linux, même si les développeurs sont encore confrontés à la charge de travail supplémentaire, aux correctifs discutables et à l’alourdissement occasionnel du noyau qu’elle engendre.

Le noyau Linux est un noyau libre et open source de type Unix utilisé dans de nombreux systèmes informatiques à travers le monde. Créé par Linus Torvalds en 1991, il 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 portent le nom de 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 en informatique 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. 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. Il a toutefois déclaré en 2012 que sa contribution personnelle consistait désormais principalement à intégrer du code écrit par d'autres, et qu'il ne programmait plus que très peu. Il conserve le pouvoir suprême de décider quels nouveaux codes sont intégrés au noyau Linux standard.

Début juillet 2026, Linus Torvalds s'est exprimé sur la plus-value de l'IA dans le noyau Linux et dit « Oui à l'IA, mais l'expertise des développeurs humains est requise pour corriger les patchs et les rapports de bogue générés ». Elle s’avère être une redite de prises de positions précédentes dans lesquelles il souligne qu’il voit l’intelligence artificielle comme un meilleur outil pour les revues que pour la génération de code et que, dans un cas comme dans l’autre, l’apport des développeurs humains est nécessaire pour corriger les productions de l’IA. Sa sortie intervient dans un contexte de divisions dans la filière autour de la mise à contribution de l’IA. En effet, certains projets optent pour l’interdiction des outils dits d’intelligence artificielle.

Récemment, Linus Torvalds s'est de nouveau exprimé sur la place de l'IA dans le développement du noyau Linux. Il invite notamment les détracteurs de l’IA à créer une branche dérivée de Linux ou à s’en aller. La position de Linus Torvalds vis-à-vis de l’IA semble s’assouplir. Après avoir souligné qu’en 2024, la technologie de l’IA relevait à 90 % du marketing et à 10 % de la réalité factuelle, Torvalds vient de déclarer que Linux n’est pas un projet « anti-IA », et que toute personne qui y voit un problème peut soit s’en détourner, soit créer un fork du noyau.

Les commentaires de Torvalds font suite à une discussion sur les sentiments anti-LLM sur lore.kernel.org, les archives publiques officielles des listes de diffusion consacrées au développement du noyau Linux. Il a déclaré que, bien qu’il soit conscient que certaines personnes détestent vraiment l’IA, c’est un domaine dans lequel il est prêt à « mettre absolument le holà en tant que responsable principal ». « Linux ne fait pas partie de ces projets anti-IA, et si cela pose problème à quelqu’un, il peut agir dans l’esprit de l’open source et créer une branche. Ou tout simplement se retirer. »

Le créateur de Linux a ajouté que l’IA est un outil, comme n’importe quel autre, et un outil utile qui plus est. Il a précisé que même si d’autres questions se posent autour de l’IA, telles que son impact économique à terme, la question de savoir « si elle est utile » ne fait plus partie de ces interrogations. L’IA peut être un « outil quelque peu pénible, tant en raison de la charge de travail qu’elle impose aux responsables de la maintenance que du simple fait qu’elle ne cesse de dénicher des bogues embarrassants », a déclaré Torvalds. « Mais la solution n’est pas de faire l’autruche et de chanter “La La La, je ne t’entends pas” à tue-tête comme certaines personnes semblent le faire. »

Torvalds a admis que l’IA n’était pas parfaite, mais il estime que quiconque souligne les problèmes de cette technologie ferait mieux de se regarder dans le miroir et de se pointer du doigt en même temps. « Parce que ce n’est pas comme si l’intelligence naturelle était toujours si formidable non plus », a-t-il ajouté. Il a également affirmé : « Nous n’obligeons personne à l’utiliser, mais j’ignorerai haut et fort ceux qui tentent de dissuader les autres de s’en servir. »

L’ingénieur logiciel finlandais semblait adopter une approche plus prudente vis-à-vis de l’IA en 2024. Outre le fait de déplorer qu’il s’agissait à 90 % d’un battage marketing, il avait déclaré qu’il faudrait cinq ans pour que l’on comprenne clairement à quoi servait réellement l’IA. Il semble que cette utilité soit devenue évidente dans un délai plus court que prévu. En janvier, Torvalds a déclaré avoir commencé à utiliser l’IA pour écrire du code, mais uniquement dans le cadre d’un petit projet personnel et non sur Linux.

Quelques mois plus tard, il a critiqué les développeurs Linux pour avoir soumis des rapports de bogues inopportuns peu avant la sortie de la version RC5, soulignant que certains s’appuyaient sur l’IA pour signaler des problèmes insignifiants. Il a ajouté que bon nombre des correctifs proposés étaient également générés par l’IA et introduisaient souvent un encombrement inutile dans le noyau Linux au lieu de résoudre le problème sous-jacent.

Les commentaires de Torvalds suggèrent que l’IA a déjà dépassé le stade expérimental pour Linux, même si les développeurs sont encore confrontés à la charge de travail supplémentaire, aux correctifs discutables et à l’alourdissement occasionnel du noyau qu’elle engendre. L'avenir nous dira si l'IA trouvera sa place dans le noyau Linux ou pas. En attendant, la communauté Linux a déjà formellement adopté début 2026 le tout premier plan de succession de Linus Torvalds, plus de 34 ans après le lancement du noyau Linux.

Lors de l'annonce de la de la version 7.0 RC1 du noyau Linux, Linus Torvalds a plaisanté sur sa succession à la tête du noyau. « Comme la plupart des gens l'ont compris, j'en arrive à un point où je suis dérouté par les grands nombres (je n'ai presque plus assez de doigts et d'orteils), donc le prochain noyau s'appellera 7.0 », a-t-il écrit au début du mois. Il a déclaré cette fois-ci ne pas avoir de plan clair pour le jour où le numéro majeur lui-même deviendra trop grand à gérer. Linus Torvalds a laissé entendre que ce sera le problème d'un successeur « plus compétent » que lui.

Voici le message de Linus Torvalds :

Oui.

Et non, ce n’est pas la position du noyau Linux.

Je comprends que certaines personnes aient une réelle aversion pour l’IA, mais c’est un domaine sur lequel je suis prêt à m’opposer fermement en tant que responsable principal.

Linux ne fait pas partie de ces projets anti-IA, et si cela pose problème à quelqu’un, il peut agir dans l’esprit de l’open source et créer un fork.

Ou tout simplement s’en aller.

L’IA est un outil, tout comme les autres outils que nous utilisons. Et c’est clairement un outil utile.

Cela n’était peut-être pas aussi « évident » il y a encore un an, mais cela ne fait plus aucun doute aujourd’hui.

D’autres questions se posent autour de l’IA (comme celle de savoir à quoi ressemblera réellement son économie à terme), mais « est-elle utile ? » ne fait plus partie de ces questions. Quiconque en doute n’a manifestement jamais eu l’occasion de l’utiliser.

Oui, cela peut aussi être un outil quelque peu pénible, tant en raison de la charge de travail qu’il impose aux responsables de la maintenance que du simple fait qu’« il ne cesse de dénicher des bugs embarrassants ».

Mais la solution n’est pas de faire l’autruche et de chanter « La La La, je ne t’entends pas » à tue-tête comme certaines personnes semblent le faire.

La solution consiste à s’assurer que ces outils LLM aident les responsables de la maintenance au lieu de leur causer uniquement des soucis. Il n’y a aucun doute là-dessus.

Nous n’obligeons personne à l’utiliser, mais j’ignorerai haut et fort ceux qui tentent de dissuader les autres de s’en servir.

Et non, l’IA n’est pas parfaite. Mais bon sang, ceux qui soulignent les problèmes de l’IA feraient mieux de se regarder dans le miroir et de pointer du doigt leur propre comportement en même temps.

Car ce n’est pas comme si l’intelligence naturelle était toujours si formidable que ça non plus.

Le projet du noyau a toujours porté et continuera de porter sur la technologie.

Bien sûr, l’aspect social du travail sur l’open source est important et constitue souvent un élément très motivant du projet, mais en fin de compte, c’est un avantage secondaire, pas l’_objectif_ du projet.

Il ne s’agit *PAS* d’une sorte de projet « militant social », cela n’a jamais été le cas et ne le sera jamais.

Au sein de la communauté du noyau, nous pratiquons l’open source parce que cela aboutit à une meilleure technologie, et non pour des raisons idéologiques.

Nous prenons donc nos décisions principalement en fonction de leur mérite technique. Et non par crainte des nouveaux outils.


Source : Message de Linus Torvalds

Et vous ?

Pensez-vous que ce message est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

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.

« Rust sauvera Linux de l'IA », affirme Greg Kroah-Hartman dans le cadre d'une critique de l'usage de l'intelligence artificielle pour trouver les bogues au sein du code du noyau écrit en langage C

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

[calvaire]

Il faut arrêter de nier l'évidence : l'IA n'est plus un gadget. Je l'utilise de plus en plus dans mes workflows, et ceux qui la snobent par purisme ont simplement un train de retard. Les LLM ont passé un cap monumental.
Même Greg Kroah-Hartman, pilier ultra-exigeant du noyau Linux, a lui aussi changé d'avis. Pour lui, les rapports de bugs et revues de code assistés par IA sont devenus excellents. Il l'a dit cash :
Il y a eu un moment, il y a quelques mois, où « le monde a basculé » et les rapports générés par l'IA sont devenus « bons et réels ».

Et quand je vois les failles de sécurités massives en nombre corrigé ces 2 derniers mois sur plusieurs logiciels (firefox, windows...) comme par hasard juste après l'utilisation de mythos

[Anselme45]

Même Greg Kroah-Hartman, pilier ultra-exigeant du noyau Linux, a lui aussi changé d'avis. Pour lui, les rapports de bugs et revues de code assistés par IA sont devenus excellents. Il l'a dit cash :
Il y a eu un moment, il y a quelques mois, où « le monde a basculé » et les rapports générés par l'IA sont devenus « bons et réels ».

Amusant, ce même site rapportait il n'y a que quelques jours en arrière que les rapports de bugs issus de l'IA étaient proscrits par le projet Linux parce que de mauvaises qualités!!!

Ces rapports étaient pléthoriques, redondants et rapportaient même des bugs qui n'existaient pas!!!

Auriez-vous une lecture sélective depuis Singapour? C'est le décalage horaire? La mauvaise foi? Un strabisme naissant?

[Anselme45]

Il y a peu le sieur Linus Torvalds niait l'intérêt de l'IA pour le projet Linux et voilà que le monsieur change d'avis tel les hélices d'une éolienne...

Dans combien de temps, les médias vont nous annoncer que le monsieur a reçu des offres alléchantes et financières de quelques promoteurs de l'IA?

[fdecode]

Amusant, ce même site rapportait il n'y a que quelques jours en arrière que les rapports de bugs issus de l'IA étaient proscrits par le projet Linux parce que de mauvaises qualités!!!

Ce site dit ce qu'il veut. En attendant, les IA progressent effectivement très vite. Et même si le problème de détection de bug est théoriquement indécidable, les IA actuelles se débrouillent très bien pour détecter certaines erreurs. Un outil complémentaire, en somme.

[fdecode]

Il faut arrêter de nier l'évidence : l'IA n'est plus un gadget.

Se retrouver avec 5 dislikes en ayant simplement rapporté un fait... Vous n'êtes pas très aimé calvaire.

[calvaire]

Se retrouver avec 5 dislikes en ayant simplement rapporté un fait... Vous n'êtes pas très aimé calvaire.

la vérité n'est pas aimé.
et dans ce forum j'ai le sentiment que beaucoup sont encore dans l'ancien monde.

Ils confondent le faite de déplorer les conséquence et le réel: c'est un mal nécessaire.
L'ia pose de gros problemes d'acces aux ressources, d’inégalités sociale, de hausse du chomage...etc, oui.

Mais ne pas foncer dans l'ia c'est prendre le risque d'etre has been.
Plus personne aujourd'hui ne veut payer un développeur et un projet logiciel qui refuse l'ia, un outil qui boost sa productivité de 10-50% aucun patron ne s'en prive.
En dehors du code, Linux a besoin de Mythos et autre ia spécialisé, si ils ne le font pas d'autre le feront et s'en serviront non pas pour fixer les failles mais pour les exploiter.

Et comme toute entreprises, si tu n'utilises pas l'ia, d'autres vont le faire et vont te piquer tes contrats.
Et a l'échelle des super puissance, si tu fais pas de l'ia, d'autres nations vont le faire et vont te dépasser et te dominer. C'est la guerre froide, et une course à l'arme nucléaire, pas le choix il faut la plus grosse. Les chinois,/russes/américains ne vont pas se priver de créer et déployer des flottes de drones IA.
Partout ou l'UE a imposé des restrictions environnementale, la chine a pris le dessus, aujourd'hui les européens consomme de la voitures chinoise et demain ce sera des avions chinois. Oui "la voiture et l'avion sa pollue", c'est horrible, mais le chômage de masse et consommer chinois c'est pas mieux.

[Anselme45]

Ce site dit ce qu'il veut. En attendant, les IA progressent effectivement très vite. Et même si le problème de détection de bug est théoriquement indécidable, les IA actuelles se débrouillent très bien pour détecter certaines erreurs. Un outil complémentaire, en somme.

Ce site ne dit pas ce qu'il veut, il ne fait que rapporter les commentaires et résultats d'études menées à travers le monde dans l'industrie numérique!!!

Maintenant si vous vous proposez de faire un tri qualitatif des articles: Du genre "les articles Pro-IA, c'est la vérité", "les articles anti-IA ne sont que des fake news", libre à vous!

Vous ne serez pas le premier à accepter les informations que lorsqu'elles viennent confirmer vos "a priori"... Je vous invite à rejoindre le club Trump, il pourra même vous apprendre quelques trucs supplémentaires comme "ré-écrire la réalité"!!!