Actions : le tag est sur le manteau, le reçu du vestiaire a le numéro du cintre

Le vestiaire, ce soir-là, te rend un reçu à la place du tag cousu dans le manteau. Le tag, c'est v3, ou main. Il peut être recousu sur un autre manteau pendant que tu as le dos tourné. Le reçu, lui, a le numéro du cintre : un commit. Si tu ne lis que le billet punaisé sur la porte, tu as une liste de forfaits, et une phrase sur ce que le reçu ne garantit pas. Si tu ne lis que la doc, tu as le mot vérifié, et, une page plus loin, le mot examiné. Ce n'est pas le même tampon.

Le 14 octobre 2026, le changelog titre GitHub Actions workflow lockfiles in public preview. Une note de rédaction, datée October 14th, 2026, dit que la liste des forfaits qui ont accès à cet aperçu public a été mise à jour. La phrase que j'ai lue ensuite : l'aperçu est ouvert pour GitHub Enterprise Cloud, GitHub Enterprise Cloud with data residency, Team, et Free. Je n'ai pas la liste d'avant la note. Je ne la reconstitue pas. Pro n'est pas nommé. GitHub Enterprise Server non plus.

Le reçu a le commit, et le billet dit qu'il ne juge pas le manteau

Le billet : les tags et les branches peuvent bouger après la relecture, donc un run plus tard peut exécuter un autre code. Le lockfile te laisse garder ces références dans le workflow, tout en lançant les commits que tu as verrouillés. Si une action est compromise, un tag ou une branche déplacé peut introduire du code malveillant sans changement dans ton dépôt. Puis la phrase que les autres pages n'impriment pas : verrouiller ne détermine pas si la dépendance elle-même est sûre. Il faut les relire avant de les verrouiller.

La page de concept ouvre sur une autre formule. Un lockfile épingle chaque action dont tes workflows dépendent à un commit vérifié, pour que le code que tu as relu soit celui qui tourne. La page de mode d'emploi reprend verified commit dans son chapeau. La page qui gouverne l'exécution, dans le paragraphe Require lockfile, dit que la protection bloque les runs de workflows qui ont des dépendances uses: vers d'autres actions, sauf si ces dépendances sont épinglées dans un lockfile. Le but imprimé : que les workflows visés exécutent du code prévisible, examiné (« predictable, vetted code »), plutôt que ce vers quoi un tag ou une branche pointe au moment du run. « Sûr » n'est pas sur cette page. « Vérifié » et « examiné » ne sont pas sur le billet. Je ne les soude pas en un seul tampon.

Le fichier, les pages qui le décrivent le mettent au même chemin : .github/workflows/actions.lock. Il est produit par gh actions-lock, une extension de la CLI, et il ne s'édite pas à la main. L'exemple de la page de concept a une version v0.0.2, deux sections, workflows et dependencies, et pour chaque dépendance un ref, un commit, un owner_id et un repo_id. L'exemple imprime commit: 'sha1-...', owner_id: 44036562, repo_id: 197814629. Ce sont les chiffres de l'exemple. Le billet du 14 n'imprime ni la version du fichier, ni ces deux identifiants. Le owner_id et le repo_id, dit la page, servent à confirmer au moment du run que le dépôt derrière le nom est encore celui que tu as verrouillé. Ce n'est pas la phrase du billet sur la sûreté de la dépendance.

Le workflow réutilisable n'a pas la même phrase sur les deux feuilles

La puce du billet qui dit épingler : le fichier a des commits relisables pour les actions et leurs dépendances transitives, ainsi que les dépendances de workflows réutilisables. « As well as reusable workflow dependencies. » Pas d'exception dans cette puce.

La page de concept a deux phrases, et elles ne disent pas la même chose. La première : le lockfile épingle un SHA sur chaque action, y compris les transitives, et sur chaque workflow réutilisable dont tes workflows dépendent. La seconde, plus bas : un lockfile couvre les workflows de son propre dépôt. Il s'étend aux dépendances transitives, celles que tes actions utilisent, sauf les dépendances des appels de workflows réutilisables. Un workflow réutilisable est couvert par le lockfile du dépôt où il est défini. La page de mode d'emploi répète cette seconde phrase, et elle ajoute un conseil : si ton organisation maintient des workflows partagés, embarquer ces dépôts-là d'abord.

Le billet n'imprime pas le « except ». Je ne lis pas sa puce comme si elle l'avait. Je ne lis pas non plus l'exception comme si elle annulait le billet. Elles ne sont pas sur la même feuille.

Le mode d'emploi réécrit le manteau, le billet ne le dit pas

Depuis la racine, gh actions-lock sans argument parcourt chaque workflow sous .github/workflows/. Pour un seul fichier, on passe le chemin. L'installation imprimée est gh extension install github/gh-actions-lock. L'astuce pour mettre à jour l'extension, plus bas, est gh extension upgrade gh-actions-lock. Le préfixe github/ est sur la commande d'installation. Il n'est pas sur celle de mise à jour.

Puis la phrase qui n'est ni dans le billet, ni sur la page de concept : l'extension change plus que le lockfile. Elle réécrit les références uses. octo-org/deploy-action@v3 peut devenir octo-org/deploy-action@v3.1.0. Plus spécifique, sans changer le commit vers lequel ça résout. Les actions de ton propre dépôt passent de uses: ./… à uses: $/…, dans les workflows et dans les action.yml du dépôt. Un $/… résout toujours vers le commit en cours d'exécution, donc il n'a pas de ligne dans le lockfile.

Ailleurs, la page de concept dit que, pour les dépôts qui adoptent un lockfile, épingler un SHA complet dans les fichiers de workflow n'est plus nécessaire. La page de gouvernance dit une autre chose, utile : tu peux garder activée l'exigence Require actions to be pinned to a full-length commit SHA. Pour les dépendances couvertes par un lockfile, GitHub évalue cette exigence avec le SHA verrouillé. Garder la politique pendant un déploiement progressif conserve l'épinglage SHA pour les workflows qui n'ont pas encore de lockfile. « Plus nécessaire » est une page. « Tu peux la garder » est l'autre.

Dependabot, sur le billet : quand il ouvre une mise à jour de version pour une action dans un workflow déjà embarqué, il régénère aussi l'entrée de lockfile dans la même pull request. La page de mode d'emploi ajoute deux phrases que le billet n'a pas. Dependabot n'embarque pas un workflow à ta place. S'il met à jour une dépendance dans un workflow sans entrée de lockfile, il signale que l'embarquement est requis. Plus bas, les références à une branche ou à une version partielle, main ou v3, sont crues depuis le lockfile et ne sont pas re-résolues sur un run normal. Pour accepter un tag qui a bougé, gh actions-lock --relock. Si le commit d'origine n'est plus atteignable, gh actions-lock --relock --accept-moved. Ces deux drapeaux ne sont pas dans le billet.

La politique Require lockfile, dit le billet, est aussi en aperçu public. Les administrateurs d'entreprise, d'organisation et de dépôt peuvent exiger des lockfiles. La page de gouvernance dit de générer et de vérifier les lockfiles avant de passer la protection à Active, sinon les runs se bloquent dans des dépôts qui ne sont pas prêts. Sur cette même page, une autre note : une politique par défaut bloquera l'événement pull_request_target dans les dépôts publics, appliquée le 2 novembre 2026. Ce n'est pas le paragraphe du lockfile. Je ne le lui colle pas.

✍️ À toi : le workflow que tu as vraiment sous les yeux, et si le diff que l'extension te propose réécrit un uses ou se contente d'ajouter le fichier. Le billet a un reçu. Ton dépôt a un diff.

Le 14 octobre, le changelog met les lockfiles de workflows en aperçu public pour Enterprise Cloud, Enterprise Cloud avec résidence des données, Team et Free, et il dit que verrouiller ne dit pas si la dépendance est sûre. La page de concept parle d'un commit vérifié, d'une exception pour les dépendances des workflows réutilisables, et d'un épinglage SHA qui ne serait plus nécessaire dans les fichiers. La page de mode d'emploi réécrit les uses, et elle dit que Dependabot n'embarque pas un workflow tout seul. La page de gouvernance dit que tu peux garder l'exigence du SHA complet, et elle appelle le code visé « examiné ». Quatre feuilles. Le tag est encore cousu dans le manteau.