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

Les questions d'entretien sur les pipelines CI/CD figurent parmi les sujets les plus fréquents en recrutement DevOps en 2026. Avec GitHub Actions traitant désormais plus de 71 millions de jobs par jour et livrant l'exécution parallèle des steps en juin 2026, GitLab CI atteignant la version 19 avec son Secrets Manager natif, et Jenkins conservant un taux d'adoption de 28%, les recruteurs attendent des candidats une maîtrise pratique des trois plateformes.

Structure des Workflows et Déclencheurs GitHub Actions

GitHub Actions organise l'automatisation autour de workflows, jobs et steps. Un workflow est un fichier YAML stocké dans .github/workflows/ qui définit quand et comment l'automatisation s'exécute. Chaque workflow contient un ou plusieurs jobs, et chaque job s'exécute sur un runner distinct.

Une question d'entretien classique demande aux candidats d'expliquer la relation entre les triggers on, les dépendances entre jobs et le mot-clé needs.

# .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

Ce workflow illustre trois concepts clés : le mot-clé needs crée un graphe de dépendances entre jobs, la stratégie matrix permet de tester en parallèle sur plusieurs versions de Node.js, et le mot-clé environment conditionne les déploiements à une approbation manuelle.

Steps Parallèles dans GitHub Actions

GitHub Actions a livré l'exécution parallèle des steps le 25 juin 2026, répondant à l'une des fonctionnalités les plus demandées. Auparavant, tous les steps d'un job s'exécutaient séquentiellement. Cette nouveauté introduit quatre mots-clés permettant l'exécution concurrente au sein d'un même job.

# .github/workflows/parallel-steps.yml
name: Build with Parallel Steps

on:
  push:
    branches: [main]

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

      # Run lint and typecheck in parallel
      - name: lint
        run: npm run lint
        background: true

      - name: typecheck
        run: npm run typecheck
        background: true

      - wait-all:              # wait for both to complete

      # Or use the parallel shorthand
      - parallel:
          - name: build-frontend
            run: npm run build:frontend
          - name: build-backend
            run: npm run build:backend

      - run: npm run deploy

Le mot-clé background: true lance un step de façon asynchrone et passe immédiatement au step suivant. Le mot-clé wait-all suspend l'exécution jusqu'à ce que tous les steps en arrière-plan soient terminés. Le mot-clé parallel offre une syntaxe raccourcie qui exécute plusieurs steps simultanément et attend leur complétion avant de continuer.

Deux mots-clés supplémentaires existent : wait cible des steps nommés spécifiques en arrière-plan, et cancel termine proprement un step en arrière-plan lorsqu'il n'est plus nécessaire (utile pour arrêter des services longue durée).

Configuration de Pipeline GitLab CI avec Stages

GitLab CI utilise un fichier .gitlab-ci.yml à la racine du dépôt. Contrairement à GitHub Actions où les jobs s'exécutent indépendamment par défaut, GitLab CI organise les jobs en stages qui s'exécutent séquentiellement, tandis que les jobs au sein d'un même stage s'exécutent en parallèle.

Les recruteurs demandent fréquemment aux candidats de convertir un workflow GitHub Actions en pipeline GitLab CI, ou inversement.

# .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

Les différences clés avec GitHub Actions : les stages imposent un ordre d'exécution global, le mot-clé parallel:matrix gère les builds matriciels, et artifacts:reports:junit intègre les résultats de tests directement dans les vues de merge request.

GitLab 19.0 (mai 2026) a introduit le Secrets Manager en open beta, offrant un stockage natif des secrets sans services externes comme HashiCorp Vault. GitLab 19.2 (juillet 2026) a rendu les policies d'exécution de pipelines planifiés généralement disponibles, permettant aux équipes d'imposer des scans de conformité ou des vérifications de dépendances selon une cadence fixe sur plusieurs projets depuis une seule définition de policy.

Syntaxe de Pipeline Déclaratif Jenkins

Jenkins utilise un Jenkinsfile stocké à la racine du dépôt. La syntaxe de pipeline déclarative, recommandée comme standard en 2026, offre une gestion structurée des erreurs et une organisation claire basée sur les stages.

Une question d'entretien fréquente : expliquer la différence entre pipelines déclaratifs et scriptés, et quand utiliser chacun.

// 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}"
        }
    }
}

Les pipelines déclaratifs imposent une structure via les blocs obligatoires pipeline, agent et stages. La directive parallel à l'intérieur d'un stage exécute lint et tests simultanément. La directive input suspend l'exécution pour une approbation manuelle, similaire aux environments GitHub Actions et aux portes manuelles GitLab. Jenkins requiert Java 21 depuis janvier 2026, les environnements de pipeline doivent donc tenir compte de cette dépendance runtime.

Gestion des Secrets sur les Plateformes CI/CD

Chaque entretien CI/CD inclut des questions sur la gestion des secrets. Chaque plateforme gère les credentials différemment, et comprendre les implications de sécurité est essentiel.

GitHub Actions stocke les secrets au niveau du dépôt, de l'environnement ou de l'organisation. Les secrets sont masqués automatiquement dans les logs, mais le modèle de portée actuel a des limitations. La feuille de route sécurité 2026 introduit des secrets scopés qui lient les credentials à des contextes d'exécution explicites, adressant le risque d'accès trop large.

GitLab CI fournit des variables CI/CD avec des règles de protection. Les variables protégées ne sont injectées que dans les pipelines s'exécutant sur des branches ou tags protégés. GitLab 19.0 a introduit le Secrets Manager, permettant aux équipes de stocker et référencer les secrets nativement sans coffres externes. Les secrets sont scopés aux projets ou groupes et accessibles uniquement aux jobs qui les demandent explicitement.

Jenkins utilise le plugin Credentials avec plusieurs types de credentials (nom d'utilisateur/mot de passe, clé SSH, texte secret, certificat). L'helper credentials() dans les pipelines déclaratifs lie les secrets aux variables d'environnement, et les credentials au niveau Folder scopent l'accès à des projets spécifiques.

La réponse critique en entretien : ne jamais coder en dur les secrets dans les fichiers de pipeline, toujours utiliser la gestion native des secrets de la plateforme, effectuer une rotation régulière des credentials, et préférer les tokens à courte durée aux clés API longue durée.

Optimisation de Pipeline et Stratégies de Cache

Les pipelines lents impactent directement la productivité des développeurs. Les recruteurs testent si les candidats peuvent diagnostiquer et corriger les goulots d'étranglement de performance dans les systèmes CI/CD.

Trois techniques d'optimisation universelles s'appliquent aux trois plateformes :

Le cache des dépendances évite de re-télécharger les packages à chaque exécution. GitHub Actions utilise actions/cache ou le support de cache intégré dans les actions setup. GitLab CI utilise cache avec une stratégie de clé. Jenkins repose sur la persistance du workspace ou les commandes stash/unstash.

L'exécution parallèle répartit le travail sur plusieurs runners. GitHub Actions supporte maintenant à la fois les jobs parallèles (stratégie matrix) et les steps parallèles (mots-clés background/parallel). GitLab CI utilise parallel:matrix, et Jenkins utilise la directive parallel. La bonne granularité de découpage dépend du projet : trop de jobs parallèles gaspillent le temps de démarrage des runners, trop peu laissent de la capacité inutilisée.

L'exécution conditionnelle évite les stages inutiles. Les trois plateformes le supportent : GitHub Actions avec les expressions if, GitLab CI avec rules, et Jenkins avec les directives when. Un pipeline bien conçu évite les stages de déploiement sur les branches de fonctionnalité et évite de déclencher les suites de tests complètes pour les changements de lint uniquement.

Sécurité et Protection de la Supply Chain CI/CD

Les attaques de supply chain ciblant les systèmes CI/CD ont augmenté significativement en 2025, avec des incidents affectant tj-actions/changed-files et d'autres GitHub Actions populaires. Les questions d'entretien sondent désormais régulièrement les candidats sur les stratégies de durcissement.

Épingler les versions d'actions à des SHAs de commit spécifiques plutôt qu'à des tags pour prévenir les attaques par détournement de tag :

# .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

GitLab CI adresse les préoccupations de supply chain via les composants CI/CD avec attestation SLSA Level 1 (disponible depuis GitLab 18.1), fournissant une provenance plus claire lors de l'assemblage de pipelines à partir de composants réutilisables. Les tags de conteneurs immuables (GitLab 18.2) empêchent le remplacement d'images après publication.

Pour Jenkins, le mécanisme de Shared Library doit utiliser un dépôt dédié avec protection de branche, exigences de revue de code et commits signés. La Commission européenne a lancé un programme de Bug Bounty Jenkins via YesWeHack, reflétant le rôle critique de la plateforme dans les supply chains d'entreprise.

Comparaison Cross-Platform pour la Préparation aux Entretiens

Cette table de comparaison couvre les différences les plus fréquemment testées en entretien. La question de suivi demande typiquement : « Quelle plateforme choisiriez-vous pour un nouveau projet, et pourquoi ? » La réponse dépend de l'outillage existant, de la taille de l'équipe, des exigences de conformité, et de si l'organisation préfère une infrastructure gérée (GitHub/GitLab) ou un contrôle total (Jenkins).

Sources

• Actions steps can now be run in parallel (GitHub Changelog, juin 2026)
• GitLab 19.0 release notes (GitLab Docs, mai 2026)
• GitLab 19.2 release notes (GitLab Docs, juillet 2026)
• Jenkins Changelog (Jenkins.io, août 2026)
• GitHub Actions 2026 Security Roadmap (GitHub Blog)

Pour approfondir ces questions en pratique, consulter les modules fondamentaux CI/CD et GitHub Actions, ou explorer les questions spécifiques GitLab CI et Jenkins. Pour une préparation DevOps plus large, le guide des questions d'entretien DevOps essentielles couvre l'ensemble des sujets au-delà du CI/CD.

Points Clés pour les Entretiens CI/CD Pipeline

• Les steps parallèles GitHub Actions (background, wait-all, parallel) ont été livrés en juin 2026, permettant l'exécution concurrente au sein d'un même job tout en partageant le runner, checkout et workspace
• GitLab 19.x a introduit le Secrets Manager natif (open beta, mai 2026) et rendu les policies d'exécution de pipelines planifiés généralement disponibles (juillet 2026), réduisant la dépendance aux outils externes
• Jenkins 2.574+ a désassocié les plugins core incluant JUnit et Mailer du fichier WAR, nécessitant une installation explicite pour les instances sans accès au centre de mise à jour
• La gestion des secrets est le sujet de sécurité le plus testé sur les trois plateformes : démontrer la connaissance des secrets scopés, variables protégées et stratégies de rotation des credentials
• L'optimisation des pipelines via le cache, la parallélisation et l'exécution conditionnelle s'applique universellement et signale une expérience pratique en production aux recruteurs
• Préparer au moins une configuration de pipeline fonctionnelle par plateforme, en se concentrant sur des patterns réels plutôt que des exemples jouets