Analyse statique vs dynamique
L'analyse statique lit le code ; l'analyse dynamique l'exécute. Un analyseur statique parse un fichier en arbre syntaxique abstrait (AST) et vérifie cette structure contre des règles — pas de serveur, pas de données de test, pas d'environnement d'exécution requis, ce qui lui permet de tourner en quelques secondes sur un codebase qui n'a jamais été déployé. L'analyse dynamique (tests, fuzzers, scanners DAST) observe le comportement runtime réel — ce qu'une fonction retourne pour une entrée donnée, comment un serveur en marche répond à une requête forgée — ce que l'analyse statique ne peut pas voir par définition, puisque rien ne s'exécute. Aucune ne remplace l'autre ; elles répondent à des questions différentes.
Ce que l'analyse statique vérifie réellement — au-delà de la sécurité
La sécurité domine le marketing, mais l'analyse statique est une technique générale pour vérifier n'importe quelle propriété structurelle du code. Les 708 règles de StaticCodeAudit couvrent ces catégories :
Sécurité
Injection SQL, XSS, SSRF, traversée de chemin, secrets en dur, désérialisation non sécurisée, cryptographie faible, injection de commande, injection LDAP, cookies non sécurisés, patterns de conformité RGPD.
Architecture
Protection des routes admin, logique base de données embarquée dans les routeurs, requêtes directes non paramétrées, patterns de requêtes N+1, fichiers surdimensionnés.
Interface / UI
Styles inline, usage manuel de createElement, fuites d'event listeners, manipulation du DOM dans des boucles.
Accessibilité / UX
Labels ARIA manquants, texte alternatif manquant, gestion du focus, mauvais usage de l'autoplay, problèmes i18n, patterns toast/notification, appels console.log résiduels.
Maintenance
Marqueurs TODO/FIXME/HACK/XXX non résolus, API dépréciées, gestion d'exception fourre-tout, instructions de debug, suppresseurs d'erreur.
Dépendances
Scan des CVE connues sur les paquets installés (équivalents pip-audit, npm audit), plages de versions non épinglées, conformité de licence.
CI/CD
Mauvaise configuration GitHub Actions et GitLab CI, injection d'expression, permissions de workflow excessives, actions tierces non épinglées.
Comment les findings se mappent aux standards publiés
Un finding sans référence à un standard n'est qu'une opinion. StaticCodeAudit tague chaque règle avec au minimum un identifiant CWE (la taxonomie de faiblesses de MITRE) ou un critère de succès WCAG 2.1, et superpose les mappings OWASP Top 10, ISO/IEC 27001 Annexe A, OWASP ASVS v5.0 et NIST CSF 2.0 quand pertinent — pour qu'un finding soit traçable à une référence externe et auditable plutôt qu'à un label de sévérité inventé par l'éditeur.
Voir la couverture complète des standards →Questions fréquentes
L'analyse statique de code, est-ce la même chose que le SAST ?
Le SAST (Static Application Security Testing) est de l'analyse statique cantonnée spécifiquement aux vulnérabilités de sécurité. L'analyse statique de code est la technique plus large — le même mécanisme de parsing et de correspondance aux règles s'applique à l'architecture, l'accessibilité, la maintenabilité et les vérifications de dépendances, pas seulement aux vulnérabilités exploitables. Voir le guide SAST dédié pour le cas d'usage spécifique à la sécurité.
L'analyse statique peut-elle détecter des bugs qui n'apparaissent qu'au runtime ?
Pas directement — tout ce qui dépend des valeurs d'entrée réelles, du timing, ou de l'état de l'environnement au runtime est hors de ce que l'analyse statique peut observer par définition. L'analyse de taint réduit cet écart en traçant comment des données non fiables pourraient circuler dans le code sans l'exécuter, mais c'est de l'inférence, pas de l'observation. C'est le rôle des tests dynamiques.
Pourquoi StaticCodeAudit couvre-t-il l'UI et l'accessibilité, pas seulement la sécurité ?
Parce que la technique sous-jacente — parser le code, vérifier la structure contre des règles — s'applique aussi bien à un label ARIA manquant ou un style inline qu'à un pattern d'injection SQL. L'accessibilité a spécifiquement un poids réglementaire croissant (l'European Accessibility Act 2025, par exemple), c'est pourquoi le mapping WCAG 2.1 est intégré aux côtés du mapping CWE plutôt que d'être un produit séparé.
Comment l'analyse statique évite-t-elle les faux positifs ?
Elle ne les évite pas entièrement — aucun analyseur statique ne le fait, puisqu'il raisonne sur la structure du code sans contexte runtime complet. Ce qui varie énormément entre outils, c'est le taux de faux positifs, qui dépend de la conception des règles (les règles purement pattern sont plus bruyantes que celles avec taint tracking) et de la prudence avec laquelle une règle est scopée. Demandez un benchmark publié et reproductible plutôt qu'un chiffre auto-déclaré par l'éditeur — voir les vrais benchmarks précision/recall.
L'analyse statique a-t-elle besoin que le code compile ?
Ça dépend de l'outil. Certains moteurs exigent un build complet pour construire une base interrogeable (courant pour l'analyse sémantique profonde des langages compilés). StaticCodeAudit non — il parse les fichiers source directement sans étape de build, pour n'importe lequel de ses 8 langages supportés, y compris les compilés comme Java et C#.
Voyez à quoi ressemble une analyse statique full-spectrum
Ouvrez le rapport démo en direct — findings sécurité, architecture, UI, accessibilité, maintenance, dépendances et CI/CD, tous dans un seul fichier HTML.
Ouvrir le rapport en direct Voir le mapping aux standards