Un ingénieur DevOps GitHub Actions conçoit les workflows de build, de test et de déploiement, les reusable workflows et les actions maison partagés dans l'organisation, et les runners auto-hébergés quand ceux de GitHub ne suffisent pas. Les offres françaises associent GitHub Actions à Terraform, Docker, Kubernetes, un cloud (AWS, Azure ou GCP) et Artifactory ou GitHub Packages. On voit aussi des missions de migration depuis Azure DevOps ou Jenkins.
La sécurité de la chaîne d'approvisionnement fait le tri entre les profils. En mars 2025, l'action tierce tj-actions/changed-files a été compromise et a écrit des secrets dans les journaux de nombreux dépôts qui la référençaient par un tag. Un candidat expérimenté fige les actions tierces par SHA, réduit les permissions du GITHUB_TOKEN et sait pourquoi pull_request_target est risqué. Un profil qui a surtout copié des workflows trouvés en ligne n'aborde pas ces sujets.
Une partie des questions dépend de l'édition, GitHub Enterprise Cloud ou Server, et de la souscription à GitHub Advanced Security. Reste à savoir qui opère les runners auto-hébergés. Les 30 questions du PDF sont notées de 1 à 4, avec un cas pratique de 20 minutes.
L'écosystème GitHub Actions d'un ingénieur DevOps
Workflows, jobs et déclencheurs
Des fichiers YAML rangés dans .github/workflows et déclenchés par un événement : push, pull request, release, planification ou lancement manuel. Un workflow contient des jobs, chacun sur un runner, faits de steps qui lancent des commandes ou des actions. Les matrices démultiplient un job sur plusieurs versions ou systèmes.
Actions et reusable workflows
Une action est une brique réutilisable, écrite en JavaScript, empaquetée en conteneur ou composée de steps (composite). Un reusable workflow est un workflow entier appelé par un autre, avec ses propres jobs et secrets. Savoir choisir entre les deux est un bon indicateur d'expérience.
Runners hébergés et auto-hébergés
GitHub fournit des runners Linux, Windows et macOS, dont des machines plus puissantes (larger runners) facturées à part. Les runners auto-hébergés tournent sur les machines de l'entreprise, pour accéder à un réseau interne ou à un matériel particulier. GitHub déconseille de les utiliser sur un dépôt public.
Actions Runner Controller (ARC)
L'opérateur Kubernetes maintenu par GitHub pour faire tourner des runners auto-hébergés en pods. Il s'installe avec deux charts Helm et ajuste le nombre de runners à la file de jobs. Chaque runner éphémère exécute un job puis disparaît.
GITHUB_TOKEN, secrets et environnements
Chaque exécution reçoit un GITHUB_TOKEN dont le workflow règle les permissions. Les secrets se déclarent au niveau de l'organisation, du dépôt ou d'un environnement. Un environnement peut exiger une approbation, limiter les branches qui y déploient et garder ses propres secrets.
OIDC vers les clouds
Le job demande à GitHub un jeton OIDC (permission id-token: write) et l'échange contre des droits temporaires chez AWS, Azure ou GCP. La confiance se règle sur le dépôt, la branche ou l'environnement. Aucune clé d'accès n'est stockée dans les secrets.
GitHub Packages et GHCR
Le registre de conteneurs ghcr.io et les registres de paquets npm, Maven, NuGet ou RubyGems de GitHub. Un workflow y publie avec le GITHUB_TOKEN quand les permissions du paquet l'autorisent. Beaucoup d'entreprises gardent toutefois Artifactory ou Nexus à côté.
Dependabot, CodeQL et Advanced Security
Dependabot propose des mises à jour de dépendances, y compris des actions utilisées par les workflows. CodeQL analyse le code dans un workflow. Depuis 2025, GitHub Advanced Security se vend en deux offres : Secret Protection (détection de secrets, push protection) et Code Security (CodeQL, dependency review, Copilot Autofix). Plusieurs de ces fonctions restent gratuites sur les dépôts publics.
Rulesets et protection de branches
Les règles qui imposent une revue, des contrôles de statut réussis ou des commits signés avant une fusion. Les rulesets, plus récents que la protection de branche classique, peuvent s'appliquer à plusieurs dépôts d'une même organisation.
On trouve ce profil dans les organisations dont le code est sur GitHub, souvent avec un cloud public derrière, et dans les équipes qui regroupent plusieurs chaînes (Azure DevOps, Jenkins) sur GitHub. Le poste peut relever d'une équipe plateforme qui publie des reusable workflows pour toute l'organisation, ou d'une équipe produit qui gère sa propre chaîne. GitHub propose une certification GitHub Actions, qui atteste la connaissance de la syntaxe et des fonctions. L'exploitation des runners et la sécurité des workflows se vérifient en entretien.
Les points à contrôler chez un ingénieur DevOps GitHub Actions
- Conception de workflows et déclencheurs
- Réutilisation : actions et reusable workflows
- Runners auto-hébergés et ARC
- Sécurité des workflows et supply chain
- Secrets, OIDC et environnements
- Performance : cache, matrices, concurrence
GitHub Actions en entretien : cinq questions et leurs réponses
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un workflow utilise une action tierce référencée par @v3. Quel risque voyez-vous, et que faites-vous ?
Une bonne réponseUn tag peut être déplacé par le mainteneur, ou par un attaquant qui a pris la main sur le dépôt de l'action : le code exécuté change sans que le workflow bouge. C'est ce qui est arrivé à tj-actions/changed-files en mars 2025. Il fige l'action sur son SHA complet avec le tag en commentaire, laisse Dependabot proposer les mises à jour, limite les actions autorisées dans l'organisation et réduit les permissions du GITHUB_TOKEN pour borner les dégâts.
Signal d'alerte« C'est une action populaire, donc elle est sûre », ou @main pour avoir toujours la dernière version.
Question 2 · senior
Un contributeur externe ouvre une pull request. Quels workflows peuvent lire vos secrets, et comment le savez-vous ?
Une bonne réponseUn workflow déclenché par pull_request depuis un fork n'a pas accès aux secrets et reçoit un GITHUB_TOKEN en lecture. pull_request_target tourne dans le contexte de la branche cible, avec les secrets : s'il récupère et exécute le code de la PR, le contributeur exécute son code avec vos secrets. Il reste sur pull_request, sépare la partie privilégiée dans un workflow_run qui n'exécute pas le code reçu, et exige une approbation avant de lancer les workflows des nouveaux contributeurs.
Signal d'alertepull_request_target avec un checkout de la PR « pour que les tests aient les secrets ».
Question 3 · confirmé
Le build et le déploiement doivent être partagés entre les dépôts d'une équipe. Reusable workflow ou composite action : que choisissez-vous ?
Une bonne réponseUn reusable workflow pour partager des jobs entiers, avec leurs runners, leurs environnements et leurs secrets. Une composite action pour une suite de steps insérée dans un job existant, sans job ni environnement propre. Le tout dans un dépôt central, référencé par tag ou par SHA. Il connaît les limites : dix niveaux d'imbrication et 50 reusable workflows distincts appelés depuis un même fichier, imbrications comprises.
Signal d'alerteCopier le fichier dans chaque dépôt et le corriger partout à chaque changement.
Question 4 · senior
Vous installez des runners auto-hébergés sur Kubernetes avec Actions Runner Controller. Comment empêchez-vous qu'un job en contamine un autre ?
Une bonne réponseDes runner scale sets avec des runners éphémères : chaque pod exécute un seul job puis il est supprimé. Des scale sets distincts selon le niveau de confiance (dépôts internes, déploiements en production), réservés à certains dépôts par les groupes de runners. Le mode Kubernetes, ou un Docker-in-Docker isolé quand il faut construire des images, sans monter la socket Docker de l'hôte. Des limites de ressources et une politique réseau qui restreint ce que les pods peuvent joindre.
Signal d'alerteUn runner persistant sur une VM, partagé par tous les dépôts, y compris publics.
Question 5 · confirmé
Votre workflow déploie sur Azure avec le secret d'un principal de service. Par quoi le remplacez-vous, et que doit vérifier la confiance ?
Une bonne réponseUne identité fédérée (federated credential) sur une application Entra ID ou une identité managée, dont le sujet correspond au dépôt et à l'environnement, par exemple repo:organisation/depot:environment:production. Le job demande la permission id-token: write et azure/login se connecte sans secret. Même principe sur AWS avec un rôle dont la politique de confiance vérifie l'audience et le sub, ou sur GCP. Ensuite, il supprime l'ancien secret.
Signal d'alerteGarder le secret et le renouveler tous les ans, ou un principal de service propriétaire de tout l'abonnement.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
DevOps GitHub Actions : questions fréquentes
Quelles compétences attendre d'un ingénieur DevOps GitHub Actions ?
La syntaxe des workflows ne suffit pas. On attend la réutilisation par reusable workflows et actions maison, l'exploitation de runners auto-hébergés, l'authentification OIDC vers le cloud, les environnements protégés et la sécurité face aux actions tierces et aux pull requests externes. S'y ajoute le socle DevOps du poste : Docker, Kubernetes, Terraform, un cloud, du Bash ou du Python. Un bon profil sait aussi expliquer d'où vient sa facture de minutes.
Quel crédit accorder à la certification GitHub Actions ?
Elle montre que la personne connaît la syntaxe, les déclencheurs, les actions et les fonctions d'entreprise de GitHub Actions. Elle ne dit rien de l'exploitation de runners à grande échelle ni des incidents de sécurité vécus. C'est un indice parmi d'autres ; compte surtout un workflow concret que la personne a conçu, avec ses choix de permissions, de secrets et de déclencheurs.
Comment évaluer un profil qui vient de GitLab CI ou de Jenkins ?
Les notions se transposent : jobs, déclencheurs, runners ou agents, secrets, environnements. L'écart porte sur le modèle de réutilisation, la place de la marketplace et les pièges propres à GitHub, comme pull_request_target ou les tags d'actions déplaçables. Pour un profil GitLab ou Jenkins, les questions de sécurité s'accompagnent d'une description du mécanisme. S'il raisonne juste sur les risques, l'outil s'apprend vite.
Comment construire l'exercice pratique d'un DevOps GitHub Actions ?
Un workflow existant à relire en direct fait un bon test technique. Le fichier comporte des défauts réalistes : action tierce référencée par tag, permissions larges, titre de PR inséré dans un run, clé cloud dans les secrets, déploiement sans environnement protégé. La personne dit ce qu'elle corrige et dans quel ordre. Un profil confirmé trouve la plupart des défauts et commence par ceux qui exposent les secrets.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
