GitHub comptabilise désormais les pull requests en brouillon dans les limites de PR ouvertes

Le 8 octobre 2026, GitHub a étendu les paramètres de limitation des pull requests : on peut désormais les configurer pour que les PR en brouillon (draft) comptent aussi dans la limite. L'annonce du GitHub Changelog est brève, et son motif est formulé sans détour : les mainteneurs constatent dans les dépôts de plus en plus de contributions de faible qualité et ont besoin de meilleurs moyens pour les gérer. L'annonce ne contient aucun chiffre, mais ce changement obéit à une logique claire.

Ce qui change concrètement

Les limites de pull requests permettent aux propriétaires de dépôts de plafonner le nombre de PR ouvertes simultanément. À en juger par la formulation « il est désormais aussi possible d'inclure les brouillons », les PR en draft n'entraient pas jusque-là dans ces restrictions. Pour un auteur cherchant à contourner la limite, c'était une échappatoire toute prête. Il suffisait d'ouvrir des ébauches au statut draft et d'en accumuler autant que voulu.

Cette brèche peut désormais être refermée, à titre optionnel. Le paramètre n'est pas imposé à tous les projets : c'est au mainteneur de décider s'il compte les brouillons au même titre que les PR ordinaires.

D'où vient le bruit

Le flux de contributions de faible qualité dans l'open source est depuis longtemps un problème à part entière. Une partie de ces demandes provient de modifications en masse faites pour gonfler des statistiques ou un « portfolio ». De plus en plus, elles sont générées par des assistants de code et des agents, capables d'ouvrir une PR plus vite qu'un humain ne peut lire sa description. Dans son annonce, GitHub n'en détaille pas les causes, mais le contexte du secteur est évident : le coût de création d'une PR est tombé presque à zéro, tandis que le coût de la relecture est resté le même et pèse entièrement sur le mainteneur.

Dans ce schéma, le brouillon joue le rôle de tampon. Un auteur, ou son script, peut garder des dizaines d'ébauches ouvertes ; le mainteneur les voit quand même dans la liste, reçoit les notifications et dépense son attention à les trier. Inclure les brouillons dans la limite rend la règle plus équitable : une demande ouverte occupe un emplacement, quel que soit son statut.

Ce que l'on sait des paramètres

• Date de publication : 8 octobre 2026, rubrique GitHub Changelog.
• Principe : les draft pull requests peuvent être incluses dans le décompte des limites de PR.
• Type de paramètre : optionnel, géré côté mainteneurs.
• Objectif affiché : réduire la charge liée aux contributions de faible qualité.
• Non précisé dans l'annonce : les seuils concrets, les règles de décompte par auteur et le comportement des brouillons déjà ouverts lors de l'activation de l'option.

Conséquences pratiques

Les mainteneurs de dépôts populaires gagneraient à vérifier leur configuration actuelle des limites et à décider s'ils ont besoin de comptabiliser les brouillons. Si le projet utilise les drafts comme espace de travail pour des fonctionnalités longues, une limite stricte pénalisera aussi les contributeurs de bonne foi. Dans ce cas, il est raisonnable de commencer par consigner la règle dans le CONTRIBUTING et d'expliquer comment travailler avec la limite.

Les contributeurs ont intérêt à fermer à l'avance les ébauches obsolètes et à éviter de garder plusieurs brouillons parallèles dans un dépôt qui n'est pas le leur. Les équipes qui lancent des agents pour ouvrir automatiquement des PR doivent intégrer les limites dans leur logique : file d'attente, nouvelles tentatives et priorisation. Sinon, l'agent butera sur le plafond et perdra silencieusement ses résultats.

Le changement est modeste et ne règle pas le problème de la qualité : la limite plafonne le volume, pas le contenu. Mais comme couche de protection parmi d'autres, aux côtés des modèles de PR, des vérifications obligatoires et de la restriction du cercle des auteurs, elle remplit son rôle. Mieux vaut vérifier les mécanismes exacts de décompte dans la documentation de GitHub : l'annonce elle-même donne peu de détails.