Le 14 octobre 2026, GitHub a ouvert en préversion publique les fichiers de verrouillage des dépendances de workflows Actions. La fonction est annoncée pour les offres Free, Team et Enterprise Cloud, y compris avec résidence des données. [1]
Pourquoi une étiquette de version ne suffit pas toujours
Un workflow est une suite d’étapes automatisées, par exemple pour lancer des tests ou préparer une livraison logicielle. Il peut appeler une action provenant d’un autre dépôt. Quand cette référence désigne une branche ou une étiquette de version, sa cible peut changer : le nom reste identique, mais il ne pointe plus nécessairement vers le même code. [2]
Pour comprendre le problème, on peut comparer cette référence à un raccourci : connaître son nom ne dit pas à lui seul quel contenu il ouvrira demain. Le verrouillage sert à fixer une révision précise. L’intérêt n’est donc pas de multiplier les réglages, mais de rendre visibles et examinables les changements de dépendances.
Un inventaire lié à des révisions précises
La documentation place ce fichier dans .github/workflows/actions.lock. Il est généré par l’extension GitHub CLI gh actions-lock et ne doit pas être modifié manuellement. Il conserve la révision exacte, mais aussi les identifiants du propriétaire et du dépôt source. Les workflows peuvent y être intégrés progressivement. [2]
Le périmètre mérite une attention particulière : les dépendances transitives des actions sont couvertes, mais les dépendances internes d’un workflow réutilisable appelé relèvent du fichier de verrouillage du dépôt qui définit ce workflow. Un seul fichier local ne verrouille donc pas indistinctement tout le contenu de tous les dépôts appelés. [2]
Dependabot permet de continuer à mettre à jour
Verrouiller une dépendance n’oblige pas à la conserver indéfiniment. Selon la documentation de Dependabot, lorsqu’une mise à jour concerne une action d’un workflow déjà intégré au dispositif, l’entrée correspondante du fichier de verrouillage est régénérée dans la même proposition de modification. La référence du workflow et sa révision verrouillée peuvent ainsi évoluer ensemble, sans configuration supplémentaire pour cette synchronisation. [3]
Il faut distinguer les mises à jour de version, qui suivent les nouvelles éditions même sans vulnérabilité connue, des mises à jour de sécurité. Une proposition automatisée reste à examiner : lire les changements, vérifier les tests puis décider de son intégration. L’automatisation prépare le travail ; elle ne remplace pas la décision de maintenance. [3]
Ce que le verrouillage ne garantit pas
GitHub précise que cette protection ne détermine pas si une dépendance est sûre. Fixer une révision déjà malveillante ne la rend pas acceptable. Le dispositif vise les changements inattendus après sélection du code, pas un audit exhaustif de celui-ci. Une politique « Require lockfile », également en préversion, permet d’exiger ces fichiers à l’échelle d’un dépôt, d’une organisation ou d’une entreprise. [1]
Cette différence invite à poser deux questions séparées : « Est-ce bien le code choisi qui s’exécute ? » et « Avons-nous de bonnes raisons de faire confiance à ce code ? » Le verrouillage traite la première de façon plus explicite ; la seconde exige toujours un examen adapté au projet.
Une adoption à organiser dans l’équipe
Une approche raisonnable consiste à commencer par un workflow bien compris, examiner les révisions enregistrées et convenir de la manière dont les mises à jour seront relues. Cela permet d’expliquer les changements aux développeurs avant d’étendre la règle. Le statut de préversion annoncé par GitHub invite à rester attentif à l’évolution du dispositif. [1]
Sources
[1] GitHub Changelog — Annonce des lockfiles Actions, publiée le 14 octobre 2026.
[2] GitHub Docs — Comprendre le verrouillage des workflows, documentation sans date de publication affichée.
[3] GitHub Docs — Mises à jour avec Dependabot, documentation sans date de publication affichée. Sources consultées le 15 octobre 2026.
Crédit photographique
Photo d’illustration d’archive : Laptop coding programs, Tirza van Dijk, 17 janvier 2016, publiée initialement sur Unsplash sous CC0. Elle ne montre pas l’interface de la nouvelle fonction GitHub. Original sur Wikimedia Commons ; licence CC0 1.0. Version redimensionnée à 1 280 × 853 pixels, sans recadrage supplémentaire.
.jpg){kind=link}