Un audit de sécurité informatique ne consiste pas à lancer un scanner et à attendre une liste de failles. C’est une démarche cadrée qui examine les équipements, les applications, les accès et les pratiques de l’organisation, puis transforme les constats en actions concrètes. Pour une TPE, une PME ou une équipe web, l’enjeu est de savoir où se trouvent les risques qui peuvent réellement interrompre l’activité ou exposer des données.
La méthode dépend du niveau de sécurité attendu. Un service présentant des besoins élémentaires n’exige pas nécessairement un audit formel. Des besoins modérés justifient au minimum un test d’intrusion, tandis que des besoins importants ou élevés appellent un examen plus complet, avec audit d’architecture, audit de configuration et tests d’intrusion. Le périmètre doit aussi tenir compte des procédures, des locaux et des liens avec des prestataires : un pare-feu bien choisi ne compense ni un compte administrateur partagé ni des sauvegardes jamais testées.
Une entreprise fictive, Atelier Sillage, sert de fil conducteur. Elle vend en ligne, utilise un logiciel de gestion hébergé dans le cloud et confie la maintenance de son site à un prestataire. Son audit ne vise pas à « tout vérifier » sans distinction. Il doit identifier ce qui pourrait bloquer les commandes, compromettre les données des clients ou empêcher l’équipe de reprendre son activité après un incident.
En bref
- Définir le niveau de risque, les objectifs et le périmètre avant les tests.
- Examiner les configurations, les droits, les applications et les procédures, pas seulement les outils de sécurité.
- Classer les constats selon leur impact métier et leur exploitabilité.
- Transformer le rapport d’audit en plan de remédiation, puis vérifier les corrections.
Définir le périmètre et le niveau de l’audit de sécurité informatique
Le périmètre détermine ce qui sera réellement examiné. Pour Atelier Sillage, il peut inclure le site marchand, l’espace d’administration, les serveurs, les comptes cloud, le réseau du bureau et les accès du prestataire. Il faut aussi préciser les exclusions. Une filiale, un ancien environnement de test ou une application administrée par un tiers ne doit pas disparaître du cadrage simplement parce qu’elle est moins visible.
Commencez par relier les actifs à des usages et à des responsables. Un serveur héberge-t-il le site ou les sauvegardes ? Qui gère les comptes des salariés ? Où circulent les données de commande ? Cette cartographie n’a pas besoin d’être un schéma sophistiqué. Un inventaire clair, avec propriétaire, fonction, emplacement et sensibilité des données, vaut mieux qu’un diagramme jamais mis à jour.
Le niveau d’audit se choisit selon les conséquences d’un incident, l’exposition du service et les exigences de l’organisation. Pour un service aux besoins élémentaires, un audit formel peut ne pas être nécessaire. Lorsque le besoin est modéré, un audit partiel incluant au minimum des tests d’intrusion est recommandé. Pour des besoins importants ou élevés, un audit complet doit au moins couvrir l’architecture, les configurations et les tests d’intrusion.
| Approche | Ce qui est examiné | Quand la retenir |
|---|---|---|
| Audit d’architecture | Réseaux, interconnexions, segmentation et choix techniques | Refonte, migration ou ouverture à des partenaires |
| Audit de configuration | Serveurs, postes, équipements réseau et applications | Vérification des réglages et des règles de sécurité |
| Audit de code | Code source et conditions de compilation | Application développée ou maintenue en interne |
| Test d’intrusion | Failles exploitables dans un périmètre autorisé | Besoin modéré ou validation d’un service exposé |
| Audit organisationnel | Procédures, responsabilités, mesures physiques et pratiques | Accès, gestion des départs ou continuité d’activité à examiner |
Un test d’intrusion ne prouve pas l’absence de vulnérabilités : il démontre ce qu’un auditeur a pu découvrir et exploiter dans les conditions convenues. Il ne remplace donc pas l’analyse des pratiques et des configurations. Pour approfondir le cadrage, la méthode présentée dans ce guide d’audit de cybersécurité peut aider à préparer les étapes et les questions à poser.
Préparer l’audit et réunir les informations utiles
Un audit bien préparé réduit les interruptions et évite les constats fondés sur des informations incomplètes. Avant toute intervention, l’organisation doit préciser les objectifs, les plages horaires, les systèmes concernés et les personnes autorisées à répondre aux auditeurs. Cette étape est particulièrement importante lorsque des tests sont réalisés sur un service en production : un contrôle mal planifié peut perturber une boutique en ligne ou déclencher les alertes d’un prestataire.
Atelier Sillage rassemble ses schémas réseau, l’inventaire des équipements, la liste des applications, les règles de gestion des comptes et les procédures de sauvegarde. L’équipe indique aussi les services opérés par des tiers. Si l’hébergement est externalisé, les responsabilités de l’entreprise et de l’hébergeur doivent être distinguées ; un audit ne donne pas automatiquement le droit de tester les infrastructures d’un fournisseur.
Les journaux techniques, ou logs, apportent des traces sur les connexions et les événements. Leur disponibilité dépend des outils et de la durée de conservation définie par l’organisation. Il faut vérifier que les accès nécessaires à l’audit sont prévus, limités et traçables. Fournir un compte d’administration permanent à tous les intervenants n’est pas une bonne préparation : les droits doivent correspondre aux contrôles autorisés.
Une réunion de lancement permet de fixer les règles par écrit. Elle précise le périmètre, les contacts d’urgence, les horaires, les techniques permises et les systèmes à exclure. Pour un test d’intrusion, ces règles d’engagement sont indispensables. Elles protègent l’entreprise comme le prestataire et évitent qu’une vérification légitime soit confondue avec une attaque réelle.
- Inventorier les actifs, les applications, les données sensibles et leurs responsables.
- Réunir les schémas, les règles d’accès, les procédures et les éléments de preuve disponibles.
- Valider les autorisations, les limites des tests et les contacts à prévenir en cas d’incident.
- Planifier les interventions en tenant compte des périodes de forte activité et des dépendances externes.
Le choix d’un auditeur mérite la même attention que le choix du périmètre. Pour une mission sensible ou structurante, l’organisation peut consulter les prestataires d’audit de sécurité qualifiés PASSI par l’ANSSI et vérifier que les compétences proposées correspondent au besoin. Une mission doit annoncer clairement ses limites : « audit complet » ne signifie rien si les applications, les accès distants ou les procédures sont laissés de côté.
La conformité réglementaire peut entrer dans le périmètre, mais elle ne doit pas absorber toute l’analyse. Le RGPD, ISO 27001, NIS 2 ou DORA répondent à des objectifs et à des obligations différents. Cocher des exigences documentaires sans vérifier les protections effectivement en place donne une image rassurante, mais incomplète. Les règles de protection des données doivent être reliées aux traitements réels, aux personnes qui y accèdent et aux mesures techniques correspondantes.
Pour une entreprise qui utilise un hébergement cloud, il est utile d’identifier précisément les services concernés et les responsabilités de chacun. Une ressource consacrée aux services d’hébergement cloud peut servir de point de départ pour comprendre les différences entre les offres, sans remplacer l’examen des réglages du compte et des contrats.
Examiner les configurations, les accès et la sécurité réseau
La phase technique confronte les réglages réels aux pratiques de sécurité attendues et aux règles internes. Les produits installés ne suffisent pas à démontrer que le système est protégé. Un pare-feu mal configuré, un logiciel jamais mis à jour ou un compte constructeur laissé actif peut créer une voie d’accès malgré la présence d’outils de sécurité. L’audit doit donc vérifier la manière dont les dispositifs fonctionnent, pas seulement leur nom dans un inventaire.
Le contrôle des accès examine qui peut consulter, modifier ou administrer chaque ressource. Chez Atelier Sillage, l’auditeur pourrait repérer un ancien compte salarié encore actif, des droits trop larges accordés à un compte de maintenance ou un identifiant partagé entre plusieurs personnes. Ces situations compliquent la traçabilité et augmentent les conséquences d’un mot de passe volé. Les départs, changements de poste et comptes temporaires méritent une attention particulière.
Les configurations des systèmes d’exploitation, des équipements réseau et des applications sont examinées selon le périmètre retenu. L’auditeur vérifie notamment les mises à jour, les services exposés, les réglages par défaut et la journalisation. La sécurité réseau implique aussi de comprendre les échanges entre les zones : un poste de travail ne devrait pas avoir accès à toutes les ressources simplement parce qu’il est connecté au réseau du bureau.
Les applications web et les API nécessitent des contrôles adaptés. L’authentification, la gestion des sessions, les entrées fournies par les utilisateurs et les messages d’erreur peuvent révéler des faiblesses. Une boutique en ligne doit être examinée en tenant compte de ses fonctions métier : création de compte, commande, paiement et accès à l’espace client. Les tests doivent éviter de modifier des données réelles ou de déclencher des opérations irréversibles.
Dans le cloud, l’examen porte souvent sur les droits des comptes, l’exposition des ressources, la configuration du stockage et les relations entre services. Le fait qu’une plateforme soit administrée par un fournisseur ne dispense pas l’entreprise de sécuriser ses comptes et ses réglages. Une mauvaise attribution de droits peut exposer des données même si l’infrastructure sous-jacente est correctement maintenue.
Un audit de code source peut compléter les contrôles lorsqu’une application est développée ou adaptée par l’entreprise. Il recherche des erreurs de programmation et des défauts de logique susceptibles de compromettre la confidentialité ou l’intégrité des données. Cette activité ne consiste pas simplement à lancer un outil d’analyse automatisée : les résultats doivent être examinés et replacés dans le fonctionnement réel de l’application.
Les scanners de vulnérabilités sont utiles pour repérer des versions obsolètes ou des services exposés, mais ils ne constituent pas un audit à eux seuls. Ils peuvent produire des alertes à confirmer et manquer des défauts liés aux règles métier. La gestion des vulnérabilités demande donc un suivi : vérifier les alertes pertinentes, déterminer les systèmes touchés, appliquer les corrections et contrôler leur efficacité.
Les mesures physiques et organisationnelles restent dans le champ de la sécurité. Une salle serveur accessible sans contrôle, des sauvegardes conservées au même endroit que les équipements principaux ou une procédure de récupération inconnue des équipes peuvent fragiliser l’ensemble du dispositif. Les protections techniques ont besoin de procédures appliquées et de responsables identifiés.
Analyser les résultats et rédiger un rapport d’audit exploitable
Un constat n’est utile que si l’entreprise comprend son effet possible et sait quoi faire ensuite. Le rapport d’audit doit documenter le périmètre, la méthode, les vérifications réalisées, les limites de la mission et les éléments qui justifient chaque observation. Une capture, une configuration examinée ou un résultat de test apporte une preuve ; une affirmation sans contexte ne suffit pas à guider une correction.
La gravité ne se résume pas à une note automatique. Une vulnérabilité exposée sur un service accessible depuis Internet n’a pas le même poids qu’un défaut sur un environnement isolé et sans données sensibles. Pour établir les priorités, l’équipe doit rapprocher la facilité d’exploitation, l’exposition, l’impact métier et les protections déjà en place.
Atelier Sillage pourrait recevoir un constat sur un compte d’administration inutilisé. Le risque dépend alors de plusieurs éléments : le compte est-il actif ? Peut-il accéder à la boutique ? Est-il protégé par une authentification forte ? Les journaux permettent-ils de repérer son usage ? La réponse à ces questions aide à décider s’il faut désactiver immédiatement le compte ou programmer une modification plus large des règles d’accès.
Le rapport doit distinguer les problèmes techniques des écarts organisationnels et réglementaires, tout en montrant leurs liens. Une procédure de création de comptes trop permissive peut expliquer la présence de droits excessifs. Une sauvegarde non testée peut transformer une panne limitée en interruption prolongée. Ce croisement évite de traiter uniquement le symptôme visible.
Les recommandations doivent être précises et proportionnées. « Renforcer la sécurité » n’indique ni la tâche à effectuer ni le résultat attendu. Une consigne utile nomme le système concerné, le changement recommandé, la priorité et, si possible, le responsable de la correction. Les actions peuvent être réparties entre mesures immédiates, corrections planifiées et changements d’architecture plus longs.
Il faut aussi présenter les limites de l’exercice. Un test d’intrusion couvre un périmètre et une période définis ; il ne certifie pas qu’aucune faille n’existe. Un scan automatisé fournit des indices, pas une garantie. Pour cette raison, les résultats doivent être lus avec le contexte de l’entreprise, et non comme un classement abstrait de vulnérabilités.
La restitution orale aide à clarifier les constats avec les équipes techniques et métier. Un responsable de boutique n’a pas besoin de parcourir toutes les preuves techniques pour comprendre qu’une faiblesse peut exposer les commandes. À l’inverse, l’équipe qui applique la correction doit disposer d’assez de détails pour savoir où intervenir et comment vérifier le résultat.
Un bon rapport d’audit crée un langage commun entre direction, équipe informatique et prestataires. Il relie chaque faiblesse à un risque compréhensible, sans dramatiser ni minimiser. Sa valeur se mesure à la qualité des décisions qu’il rend possibles, pas au nombre de pages ni au volume d’alertes recensées.
Construire un plan de remédiation et vérifier les corrections
La remise du rapport ne clôt pas la démarche. Sans décisions, responsables et échéances, les constats s’accumulent dans un dossier partagé puis disparaissent de l’agenda. Le plan de remédiation transforme les recommandations en tâches suivies. Il peut être géré dans un outil de projet classique, à condition que chaque action soit attribuée et que son avancement soit vérifiable.
Pour Atelier Sillage, une faille directement exploitable sur l’espace d’administration peut justifier une correction rapide, tandis qu’une refonte de la segmentation réseau demandera un projet distinct. Les priorités doivent tenir compte des dépendances et des contraintes d’exploitation, mais « manque de temps » ne peut pas devenir une réponse permanente à un risque élevé. Si la correction ne peut pas être appliquée tout de suite, une mesure temporaire doit réduire l’exposition et avoir une date de réexamen.
Le suivi peut distinguer plusieurs échéances : les mesures urgentes, les corrections planifiées à court terme et les chantiers structurels. Ce découpage aide à arbitrer les ressources et à expliquer les décisions à la direction. Il permet aussi de ne pas sacrifier les problèmes qui demandent plus de travail au profit des seules corrections faciles.
Après correction, l’organisation doit vérifier que le problème a disparu et que le changement n’a pas provoqué de régression. Selon la nature du constat, cette revalidation peut prendre la forme d’un nouveau test, d’une revue de configuration ou d’une vérification des journaux. Pour un service exposé, une confirmation du prestataire ne remplace pas toujours une preuve observable.
La protection des données dépend aussi de la capacité à reprendre l’activité. Les sauvegardes doivent être protégées, accessibles aux personnes autorisées et testées dans des conditions représentatives. Une sauvegarde qui n’a jamais été restaurée est une hypothèse, pas une assurance de reprise. Le plan de continuité doit préciser qui intervient, quelles ressources sont prioritaires et comment les équipes communiquent pendant une interruption.
La fréquence des audits n’a pas à être identique pour tous les systèmes. Un changement majeur, une migration vers le cloud, l’ajout d’un partenaire ou un incident peut justifier une revue ciblée avant la prochaine échéance régulière. Pour les services sensibles, un audit périodique aide à repérer les écarts apparus depuis la dernière vérification. Le calendrier doit suivre l’évolution du risque, pas seulement une date choisie par habitude.
La conformité réglementaire se maintient également dans le temps. Une procédure peut être écrite sans être connue, un accès temporaire peut devenir permanent et un nouveau traitement de données peut apparaître lors d’une évolution commerciale. Une revue des règles et des pratiques permet de détecter ces décalages avant qu’ils ne deviennent des incidents ou des écarts difficiles à justifier.
Pour une entreprise de taille modeste, le rythme peut rester pragmatique : suivre régulièrement les correctifs et les accès, refaire des contrôles ciblés après les changements importants, puis programmer un audit plus large selon le niveau de risque. L’objectif n’est pas de multiplier les missions, mais de vérifier que les protections annoncées existent, fonctionnent et restent adaptées aux usages réels.
Un audit apporte donc une photographie utile, mais le niveau de sécurité dépend de ce qui se passe après la restitution. Lorsque les corrections sont vérifiées et les responsabilités clairement réparties, le rapport cesse d’être un document de conformité et devient un outil de pilotage.
À quelle fréquence réaliser un audit de sécurité informatique ?
La fréquence dépend du risque et des changements du système. Un audit périodique peut être complété par des contrôles ciblés après une migration, l’ajout d’un service ou un incident de sécurité.
Un test d’intrusion suffit-il pour sécuriser une entreprise ?
Non. Il recherche et vérifie des failles exploitables dans un périmètre défini, mais ne remplace pas l’examen des configurations, de l’architecture, des procédures et des accès.
Que doit contenir un rapport d’audit ?
Le rapport décrit le périmètre et la méthode, présente les constats et leurs preuves, évalue les risques et propose des recommandations classées par priorité. Il précise aussi les limites de la mission.
Faut-il toujours faire appel à un prestataire externe ?
Pas nécessairement pour chaque contrôle. Un prestataire indépendant est toutefois pertinent pour les missions sensibles, les tests d’intrusion ou lorsque l’entreprise ne dispose pas des compétences et du recul nécessaires.
