Tests D'intrusion UK - Ce Qu'attendre en 2026

Les recherches de services de tests d’intrusion au Royaume-Uni ont augmente de plus de 35 % entre 2023 et 2025, portees par une combinaison d’incidents de ransomware, d’obligations reglementaires de plus en plus strictes et d’une vague d’assureurs exigeant des preuves de tests de securite actifs avant d’emettre des polices cyber. Malgre cette demande, il subsiste une grande confusion sur ce qu’est reellement un test d’intrusion, en quoi il differe d’une analyse de vulnerabilites, et ce que cela coute correctement.

Ce guide couvre l’ensemble du tableau : ce que les tests d’intrusion sont et ne sont pas, les principaux types, le deroulement du processus, ce que les resultats doivent contenir, quelles certifications comptent au Royaume-Uni, et des fourchettes de couts realistes pour 2026.

En resume

• Un test d’intrusion est une simulation d’attaque par un testeur autorise utilisant les memes techniques que de vrais attaquants. Ce n’est pas la meme chose qu’une analyse de vulnerabilites, qui est automatisee et ne peut pas chainer les vulnerabilites ni evaluer l’impact reel.
• Les testeurs chainent plusieurs vulnerabilites pour demontrer l’impact reel, pas simplement lister les problemes individuels. C’est ce qui rend la methodologie distincte et precieuse.
• Au Royaume-Uni, PCI DSS impose des tests d’intrusion annuels, et l’article 32 du RGPD britannique, ISO 27001 et les recommandations du NCSC pointent tous vers des tests d’intrusion reguliers comme preuve de controles techniques adequats.
• Pour les prestataires accredites CREST, recherchez les qualifications CRT (application web), CCT App (application web) ou CCT Inf (infrastructure). Pour les travaux dans le secteur public, le schema CHECK s’applique.

Ce qu’est un test d’intrusion (et ce qu’il n’est pas)

Un test d’intrusion est une simulation structuree et autorisee d’une attaque contre une cible definie. Le testeur utilise les memes outils, techniques et processus de pensee qu’un attaquant malveillant, mais opere dans un perimetre et des regles d’engagement convenus. L’objectif est d’identifier les vulnerabilites et de demontrer leur exploitabilite dans le monde reel avant qu’un veritable attaquant ne le fasse.

Une analyse de vulnerabilites n’est pas un test d’intrusion. Un scanner automatise interroge les systemes par rapport a une base de donnees de vulnerabilites connues et produit une liste de resultats. Il est rapide et repetable, mais il ne peut pas raisonner sur le contexte, enchainer des resultats, evaluer la logique metier, ni demontrer l’impact reel de ce qu’il trouve. De nombreuses organisations confondent les deux, et certains fournisseurs brouillent deliberement la limite. Si un fournisseur vous fait un devis pour des “tests d’intrusion” et que la mission repose entierement sur un outil sans analyse manuelle, vous avez achete une analyse de vulnerabilites a prix premium.

La distinction importe concretermement. Une analyse de vulnerabilites pourrait signaler que votre application a un formulaire de connexion sans verrouillage de compte. Un test d’intrusion va plus loin : le testeur tente d’exploiter cela en combinaison avec une faille d’enumeration de noms d’utilisateur et un jeton de session previsible pour demontrer une chaine de prise de controle complete du compte. C’est la difference entre lister un risque et le prouver.

Types de tests d’intrusion

Par niveau de connaissance. Les tests sont typiquement decrits comme boite noire, boite grise ou boite blanche, selon la quantite d’informations fournie au testeur au depart :

• Boite noire : le testeur commence sans connaissance prealable de la cible, simulant un attaquant externe qui a effectue sa propre reconnaissance. Le plus proche d’un scenario d’attaque reel mais peut etre inefficace en termes de temps car le testeur passe du temps d’engagement sur des taches (comme la cartographie de l’application) que vous pourriez fournir.
• Boite grise : le testeur recoit certaines informations, generalement des identifiants utilisateur et de la documentation, mais pas le code source ni les diagrammes d’architecture complets. Le choix le plus courant pour les tests d’applications web car il equilibre realisme et efficacite.
• Boite blanche : le testeur dispose d’un acces complet incluant le code source, la documentation d’architecture et les diagrammes d’infrastructure. Utilise pour les evaluations completes et les revues de code portees par la conformite. Trouve la plus grande proportion de vulnerabilites mais necessite le plus de preparation de votre equipe.

Par type de cible. Les categories courantes incluent :

• Test d’intrusion reseau : infrastructure externe ou interne, regles de pare-feu, configuration VPN, possibilites de mouvement lateral
• Test d’intrusion d’application web : OWASP Top 10 et au-dela, y compris l’authentification, la gestion des sessions, la validation des entrees et la logique metier
• Test d’intrusion API : endpoints REST et GraphQL, contournement d’authentification, affectation de masse, limitation de debit et exposition de donnees
• Test d’intrusion d’application mobile : applications Android et iOS, stockage de donnees non securise, contournement de l’epinglage de certificat et problemes d’API backend exposes via la couche mobile
• Ingenierie sociale : simulation de phishing, pretexting et vishing (phishing vocal) pour tester votre couche humaine
• Test d’intrusion physique : tailgating, clonage RFID, contournement du controle d’acces, ciblage des locaux physiques

La plupart des entreprises britanniques commencent par un test d’application web ou reseau et elargissent la portee a mesure que leur programme de securite muri.

Le processus de test d’intrusion

Un test d’intrusion rigoureux suit une methodologie definie. Les frameworks CREST et PTES (Penetration Testing Execution Standard) decrivent tous deux une sequence similaire :

Perimetre et regles d’engagement

Avant le debut des tests, vous et le prestataire convenez de la cible, du type de test, des fenetres de test (certaines organisations exigent des tests en dehors des heures de bureau pour eviter un impact sur la production), des procedures d’escalade en cas de decouverte d’un resultat critique en cours de test, et de ce qui est explicitement hors perimetre. Obtenez cela par ecrit. Une lettre d’autorisation protege les deux parties.

Reconnaissance

Le testeur rassemble des informations sur la cible par des moyens passifs (renseignement en sources ouvertes, journaux de transparence des certificats, offres d’emploi revelant la pile technologique, identifiants fuitees dans des bases de donnees de violations) et des moyens actifs (enumeration DNS, scan de ports, empreinte de services). Dans un test en boite noire, cette phase peut occuper une part significative du temps d’engagement.

Exploitation

Le testeur tente d’exploiter les vulnerabilites identifiees pour obtenir un acces initial ou demontrer un impact. C’est la que la methodologie diverge du scanning : un testeur qualifie essaie plusieurs voies, s’adapte quand un chemin est bloque, et cherche des combinaisons de problemes de moindre gravite qui produisent ensemble un resultat a fort impact.

Post-exploitation et enchainement de vulnerabilites

C’est la phase que la plupart du marketing des fournisseurs ignore. Apres avoir obtenu un acces initial, que peut reellement faire un attaquant ? Un testeur evaluant une application web pourrait enchainer une vulnerabilite XSS avec une faille CSRF et un identifiant de session previsible pour demontrer une prise de controle complete du compte. Sur l’infrastructure, la post-exploitation implique l’escalade de privileges, le mouvement lateral et la determination des donnees ou systemes accessibles depuis le point d’appui initial.

L’enchainement est crucial car il recadre le risque. Un resultat individuel note CVSS 5.5 (Moyen) devient une conversation differente quand vous pouvez montrer qu’il est exploitable en combinaison avec deux autres pour exfiltrer votre base de donnees clients.

Rapport

Le testeur documente tous les resultats, redige le rapport et le livre dans le delai convenu (generalement cinq a dix jours ouvrables apres la fin des tests). Ce que le rapport contient est couvert dans la section suivante.

Ce que contient un rapport de test d’intrusion de qualite

Un rapport professionnel de test d’intrusion est un document de travail pour votre equipe, pas un outil de vente pour le prestataire. Il doit contenir :

Resume executif. Un apercu non technique de la mission, la posture de risque globale, le nombre et la gravite des resultats, et les problemes les plus critiques. Redige pour un lecteur de niveau direction qui doit prendre des decisions, pas un developpeur qui doit corriger du code.

Perimetre et methodologie. Ce qui a ete teste, comment ca a ete teste, et toute limitation (par exemple, si certaines URL ont ete exclues ou si les tests etaient limites aux heures de bureau).

Resultats classes par risque. Chaque vulnerabilite listee avec une cote de gravite. La plupart des prestataires britanniques professionnels utilisent des scores CVSS 3.1 aux cotes d’une cote de risque contextuelle qui tient compte de votre environnement specifique. Un score CVSS isole peut induire en erreur ; un resultat 7.5 sans vecteur d’acces externe est un risque different du meme score sur un endpoint accessible au public.

Details techniques et etapes de reproduction. Suffisamment d’informations pour que vos developpeurs reproduisent le resultat, comprennent pourquoi il est exploitable, et confirment que leur correctif fonctionne. Cela signifie : requetes et reponses exactes, charges utiles utilisees, captures d’ecran si utile.

Guide de remediation. Conseils specifiques et actionnables pour chaque resultat. Pas “mettez a jour vos dependances” mais “mettez a jour la bibliotheque X de la version 2.3.1 a 2.4.0 et supprimez l’appel de serialisation obsolete a la ligne 247 de UserController.php.”

Declaration de retest. Confirmation de l’inclusion ou non d’un retest, et si oui, comment les resultats seront clos. Un resultat n’est pas resolu tant qu’un testeur ne le confirme pas.

Obligations de conformite britanniques pour les tests d’intrusion

PCI DSS. Toute entreprise qui traite, stocke ou transmet des donnees de titulaires de carte doit effectuer des tests d’intrusion au moins annuellement et apres tout changement significatif d’infrastructure ou d’application. PCI DSS v4.0, devenu la seule version active en mars 2024, inclut des exigences mises a jour pour le perimetre et la methodologie des tests d’intrusion. C’est une exigence obligatoire, pas une recommandation.

RGPD britannique Article 32. Oblige les organisations a mettre en oeuvre des mesures techniques appropriees pour assurer une securite adaptee au risque. Les tests d’intrusion sont le moyen le plus direct de demontrer que vous avez activement evalue si vos controles techniques fonctionnent. L’ICO a reference les tests de securite dans des decisions d’execution.

ISO 27001. Le controle 8.8 de l’annexe A couvre la gestion des vulnerabilites techniques, et les tests d’intrusion sont une methode standard pour satisfaire ce controle. Si vous visez la certification ISO 27001, votre auditeur s’attendra a voir des preuves de tests.

Cyber Essentials Plus. Le niveau superieur du schema Cyber Essentials du gouvernement britannique inclut une evaluation sur site et un scan de vulnerabilites. Bien que Cyber Essentials Plus ne soit pas un test d’intrusion, l’obtenir et maintenir la base qu’il etablit est un prerequis sense.

Recommandations du NCSC. Le National Cyber Security Centre recommande les tests d’intrusion dans le cadre de son referentiel “10 etapes pour la cybersecurite”, specifiquement sous les etapes “Gestion des vulnerabilites” et “Securite reseau”.

Certifications CREST et pourquoi elles comptent

CREST est le principal organisme d’accreditation britannique pour les entreprises de tests d’intrusion et les testeurs individuels. Les prestataires enregistres CREST sont evalues sur leurs processus, leur methodologie et leur capacite a traiter les donnees sensibles de maniere appropriee. Les testeurs individuels peuvent detenir les qualifications suivantes :

• CREST Registered Tester (CRT) : certification de niveau entree demontrant une competence technique dans les tests d’application web ou d’infrastructure.
• CREST Certified Tester - Application (CCT App) : certification avancee pour les tests d’intrusion d’applications web. Requiert la reussite d’un examen pratique.
• CREST Certified Tester - Infrastructure (CCT Inf) : certification equivalente pour les tests reseau et infrastructure.

Pour les organismes publics britanniques, le schema CHECK s’applique. CHECK est un schema gere par le NCSC exigeant que les testeurs d’intrusion detiennent le statut CHECK Team Member ou CHECK Team Leader. Si vous etes un departement gouvernemental, un organisme NHS ou une autorite locale, votre prestataire doit detenir le statut CHECK.

Lors de l’evaluation des prestataires, demandez a voir les certifications specifiques detenues par les testeurs qui travailleront sur votre mission, pas les certifications detenues par les membres seniors de l’equipe de l’entreprise. La personne qui redige votre rapport et effectue votre test est la certification qui compte.

A quelle frequence devriez-vous tester ?

La bonne reponse depend de votre profil de risque, mais les minimums pratiques sont :

• Annuellement au minimum pour toute application exposee sur internet traitant des donnees personnelles ou de paiement
• Apres les versions majeures qui introduisent de nouvelles fonctionnalites, de nouveaux flux d’authentification ou de nouvelles integrations
• Avant la mise en production avec un nouveau produit, application ou service qui traitera des donnees personnelles ou de paiement pour la premiere fois
• Apres un incident de securite, pour comprendre si l’attaquant a laisse des mecanismes de persistance ou exploite des vulnerabilites qui n’ont pas encore ete fermees
• Quand votre profil de risque change, par exemple apres une fusion, une acquisition ou une expansion significative de votre base d’utilisateurs

Couts des tests d’intrusion au Royaume-Uni

Les tarifs refletent les prix du marche britannique en 2026. Les devis nettement inferieurs a ces fourchettes indiquent generalement un scan automatise avec une analyse manuelle minimale.

Le service de test d’intrusion Mecanik couvre les tests d’applications web, d’API et d’infrastructure pour les entreprises britanniques, en utilisant la methodologie PTES et OWASP, avec des exploits de preuve de concept et un rapport de remediation priorise.

Points cles

• Un test d’intrusion est une simulation manuelle et autorisee d’une attaque. Il est categoriquement different d’un scan de vulnerabilites automatise.
• Les testeurs chainent plusieurs vulnerabilites pour demontrer un impact reel, pas simplement enumerer les problemes individuels de facon isolee.
• Les obligations de conformite britanniques (PCI DSS, RGPD britannique Article 32, ISO 27001, recommandations NCSC) pointent toutes vers des tests d’intrusion reguliers comme pratique de securite de base.
• Un rapport de qualite contient des resultats classes par risque, des etapes de reproduction techniques, des scores CVSS avec des cotes contextuelles, et des conseils de remediation specifiques pour chaque probleme.
• Pour les certifications, recherchez CREST CRT, CCT App ou CCT Inf pour les testeurs individuels de votre mission. Pour le secteur public, le statut du schema CHECK est requis.
• Testez annuellement au minimum, apres les versions majeures, et avant la mise en production de tout nouveau service traitant des donnees personnelles ou de paiement.

Questions frequemment posees (FAQ)

Quelle est la difference entre un test d’intrusion et une analyse de vulnerabilites ? Une analyse de vulnerabilites utilise des outils automatises pour verifier les systemes par rapport a une base de donnees de problemes connus. Un test d’intrusion implique un testeur humain qui raisonne sur la cible, enchaine les vulnerabilites et demontre l’exploitabilite reelle. Les analyses sont rapides et utiles pour etablir une base de reference ; elles ne remplacent pas les tests manuels.

Combien de temps dure un test d’intrusion ? Un test d’application web pour un site de complexite moyenne dure generalement trois a cinq jours de temps de test. Les grandes applications, les missions en boite blanche avec revue de code source, ou les tests d’infrastructure sur de nombreux hotes prennent plus de temps. La conversation de cadrage et la redaction du rapport ajoutent du temps supplementaire, prevoyez donc deux a quatre semaines du debut de la mission a la livraison du rapport final.

Dois-je informer mon hebergeur avant un test d’intrusion ? Verifiez les conditions d’utilisation de votre hebergeur ou fournisseur cloud. AWS, Azure et GCP autorisent tous les tests d’intrusion sur vos propres ressources sans notification prealable pour la plupart des services, bien que certaines restrictions s’appliquent. Les hebergeurs mutualisees exigent souvent un preavis. Votre prestataire de test d’intrusion devrait confirmer cela lors du cadrage.

Que se passe-t-il si le testeur trouve une vulnerabilite critique pendant le test ? Vos regles d’engagement doivent definir une procedure d’escalade pour les resultats critiques. Un testeur serieux vous contactera immediatement plutot qu’attendre le rapport. Vous decidez ensuite si vous pausez les tests pendant la remediation, continuez avec ce resultat documente, ou ajustez le perimetre.

Un test d’intrusion peut-il causer une interruption de service ? La plupart des techniques de test sont non destructives et ne causent pas d’interruption de service. Les tests de deni de service necessitent un accord explicite et sont generalement conduits en dehors des heures de bureau. Votre testeur doit discuter du risque de toute technique potentiellement perturbatrice avant de la tenter.

Comment verifier les certifications d’un testeur d’intrusion CREST ? CREST maintient un registre public des entreprises enregistrees et des personnes certifiees sur crest-approved.org. Recherchez par nom d’entreprise ou de testeur pour verifier le statut. Pour CHECK, le NCSC publie une liste de prestataires de services approuves CHECK.