DevOps

Un cache CI est souvent considéré comme un simple réglage de performance. Pourtant, les fichiers restaurés peuvent finir dans un chemin exécuté par le build : dépendances, scripts, objets compilés, outils téléchargés ou couches intermédiaires. Un cache modifié par un job peu fiable peut donc devenir un canal d’exécution dans un workflow plus privilégié. Depuis le 10 septembre 2026, GitHub Actions permet de fixer explicitement les droits du cache avec cache-mode. La clé accepte quatre valeurs, read, write, write-only et none, au niveau du workflow ou d’un job. La fonction est disponible sur github.com pour tous les plans. Le réglage le plus utile en pratique consiste à séparer les rôles : les validations de pull requests restaurent un cache en lecture seule, tandis qu’un workflow déclenché depuis une branche de confiance produit les nouvelles entrées. Les jobs de publication qui n’ont pas besoin du cache le désactivent complètement. cache-mode impose une limite de droits appliquée par le service de cache. Il ne vérifie toutefois pas l’intégrité des fichiers déjà présents et ne corrige pas un workflow qui exécute du code non fiable avec des secrets.