SonarQube Quality Gates : bloquer les mauvais commits avant la production

Un pipeline CI qui ne bloque pas les commits de mauvaise qualité est un pipeline décoratif. Les Quality Gates de SonarQube sont le mécanisme qui transforme une analyse statique en vrai filet de sécurité. Voici comment les configurer pour qu’elles mordent vraiment.

Ce qu’est (et n’est pas) une Quality Gate

Une Quality Gate est un ensemble de conditions booléennes : si toutes passent, le code peut avancer dans le pipeline ; si l’une échoue, le build s’arrête.

Ce n’est pas un simple rapport. Une Quality Gate mal configurée (trop laxiste) ou ignorée (le pipeline ne l’attend pas) ne protège rien. Les deux erreurs sont fréquentes.

Comprendre le périmètre : nouveau code vs code existant

SonarQube distingue deux périmètres d’analyse :

Le code existant — tout ce qui était dans le dépôt avant la date de référence (souvent le début du projet ou la dernière version majeure). Il peut avoir de la dette technique : c’est normal, on ne répare pas tout d’un coup.

Le nouveau code — uniquement ce qui a changé depuis la date de référence. C’est sur ce périmètre que les Quality Gates doivent être strictes.

Cette distinction est fondamentale : elle permet d’imposer des standards élevés sur le code qui s’écrit aujourd’hui sans bloquer l’équipe sur une dette historique impossible à résorber en une sprint.

Configurer une Quality Gate efficace

Dans SonarQube : Quality Gates → Créer → Ajouter des conditions.

Voici un profil raisonnable pour une équipe qui veut progresser sans se bloquer :

Conditions sur le NOUVEAU CODE uniquement :

Coverage              < 75%     → FAILED
Bugs                  > 0       → FAILED   (Rating < A)
Vulnerabilities       > 0       → FAILED   (Rating < A)
Security Hotspots     unreviewed > 0  → FAILED
Code Smells           > 5%      → WARNING  (Maintainability Rating < B)
Duplicated Lines      > 3%      → WARNING

La règle de base : zéro bug, zéro vulnérabilité sur le nouveau code. Sur les code smells et la duplication, une tolérance initiale est acceptable si l’équipe améliore progressivement.

Intégration dans GitLab CI : le paramètre qui change tout

sonarqube-check:
  stage: quality
  image:
    name: sonarsource/sonar-scanner-cli:latest
    entrypoint: [""]
  variables:
    SONAR_HOST_URL: $SONAR_HOST_URL
    SONAR_TOKEN: $SONAR_TOKEN
    GIT_DEPTH: 0    # important : historique complet pour le blame
  script:
    - sonar-scanner
        -Dsonar.projectKey=$CI_PROJECT_NAME
        -Dsonar.sources=src
        -Dsonar.python.coverage.reportPaths=coverage.xml
        -Dsonar.qualitygate.wait=true      # ← LE paramètre clé
        -Dsonar.qualitygate.timeout=300    # attendre 5 min max
  allow_failure: false    # echec bloquant
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

Sans qualitygate.wait=true, le scanner lance l’analyse et rend la main immédiatement — le pipeline passe vert même si SonarQube détecte des problèmes 30 secondes plus tard. Ce paramètre fait attendre le scanner jusqu’à ce que SonarQube ait rendu son verdict.

Intégration dans Jenkins

pipeline {
  agent any
  stages {
    stage('Tests') {
      steps {
        sh 'pytest tests/ --cov=src --cov-report=xml'
      }
    }
    stage('SonarQube Analysis') {
      steps {
        withSonarQubeEnv('SonarQube') {
          sh """
            sonar-scanner \
              -Dsonar.projectKey=myapp \
              -Dsonar.sources=src \
              -Dsonar.python.coverage.reportPaths=coverage.xml
          """
        }
      }
    }
    stage('Quality Gate') {
      steps {
        timeout(time: 5, unit: 'MINUTES') {
          waitForQualityGate abortPipeline: true
          // abortPipeline: true → arrête le pipeline si gate FAILED
        }
      }
    }
    stage('Deploy') {
      // Cette étape n'est atteinte que si la Quality Gate est verte
      steps { sh './deploy.sh' }
    }
  }
}

waitForQualityGate abortPipeline: true est l’équivalent Jenkins de qualitygate.wait=true. Sans abortPipeline: true, Jenkins affiche le statut mais ne bloque pas.

Décoration des merge requests

Configurez l’intégration GitLab dans Administration → ALM Integrations → GitLab. SonarQube postera automatiquement un commentaire sur chaque MR :

❌ Quality Gate: FAILED

Sur le nouveau code :
- 2 Bugs détectés (src/api/auth.py, src/db/session.py)
- 1 Vulnérabilité (SQL Injection potentielle, src/db/queries.py)
- Couverture: 61% (requis: 75%)

Voir l'analyse complète : https://sonar.example.com/dashboard?id=myapp

Le développeur voit le problème directement dans Bitbucket ou GitLab, avec le lien vers l’analyse détaillée.

Éviter les pièges courants

La gate trop permissive — une gate qui ne bloque jamais est inutile. Si elle passe toujours, c’est qu’elle ne mesure rien d’important.

La gate trop stricte — une gate qui bloque tout le temps génère de la frustration et se fait contourner (allow_failure: true dans le YAML). Commencez strict sur les vulnérabilités, plus souple sur la couverture.

Oublier GIT_DEPTH: 0 — SonarQube a besoin de l’historique Git complet pour calculer le périmètre « nouveau code ». Un clone shallow (défaut dans certains CI) fausse les résultats.

Ne pas différencier branches et PRs — appliquez des gates différentes : stricte sur les MRs (bloquant), informative sur les branches de feature (non bloquant mais visible).

Notre formation SonarQube couvre la configuration complète des Quality Gates et leur intégration dans Jenkins et GitLab CI, avec des cas pratiques sur des codebases réelles.