L'IA détecte tant de bogues sous Linux que Canonical décide de passer à un rythme hebdomadaire de publication des mises à jour du noyau pour Ubuntu, la décision suscite une controverse sur sa pertinence
L'explosion des vulnérabilités (CVE) découvertes sous Linux de manière automatisée par l'intelligence artificielle force les éditeurs à repenser entièrement leur stratégie de sécurité. C’est en droite ligne avec cet état de choses que Canonical a annoncé l'abandon de son modèle traditionnel 4/2 (mises à jour de maintenance toutes les 4 semaines et de sécurité toutes les 2 semaines) au profit d'un cycle de publication de mises à jour de 2 semaines unifié et chevauchant, ce qui se traduit concrètement par la sortie d'un nouveau noyau Ubuntu chaque semaine. La décision suscite une controverse sur sa pertinence.
@Canonical’s Kernel team is transitioning to a rapid 2-week Stable Release Update (SRU) cycle, published weekly. Each release retains extensive testing to preserve the reliability and quality Ubuntu users expect.
Users who are sensitive to turnaround times can begin their own… pic.twitter.com/nexky3iXEo
— Canonical (@Canonical) September 25, 2026
Et ce, pour diverses raisons parmi lesquelles la récurrence des mises à jour pour lesquelles Windows est critiqué par les utilisateurs
C’est connu, Windows 11 est critiqué par les utilisateurs pour la gestion des mises à jour. C’est fort de cet état de choses que des observateurs ne manquent pas de le pointer du doigt suite à l’annonce de Canonical. Auparavant, Canonical utilisait un modèle "4/2" (une mise à jour complète toutes les 4 semaines, et un point de sécurité optionnel à 2 semaines). Désormais, le rythme passe à un noyau déployé chaque semaine.
Pour les équipes d’infrastructure (DevOps, administrateurs de parcs de serveurs ou de clusters Kubernetes), la cadence de mise à jour devient une contrainte critique. Tester, valider et redémarrer des grappes de serveurs (node pools) chaque semaine représente un coût d'exploitation humain et technique colossal, augmentant le risque d'introduire des régressions en production.
Now we are no different from Windows lol
— sofavoured (@0x_smokey0) September 25, 2026
En parallèle, il y a la question de la légitimité de l’inflation des vulnérabilités CVE qui a mené à cette décision de Canonical. Le nombre de vulnérabilités frôle désormais les 2000 CVE par version du noyau Linux. Cette hausse spectaculaire est en partie due au fait que la communauté du noyau Linux est devenue sa propre autorité de numérotation des CVE (CNA). Elle attribue un identifiant CVE à presque n'importe quel bogue au motif qu'un défaut système peut potentiellement être exploité. Beaucoup critiquent cette politique qui mélange des failles critiques réelles et des anomalies mineures, forçant Canonical à accélérer son cycle pour des correctifs parfois superflus.
Voici néanmoins les avantages potentiels de cette nouvelle stratégie de Canonical pour les administrateurs système et les utilisateurs
- Réduction drastique de la fenêtre d'exposition : Auparavant, le modèle 4/2 (mises à jour générales toutes les 4 semaines, correctifs critiques à mi-parcours) pouvait laisser des serveurs exposés à des failles de sécurité connues pendant plusieurs semaines. Le rythme hebdomadaire permet de déployer les correctifs de vulnérabilités (CVE) beaucoup plus rapidement.
- Maintien d'un niveau de test rigoureux (2 semaines) : Bien qu'un noyau sorte toutes les semaines, chaque version bénéficie de deux semaines complètes de préparation et de validation. La première semaine est dédiée à l'intégration des patchs et aux premiers tests légers (smoke tests), et la deuxième semaine est entièrement consacrée aux tests de régression et à la certification matérielle.
- Accès anticipé via le dépôt -proposed : Les équipes qui ont un besoin critique de correctifs immédiats peuvent récupérer de manière officielle les versions candidates dès la fin de la première semaine, acceptant ainsi de faire l'impasse sur la phase de certification matérielle au profit de la rapidité.
- Fin de la distinction complexe entre correctifs "urgents" et "réguliers" : Le pipeline est désormais unifié. Toutes les modifications (sécurité, corrections de bugs matériels) suivent la même voie prévisible, évitant les surprises liées aux publications d'urgence
Dualité oblige, les inconvénients de la nouvelle stratégie de Canonical suivent pour le public concerné
- Surcharge d'administration et fatigue des équipes : Pour les administrateurs gérant des flottes de serveurs ou des parcs de machines à grande échelle, maintenir la cadence des mises à jour du noyau devient une tâche hebdomadaire contraignante.
- Nécessité d'automatiser les redémarrages : Mettre à jour un noyau Linux implique généralement un redémarrage du système pour l'appliquer (sauf utilisation de technologies coûteuses ou complexes comme le Livepatching). Un cycle hebdomadaire oblige les entreprises à revoir leurs fenêtres de maintenance et à automatiser agressivement la validation et le basculement des grappes de serveurs (Node Pools).
- Risque accru d'effets de bord (régressions) : Même si la durée de test de Canonical reste de deux semaines, l'industrialisation et l'accélération du rythme augmentent statistiquement la probabilité qu'un bug spécifique à un matériel ou à une application métier passe entre les mailles du filet.
- Le fardeau de la validation interne transféré aux entreprises : Comme le souligne la communauté des architectes cloud, la cadence des correctifs devient une contrainte de conception. Les équipes internes doivent désormais décider si elles font aveuglément confiance à la certification de Canonical ou si elles doivent mettre en place leurs propres bancs d'essai automatisés hebdomadaires.
Canonical is switching Ubuntu kernel updates to overlapping two-week cycles, resulting in new kernel releases every week.https://t.co/G6qGwzurVf#Linux #Ubuntu #Kernel #OpenSource pic.twitter.com/F56pQFC4hE
— Linuxiac (@linuxiac) September 23, 2026
Le phénomène auquel fait face Canonical n'est pas isolé. Toute l'industrie logicielle subit la transition vers le développement et l'audit assistés par IA et ce, avec ses hauts et ses bas.
Chez Microsoft et Google, des outils comme Daybreak (OpenAI) ou Glasswing (Anthropic) ont été partagés avec des firmes de sécurité. Résultat : Microsoft a dû publier 620 correctifs en une seule semaine et Google 433 pour Chrome. Même mesure que chez Canonical : augmentation drastique de la fréquence des vagues de correctifs hors calendrier traditionnel.
Le projet cURL s’est retrouvé inondé par des rapports générés par IA décrivant des failles de sécurité fictives ou hors contexte (souvent basées sur une mauvaise interprétation du code C par les LLM). Il s’en alors suivi une fermeture définitive de son programme public de Bug Bounty pour stopper le bruit numérique.
L'IA a industrialisé la découverte des failles. En parallèle, l'écriture du code reste en majorité humaine ou étroitement supervisée. La relecture automatisée par des machines crée une asymétrie : les défenseurs (éditeurs de logiciels, mainteneurs) sont contraints d'adopter des pipelines d'intégration et de déploiement continus (CI/CD) ultra-rapides pour ne pas se laisser submerger par les robots chasseurs de bugs. Cela vient avec des hauts et des bas.
Et vous ?
Comment accueillez-vous ce changement de rythme de publication des mises à jour du noyau Ubuntu ? Est-il souhaitable de voir cette approche étendue aux autres distributions Linux ?
Que pensez-vous de l’utilisation de l’intelligence artificielle pour la découverte des failles logicielles ? Comment cela affecte-t-il vos flux de travail d’entreprise ? Partagez vos anecdotes.
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
Vous avez lu gratuitement 103 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.