Les fichiers de verrouillage des flux GitHub Actions passent en disponibilité générale

GitHub a annoncé le 28 octobre 2026 la disponibilité générale des fichiers de verrouillage des dépendances de flux de travail GitHub Actions. Ils sont proposés sur GitHub Enterprise Cloud, GitHub Enterprise Cloud avec résidence des données, et sur les formules Team et Free. Un fichier de verrouillage permet à un flux de travail de garder des références lisibles à des étiquettes et des branches, tout en exécutant les commits exacts qui ont été verrouillés, même si ces références se déplacent ensuite. L’entrée du journal des modifications indique que la version générale reprend les capacités introduites en préversion publique.

Le problème tient aux références modifiables. Un flux de travail qui dit utiliser une action à une étiquette ou une branche exécute le commit vers lequel ce nom pointe au démarrage de la tâche. Si le nom se déplace, la tâche exécute en silence un autre code. Le fichier de verrouillage enregistre les commits derrière ces noms, pour les actions et pour leurs dépendances transitives, c’est-à-dire les actions que ces actions utilisent à leur tour. L’extension gh actions-lock de la CLI GitHub génère le fichier .github/workflows/actions.lock. Le fichier du flux de travail garde ses références lisibles, et le fichier de verrouillage décide de ce qui s’exécute réellement.

L’adoption peut être progressive. Les équipes activent les flux de travail un par un. Une fois un flux de travail activé, GitHub Actions exige que chacune de ses dépendances figure dans le fichier de verrouillage et exécute le commit enregistré. L’adoption n’a donc pas à couvrir tous les flux de travail en une fois. Pour une règle ferme, les administrateurs d’entreprise, d’organisation et de dépôt peuvent appliquer une politique « Exiger le fichier de verrouillage ». Le journal ne décrit pas ce qui arrive aux flux qui enfreignent la politique ; il vaut mieux la tester sur un petit périmètre avant de l’étendre.

Deux fonctions maintiennent le fichier à jour. Quand Dependabot ouvre une mise à jour de version pour une action d’un flux activé, il régénère aussi l’entrée correspondante dans la même demande de fusion, sans configuration supplémentaire. Cela évite une étape de régénération séparée. Les équipes peuvent aussi vérifier si un fichier est périmé. La vérification contrôle qu’il est à jour sans modifier de fichier ; elle peut donc tourner comme contrôle d’intégration continue et faire échouer une construction quand quelqu’un modifie un flux sans toucher au fichier de verrouillage.

GitHub est clair sur la limite. Les fichiers de verrouillage aident à se protéger de changements inattendus, mais ne disent pas si une dépendance est sûre. Un commit malveillant ou vulnérable au moment du verrouillage le reste ensuite. GitHub conseille d’examiner les dépendances avant de les verrouiller. Le verrouillage avance donc le moment de l’examen, au verrouillage et à chaque mise à jour de Dependabot, sans le remplacer. L’entrée ne dit rien non plus des exécuteurs auto-hébergés ni de GitHub Enterprise Server ; les équipes concernées doivent consulter la documentation.

Pour commencer, installez l’extension depuis le dépôt gh-actions-lock, générez le fichier, puis relisez et validez le fichier de verrouillage et les changements du flux de travail. GitHub renvoie à sa documentation et à une discussion communautaire et un suivi de problèmes pour les retours.

Pour les équipes qui s’appuient sur des actions tierces, le gain pratique est une trace vérifiable du code exact exécuté par un pipeline, et un moyen de rendre la dérive visible dans une demande de fusion.