Selon le panorama de la cybermenace 2024 de l’ANSSI, les PME et ETI françaises concentrent désormais plus de la moitié des incidents traités par le CERT-FR. Le coût moyen d’un incident pour une PME française se situe entre 30 000 et 300 000 € selon les études (rançon, interruption d’activité, perte de données, communication de crise) — et ces chiffres ne couvrent pas le coût réputationnel.

Quand l’application impactée est une application métier sur mesure (et non un SaaS du marché), la responsabilité retombe directement sur l’éditeur ou l’entreprise qui l’a commandée. Pas de support éditeur à appeler, pas de SLA à invoquer : c’est vous, ou votre prestataire, qui devez tenir.

D’où l’importance d’auditer avant la production, pas après l’incident. Cet article fournit la checklist que nous utilisons en interne sur tous nos projets — et que vous pouvez réutiliser, adapter, faire passer à votre prestataire actuel pour challenger sa rigueur.

Quand faire l’audit sécurité ?

Trois moments-clés, dans cet ordre de priorité.

1. Avant la mise en production (obligatoire)

C’est le moment non-négociable. Aucune application métier qui touche à des données réelles ne devrait passer en production sans audit. Même si vous êtes une PME, même si le projet est petit, même si “on n’est pas une cible”. L’absence d’audit pré-prod, c’est l’équivalent de mettre une voiture neuve en circulation sans contrôle technique.

Pour les projets en environnement réglementé (santé, finance, ICPE, défense), l’audit pré-prod est de toute façon exigé contractuellement par le donneur d’ordre.

2. À chaque release majeure

Une release majeure, c’est : refonte d’un module critique, ajout d’une intégration externe (API tierce, SSO), changement de stack (montée de version framework, changement DB), ouverture à un nouveau public (extranet client, mobile). Toute modification qui change la surface d’attaque justifie un nouvel audit — généralement plus léger qu’un audit initial (5-10 j vs 15-25 j).

3. Après un incident (ou une alerte)

Si vous détectez une activité suspecte, si un employé signale un comportement bizarre, ou si un partenaire vous alerte sur une fuite : audit immédiat, sans attendre la confirmation. Mieux vaut un audit blanc qu’un incident confirmé une semaine trop tard.

Checklist OWASP Top 10 — version PME 2026

L’OWASP Top 10 reste la référence universelle. Voici la version 2021 (toujours en vigueur en 2026, prochaine révision OWASP attendue), avec pour chaque vuln un exemple métier concret et la manière de tester.

A01:2021 — Broken Access Control

Le risque le plus fréquent en application métier. Un utilisateur accède à des données ou des actions qui ne devraient pas lui être autorisées : URL manipulée, ID séquentiel deviné, rôle mal vérifié côté serveur.

Exemple métier : un commercial accède aux fiches de tous les clients en changeant /clients/127 en /clients/128. Ou un salarié récemment passé “lecture seule” peut toujours valider des bons de commande.

Comment tester : se connecter avec deux comptes (un standard, un à privilèges réduits) et tenter d’accéder aux ressources de l’autre. Tester systématiquement la manipulation d’identifiants dans les URL et les payloads.

A02:2021 — Cryptographic Failures

Données sensibles transmises ou stockées sans chiffrement, ou avec un chiffrement faible. Mots de passe en clair ou hashés en MD5/SHA1.

Exemple métier : un PDF de bulletin de paie envoyé en clair par email. Une base de données utilisateurs avec des mots de passe en SHA1 sans salt.

Comment tester : vérifier que TLS 1.3 est imposé (test SSL Labs : note A minimum), que les mots de passe sont hashés en bcrypt / argon2 / scrypt, que les exports sensibles sont chiffrés.

A03:2021 — Injection

SQL, XSS, command injection, LDAP, NoSQL. Toujours présent malgré 25 ans d’avertissements.

Exemple métier : un champ “recherche client” qui exécute du SQL parce que le développeur a concaténé la string. Un champ “commentaire” qui affiche du JavaScript chez tous les utilisateurs qui consultent la fiche.

Comment tester : utiliser OWASP ZAP ou Burp Suite pour fuzzer chaque champ d’entrée. Vérifier que tous les ORM utilisent du prepared statement, que toutes les sorties HTML passent par un échappement systématique (template engine sans bypass de l’auto-escape).

A04:2021 — Insecure Design

Faille dans la logique métier, pas dans le code. Un workflow qui permet de payer une commande deux fois, un panier négatif possible, un export qui ne vérifie pas le périmètre.

Exemple métier : un workflow d’audit terrain qui permet de “valider” un rapport sans avoir uploadé les photos de preuve. Un système de remboursement qui peut générer un avoir supérieur au montant initial.

Comment tester : threat modeling en amont (méthode STRIDE), revue manuelle des workflows critiques par une personne externe au projet, scénarios d’abus testés par un QA dédié.

A05:2021 — Security Misconfiguration

Headers HTTP manquants, pages d’erreur trop bavardes, services par défaut activés, panneau d’admin accessible en /admin sans IP whitelist.

Exemple métier : phpMyAdmin accessible depuis Internet en /phpmyadmin. Stacktrace Symfony complète affichée en prod. Bucket S3 public alors qu’il devrait être privé.

Comment tester : scanner avec Nikto, vérifier les headers avec securityheaders.com (objectif : note A), désactiver DEBUG / verbose error en production, restreindre les outils d’admin.

A06:2021 — Vulnerable and Outdated Components

Dépendances avec des CVE connues. Le risque qui grossit le plus vite : 80 % du code d’une app moderne vient de packages tiers.

Exemple métier : une app Node qui tourne avec un Lodash vieux de 4 ans, vulnérable à un prototype pollution. Un Symfony 4 toujours en prod alors que le 4.x est end-of-life depuis 2 ans.

Comment tester : npm audit / composer audit en CI bloquant. Snyk ou Dependabot activé sur le repo. Revue trimestrielle des dépendances obsolètes.

A07:2021 — Identification and Authentication Failures

Pas de rate limiting sur le login, pas de MFA, sessions trop longues, reset de mot de passe par email simple.

Exemple métier : un attaquant teste 10 000 mots de passe sur un compte admin sans être bloqué. Un cookie de session valide 30 jours sans renouvellement.

Comment tester : tenter du bruteforce sur le login (doit être bloqué après 5-10 tentatives), vérifier l’expiration des sessions (24h max idéalement), exiger MFA sur les comptes sensibles.

A08:2021 — Software and Data Integrity Failures

Pipeline CI/CD compromis, dépendances installées sans vérification de signature, mises à jour automatiques d’une source non vérifiée.

Exemple métier : un GitHub Actions qui pull une image Docker latest depuis un compte tiers sans pinning de hash. Un script d’install qui exécute curl | bash sur un domaine non vérifié.

Comment tester : pin de versions strictes (lockfile commité), signature des images Docker (cosign), revue des secrets dans les pipelines (pas de token long-lived).

A09:2021 — Security Logging and Monitoring Failures

Pas de logs, pas de centralisation, pas d’alerting. Un incident peut se dérouler pendant des semaines avant d’être détecté.

Exemple métier : un attaquant vole une base utilisateurs, exfiltre par lot pendant 3 semaines, et personne ne le voit parce qu’il n’y a pas de log d’export ni d’alerte sur volumétrie anormale.

Comment tester : vérifier que tous les événements sécurité (login échoué, changement permission, export massif) sont loggés avec contexte complet, centralisés (Loki, Graylog, ELK), et qu’au moins une alerte sur volumétrie suspecte est en place.

A10:2021 — Server-Side Request Forgery (SSRF)

L’application fait des requêtes HTTP vers des URL fournies par l’utilisateur, sans filtrer. L’attaquant peut accéder aux services internes (metadata cloud, API privée).

Exemple métier : un champ “URL d’avatar” qui télécharge l’image — l’attaquant met http://169.254.169.254/latest/meta-data/ et récupère les credentials AWS de la machine.

Comment tester : vérifier que toutes les URL externes appelées par le serveur passent par une whitelist ou une validation stricte (pas de range RFC 1918, pas de localhost, pas de metadata cloud).

Au-delà d’OWASP : 5 contrôles spécifiques app métier

L’OWASP Top 10 couvre les fondamentaux, mais une application métier a des risques spécifiques que le top 10 généraliste ne traite pas explicitement.

Audit trail RGPD-compatible

Vérifier que chaque action significative est journalisée avec : qui, quand, depuis où, quelle action, sur quoi, état avant, état après. Format immuable (append-only), conservation 6 ans minimum, exportable pour la CNIL en cas de contrôle.

Export de données (anti-fuite)

Tout export massif de données doit être journalisé, rate-limité (pas plus de N enregistrements par jour par utilisateur), filigrané dynamiquement (nom + timestamp en transparence sur les PDF) et idéalement alertant au-delà d’un seuil (notification au DPO ou au RSSI).

Sessions concurrentes

Une session par utilisateur, ou notification claire en cas de double connexion. Évite l’escalade silencieuse quand un compte est compromis. Sur les comptes admin : interdire les sessions multiples.

Rate limiting API

Toutes les API publiques doivent être rate-limitées (par IP + par token). Cible raisonnable : 60 req/min pour les endpoints standards, 5 req/min pour les endpoints sensibles (login, reset password, export). Sans rate limiting, pas de protection contre l’énumération ou le scraping.

Désactivation compte ex-employé

Process documenté + automatisé : quand un employé part, son compte est désactivé dans l’heure. Audit régulier (trimestriel) pour vérifier que la liste des comptes actifs correspond bien à la liste RH des employés présents. C’est un classique des audits ANSSI : la moitié des PME laissent traîner des comptes actifs d’ex-collaborateurs.

Pentest externe vs audit interne : quand investir ?

Soyons honnêtes. Un pentest externe sérieux par un cabinet PASSI (Prestataire d’Audit de la Sécurité des Systèmes d’Information, qualifié ANSSI) coûte 15 à 50 k€ pour une application de taille moyenne. C’est un investissement lourd pour une PME.

Quand le pentest externe est rentable :

  • Application en environnement réglementé (santé, ICPE, finance, défense) — souvent obligatoire
  • Enjeu financier > 50 k€ en cas de fuite (RGPD, perte client, rançon)
  • Vous vendez à de grands comptes qui exigent un rapport PASSI dans l’appel d’offres
  • Application qui manipule des paiements ou des données très sensibles
  • Mise en production critique avec donneur d’ordre exigeant

Quand un audit interne sérieux suffit :

  • MVP en bêta interne, données de test
  • Application interne, < 50 utilisateurs, données peu sensibles
  • Premier audit avant un pentest externe planifié 3-6 mois plus tard

L’audit interne sérieux n’est pas “le dev qui relit son propre code”. C’est : un développeur sénior externe au projet + outils d’analyse statique + scan dynamique + revue manuelle des workflows critiques. Compter 5 à 10 jours pour une app standard. Coût indicatif : 5-10 k€.

Outils 2026 : gratuits et payants

Voici la stack que nous utilisons et recommandons.

Gratuit / open-source

  • OWASP ZAP — scanner DAST (dynamic) automatique, gratuit, excellent pour un premier balayage
  • Burp Suite Community — proxy + outils manuels, version gratuite suffisante pour tests ponctuels
  • Semgrep — analyse statique (SAST) multi-langages, règles communautaires + custom, version gratuite généreuse
  • npm audit / composer audit / pip-audit — scan dépendances natif aux package managers
  • Trivy — scan vulnérabilités sur images Docker, IaC, dépendances
  • Nikto — scanner web vintage mais toujours utile pour misconfigs serveur
  • testssl.sh — test exhaustif de la configuration TLS

Payant (à partir de l’usage pro)

  • Burp Suite Pro — ~470 €/an, indispensable si vous faites du pentest sérieux
  • Snyk — scan dépendances + container + IaC + code, freemium puis ~25 €/dev/mois
  • Bearer — outil français, focus privacy / RGPD, scanne le code pour détecter le traitement de données personnelles
  • GitGuardian — détection de secrets dans les repos, freemium puis offre équipe

Outils ANSSI / officiels

  • Guide d’hygiène informatique de l’ANSSI — gratuit, 42 mesures de référence
  • Méthode EBIOS Risk Manager — pour le threat modeling structuré
  • Référentiel PASSI — pour comprendre ce qu’attend un audit qualifié

Cas concret : pentest Knuckles avant production

Sur le projet Knuckles pour Efectis (audit de 12 000 trémies coupe-feu sur centrales nucléaires EDF), un audit sécurité interne a été conduit en pré-production, complété par une revue indépendante avant la livraison au client final.

L’audit a couvert : authentification (SSO + MFA), gestion des permissions (rôles auditeur / superviseur / admin), audit trail complet, export de rapports normés, fonctionnement offline en zone contrôlée. Un focus particulier a été mis sur l’intégrité des données terrain : impossible de modifier un audit après validation, signature horodatée de chaque action, conservation immuable des photos de preuve.

Deux trouvailles mineures ont été remontées et corrigées avant mise en production : un endpoint d’export qui ne vérifiait pas finement le périmètre du superviseur, et un header X-Frame-Options manquant côté admin. Aucune trouvaille critique. La méthode complète (méthode A-N-C-R-E) et le contexte du projet sont détaillés dans l’étude de cas : Knuckles · Efectis : auditer 12 000 trémies en centrale nucléaire.

FAQ

Combien coûte un audit sécurité applicative ?

Trois ordres de grandeur. Audit interne sérieux par un dev sénior externe au projet : 5 à 10 k€ pour une app standard. Pentest externe non qualifié (cabinet sécu standard, sans label PASSI) : 8 à 25 k€. Pentest PASSI qualifié ANSSI : 15 à 50 k€, parfois plus pour applications complexes ou critiques (santé, finance, défense).

Faut-il refaire l’audit chaque année ?

Oui, idéalement. Audit complet annuel + scan automatisé continu (Snyk, Dependabot, Semgrep en CI). En cas de release majeure (refonte module critique, ajout intégration), un audit ciblé entre les audits annuels est recommandé. Coût d’un audit annuel “léger” sur app stable : 3 à 8 k€.

Quelle différence entre audit, pentest et red team ?

  • Audit : revue méthodique de la sécurité (code, infra, process), souvent en boîte blanche (avec accès au code), produit un rapport exhaustif
  • Pentest : tentative d’intrusion ciblée, souvent en boîte noire ou grise, focus sur l’exploitation réelle de vulns
  • Red team : exercice offensif réaliste sur plusieurs semaines, simule un attaquant réel motivé, teste aussi la détection par votre équipe (SOC, blue team)

Pour une PME : audit + pentest suffisent. Le red team est pertinent pour les grandes ETI ou organisations matures (>500 personnes, équipe sécu interne).

L’audit couvre-t-il l’infra (serveur) ou juste le code ?

Cela dépend du périmètre commandé. Un audit applicatif classique couvre : code, configuration applicative, dépendances, surface API. Un audit infrastructure couvre : OS, réseau, firewall, services exposés, durcissement serveur. Idéalement, commandez les deux si vous hébergez vous-même. Si vous êtes sur un PaaS managé (Vercel, Scaleway Serverless, Cloud Temple), l’audit infra est partiellement délégué à l’hébergeur.

Comment choisir un auditeur externe ?

Quatre critères. (1) Qualification PASSI ANSSI si vous êtes en environnement réglementé. (2) Références vérifiables dans votre secteur ou sur des projets similaires en taille. (3) Méthodologie écrite transmise avant signature (référentiel utilisé, livrables, format du rapport). (4) Disponibilité post-audit pour échanger sur les findings et accompagner la remédiation. Méfiez-vous des cabinets qui ne livrent qu’un PDF sans échange.

Que faire si l’auditeur trouve des trous critiques ?

Ne paniquez pas. Trois étapes. (1) Triez : criticité réelle vs théorique, exploitabilité, données impactées. (2) Patchez les criticals immédiatement (avant prod ou en hotfix si déjà en prod), planifiez les highs sous 2-4 semaines, les mediums au prochain sprint. (3) Documentez la remédiation et re-testez (audit de validation léger). Si la criticité est telle que vous devez retarder la mise en production : faites-le. Une mise en prod repoussée d’un mois coûte beaucoup moins cher qu’un incident en production.

Vous voulez auditer votre application métier ?

NothingElse.app intègre l’audit sécurité dans tous les projets que nous livrons. Nous accompagnons aussi les PME et ETI qui veulent auditer une application existante (développée en interne ou par un autre prestataire) avant une mise en production critique ou un appel d’offres exigeant.