🛡️ SonarQube : l'analyse statique qui garde ton code propre

📚 Introduction

La relecture de code attrape beaucoup de choses, mais pas tout. Un bug subtil, une injection SQL oubliée, une méthode de 300 lignes que personne n’ose toucher, une couverture de tests qui s’effrite commit après commit : à l’échelle d’un projet vivant, ça passe entre les mailles. L’analyse statique automatise cette vigilance — elle lit le code sans l’exécuter et remonte ce qui cloche.

SonarQube, édité par la société Sonar, est la référence du domaine. Il scanne le code, classe les problèmes (bugs, vulnérabilités, code smells), mesure la couverture et la duplication, et surtout : il sait dire « non » quand du nouveau code dégrade la qualité. On va voir comment le lancer, ce qu’est un quality gate, et comment le brancher dans une CI.

🔎 Sonar, SonarQube, SonarQube Cloud : qui est qui ?

Le nommage a changé fin 2024, autant le clarifier :

• Sonar — l’entreprise éditrice.
• SonarQube Server — la plateforme auto-hébergée (éditions payantes Developer, Enterprise, Data Center).
• SonarQube Community Build — la version gratuite et open source (LGPL-3.0), auto-hébergée, qui s’appelait « Community Edition » jusqu’à fin 2024. C’est celle du homelab.
• SonarQube Cloud — la version SaaS, anciennement SonarCloud.
• SonarQube for IDE — l’extension d’éditeur, ex-SonarLint, qui remonte les problèmes pendant que tu codes.

🚀 Lancer SonarQube Community Build

Une commande Docker suffit pour un serveur local. Le port par défaut est le 9000 :

docker run -d --name sonarqube -p 9000:9000 sonarqube:community

L’interface s’ouvre sur http://localhost:9000 (identifiants par défaut admin / admin, à changer immédiatement). On crée ensuite un projet, on génère un token, et on lance l’analyse depuis le dépôt avec le scanner officiel :

docker run --rm \
  -e SONAR_HOST_URL="http://localhost:9000" \
  -e SONAR_TOKEN="<ton-token>" \
  -v "$(pwd):/usr/src" \
  sonarsource/sonar-scanner-cli

Un petit fichier sonar-project.properties à la racine décrit le projet :

sonar.projectKey=mon-app
sonar.sources=src

🎯 Le quality gate et le « Clean as You Code »

C’est la fonctionnalité qui change tout. Plutôt que de te noyer sous des milliers d’avertissements sur du code legacy, SonarQube applique le principe Clean as You Code : il concentre l’exigence sur le code nouveau ou modifié. Ta dette existante ne disparaît pas, mais elle ne t’empêche pas d’avancer — et le code que tu écris aujourd’hui, lui, doit être propre.

Le quality gate matérialise cette exigence : un ensemble de conditions sur le nouveau code (zéro nouveau bug, zéro vulnérabilité, couverture minimale, duplication maîtrisée). S’il passe au vert, tu merges. S’il passe au rouge, quelque chose s’est dégradé. Les métriques suivies sont classiques mais complètes : bugs, vulnérabilités, security hotspots, code smells, couverture de tests et duplication.

🧰 L’intégrer dans la CI

Tout l’intérêt est là : l’analyse tourne à chaque push, et le quality gate peut faire échouer le pipeline. Avec GitLab CI, un job suffit :

sonarqube:
  image: sonarsource/sonar-scanner-cli:latest
  variables:
    SONAR_HOST_URL: '$SONAR_HOST_URL'
    SONAR_TOKEN: '$SONAR_TOKEN'
  script:
    - sonar-scanner

Le principe est le même avec GitHub Actions. En amont, une bonne suite de tests — Pest côté PHP, par exemple — produit le rapport de couverture que SonarQube consomme pour vérifier que le nouveau code est bien testé.

⚠️ Quelques précautions

• Ne vise pas le « zéro problème » sur tout le legacy. C’est décourageant et sans fin. Le quality gate sur le nouveau code (Clean as You Code) est la bonne stratégie : la qualité monte à mesure que tu touches le code.
• Les faux positifs existent. Une règle inadaptée à ton contexte se désactive ou s’ajuste dans le quality profile, plutôt que de la subir ou d’ignorer tous les avertissements.
• La version Community Build a ses limites. Elle n’analyse pas les branches ni les pull requests séparément — c’est réservé aux éditions payantes. Pour un projet perso, on scanne la branche principale ; en équipe, l’analyse de PR justifie souvent l’édition Developer ou SonarQube Cloud.
• Ça consomme des ressources. SonarQube embarque une base de données et un moteur de recherche : prévois de la RAM sur ton serveur.

🎉 Conclusion

SonarQube, c’est un garde-fou automatique sur la qualité : il voit ce que la relecture laisse passer, et le quality gate transforme « on devrait nettoyer ça un jour » en une règle qui bloque la merge aujourd’hui. Commence simple — un docker run, un scan de ta branche principale, le quality gate par défaut — puis branche-le dans ta CI. Le code que tu écris à partir de maintenant restera propre, sans grand ménage héroïque.

🔗 Liens utiles

• SonarQube — édition Community open source
• SonarQube Community Build — documentation
• Image Docker SonarQube (Docker Hub)
• SonarQube Community Build sur GitHub