Les deux prestations sont vendues côte à côte, souvent au même prix, et beaucoup d’acheteurs les considèrent comme interchangeables. Elles ne le sont pas : elles répondent à des questions différentes et ne trouvent pas les mêmes choses.
Le test d’intrusion : que verrait un attaquant ?
On adopte le point de vue offensif. On part de l’extérieur, ou d’un accès limité, et on cherche un chemin. Le résultat est une démonstration : voici comment on est entré, voici jusqu’où on est allé.
Ce qu’il trouve bien : les chemins d’attaque réels, les enchaînements de faiblesses mineures qui, combinées, donnent un accès majeur. C’est ce qu’aucune revue documentaire ne révèle.
Ce qu’il rate : tout ce qui n’était pas sur le chemin emprunté. Un test réussi s’arrête souvent dès qu’un accès administrateur est obtenu — le reste du périmètre n’est jamais regardé.
L’audit de configuration : le paramétrage est-il conforme ?
On regarde de l’intérieur, avec les accès nécessaires. On compare la configuration réelle à un référentiel : recommandations de l’éditeur, guides de l’ANSSI, exigences internes.
Ce qu’il trouve bien : l’exhaustivité sur le périmètre examiné. Chaque paramètre est vérifié, y compris ceux qu’un attaquant n’aurait pas exploités cette fois-ci.
Ce qu’il rate : la mise en perspective. Deux cents écarts listés sans hiérarchie ne disent pas lequel aurait permis une compromission.
Dans quel ordre
La règle que nous appliquons dépend de la maturité.
Maturité faible — pas de politique de durcissement, pas d’inventaire fiable : commencez par l’audit de configuration. Un test d’intrusion trouvera tellement de chemins que le rapport n’aidera pas à prioriser. Vous paierez cher pour apprendre que tout est ouvert.
Maturité correcte — durcissement appliqué, correctifs suivis : le test d’intrusion apporte davantage. Il révèle ce que la conformité aux référentiels ne couvre pas, notamment les enchaînements et la logique applicative.
Contexte réglementaire : l’audit de configuration produit une preuve documentaire directement utilisable. Le test d’intrusion produit une démonstration, plus convaincante en comité de direction.
Le cas particulier de l’audit organisationnel
Une troisième prestation, souvent oubliée : l’examen des processus. Gestion des habilitations, des changements, des incidents, des prestataires.
C’est là que se trouvent les causes de la plupart des écarts techniques. Un serveur mal configuré est un symptôme ; l’absence de procédure de mise en service en est la cause. Corriger le symptôme sans la cause garantit de le retrouver l’année suivante.
Ce que dit le cadre normatif
La mesure 8.8 d’ISO/IEC 27002:2022 sur la gestion des vulnérabilités techniques n’impose aucune des deux prestations en particulier. Elle demande d’obtenir l’information, d’évaluer l’exposition et d’agir.
Un auditeur de certification acceptera l’une ou l’autre, à condition que les résultats soient suivis d’effet. Un rapport sans plan d’action daté ne prouve rien.
Ce qu’il faut exiger dans les deux cas
- Un périmètre écrit, avec ce qui est exclu.
- Une priorisation qui tient compte de votre contexte, pas seulement d’un score — voir pourquoi le CVSS ne suffit pas.
- Des preuves reproductibles.
- Une contre-vérification après correction.
Ces exigences sont détaillées dans notre article sur ce que doit contenir un rapport.
Ce que ni l’un ni l’autre ne trouvera
Les deux prestations partagent des angles morts qu’il vaut mieux connaître avant de considérer un périmètre comme couvert.
- Ce qui n’était pas allumé le jour du test. Une application arrêtée pour maintenance, un environnement de secours, un site distant fermé : ils sortent du périmètre de fait, sans que le rapport le mentionne toujours.
- Les chaînes qui traversent plusieurs domaines. Un test cantonné à une application ne verra pas qu’une faiblesse mineure chez elle devient critique combinée à un droit excessif dans l’annuaire. Le découpage en lots par prestataire reproduit ce cloisonnement dans les résultats.
- Les usages détournés. Un utilisateur légitime qui exporte massivement des données auxquelles il a droit ne constitue une anomalie ni pour un test d’intrusion, ni pour un audit de configuration. C’est un sujet de détection et de revue des droits.
- Ce qui change la semaine suivante. Les deux prestations produisent une photographie. Dans un environnement où les déploiements sont hebdomadaires, sa durée de validité est courte — argument en faveur de contrôles automatisés continus en complément, pas en remplacement.
Ce qui fait varier le prix du simple au triple
À intitulé identique, les propositions s’écartent fortement. Trois paramètres expliquent l’essentiel de l’écart, et ce sont ceux à fixer vous-même pour comparer des offres comparables.
Le niveau d’information fourni. Un test en aveugle consomme une part importante du temps en reconnaissance — du temps qui n’est pas passé à chercher des vulnérabilités. Fournir l’architecture, les comptes de test et le code source déplace l’effort vers la recherche. Pour un premier test, l’approche en aveugle a une valeur de démonstration ; pour les suivants, elle coûte cher en résultats perdus.
La profondeur d’exploitation. Identifier une faiblesse et démontrer son impact réel par une chaîne complète sont deux niveaux d’effort très différents. Le second convainc une direction générale ; le premier tient en une ligne de rapport.
La contre-vérification. Le retour du prestataire après correction, pour valider que le correctif tient, est fréquemment optionnel — et fréquemment supprimé pour tenir le budget. C’est la ligne à conserver en priorité : un correctif non vérifié n’a pas de statut.
L’erreur de calendrier la plus fréquente
Commander un test d’intrusion trois semaines avant une échéance de certification ou une réponse à appel d’offres met l’organisation dans une position difficile : les constats arrivent trop tard pour être corrigés, et trop tôt pour être ignorés.
Le bon séquencement est l’inverse : le test se place suffisamment en amont pour que le délai de correction — six à douze semaines pour des sujets d’architecture — tienne avant l’échéance. Un rapport daté de neuf mois accompagné d’un plan d’action suivi vaut mieux, devant un auditeur comme devant un client, qu’un rapport récent dont rien n’a été traité.
Sources
- ISO/IEC 27002:2022, mesure 8.8
- ANSSI — guides de recommandations de configuration
- OWASP Web Security Testing Guide
Aller plus loin
Nous menons les trois types de missions : tests d’intrusion, audits de configuration et audit 360 couvrant technique, organisationnel et humain.