Audit de sécurité informatique : grille, exemple de rapport
et prix

Cherchez "audit de sécurité informatique" et lisez les dix premiers résultats. Vous trouverez des catalogues de prestations qui empilent les acronymes, mais presque jamais un prix, ni un exemple de livrable, ni la moindre indication de ce qui sera vraiment testé. C'est gênant pour une décision d'achat : on vous demande de signer un devis sans savoir ce que vous allez recevoir. Cet article prend le contre-pied. On y pose une grille de contrôles concrète, un extrait de rapport anonymisé, les tarifs affichés, et surtout la distinction que la plupart des pages évitent : un audit de sécurité, ce n'est pas une seule chose, et ce que vous achetez dépend entièrement de la couche que vous voulez couvrir.

Une précision d'honnêteté d'abord. own2pwn est un pentester certifié OSWE qui intervient sur le volet technique d'un audit : configurations, code, exposition externe, exploitation. Pas sur la gouvernance (politique de sécurité, analyse de risques, plan de continuité), qui est un autre métier. Tout ce qui suit décrit donc ce qu'un audit technique prouve, comment il se déroule et ce qu'il coûte, sans jamais prétendre couvrir ce qu'il ne couvre pas.

Ce qu'un audit de sécurité informatique prouve vraiment

Un audit de sécurité, au sens large, répond à une question simple : est-ce que ce système résiste à quelqu'un qui essaie de le casser ? La difficulté, c'est qu'il y a trois façons très différentes de répondre, et qu'on les vend souvent sous le même mot. La première regarde vos règles : avez-vous une politique d'accès, une procédure de sauvegarde, une sensibilisation au phishing ? La deuxième regarde l'implémentation : ces règles sont-elles réellement appliquées dans les configurations et le code ? La troisième regarde la résistance : un attaquant, avec ces règles et cette implémentation, arrive-t-il quand même à ses fins ?

Un audit de sécurité informatique complet couvre idéalement trois couches : l'organisation, les systèmes internes et l'exposition externe. La plupart des PME imaginent qu'un audit se limite à un scan de leur site web. C'est la partie visible, mais la valeur vient du croisement des angles. Une politique de mots de passe parfaite sur le papier ne vaut rien si le portail d'administration est accessible sans authentification depuis Internet. C'est exactement ce qu'un audit de sécurité informatique en entreprise doit mettre en évidence : l'écart entre ce qui est écrit et ce qui est réellement exposé. Pour un panorama orienté petites structures, l'article dédié à l'audit informatique en PME détaille les quick wins avant même l'audit complet.

Audit organisationnel, audit technique, pentest : ce que chacun prouve

Voici la distinction qui manque presque partout, et qui devrait décider de ce que vous commandez. Les trois prestations ne regardent pas le même objet et ne produisent pas la même preuve. Confondre les trois, c'est acheter un audit organisationnel en croyant se protéger d'une intrusion, ou payer un test d'intrusion en s'attendant à un rapport de conformité. Le tableau ci-dessous résume ce que chacun démontre, ce qu'il laisse dans l'ombre, et où own2pwn intervient.

La colonne "ce qu'il ne prouve pas" est la plus utile. Un audit organisationnel peut donner un satisfecit à une entreprise dont le site principal tombe en trente minutes face à un attaquant, parce que la case "procédure existe" était cochée. Inversement, un test d'intrusion qui échoue à entrer ne prouve pas que le système est sain, il prouve que cet auditeur, dans ce périmètre et ce temps, n'a pas trouvé de chemin. La nuance entre balayer une surface et prouver un impact est développée dans l'article pentest contre scan de vulnérabilité. Et si vous hésitez entre un audit technique et une simulation d'attaque complète sur la durée, la comparaison red team contre pentest pose les curseurs. own2pwn se positionne sur les deux colonnes du bas : l'audit technique et le test d'intrusion en entreprise, jamais la gouvernance.

Les couches d'un audit : du périmètre au retest

Un audit technique sérieux suit toujours la même trajectoire, quel que soit le périmètre. Ce n'est pas un scanner qu'on lance et dont on exporte le PDF. Chaque phase conditionne la suivante : un mauvais cadrage produit un rapport hors sujet, une collecte bâclée laisse des actifs hors du champ, et un rapport sans preuve reproductible finit au fond d'un tiroir. Le schéma ci-dessous déroule les sept étapes, du cadrage jusqu'au retest qui vérifie que les correctifs tiennent.

La phase de cadrage mérite qu'on s'y arrête, car c'est là que la moitié des audits ratés se jouent. Un périmètre flou ("auditez notre SI") produit soit un survol inutile, soit un dépassement de budget. Le déroulé complet d'une mission, phase par phase, est détaillé dans l'article sur le déroulement d'un pentest. Retenez surtout que le retest, en phase 7, n'est pas une option commerciale : sans lui, personne ne sait si les vulnérabilités signalées ont réellement été fermées ou seulement lues.

Une grille d'audit de sécurité : domaine, contrôle, preuve, méthode

Voici la partie que les catalogues ne publient jamais. Une grille d'audit de sécurité, c'est la liste des contrôles qu'on vérifie, avec pour chacun la preuve qu'on attend et la méthode employée pour l'obtenir. Sans elle, "on audite votre sécurité" ne veut rien dire. Celle ci-dessous est un extrait volontairement resserré sur le périmètre applicatif et l'exposition externe, ceux qu'own2pwn couvre. La logique importe plus que l'exhaustivité : chaque ligne relie un objectif à un test reproductible, jamais à une case cochée à l'aveugle.

Chaque ligne de cette grille correspond à un test qu'on peut refaire et dont la sortie tient dans un journal ou une capture. C'est le critère qui sépare un audit d'un questionnaire déclaratif. La colonne "composants" renvoie directement à la gestion des vulnérabilités : trouver une version obsolète ne suffit pas, encore faut-il savoir si elle est atteignable et exploitable dans votre contexte. C'est cette hiérarchisation par risque réel, pas par nombre d'alertes, qui rend une grille exploitable pour un dirigeant.

À quoi ressemble un rapport d'audit de sécurité : exemple anonymisé

Un "rapport d'audit de sécurité" digne de ce nom n'est pas un export de scanner avec un logo dessus. Sa structure suit un ordre précis, du plus lisible au plus technique, pour qu'un dirigeant lise la synthèse et qu'un développeur trouve le détail reproductible. Voici l'ossature d'un rapport own2pwn, sans le moindre nom de client puisqu'un rapport d'audit est confidentiel par nature.

Rapport d'audit technique
├── 1. Synthèse pour la direction
│      Risque global, findings critiques, effort de remédiation
├── 2. Périmètre et méthodologie
│      Ce qui a été testé, comment, sur quelle fenêtre
├── 3. Tableau de bord des findings
│      Par sévérité : Critique / Élevé / Moyen / Faible
├── 4. Findings détaillés  (un par vulnérabilité)
│      ├── Description et localisation exacte
│      ├── Preuve reproductible (requête, capture, étapes)
│      ├── Sévérité CVSS v4.0 + vecteur
│      ├── Impact métier concret
│      └── Remédiation priorisée
├── 5. Plan d'action ordonné par risque
└── 6. Annexes : outils, journaux, périmètre exact

Le cœur du rapport, ce sont les findings détaillés. Chacun doit tenir seul : un développeur qui ne lit que cette fiche doit pouvoir reproduire le problème et le corriger. Voici à quoi ressemble un finding anonymisé, ici une faille de contrôle d'accès (un utilisateur accède à une ressource qui ne lui appartient pas). Les valeurs sont fictives et servent d'illustration.

FINDING-004 : Accès direct non autorisé à un objet (IDOR)
Sévérité : Élevé   (bande CVSS v4.0 : 7,0 à 8,9)
Localisation : GET /api/v2/invoices/{id}

Description
  L'identifiant de facture est un entier séquentiel. Un compte
  authentifié peut lire les factures d'autres clients en
  incrémentant simplement {id}. Aucun contrôle d'appartenance
  n'est effectué côté serveur.

Preuve (reproductible avec deux comptes de test)
  Compte A (id interne 1041) demande sa facture :
    GET /api/v2/invoices/5093   -> 200 OK  (sa facture)
  Le même compte A demande la facture d'un autre :
    GET /api/v2/invoices/5094   -> 200 OK  (facture du compte B)
  Attendu : 403 Forbidden.

Impact métier
  Fuite de données de facturation entre clients : montants,
  raisons sociales, adresses. Violation de confidentialité,
  exposition RGPD.

Remédiation (priorité 1)
  Vérifier l'appartenance de l'objet au compte appelant à
  chaque requête. Préférer un identifiant non devinable
  (UUID) à un entier séquentiel comme défense en profondeur.

Ce format n'a rien d'exotique : le score de sévérité s'appuie sur le barème public du CVSS v4.0 de FIRST, où la bande "Élevé" couvre 7,0 à 8,9 et "Critique" 9,0 à 10,0. Ce qui fait la valeur du finding, ce n'est pas le chiffre, c'est la preuve reproductible et l'impact métier traduit en langage de risque. Un rapport d'audit de sécurité qui vous donne une liste de CVE sans dire laquelle est réellement atteignable chez vous vous laisse exactement où vous étiez : devant une pile d'alertes à trier vous-même.

Combien coûte un audit de sécurité informatique en entreprise

Le prix d'un audit technique se ramène à une chose : du temps de spécialiste. Il n'y a pas de licence miracle qui remplace un humain qui lit une réponse HTTP et comprend pourquoi elle trahit une faille. Chez own2pwn, les tarifs sont affichés, parce qu'une décision d'achat éclairée vaut mieux qu'un devis opaque :

• Taux journalier : 450 euros net en blackbox, 600 euros net en whitebox (accès au code source et à des comptes de test, ce qui va plus vite et plus loin). TVA non applicable, art. 293 B du CGI.
• Missions cadrées : 2 250 euros pour un périmètre resserré, 4 500 euros pour un périmètre plus large. Le retest est inclus dans les deux cas.
• Réponse sous 24 heures à une demande de cadrage, pour poser le périmètre et le devis avant tout engagement.

Le facteur qui fait bouger le montant n'est jamais le nombre de failles trouvées, c'est la surface à couvrir et la profondeur demandée. Pour comprendre ce qui compose réellement une facture de test d'intrusion, l'article prix d'un test d'intrusion détaille les postes. Un point de vigilance : méfiez-vous d'un audit annoncé à quelques centaines d'euros. À ce niveau, ce n'est pas un audit, c'est la sortie brute d'un scanner automatisé, sans qualification ni preuve, rebaptisée en prestation. La différence entre blackbox, whitebox et greybox, et ce que chaque mode change au prix comme à la couverture, est traitée dans l'article sur les modes boîte noire, blanche et grise.

Choisir le bon périmètre quand on part de zéro

La question qui bloque le plus d'entreprises n'est pas "faut-il auditer" mais "par où commencer". La réponse tient en une règle : auditez d'abord ce qui est à la fois le plus exposé et le plus sensible. L'application qui porte vos données clients, accessible depuis Internet, passe avant le poste de travail du comptable. Un périmètre bien choisi vaut mieux qu'un audit "complet" qui survole tout sans rien prouver.

En pratique, on cadre autour de trois questions. Qu'est-ce qui, s'il tombe, fait le plus mal (données, disponibilité, réputation) ? Qu'est-ce qui est atteignable depuis l'extérieur sans authentification ? Et qu'est-ce qui a changé récemment (une refonte, une migration, un nouveau service exposé) ? Un audit est une photographie à un instant donné. Entre deux audits annuels, la surface d'attaque bouge : un sous-domaine oublié, une API mise en ligne, un composant qui vieillit. C'est là qu'une surveillance continue prend le relais, un rôle que remplit l'EASM (External Attack Surface Management), complémentaire de l'audit ponctuel et pas substituable à lui.

Enfin, si la conformité vous pousse vers un prestataire qualifié, sachez distinguer ce que le label PASSI de l'ANSSI apporte et ce dont vous avez réellement besoin. Un label est utile quand un texte l'exige ; il ne rend pas mécaniquement un audit meilleur qu'un audit technique bien mené. Le bon réflexe est de partir du besoin (prouver quoi, pour qui, contre quelle exigence), pas de l'acronyme.

À retenir

• Trois audits, trois preuves : l'organisationnel prouve que les règles existent, le technique qu'elles sont implémentées, le pentest qu'elles résistent. own2pwn couvre les deux derniers, pas la gouvernance.
• Une grille rend l'audit vérifiable : chaque contrôle a une preuve attendue et une méthode de test reproductible, pas une case déclarative.
• Un rapport utile donne pour chaque finding la preuve reproductible, la sévérité CVSS, l'impact métier et une remédiation priorisée, plus un retest pour confirmer les correctifs.
• Le prix, c'est du temps de spécialiste : 450 euros net par jour (600 en whitebox), missions à 2 250 ou 4 500 euros, retest inclus, TVA non applicable. Un audit à quelques centaines d'euros est un scan déguisé.
• Le périmètre d'abord : auditez le plus exposé et le plus sensible, et complétez l'audit annuel par une surveillance continue de la surface d'attaque.

Un audit de sécurité informatique ne vaut que par ce qu'il prouve, et par ce que vous pouvez en faire ensuite. Si vous voulez un audit technique cadré, avec des findings reproductibles et une remédiation ordonnée par risque plutôt qu'une liste d'alertes, on peut poser le périmètre ensemble. Demandez un audit web en boîte noire pour éprouver l'exposition externe, ou un audit en boîte blanche avec accès au code pour aller au fond, et écrivez-nous avec vos actifs prioritaires : réponse sous 24 heures pour le cadrage et le devis.

Questions fréquentes sur l'audit de sécurité informatique