Ce qu'est un audit de code source
L'audit de code source, ou revue de code sécurité, consiste à lire le code d'une application pour identifier les failles qu'il contient : entrées non validées, contrôles d'accès absents, cryptographie mal employée, secrets stockés en clair, logique métier contournable. L'auditeur travaille sur le dépôt de code, les fichiers de configuration et les dépendances, pas sur l'application déployée.
C'est ce qui le distingue d'un pentest en boîte blanche. Dans ce dernier, le pentester reçoit aussi le code, mais il s'en sert pour orienter ses attaques sur l'application en fonctionnement et démontrer l'exploitation. L'audit de code, lui, peut signaler un défaut sans le démontrer : un algorithme de hachage obsolète, une vérification de signature incomplète, une fonction d'export sans contrôle de rôle. Ces constats sont réels même quand aucun scénario d'exploitation n'est immédiatement disponible.
La revue manuelle se distingue enfin de l'analyse statique automatisée, appelée SAST. Un outil SAST parcourt le code à la recherche de motifs dangereux et produit une liste d'alertes. Il est rapide et répétable, mais il ne comprend ni le métier ni l'architecture. Les trois approches ne trouvent pas les mêmes choses.
SAST, revue manuelle, pentest boîte blanche : comparatif
| Critère | SAST automatisé | Audit de code manuel | Pentest boîte blanche |
|---|---|---|---|
| Ce qui est trouvé | Motifs connus : injection par concaténation, fonctions dangereuses, secrets en clair, dépendances vulnérables. | Défauts de conception, contrôles d’accès manquants, logique métier contournable, cryptographie mal utilisée, chemins de code morts mais accessibles. | Failles exploitables sur l’application en fonctionnement : IDOR, élévation de privilèges, injection, erreurs de configuration et d’hébergement. |
| Faux positifs | Nombreux. Chaque alerte doit être qualifiée par un développeur, ce qui coûte souvent plus que l’outil. | Rares. Chaque constat est lu dans son contexte, mais il n’est pas toujours démontré exploitable. | Quasi nuls. Chaque finding s’accompagne d’une preuve d’exploitation reproductible. |
| Ce qui échappe | Tout ce qui demande de comprendre le métier : droits, flux financiers, isolation entre clients. | Ce qui n’est pas dans le code : configuration de production, services exposés, dépendances d’hébergement. | Les chemins jamais déclenchés pendant les tests, et les défauts de conception invisibles de l’extérieur. |
| Coût indicatif | Licence de quelques centaines à quelques milliers d’euros par an, plus le temps de tri. | 3 à 10 jours de revue manuelle, soit 2 400 à 12 000 € HT au TJM du marché. | 5 à 20 jours selon le périmètre, soit 3 000 à 15 000 € HT pour une PME. |
Les fourchettes de prix du pentest sont celles du marché français, détaillées dans notre guide sur le prix d'un pentest. Le SAST reste utile : placé dans l'intégration continue, il empêche le retour des défauts déjà corrigés. Il ne constitue pas un audit.
Quand préférer l'audit de code, quand préférer le pentest
L'audit de code source est le bon choix quand :
- le code porte une logique métier sensible que l'on ne peut pas tester de l'extérieur en quelques jours : moteur de calcul financier, règles d'attribution de droits, isolation entre clients d'une plateforme multi-tenant ;
- l'application fait de la cryptographie elle-même : signature, chiffrement de données, génération de jetons. Les erreurs y sont invisibles en boîte noire et catastrophiques en production ;
- le code traite un paiement ou des données de carte, et qu'une exigence contractuelle ou PCI DSS demande une revue avant mise en production ;
- un contrat ou une due diligence l'exige, par exemple avant une levée de fonds, une acquisition ou un référencement chez un grand compte qui demande une preuve sur le code et pas seulement sur l'application.
Le pentest est le bon choix, et souvent le premier, quand :
- l'application n'a jamais été testée : on cherche d'abord ce qu'un attaquant obtient réellement ;
- le risque porte sur la configuration, l'hébergement ou les services exposés, que le code ne décrit pas ;
- un client ou un assureur attend un rapport de test d'intrusion, document qu'un audit de code ne remplace pas ;
- le budget ne permet qu'une mission : le pentest couvre plus de surface par jour investi.
Méthode : les six étapes d'un audit de code
- 1
Cadrage du périmètre de code
On liste les dépôts, les branches et les modules à lire, et surtout ceux que l’on exclut. Un audit qui prétend couvrir tout le code d’une entreprise en cinq jours n’en couvre aucun correctement.
- 2
Cartographie des points d’entrée
Routes HTTP, endpoints d’API, tâches planifiées, consommateurs de files de messages, webhooks entrants. Chaque point d’entrée est une porte par laquelle une donnée non maîtrisée peut arriver.
- 3
Suivi des flux de données
Depuis chaque entrée, l’auditeur suit la donnée jusqu’à sa destination : requête en base, appel système, fichier écrit, réponse renvoyée. C’est là que se voient les validations absentes et les encodages oubliés.
- 4
Revue des fonctions sensibles
Authentification, gestion de session, autorisation par rôle et par tenant, cryptographie, upload et génération de fichiers, paiement, export de données. Ces fonctions sont lues ligne par ligne, pas survolées.
- 5
Confirmation dynamique des constats
Un constat de lecture est vérifié sur un environnement de test dès que c’est possible. Un défaut démontré exploitable change de priorité pour l’équipe de développement.
- 6
Rapport et restitution
Chaque constat est localisé dans le code, noté, expliqué et accompagné d’un correctif proposé. La restitution se fait avec les développeurs, qui sont les seuls à pouvoir corriger.
La cinquième étape est celle qui sépare un audit utile d'une liste de remarques : quand un constat de lecture est confirmé par une exploitation, même limitée, il cesse d'être discutable. C'est aussi la raison pour laquelle l'audit de code et le pentest boîte blanche sont souvent menés par la même personne, dans la même mission.
Ce que doit contenir le rapport d'audit de code
Un rapport d'audit de code s'adresse d'abord aux développeurs. Il doit leur permettre de corriger sans avoir à refaire l'analyse. Pour chaque constat, exigez :
- la localisation exacte : dépôt, fichier, ligne ou fonction, et la version ou le commit audité ;
- la sévérité, exprimée avec un score CVSS et son vecteur, pour prioriser sans débat ;
- la preuve ou le scénario : exploitation démontrée quand elle existe, sinon l'enchaînement qui rend le défaut atteignable ;
- le correctif proposé, avec un extrait de code ou une référence de bibliothèque, pas un simple « valider les entrées » ;
- le périmètre lu et le périmètre exclu, pour qu'un lecteur sache ce que le rapport ne dit pas.
Export CSV sans contrôle du tenant
Élevée · CVSS 8.1- Localisation
src/api/exports/csv.ts:142commit 3f9c1e2, branche main- Vecteur
- AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
- Preuve
- La route lit
organisationIddepuis la requête sans le comparer à la session. Confirmé sur l'environnement de test : un compte standard de l'organisation A obtient l'export complet de l'organisation B. - Correctif
- const orgId = req.query.organisationId + const orgId = session.organisationId const rows = await exports.findMany({ where: { organisationId: orgId } })Ajouter un test d'intégration qui tente l'export croisé et attend un 403.
La synthèse pour la direction et la structure générale sont les mêmes que pour un rapport de test d'intrusion. Notre exemple de rapport de pentest montre le niveau de détail attendu pour chaque finding.
Prix d'un audit de code source en 2026
Comme un pentest, un audit de code se chiffre en jours multipliés par un tarif journalier. Le TJM observé sur le marché français pour une revue de code sécurité va de 800 à 1 200 € HT : la lecture de code demande un profil qui sait à la fois développer et attaquer, plus rare qu'un pentester généraliste. Les fourchettes ci-dessous sont des ordres de grandeur de marché, pas une grille Laucked.
| Taille | Périmètre type | Durée | Budget indicatif | Repère visuel sur une échelle de 0 à 12 000 € HT |
|---|---|---|---|---|
| Petite base de code | Une application ou un service, moins de 20 000 lignes, un ou deux langages | 3 à 4 jours | 2 400 à 4 800 € HT | |
| Base de code moyenne | Monolithe et API, 20 000 à 100 000 lignes, plusieurs rôles utilisateurs | 5 à 8 jours | 4 000 à 9 600 € HT | |
| Grande base de code, revue ciblée | Plusieurs services, revue limitée aux modules sensibles : authentification, paiement, export | 8 à 10 jours | 6 400 à 12 000 € HT |
Deux facteurs font sortir de ces fourchettes : un code sans tests ni documentation, qui oblige l'auditeur à reconstituer l'architecture avant de lire, et un périmètre flou, qui se traduit par des jours de revue dispersés. Un devis sérieux nomme les dépôts et les modules couverts. Laucked chiffre toute mission sur devis, après un cadrage gratuit ; notre page devis pentest liste ce qu'un chiffrage doit préciser, et le guide des prix donne les fourchettes du test d'intrusion pour comparer.
Combiner audit de code et pentest boîte blanche
Sur une application critique, la combinaison la plus efficace consiste à lire le code des fonctions sensibles puis à attaquer l'application avec ce que la lecture a révélé. La revue repère les chemins fragiles qu'un test en boîte noire aurait mis des jours à trouver ; l'exploitation prouve lesquels sont réellement atteignables et avec quel impact. Le rapport unique qui en résulte parle aux deux publics : la direction lit l'impact démontré, les développeurs lisent la ligne à corriger.
Concrètement, pour une application SaaS de taille moyenne, cela représente deux à trois jours de lecture ciblée sur l'authentification, les autorisations et les exports, intégrés à une mission de pentest boîte grise de six à huit jours. Le surcoût est limité, et c'est souvent là que se trouvent les constats les plus sérieux : une vérification de tenant oubliée dans une seule route, un jeton signé avec une clé partagée, une fonction d'administration accessible par une URL non référencée.
Questions fréquentes sur l'audit de code source
Audit de code ou pentest : par quoi commencer ?
Par le pentest, dans la grande majorité des cas. Il mesure ce qu'un attaquant obtient réellement sur l'application en fonctionnement et couvre aussi la configuration, l'hébergement et les dépendances. L'audit de code vient ensuite, sur les modules dont le pentest ne peut pas garantir la couverture : cryptographie, paiement, logique métier complexe.
Combien de temps dure un audit de code source ?
De 3 à 10 jours pour une revue manuelle ciblée. La durée dépend du volume de code à lire, du nombre de points d'entrée et du périmètre convenu. Au-delà, on parle d'une revue d'architecture étalée sur plusieurs semaines, rarement justifiée pour une PME.
Quels langages peuvent être audités ?
Tous les langages courants du web et du back-end : JavaScript et TypeScript, Python, PHP, Java et Kotlin, C#, Go, Ruby. Ce qui compte n'est pas le langage mais la capacité de l'auditeur à suivre un flux de données depuis une entrée utilisateur jusqu'à une fonction sensible, quel que soit le framework.
Un outil SAST suffit-il ?
Non. Un outil d'analyse statique trouve des motifs connus (requête SQL concaténée, fonction dangereuse, secret en clair) et produit beaucoup de faux positifs. Il ne comprend ni la logique métier ni les contrôles d'accès. Il est utile en intégration continue, pour éviter les régressions, mais il ne remplace pas la lecture par un humain.
L'audit de code est-il obligatoire ?
Rarement. PCI DSS v4.0 demande une revue du code développé en interne avant sa mise en production pour les composants qui traitent des données de carte, à confirmer avec votre évaluateur. En dehors de ce cas, l'obligation vient plutôt d'un contrat client, d'une due diligence ou d'une exigence d'hébergement de données de santé. NIS2 et DORA exigent des tests de sécurité, sans imposer la revue de code.
Faut-il auditer le code généré par une IA ?
Oui, avec la même méthode que le reste. Le code produit par un assistant reproduit souvent des exemples publics peu sûrs : validation d'entrée absente, gestion d'erreur qui expose des détails, dépendances inutiles. Si l'application embarque elle-même un modèle ou un agent, la revue doit aussi couvrir les prompts et les outils exposés, ce qui relève d'un audit IA.
Pour le code qui embarque un modèle ou un agent, voir notre page audit de sécurité IA.
Références : OWASP Code Review Guide ; OWASP Application Security Verification Standard (ASVS).