# Questions d'Entretien CI/CD Pipeline : GitHub Actions, GitLab CI et Jenkins en 2026

> Préparez vos entretiens CI/CD 2026 avec les questions techniques les plus fréquentes sur GitHub Actions, GitLab CI et Jenkins. Exemples de code, comparaison des plateformes et bonnes pratiques de sécurité.

- Published: 2026-05-18
- Updated: 2026-05-18
- Author: SharpSkill
- Tags: ci-cd, github-actions, gitlab-ci, jenkins, devops, interview, pipeline
- Reading time: 12 min

---

Les pipelines CI/CD constituent un pilier fondamental de l'ingénierie logicielle moderne. En 2026, la maîtrise de GitHub Actions, GitLab CI et Jenkins représente un prérequis pour tout professionnel DevOps ou développeur senior candidatant à des postes techniques. Les recruteurs évaluent désormais non seulement la capacité à écrire des fichiers de configuration, mais aussi la compréhension approfondie des modèles d'exécution, des stratégies de sécurité et des patterns d'optimisation propres à chaque plateforme.

Cet article analyse les questions d'entretien les plus fréquentes sur les pipelines CI/CD en 2026, avec des exemples concrets exploitables immédiatement en production. Chaque section couvre un outil majeur, accompagné de code fonctionnel et d'explications techniques détaillées.

> **Trois plateformes, une logique commune**
>
> Malgré des syntaxes différentes, GitHub Actions, GitLab CI et Jenkins partagent les mêmes concepts fondamentaux : déclencheurs, étapes séquentielles ou parallèles, gestion des secrets, et portes d'approbation manuelle. Comprendre cette structure commune permet de répondre avec assurance aux questions d'entretien, quelle que soit la plateforme ciblée.

## GitHub Actions : Structure d'un Workflow CI Complet

GitHub Actions utilise des fichiers YAML placés dans le répertoire `.github/workflows/` du dépôt. Chaque workflow se compose de jobs qui s'exécutent en parallèle par défaut, sauf si des dépendances explicites sont déclarées via le mot-clé `needs`. Cette architecture favorise la rapidité d'exécution tout en permettant un contrôle fin de l'ordonnancement.

La question d'entretien la plus classique consiste à demander au candidat de concevoir un pipeline CI complet avec lint, tests et déploiement conditionnel. Le workflow suivant illustre les bonnes pratiques attendues en 2026.

```yaml
# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint              # waits for lint to pass
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # runs tests on both versions
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # requires approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh
```

Plusieurs éléments méritent une attention particulière lors d'un entretien. La directive `needs: lint` dans le job `test` établit une dépendance explicite : les tests ne s'exécutent que si le linting réussit. Sans cette directive, les deux jobs s'exécuteraient simultanément, ce qui gaspillerait des ressources en cas d'erreur de linting.

La stratégie `matrix` permet d'exécuter les tests sur plusieurs versions de Node.js en parallèle. Ce pattern est systématiquement interrogé en entretien, car il démontre la compréhension de la compatibilité multi-versions et de l'optimisation des ressources CI.

Le job `deploy` combine deux mécanismes de protection : la condition `if: github.ref == 'refs/heads/main'` restreint le déploiement à la branche principale, tandis que le champ `environment: production` active les règles de protection d'environnement configurées dans les paramètres du dépôt (approbation requise, délai d'attente, restrictions de branches).

### Questions d'entretien sur GitHub Actions

**Comment fonctionne la mise en cache des dépendances ?** La directive `cache: npm` dans `actions/setup-node` détecte automatiquement le fichier `package-lock.json` et restaure le cache `node_modules` entre les exécutions. Cette optimisation réduit considérablement la durée des pipelines, passant souvent de plusieurs minutes à quelques secondes pour l'installation des dépendances.

**Quelle est la différence entre `on: push` et `on: pull_request` ?** Le déclencheur `push` s'active lors de chaque commit poussé sur les branches spécifiées. Le déclencheur `pull_request` s'active lors de la création ou mise à jour d'une pull request ciblant ces branches. En combinant les deux, le pipeline valide aussi bien les commits directs que les contributions via PR.

**Comment gérer les secrets dans GitHub Actions ?** Les secrets sont stockés au niveau du dépôt, de l'organisation ou de l'environnement. Ils sont accessibles via la syntaxe `${{ secrets.NOM_SECRET }}` et ne sont jamais affichés dans les logs. Les secrets d'environnement offrent un niveau supplémentaire de protection car ils ne sont accessibles qu'aux jobs associés à l'environnement correspondant.

## GitLab CI : Pipeline Stage-Based

GitLab CI repose sur un fichier unique `.gitlab-ci.yml` à la racine du dépôt. Son modèle d'exécution est fondamentalement différent de celui de GitHub Actions : les stages s'exécutent séquentiellement, tandis que les jobs au sein d'un même stage s'exécutent en parallèle. Cette distinction constitue une question d'entretien récurrente.

```yaml
# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

variables:
  NODE_VERSION: "22"

lint:
  stage: validate
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run lint

unit-tests:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["20", "22"]
  script:
    - npm ci
    - npm test
  artifacts:
    reports:
      junit: coverage/junit.xml
    expire_in: 7 days

deploy-production:
  stage: deploy
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual                   # manual gate
  environment:
    name: production
    url: https://app.example.com
  script:
    - ./deploy.sh
```

Le système de cache de GitLab CI mérite une analyse approfondie. La clé `${CI_COMMIT_REF_SLUG}` génère un cache spécifique par branche, évitant les conflits entre les pipelines de branches différentes. Les artifacts, distincts du cache, persistent les résultats de build entre les stages et peuvent être téléchargés après l'exécution du pipeline.

La directive `parallel: matrix` de GitLab CI offre un mécanisme similaire à la `strategy.matrix` de GitHub Actions. Chaque combinaison de la matrice génère un job distinct qui s'exécute en parallèle au sein du même stage. Les rapports JUnit générés par les artifacts sont automatiquement intégrés à l'interface de merge request de GitLab.

Le déploiement utilise `when: manual` pour créer une porte d'approbation. Contrairement à GitHub Actions où cette fonctionnalité repose sur les environnements protégés, GitLab CI l'intègre directement dans la définition du job. La section `environment` associe le déploiement à un environnement nommé, activant le suivi des déploiements dans l'interface GitLab.

### Questions d'entretien sur GitLab CI

**Quelle est la différence entre `rules` et `only/except` ?** Les directives `only/except` sont dépréciées depuis GitLab 13. La directive `rules` offre une syntaxe plus expressive avec des conditions composables (`if`, `changes`, `exists`) et des actions (`when: manual`, `when: delayed`). Les candidats qui utilisent encore `only/except` révèlent une connaissance obsolète de la plateforme.

**Comment fonctionnent les variables d'environnement dans GitLab CI ?** GitLab CI propose plusieurs niveaux de variables : projet, groupe, instance, et pipeline. Les variables marquées comme « protégées » ne sont accessibles que dans les pipelines exécutés sur des branches protégées. Les variables « masquées » sont cachées dans les logs. Cette hiérarchie granulaire surpasse le modèle de secrets de GitHub Actions en termes de flexibilité.

**Comment optimiser la durée d'un pipeline GitLab CI ?** Trois stratégies principales : le cache distribué réduit le temps d'installation des dépendances, la directive `parallel` exploite le parallélisme au sein d'un stage, et les `rules: changes` permettent de ne déclencher un job que si les fichiers pertinents ont été modifiés. Le DAG (Directed Acyclic Graph) via `needs` permet également de contourner l'exécution séquentielle des stages.

## Jenkins : Pipeline Déclaratif avec Jenkinsfile

Jenkins occupe une position unique dans l'écosystème CI/CD : entièrement auto-hébergé, hautement extensible via ses 1 800+ plugins, et privilégié par les organisations qui nécessitent un contrôle total sur leur infrastructure. Le Jenkinsfile, écrit en syntaxe déclarative Groovy, définit le pipeline comme du code versionné dans le dépôt.

```groovy
// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // configured in Jenkins Global Tool
    }

    environment {
        CI = 'true'
        DEPLOY_ENV = credentials('deploy-env-secret')
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint & Test') {
            parallel {             // parallel execution
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Test') {
                    steps {
                        sh 'npm test'
                    }
                    post {
                        always {
                            junit 'coverage/junit.xml'
                        }
                    }
                }
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            input {
                message 'Deploy to production?'
            }
            steps {
                sh './deploy.sh'
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build failed: ${env.JOB_NAME}",
                 body: "Check ${env.BUILD_URL}"
        }
    }
}
```

La structure déclarative de Jenkins impose une hiérarchie stricte : `pipeline > stages > stage > steps`. Le bloc `parallel` au sein d'un stage permet d'exécuter le lint et les tests simultanément, optimisant la durée totale du pipeline.

La directive `tools` référence des outils configurés globalement dans l'administration Jenkins. Ce mécanisme centralise la gestion des versions d'outils à travers tous les pipelines de l'organisation, évitant les divergences de configuration entre projets.

Le bloc `input` crée une porte d'approbation interactive : le pipeline se met en pause et attend qu'un utilisateur autorise la poursuite du déploiement. Ce mécanisme, combiné avec la directive `when { branch 'main' }`, offre un double niveau de protection pour les déploiements en production.

La section `post` gère les actions post-exécution. La condition `failure` déclenche l'envoi d'un email de notification uniquement en cas d'échec, intégrant dynamiquement le nom du job et l'URL du build via les variables d'environnement Jenkins.

### Questions d'entretien sur Jenkins

**Quelle est la différence entre pipeline déclaratif et scripté ?** La syntaxe déclarative (avec le bloc `pipeline {}`) impose une structure prédéterminée, facilitant la lisibilité et la maintenance. La syntaxe scriptée (avec le bloc `node {}`) offre une flexibilité totale en Groovy, mais au prix d'une complexité accrue. En 2026, la syntaxe déclarative est recommandée pour la majorité des cas d'usage, la syntaxe scriptée étant réservée aux pipelines hautement dynamiques.

**Comment sécuriser les credentials dans Jenkins ?** Le plugin Credentials stocke les secrets de manière chiffrée. La directive `credentials()` dans le bloc `environment` injecte les secrets comme variables d'environnement, les masquant automatiquement dans les logs. Jenkins supporte plusieurs types de credentials : texte secret, nom d'utilisateur/mot de passe, fichier, et certificat SSH.

**Comment Jenkins gère-t-il la scalabilité ?** L'architecture maître/agent permet de distribuer les builds sur plusieurs machines. Les agents peuvent être physiques, virtuels, ou éphémères (conteneurs Docker, pods Kubernetes via le plugin Kubernetes). La directive `agent { kubernetes { ... } }` crée des pods à la demande pour chaque build, optimisant l'utilisation des ressources.

## Sécurité des Pipelines : Épinglage et Supply Chain

La sécurité de la chaîne d'approvisionnement CI/CD est devenue un sujet majeur d'entretien en 2026. L'attaque par compromission d'une action GitHub tierce via le déplacement d'un tag constitue un vecteur de menace documenté. L'épinglage par SHA de commit représente la contre-mesure recommandée.

```yaml
# .github/workflows/secure.yml
steps:
  # Vulnerable: tag can be moved to malicious commit
  - uses: actions/checkout@v4

  # Secure: pinned to exact commit SHA
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
```

La référence par tag (`@v4`) est résolue dynamiquement par GitHub : si un mainteneur malveillant (ou un compte compromis) déplace le tag vers un commit contenant du code malicieux, tous les workflows utilisant ce tag exécutent automatiquement le code compromis. L'épinglage par SHA (`@11bd71901...`) référence un commit immuable, immunisant le pipeline contre ce type d'attaque.

En pratique, l'outil Dependabot ou Renovate Bot peut automatiser la mise à jour des SHA tout en maintenant la sécurité. Cette approche combine les avantages de l'immuabilité (sécurité) et de l'automatisation (maintien à jour).

Les recruteurs posent fréquemment des questions sur les autres vecteurs d'attaque CI/CD : injection de commandes via les titres de PR (`${{ github.event.pull_request.title }}`), exfiltration de secrets par des workflows de forks, et élévation de privilèges via les permissions GITHUB_TOKEN. La connaissance de ces vecteurs distingue les profils seniors des profils intermédiaires.

## Tableau Comparatif des Trois Plateformes

| Fonctionnalité | GitHub Actions | GitLab CI | Jenkins |
|---|---|---|---|
| Fichier de configuration | `.github/workflows/*.yml` | `.gitlab-ci.yml` | `Jenkinsfile` |
| Modèle d'exécution | Job-based (parallèle par défaut) | Stage-based (stages séquentiels) | Stage-based (flexible) |
| Hébergement des runners | GitHub-hosted + self-hosted | GitLab.com partagé + self-hosted | Self-hosted uniquement |
| Stockage des secrets | Secrets dépôt/org/environnement | Variables CI/CD (protégées) | Plugin Credentials |
| Builds matriciels | `strategy.matrix` | `parallel:matrix` | `matrix` (plugin) |
| Portes manuelles | `environment` + reviewers requis | `when: manual` | Directive `input` |
| Marketplace | 20 000+ Actions sur le Marketplace | Catalogue de composants CI/CD | 1 800+ plugins |
| Fonctionnalités IA | Copilot for Actions (preview) | Duo CI Expert Agent (beta) | Plugins communautaires |
| Tarification | Gratuit pour les dépôts publics, à la minute pour les privés | 400 minutes CI/CD gratuites, puis paliers | Gratuit (open source), auto-géré |

Ce tableau constitue un outil de référence précieux en entretien. Les recruteurs attendent une capacité à comparer objectivement les plateformes, en identifiant les forces et les compromis de chacune selon le contexte organisationnel.

## Questions Transversales Fréquentes en Entretien

**Comment choisir entre GitHub Actions, GitLab CI et Jenkins ?** Le choix dépend du contexte organisationnel. GitHub Actions convient aux équipes déjà présentes sur GitHub, avec un écosystème d'actions riche et une configuration minimale. GitLab CI s'impose pour les organisations utilisant GitLab comme plateforme DevOps intégrée (SCM + CI/CD + registre + monitoring). Jenkins reste pertinent pour les entreprises nécessitant un contrôle total de l'infrastructure, une personnalisation avancée, ou une intégration avec des systèmes legacy.

**Qu'est-ce que le pattern « shift-left » en CI/CD ?** Le shift-left consiste à déplacer les vérifications de qualité et de sécurité le plus tôt possible dans le pipeline. Concrètement, cela signifie exécuter le linting, l'analyse statique (SAST), et les tests unitaires avant les tests d'intégration et le déploiement. Ce pattern réduit le coût de correction des défauts en les détectant au plus près du moment où ils sont introduits.

**Comment implémenter le déploiement blue-green avec un pipeline CI/CD ?** Le déploiement blue-green maintient deux environnements de production identiques. Le pipeline déploie la nouvelle version sur l'environnement inactif, exécute les tests de validation (smoke tests, health checks), puis bascule le trafic via un load balancer ou un service mesh. En cas d'échec, le rollback consiste à rebasculer le trafic vers l'environnement précédent, sans redéploiement.

**Qu'est-ce que GitOps et comment les pipelines CI/CD s'y intègrent ?** GitOps utilise un dépôt Git comme source unique de vérité pour l'état désiré de l'infrastructure. Le pipeline CI construit et teste l'application, puis met à jour le manifeste de déploiement dans le dépôt GitOps. Un opérateur (ArgoCD, Flux) détecte le changement et synchronise l'état du cluster Kubernetes. Ce modèle sépare strictement le CI (build/test) du CD (déploiement), améliorant l'auditabilité et la reproductibilité.

Pour approfondir chaque plateforme et consolider les acquis, les ressources suivantes couvrent l'ensemble des sujets abordes dans cet article : les [fondamentaux du CI/CD](/technologies/devops/interview-questions/ci-cd-fundamentals), les questions specifiques a [GitHub Actions](/technologies/devops/interview-questions/github-actions), les exercices dedies a [GitLab CI](/technologies/devops/interview-questions/gitlab-ci), le module complet sur [Jenkins](/technologies/devops/interview-questions/jenkins), ainsi que les [questions essentielles d'entretien DevOps](/blog/devops/essential-devops-interview-questions) qui couvrent l'ecosysteme dans son ensemble.

## Conclusion

La préparation aux entretiens CI/CD en 2026 exige une compréhension qui dépasse la simple mémorisation de syntaxe YAML ou Groovy. Les recruteurs évaluent la capacité à raisonner sur les architectures de pipelines, les compromis entre les plateformes, et les implications de sécurité des choix techniques.

Les points essentiels à retenir :

- **GitHub Actions** excelle par son intégration native avec l'écosystème GitHub, son modèle d'exécution parallèle par défaut et son marketplace de plus de 20 000 actions
- **GitLab CI** se distingue par son approche plateforme intégrée, sa gestion granulaire des variables et son modèle stage-based intuitif
- **Jenkins** reste incontournable pour les organisations nécessitant un contrôle total de l'infrastructure et une extensibilité illimitée via les plugins
- **La sécurité** de la supply chain CI/CD (épinglage par SHA, gestion des permissions, protection contre l'injection) constitue désormais un sujet d'entretien à part entière
- **Les patterns transversaux** (shift-left, blue-green, GitOps) démontrent une vision architecturale qui distingue les profils seniors
- **La comparaison objective** des plateformes, en fonction du contexte organisationnel plutôt que de préférences personnelles, révèle la maturité technique du candidat

La maîtrise combinée de ces trois plateformes, associée à une compréhension des enjeux de sécurité et des patterns de déploiement modernes, constitue un atout décisif sur le marché DevOps en 2026.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/fr/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins