SonarQube : Quality Gates et clean code en pratique

Un SonarQube installé mais dont les Quality Gates passent toujours au vert est pire que pas de SonarQube. Voici comment le configurer pour qu’il serve vraiment de filet de sécurité.

Comprendre la logique Nouveau Code vs Code existant

SonarQube distingue deux périmètres : le code existant (legacy, potentiellement problématique) et le nouveau code (ce qui a changé depuis une date de référence ou une version). La stratégie officielle conseille de ne pas essayer de nettoyer tout le code existant d’un coup, mais de maintenir une qualité irréprochable sur tout nouveau code.

Concrètement, votre Quality Gate doit être stricte sur le nouveau code et tolérer (temporairement) la dette existante.

Configurer une Quality Gate saine

La Quality Gate par défaut de SonarQube (Sonar Way) est un bon point de départ, mais elle s’applique à tout le code. Créez une gate dédiée au nouveau code :

Conditions sur le nouveau code uniquement :
- Taux de couverture de tests < 80%    → FAILED
- Reliability Rating < A               → FAILED (A = zéro bug)
- Security Rating < A                  → FAILED (A = zéro vulnérabilité)
- Security Hotspots non revus > 0      → FAILED
- Maintainability Rating < A           → FAILED (A = ratio dette < 5%)

Ces conditions font que tout nouveau code qui introduit un bug, une vulnérabilité ou qui n’est pas couvert à 80% bloque le pipeline.

Intégration dans GitLab CI

sonarqube:
  image: sonarsource/sonar-scanner-cli:latest
  variables:
    SONAR_HOST_URL: "https://sonar.example.com"
    SONAR_TOKEN: $SONAR_TOKEN   # variable CI/CD, jamais en clair
  script:
    - sonar-scanner
      -Dsonar.projectKey=myapp
      -Dsonar.sources=src
      -Dsonar.python.coverage.reportPaths=coverage.xml
      -Dsonar.qualitygate.wait=true   # bloque le pipeline si la gate échoue
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Le paramètre qualitygate.wait=true est crucial : le scanner attend que SonarQube ait terminé l’analyse et retourne un code d’erreur si la Quality Gate échoue. Sans ça, le pipeline passe toujours vert même si Sonar détecte des problèmes.

Décorations sur les merge requests

Configurez l’intégration GitLab dans SonarQube (Administration → ALM Integrations → GitLab). SonarQube postera automatiquement un commentaire sur chaque merge request avec les nouveaux problèmes détectés :

SonarQube Quality Gate: FAILED

New issues:
- 2 Bugs in src/api/auth.py
- 1 Security Hotspot in src/db/queries.py (SQL Injection risk)
Coverage on new code: 62% (required: 80%)

Le développeur voit les problèmes sans quitter GitLab.

Mesurer la couverture correctement

SonarQube ne génère pas la couverture — il l’importe depuis votre outil de test. Pour Python avec pytest :

# Générer le rapport de couverture
pytest --cov=src --cov-report=xml:coverage.xml tests/

# Le rapport XML est ensuite importé par le scanner Sonar

Pour Java (Maven) :

<!-- pom.xml -->
<plugin>
  <groupId>org.jacoco</groupId>
  <artifactId>jacoco-maven-plugin</artifactId>
  <configuration>
    <destFile>${project.build.directory}/jacoco.exec</destFile>
  </configuration>
</plugin>

Sécurité : les OWASP Hotspots ne sont pas des bugs

SonarQube distingue les vulnérabilités (problèmes avérés) des Security Hotspots (code sensible à revoir manuellement). Ne les ignorez pas : ce sont des points d’entrée potentiels qui méritent une revue humaine.

Notre formation SonarQube couvre l’installation, la configuration des gates et l’intégration dans Jenkins et GitLab CI.