GitHub autorise le rôle Triage à archiver les pull requests, une action jusqu'ici réservée aux administrateurs

Le 8 octobre 2026, GitHub a modifié les règles d'accès à l'archivage des pull requests. Les utilisateurs dotés du rôle Triage ou d'un rôle supérieur peuvent désormais les archiver et les désarchiver. Jusqu'ici, ce droit était réservé aux administrateurs du dépôt. Sur les cinq rôles standard de GitHub (Read, Triage, Write, Maintain, Admin), le seuil passe du plus haut échelon au deuxième en partant du bas. Le changement est modeste, mais il touche l'un des flux de travail les plus sollicités de la plateforme.

Ce qui change concrètement

L'annonce publiée dans le GitHub Changelog est brève. Auparavant, l'archivage d'une PR exigeait des droits d'administrateur, si bien que les triageurs de confiance devaient s'en remettre aux administrateurs, même pour les cas de routine. Dans la version de l'annonce dont nous disposons, le texte s'interrompt sur cette phrase. Les détails d'implémentation n'y figurent pas : par exemple, la manière dont les PR archivées apparaissent dans la recherche et les filtres, ou les événements qui sont consignés dans le journal d'audit. Mieux vaut les vérifier dans la documentation de GitHub.

La règle fonctionne désormais dans les deux sens : un utilisateur avec le rôle Triage peut aussi bien archiver une PR que la restaurer. C'est important. En cas d'archivage par erreur, le triageur corrige lui-même sans avoir à chercher un administrateur.

Pourquoi le seuil d'accès compte

Le rôle Triage de GitHub a été conçu pour les personnes qui trient le flux entrant. Elles posent des étiquettes, assignent des responsables, ferment les doublons et rouvrent des tickets. En revanche, elles ne peuvent pas pousser de code dans le dépôt. C'est un rôle naturel pour les bénévoles des projets open source, ainsi que pour les ingénieurs support ou les spécialistes QA dans les équipes en entreprise.

Avant ce changement, il existait un trou dans la raquette. Un triageur repérait une PR obsolète ou abandonnée, pouvait la fermer, mais pas la retirer de l'espace de travail. Il fallait alors écrire à un administrateur. Dans les petits projets, il n'y en a généralement qu'un, et ces demandes deviennent vite un goulot d'étranglement. Désormais, le nettoyage courant de la file reste au niveau où l'on décide de son contenu.

Il y a aussi un contexte indirect. Des outils comme les agents de code rendent l'ouverture d'une PR moins coûteuse, et dans de nombreux dépôts, les files s'allongent. GitHub ne fait pas ce lien dans son annonce : c'est notre observation. Mais plus les PR sont créées automatiquement, plus chaque transmission de tâche entre rôles coûte cher.

Les paramètres en bref

• Date de l'annonce : 8 octobre 2026.
• Qui y a accès : le rôle Triage et les rôles supérieurs (Triage, Write, Maintain, Admin).
• Opérations : archivage et désarchivage des pull requests.
• Auparavant : uniquement les administrateurs du dépôt.
• Source : GitHub Changelog.

Comment tirer parti du changement dans votre équipe

Commencez par vérifier à qui le rôle Triage est attribué dans votre dépôt. Si vous ne l'avez accordé que pour les étiquettes et les assignations, ces personnes disposent désormais d'une action supplémentaire. Pour la plupart des équipes, c'est acceptable, mais dans les projets soumis à un règlement strict, mieux vaut les prévenir à l'avance.

Consignez ensuite dans le CONTRIBUTING ou dans un guide interne les critères d'archivage. Par exemple : PR sans activité au-delà d'un certain délai, doublons, PR abandonnées par leur auteur. Sans règle, chaque triageur décidera à sa façon, et les questions du type « pourquoi ma PR a-t-elle disparu » se multiplieront.

Enfin, si vous avez de l'automatisation autour des PR (bots, tableaux de bord, rapports sur la vitesse de revue), vérifiez comment elle prend en compte les requêtes archivées. Les équipes qui mesurent la durée de vie des PR devront décider à l'avance si l'archivage compte comme une fermeture. GitHub ne vous dira sans doute pas comment procéder dans votre propre processus.