En quoi consiste un audit de sécurité informatique ?

Pour comprendre en quoi consiste un audit de sécurité informatique en entreprise, distinguez le volet organisationnel, qui évalue les responsabilités, les accès, les sauvegardes et la réponse à incident, du volet technique, qui examine les paramètres des systèmes, les vulnérabilités et le code. Le prix dépend du nombre de systèmes à examiner et de la profondeur du travail : notre contrôle de sécurité automatisé coûte 89–890 € selon le périmètre, tandis qu’un audit manuel réalisé par un expert est proposé à partir de 3 500 €. Déterminez d’abord le volet dont vous avez besoin et les preuves attendues : l’examen d’un site, l’évaluation du management de la sécurité d’une entreprise et la certification constituent des prestations distinctes, aux résultats différents.

Imaginez qu’avant la signature d’un contrat, un client vous demande un audit de sécurité, avec en annexe des questions portant à la fois sur les droits d’accès des salariés et sur l’examen technique du système. Transmettre simplement la demande au développeur ne suffit pas : vous devez établir avec le client s’il attend un rapport sur le site, des processus d’entreprise documentés ou le certificat d’un organisme indépendant, et quels systèmes ou activités cette attestation doit couvrir. Nous recommandons de conserver la formulation exacte de la demande et d’en préciser l’objectif avant de choisir le prestataire et d’accepter le devis.

En quoi consiste un audit de sécurité informatique : deux missions sous un même nom

Les deux volets répondent à des questions différentes. Le volet organisationnel examine comment l’entreprise prend et applique ses décisions de sécurité ; le volet technique, comment un système donné fonctionne et si ses protections peuvent être contournées. Un même sujet prend donc une forme très différente dans chacun : pour évaluer la procédure de gestion des droits d’accès, l’auditeur demande qui approuve les droits d’un salarié et comment ils sont révoqués ; pour tester l’application, il tente, avec un compte ordinaire, d’effectuer des actions interdites à ce compte. Il est utile de lire les deux résultats ensemble, mais l’un ne remplace pas l’autre : une politique d’accès bien définie ne prouve pas que l’application la respecte, et une application sûre ne prouve pas que quelqu’un ait désactivé le compte d’un salarié parti.

Le mot « audit » ne suffit donc pas à définir une commande. Nous recommandons d’y ajouter deux éléments : les critères d’évaluation du travail et les preuves attendues dans le rapport. Pour une analyse de vulnérabilités, il s’agit de constats hiérarchisés ; pour un test d’intrusion, d’un mécanisme de protection ou d’une restriction d’action précis que l’on tentera de contourner ; pour un audit organisationnel de conformité, d’un ensemble d’exigences auquel comparer les documents et les pratiques quotidiennes.

Si vous choisissez uniquement une évaluation initiale des faiblesses, présentez le résultat comme tel, et non comme une certification, et convenez dès la définition de la mission des destinataires du document et de la décision qu’ils devront prendre. Pour une certification, il est essentiel de savoir qui délivrera l’attestation : l’ISO ne certifie pas elle-même les entreprises et définit la certification comme l’attestation écrite, par un organisme indépendant, de la conformité à des exigences précises. Dans cette même explication, l’ISO indique que l’accréditation atteste la compétence de l’organisme de certification, sans être obligatoire ; affirmer que seuls les organismes accrédités peuvent certifier serait donc inexact. Si votre client exige une certification accréditée, précisez cette condition avant le contrat et vérifiez l’accréditation de l’organisme choisi, pour éviter de vous retrouver avec une attestation que le client n’a pas accepté de reconnaître.

Notre offre porte sur l’examen technique des systèmes web. Pour le volet organisationnel, nous pouvons vous aider à préparer des politiques de sécurité, mais nous ne certifions pas les entreprises et ne pilotons pas votre système de management de la sécurité de l’information (SMSI) à votre place ; cette limite mérite de figurer dans la commande. Si la mission comprend à la fois l’examen du site et l’évaluation du management de l’entreprise, convenez de la personne qui prépare les preuves techniques, de celle qui les compare aux exigences retenues et de celle qui assume l’évaluation finale. Sinon, vous risquez d’attendre de nous une évaluation des processus de management, et de l’auditeur organisationnel un test que vous n’avez pas commandé. Le volet organisationnel est généralement réalisé par un consultant en management de la sécurité de l’information ou un auditeur ISO/IEC 27001, tandis que le certificat est délivré par un organisme de certification.

Volet organisationnel : confronter les documents aux pratiques

Sur le papier, tout peut sembler parfait. Le volet organisationnel doit donc vérifier que les dispositions de la politique de sécurité ont un responsable, les ressources nécessaires et des preuves d’application, et que des actions sont prévues pour les problèmes relevés dans l’évaluation des risques ; le guide de l’ENISA pour les petites et moyennes entreprises couvre la responsabilité de la direction, l’implication et la formation des salariés, les politiques de sécurité, la gestion des fournisseurs, la protection des accès et le plan de réponse à incident. Complétez les entretiens avec la direction et les salariés par l’examen de documents et d’exemples concrets de pratiques, afin de distinguer les procédures prévues de leur application et de préciser les preuves que l’auditeur n’a pas pu obtenir et qui restent à préparer.

Sur les accès, un bon auditeur examine non seulement l’attribution des comptes, mais aussi leur désactivation, l’utilisation de l’authentification multifacteur (MFA) et les droits des fournisseurs. Il est donc utile d’inclure dans les exemples examinés le départ d’un salarié ou le remplacement d’un fournisseur : c’est précisément là que des comptes sont souvent oubliés. Il en va de même pour les sauvegardes : répondre « nous faisons des sauvegardes » ne dit pas grand-chose. Une sauvegarde dont personne n’a jamais testé la restauration peut se révéler incomplète lors d’un incident, alors que le site est déjà indisponible. L’inventaire des systèmes et des appareils doit avoir des responsables, les journaux d’événements une procédure d’examen, et le plan de réponse à incident une personne nommément désignée pour prendre les décisions et communiquer avec les parties concernées. Sinon, le plan reste un document que personne n’applique lors de l’incident.

Vous pouvez utiliser comme critères les exigences de la norme ISO/IEC 27001:2022, qui spécifie les exigences relatives à un système de management de la sécurité de l’information ; le mot « système » désigne ici le management, et pas seulement l’application examinée ; l’explication de la norme par BSI mentionne 93 mesures de sécurité de l’information et quatre domaines : organisationnel, humain, physique et technologique. Convenez des exigences que l’audit évaluera et des preuves utilisées : une référence à la norme dans un devis ne dit pas encore si vous commandez une évaluation du système de management ou un examen technique dont les résultats serviront ensuite dans un audit plus large ; consignez ce choix avant le début du travail.

Un autre référentiel est CIS Controls v8.1, avec 18 groupes de mesures, qui couvre des domaines allant de l’inventaire des actifs de l’entreprise aux tests d’intrusion et comprend au total 153 mesures de protection. CIS décrit le CIS Implementation Group 1 (IG1) comme les pratiques essentielles de cybersécurité, avec 56 mesures de protection. Précisez donc dans la commande le groupe choisi, et pas seulement le nom du référentiel. Demandez que le rapport relie chaque exigence évaluée à la preuve obtenue et à la faiblesse constatée, pour pouvoir vérifier exactement la même condition après les corrections, au lieu de comparer deux appréciations générales.

Quand la loi impose un audit de sécurité informatique

Au 29 octobre 2026, les statuts d’entité essentielle et d’entité importante de NIS2 ne sont pas encore en vigueur en France. Le projet de loi Résilience a été adopté par le Sénat le 12 mars 2025 puis en commission à l’Assemblée nationale le 10 septembre 2025, sans examen en séance publique à l’Assemblée ; la procédure en manquement engagée par la Commission européenne contre la France devant la Cour de justice de l’Union européenne, pour défaut de transposition de NIS2, est toujours en cours. Le Référentiel Cyber France (ReCyF) de l’ANSSI est un document de travail, non obligatoire par défaut. Pour une entreprise désignée opérateur de services essentiels (OSE) par le Premier ministre, la loi du 26 février 2018 permet à celui-ci d’imposer un contrôle du respect des obligations et du niveau de sécurité, sur pièces et sur place, même sans soupçon de manquement. Ce contrôle est réalisé par l’ANSSI ou par un prestataire d’audit de la sécurité des systèmes d’information qualifié par l’ANSSI (PASSI), choisi par l’opérateur sur la liste communiquée par l’ANSSI. Le PASSI ne doit avoir aucun lien de contrôle avec l’opérateur au sens des articles L. 233-1 et suivants du Code de commerce, ni être le prestataire ayant réalisé l’audit d’homologation. Un même système ne peut en principe faire l’objet de plus d’un contrôle imposé par année civile, sauf incident de sécurité sur ce système ou vulnérabilité ou manquement constaté lors d’un contrôle précédent. Les dirigeants encourent une amende de 100 000 € s’ils ne respectent pas les règles de sécurité à l’expiration du délai fixé par la mise en demeure, et de 125 000 € s’ils font obstacle au contrôle. Pour les systèmes visés à l’article L. 1332-6-1 du Code de la défense, les opérateurs d’importance vitale (OIV) relèvent d’un régime distinct : le contrôle demandé par le Premier ministre au titre de l’article L. 1332-6-3 est réalisé par l’ANSSI, un service de l’État qu’il désigne ou un prestataire qu’il qualifie. Le même plafond d’un contrôle par année civile d’un même système s’applique, sauf incident affectant leurs systèmes ou vulnérabilité ou manquement constaté lors d’un contrôle précédent. Ces contrôles se distinguent de l’audit d’homologation de l’opérateur, qui peut être réalisé en interne. Les coûts et la correction des manquements incombent à l’opérateur.

Le droit français n’impose pas d’autoévaluation de sécurité périodique à toutes les entreprises. Sans désignation comme OSE ou OIV, une entreprise n’a pas les obligations propres à ces statuts. Pour un OSE, l’arrêté du 14 septembre 2018 impose l’homologation de chaque système d’information essentiel (SIE). Sa validité doit être réexaminée au moins tous les trois ans et lors de tout événement ou changement modifiant le contexte du dossier ; l’homologation est renouvelée dès qu’elle n’est plus valide. Un audit est requis à l’homologation et à chaque renouvellement : il comprend notamment un audit d’architecture, un audit de configuration et un audit organisationnel et physique. L’opérateur ou le prestataire mandaté le réalise selon le référentiel d’audit prévu par le décret n° 2015-350. Le réexamen triennal n’équivaut donc pas à un audit automatique tous les trois ans, et cette règle n’impose pas de test d’intrusion. L’OSE transmet aussi à l’ANSSI une mise à jour annuelle de sa liste de SIE ; l’ANSSI invite à l’envoyer entre le 1er et le 30 novembre, une confirmation de validité suffisant en l’absence de changement. Cette déclaration n’est pas une autoévaluation de sécurité ; les indicateurs de sécurité sont transmis uniquement à la demande de l’ANSSI. Pour un OIV, l’homologation de chaque système d’information d’importance vitale suit l’arrêté de son secteur. L’audit est réalisé par une équipe interne ou un PASSI qualifié par l’ANSSI, conformément au référentiel PASSI. La périodicité dépend de cet arrêté : celui du 28 novembre 2016 pour l’industrie limite la validité à trois ans avant renouvellement, tandis que celui du 13 juillet 2020 pour la recherche publique prévoit un réexamen au moins tous les trois ans. Pour les entités financières autres que les microentreprises, le règlement DORA (UE) 2022/2554, directement applicable, impose des tests appropriés au moins une fois par an sur tous les systèmes et applications de TIC soutenant des fonctions critiques ou importantes ; les tests d’intrusion figurent parmi les méthodes du programme de tests. Les tests d’intrusion fondés sur la menace (TLPT), au moins tous les trois ans, concernent uniquement les entités identifiées par l’autorité compétente au titre de l’article 26, paragraphe 8, à l’exclusion des microentreprises et des entités visées à l’article 16, paragraphe 1, premier alinéa. L’autorité peut adapter cette fréquence. L’ACPR est compétente pour les entités relevant de son périmètre ; la BCE est l’autorité TLPT pour les établissements de crédit significatifs. La Banque de France, l’ACPR et l’AMF préparent ensemble les réponses françaises sur les TLPT. Une entreprise qui ne relève d’aucun de ces régimes n’est soumise à aucun de ces dépôts ni calendriers de tests. Face à une offre d’« audit obligatoire », demandez donc de préciser l’obligation concernée et votre statut, ainsi que la disposition précise qui la fonde : l’homologation selon l’arrêté du 14 septembre 2018 pour les OSE ou l’arrêté sectoriel pour les OIV, un contrôle notifié par le Premier ministre, ou l’article applicable de DORA. Distinguez l’audit d’homologation du contrôle imposé par l’autorité ; ni les futurs statuts NIS2 ni un objectif du ReCyF ne constituent à eux seuls une obligation actuelle.

Volet technique : des adresses publiques au code

Dans le cahier des charges technique, indiquez les adresses publiques, les enregistrements DNS, les services ouverts et les paramètres TLS, ainsi que la configuration du serveur ou de l’environnement cloud, les applications web et le code source dont vous autorisez l’examen. Pour chaque partie, précisez si le prestataire aura accès aux paramètres ou évaluera uniquement ce qui est visible de l’extérieur, car ce sont des missions différentes. Dans la classification des techniques de test de sécurité du NIST, l’examen des documents, des journaux et des configurations est distingué de l’identification et de l’analyse des cibles, ainsi que de la confirmation des vulnérabilités ; vous pouvez utiliser cette distinction pour décrire plus précisément, dans le devis, les méthodes choisies et le résultat attendu.

Pour les applications web, le Top 10 OWASP 2025 fournit un langage commun : dix catégories de risques, dont les deux premières sont les défaillances du contrôle d’accès et les mauvaises configurations de sécurité. La liste ne vérifie rien à elle seule ; un bon auditeur transforme chaque catégorie en question sur votre application. Pour le contrôle d’accès, cela consiste à tenter les actions d’un rôle avec le compte d’un autre rôle ; pour la conception non sécurisée, à choisir un processus métier dont les règles pourraient être contournées. Complétez la référence à l’OWASP par l’étendue des vérifications, afin que les deux parties sachent quelles fonctions et quels rôles utilisateur font réellement partie de la mission.

Pour la messagerie, prévoyez l’évaluation des paramètres SPF, DKIM et DMARC en reliant la mission aux systèmes depuis lesquels votre entreprise envoie ses messages : depuis le 1er février 2024, les exigences de Google pour les expéditeurs prévoient que tout expéditeur vers des comptes Gmail configure SPF ou DKIM, et que ceux qui envoient plus de 5 000 messages par jour configurent SPF, DKIM et DMARC. La politique DMARC peut être « none », mais, pour les envois directs, le domaine du champ From doit être aligné sur le domaine SPF ou DKIM. Demandez donc l’évaluation des paramètres et des circuits d’envoi que vous utilisez, sans vous limiter à constater la présence d’enregistrements de domaine.

Dans nos audits, le constat le plus fréquent est l’absence de mises à jour de PHP, du cœur du système de gestion de contenu et des frameworks. Nous recommandons donc d’inclure dans le cahier des charges technique un inventaire des versions, extensions et dépendances utilisées, et de demander que chaque constat précise le composant concerné et l’action nécessaire. Le développeur reçoit ainsi une tâche réalisable plutôt qu’une remarque générale sur un site obsolète. Si votre priorité est de savoir ce que les utilisateurs sont autorisés à faire dans le système, un inventaire des versions ne suffit pas : il faut aussi des tests de contrôle d’accès et des tests de logique métier. Nous avons rencontré des erreurs critiques permettant à n’importe quel utilisateur d’obtenir les droits d’administrateur, dont la correction a abouti à une réécriture complète du cœur du système ; un inventaire des versions n’aurait pas permis de découvrir une telle erreur.

La question des actions autorisées à un utilisateur diffère de celle des versions installées, et chacune nécessite ses propres preuves dans le rapport. Le NIST définit le scan de vulnérabilités comme une technique permettant d’identifier les hôtes, leurs caractéristiques et les vulnérabilités associées ; dans notre contrôle de sécurité automatisé, ce scan constitue une étape du travail technique. Le test d’intrusion, selon la définition du NIST, se caractérise par la simulation d’attaques réelles pour rechercher des possibilités de contournement des protections et, souvent, des combinaisons de vulnérabilités permettant d’élargir les accès. Nous détaillons le choix du test dans notre article sur le test d’intrusion ; pour la commande d’audit, il importe ici de préciser quelles faiblesses le prestataire se contentera de rechercher, lesquelles il tentera d’exploiter concrètement dans les limites convenues, et quelles actions seront volontairement exclues.

Comment se déroule l’audit, de la mission au contre-test

Commencez par une description écrite du champ de l’audit indiquant les systèmes, applications, adresses et rôles utilisateur à examiner, ainsi que les exclusions explicites. Ajoutez l’objectif et les limites du travail : les actions autorisées, l’environnement utilisé, la personne habilitée à interrompre les vérifications et le contact à joindre en cas d’imprévu. Pour un système de commandes, par exemple, convenez séparément de la manière de tester les actions qui créeraient autrement une véritable commande. Votre prestataire de maintenance doit également lire cet accord, afin que les actions autorisées, les accès et les interlocuteurs soient convenus avant le début du travail technique.

Avant le démarrage, préparez les documents et mobilisez les personnes à interroger selon les besoins de la mission : pour le volet organisationnel, les politiques, des exemples d’attribution d’accès, les comptes rendus de restauration des sauvegardes et le plan de réponse à incident ; pour le volet technique, une description du système et les accès convenus, en signalant aussi ce dont vous ne disposez pas encore. Si les vérifications portent sur une copie, notez ses différences avec le système utilisé au quotidien et convenez de la façon de les présenter dans le rapport. Le lecteur pourra ainsi comprendre à quel environnement les résultats s’appliquent et quelles questions restent ouvertes faute de documents, d’accès ou de disponibilité d’une fonction. Pour le travail technique, convenez de créneaux de test précis et des modalités de communication ; pour l’examen des documents, fixez à vos collègues une date limite pour apporter leurs précisions, afin de distinguer clairement les éléments vérifiés de ceux qui ne sont pas encore confirmés.

Si le prestataire découvre un problème important pendant la mission, demandez qu’il vous le signale selon les modalités convenues pendant que le reste du travail se poursuit, sans attendre la date de remise du rapport complet. Convenez aussi de la personne qui décide de poursuivre les tests sur le point concerné et de la manière de consigner les autorisations ou restrictions reçues : ces décisions seront nécessaires pour expliquer jusqu’où le constat a pu être confirmé.

Prévoir aussi le temps nécessaire aux corrections

L’audit réalisé avec notre système prend quelques jours, tandis que le travail d’audit manuel lui-même demande de 1 à 3 semaines selon le champ de l’audit. Un délai d’attente peut précéder son démarrage, selon la charge de travail de l’auditeur. La page du service indique une plage globale de réalisation de 1 à 60 jours ; ne considérez donc pas ces indications comme un délai garanti unique et convenez, avant la commande, de la date de démarrage, de la remise du rapport et du contre-test. Si un client ou un appel d’offres vous impose une date, prévoyez aussi du temps pour examiner et corriger les constats, ainsi que pour les réponses de votre équipe : la date de fin des vérifications et celle à laquelle vous souhaitez avoir corrigé les faiblesses sont deux échéances distinctes.

Notre offre d’audit manuel par un expert comprend un contre-test dans les 30 jours suivant les corrections. Pour qu’il soit utile, convenez à la remise du rapport de la personne qui corrige chaque constat, de celle qui signale la fin du travail et des preuves que le prestataire vérifiera à nouveau. Précisez séparément l’étendue et le paiement des corrections, car le prix de l’audit ne vaut pas accord pour tous les développements ultérieurs. Votre équipe peut effectuer les corrections, que nous vérifierons ensuite, ou vous pouvez nous les confier dans le cadre d’une mission distincte, chiffrée après le rapport. Dans le rapport de contre-test, demandez de distinguer les faiblesses corrigées, reportées et non encore vérifiées, et d’indiquer l’état du système utilisé, afin que votre équipe et le destinataire du rapport disposent d’une réponse commune et compréhensible pour chaque constat initial.

Que demander dans le rapport d’audit

Demandez en début de rapport une synthèse compréhensible par la direction, présentant l’objectif des vérifications, les systèmes couverts et les principaux constats. Elle doit permettre de décider des travaux et des ressources sans relire l’intégralité du contenu technique ; demandez que les limites de la mission y figurent aussi. Si le code source n’était pas disponible ou si un rôle utilisateur n’a pas été examiné, demandez de le dire explicitement, plutôt que de laisser le lecteur deviner ce que recouvre une appréciation succincte de l’état du système. Pour évaluer cette synthèse, vérifiez si votre dirigeant peut en tirer la prochaine décision à prendre, la personne responsable et une question encore sans réponse.

Pour chaque constat technique, demandez son emplacement dans le système, les circonstances de sa découverte, le rôle utilisateur employé, la procédure de reproduction et la preuve du résultat. Pour une non-conformité organisationnelle, demandez, outre la référence à l’exigence, le document ou l’exemple de pratique sur lequel repose l’évaluation. La recommandation de correction doit préciser ce qu’il faut modifier : remplacez donc une formule comme « corriger les accès » par les droits et la fonction précis que votre développeur doit modifier, en indiquant le comportement attendu après correction. Le rapport pourra ainsi servir à attribuer la tâche puis à vérifier son exécution, sans obliger chaque nouveau lecteur à réinterpréter l’intention de l’auditeur.

Si le rapport utilise le Common Vulnerability Scoring System (CVSS), demandez aussi d’en préciser la version : FIRST publie le CVSS, notamment sa version 4.0, dont les niveaux de gravité sont « nulle » (0,0), « faible » (0,1–3,9), « moyenne » (4,0–6,9), « élevée » (7,0–8,9) et « critique » (9,0–10,0) ; l’utilisation de ces libellés est facultative. À côté du score, demandez une justification et une explication concernant l’activité de votre entreprise : quelle opération ou quel ensemble de données est touché par le constat, par exemple, et pourquoi cet ordre de correction est recommandé. Vous pourrez ainsi discuter de la priorité à partir des circonstances décrites, et pas seulement d’un chiffre.

Nous utilisons notre expérience de ces erreurs critiques pour demander une description claire des conséquences, et non pour affirmer que chaque site doit être reconstruit : le rapport doit distinguer une correction ciblée d’un problème nécessitant de revoir le fonctionnement fondamental du système. Si le rapport préconise une refonte importante, demandez quelles preuves justifient cette recommandation, ce qui peut être corrigé séparément et quelle question restera sans réponse si l’entreprise ne retient qu’une partie des travaux proposés.

Demandez le fichier de résultats bruts du scanner en annexe si votre équipe technique en a besoin, mais conditionnez l’acceptation du rapport aux preuves, aux priorités et aux recommandations de correction réalisables attendues dans votre commande ; ne faites pas du nombre de lignes une mesure de qualité. Demandez au prestataire d’expliquer un constat du début à la fin : comment il a été établi, ce que le résultat prouve, en quoi il touche votre système et comment sa correction sera vérifiée après les modifications. Demandez-lui également de préciser tout ce qui reste une hypothèse dans cette conclusion ; cet examen fournit une base concrète pour accepter le rapport et répartir la suite du travail.

Pourquoi les prix des audits varient autant

Les prix diffèrent surtout parce que les offres couvrent un nombre de systèmes et une profondeur de travail différents : un scan automatisé et un inventaire des versions coûtent des centaines d’euros, tandis que des tests manuels de contrôle d’accès et de logique métier, un audit de code source et un contre-test nécessitent des journées de travail d’expert. Dans notre service d’audit de sécurité de site web, le contrôle de sécurité automatisé coûte 89–890 € selon le périmètre et s’adresse aux systèmes WordPress, Laravel, Drupal, Joomla et Moodle. L’offre comprend un scan automatisé de vulnérabilités, la vérification des versions, des extensions et des dépendances, l’évaluation de la configuration et des paramètres du serveur, ainsi qu’un rapport présentant les constats et les priorités. Utilisez ce contenu pour comparer le prix à celui d’une autre offre et précisez quelles installations seront examinées. Reliez le bas de la fourchette au périmètre convenu, afin de ne pas appliquer le prix de vérification d’un site à l’ensemble des systèmes de l’entreprise dont le prestataire n’a pas encore évalué les limites.

Notre audit manuel par un expert est proposé à partir de 3 500 € et comprend un examen manuel fondé sur le Top 10 OWASP, des tests de contournement du contrôle d’accès et des tests de logique métier, un audit de code source et un test d’intrusion autorisé. L’audit de code source est prévu pour Laravel, WordPress et les solutions développées sur mesure. Dans le rapport, nous classons les constats selon le risque réel et ajoutons à chacun une recommandation de correction ; l’offre comprend aussi un contre-test après les corrections. La mention « à partir de » reste valable même si votre système ne possède qu’une adresse publique, car le devis nécessite encore de convenir des fonctions, des rôles et du code à examiner.

Un contrôle complet réalisé avec notre système coûte généralement 500–800 €. C’est le montant que nous observons le plus souvent dans la fourchette de prix du contrôle de sécurité automatisé, et non un tarif distinct pour une évaluation combinée du management de l’entreprise, de tous ses systèmes et de la certification. Reliez donc le mot « complet » au champ technique précis dont nous sommes convenus. Pour la plupart des sites, nous recommandons un contrôle de sécurité automatisé régulier, que l’on peut répéter fréquemment, et un audit manuel par un expert lorsque le système traite des paiements ou des données personnelles, ou qu’il joue un rôle critique pour l’entreprise : seule une personne peut découvrir les erreurs de droits d’accès et les contournements de la logique métier. En pratique, un contrôle de sécurité automatisé régulier associé à un audit manuel annuel fonctionne bien.

Cette distinction facilite aussi la discussion budgétaire : si vous cherchez des réponses sur les composants et les paramètres du site, demandez un devis pour cette mission ; si la question principale concerne le contournement des droits utilisateur ou des règles métier, incluez les tests manuels correspondants et laissez le prestataire chiffrer ce travail séparément.

Pour comparer les offres, préparez une description identique des systèmes, applications et rôles utilisateur, ainsi que des sites d’activité de l’entreprise si le volet organisationnel est également nécessaire, puis demandez de distinguer les opérations automatisées des opérations manuelles. Imaginez un devis portant uniquement sur le site public et un autre portant sur le même site avec l’espace client, l’administration et le code source : avant de comparer les montants, précisez les limites de chaque offre. Pour chaque partie, consignez aussi les accès nécessaires, les critères de conformité retenus et le destinataire du rapport. Vous fournissez ainsi au prestataire une base concrète pour son devis et vous vous donnez les moyens de repérer une tâche omise.

Précisez séparément si le prix comprend l’explication des constats à votre développeur, leur rapprochement avec les exigences de la norme choisie et le contre-test, ainsi que la limite entre le travail d’audit et le développement des corrections. Lors de la préparation du budget d’audit, nous recommandons aussi de prévoir une décision concernant la correction des faiblesses constatées. Si les prix restent très différents pour des offres de même étendue, demandez aux prestataires d’expliquer le travail et ses limites à partir d’une fonction concrète, par exemple la modification des accès d’un utilisateur, plutôt qu’en ajoutant des noms de services. Vous pourrez ainsi choisir selon le résultat concret et les responsabilités, sans vous en remettre à une promesse de sécurité exhaustive.

Quand une entreprise a-t-elle besoin d’un audit de sécurité ?

Nous recommandons de commander un audit lorsque l’entreprise doit prendre une décision précise en matière de sécurité ou fournir une attestation vérifiable, en précisant dès le départ si la décision concerne le management, l’état technique ou les deux. Si la demande est liée à NIS2, déterminez d’abord votre statut et les exigences applicables, en vous aidant notamment de notre article sur NIS2 et son champ d’application, puis formulez la mission. L’ordre compte : précisez l’applicabilité des exigences et l’attestation nécessaire avant de choisir le service, pour éviter que la commande d’un rapport technique soit votre seule réponse à une question nécessitant aussi d’évaluer les responsabilités et les processus de l’entreprise. Si le site ne comporte ni comptes utilisateur, ni paiements, ni traitement de données personnelles, et si personne ne demande d’attestation, un audit étendu n’est généralement pas nécessaire : installez d’abord les mises à jour ; un contrôle de sécurité automatisé suffit.

Si les vérifications sont demandées par un assureur ou un client, faites préciser le résultat attendu et transmettez au prestataire le texte même de l’exigence. Distinguez, par exemple, une question sur la formation des salariés ou les tests de restauration des sauvegardes d’une demande de vérification des droits d’accès de l’application ; préparez les preuves adaptées aux réponses. Si un questionnaire fournisseur demande d’attester un processus de sécurité plus large que celui couvert par votre audit technique, convenez avec le client des informations complémentaires et désignez dans votre entreprise une personne chargée de les réunir, plutôt que d’élargir la portée du rapport technique. Précisez en même temps si le destinataire attend le rapport lui-même, des réponses à des questions précises ou une autre forme d’attestation, et à quelle échéance.

Pour un appel d’offres, conservez le type de vérification demandé et les conditions de qualification du prestataire exactement tels que l’acheteur les a formulés. Faites lever les ambiguïtés avant de demander un devis, afin de ne pas devoir réécrire l’offre après le démarrage. Nous examinons ce choix plus en détail dans notre article sur les vérifications de sécurité exigées dans un appel d’offres ; pour préparer le cahier des charges technique, vous pouvez nous transmettre la formulation de l’exigence et une description du système. Indiquez aussi la date de remise, la documentation disponible et la personne qui effectuera les corrections de votre côté : la discussion sur la réalisation des vérifications doit couvrir la préparation du rapport et la capacité de votre équipe à exploiter ses résultats avant la date requise.

Après un incident et entre les vérifications planifiées

Après un incident, nous recommandons d’adapter la mission d’audit à la question précise encore sans réponse : la correction résout-elle le problème constaté, faut-il rechercher une erreur d’accès similaire dans une autre fonction, et comment l’entreprise vérifiera-t-elle ensuite l’application de la procédure concernée ? Transmettez au prestataire la description des événements connus et distinguez les faits confirmés des hypothèses. Si vous souhaitez reconstituer le déroulement des faits, désignez aussi ce travail séparément et convenez de son résultat, sans supposer qu’un audit général du site répondra automatiquement à toutes les questions liées à l’incident. Pour les corrections à vérifier, conservez le lien avec les constats initiaux, afin de pouvoir préciser après les modifications quel problème a été revérifié et comment.

Nos clients commandent généralement un audit une ou deux fois par an ; il s’agit d’une observation tirée de notre expérience, et non d’un intervalle fixé pour toutes les entreprises. Dans votre planning, nous recommandons d’inscrire, à côté de la prochaine date, les changements qui déclencheront une réévaluation de l’étendue des vérifications : un nouveau rôle utilisateur, une fonction d’accès réécrite ou le remplacement d’un fournisseur disposant de droits dans le système, par exemple. Confiez à la personne responsable la comparaison de ces changements avec le champ de l’audit précédent et la proposition d’une partie précise à examiner. Conservez dans la mission suivante les constats non résolus du rapport précédent et les décisions de report correspondantes, afin que les nouvelles vérifications partent de la situation connue.