Comment choisir une entreprise de test d’intrusion (guide de l’acheteur 2026)

Un prospect nous a transmis il y a quelque temps le rapport de pentest d’un concurrent, avec une seule question : est-ce que ça vaut quelque chose ? 60 pages, une belle charte graphique, plein d’assurance. C’était aussi un scan Nessus dont on avait simplement remplacé le nom de l’outil. Aucun test manuel. Aucune logique métier. Aucune preuve que quiconque avait réellement pénétré quoi que ce soit. Juste des scores CVSS et une note “moyenne” pour un en-tête de sécurité HTTP manquant.

Ce rapport, ou un proche cousin, nous le voyons en permanence. Et il touche au cœur de la question : comment choisir une entreprise de test d’intrusion ? Car le livrable a une allure presque identique, qu’un testeur senior ait passé deux semaines à vivre dans votre application ou qu’un script ait tourné toute la nuit. La facture aussi peut se ressembler. Ce guide vise à lire au-delà de la page de garde et à distinguer un vrai test d’un simple “scan-and-dump”.

Nous menons des engagements offensifs à plein temps. Nous savons ce que coûte la réalisation d’un bon test, et nous savons exactement où l’on rogne quand c’est bon marché. Voici ce que nous vérifierions si nous étions assis de votre côté de la table.

À retenir

• Jugez le testeur, pas le logo. Demandez qui interviendra sur votre engagement, ses années passées en sécurité offensive et ses certifications (OSCP, OSWE, CREST, GPEN) – pas le marketing du prestataire.
• Exigez une méthodologie alignée sur un standard public (OWASP WSTG, OWASP ASVS, PTES) et un exemple de rapport caviardé que vous pouvez lire avant de signer.
• Le retest après vos correctifs doit être inclus, pas une option payante. Un pentest sans retest de validation n’est qu’un demi-service.
• Le signal d’alerte le plus clair : un prix fixe bas, un délai de 24 heures et aucun appel de cadrage. C’est un scan automatisé déguisé en costume.
• C’est dans le test manuel de la logique métier et du contrôle d’accès que se trouve le vrai risque. Les scanners en manquent presque la totalité.

Que vend réellement une entreprise de test d’intrusion ?

Un test d’intrusion est une attaque limitée dans le temps et orientée objectif, menée sur vos systèmes par un humain qui cherche à s’introduire comme le ferait un véritable adversaire. C’est tout l’intérêt. Une personne raisonne sur votre application précise, enchaîne de petits problèmes jusqu’à une compromission réelle et prouve l’impact. Un scan de vulnérabilités alimente ce travail, mais à lui seul il n’est pas un test d’intrusion.

Cela compte, parce que les deux se vendent sous le même mot avec des qualités radicalement différentes. Alors, quand vous réfléchissez à comment choisir une entreprise de test d’intrusion, vous réfléchissez en réalité à une seule chose : est-ce que j’achète de l’expertise humaine, ou de l’automatisation avec une marge ? Nous avons creusé cette distinction dans un article dédié sur test d’intrusion contre scan de vulnérabilités, mais la version courte est simple. Les scanners trouvent des signatures connues. Les testeurs trouvent la logique.

Voici la partie inconfortable. Les vulnérabilités qui compromettent réellement les entreprises – contrôle d’accès défaillant, IDOR, contournement d’authentification, SSRF qui pivote vers les métadonnées cloud, abus de logique métier dans un tunnel de paiement ou de virement de fonds – ne sont presque jamais mises au jour par un outil. L’OWASP classe le Broken Access Control comme le risque web numéro un, et dans nos engagements les failles de contrôle d’accès et de logique figurent systématiquement parmi les plus critiques que nous rapportons. Aucun scanner ne parcourt votre workflow en plusieurs étapes et ne remarque qu’une requête comme GET /api/v2/accounts/1043/statements renvoie sans broncher le compte 1044 quand on change un seul chiffre. Un humain, si.

Que faut-il rechercher chez une entreprise de test d’intrusion ?

Quatre choses : les personnes, la méthode, le livrable et ce qui se passe après les correctifs. Le reste, c’est de l’emballage.

Des testeurs seniors, nommés et certifiés

Posez la question directement. Qui interviendra sur mon engagement ? Combien d’années ont-ils consacrées au travail offensif ? Qu’ont-ils publié, présenté ou rapporté ? Un bon prestataire répond sans broncher. Les certifications sont un indicateur raisonnable de compétence pratique – OSCP et OSWE d’Offensive Security, CREST CRT et CCT, GPEN et GXPN vous obligent tous à exploiter réellement des systèmes plutôt qu’à cocher des cases à choix multiple. Une réserve que nous répéterons : les certifications sont un plancher, pas un plafond. Un testeur couvert de badges mais sans instinct pour les failles logiques vous remettra tout de même un export de scanner.

Méfiez-vous du “bait-and-switch”. Un consultant senior soigné vend la mission, puis un junior avec un scanner la réalise. Faites inscrire le testeur nommé par écrit.

Une méthodologie que vous pouvez confronter à un standard

Un prestataire crédible aligne son travail sur quelque chose de public. Pour les applications web, cela signifie le OWASP Web Security Testing Guide (WSTG) et OWASP ASVS pour la profondeur de couverture, et PTES pour la forme de l’engagement global. Si un prestataire ne peut pas vous dire quelles catégories il couvre, ni comment il teste l’authentification, la gestion des sessions, le contrôle d’accès, l’injection et la logique métier, c’est un problème que vous entendez dès le premier appel.

Demandez quelle part du test est manuelle. Sur un engagement web, la passe automatisée – un scan actif Burp Suite, quelques templates nuclei, ffuf pour la découverte de contenu – c’est peut-être la première journée. La valeur vient ensuite. C’est là qu’un humain manipule les JWT, teste chaque référence d’objet pour l’IDOR et détourne le seul workflow dont les développeurs pensaient que personne n’irait jamais le titiller.

Un exemple de rapport sur lequel vous agiriez vraiment

Exigez un exemple caviardé avant d’acheter. Lisez-le en ingénieur, pas en acheteur. Un bon finding a un titre clair, un impact métier en langage clair, des étapes de reproduction exactes (la requête, le paramètre, le payload), des preuves, une sévérité que vous pouvez défendre et un correctif précis. Pas “cross-site scripting détecté – à corriger.”

Si l’exemple est un export de scanner avec un nouveau logo, vous avez votre réponse. Le test : vos développeurs devraient pouvoir reproduire et corriger un finding à partir du seul rapport, sans appel de suivi pour le traduire.

Le retest inclus, pas vendu en supplément

Ce point sépare vite les entreprises sérieuses des autres. Après votre remédiation, quelqu’un doit vérifier que les correctifs fonctionnent réellement et n’ont pas ouvert de nouvelles brèches. Ce retest fait partie de l’engagement, pas d’une facture ultérieure. Nous le traitons comme partie intégrante du travail, car un pentest qui s’arrête à “voici les bugs” vous laisse deviner si vous êtes en sécurité. Un retest propre se trouve aussi être exactement ce que vos auditeurs et vos clients grands comptes veulent voir.

Quels sont les signaux d’alerte au moment de choisir un prestataire de pentest ?

Le plus bruyant : un prix fixe, suspicieusement bas, un délai de 24 à 48 heures et aucune conversation de cadrage. Un vrai test ne peut pas être chiffré avec précision sans comprendre votre périmètre – combien d’applications, combien de rôles, combien d’endpoints API, s’il est authentifié, quels sont vos objectifs. Une entreprise qui chiffre avant de poser des questions chiffre pour un scan.

Quelques autres que nous croisons sans arrêt :

• “Nous utilisons du testing propulsé par l’IA” comme unique argument de vente. L’automatisation nous aide nous aussi. Mais si l’élément différenciant est un outil plutôt que les personnes qui le pilotent, vous achetez l’outil.
• Aucune preuve d’exploitation. “Potentiellement vulnérable” avec un score CVSS et sans reproduction, c’est une supposition de scanner. Les vrais findings montrent la requête et le résultat.
• Rapport et fuite. Un bon engagement se termine par un appel où les testeurs guident vos ingénieurs à travers les findings critiques et répondent aux questions gênantes.
• Tout est critique, ou tout est informatif. Une sévérité mal calibrée signifie que personne n’a raisonné sur votre risque réel. Méfiez-vous aussi des rapports gonflés de findings informatifs sans valeur pour paraître épais.
• Ils esquivent la question “qui teste”. S’ils ne veulent pas nommer le testeur ni les certifications, partez du principe que la réponse ne vous plairait pas.

Quelles questions poser à une entreprise de test d’intrusion ?

Emportez-les dans l’appel commercial. Les réponses vous en disent plus que n’importe quelle brochure.

• Qui, précisément, testera mes systèmes, et quel est son parcours en sécurité offensive et ses certifications ?
• Quel pourcentage de cet engagement est manuel par rapport à l’automatisé, et quel standard (OWASP WSTG, PTES, ASVS) suivez-vous ?
• Puis-je voir un exemple de rapport caviardé avant de signer ?
• Un retest de validation après remédiation est-il inclus dans ce prix ?
• Comment gérez-vous précisément le test de la logique métier et du contrôle d’accès ?
• De quoi avez-vous besoin de ma part pour cadrer cela avec précision, et à quoi ressemble le calendrier ?
• Y aura-t-il un débrief en direct avec mon équipe d’ingénierie ?

Des réponses précises, assurées et cohérentes sont bon signe. Des réponses vagues, ou chaque question qui ramène à une grille tarifaire, sont votre signal pour continuer à chercher.

Comment CyberXplore aborde la question

Nous avons bâti notre service de test d’intrusion d’applications web autour de ce que les acheteurs devraient exiger : des testeurs seniors nommés, une méthodologie alignée sur OWASP WSTG et ASVS, des rapports sur lesquels vos développeurs peuvent agir sans traducteur, et un retest gratuit après votre remédiation. Chaque finding critique est livré avec la requête exacte, le payload et les étapes de reproduction, plus un débrief en direct avec votre équipe. Nous préférons trop expliquer un bug que vous tendre un chiffre CVSS et partir. Si vous voulez un devis honnête et cadré pour votre environnement, demandez un devis et nous commencerons par une conversation de cadrage, pas par une étiquette de prix.

FAQ

Combien devrait coûter un test d’intrusion ?

Cela dépend du périmètre et de la profondeur, alors traitez avec méfiance tout prix fixe annoncé sans appel de cadrage. Une seule petite application web est un travail très différent d’une grande plateforme authentifiée avec des dizaines d’endpoints API et plusieurs rôles. La bonne question n’est pas “quel est le moins cher” mais “qu’est-ce que j’obtiens pour ce prix” – du test manuel, un vrai rapport et un retest, ou un scan dans un PDF.

Quelles certifications un testeur d’intrusion devrait-il avoir ?

OSCP et OSWE d’Offensive Security, CREST CRT ou CCT, ainsi que GPEN ou GXPN sont tous des signaux solides, car ils exigent des candidats qu’ils exploitent réellement des systèmes plutôt que de mémoriser de la théorie. Considérez les certifications comme un seuil minimal, pas comme une preuve d’excellence. Des années d’expérience réelle en engagement et un flair pour les failles de logique métier comptent tout autant.

Un test d’intrusion est-il la même chose qu’un scan de vulnérabilités ?

Non. Un scan de vulnérabilités est une vérification automatisée des problèmes connus et des mauvaises configurations. Un test d’intrusion, c’est un humain qui tente activement de s’introduire, enchaîne les findings et prouve un impact réel. Un bon pentest utilise le scan comme un intrant précoce, puis consacre l’essentiel de son temps au travail manuel que les outils ne peuvent pas faire, comme le test du contrôle d’accès et de la logique.

Combien de temps dure un test d’intrusion ?

La plupart des engagements ciblés sur des applications web représentent une à trois semaines de test actif, plus le reporting, selon le périmètre. Un délai le jour même signifie presque toujours un scan automatisé plutôt qu’un test manuel. Prévoyez de la marge pour un retest après que votre équipe a corrigé les findings.

Le retest devrait-il être inclus dans le prix ?

Oui. Après votre remédiation, un testeur devrait vérifier que les correctifs ont bien fermé les problèmes et n’en ont pas ouvert de nouveaux. Si un prestataire facture ce retest de validation séparément, intégrez-le au coût total et demandez-vous si le premier engagement a jamais vraiment été complet sans lui.

Quel est le principal signal d’alerte, à lui seul ?

Un prix fixe bas, un délai rapide et aucune conversation de cadrage. Un test précis ne peut pas être chiffré sans comprendre vos applications, vos rôles et vos objectifs. Un devis qui tombe avant que quiconque ait posé une vraie question concerne presque certainement un scan automatisé, pas un test d’intrusion.