L'ingénieur DevOps GitLab CI écrit et maintient les fichiers .gitlab-ci.yml, les templates ou components partagés entre projets, les runners et leur autoscaling, et le passage vers les environnements. GitLab CI revient dans une bonne partie des offres DevOps en France, souvent sur une instance auto-hébergée avec des runners sur Kubernetes ou sur des VM. Beaucoup de missions portent aussi sur une migration depuis Jenkins.
Sur un CV, « GitLab CI » recouvre des expériences très différentes. Ajouter un job de tests dans un fichier existant n'apprend rien sur les pipelines de merge request en double, les caches qui se partagent mal entre runners ou un CI_JOB_TOKEN qui ouvre trop d'accès. Les profils qui ont porté une plateforme parlent de rules, de needs, de versions de components figées et de runners séparés selon ce qu'ils ont le droit de toucher.
Avant l'entretien, il faut connaître l'édition utilisée (Free, Premium ou Ultimate), car plusieurs fonctions en dépendent : approbations de déploiement, merge trains, une partie des rapports de sécurité. Le candidat ouvre un .gitlab-ci.yml qu'il a écrit et explique un choix qu'il ferait autrement aujourd'hui. Le cas pratique du PDF part d'un groupe de vingt projets à remettre en ordre.
GitLab CI/CD : les briques qu'un ingénieur DevOps assemble
.gitlab-ci.yml : stages, rules et needs
Le fichier qui décrit le pipeline, dans le dépôt. Les stages fixent l'ordre général, needs laisse un job démarrer dès que ses dépendances sont terminées, et rules décide si un job existe (branche, merge request, tag, fichiers modifiés). Une bonne part des pipelines lents ou lancés en double vient de ces trois mots-clés.
include, extends et CI/CD components
Les moyens de partager la configuration entre projets. include importe des fichiers, extends fait hériter un job d'un autre, et les components, publiés dans le CI/CD Catalog, sont des briques versionnées avec des paramètres typés appelés inputs. La documentation de GitLab recommande de figer leur version par tag ou par SHA plutôt que ~latest.
GitLab Runner
Le programme qui exécute les jobs, sur une VM, un serveur ou un cluster Kubernetes. L'exécuteur choisi (shell, docker, kubernetes, docker-autoscaler, instance) fixe l'isolement des jobs et la façon de monter en charge. Les exécuteurs Instance et Docker Autoscaler remplacent l'ancien autoscaling par Docker Machine. Un runner se crée maintenant avec un jeton d'authentification glrt-, l'ancien jeton d'enregistrement étant déprécié.
Pipelines parent-enfant et multi-projets
Un pipeline peut en déclencher d'autres, dans le même projet (enfant) ou dans un autre (multi-projets). C'est utile pour un monorepo où chaque service a son pipeline, ou pour générer un pipeline à partir d'un fichier produit par un job. Les pipelines enfants sont limités à deux niveaux.
Environnements, déploiements et review apps
GitLab suit ce qui est déployé et où. Dans les éditions Premium et Ultimate, un environnement de production peut être protégé et soumis à des approbations, et resource_group empêche deux déploiements simultanés. Les review apps créent un environnement temporaire par merge request et le suppriment à la fusion.
Variables CI/CD, Vault et OIDC
Les variables portent la configuration et les secrets, avec les options masquée, protégée et cachée. Pour un cloud ou pour Vault, le mot-clé id_tokens donne au job un jeton OIDC signé que le fournisseur échange contre des droits temporaires, sans clé stockée dans GitLab. Les anciennes variables CI_JOB_JWT ne sont plus la méthode à suivre.
Container Registry et Package Registry
Les registres intégrés à chaque projet, pour les images de conteneur et les paquets (Maven, npm, PyPI, NuGet, Helm). Les jobs s'y authentifient avec leur jeton de job. Des règles de nettoyage évitent qu'ils grossissent sans fin.
Scans de sécurité intégrés
GitLab fournit des analyseurs pour le SAST, la détection de secrets, les dépendances et les images de conteneur. Une partie fonctionne dans toutes les éditions, mais les rapports dans la merge request, les politiques de sécurité et plusieurs analyseurs demandent Ultimate. L'édition en place se vérifie avant d'en faire un critère d'entretien.
On croise ce profil dans des équipes plateforme qui fournissent la CI à des dizaines de projets, et dans des équipes produit qui tiennent leur propre chaîne. Le premier cas demande de concevoir des components et des runners partagés, le second de bien connaître le pipeline d'un projet et son déploiement. GitLab publie une version mineure chaque mois et la syntaxe a beaucoup bougé : only et except cèdent la place à rules, les templates aux components, les variables CI_JOB_JWT à id_tokens. Un CV resté sur les anciennes pratiques n'est pas disqualifiant, à condition que la personne sache ce qui a changé.
GitLab CI : les compétences qui distinguent un profil confirmé
- Conception de pipelines : rules, needs, workflow
- Réutilisation : include, extends, components
- Runners : exécuteurs, autoscaling, isolement
- Performance : cache, artefacts, parallélisme
- Sécurité de la chaîne : variables, jetons, OIDC
- Déploiement : environnements, review apps, retour arrière
Ce qu'un bon candidat répond sur GitLab CI, en cinq questions
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é
Chaque push sur une branche qui a une merge request ouverte lance deux pipelines. Pourquoi, et comment corrigez-vous ?
Une bonne réponseUn pipeline de branche et un pipeline de merge request partent pour le même commit, parce que rien ne les sépare. La correction se fait dans workflow:rules : un pipeline de merge request quand $CI_PIPELINE_SOURCE vaut merge_request_event, un pipeline de branche seulement si aucune MR n'est ouverte ($CI_OPEN_MERGE_REQUESTS vide), plus la branche par défaut et les tags. Il connaît les templates Workflows/MergeRequest-Pipelines et Workflows/Branch-Pipelines.
Signal d'alerteSupprimer l'un des deux pipelines au hasard, ou payer deux fois les minutes de runner sans chercher la cause.
Question 2 · confirmé
Le pipeline d'un projet prend 40 minutes. Comment le faites-vous descendre sans retirer de tests ?
Une bonne réponseIl mesure d'abord la durée de chaque job et le temps passé à attendre un runner. Puis needs pour sortir de l'ordre strict des stages, parallel pour découper les tests, un cache des dépendances dont la clé suit le fichier de verrouillage (cache:key:files), des artefacts réduits à ce qui sert ensuite, rules:changes pour ne lancer que les jobs concernés, et interruptible pour annuler un pipeline rendu inutile par un nouveau push. Il distingue le cache, qui accélère, de l'artefact, qui transmet un résultat.
Signal d'alerte« On prend des runners plus gros » sans mesure, ou des tests passés en allow_failure pour gagner du temps.
Question 3 · senior
Votre équipe plateforme doit fournir le build Docker standard à toute l'entreprise. Comment le publiez-vous dans GitLab, et comment le faites-vous évoluer sans casser les projets qui l'utilisent ?
Une bonne réponseUn CI/CD component dans un projet dédié, publié au CI/CD Catalog, avec des inputs typés (spec:inputs) pour l'image, le contexte et les tags. Des releases en version sémantique avec un changelog, et des projets qui référencent une version figée, un tag ou un SHA pour les plus prudents, plutôt que ~latest ou une branche. Un pipeline de test tourne sur le component à chaque modification. Une rupture passe par une version majeure, et les deux versions cohabitent un temps.
Signal d'alerteUn include d'un fichier pris sur la branche main d'un autre projet, que tous les projets reçoivent dès qu'il change.
Question 4 · confirmé
Votre job de déploiement obtient des droits cloud par OIDC. Sur quels critères le fournisseur cloud doit-il accepter le jeton émis par GitLab ?
Une bonne réponseLe job déclare id_tokens avec une audience propre au fournisseur. La relation de confiance vérifie l'émetteur (l'URL de l'instance GitLab), l'audience, puis des claims précis : le projet, de préférence par project_id qui ne change pas si le projet est renommé, la branche ou le tag, ref_protected à true, et l'environnement de déploiement. Le rôle obtenu n'a que les droits du déploiement, pour une durée courte.
Signal d'alerteUne confiance qui accepte tout jeton de l'instance ou de tout le groupe, ou une clé d'accès longue gardée en variable « en secours ».
Question 5 · senior
Vous administrez des runners partagés par toute l'entreprise. Comment empêchez-vous qu'un projet lise les secrets ou les artefacts d'un autre ?
Une bonne réponseDes jobs dans des conteneurs ou des VM jetables plutôt que l'exécuteur shell. Pas de mode privilégié ni de socket Docker montée sur les runners partagés, et une autre méthode pour construire les images (BuildKit rootless, Buildah, service de build dédié). Des runners protégés et réservés aux déploiements en production, qui ne prennent que les jobs des branches et tags protégés. Il limite aussi le CI_JOB_TOKEN par la liste d'autorisation entre projets.
Signal d'alerteUn runner shell unique, avec Docker en mode privilégié, pour tout le monde et y compris pour les déploiements.
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
Ingénieur DevOps GitLab CI : questions fréquentes
Que doit savoir faire un ingénieur DevOps GitLab CI, au-delà du YAML ?
L'entretien vérifie les règles de déclenchement (rules, workflow), la réutilisation par components, l'administration des runners et leur isolement, l'authentification OIDC vers le cloud et le déploiement par environnements. Le socle DevOps reste nécessaire : Linux, Docker, Kubernetes ou VM, Terraform, scripts Bash ou Python. Sur un poste plateforme, savoir concevoir pour plusieurs dizaines de projets compte plus que connaître un seul pipeline par cœur.
Un profil GitHub Actions s'adapte-t-il vite à GitLab CI ?
En général, oui. Les concepts se recoupent : jobs, déclencheurs, runners, secrets, OIDC, environnements. Le vocabulaire et la réutilisation diffèrent (components et include d'un côté, actions et reusable workflows de l'autre), tout comme l'administration des runners. Les questions portent sur des situations de l'outil en place, pour voir si la personne transpose correctement ce qu'elle connaît. Un raisonnement juste sur les rules et la sécurité des runners compte plus que la syntaxe exacte.
Dans quel ordre mener l'entretien technique d'un DevOps GitLab CI ?
L'entretien part d'un pipeline que la personne a conçu : ce qu'il fait, ce qui a posé problème, ce qu'elle changerait. Viennent ensuite des questions par thème (règles, runners, sécurité, déploiement), puis une mise en situation sur un .gitlab-ci.yml réel et anonymisé, à critiquer ou à accélérer. Chaque thème se note sur la même grille pour comparer les candidats entre eux. Le PDF suit ce découpage, avec six axes et un cas de 20 minutes.
Test à la maison ou exercice en direct : que choisir ?
Pour ce poste, un test technique court en direct suffit souvent. L'exercice part d'un .gitlab-ci.yml de 80 lignes avec des défauts réalistes : pipelines en double, cache mal employé, clé cloud en variable, déploiement lançable depuis n'importe quelle branche. La personne dit ce qu'elle corrige, dans quel ordre et pourquoi. En vingt minutes, on voit si elle pense d'abord sécurité ou confort, et si elle connaît les mots-clés actuels.
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.
