En mai 2026, pendant le cycle de développement de Linux 7.1-rc4, Linus Torvalds sort de son silence habituel sur la liste privée de sécurité du noyau. Le constat est bref et brutal : la liste est devenue « almost entirely unmanageable », presque entièrement ingérable.
La cause identifiée : un flot de rapports de vulnérabilités générés par IA, massivement dupliqués. Plusieurs chercheurs ou outils automatisés trouvant les mêmes bugs potentiels avec les mêmes outils, reportant la même chose sans coordination ni validation préalable.
C’est un cas documenté et vérifiable. Ce n’est pas un cas isolé. Et il mérite d’être lu lentement, sans le réduire ni dans un sens ni dans l’autre.
Ce qui s’est passé, exactement
La liste de sécurité privée du noyau Linux est l’endroit où les chercheurs en sécurité rapportent des vulnérabilités avant qu’elles soient rendues publiques. C’est un mécanisme de responsible disclosure : vous trouvez une faille, vous la signalez aux mainteneurs, ils la corrigent, puis elle est publiée. Ce processus protège les utilisateurs pendant la fenêtre de correction.
Le problème rapporté en mai 2026 : des outils d’analyse statique ou d’audit de code basés sur des LLM ont été utilisés par plusieurs acteurs indépendants pour analyser le code du noyau. Ces outils ont identifié les mêmes patterns de vulnérabilités potentielles. Plusieurs d’entre eux ont été reportés en parallèle, par des personnes différentes, sans vérification que le bug était réel ou qu’il n’avait pas déjà été reporté.
Le résultat : une liste privée inondée de signalements dont une fraction seulement correspond à des vulnérabilités réelles, et dont beaucoup sont des doublons. Pour les mainteneurs bénévoles de la sécurité du noyau, chaque rapport doit être lu, évalué, trié.
Le steelman : l’IA trouve aussi de vrais bugs
La nuance est importante, et les mainteneurs eux-mêmes l’ont soulignée. L’IA ne génère pas que du bruit. Des vulnérabilités réelles ont été trouvées par ces outils automatisés. Des bugs qui auraient pu passer inaperçus pendant des années ont été identifiés grâce à des analyses statiques à grande échelle.
C’est le progrès honnête à reconnaître. Les outils d’analyse basés sur l’IA ont une capacité réelle à scanner de grandes bases de code en profondeur, avec une couverture qu’un humain ne peut pas atteindre manuellement. C’est un gain.
Le problème n’est pas l’IA dans l’audit de sécurité. Le problème est l’usage sans filtrage, sans validation, sans coordination. L’IA baisse le coût de trouver des bugs potentiels. Elle ne baisse pas, elle augmente même, le coût de les valider si personne n’assume cette étape.
Les mainteneurs du noyau notent que si certains rapports générés par IA identifient de vrais problèmes, la majorité sont des faux positifs ou des doublons de problèmes déjà connus. Le volume a rendu le tri « presque entièrement ingérable ».
Ce que ce cas illustre : le coût externalisé
C’est l’angle que la plupart des analyses passent sous silence. L’IA qui génère des rapports de sécurité à la chaîne transfère un coût. Elle réduit le coût pour celui qui génère les rapports. Elle augmente le coût pour ceux qui doivent les recevoir, les lire, les trier, les valider.
Ce pattern se retrouve partout où l’IA est utilisée pour produire du volume sans responsabilité sur la qualité :
- Les outils IA de génération de contenu qui inondent les boîtes mail de « cold outreach » personnalisé en masse
- Les générateurs de code qui créent des PRs à la chaîne sur des projets open source, obligeant les mainteneurs à trier
- Les outils de génération de litige juridique qui produisent des mémoires citant des jurisprudences inexistantes, forçant les juges à filtrer
Dans chaque cas, le coût de la vérification est externalisé sur un tiers qui n’a pas choisi de le porter.
Linus Torvalds et l’IA : ne pas sur-interpréter
Torvalds est souvent cité comme critique de l’IA. Sa déclaration la plus connue : « 90% marketing, 10% reality », prononcée en octobre 2024 à l’Open Source Summit de Vienne (source : The Register). C’est un propos général sur le hype, pas une condamnation de la technologie.
Sa réaction sur la liste de sécurité du noyau en mai 2026 est spécifique à un problème précis : le volume non filtré. Ce n’est pas une position anti-IA. C’est la réaction prévisible d’un mainteneur face à une dégradation de signal dans un canal critique.
Il serait aussi faux de dire « Torvalds condamne l’IA » que de dire « l’IA résout les problèmes de sécurité ». Les deux sur-simplifient.
Ce que ça dit sur le déploiement de l’IA en entreprise
Le pattern Linux est devant vous dans n’importe quelle entreprise qui déploie un outil IA de détection d’anomalies, d’audit ou de compliance. L’outil détecte à grande échelle. Quelqu’un doit trier, valider, prioriser. Si la chaîne de triage n’est pas dotée en humains avant le déploiement, l’outil produit 500 signalements par semaine que personne ne lit. Le bénéfice de l’automatisation disparaît dans le coût caché du triage non assumé. Et passe parfois en perte nette quand un vrai signal se noie dans le bruit. Les vendeurs d’outils IA n’ont aucun intérêt à mettre cette règle en avant. C’est précisément pour ça qu’elle devrait être la première question du dossier.