Scan de vulnérabilités vs test d'intrusion : lequel choisir ?

Le scan de vulnérabilités et le test d’intrusion répondent à deux questions différentes, donc pour la plupart des organisations la réponse honnête est qu’il vous faut les deux. Un scan de vulnérabilités demande « quelles faiblesses connues sont présentes sur mes systèmes ? » et y répond automatiquement, largement et souvent. Un test d’intrusion demande « un attaquant peut-il réellement enchaîner ces faiblesses jusqu’à une compromission ? » et y répond à la main, sur un périmètre restreint et en profondeur. Si vous ne pouvez en financer qu’un seul pour l’instant, c’est l’objectif qui tranche : une couverture continue des failles connues oriente vers le scan, une preuve d’exploitabilité réelle oriente vers le test d’intrusion.

On confond souvent les deux parce que tous deux produisent une liste de constats notés par gravité. La différence tient au sens de ces constats. Un scanner signale ce qui pourrait être exploitable. Un test d’intrusion rapporte ce qui a été exploité, par une personne, dans votre environnement.

Scan de vulnérabilités vs test d’intrusion en un coup d’œil

Dimension	Scan de vulnérabilités	Test d’intrusion
Question centrale	Quelles failles connues sont présentes ?	Un attaquant peut-il entrer, et jusqu’où ?
Méthode	Outils automatisés, comparaison signatures/versions	Test manuel par un testeur, outillé au besoin
Couverture	Large : tous les actifs du périmètre	Profonde : un périmètre choisi, enchaîné de bout en bout
Résultat	Une liste classée de faiblesses potentielles	Un chemin d’attaque validé, preuve et impact à l’appui
Faux positifs	Fréquents, tri humain nécessaire	Rares : les constats sont démontrés
Cadence	Continue ou planifiée, tourne en minutes	Périodique, s’étale sur des jours ou des semaines
Trouve l’inconnu	Non : seulement les problèmes connus, catalogués	Oui : failles de logique, chaînées, de code spécifique

Les organismes de normalisation les traitent comme des techniques distinctes, pas interchangeables. NIST SP 800-115, le guide fédéral des tests de sécurité, documente le scan de vulnérabilités et le test d’intrusion comme deux activités séparées dans son catalogue de méthodes d’évaluation, et cette séparation se retrouve dans les cadres de conformité qui imposent chacun selon son propre calendrier.

Ce que fait le scan de vulnérabilités

Un scanner de vulnérabilités inventorie ce qui tourne sur un hôte ou un réseau, puis compare chaque composant à une base de problèmes connus : versions de paquets obsolètes, correctifs manquants, configurations faibles, services exposés. La correspondance est mécanique. Si le scanner voit Apache dans une version porteuse d’une faille publiée, il signale cette faille.

Les forces découlent de ce mécanisme :

• L’ampleur. Un scan couvre tous les actifs que vous lui indiquez, pas un échantillon. Rien dans le périmètre n’est laissé de côté faute de temps.
• La rapidité et la répétabilité. Un scan tourne en minutes ou en heures et applique les mêmes contrôles à chaque fois, ce qui permet de le lancer en continu et d’en suivre la tendance.
• Un coût par exécution faible. Une fois configuré, le scan est assez bon marché pour tourner chaque semaine ou chaque jour.

Les limites en découlent tout aussi directement. Un scanner ne connaît que le contenu de sa base : il trouve des problèmes connus dans des logiciels connus, et rien d’autre. Il ne comprend pas votre logique métier, il ne sait pas dire si un panneau d’administration exposé est réellement atteignable depuis Internet, et il produit des faux positifs qu’un humain doit ensuite trier. Un scan vierge signifie « aucune faille cataloguée détectée », pas « sécurisé ».

Ce que fait le test d’intrusion

Un test d’intrusion, c’est une personne, autorisée et cadrée, qui tente de compromettre vos systèmes comme le ferait un attaquant. Les outils l’assistent, mais le travail est guidé par le jugement : sonder, enchaîner de petites faiblesses, s’adapter quand survient l’inattendu. NIST SP 800-115 le présente comme la technique qui dépasse l’identification des faiblesses pour réellement les exploiter, généralement selon une séquence de phases reconnaissable : planification, découverte, attaque et restitution.

Cette approche pratique trouve ce que les scanners ne peuvent structurellement pas voir :

• Les failles de logique métier. Un panier qui accepte une quantité négative, une API qui fait confiance à un identifiant d’utilisateur fourni par le client. Aucune signature n’existe pour cela.
• Les chaînes. Une fuite d’information mineure, plus un identifiant par défaut, plus un compte de service surdoté en droits, deviennent une compromission complète. Chaque maillon paraît anodin à un scanner ; la chaîne est critique.
• L’exploitabilité réelle. Un testeur prouve si un constat « critique » est réellement atteignable et ce qu’il rapporte, ce qui tranche dans le bruit des faux positifs laissé par un scanner.

La contrepartie, c’est la couverture et la cadence. Un test d’intrusion examine un périmètre défini sur une fenêtre fixe : c’est un instantané profond, pas une surveillance continue, et le lendemain de sa clôture une nouvelle CVE ou un nouveau déploiement peut ouvrir une brèche qu’il n’a jamais vue.

Lequel vous faut-il ?

Partez du résultat que vous achetez, pas de l’étiquette.

Il vous faut un scan de vulnérabilités quand l’objectif est de garder une vue large et à jour de l’exposition connue : quels actifs manquent de correctifs, font tourner des logiciels en fin de vie ou s’écartent d’une configuration durcie. De nouvelles failles sont publiées chaque jour, donc cela ne fonctionne qu’en continu. Le scan est aussi la couche qui rattrape la régression qu’un test d’intrusion ne peut pas voir, parce que le test a eu lieu le trimestre dernier et que le paquet vulnérable a été déployé la semaine dernière.

Il vous faut un test d’intrusion quand l’objectif est la validation : la preuve qu’un attaquant ne peut pas transformer vos expositions en compromission, ou une démonstration, pour un client, un auditeur ou un conseil d’administration, que quelqu’un de compétent a essayé et documenté ses trouvailles. C’est aussi le seul moyen pratique de faire émerger les failles sans signature, les problèmes de logique et les chaînes qui composent une large part des incidents réels.

La conformité tranche souvent à votre place en imposant les deux selon des calendriers fixes. PCI DSS v4.0 en est l’exemple le plus net : elle impose des scans de vulnérabilités internes et externes au moins une fois tous les trois mois (exigences 11.3.1 et 11.3.2, avec un nouveau scan après tout changement significatif), et un test d’intrusion au moins une fois tous les douze mois et après tout changement significatif (exigence 11.4). Le cadre les traite délibérément comme deux contrôles séparés, parce que réussir l’un ne dit rien de l’autre.

Pourquoi la plupart des équipes ont besoin des deux

L’argument pour faire les deux n’est pas la redondance, c’est la couverture de modes de défaillance différents sur des échelles de temps différentes. Le scan fournit le balayage large et continu ; le test d’intrusion fournit la validation profonde et périodique. Supprimez l’un et une brèche prévisible s’ouvre.

Les données sur la menace plaident pour davantage d’attention au scan, pas moins. Dans le rapport Verizon 2026 sur les compromissions de données (DBIR), les vulnérabilités logicielles sont devenues le premier vecteur d’accès initial : 31 % des compromissions commencent ainsi, devant les identifiants volés. Cela fait suite au rapport de l’année précédente, qui enregistrait une hausse de 34 % de l’exploitation comme point d’entrée et constatait que l’intérêt des attaquants pour les équipements de périmètre et les VPN passait de 3 % à 22 % des cibles. Les failles connues, donc scannables, sont de plus en plus la porte d’entrée des attaquants.

Le même rapport 2025 montre pourquoi le scan seul ne suffit pas non plus : les organisations mettaient une médiane d’environ 32 jours pour corriger entièrement leurs failles, et une moyenne d’environ 209 jours tous périmètres confondus, alors que les attaquants exploitaient les nouveaux problèmes en cinq jours environ après leur divulgation. Le scan fait apparaître la faille ; il ne prouve pas que vous l’avez refermée, et il ne teste pas si la moitié que vous n’avez pas encore corrigée est réellement atteignable. C’est cette validation que fournit un test d’intrusion, et c’est pourquoi un correctif marqué « fait » par un scanner mérite encore un nouveau test.

Un attelage viable pour une petite équipe ressemble à ceci :

1. Faites tourner un scan de vulnérabilités en continu comme couche permanente. Le scan de vulnérabilités en continu de CloudKey croise chaque nouvelle CVE avec votre inventaire d’actifs réel et classe le résultat selon les preuves d’exploitation, pour que la sortie quotidienne soit une courte liste plutôt qu’un rapport de mille lignes. (Si vous ne savez pas comment lire ce classement, notre guide CVSS vs EPSS vs KEV le détaille.)
2. Planifiez des tests d’intrusion périodiques comme couche de validation, au moins une fois par an et après tout changement significatif, pour prouver l’exploitabilité et trouver les inconnues que le scan rate. Les tests d’intrusion CloudKey incluent un nouveau test de chaque correctif à chaque engagement.

Le scan réduit le champ à ce qui est connu et présent ; le test d’intrusion confirme ce qui est réellement dangereux. Ensemble, ils ferment à la fois la brèche d’ampleur et la brèche de profondeur. Séparés, l’une des deux reste ouverte.

Questions rapides

Un test d’intrusion, n’est-ce qu’un scan automatisé ? Non. Un scan est exécuté par un logiciel contre une base de signatures ; un test d’intrusion est mené par une personne qui tente d’exploiter et d’enchaîner les faiblesses, y compris des failles sans signature. Beaucoup de tests d’intrusion débutent par un scan, mais la valeur réside dans le travail manuel qui suit.

Un scan de vulnérabilités peut-il remplacer un test d’intrusion ? Non, et l’inverse est tout aussi faux. Un scan couvre l’ampleur et tourne en continu, mais ne trouve que des problèmes connus et produit des faux positifs. Un test d’intrusion valide l’exploitabilité réelle et trouve l’inconnu, mais seulement sur un périmètre défini à un instant donné. Ils couvrent des brèches différentes.

À quelle fréquence faut-il faire chacun ? Le scan devrait être continu, ou au moins mensuel, car de nouvelles failles paraissent chaque jour. Le test d’intrusion est périodique : PCI DSS, par exemple, l’exige au moins une fois tous les douze mois et après tout changement significatif. Calez la cadence sur votre rythme de changement et vos obligations de conformité.

Lequel coûte le plus cher ? Le test d’intrusion, et de loin par engagement, car c’est un travail manuel qualifié sur des jours ou des semaines. Le scan est bon marché à répéter une fois configuré. Les deux budgets ne sont pas interchangeables, car ils achètent des choses différentes.

Un scan de vulnérabilités vierge signifie-t-il que je suis sécurisé ? Non. Il signifie qu’aucune faille cataloguée n’a été détectée dans les logiciels que le scanner reconnaît. Il ne dit rien des failles de logique métier, des erreurs de configuration que le scanner ne peut atteindre, des problèmes de code spécifique, ni de l’exploitabilité réelle d’un constat. Voyez un scan vierge comme un plancher, pas comme un verdict.

Si je ne peux en financer qu’un cette année, lequel ? Décidez par l’objectif. Si vous n’avez aucune vue actuelle de votre exposition connue, commencez par un scan continu, puisque les attaquants entrent de plus en plus par ces failles connues. Si vous scannez déjà mais n’avez jamais fait prouver par un tiers indépendant si vos expositions sont exploitables, ou qu’un auditeur l’exige, réservez le test d’intrusion.