Module 4Mettre en œuvre des outils de gestion de versions et de mesure de la qualité du code
Chapitre 8 sur 11
Métriques, complexité cyclomatique, bugs, vulnérabilités, code smells, notes A à E, dette technique, porte qualité et installation.
Objectifs
Avec ce chapitre, tu sauras…
Leçon 1
Une partie de la qualité du code se mesure automatiquement par l'analyse statique : des outils lisent le code source sans l'exécuter et appliquent des règles (conventions, bonnes pratiques, erreurs connues). D'autres critères demandent un jugement humain : l'architecture, la documentation, la portabilité, la pertinence des choix. La norme ISO/IEC 25010 décrit les caractéristiques de qualité d'un logiciel (fiabilité, sécurité, maintenabilité, performance, compatibilité, portabilité…).
Leçon 2
| Métrique | Ce qu'elle mesure | Interprétation |
|---|---|---|
| lignes de code (LOC) | la taille du code (sans les lignes vides ni les commentaires) | sert surtout à comparer et à rapporter les autres mesures |
| nombre de méthodes par classe | la taille des classes | une classe avec 60 méthodes fait probablement trop de choses |
| couplage afférent (Ca) | le nombre de classes qui dépendent de cette classe | élevé : la classe est très utilisée, la modifier est risqué |
| couplage efférent (Ce) | le nombre de classes dont dépend cette classe | élevé : la classe est fragile, sensible aux changements des autres |
| instabilité I = Ce / (Ca + Ce) | entre 0 (stable : beaucoup l'utilisent, elle dépend de peu) et 1 (instable) | les classes stables devraient être abstraites (interfaces) |
| complexité cyclomatique | le nombre de chemins indépendants dans une fonction | élevée : difficile à tester et à comprendre ; au-delà de 10 par fonction, on découpe |
| complexité cognitive | l'effort de compréhension pour un humain (pénalise l'imbrication) | plus proche du ressenti du lecteur |
| duplication | le pourcentage de code copié-collé | une correction devra être faite à plusieurs endroits |
| couverture de tests | le pourcentage de code exécuté par les tests automatisés | faible : beaucoup de code jamais vérifié |
| densité de commentaires | lignes de commentaires / (lignes de code + lignes de commentaires) | ni trop peu, ni trop (un code clair a besoin de peu de commentaires) |
| Outil | Langages, usage |
|---|---|
| SonarQube | plus de 30 langages ; tableau de bord, historique, porte qualité (ce chapitre) |
| PHPStan, Psalm | analyse statique du PHP (types, erreurs probables) |
| ESLint | JavaScript et TypeScript |
| PMD, SpotBugs (successeur de FindBugs), Checkstyle | Java |
| Codacy, CodeScene, Code Climate | services en ligne d'analyse de code |
| Veracode, Checkmarx, PVS-Studio | analyse orientée sécurité ou haute fiabilité (souvent payants) |
Leçon 3
| Offre | Pour qui ? |
|---|---|
| SonarQube Community Build | gratuite et open source, à installer soi-même : idéale pour apprendre et pour les petites équipes |
| SonarQube Server (éditions Developer, Enterprise, Data Center) | payantes, avec l'analyse des branches et des merge requests, plus de langages et de règles de sécurité |
| SonarQube Cloud (anciennement SonarCloud) | service en ligne, gratuit pour les projets publics |
| SonarQube for IDE (anciennement SonarLint) | extension gratuite pour VS Code, JetBrains, Eclipse, Visual Studio : signale les problèmes pendant que tu codes, comme un correcteur orthographique |
Leçon 4
| Type | Définition | Qualité impactée | Exemple |
|---|---|---|---|
| bug | une erreur évidente ou très probable, qui provoquera un mauvais comportement | fiabilité | une variable utilisée sans être initialisée, une condition toujours vraie |
| vulnérabilité | une faiblesse exploitable par un attaquant | sécurité | une requête SQL construite par concaténation (module M108) |
| point chaud de sécurité (security hotspot) |
Leçon 5
kitab et nom « Kitab » → branche principale main.sonar-project.properties (ci-dessous).1L'analyse statique…
2Une fonction avec deux if et une boucle while a une complexité cyclomatique de…
3Un problème qui rend le code difficile à maintenir sans provoquer d'erreur est…
4Une requête SQL construite par concaténation est…
5Avec un ratio de dette technique de 15 %, la note de maintenabilité est…
6La porte qualité Sonar way exige sur le nouveau code une couverture d'au moins…
7L'extension qui analyse le code dans l'éditeur s'appelle aujourd'hui…
8Un test interrompu par une exception inattendue est…
L'essentiel du chapitre
sonarqube:community, port 9000, admin/admin), sonar-project.properties, SonarScanner ; analyse automatique dans la CI.| Composant | Rôle |
|---|---|
| SonarScanner | le programme qui analyse le code (sur le poste ou dans le pipeline) et envoie un rapport au serveur |
| serveur SonarQube | un serveur web (consultation des résultats), un moteur de calcul (traite les rapports) et un moteur de recherche (Elasticsearch, intégré) |
| base de données | stocke la configuration et l'historique des analyses (PostgreSQL en production ; la base intégrée ne sert qu'aux essais) |
| un code sensible à revoir par un humain : ce n'est pas forcément une faille |
| sécurité |
| l'utilisation d'un cookie, d'une expression régulière, d'un mot de passe |
| code smell (« mauvaise odeur ») | un défaut de conception ou de style, qui ne provoque pas d'erreur mais rend le code difficile à maintenir | maintenabilité | code dupliqué, fonction trop longue ou trop complexe, variable inutilisée, commentaire de code mort |
| Note | Fiabilité | Sécurité | Maintenabilité (ratio de dette technique) |
|---|---|---|---|
| A | 0 bug | 0 vulnérabilité | ≤ 5 % |
| B | au moins 1 bug mineur | au moins 1 vulnérabilité mineure | de 6 à 10 % |
| C | au moins 1 bug majeur | au moins 1 vulnérabilité majeure | de 11 à 20 % |
| D | au moins 1 bug critique | au moins 1 vulnérabilité critique | de 21 à 50 % |
| E | au moins 1 bug bloquant | au moins 1 vulnérabilité bloquante | plus de 50 % |
| Mesure | Calcul |
|---|---|
| densité de commentaires | lignes de commentaires / (lignes de code + lignes de commentaires) × 100 ; 50 % = autant de commentaires que de code |
| duplication | lignes dupliquées / lignes totales × 100 ; un bloc est considéré comme dupliqué à partir d'environ 100 éléments de code (tokens) successifs identiques répartis sur au moins 10 lignes (pour PHP et JavaScript) |
| couverture | (CT + CF + LC) / (2 × B + EL), où CT et CF sont les conditions évaluées au moins une fois à vrai et à faux, LC les lignes couvertes, B le nombre total de conditions, EL le nombre de lignes exécutables |
| tests | nombre de tests, erreurs (un test interrompu par une exception inattendue), échecs (un test dont une assertion est fausse), lignes et conditions non couvertes |
| complexité | totale, par fonction, par fichier, par classe ; complexité cognitive |
Vidéo · À regarder
FR[Sonar] Partie 3 : Test d'un projet avec Sonar et présentation de l'interface de résultats
YouTube (FR) · YouTube
Classe chaque problème : (1) une méthode de 180 lignes ; (2) echo $_GET['nom']; ; (3) une condition if ($x = 5) au lieu de == ; (4) le même bloc de 25 lignes dans trois contrôleurs ; (5) un mot de passe de base de données écrit dans le code ; (6) une variable $resultat déclarée et jamais utilisée ; (7) une division par une variable qui peut valoir zéro.
Calculer la complexité cyclomatique
Pour une fonction : complexité = nombre de points de décision + 1. Un point de décision est chaque if, elseif, case, for, foreach, while, catch, opérateur ternaire ? :, et chaque opérateur logique && ou || dans une condition. Une fonction sans aucune décision a une complexité de 1.
<?php
function fraisLivraison(string $ville, float $poidsKg, float $montant): float
{
if ($montant >= 300) { // décision 1
return 0.0;
}
$frais = in_array($ville, ['Rabat', 'Fès'], true) ? 20.0 : 35.0; // décision 2 (ternaire)
if ($poidsKg > 2) { // décision 3
$frais += 10 * ceil($poidsKg - 2);
}
return $frais;
}
// complexité cyclomatique = 3 + 1 = 4 : il faut au moins 4 cas de test pour couvrir tous les cheminsLe résumé ajoute throw et return (« sauf en dernière instruction ») aux éléments qui augmentent la complexité : c'était la règle des anciennes versions de SonarQube. La définition classique de McCabe, appliquée aujourd'hui, ne compte que les décisions (conditions, boucles, catch, ternaires, opérateurs && et ||). Les deux méthodes donnent des valeurs proches ; ce qui compte, c'est l'ordre de grandeur.
Tableau: Les outils d'analyse
SonarQube (de l'éditeur suisse SonarSource) est une plateforme d'inspection continue de la qualité du code. Elle analyse le code source de plus de trente langages (PHP, JavaScript, TypeScript, Java, C#, Python, C/C++…), détecte les problèmes de fiabilité, de sécurité et de maintenabilité, mesure la couverture de tests, la duplication et la complexité, estime la dette technique, et conserve l'historique des analyses.
Tableau: Les types de problèmes
La méthode la plus simple est Docker (module M201, chapitre 10).
docker run -d --name sonarqube -p 9000:9000 sonarqube:community
# puis ouvrir http://localhost:9000 (premier démarrage : une à deux minutes)
# identifiants initiaux : admin / admin → SonarQube oblige à changer le mot de passeLe résumé fait télécharger le JDK d'Oracle puis modifier à la main le fichier wrapper.conf pour indiquer le chemin de Java, et lancer StartSonar.bat. L'installation à partir de l'archive ZIP reste possible (elle demande Java 17 ou 21), mais l'image Docker officielle évite ces réglages. Sous Linux, SonarQube demande aussi d'augmenter des paramètres du système (vm.max_map_count) à cause de son moteur de recherche intégré.
Analyser le projet Kitab
Installe SonarQube avec Docker, crée le projet kitab, écris le fichier sonar-project.properties et lance l'analyse de ton code Kitab (ou d'un projet PHP du M107). Installe SonarQube for IDE dans VS Code. Relève les notes et les cinq problèmes les plus graves, corrige-les, relance l'analyse et compare les deux tableaux de bord dans ton rapport.
Calcule la complexité cyclomatique de cette fonction et donne le nombre minimal de cas de test pour couvrir tous les chemins :
function remise(float $total, bool $fidele, string $code): float
{
$taux = 0;
if ($total > 500 && $fidele) {
$taux = 0.10;
} elseif ($code === 'RENTREE') {
$taux = 0.05;
}
foreach ([100, 200] as $palier) {
if ($total > $palier) {
$taux += 0.01;
}
}
return $total * (1 - $taux);
}L'analyse de Kitab donne : 0 bug ; 2 vulnérabilités dont une critique ; 145 code smells ; dette technique de 3 jours (24 heures de 8 h, soit 1 440 minutes) ; 12 000 lignes de code ; couverture 42 % ; duplication 6,5 %. (1) Donne la note de fiabilité, de sécurité et de maintenabilité (30 minutes par ligne). (2) Sur le nouveau code, la couverture est de 85 % et la duplication de 1 % ; il n'y a aucun nouveau problème mais un point chaud non revu : la porte Sonar way passe-t-elle ? (3) Par quoi commences-tu ?
L'architecture
poste du développeur serveur d'intégration continue serveur SonarQube
┌────────────────────┐ ┌──────────────────────────────┐ ┌──────────────────────────┐
│ IDE + SonarQube │ push │ pipeline (GitLab CI, Jenkins) │ rapport│ serveur web (interface) │
│ for IDE (analyse │──────► │ └─► SonarScanner analyse │──────► │ moteur de calcul │
│ en direct) │ Git │ le code │ │ moteur de recherche │
└────────────────────┘ └──────────────────────────────┘ │ │ │
│ base de données │
│ (PostgreSQL) │
└──────────────────────────┘Les scanners n'ont pas besoin d'être sur le même réseau que le serveur et ne communiquent jamais directement avec la base de données ; une installation n'a qu'un serveur et une base.
Le cycle d'analyse dans une équipe
L'intégration de SonarQube dans le cycle de vie
Chaque problème a une gravité (de bloquant à mineur ou informatif), une explication de la règle, un exemple de correction et une estimation du temps de correction. Les versions récentes de SonarQube classent les problèmes directement par qualité logicielle (sécurité, fiabilité, maintenabilité) avec les gravités Blocker, High, Medium, Low et Info.
Tableau: Les notes de A à E
Tableau: Les autres mesures
La porte qualité
Ce que tu vas voir (vidéo courte, entièrement sur ce sujet) : l'analyse d'un projet avec Sonar puis la présentation de l'interface des résultats : bugs, vulnérabilités, code smells, couverture et duplications. Ce sont les métriques et l'interface de résultats de cette section.
sonar.projectKey=kitab
sonar.projectName=Kitab
sonar.sources=app,resources/js
sonar.tests=tests
sonar.exclusions=vendor/**,node_modules/**,public/build/**
sonar.php.coverage.reportPaths=coverage.xml
sonar.sourceEncoding=UTF-8docker run --rm --network host \
-e SONAR_HOST_URL="http://localhost:9000" \
-e SONAR_TOKEN="le_jeton_copié" \
-v "$(pwd):/usr/src" \
sonarsource/sonar-scanner-cliLe chapitre 10 montre comment lancer cette même analyse automatiquement à chaque push, dans le pipeline GitLab.