# GitHub impose des protections pour contrôler l’exécution des workflows Actions _Publié le 2 novembre 2026 — https://ip73.fr/2026/11/02/github-impose-des-protections-pour-controler-l-execution-des/_ L'administrateur d'un dépôt GitHub peut désormais définir une liste blanche précisant qui peut déclencher les workflows Actions, et quels événements sont acceptés. Ce mécanisme de « workflow execution protections » permet de raffiner le contrôle des pipelines CI/CD, allant au-delà des règles de sécurité traditionnelles. Selon docs.github.com, ces protections permettent de cibler spécifiquement les organisations ou les dépôts concernés, et de restreindre l'accès aux workflows sensibles, par exemple ceux qui déploient du code en production. Ce système s'empile sur d'autres mesures de protection déjà en place dans un même dépôt ou une même organisation. Il est conseillé de privilégier la création de politiques multiples et bien définies plutôt que de construire une seule règle monolithique pour l'ensemble du compte. ## Sécuriser l'identité du déclencheur et des événements Par défaut, tout utilisateur disposant des droits d'écriture sur un dépôt peut lancer un workflow. Les règles d'acteur (Actor rules) introduisent une distinction nette entre celui qui contribue au code et celui qui exécute le processus de construction. On peut ainsi accorder les droits d'écriture à un contributeur sans lui conférer la capacité d'activer les workflows en question. Parallèlement, il est possible de restreindre les événements autorisés, qu'il s'agisse de `push`, de `pull_request`, ou de `workflow_dispatch`. Les fonctionnalités natives de GitHub ne sont pas soumises à ces limitations, mais si une identité spécifique, telle que `dependabot[bot]`, est utilisée, elle doit être explicitement listée parmi les acteurs autorisés. Ce renforcement des contrôles intervient dans un contexte où l'automatisation prend une ampleur inédite. Le rapport Octoverse 2026 de GitHub, publié fin octobre, montrait déjà une accélération spectaculaire : le nombre de *pull requests* fusionnées a triplé en moins d'un an, atteignant 220 millions par mois. ## L'impact de l'interdiction de `pull_request_target` Le changement le plus marqué concerne l'événement `pull_request_target`. GitHub annonce que cet événement sera bloqué par défaut dans tous les dépôts publics à compter du 2 décembre 2026, sauf si une politique d'événement Actions l'autorise explicitement. Cette mesure vise à réduire les risques de sécurité, car `pull_request_target` s'exécute dans le contexte du dépôt de base et peut y accéder aux secrets, exposant potentiellement des données si du code non fiable provient d'un *fork*. Initialement, cette règle fonctionnera en mode « evaluate », permettant aux équipes de voir quels workflows seraient affectés sans que cela ne casse leur pipeline. Les développeurs disposent ainsi de temps pour ajuster leurs politiques. Avant la mise en application définitive le 2 décembre 2026, deux fenêtres de « brownout » sont prévues : le 9 novembre 2026 de 16h00 à 18h00 UTC, et le 16 novembre 2026 de 16h00 à 18h00 UTC. Durant ces périodes, les tentatives bloquées généreront des exécutions échouées avec une annotation d'erreur. Pour les dépôts privés et internes, aucun changement n'est à prévoir. En outre, la protection `Require lockfile` ajoute une couche de prévisibilité en exigeant que les workflows ciblés soient intégrés dans le fichier de verrouillage du dépôt, garantissant l'utilisation de code vérifié. Si un workflow appelle un autre workflow réutilisable non intégré au *lockfile* de son propre dépôt, il sera bloqué. ## Sources - [Governing execution of GitHub Actions workflows - GitHub Docs](https://docs.github.com/actions/how-tos/administer/control-workflow-execution), docs.github.com - [pull\_request\_target blocked by default December 2](https://github.blog/changelog/2026-11-02-pull_request_target-blocked-by-default-december-2), GitHub, 2 novembre 2026 - [GitHub Octoverse 2026](https://simonwillison.net/2026/Oct/28/github-octoverse-2026/), Simon Willison, 28 octobre 2026