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

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.

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.

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

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

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

# .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, les questions specifiques a GitHub Actions, les exercices dedies a GitLab CI, le module complet sur Jenkins, ainsi que les questions essentielles d'entretien DevOps 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.