Sommaire
Un audit de sécurité examine le code, la configuration, les accès et les données d’une application pour repérer les failles et les classer par priorité, en s’appuyant sur des référentiels comme l’OWASP Top 10. Je propose un audit express à 589€HT en quelques jours et un audit complet à 1 990€HT en 5 à 7 jours.
Votre application gère des clients, des commandes, des données de salariés. Elle a été développée vite, ou par un prestataire qui n’est plus là, ou avec un outil d’IA. Un client important vous demande des garanties de sécurité. Dans tous ces cas, un audit permet de savoir où vous en êtes avant qu’un incident ne le révèle. Voici ce qu’il vérifie, comment il se déroule, ce qu’il coûte et ce qu’il ne remplace pas.
Les deux formules
L’audit de sécurité fait partie de mon audit technique, qui couvre aussi l’architecture, la performance et la base de données. Montants hors taxes :
| Audit express | Audit complet | |
|---|---|---|
| Prix | 589€HT | 1 990€HT |
| Durée | Quelques jours | 5 à 7 jours |
| Périmètre | Audit technique et analyse de performance, avec les points de sécurité prioritaires | Six domaines : architecture et code, performance, sécurité, SEO et accessibilité, base de données, mobile et PWA |
| Livrable | Rapport et plan d’optimisation personnalisé | Rapport détaillé, plan d’action priorisé et chiffré |
| Après l’audit | Restitution de 2 heures, 30 jours de support | |
| Pour qui | Savoir rapidement où vous en êtes | Décider d’une reprise, d’une refonte ou d’un plan de correction |
Ce qui est vérifié
Je m’appuie sur le Top 10 de l’OWASP, le référentiel de référence des risques de sécurité des applications web, dans sa version 2025 (consultée le 27 octobre 2026). Concrètement, pour une application métier, l’audit de sécurité porte sur :
- Le contrôle d’accès (A01) : chaque rôle ne voit-il que ce qu’il doit voir ? Les droits sont-ils vérifiés côté serveur et dans la base ? C’est le premier point de l’OWASP et celui que je teste le plus longuement, compte par compte (voir gérer les droits d’accès par rôle).
- La configuration (A02) : mode débogage laissé actif, en-têtes de sécurité, comptes par défaut, stockage de fichiers ouvert au public.
- Les dépendances (A03) : bibliothèques obsolètes ou présentant des vulnérabilités connues, origine des paquets installés.
- Le chiffrement et les secrets (A04) : clés d’API dans le code ou dans le navigateur, mots de passe stockés correctement, échanges chiffrés.
- Les injections (A05) : requêtes construites à partir de saisies utilisateur sans protection.
- L’authentification (A07) : robustesse des mots de passe, limitation des tentatives, double authentification, réinitialisation du mot de passe.
- La journalisation (A09) : les actions sensibles laissent-elles une trace exploitable en cas d’incident ?
- La gestion des erreurs (A10) : les messages d’erreur révèlent-ils des informations techniques ?
S’y ajoutent les sauvegardes et la conformité RGPD de base : données collectées, durées de conservation, sous-traitants. La liste détaillée des failles courantes est dans les failles les plus fréquentes dans les applications de PME.
Comment se déroule l’audit complet
| Étape | Durée | Contenu |
|---|---|---|
| Analyse initiale | 1 à 2 jours | Collecte des informations techniques et des accès |
| Audit approfondi | 3 à 5 jours | Tests automatisés, analyse manuelle du code, essais avec chaque rôle |
| Recommandations | 1 à 2 jours | Plan d’action priorisé, chiffré, avec feuille de route |
| Restitution | 2 heures | Présentation des résultats à vos équipes |
L’audit se fait en lecture seule ou sur une copie. Les points sont classés par gravité : à corriger immédiatement, à planifier, à surveiller.
Quand faire un audit
- Avant une mise en production, surtout si l’application stocke des données personnelles ou financières.
- Avant de reprendre une application développée par un autre prestataire, en no-code ou avec un outil d’IA (voir projet commencé avec l’IA).
- Quand un client ou un donneur d’ordre demande des garanties de sécurité.
- Après un incident, pour comprendre ce qui s’est passé et éviter qu’il se reproduise.
- Périodiquement, pour une application qui évolue beaucoup.
Ce qu’un audit ne remplace pas
Je le dis franchement : mon audit est un audit de code et de configuration, réalisé par un développeur. Il ne remplace pas :
- un test d’intrusion qualifié, quand un contrat ou une réglementation l’exige. L’ANSSI qualifie des prestataires d’audit de la sécurité des systèmes d’information (PASSI), qui couvrent notamment les tests d’intrusion, les audits de code et de configuration ;
- un audit de l’ensemble de votre système d’information : postes de travail, réseau, messagerie, sensibilisation des équipes ;
- un avis juridique sur votre conformité RGPD.
Si votre besoin relève de l’un de ces cas, je vous le dis dès l’appel de découverte et l’audit applicatif peut alors préparer le travail du prestataire qualifié.
Par où commencer
- Un appel de 30 minutes pour décrire l’application et votre objectif : je vous dis quelle formule convient.
- L’envoi des accès : code, hébergement, comptes de test.
- L’audit, puis le rapport.
- Les corrections, avec l’équipe de votre choix. Si l’application doit être reprise ou passée en production, la page mettre en production un prototype interne en toute sécurité détaille les étapes.
Le contenu des deux formules est rappelé dans le tableau en haut de cette page. Si l’audit conclut qu’une refonte est préférable, l’estimateur donne une première fourchette.
Questions fréquentes
Quelle différence entre un audit et un test d’intrusion ?
L’audit que je réalise examine l’application de l’intérieur : code, configuration, droits, dépendances, base de données. Un test d’intrusion simule une attaque de l’extérieur, souvent sans accès au code. Les deux se complètent. Pour un test d’intrusion exigé par un client ou une réglementation, l’ANSSI qualifie des prestataires d’audit (PASSI).
De quels accès avez-vous besoin ?
Du code source, d’un accès en lecture à la configuration de l’hébergement et de la base de données et d’un compte de test par rôle utilisateur. L’audit se fait sur une copie ou en lecture seule : aucune modification n’est apportée à votre production.
Que se passe-t-il après l’audit ?
Vous recevez un rapport avec les points relevés, classés par gravité et un plan d’action chiffré pour l’audit complet. Vous pouvez corriger avec votre équipe, votre prestataire actuel ou avec moi. L’audit complet inclut une restitution de 2 heures et 30 jours de support pour répondre à vos questions.
Un audit garantit-il qu’il n’y a plus aucune faille ?
Non. Aucun audit ne peut le garantir. Il réduit fortement le risque en traitant les failles les plus probables et les plus graves, à un instant donné. La sécurité se maintient ensuite : mises à jour, revues de droits, contrôle des nouvelles fonctions.
Mon application a été créée avec un outil d’IA : l’audit est-il adapté ?
Oui, c’est même l’un des cas où il est le plus utile. Les applications générées rapidement fonctionnent souvent bien en démonstration, mais présentent des lacunes sur les droits d’accès et la gestion des clés. L’audit est la première étape avant toute reprise.