Votre application tourne depuis des mois, voire des années. Personne n'a jamais vérifié si elle était vulnérable. Pas de test de pénétration, pas d'audit de code, pas de revue des configurations serveur. C'est la situation de la majorité des PME françaises.
Un audit de sécurité applicatif n'est pas un luxe réservé aux grands comptes. C'est un investissement qui coûte infiniment moins cher qu'une compromission. Encore faut-il savoir quand le faire, comment le mener et quoi en attendre.
Quand réaliser un audit de sécurité ?
Les moments clés
Certains moments du cycle de vie d'une application appellent naturellement un audit :
- Avant une mise en production — valider que l'application est prête à affronter le trafic réel et les tentatives d'attaque
- Après un changement majeur — nouvelle fonctionnalité critique (paiement, authentification), migration d'infrastructure, changement de framework
- Périodiquement — une fois par an minimum. Les vulnérabilités apparaissent en continu, même sans modification de votre code
- Après un incident — pour comprendre ce qui s'est passé, colmater les failles et empêcher une récidive
- Avant une levée de fonds ou un audit client — de plus en plus de partenaires et d'investisseurs exigent un rapport de sécurité
Les signaux d'alerte
Certains symptômes doivent déclencher un audit d'urgence :
- Hausse inexpliquée du trafic ou de la charge serveur
- Emails envoyés depuis votre domaine que vous n'avez pas initiés
- Fichiers modifiés sans intervention connue
- Comptes utilisateurs créés sans inscription légitime
- Dépendances avec des CVE critiques non corrigées
Les différents types d'audit
Audit de code (revue statique)
L'audit de code analyse le code source pour identifier les failles potentielles : injections SQL, XSS, gestion des secrets, logique d'authentification.
C'est le type d'audit le plus approfondi car il examine la logique applicative en détail. Il nécessite un accès au code source et une expertise dans les technologies utilisées.
- Durée : 2 à 5 jours selon la taille de l'application
- Livrable : rapport avec les failles identifiées, leur criticité et les correctifs recommandés
- Idéal pour : les applications métier critiques, avant une mise en production majeure
Test de pénétration (pentest)
Le pentest simule une attaque réelle contre votre application en production. L'auditeur tente d'exploiter les failles comme le ferait un attaquant, mais de manière contrôlée et documentée.
- Boîte noire — l'auditeur ne connaît rien de l'application, comme un attaquant externe
- Boîte grise — l'auditeur a un accès utilisateur standard (le plus courant et le plus réaliste)
- Boîte blanche — l'auditeur a accès au code source et à l'infrastructure (le plus complet)
Audit de configuration
L'audit de configuration vérifie les réglages de votre serveur, de votre base de données, de votre reverse proxy et de vos services tiers :
- Headers HTTP de sécurité
- Configuration TLS (versions, cipher suites)
- Permissions fichiers et répertoires
- Ports ouverts et services exposés
- Configuration du firewall
Comment se déroule un audit ?
Ce que doit contenir un bon rapport d'audit
Un rapport d'audit utile n'est pas une liste de CVE générée par un scanner automatique. Il doit contenir :
- Un résumé exécutif — compréhensible par un non-technicien, avec le niveau de risque global
- Le détail de chaque vulnérabilité — description, preuve d'exploitation, impact potentiel, criticité (CVSS)
- Des recommandations concrètes — pas « améliorer la sécurité », mais « ajouter un rate limiter de 5 tentatives par minute sur /api/login »
- Une priorisation — quoi corriger en premier, quoi peut attendre, quoi est un risque accepté
Après l'audit : le plan de remédiation
Un audit sans correction est un audit inutile. Le rapport doit déboucher sur un plan d'action concret :
- Correctifs critiques sous 48h — les failles exploitables immédiatement ne peuvent pas attendre le prochain sprint
- Correctifs hauts sous 2 semaines — failles sérieuses mais nécessitant un contexte d'exploitation
- Correctifs moyens/bas dans le backlog — intégrés dans le cycle de développement normal
- Re-test — valider que les correctifs sont effectifs et n'ont pas introduit de nouvelles failles
Combien coûte un audit de sécurité ?
Le coût dépend du périmètre, du type d'audit et de la taille de l'application. Pour une application web de taille moyenne (PME) :
- Audit de configuration : 1 à 2 jours
- Pentest boîte grise : 3 à 5 jours
- Audit de code complet : 3 à 10 jours
C'est un investissement modeste comparé au coût moyen d'une violation de données pour une PME (estimé à plusieurs dizaines de milliers d'euros en coûts directs et indirects).
L'audit technique que je propose inclut systématiquement un volet sécurité proportionné à la criticité de votre application.