Introduction & Fondamentaux¶

Comprendre les outils de qualité de code et leur rôle dans le cycle de développement.

Pourquoi la qualité de code¶

La qualité de code n'est pas un luxe ni une tâche "quand on aura le temps". C'est un investissement qui se rembourse des les premières semaines d'un projet.

La dette technique¶

Chaque raccourci pris aujourd'hui — un # TODO jamais traite, une validation manquante, un test saute — augmente le coût de maintenance futur. La dette technique fonctionne comme une dette financiere : elle accumule des intérêts. Plus vous attendez pour la rembourser, plus le coût explose.

Un code sans standards :

• est plus long a comprendre pour un nouveau développeur
• généré plus de bugs lors des évolutions
• rend le refactoring risque et coûteux

Le coût des bugs¶

Un bug détecté à l'écriture du code coute quelques minutes a corriger. Le même bug decouvert en production coute 10 a 100 fois plus cher :

La sécurité supply chain¶

Vos dépendances sont un vecteur d'attaque. Votre code peut être parfait, mais si une de vos librairies contient une faille, votre application est vulnerable.

Exemples concrets :

• Log4Shell (CVE-2021-44228) : une faille critique dans Log4j, une librairie de logging Java utilisée par des millions d'applications. Un simple message de log pouvait exécuter du code arbitraire à distance.
• event-stream (2018) : un mainteneur npm a cede la maintenance de son package a un inconnu, qui a injecte du code malveillant ciblant un portefeuille Bitcoin. Le package comptait 2 millions de téléchargements hebdomadaires.

Taxonomie des outils¶

Tous les outils de qualité ne font pas la même chose. Il est essentiel de comprendre les différentes catégories pour savoir quoi utiliser et quand.

graph TB
    subgraph "Votre code"
        A["Formatters<br/>Style automatique"]
        B["Linters<br/>Bugs & mauvaises pratiques"]
        C["SAST<br/>Failles de securite"]
    end
    subgraph "Code des autres"
        D["SCA<br/>CVE dans les dependances"]
    end
    subgraph "Environnement"
        E["Scan d'images<br/>Vulnerabilites OS & systeme"]
    end

Formatters — mise en forme automatique¶

Les formatters ne s'occupent que du style : indentation, guillemets, longueur de ligne, virgules finales. Ils ne detectent aucun bug et ne changent jamais le comportement du code.

Leur intérêt principal : éliminer les debats de style dans les revues de code. Si le formatter est configuré, la discussion est close.

Exemples : Prettier (JS/TS/CSS/HTML), Black (Python), gofmt (Go).

Linters — détection de bugs et mauvaises pratiques¶

Les linters analysent le code source pour détecter :

• des bugs potentiels (variable non utilisée, comparaison toujours fausse)
• des mauvaises pratiques (code mort, complexité excessive, imports inutiles)
• des problèmes de qualité (absence de typage, fonctions trop longues)

Contrairement aux formatters, les linters peuvent signaler des problèmes qui changent le comportement du code.

Exemples : ESLint (JS/TS), Ruff (Python), clippy (Rust).

SAST — vulnérabilités dans le code source¶

Le SAST (Static Application Security Testing) recherche des failles de sécurité directement dans votre code source :

• Injections SQL
• Cross-Site Scripting (XSS)
• Secrets commites (clés API, mots de passe)
• Deserialisation non sécurisée

Le SAST fonctionne sans exécuter le code : il analyse les fichiers source à la recherche de patterns dangereux.

Exemples : Semgrep, SonarQube (module sécurité), Bandit (Python).

SCA — vulnérabilités dans les dépendances¶

Le SCA (Software Composition Analysis) ne regarde pas votre code mais celui de vos dépendances. Il compare les versions de vos packages a des bases de données de CVE (Common Vulnerabilities and Exposures) connues.

Un projet typique a des centaines de dépendances transitives. Le SCA les analyse toutes.

Exemples : pip-audit (Python), npm audit (Node.js), Trivy filesystem (multi-langage).

Scan d'images — vulnérabilités dans les conteneurs¶

Le scan d'images analyse les couches OS et système de vos images conteneur. Il détecté :

• les packages système avec des CVE connues (openssl, glibc, curl...)
• les configurations dangereuses (exécution en root, ports exposes)
• les images basées sur des distributions obsolètes

C'est la dernière ligne de defense avant le déploiement.

Exemples : Trivy image, Grype, Docker Scout.

Quand intervient chaque outil¶

Chaque outil a sa place dans le cycle de développement. L'objectif est de détecter les problèmes le plus tôt possible (shift-left).

graph LR
    A["Ecriture"] -->|"Formatter + Linter"| B["Commit"]
    B -->|"Pre-commit hooks"| C["Push"]
    C -->|"SonarQube + SAST + SCA"| D["Build"]
    D -->|"Scan image"| E["Deploy"]

À l'écriture¶

Le formatter et le linter tournent en temps réel dans votre éditeur (VSCode, Neovim...). Chaque sauvegarde de fichier déclenche un formatage automatique et une analyse instantanée. Les erreurs apparaissent directement dans l'éditeur.

Au commit — pre-commit hooks¶

Avant chaque commit, des hooks Git exécutent automatiquement le formatter et le linter sur les fichiers modifies. Si une erreur est détectée, le commit est bloque. Cela garantit qu'aucun code non conforme n'entre dans l'historique Git.

Au push — analyse approfondie¶

Le push vers Gitea déclenche le pipeline CI qui exécuté les analyses plus lourdes :

• SonarQube : analyse de qualité complète, quality gates, métriques de couverture
• SAST (Semgrep) : détection de failles de sécurité dans le code source
• SCA (pip-audit, npm audit, Trivy) : scan des dépendances pour les CVE connues

Au build — scan d'image¶

Après la construction de l'image conteneur, Trivy scanne toutes les couches pour détecter les vulnérabilités système. Si des CVE critiques sont trouvees, le pipeline échoué et le déploiement est bloque.

Stack retenue¶

Pre-requis¶

Avant de commencer ce tutoriel, assurez-vous d'avoir les outils suivants installes :