Les offres le nomment administrateur GitLab, expert GitLab, ingénieur usine logicielle ou administrateur de forge, souvent avec Artifactory, Nexus et SonarQube dans le même périmètre. Le poste concerne surtout les instances auto-hébergées, installées par le paquet Linux sur des VM ou par le chart Helm sur Kubernetes. Les questions d'entretien pour un administrateur GitLab portent donc sur l'exploitation de la plateforme plus que sur la syntaxe du fichier .gitlab-ci.yml.
Un piège revient souvent : le CV d'un ingénieur DevOps qui a beaucoup utilisé GitLab CI mais n'a jamais mené une montée de version ni restauré une sauvegarde. La différence s'entend vite. Un administrateur parle des arrêts obligatoires entre versions, du fichier gitlab-secrets.json, de Gitaly et des files Sidekiq. Les migrations depuis Jenkins, Bitbucket ou une autre instance GitLab font aussi partie des missions.
Le calendrier pèse sur le poste. GitLab sort une version mineure chaque mois et une majeure chaque année en mai, et l'exécuteur Docker Machine, encore courant pour l'autoscaling des runners, doit disparaître avec GitLab 20.0 en mai 2027. Le PDF propose 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Les composants d'une instance GitLab auto-hébergée
Paquet Linux (Omnibus)
L'installation la plus répandue : un seul paquet qui embarque l'application, PostgreSQL, Redis, Gitaly et nginx, configurés par le fichier gitlab.rb. Il convient à la majorité des instances et se répartit sur plusieurs serveurs quand la charge augmente. Un administrateur doit le connaître en détail.
Chart Helm et Cloud Native Hybrid
Le chart Helm fait tourner les composants sans état de GitLab dans Kubernetes. En production, PostgreSQL, Redis ou Valkey et le stockage objet restent en dehors du cluster. Ce mode demande de vraies compétences Kubernetes en plus de GitLab.
Gitaly et Gitaly Cluster (Praefect)
Gitaly stocke et sert les dépôts Git. Gitaly Cluster (Praefect) ajoute la réplication et la bascule automatique, au prix d'une complexité réelle et de limites sur les sauvegardes. C'est le composant le plus sensible pour les performances.
PostgreSQL, Redis ou Valkey, Sidekiq
PostgreSQL porte les données de l'application, Redis ou Valkey le cache et les files, Sidekiq les tâches en arrière-plan. GitLab 19 exige au moins PostgreSQL 17. Une file Sidekiq qui grossit retarde les pipelines et les notifications.
GitLab Runner
Le programme qui exécute les jobs CI, sur Docker, Kubernetes, des VM ou un shell. L'administrateur gère la flotte : enregistrement par jeton d'authentification, autoscaling avec Docker Autoscaler et les plugins fleeting, isolation entre projets. Docker Machine est déprécié depuis la 17.5.
Sauvegarde et Geo
gitlab-backup sauvegarde la base et les dépôts, mais pas la configuration ni gitlab-secrets.json. Les sauvegardes côté serveur et incrémentales réduisent la durée sur les grosses instances. Geo, en Premium et Ultimate, maintient un site secondaire pour la reprise après sinistre.
Authentification : LDAP, SAML, SCIM
Connexion à l'annuaire de l'entreprise, synchronisation des groupes et blocage automatique des comptes au départ. Une erreur de configuration peut bloquer tous les utilisateurs, administrateurs compris, d'où l'importance d'un compte de secours.
API, Terraform et automatisation
L'API REST et GraphQL, le provider Terraform GitLab et python-gitlab servent à créer groupes, projets, règles de protection et runners sans clics. Un exemple de script d'administration écrit par le candidat en dit plus que la liste des outils.
L'administrateur GitLab travaille dans l'équipe outillage, usine logicielle ou plateforme, au service de toutes les équipes de développement. Le poste se trouve surtout là où l'entreprise héberge sa propre instance, pour garder le code chez elle ou pour des raisons de coût et de contrôle. Les offres associent souvent GitLab à Artifactory ou Nexus, SonarQube, Kubernetes et Ansible, et demandent régulièrement de migrer des projets depuis Jenkins ou Bitbucket. Selon l'édition (CE, Premium ou Ultimate), des fonctions comme Geo, SCIM ou l'audit complet sont disponibles ou non. L'édition sur laquelle le candidat a travaillé compte donc.
Six domaines d'exploitation qu'un administrateur GitLab maîtrise
- Installation et configuration (paquet Linux, Helm)
- Montées de version et correctifs
- Sauvegarde, restauration et Geo
- Haute disponibilité et performance
- Administration de la flotte de runners
- Identités, droits et automatisation
Situations de run GitLab et réponses attendues
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é
L'instance est en 17.3 et doit passer en 19. Comment préparez-vous la montée de version ?
Une bonne réponseIl calcule le chemin avec les arrêts obligatoires, par exemple avec l'outil Upgrade Path de GitLab. Depuis la 17.5, les arrêts tombent sur les versions x.2, x.5, x.8 et x.11, avec le dernier patch de chacune. Entre deux arrêts, il attend la fin des migrations en arrière-plan. Il lit les changements cassants des versions majeures 18.0 et 19.0, vérifie les prérequis, dont PostgreSQL 17 au minimum pour GitLab 19, sauvegarde l'instance et les fichiers de configuration, et répète l'opération sur une copie de recette pour mesurer la durée. Il vérifie aussi la compatibilité des runners.
Signal d'alerteInstaller directement le dernier paquet sur la 17.3. Enchaîner les versions sans attendre la fin des migrations en arrière-plan.
Question 2 · confirmé
Vous restaurez la sauvegarde de cette nuit sur un serveur neuf. Les projets reviennent, mais les variables CI/CD et l'authentification à deux facteurs ne fonctionnent plus. Que s'est-il passé ?
Une bonne réponseLe fichier gitlab-secrets.json n'a pas été restauré. Il contient les clés qui chiffrent certaines colonnes de la base : variables CI/CD, secrets de double authentification, jetons des runners. gitlab-backup create ne sauvegarde ni ce fichier ni gitlab.rb, qu'il faut sauvegarder à part. Il rappelle aussi qu'une sauvegarde ne se restaure que sur exactement la même version et la même édition (CE ou EE).
Signal d'alerteAccuser une base corrompue, ou recréer les variables à la main sans comprendre la cause.
Question 3 · senior
Sur une instance de 3 000 utilisateurs installée sur un seul serveur, les push et les clones ralentissent aux heures de pointe. Que regardez-vous, et quand passez-vous à une architecture répartie ?
Une bonne réponseLes métriques fournies avec GitLab (Prometheus et Grafana) : latence des appels Gitaly et charge processeur, saturation de Puma, files Sidekiq, requêtes lentes PostgreSQL, entrées-sorties disque. La cause fréquente est la CI qui clone en masse : profondeur de clone, cache de pack-objects de Gitaly, gros dépôts à entretenir. Pour l'architecture, il s'appuie sur les architectures de référence de GitLab, qui recommandent en général la haute disponibilité à partir de 3 000 utilisateurs, avec Gitaly, PostgreSQL, Redis ou Valkey, Sidekiq et les nœuds Rails séparés, dimensionnés sur le nombre réel de requêtes par seconde.
Signal d'alerteDoubler la mémoire du serveur sans mesure, ou déplacer les dépôts sur un partage NFS.
Question 4 · confirmé
Chaque matin, les jobs attendent dix minutes un runner, puis la flotte reste vide l'après-midi. Comment redimensionnez-vous les runners ?
Une bonne réponseIl mesure le temps d'attente des jobs, la concurrence et les métriques du runner manager. Il passe à un autoscaling : exécuteur Docker Autoscaler ou instance, avec les plugins fleeting sur des groupes d'autoscaling AWS, Google Cloud ou Azure, ou bien exécuteur Kubernetes avec un autoscaler de nœuds. Il règle le nombre de machines gardées en attente selon les plages horaires, les limites de concurrence, un cache distribué en stockage objet et des tags pour isoler les gros jobs. Il sait que l'exécuteur Docker Machine est déprécié depuis la 17.5 et doit être retiré dans GitLab 20.0.
Signal d'alerteAjouter des VM fixes qui tournent jour et nuit. Garder Docker Machine sans plan de remplacement.
Question 5 · confirmé
L'entreprise passe à l'authentification SAML avec Entra ID. Comment traitez-vous les comptes existants, les groupes et les départs ?
Une bonne réponseIl relie les identités SAML aux comptes existants au lieu d'en créer de nouveaux, teste avec un groupe pilote et garde un compte administrateur local de secours. Il synchronise les groupes de l'annuaire vers les groupes GitLab avec leurs rôles, et automatise le provisionnement et le blocage des comptes (SCIM, disponible en Premium et Ultimate, ou synchronisation LDAP). Un compte bloqué ne peut plus utiliser ses jetons. Il fait aussi la revue des comptes inactifs, qui consomment des licences.
Signal d'alerteRecréer tous les comptes et perdre l'historique des contributions. Couper la connexion par mot de passe avant d'avoir testé, ce qui enferme les administrateurs dehors.
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
Administrateur GitLab, les questions fréquentes
Administrateur GitLab ou ingénieur GitLab CI : faut-il le même profil ?
Non. L'ingénieur GitLab CI écrit et maintient les pipelines, les templates partagés et les règles de déploiement. L'administrateur fait tourner la plateforme : versions, sauvegardes, performances, runners, authentification. Les deux se parlent tous les jours et certains profils couvrent les deux. Si l'instance est hébergée par GitLab (GitLab.com), le besoin d'administration est faible et un profil CI suffit. Avec une instance auto-hébergée, il faut quelqu'un qui maîtrise l'exploitation.
Un administrateur Jenkins ou Bitbucket peut-il prendre un poste GitLab ?
Souvent, oui, s'il a une solide base Linux et une expérience d'exploitation : sauvegardes, montées de version, supervision, annuaire. Il devra apprendre l'architecture propre à GitLab (Gitaly, Sidekiq, arrêts de montée de version) et la gestion des runners. L'entretien teste sa logique sur une panne ou une montée de version plutôt que sa connaissance des commandes GitLab, qui s'apprennent en quelques semaines.
Quel test technique est donné à un administrateur GitLab ?
Le plus parlant est une mise en situation sur une VM de test : une instance GitLab en panne ou à mettre à jour, avec un temps limité et le droit de consulter la documentation. Un cas écrit convient aussi, comme une restauration qui échoue ou des runners saturés, avec un plan d'action à proposer. Le candidat commente sa démarche à voix haute : la méthode compte autant que la commande exacte.
GitLab CE, Premium ou Ultimate : qu'est-ce que ça change pour le poste ?
L'édition fixe une partie des outils de l'administrateur. Geo, SCIM et la synchronisation de groupes, les événements d'audit complets ou certaines règles d'approbation demandent Premium ou Ultimate. Un candidat qui n'a connu que la Community Edition peut tenir le poste, mais il devra découvrir ces fonctions. À l'inverse, sur une instance CE, il doit savoir compenser certaines absences par des scripts ou d'autres outils.
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.
