Comment préparer un audit de cybersécurité

Un audit de cybersécurité se prépare, et il se prépare plus tôt que la plupart des équipes ne l’anticipent. La difficulté n’est presque jamais de rédiger les politiques : elle est de démontrer que les mesures décrites fonctionnent réellement. Un auditeur, un client donneur d’ordre ou un organisme de certification ne se contente pas d’un classeur de procédures. Il demande des éléments probants, datés, indépendants, et il demande ce que vous en avez fait.

C’est exactement ce qu’un test d’intrusion produit : une attaque contrôlée de vos propres systèmes, menée sur mandat écrit, dont le rapport devient une pièce du dossier d’audit. Cet article explique ce que recouvre un audit de cybersécurité en France, quels textes vous obligent réellement à tester, par quels dispositifs gratuits commencer, et comment enchaîner les étapes pour arriver préparé à la date de l’audit. Il s’adresse aux RSSI, aux DSI de PME et d’ETI et aux dirigeants, en langage courant.

Ce que recouvre un audit de cybersécurité

Un audit de cybersécurité est une évaluation méthodique de l’écart entre les exigences qui vous sont applicables et ce que vous avez effectivement mis en place. En France, il prend plusieurs formes selon l’origine de la demande : un audit de certification ISO/IEC 27001 conduit par un organisme accrédité, un audit interne ou un audit à blanc mené pour votre propre système de management, un audit fournisseur demandé par un client dans le cadre d’un marché, ou encore un contrôle sectoriel.

Le vocabulaire technique, lui, est stable, parce que le marché français a hérité de la découpe utilisée par l’ANSSI pour décrire les prestations d’audit. Vous retrouverez ces cinq portées dans presque tous les cahiers des charges :

• Audit d’architecture : la conception du système d’information, le cloisonnement, les flux, les points d’exposition.


• Audit de configuration : le paramétrage réel des équipements, des serveurs, des annuaires et des services cloud, comparé à un référentiel de durcissement.


• Audit de code source : la revue des sources d’une application, généralement ciblée sur les fonctions sensibles.


• Tests d’intrusion : la mise à l’épreuve du système par des scénarios d’attaque, avec démonstration de l’exploitation.


• Audit organisationnel et physique : la gouvernance, les procédures, les habilitations, les accès aux locaux.

Un audit de sécurité informatique combine généralement plusieurs de ces portées. Son livrable est un rapport qui liste les points conformes, les écarts constatés et les recommandations. Pour la direction, c’est une photographie datée du niveau de sécurité. Pour l’auditeur externe, c’est la matière première du dossier.

Le cadre français : ce qui vous oblige réellement à tester

Levons d’emblée un malentendu commercial fréquent. Aucun texte français en vigueur n’impose à une entreprise privée de faire réaliser « un test d’intrusion » en tant que tel. Les obligations qui existent portent sur le résultat — un niveau de sécurité adapté au risque — et vous laissent le choix des moyens. Cela ne veut pas dire que le test est facultatif dans les faits : par plusieurs chemins, il devient la façon la plus économique de prouver ce qu’on vous demande de prouver.

Deux points pratiques complètent ce tableau. D’abord, le mandat écrit n’est pas une formalité : sans autorisation, les actes réalisés pendant un test relèveraient des articles 323-1 et suivants du code pénal. Tous nos tests d’intrusion sont réalisés sur mandat écrit, dans un périmètre défini contractuellement — et c’est précisément la pièce que votre auditeur demandera pour vérifier que le test était licite. Ensuite, si un test met en évidence une violation de données à caractère personnel, la notification à la CNIL dans les 72 heures prévue par l’article 33 du RGPD s’applique comme pour tout autre incident.

NIS 2 et ReCyF : où en est-on vraiment

La question revient à chaque cadrage, et beaucoup de pages francophones y répondent faussement. La directive (UE) 2022/2555 n’est pas transposée en droit français. Le véhicule législatif est le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, adopté par le Sénat le 12 mars 2025 et transmis à l’Assemblée nationale, où son examen n’est pas achevé. Tant que ce texte n’est pas promulgué, personne ne peut vous opposer une obligation d’enregistrement, une échéance ou un plafond de sanction en droit français. Nous détaillons l’état d’avancement dans NIS 2 en France et la loi Résilience.

Dans l’intervalle, l’ANSSI a mis à disposition le Référentiel Cyber France (ReCyF) le 17 mars 2026. Il correspond au référentiel de cybersécurité mentionné à l’article 14 du projet de loi Résilience et il est diffusé à ce stade en tant que document de travail. Il organise les exigences en objectifs de sécurité, dont une partie s’applique aux entités importantes et une partie supplémentaire aux entités essentielles. L’un de ces objectifs porte sur la réalisation d’audits et de contrôles techniques — c’est celui qui intéresse directement la préparation d’un audit.

Deux précautions de vocabulaire, parce qu’elles se voient immédiatement dans une salle de réunion française. On peut travailler l’alignement sur les objectifs du ReCyF ; on ne peut pas être « certifié ReCyF », et aucun prestataire ne peut vous le délivrer. Et le référentiel n’est pas, en lui-même, une obligation opposable. L’intérêt de s’y référer dès maintenant est ailleurs : ce que vous mettez en place aujourd’hui pour démontrer que vos mesures sont testées restera valable après la transposition, quel que soit le texte final. Nous consacrons un article entier à cette traduction en périmètre testable : ReCyF, l’objectif d’audit de l’ANSSI et vos tests.

Commencez par les dispositifs de diagnostic français

Avant d’engager un budget d’audit, il existe en France une couche de diagnostics d’entrée de gamme, gratuits ou subventionnés, que les pages traduites depuis l’anglais ne mentionnent jamais. Ils ne remplacent pas une preuve technique, mais ils vous font gagner du temps sur le cadrage et ils vous évitent de payer pour découvrir des évidences.

• L’autodiagnostic de Cybermalveillance.gouv.fr : un questionnaire en ligne gratuit qui situe votre niveau de maturité et renvoie vers des fiches pratiques. Utile pour objectiver une discussion avec la direction générale.


• MonAideCyber : un dispositif de diagnostic gratuit porté par l’ANSSI, conduit bénévolement par des aidants cyber, orienté vers les petites structures et les collectivités. Il se conclut par un petit nombre d’actions prioritaires.


• Le DiagCyber des chambres de commerce et d’industrie : un diagnostic proposé localement par les CCI, souvent couplé à un accompagnement de proximité. Les modalités varient d’une chambre à l’autre ; renseignez-vous auprès de la vôtre.


• Le Diag Cybersécurité de Bpifrance : un diagnostic approfondi, réalisé par un prestataire référencé et partiellement financé dans le cadre des dispositifs publics de soutien aux PME. C’est le plus proche d’un véritable audit organisationnel, mais il reste déclaratif.


• Le parcours Cyberdépart de France Num : une entrée gratuite pour les TPE qui n’ont encore rien formalisé.

Soyons clairs sur ce que ces dispositifs apportent et sur ce qu’ils n’apportent pas. Ils produisent un état des lieux déclaratif : ils constatent que vous avez, ou non, une politique de mots de passe, des sauvegardes, une gestion des accès. C’est une excellente base de départ et un bon point d’entrée pour une direction qui découvre le sujet. Mais un auditeur ne les acceptera pas comme preuve que vos mesures fonctionnent, parce qu’ils ne les mettent pas à l’épreuve. Aucun de ces diagnostics ne dira si votre pare-feu laisse effectivement passer ce qu’il est censé bloquer.

Un mot d’honnêteté pour finir sur ce point : ces dispositifs sont des programmes publics français, et leurs volets subventionnés passent par des prestataires référencés en France. Haxoris est un prestataire européen ; nous n’intervenons pas sur ces volets financés. Nous intervenons sur ce qui vient après, quand il faut produire la preuve technique.

Ce que votre auditeur attend comme preuve technique

Quand on en arrive aux éléments probants, les attentes sont assez homogènes d’un auditeur à l’autre. Personne ne cherche à cocher une case : on cherche une preuve traçable.

1. Une preuve indépendante et récente : les tests menés par votre propre équipe informatique sont utiles au quotidien, mais ils passent rarement comme élément probant formel, parce que l’indépendance manque. Un rapport établi par un tiers est nettement plus solide. La fraîcheur compte tout autant : au-delà de douze mois, un rapport perd l’essentiel de sa valeur, puisque votre environnement comme la menace ont changé.


2. Du contenu, pas des données brutes : un export brut de scanner, long de centaines de lignes et dépourvu de contexte, joue contre vous. Les rapports constitués uniquement de sorties d’outils éveillent la méfiance et débouchent presque toujours sur une demande de preuve complémentaire. À l’inverse, un rapport de test lisible, où chaque constat est confirmé et son impact expliqué, répond à la question du premier coup. Nous détaillons ce que recouvre un [audit de vulnérabilités](/fr/services/audit-de-vulnerabilites) et ce qui le sépare d’un test dans [scan de vulnérabilités ou test d’intrusion](/fr/articles/scan-vulnerabilites-ou-test-intrusion).


3. Un plan de remédiation, pas seulement une liste : pour chaque écart constaté, votre auditeur veut savoir qui corrige, quand, et où le suivi est enregistré. La conscience du risque ne suffit pas ; c’est l’effort documenté de traitement dans un délai raisonnable qui démontre que vos mesures vivent.

En résumé, un auditeur cherche une preuve crédible que vous testez votre résistance de façon régulière et que vous traitez ce que vous trouvez. Un rapport de test d’intrusion bien construit couvre l’essentiel de ces attentes en un seul document.

Où ces preuves atterrissent dans un dossier ISO 27001

Si vous préparez ou maintenez une certification ISO/IEC 27001, deux mesures de l’annexe A accueillent naturellement les résultats de test. La 8.8 traite de la gestion des vulnérabilités techniques : obtenir l’information, évaluer l’exposition, agir. Un rapport de test assorti d’une cotation du risque, du suivi des corrections et d’un contre-audit remplit cette chaîne de bout en bout. La 8.29 traite des tests de sécurité pendant le développement et la recette : elle attend que le test soit intégré à votre chaîne de production, et non réalisé une fois par an de façon isolée. Documenter les deux avec la même série de rapports garde le dossier compact et cohérent.

Rappelons au passage ce qu’une certification ISO 27001 ne fait pas : elle ne couvre pas automatiquement ce que la directive NIS 2 demandera une fois transposée. Nous traitons cette articulation dans ISO 27001 et NIS 2. Et par construction, les certificats sont délivrés par des organismes de certification accrédités, jamais par le prestataire qui vous accompagne : nous préparons le dossier, nous n’en jugeons pas.

Pourquoi le test d’intrusion change la donne

Vous pouvez traiter beaucoup de sujets en interne : écrire des politiques, sensibiliser vos équipes, déployer des outils. Le test d’intrusion est le seul exercice qui vérifie, en conditions réelles, si tout cela tient.

• Il mesure l’efficacité, pas l’existence : l’audit constate sur le papier que vous disposez d’un pare-feu, d’une protection des postes et de sauvegardes. Seul le test montre si le pare-feu filtre réellement, ou si un attaquant passe à côté. Les deux démarches sont complémentaires ; sans test, le sentiment de sécurité peut être trompeur.


• Il produit des constats actionnables : un service exposé qui sert de point d’entrée, un accès non prévu à une base, une fuite de données techniques. Ce sont des tâches, pas des généralités.


• Il évite la mauvaise surprise le jour de l’audit : un auditeur qui découvre lui-même une base de données accessible depuis Internet colore tout son rapport. Mieux vaut trouver et corriger avant, pour qu’il constate un environnement assaini ou, à tout le moins, un traitement en cours.


• Il vaut aussi hors de toute contrainte : même sans obligation, l’investissement se rembourse en risque d’incident évité et en temps d’audit gagné. La structure des coûts est détaillée dans [combien coûte un test d’intrusion](/fr/articles/prix-test-intrusion-pentest).


• Il est opposable au marché : dans un appel d’offres ou une évaluation fournisseur, le rapport de test est souvent le premier document demandé. Vous montrez que votre sécurité est vérifiée par un tiers, au lieu de l’affirmer.

Et le facteur humain ?

La sécurité ne se réduit pas à la technique. Lorsque le périmètre le permet, un exercice contrôlé d’ingénierie sociale — phishing (hameçonnage), phishing ciblé, parfois vishing — montre comment votre chaîne de signalement, de détection et d’escalade se comporte réellement. Ce n’est pas une évaluation des personnes, mais un test de mesures organisationnelles. Les résultats sont restitués de façon agrégée, jamais nominative, et aucune sanction individuelle n’en découle. En France, cela suppose que le client informe préalablement ses salariés et, selon l’effectif, associe les instances représentatives du personnel : faites valider ce point par votre direction des ressources humaines avant de lancer la campagne. Pour un auditeur, l’agrégat est exactement la preuve qui compte, et il se prolonge naturellement par un programme de sensibilisation à la cybersécurité.

Les livrables qui servent à la fois votre auditeur et vos équipes

Une mission bien menée produit un ensemble cohérent de livrables. Voici ce que chacun apporte.

• Le rapport : une synthèse managériale qui expose les risques majeurs et leur impact en langage de direction, puis une partie technique où chaque vulnérabilité est décrite, démontrée et cotée. Un bon rapport nomme la méthodologie employée — [OWASP](/fr/methodologies/owasp), WSTG, MASTG, PTES — pour que le lecteur sache jusqu’où le test est allé.


• La liste des vulnérabilités, contextualisée : une cotation générique de type CVSS ne suffit pas. Le rapport doit expliquer ce qu’une faille signifie pour votre activité : fuite de données clients, interruption de service, fraude. Cette contextualisation facilite le travail de l’auditeur, qui voit que vous connaissez vos propres risques, et la vôtre, qui savez par où commencer.


• Les recommandations et le plan de remédiation : pour chaque constat, une correction concrète et priorisée — une version à installer, un paramètre à changer, une authentification multifacteur à activer, une logique applicative à revoir. C’est souvent la partie la plus utile de la mission pour vos équipes.


• Le périmètre et la méthodologie : la note de cadrage, les fenêtres de test, les comptes fournis, les exclusions. Nos tests d’[applications web](/fr/services/test-intrusion/pentest-web) s’appuient par exemple sur [OWASP ASVS](/fr/methodologies/owasp-asvs), ce qui garantit une couverture systématique plutôt qu’une revue des seules vulnérabilités les plus connues. Un périmètre explicite rend le test reproductible : un tiers peut rejouer une partie des contrôles.


• La restitution : une séance de présentation des résultats, en visioconférence, où vos équipes techniques posent leurs questions. Ce moment fait gagner plusieurs semaines de correction.


• Le contre-audit : la vérification que les correctifs tiennent, puis la mise à jour du rapport. Chez Haxoris, il est inclus sans surcoût dans les 90 jours suivant la remise du rapport. Le rapport ainsi mis à jour est en général le document exact que votre auditeur souhaite voir.

Ces livrables font le pont entre le monde technique et le monde de l’audit. Pour vos équipes, c’est une liste de tâches. Pour l’auditeur, c’est la démonstration que vous connaissez vos risques et que vous agissez. Si la notion de test d’intrusion elle-même reste floue dans votre organisation, cette définition sert de base commune avant le cadrage.

Un calendrier de préparation sur six mois

Un audit prévu dans trois mois demande du travail dès maintenant. L’ordre ci-dessous évite d’avoir à corriger des constats critiques dans les dernières semaines.

Trois points de vigilance. Conservez le mandat écrit : c’est ce qui distingue un test autorisé d’une infraction, et l’auditeur le demande. Acceptez les risques résiduels de façon explicite et motivée : tout n’a pas à être corrigé, mais une acceptation formalisée par la bonne personne vaut infiniment mieux qu’un constat laissé en suspens. Et ne planifiez pas le test trop près de la date d’audit : il vous faut le délai intermédiaire pour corriger et faire vérifier.

Faut-il un prestataire titulaire d’une qualification de l’État ?

La question arrive presque toujours, et elle mérite une réponse franche plutôt qu’une formule évasive. La qualification PASSI est une démarche volontaire délivrée par l’ANSSI au titre du décret n° 2015-350 du 27 mars 2015. Elle n’est pas requise pour un audit ou un test d’intrusion commandé par une entreprise privée.

Elle le devient dans des contextes précis. Les contrôles des systèmes d’information d’importance vitale ordonnés au titre de l’article L. 1332-6-3 du code de la défense sont réalisés par l’ANSSI, par des services de l’État désignés par le Premier ministre, ou par des prestataires de service qualifiés. Certains marchés publics posent aussi cette exigence dans leur cahier des charges.

Haxoris ne détient pas la qualification PASSI et ne soumissionne pas sur ces prestations. Pour tout le reste — un éditeur SaaS, une PME ou une ETI du secteur privé, un programme ISO 27001, une préparation aux exigences de la directive NIS 2 — ce qui détermine la valeur d’un rapport devant un auditeur, ce sont la méthodologie employée, les certifications individuelles des personnes qui testent, un exemple de rapport que vous pouvez lire avant de signer, et la façon dont vos données sont traitées. Nous développons ce point dans faut-il un prestataire titulaire de la qualification PASSI.

Conclusion : arrivez préparé

Un audit de cybersécurité n’a rien d’un épouvantail quand la préparation a commencé assez tôt. Les résultats d’un test d’intrusion y contribuent de façon décisive : vous trouvez et corrigez les faiblesses avant qu’un tiers ne les découvre, vous remettez à votre auditeur une preuve tangible, et vous montrez que la protection de vos systèmes est traitée comme un processus, pas comme une formalité annuelle.

Haxoris vous accompagne sur cette partie du chemin. Nos pentesteurs produisent des rapports détaillés, des méthodologies éprouvées et des recommandations exploitables, avec une restitution en visioconférence et un contre-audit inclus. Que vous prépariez une certification ISO 27001, un audit de sécurité informatique plus large ou l’anticipation des exigences de la directive NIS 2, nous calons le programme de test sur votre échéance. N’attendez pas qu’un auditeur — ou un attaquant — trouve les écarts à votre place.

Dernière vérification : 11 septembre 2026.

Nos services associés : audit de sécurité informatique de votre environnement · tests d’intrusion sur vos applications et vos infrastructures · tests d’intrusion pour préparer la certification ISO 27001