Linus Torvalds affirme que les énormes mises à jour du noyau Linux sont devenues la nouvelle norme avec l’IA

Linus Torvalds a accepté une nouvelle réalité difficile : les revues assistées par IA produisent davantage de correctifs pour le noyau Linux que les mainteneurs n’en ont traditionnellement traité en fin de cycle de publication. Ce changement est de nouveau apparu durant les tests de Linux 7.2, où des mises à jour inhabituellement volumineuses se sont poursuivies jusqu’aux sixième et septième versions candidates.

L’histoire relayée par Google News ne se résume pas au fait que l’IA a trouvé des bogues dans Linux. Les outils d’IA ont modifié le volume et le calendrier des correctifs proposés, créant une tension entre une détection plus large des bogues et une ingénierie des versions maîtrisée.

Cette tension est importante, car Linux sous-tend les plateformes cloud, les appareils Android, les serveurs, les équipements réseau, les environnements de développement et les systèmes embarqués. Davantage de défauts détectés peuvent améliorer ces systèmes, mais chaque modification acceptée crée aussi une occasion supplémentaire de régression.

Torvalds n’adopte donc ni une position anti-IA ni une position favorable à l’automatisation sans restriction. Sa règle émergente est plus exigeante : utiliser l’IA, comprendre ses résultats, soumettre un travail utile et préserver la responsabilité humaine tout au long du processus.

Linux 7.2 a rendu visible cette nouvelle charge de travail

La taille des versions candidates tardives de Linux 7.2 montre que la revue assistée par IA est devenue un enjeu opérationnel, et non un débat pour l’avenir.

Torvalds a qualifié Linux 7.2-rc6 d’« énorme » dans sa mise à jour du 2 août. Il a indiqué qu’elle semblait être la plus grande sixième version candidate depuis des années, si l’on se fie au nombre de commits.

Une version candidate, ou RC, est une version de test publiée avant une version stable du noyau. Les versions candidates les plus tardives devraient normalement réduire le travail restant aux régressions et aux défauts graves.

Le volume n’est pas revenu à des niveaux habituels une semaine plus tard. Dans le message annonçant Linux 7.2-rc7, Torvalds a déclaré ne pas être enthousiasmé par sa taille.

Il a néanmoins décrit cette mise à jour comme la « nouvelle norme », de nombreux correctifs résultant de revues menées par divers outils d’IA. Le rapport sur Linux 7.2 a également relevé que les correctifs étaient répartis entre les pilotes, les systèmes de fichiers, le réseau et le code propre à certaines architectures.

La plupart des modifications étaient modestes. Torvalds a identifié trois domaines plus importants liés à la prise en charge cryptographique s390, à l’infrastructure Btrfs et aux ensembles d’IP Netfilter, sans pour autant qualifier la version candidate de dangereuse.

Cette distinction est importante. Un vaste ensemble de correctifs n’est pas automatiquement un mauvais ensemble de correctifs, et un défaut détecté par l’IA n’est pas automatiquement une réparation écrite par l’IA.

La préoccupation immédiate concerne le risque cumulatif. Des centaines de modifications individuellement modestes peuvent exiger un travail considérable de revue, de tests, d’acheminement et de suivi.

Le développement de Linux répartit cette charge entre les mainteneurs de sous-systèmes. Ces mainteneurs connaissent des domaines précis, collectent les correctifs, les évaluent et envoient des pull requests vers le noyau principal.

L’IA peut accélérer la détection sans élargir cette structure de revue humaine au même rythme. Elle peut produire des pistes en continu, tandis que l’attention des mainteneurs et les échéances de publication restent limitées.

Torvalds n’a pas jugé les modifications de Linux 7.2 suffisamment graves pour justifier un report. Il prévoyait que la version stable arriverait le week-end suivant, sauf apparition d’un nouveau problème important.

Cette décision sépare le volume de la gravité. Linux 7.2 était volumineux, mais ses modifications connues restaient suffisamment gérables pour le processus de publication établi.

Elle fait également de cette version un test utile. Si une version candidate volumineuse influencée par l’IA est publiée sans régressions graves, ses défenseurs disposeront d’éléments montrant que le flux de travail peut absorber davantage de résultats.

Si des problèmes apparaissent plus tard, le débat s’orientera vers des contrôles de calendrier et d’admission plus stricts. La question centrale n’est plus de savoir si l’IA a sa place dans le développement du noyau. Elle est de savoir où le travail généré par l’IA doit s’inscrire dans le calendrier de publication.

Pourquoi les revues par IA génèrent davantage de modifications du noyau

L’IA modifie l’économie de la détection du code suspect, mais elle ne supprime pas le travail coûteux nécessaire pour valider et intégrer un correctif.

Un développeur devait autrefois consacrer beaucoup de temps à examiner un code inconnu, suivre le flux de contrôle et rechercher des cas limites négligés. Un outil d’IA peut désormais signaler des conditions douteuses dans une base de code bien plus vaste.

Certains systèmes fonctionnent comme des assistants de revue de code. D’autres combinent des modèles de langage et le fuzzing, une méthode de test qui envoie des entrées inattendues à un logiciel afin de révéler des plantages ou des erreurs de mémoire.

Ces outils sont particulièrement adaptés à la détection de petites incohérences. Ils peuvent repérer des vérifications manquantes, des chemins d’erreur inhabituels, des motifs répétés et des hypothèses incompatibles entre des fonctions associées.

Linux offre de nombreuses occasions de ce type, car il prend en charge une variété exceptionnelle de matériels et de charges de travail. Ses pilotes, systèmes de fichiers, composants réseau et code spécifique aux processeurs reflètent des décennies de décisions d’ingénierie.

L’IA n’a pas besoin d’inventer un nouveau sous-système pour accroître le volume de correctifs. Il suffit qu’elle trouve une condition négligée dans chacun de nombreux composants existants.

Ce mécanisme explique pourquoi la mise à jour actuelle peut être à la fois énorme et composée principalement de minuscules correctifs. L’automatisation élargit la surface de recherche, puis injecte davantage de défauts potentiels dans les flux de travail humains établis.

Greg Kroah-Hartman, mainteneur du noyau stable Linux, a fourni un exemple concret. Son chasseur de bogues assisté par IA, exploité localement, aurait contribué à près de deux douzaines de correctifs fusionnés depuis avril.

Le système fonctionnait sur un ordinateur de bureau Framework équipé d’un processeur AMD Ryzen AI Max+. Selon un récit consacré au chasseur de bogues local, il testait localement les composants du noyau plutôt que d’envoyer le code à un service cloud.

Ce déploiement est important pour les projets traitant du code sensible ou non publié. Les modèles locaux peuvent réduire l’exposition des données, même s’ils ne résolvent pas les questions relatives aux données d’entraînement, aux licences ou à la qualité des résultats.

Le flux de travail de Kroah-Hartman illustre également la répartition des tâches. L’outil aurait détecté des problèmes potentiels, tandis qu’il examinait les résultats, préparait les correctifs et assumait la responsabilité des soumissions.

Ses déclarations de correctifs utilisaient un tag « Assisted-by ». Ce tag consigne l’intervention de l’automatisation sans prétendre que le logiciel peut assumer les conséquences d’une mauvaise modification.

Cette approche est très éloignée du fait de demander à un chatbot de générer un correctif puis de transférer sa réponse telle quelle. Elle considère l’IA comme un instrument de test particulièrement productif.

Cette distinction disparaît souvent dans les titres Google News sur le codage par IA. « Code généré par IA » peut décrire plusieurs activités aux profils de risque très différents.

Un modèle peut résumer un correctif, signaler du code suspect, produire un reproducer, proposer une réparation ou écrire l’essentiel d’un nouveau composant. Regrouper ces activités sous une seule étiquette masque les véritables contrôles d’ingénierie.

Pour Linux, le cas d’usage initial le plus solide semble être une assistance encadrée. Un mainteneur choisit une cible, exécute un outil, examine les éléments, rédige ou vérifie la réparation, puis la fait passer par la revue habituelle.

Le cas d’usage le plus faible est la détection opportuniste. Une personne soumet du code public à un modèle généraliste, transfère tout ce qu’il signale et laisse les mainteneurs déterminer si le problème est réel.

Les deux flux de travail augmentent le nombre de messages. Un seul apporte systématiquement le contexte et l’appropriation nécessaires pour transformer une observation de machine en logiciel fiable.

La capacité des mainteneurs constitue désormais le véritable goulot d’étranglement

La principale contrainte est passée de la détection de défauts potentiels à la décision de savoir quels résultats méritent l’attention limitée des mainteneurs.

Linux utilise depuis longtemps un processus de revue hiérarchique, car aucune personne seule ne peut évaluer chaque modification. Les contributeurs travaillent avec les mainteneurs de sous-systèmes, qui filtrent et regroupent les correctifs avant que Torvalds ne les reçoive.

L’IA peut générer des résultats plus vite que cette hiérarchie ne peut recruter des réviseurs expérimentés. Le déséquilibre qui en résulte exerce une pression sur les mainteneurs plutôt que sur les modèles produisant la sortie initiale.

Cette pression devient particulièrement visible à la fin d’un cycle de publication. Le développement du noyau commence normalement par une fenêtre de fusion pour les travaux planifiés, suivie de versions candidates de plus en plus centrées sur la stabilisation.

Un correctif valable mais non urgent peut tout de même être inapproprié durant une version candidate tardive. Modifier du code stable pour traiter un cas limite ancien peut introduire une régression juste avant la publication.

Torvalds a souligné ce point durant le développement de Linux 7.1. Après une cinquième version candidate inhabituellement volumineuse, il a déclaré qu’il deviendrait plus sélectif concernant les pull requests contenant des correctifs de faible priorité.

Plusieurs séries de correctifs avaient été déclenchées par une revue par IA. Sa préoccupation n’était pas que les défauts identifiés soient imaginaires, mais que leur calendrier crée une agitation inutile.

L’avertissement de fin de cycle soulignait que même les correctifs triviaux comportent un risque non nul. Torvalds souhaitait que les mainteneurs distinguent les régressions des problèmes plus anciens pouvant attendre une autre fenêtre de fusion.

Il s’agit de l’ingénierie conventionnelle des versions appliquée à une hausse inhabituelle de la détection. La bonne réponse n’est pas nécessairement de réduire le nombre de correctifs. C’est d’améliorer leur planification.

Le même principe devrait compter pour les équipes d’ingénierie en entreprise qui adoptent la revue par IA. La capacité d’un outil à détecter davantage de problèmes ne signifie pas que chaque résultat a sa place dans la version en cours.

Les équipes ont besoin de seuils de gravité, de règles de responsabilité, de déduplication et d’échéances pour les modifications non critiques. Sans ces contrôles, des taux de détection plus élevés peuvent affaiblir la prévisibilité des livraisons.

Les fournisseurs d’IA évaluent souvent les outils de codage à l’aide de mesures d’accomplissement des tâches. Les mainteneurs font face à un autre ensemble de résultats : temps de revue, faux positifs, travail dupliqué, régressions et suivi non résolu.

Ces mesures opérationnelles déterminent si un réviseur IA apporte une valeur nette. Un outil qui identifie dix défauts réels tout en consommant des semaines d’attention experte peut être moins performant qu’un système plus ciblé.

L’expérience Linux remet également en cause l’hypothèse selon laquelle la productivité du codage par IA appartient aux développeurs individuels. La vitesse locale compte moins lorsque la file d’intégration partagée est surchargée.

Un contributeur peut générer davantage de correctifs, mais le projet a toujours besoin d’une personne de confiance pour les inspecter. Le gain de productivité ne devient réel qu’une fois que l’ensemble du système de revue a traité le travail.

Cela crée un difficile problème d’incitation. La personne qui soumet un rapport automatisé reçoit le crédit visible pour la découverte, tandis que les mainteneurs absorbent une grande partie du coût de vérification.

Les projets pourraient répondre en exigeant des soumissions plus solides. Un rapport utile pourrait nécessiter un reproducer, les versions affectées, une analyse technique, un correctif proposé et la preuve que l’auteur a vérifié l’absence de doublons.

L’IA peut également aider à accomplir ces tâches. L’exigence importante est que l’auteur reste impliqué au lieu de transférer à des bénévoles une sortie de machine non traitée.

Pour les lecteurs qui suivent le sujet via Google News, « davantage de correctifs » semble être une amélioration sans réserve. Au sein d’un projet logiciel mature, davantage de correctifs signifie aussi davantage de décisions concernant le risque, le calendrier et la responsabilité.

Le titre Google News masque une politique de l’IA à deux facettes

Torvalds accepte l’IA comme un outil d’ingénierie utile, tout en rejetant les workflows qui externalisent ses erreurs et ses doublons vers les mainteneurs.

Sa position peut sembler incohérente si l’on considère ses déclarations séparément. Il a critiqué le bruit généré par l’IA, défendu le droit d’utiliser l’IA et attribué à la revue automatisée la découverte de véritables défauts.

Ensemble, ces déclarations forment une politique cohérente. La valeur technique compte davantage que le fait qu’un humain ou une machine ait repéré un problème en premier, mais les contributeurs humains restent responsables de ce qui arrive dans le projet.

En mai, Torvalds a déclaré qu’un afflux de rapports de sécurité générés par l’IA avait rendu la liste privée de sécurité du noyau presque ingérable. Plusieurs personnes identifiaient les mêmes problèmes avec des outils similaires.

Les rapports en double créent davantage qu’un simple encombrement de boîte de réception. Quelqu’un doit les comparer, retrouver les discussions antérieures, identifier le bon sous-système et déterminer si un correctif existe déjà.

Torvalds a soutenu que de nombreux bugs détectés par l’IA ne devraient pas être automatiquement envoyés sur un canal privé. Si plusieurs outils publics peuvent trouver le même problème, traiter chaque résultat comme un secret peut empêcher les signalants de voir le travail déjà effectué.

Sa critique visait directement l’absence de valeur ajoutée. La surcharge de rapports de sécurité le montrait demander aux contributeurs de comprendre la documentation, de créer des correctifs et de s’appuyer sur le résultat automatisé.

Deux mois plus tard, il a tracé une limite tout aussi ferme face à l’opposition généralisée. Torvalds a déclaré que Linux n’était pas un projet anti-IA et a dit aux opposants que l’open source leur permettait de forker le code.

Il a décrit l’IA comme un outil, même si elle peut faire souffrir les mainteneurs et révéler des bugs embarrassants. Selon lui, la solution consiste à faire en sorte que les outils aident les mainteneurs.

Il ne s’agit pas d’approuver le développement autonome du noyau. Il s’agit d’approuver l’utilisation de l’automatisation dans le respect des normes techniques du projet.

Le conflit principal oppose donc une automatisation utile à une automatisation sans responsable. L’origine d’une découverte importe moins que la qualité des éléments de preuve et la responsabilité qui l’accompagne.

Ce cadre ressemble à la manière dont le noyau traite les autres outils. Compilateurs, analyseurs statiques, fuzzers, suites de tests et transformations scriptées peuvent tous générer ou influencer des changements.

Aucun d’entre eux ne devient mainteneur. Une personne identifiée soumet toujours le correctif, l’explique, répond aux critiques, révise le code et gère les problèmes ultérieurs.

Les modèles de langage compliquent cet arrangement, car leur sortie peut paraître convaincante sans être ancrée dans le comportement réel du code. Ils peuvent aussi générer des explications à une échelle qui submerge les réviseurs.

La divulgation aide, mais elle ne peut à elle seule garantir la qualité. Une étiquette « Assisted-by » indique aux réviseurs qu’un outil a participé ; elle ne prouve pas que le contributeur a compris le résultat.

Les interdictions rencontrent le problème inverse. Un projet peut interdire l’assistance de l’IA, mais il reste difficile de détecter les utilisations non déclarées. Des interdictions strictes peuvent encourager la dissimulation sans réduire les soumissions de faible qualité.

Torvalds a déjà soutenu que la documentation du noyau devrait se concentrer sur les contributeurs responsables plutôt que de devenir une déclaration politique sur l’IA. Le différend sur la documentation montrait sa préférence pour traiter l’IA comme un outil parmi d’autres tout en appliquant les normes existantes.

Cette position évite un test insoluble de paternité. Les réviseurs peuvent plutôt poser des questions qu’ils comprennent déjà : le correctif est-il correct, nécessaire, testé, clairement expliqué et soumis au bon moment ?

La politique reste exigeante parce que l’IA réduit le coût de production de réponses plausibles à ces questions. Les mainteneurs auront besoin de preuves, pas d’une prose soignée.

Un reproducer, un cas de test, un benchmark ou une trace a plus de poids qu’une explication assurée. Les contributeurs assistés par des outils doivent montrer comment ils ont vérifié leurs affirmations.

C’est la nuance qu’un bref résumé Google News peut manquer. Torvalds ne livre ni le développement de Linux aux modèles ni ne le protège de toute implication de l’IA.

Il permet à l’automatisation d’élargir la vision du projet tout en insistant pour que les humains continuent d’en porter le jugement.

Davantage de correctifs ne signifie pas automatiquement un noyau plus sûr

La découverte assistée par l’IA peut améliorer la sécurité, mais le volume de correctifs ne suffit pas à établir que le noyau résultant est plus sûr ou plus stable.

Un bug découvert n’est que le début d’un processus de réparation. Les ingénieurs doivent confirmer le comportement, évaluer son impact, concevoir un correctif, tester les configurations concernées et examiner si le changement crée un autre problème.

Linux rend ce travail particulièrement difficile, car un correctif peut affecter de nombreuses architectures, compilateurs, appareils et charges de travail. Une correction testée sur une machine peut se comporter différemment ailleurs.

De petits changements peuvent tout de même atteindre des chemins de code sensibles. La gestion des erreurs, la propriété de la mémoire, la concurrence et les transitions d’état matériel produisent souvent des défaillances qui n’apparaissent que dans de rares conditions.

Les outils d’IA peuvent identifier des motifs suggérant un défaut sans comprendre toutes les contraintes d’exécution. Leurs conclusions doivent donc être traitées comme des hypothèses jusqu’à ce que les tests les étayent.

Les faux positifs consomment du temps, mais la fausse confiance constitue le plus grand danger. Un correctif plausible peut faire taire un symptôme tout en laissant la cause profonde intacte.

L’automatisation peut également créer des erreurs corrélées. Si de nombreux chercheurs utilisent le même modèle ou la même méthode d’analyse, ils peuvent signaler des conclusions identiques et négliger des catégories de problèmes identiques.

Cette concentration réduit la diversité de la revue. Dix rapports automatisés ne fournissent pas dix perspectives indépendantes lorsqu’ils partagent les mêmes hypothèses sous-jacentes.

La divulgation de sécurité ajoute une autre complication. Signaler publiquement une vulnérabilité reproductible avant qu’un correctif soit prêt peut aider les attaquants autant que les défenseurs.

Torvalds a soutenu que placer automatiquement toutes les conclusions de l’IA sur une liste privée de sécurité crée des doublons. Pourtant, les déplacer vers des canaux publics exige un jugement attentif sur l’exploitabilité et les utilisateurs concernés.

Aucune règle universelle d’orientation ne fonctionnera. Les contributeurs doivent disposer d’assez d’expertise pour distinguer un problème de correction inoffensif d’une faille de sécurité nécessitant une gestion coordonnée.

L’IA pourra peut-être un jour assister ce triage, mais automatiser l’étape de classification crée une couche supplémentaire que les mainteneurs doivent vérifier. Le goulot d’étranglement se déplace plutôt qu’il ne disparaît.

Il existe également peu d’éléments publics reliant les candidats de publication plus volumineux à la fiabilité à long terme. Torvalds a attribué de nombreux correctifs à la revue par IA, mais cette observation ne quantifie ni leur gravité ni leur bénéfice en aval.

Le nombre de commits est un signal de charge de travail, pas un score de sécurité. Une réparation à fort impact peut compter davantage que de nombreuses corrections cosmétiques.

La même prudence s’applique aux rapports selon lesquels l’IA serait devenue indispensable. Les outils produisent des conclusions utiles, mais leurs coûts totaux incluent le matériel, l’exploitation des modèles, la revue humaine, les soumissions en double et le risque de régression.

Linux 7.2 offre un test en conditions réelles, mais pas une expérience contrôlée. Les développeurs peuvent observer si sa série de candidats plus importante entraîne de graves régressions, des correctifs d’urgence ou une charge inhabituelle pour les branches stables.

Ils devraient également examiner quels changements assistés par l’IA survivent à la revue. Les taux de rejet et les historiques de révision révéleraient davantage que le nombre brut de conclusions générées.

Une évaluation responsable doit séparer plusieurs questions. L’IA a-t-elle identifié un problème réel ? L’a-t-elle correctement expliqué ? Un humain a-t-il créé le correctif final ? Les tests ont-ils montré que le correctif résolvait le problème en toute sécurité ?

Réduire ces étapes à « l’IA a corrigé Linux » déforme le travail. Cela efface également les mainteneurs dont le jugement transforme la sortie machine en code accepté.

Les éléments actuels étayent une conclusion plus limitée. L’IA est devenue suffisamment performante pour modifier le volume de revue du noyau, mais pas suffisamment fiable pour éliminer la supervision d’experts.

Ce que les développeurs et responsables d’ingénierie devraient surveiller ensuite

La prochaine phase se mesurera à travers la stabilité des versions, la qualité des soumissions et les changements dans le workflow des mainteneurs, plutôt que par un nouvel argument sur l’idéologie de l’IA.

Le premier signal sera le comportement de Linux 7.2 après sa sortie. Les corrections de branches stables, les régressions et les annulations urgentes montreront si la série de candidats inhabituellement importante est restée maîtrisée.

Une période post-publication routinière renforcerait l’argument de Torvalds selon lequel des ensembles de mises à jour plus vastes influencés par l’IA peuvent s’intégrer au développement de Linux. Une hausse des régressions soutiendrait des limites plus strictes en fin de cycle.

Le deuxième signal est la qualité des soumissions assistées par l’IA. Des étiquettes de divulgation, des cas de test complets, des reproducers fonctionnels et le suivi assuré par les contributeurs indiqueraient que les utilisateurs adoptent des workflows responsables.

Des rapports en double sans analyse pointeraient dans la direction opposée. Ils montreraient que la découverte reste plus facile à automatiser que la participation responsable.

Le troisième signal est l’outillage des mainteneurs. Les contributeurs de Linux peuvent créer ou adopter des systèmes qui dédupliquent les conclusions, orientent les rapports vers le bon sous-système, classent la gravité probable et reconnaissent les défauts déjà corrigés.

Ces systèmes nécessitent des conceptions prudentes. Un filtre qui supprime à tort un problème grave peut être plus dommageable qu’une boîte de réception débordante.

Les entreprises devraient suivre ces évolutions, car leurs dépôts internes font face au même problème de capacité. Ajouter une revue par IA sans modifier les règles de triage peut inonder les équipes de travail pendant les périodes critiques de livraison.

Un déploiement utile commence par un périmètre restreint. Les équipes peuvent choisir un sous-système, définir les preuves acceptées, suivre les faux positifs et attribuer un responsable humain à chaque soumission assistée par une machine.

Elles devraient mesurer tout le parcours, de la découverte à la réparation vérifiée. Le résultat pertinent n’est pas le nombre de commentaires produits par un outil, mais le nombre de correctifs fiables qui atteignent la production sans augmenter les régressions.

Les organisations ont également besoin de règles de calendrier. Les conclusions non critiques de l’IA devraient entrer dans le backlog normal de développement plutôt que d’interrompre un candidat de publication ou un cycle de correctif d’urgence.

Les équipes de sécurité devraient établir des procédures distinctes pour les vulnérabilités présumées. La confiance d’un modèle ne devrait jamais déterminer si un rapport reste privé.

Les développeurs ont besoin d’attentes claires en matière de responsabilité. Toute personne soumettant un travail assisté par l’IA devrait comprendre le code, reproduire le problème, défendre le changement proposé et rester disponible après l’intégration.

La documentation peut soutenir ce comportement, mais elle ne peut remplacer le jugement. L’expérience de Linux suggère que la conception du workflow compte davantage qu’une simple autorisation ou interdiction.

La gestion des connaissances devient pertinente à mesure que la revue automatisée augmente. Les équipes ont besoin d’archives consultables des conclusions antérieures, des rapports rejetés, des décisions par sous-système et des schémas de doublons connus.

Une base de connaissances d’ingénierie peut aider à préserver ce contexte à travers les revues de code, les notes techniques et les discussions sur les versions. L’objectif est d’éviter que chaque nouvelle exécution d’outil ne relance la même enquête.

Google News continuera de présenter le débat à travers des déclarations mémorables de Torvalds. L’histoire la plus importante se déroulera au sein des listes de diffusion, des historiques de correctifs et des registres de versions stables.

Surveillez si les contributeurs assistés par l’IA commencent à fournir un travail d’ingénierie complet plutôt que des observations isolées. Surveillez si les mainteneurs obtiennent des outils qui réduisent les coûts d’orientation et de duplication. Surtout, surveillez si Linux absorbe un volume plus élevé de changements sans affaiblir sa stabilité.

La communauté du kernel a déjà dépassé la question de savoir si les développeurs utiliseront l’IA. Sa question plus difficile concerne désormais toutes les équipes logicielles : la découverte automatisée peut-elle progresser plus vite que la revue humaine sans transformer des résultats utiles en changements incontrôlés ?