Module 1 — SonarQube : analyser la qualité et la sécurité du code

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 9 minutes

---

Ce que SonarQube analyse

SonarQube est un outil d’analyse statique : il lit le code source sans l’exécuter et détecte trois familles de problèmes — les bugs (des erreurs qui causeront un comportement incorrect), les code smells (du code qui fonctionne mais qui sera difficile à maintenir : trop complexe, dupliqué, mal nommé), et les vulnérabilités (des failles de sécurité potentielles, comme un algorithme de chiffrement faible). C’est un complément direct à Trivy (module précédent) : Trivy scanne les dépendances et l’image finale, SonarQube scanne le code que vous écrivez vous-même.

Le fichier analysé, volontairement imparfait

calculs.py

import hashlib

DB_PASSWORD = "SuperSecret123"

def calculer_remise(prix, categorie, est_membre, quantite, saison, code_promo):
    if categorie == "electronique":
        if est_membre:
            if quantite > 10:
                if saison == "soldes":
                    remise = 0.30
                else:
                    remise = 0.20
            else:
                if saison == "soldes":
                    remise = 0.15
                else:
                    remise = 0.10
        else:
            remise = 0.05
    else:
        remise = 0.02
    return prix * (1 - remise)

def hash_mot_de_passe(mot_de_passe):
    return hashlib.md5(mot_de_passe.encode()).hexdigest()

def calculer_total(prix, categorie, est_membre, quantite, saison, code_promo):
    inutilise = 42
    return calculer_remise(prix, categorie, est_membre, quantite, saison, code_promo) * quantite

25 lignes de code, plusieurs défauts glissés intentionnellement, pour vérifier ce que SonarQube détecte réellement — pas ce qu’on s’attend à ce qu’il détecte.

Le scan, réellement exécuté

$ docker run --rm sonarqube:community &          # serveur SonarQube réel, local
$ docker run --rm --network host \
    -v "$(pwd):/usr/src" -w /usr/src \
    sonarsource/sonar-scanner-cli:latest \
    -Dsonar.host.url=http://localhost:9000 -Dsonar.token=...

...
23:30:56.104 INFO  ANALYSIS SUCCESSFUL, you can find the results at:
                    http://localhost:9000/dashboard?id=devops-course-demo
23:30:56.275 INFO  EXECUTION SUCCESS

Les 4 problèmes réellement détectés

$ curl -s "http://localhost:9000/api/issues/search?componentKeys=devops-course-demo" -u admin:admin

python:S1172   MAJOR      line=6    Remove the unused function parameter "code_promo".
python:S3776   CRITICAL   line=6    Refactor this function to reduce its Cognitive
                                     Complexity from 19 to the 15 allowed.
python:S4790   CRITICAL   line=27   Make sure that hashing data is safe here.
python:S1481   MINOR      line=31   Remove the unused local variable "inutilise".

• S1172 (paramètre inutilisé) : code_promo est déclaré dans calculer_remise mais n’est jamais lu dans le corps de la fonction — souvent le signe d’une fonctionnalité commencée puis abandonnée, ou d’un paramètre qui devrait être branché mais ne l’est pas.
• S3776 (complexité cognitive : 19, sur un seuil de 15) : ce nombre n’est pas arbitraire — SonarQube compte réellement chaque structure de contrôle imbriquée (if dans un if dans un if…) avec un poids croissant selon la profondeur d’imbrication. calculer_remise a 4 niveaux de if imbriqués : chaque niveau supplémentaire rend la fonction plus difficile à tester exhaustivement (le nombre de chemins d’exécution possibles croît de façon exponentielle avec la profondeur, pas linéairement).
• S4790 (hachage non sûr) : hashlib.md5() est signalé comme une opération de hachage non sûre pour un usage sensible (mots de passe, jetons) — MD5 est cryptographiquement cassé depuis des années (collisions calculables en quelques secondes) ; pour un vrai stockage de mot de passe, il faudrait un algorithme conçu pour ça (bcrypt, scrypt, argon2 — volontairement lents pour ralentir les attaques par force brute), jamais un simple hash générique comme MD5 ou même SHA-256 seul.
• S1481 (variable inutilisée) : inutilise = 42 n’est jamais lue — sans conséquence fonctionnelle ici, mais un signal de code mort qui s’accumule avec le temps si personne ne le nettoie.

Ce qui n’a pas été détecté — et pourquoi c’est important de le savoir

DB_PASSWORD = "SuperSecret123" (un mot de passe en dur dans le code source) n’apparaît dans aucun des 4 problèmes remontés par cette analyse, avec l’édition Community de SonarQube et son jeu de règles par défaut. Ce n’est pas parce que le problème n’existe pas — un secret en dur dans le code source, versionné dans Git, reste un vrai risque (n’importe qui avec accès au dépôt le voit, y compris dans l’historique après suppression). C’est une limite réelle et honnête de l’outil et de sa configuration par défaut : la détection de secrets nécessite soit des règles supplémentaires, soit un outil dédié (comme gitleaks ou truffleHog, spécialisés dans la détection de secrets dans un historique Git entier). La leçon à en tirer : aucun outil d’analyse statique ne couvre 100 % des risques — un scan « propre » signifie « rien détecté par les règles actives », jamais « le code est prouvé sûr ».

Le tableau de bord global

$ curl -s "http://localhost:9000/api/qualitygates/project_status?projectKey=devops-course-demo"
{"projectStatus": {"status": "OK"}}

$ curl -s ".../api/measures/component?...&metricKeys=code_smells,cognitive_complexity,ncloc,sqale_index"
code_smells: 3
cognitive_complexity: 19
ncloc: 25          (lignes de code effectives)
sqale_index: 19    (dette technique estimée, en minutes)

Un détail réel qui mérite d’être expliqué plutôt que caché : le statut du quality gate affiche OK, malgré les 4 problèmes détectés — parce que le quality gate par défaut de SonarQube (« Sonar way ») évalue des conditions sur le nouveau code introduit (pensé pour un projet avec un historique d’analyses), pas sur le volume total de problèmes d’un premier scan complet. C’est volontaire : SonarQube est conçu pour empêcher la dette technique de s’aggraver à partir de maintenant, plus que pour bloquer un projet existant qui en a déjà accumulé — un principe pragmatique (« clean as you code ») plutôt qu’un objectif de zéro-défaut immédiat, souvent hors de portée sur une base de code réelle.

Prochaine étape

Module 2 : Trivy — scanner les vulnérabilités d’une image Docker