Fondamentaux de l'analyse de qualité¶
L'analyse de qualité du code recouvre un ensemble de techniques automatisees qui evaluent le code source selon plusieurs axes : fiabilité, sécurité, maintenabilité, couverture de tests et conformite aux standards.
Types d'analyse¶
SAST (Static Application Security Testing)¶
L'analyse statique de sécurité examine le code source sans l'exécuter pour détecter les vulnerabilites connues.
| Aspect | Detail |
|---|---|
| Méthode | Pattern matching, analyse de flux de données, taint analysis |
| Cibles | Injections SQL, XSS, path traversal, deserialization, SSRF |
| Standards | OWASP Top 10, CWE Top 25, SANS Top 25 |
| Moment | À chaque commit, dans le pipeline CI |
| Outils | Semgrep, SonarQube (rules Security), CodeQL |
SAST vs DAST
Le SAST analyse le code source (white-box). Le DAST (Dynamic Application Security Testing) teste l'application en cours d'execution (black-box). Les deux sont complementaires mais cette rubrique couvre uniquement le SAST, qui s'integre dans la chaîne logicielle.
Analyse de complexité¶
La complexité cyclomatique mesure le nombre de chemins d'execution dans une fonction. Une complexité elevee indique un code difficile a tester et a maintenir.
| Complexité cyclomatique | Interpretation | Action recommandee |
|---|---|---|
| 1 - 10 | Simple, facile a tester | Aucune |
| 11 - 20 | Moderement complexe | Refactoring souhaitable |
| 21 - 50 | Complexe | Refactoring nécessaire |
| > 50 | Tres complexe, non testable | Refactoring obligatoire |
Detection de duplication¶
Le code duplique augmente la dette technique : une correction doit etre appliquee a N endroits au lieu d'un seul.
- Duplication exacte : blocs de code identiques (copy-paste)
- Duplication structurelle : blocs de code avec la même structure mais des noms différents
- Seuil recommande : moins de 3% de duplication globale
Couverture de code (coverage)¶
La couverture mesure le pourcentage de lignes exécutées par les tests automatises.
| Metrique | Description | Seuil recommande |
|---|---|---|
| Line coverage | Lignes exécutées / lignes totales | >= 80% |
| Branch coverage | Branches exécutées / branches totales | >= 70% |
| Condition coverage | Conditions evaluees / conditions totales | >= 70% |
La couverture ne garantit pas la qualité des tests
Un code couvert a 100% avec des tests sans assertions n'a aucune valeur. La couverture est un indicateur nécessaire mais pas suffisant. Elle doit etre combinée avec des tests significatifs (mutation testing pour aller plus loin).
Analyse des dependances¶
L'analyse des dependances verifie les bibliotheques tierces utilisees par le projet.
| Axe | Vérification |
|---|---|
| Vulnerabilites connues | CVE dans les dependances (National Vulnerability Database) |
| Licences | Compatibilité avec la politique de licences de l'organisation |
| Obsolescence | Dependances en fin de vie ou non maintenues |
| Versions | Ecart entre la version utilisee et la dernière version stable |
Linting et conformite de style¶
Les linters verifient le respect des conventions de codage (indentation, nommage, imports, etc.). Ce type d'analyse est généralement gère côté développeur (pre-commit hooks, IDE), mais SonarQube peut aussi le centraliser.
Quality gate¶
Un quality gate est un ensemble de conditions que le code doit respecter pour etre considere comme acceptable. C'est le mécanisme central de contrôle qualité dans le pipeline CI/CD.
Fonctionnement¶
graph LR
Dev["Developpeur"] --> Push --> CI["CI Pipeline"] --> Scan["Scan SonarQube"] --> Gate{"Evaluation<br/>Quality Gate"}
Gate -->|PASSED| Merge["PR mergeable<br/>Merge autorise"]
Gate -->|FAILED| Block["PR bloquee<br/>Correction requise"]Conditions recommandees¶
| Condition | Seuil | Justification |
|---|---|---|
| Couverture sur nouveau code | >= 80% | Pas de régression de couverture |
| Duplication sur nouveau code | < 3% | Eviter l'accumulation de dette |
| Bugs critiques/bloquants | 0 | Pas de nouveau bug critique |
| Vulnerabilites critiques/bloquantes | 0 | Pas de nouvelle faille de sécurité |
| Security hotspots revus | 100% | Tous les points d'attention examines |
| Ratio de dette technique | < 5% | Maintenabilité du nouveau code |
Quality gate sur le nouveau code
La stratégie recommandee est le Clean as You Code : appliquer le quality gate uniquement sur le nouveau code (depuis la dernière version ou la branche cible). Cela evite de bloquer les équipes sur du code legacy tout en garantissant que chaque ajout respecte les standards.
Quality profiles¶
Un quality profile est un ensemble de regles d'analyse activees pour un langage donne. Chaque projet est associe a un quality profile par langage.
Organisation des profils¶
| Profil | Usage | Regles |
|---|---|---|
| Sonar way | Profil par defaut (built-in) | Ensemble équilibre de regles |
| Organisation | Profil standard de l'organisation | Sonar way + regles custom |
| Strict | Projets critiques (sécurité, infra) | Organisation + regles OWASP |
| Legacy | Projets legacy en cours de migration | Sous-ensemble de regles |
Heritage de profils¶
graph TD
Sonar["Sonar way (built-in)"]
Sonar --> Org["Organisation<br/>(extends Sonar way)"]
Org --> Strict["Strict<br/>(extends Organisation)"]
Org --> Legacy["Legacy<br/>(subset de Organisation)"]Ne jamais modifier Sonar way
Le profil built-in est mis a jour à chaque version de SonarQube. Créer un profil enfant qui herite de Sonar way et y ajouter les regles spécifiques a l'organisation.
Dette technique¶
La dette technique représente le coût de remédiation de tous les problèmes détectés dans le code. SonarQube la mesure en temps (jours, heures) nécessaire pour corriger l'ensemble des issues.
Types de dette¶
| Type | Exemples | Impact |
|---|---|---|
| Fiabilité | Null pointer dereference, resource leak | Bugs en production |
| Sécurité | SQL injection, hardcoded credentials | Failles exploitables |
| Maintenabilité | Complexité, duplication, code mort | Coût de maintenance eleve |
Mesure de la dette¶
Dette technique = Somme(temps_remediation_par_issue)
Ratio de dette = dette_technique / temps_developpement_estime
Rating A : ratio < 5%
Rating B : ratio 6-10%
Rating C : ratio 11-20%
Rating D : ratio 21-50%
Rating E : ratio > 50%
Standards de sécurité¶
OWASP Top 10¶
SonarQube mappe ses regles de sécurité sur le OWASP Top 10, le classement de référence des risques de sécurité applicative.
| OWASP | Catégorie | Regles SonarQube associees |
|---|---|---|
| A01:2021 | Broken Access Control | S5131, S5144, S5146 |
| A02:2021 | Cryptographic Failures | S2068, S2245, S4426 |
| A03:2021 | Injection | S2077, S2078, S2631 |
| A07:2021 | Identification & Authentication | S2068, S2647, S5344 |
| A09:2021 | Security Logging & Monitoring | S4507, S4792, S5145 |
CWE (Common Weakness Énumération)¶
Chaque regle de sécurité SonarQube est associee a un ou plusieurs identifiants CWE, permettant un mapping précis avec les bases de vulnerabilites nationales.
Regle SonarQube S2077 (SQL Injection)
→ CWE-89: Improper Neutralization of Special Elements in SQL Command
→ OWASP A03:2021: Injection
→ SANS Top 25: CWE-89
Système de notation¶
SonarQube utilise un système de notation de A (meilleur) a E (pire) sur trois axes :
| Axe | Rating A | Rating B | Rating C | Rating D | Rating E |
|---|---|---|---|---|---|
| Fiabilité | 0 bug | >= 1 mineur | >= 1 majeur | >= 1 critique | >= 1 bloquant |
| Sécurité | 0 vulnérabilité | >= 1 mineure | >= 1 majeure | >= 1 critique | >= 1 bloquante |
| Maintenabilité | Ratio dette < 5% | 6-10% | 11-20% | 21-50% | > 50% |
Metriques complementaires¶
| Metrique | Description |
|---|---|
| Lines of Code | Lignes de code (hors commentaires et lignes vides) |
| Cognitive Complexity | Difficulte de comprehension du code (plus fin que cyclomatique) |
| Security Hotspots | Points d'attention sécurité a revoir manuellement |
| Code Smells | Problèmes de maintenabilité (nommage, structure, design) |
Suivre les tendances, pas les valeurs absolues
Sur un projet legacy, le rating global peut etre mediocre. L'important est la tendance : le nouveau code doit etre en rating A sur les trois axes, et la dette globale doit diminuer dans le temps.