Le sous-système réseau Linux submergé par les patches IA — les mainteneurs imposent la règle des trois secondes

6 août 2026, Phoronix, Linux Networking, règle des trois secondes. Le 6 août 2026, le mainteneur du sous-système WiFi Linux a officialisé une nouvelle doctrine de revue de code : la règle des trois secondes. Si un patch ne passe pas l’examen visuel en moins de trois secondes — autrement dit, s’il ne saute pas aux yeux comme un correctif légitime — il est rejeté sans autre forme de procès. La raison ? Une avalanche de patches générés par IA/LLM qui noie les boîtes de réception des mainteneurs réseau depuis le début de l’année 2026.

Cette annonce fait suite à la décision, intervenue le 4 août, de Greg Kroah-Hartman — le numéro deux du noyau Linux — de rejeter systématiquement les patches générés par LLM dans la zone staging, sauf s’il s’agit de correctifs de sécurité authentiques. Mais la zone staging est un sas d’entrée pour les nouveaux contributeurs. Le sous-système réseau, lui, gère du code de production qui fait tourner des routeurs, des commutateurs, des pare-feux et des clouds entiers.

Un sous-système réseau sous siège

Phoronix rapporte que le sous-système Linux Networking continue d’être « bombardé » de patches IA. Le problème est structurel :

• Les agents de codage IA (Devin, Copilot, Codex, Cursor, etc.) génèrent des patches en masse à partir de rapports d’outils d’analyse statique.
• Ces patches corrigent souvent des faux positifs ou des problèmes cosmétiques (typos, style de code) sans apporter de valeur fonctionnelle.
• Chaque patch soumis exige du mainteneur qu’il lise, comprenne le contexte, et décide — un processus qui prend 5 à 15 minutes par patch pour un humain expérimenté.

Quand une boîte de réception reçoit 50 patches IA par semaine, le temps de revue consacré au slop (terme utilisé par les mainteneurs pour désigner le bruit IA) dépasse le temps disponible pour les vrais correctifs — ceux qui corrigent des fuites mémoire, des corruptions de paquets ou des CVE.

Kalle Valo, mainteneur du sous-système ath12k (pilote WiFi Qualcomm), a été le premier à quantifier le problème publiquement. Sur la liste de diffusion linux-wireless, il a indiqué que plus de 60 % des patches reçus sur une période de deux semaines en juillet 2026 étaient identifiables comme générés par IA — et qu’aucun d’entre eux ne corrigeait un bogue réel.

Comment reconnaître un patch IA en trois secondes

La règle des trois secondes n’est pas arbitraire. Les mainteneurs réseau ont développé des heuristiques de reconnaissance rapide :

• Commit message générique : « Fix potential null pointer dereference » sans explication du chemin d’exécution réel.
• Patch cosmétique sans contexte : correction de typo dans un commentaire, renommage de variable sans impact fonctionnel.
• Faux positif d’analyseur statique : le patch « corrige » un avertissement de Coverity ou Sparse sans comprendre que le code est correct en l’état.
• Absence de signature humaine : le contributeur n’a jamais soumis de patch auparavant, son adresse email est jetable, et le patch arrive sans discussion préalable sur la liste.
• Structure de patch trop propre : un vrai développeur laisse des traces d’itération (v2, v3, changelog). Un patch IA est souvent un one-shot parfaitement formaté.

Kalle Valo a résumé la doctrine ainsi : « Si je ne peux pas comprendre ce que fait le patch en trois secondes, je le rejette. Si le contributeur est légitime, il reviendra avec une explication. L’IA, elle, ne revient jamais. »

Le coût réel du slop pour l’infrastructure réseau

Le problème n’est pas anecdotique. Le sous-système réseau de Linux est la colonne vertébrale d’Internet. Chaque ligne de code qui y entre affecte potentiellement des millions de serveurs, des routeurs BGP, des équilibreurs de charge et des infrastructures cloud. Un patch incorrect dans net/core ou net/ipv4 peut causer une panne réseau mondiale — le souvenir de la régression TCP SACK de 2019 est encore frais.

Le risque n’est pas que l’IA produise un patch malveillant — personne n’accuse les agents de codage de sabotage. Le risque est qu’elle produise un patch plausible mais incorrect, qui passe une revue rapide un vendredi soir, et qui introduit une corruption silencieuse découverte six mois plus tard lors d’un incident de production.

David Miller, mainteneur historique du sous-système réseau, a toujours appliqué une politique de revue stricte. Mais la charge de travail supplémentaire imposée par les patches IA menace de ralentir l’intégration des vrais correctifs — y compris les correctifs de sécurité urgent. C’est le paradoxe : l’IA, conçue pour accélérer le développement, ralentit en réalité la maintenance du code critique.

La réponse de la communauté : filtrage et automatisation

Face à cette situation, plusieurs initiatives émergent pour protéger le processus de contribution :

• Filtrage par réputation : les mainteneurs commencent à ignorer les patches provenant d’adresses email sans historique de contribution. C’est discriminatoire envers les nouveaux contributeurs légitimes, mais pragmatique.
• Bot de pré‑revue : un bot qui détecte les signatures typiques des patches LLM (patterns de commit message, similarité avec des patches connus) et les marque comme NEEDS-HUMAN-REVIEW.
• Liste blanche de domaines : certaines listes de diffusion envisagent de n’accepter les patches que depuis des domaines d’entreprises ou d’institutions vérifiées.
• patcheck-ai : un script en cours de développement par la communauté pour détecter automatiquement les patches suspects avant qu’ils n’atteignent les mainteneurs.

Aucune de ces solutions n’est idéale. Toutes imposent une friction supplémentaire aux vrais contributeurs, ce qui va à l’encontre de l’éthique d’ouverture du noyau Linux. Mais l’alternative — laisser le sous-système réseau se faire submerger — est pire.

Pourquoi le réseau est plus exposé que les autres sous-systèmes

Le sous-système réseau est particulièrement vulnérable au slop IA pour trois raisons structurelles :

1. Haute visibilité : les outils d’analyse statique (Coverity, Sparse, Coccinelle) scannent le code réseau en priorité parce que c’est du code à haute surface d’attaque. Chaque alerte génère un patch IA potentiel.
2. Complexité modérée : contrairement au scheduler ou à la gestion mémoire, le code réseau est souvent auto-contenu (un pilote, un protocole). L’IA peut produire des patches syntaxiquement corrects sans comprendre la sémantique.
3. Mainteneurs sous-dimensionnés : le ratio mainteneurs/contributeurs est plus faible dans le sous-système réseau que dans d’autres parties du noyau. Chaque mainteneur gère plusieurs pilotes et protocoles simultanément.

Johannes Berg, co‑mainteneur du sous-système WiFi, a résumé la situation avec une franchise désarmante sur la liste linux-wireless : « Je passe désormais plus de temps à rejeter des patches IA qu’à écrire du code. Ce n’est pas pour ça que je me suis porté volontaire. »

Verdict

Si vous gérez une infrastructure réseau qui dépend du noyau Linux — et c’est le cas de 99 % des routeurs, commutateurs et appliances réseau dans le monde —, vous devez intégrer cette réalité dans votre gestion des risques :

• Suivez les branches stables (linux-stable) et appliquez les mises à jour dans les 48 heures. Les correctifs de sécurité passent encore, mais le bruit IA ralentit tout le reste.
• Participez au financement des mainteneurs réseau. David Miller, Jakub Kicinski, Kalle Valo et Johannes Berg sont les derniers remparts entre votre infrastructure et le slop — et ils travaillent bénévolement ou avec un soutien corporate limité.
• N’utilisez pas d’agents IA pour générer des patches kernel sans revue humaine. Si vous le faites, appliquez la règle des trois secondes vous‑même avant de soumettre.

La communauté Linux a survécu à Microsoft, aux trolls des brevets et aux supply chain attacks. Elle survivra aux patches IA — mais seulement si les mainteneurs réseau reçoivent le soutien financier et humain qu’ils méritent. La règle des trois secondes est un symptôme, pas une solution.

Références

• Phoronix — Linux Wireless Maintainer Takes Firm Stance Against AI/LLM Generated Slop Patches, 6 août 2026
• Phoronix — Linux Networking Continues Being Bombarded With AI Patches, 6 août 2026
• Phoronix — Linux Staging Area To Now Reject LLM-Generated Patches, 4 août 2026
• Liste de diffusion linux-wireless, archives consultées le 6 août 2026