Pentest black box, grey box, white box : quelle boîte pour
quel objectif

Entre un test en boîte noire et un test en boîte blanche, une seule chose change : la quantité d'informations qu'on remet au pentester avant qu'il commence. Zéro pour la boîte noire, une URL et parfois juste un nom de domaine. Tout pour la boîte blanche, code source et accès compris. La boîte grise tient le milieu, quelques comptes et un peu de documentation. Même cible, même objectif, celui d'entrer, mais trois façons très différentes de s'y prendre.

Les devis empilent les anglicismes (black box, grey box, white box) sans toujours dire ce qu'ils changent à la mission, au budget, et surtout aux failles que vous allez trouver ou rater. Voyons les trois modes, leur logique, et lequel choisir selon ce que vous cherchez à prouver.

La métaphore de la boîte : ce qu'on met dedans

Le mot "boîte" vient de là : on regarde le système à tester comme une boîte, et la couleur dit à quel point elle est transparente. Boîte noire, vous ne voyez que l'extérieur. Boîte blanche, la paroi est en verre et vous voyez tout le mécanisme interne. Boîte grise, vous avez percé quelques trous pour glisser un regard à l'intérieur. La couleur décrit donc la connaissance préalable du testeur, rien d'autre.

Retenez ce curseur, tout le reste en découle. Plus la boîte est transparente, moins le testeur perd de temps à deviner, et plus il peut aller creuser en profondeur. Mais moins le test ressemble à ce que vivrait un vrai attaquant, qui, lui, part rarement avec les plans du bâtiment. Réalisme et couverture tirent dans des directions opposées, et le choix du mode, c'est le choix de l'endroit où vous placez le curseur.

Les 3 types de test d'intrusion, en clair

Voici les trois modes, du plus opaque au plus transparent, avec ce que chacun voit et ce qu'il permet de trouver.

• Black box (boîte noire) : zéro connaissance préalable. Le pentester attaque depuis l'extérieur, avec les mêmes informations qu'un pirate lambda qui tombe sur votre application. C'est le mode le plus réaliste quant au point de départ, mais sa couverture est plafonnée par le temps : chaque heure passée à cartographier la cible est une heure non passée à exploiter.
• Grey box (boîte grise) : connaissance partielle. On fournit généralement des comptes utilisateurs (un ou plusieurs rôles), parfois une documentation d'API ou un schéma d'architecture. Le testeur saute l'étape de reconnaissance à l'aveugle et consacre son temps à ce qui compte : la logique applicative, les contrôles d'accès entre rôles, les zones authentifiées. C'est le meilleur ratio réalisme/couverture pour du web, et de loin le mode le plus courant en pratique.
• White box (boîte blanche) : accès complet. Code source, architecture, comptes de tous les rôles, souvent les configs et la CI. La couverture est maximale : le testeur lit le code, remonte une entrée utilisateur jusqu'à la requête SQL, repère les failles qu'un attaquant externe mettrait des mois à deviner. C'est le mode d'un véritable audit de code, le plus exhaustif, mais aussi le plus exigeant en expertise et en temps.

Réalisme, couverture, coût : le vrai arbitrage

Toute la décision se joue sur trois axes qui ne bougent pas dans le même sens. Le réalisme (à quel point le test imite un vrai attaquant), la couverture (quelle proportion de la surface et de la logique on arrive à éprouver), et le coût en temps et en argent. Le tableau ci-dessous résume comment chaque mode se positionne.

  +--------------+-------------+--------------+-------------+
  |              | BLACK BOX   | GREY BOX     | WHITE BOX   |
  +--------------+-------------+--------------+-------------+
  | Infos data   | aucune      | comptes +    | code source |
  |              |             | doc partielle| + archi     |
  +--------------+-------------+--------------+-------------+
  | Realisme     | eleve       | bon          | faible      |
  | (attaquant)  |             |              |             |
  +--------------+-------------+--------------+-------------+
  | Couverture   | limitee     | tres bonne   | maximale    |
  +--------------+-------------+--------------+-------------+
  | Cout / temps | modere      | modere       | eleve       |
  +--------------+-------------+--------------+-------------+
  | Ideal pour   | exposition  | appli web    | audit de    |
  |              | externe     | metier       | code, SaaS  |
  +--------------+-------------+--------------+-------------+

Lisez ce tableau en diagonale et le profil de la boîte grise ressort : le black box est plus réaliste, le white box couvre davantage, mais le grey box reste correct sur chaque axe sans dominer aucun. C'est ce qui le fait dominer sur le web : la plupart des vulnérabilités applicatives graves (contrôles d'accès cassés, élévation de privilèges, logique métier contournée) vivent derrière l'authentification. Sans compte, le testeur reste sur le paillasson ; avec un compte, il entre dans la maison, là où se cachent les vrais problèmes.

Quand choisir la boîte noire

Le black box répond à une question bien précise : "qu'est-ce qu'un attaquant qui ne sait rien de nous peut faire depuis Internet ?" C'est le bon mode pour éprouver votre exposition externe, valider qu'une nouvelle mise en ligne ne laisse pas de porte ouverte évidente, ou rassurer une direction sur le scénario du pirate opportuniste. Notre pentest web blackbox se place exactement là : on part de zéro, comme l'adversaire.

Son défaut est structurel : le temps. Une bonne partie de la mission passe en reconnaissance (cartographier les sous-domaines, deviner les rôles, tester des identifiants), et ce temps ne produit pas de failles, il les prépare. Sur un périmètre riche et authentifié, un black box seul risque de rater des vulnérabilités profondes simplement parce que le testeur n'a jamais réussi à obtenir un compte pour aller voir derrière. Réaliste, oui ; exhaustif, non.

Quand la boîte grise est le bon défaut

Pour une application web métier, un SaaS, un espace client, le grey box est presque toujours le choix par défaut, et c'est un choix qu'on assume franchement. En fournissant un ou deux comptes par rôle, vous transformez la reconnaissance à l'aveugle en test dirigé. Le pentester passe directement aux questions qui font mal : est-ce qu'un utilisateur standard peut lire les données d'un autre ? forcer un rôle admin ? contourner le tunnel de paiement ? Ce sont les failles qui coûtent cher en vrai, et elles sont toutes derrière le login.

Quand la boîte blanche s'impose

Le white box brille quand votre objectif est l'exhaustivité. Application qui manipule des données sensibles, brique critique avant une mise en production majeure, exigence d'un client grand compte, contexte réglementaire : là, vous voulez la couverture maximale, pas le scénario le plus réaliste. En donnant le code source et les accès, le testeur remonte les flux de données à la source, repère les injections là où elles naissent, et débusque des failles qu'un test externe n'atteindrait jamais dans le temps imparti. C'est l'angle de notre pentest web whitebox, qui combine l'audit de code et l'exploitation dynamique.

La contrepartie : ça demande plus d'expertise (lire du code offensivement n'est pas donné à tout le monde) et donc un TJM plus élevé, ce qu'on détaille dans le prix d'un test d'intrusion. Vous payez la profondeur. Mais pour une appli où une faille passée inaperçue coûterait bien plus que la mission, c'est de loin le mode le plus rentable.

Ce que le mode change dans le déroulé de la mission

Les cinq phases d'une mission ne bougent pas d'un mode à l'autre : cadrage et autorisation écrite, reconnaissance, exploitation, rapport, retest. Ce qui bouge, c'est la part du budget que chacune absorbe. Et cette redistribution explique à elle seule pourquoi deux missions de cinq jours ne rendent pas le même volume de findings.

En boîte noire, la reconnaissance mange facilement le tiers de la mission. On énumère les sous-domaines, on cartographie les endpoints, on cherche les technologies et les versions, on teste des identifiants par défaut. C'est du travail nécessaire, mais qui ne remplit pas encore le rapport. En boîte grise, cette phase se réduit à une prise en main de l'application : le pentester sait déjà où sont les rôles, il attaque les frontières entre eux. En boîte blanche, la phase change de nature. Elle devient une lecture de code orientée attaque, où l'on suit les flux de données depuis les points d'entrée jusqu'aux requêtes SQL, aux appels système et aux désérialisations.

L'outillage suit le même déplacement. Le mode noir s'appuie surtout sur de la découverte et un proxy d'interception ; le mode blanc y ajoute l'analyse statique, dont le tri manuel est l'essentiel du travail. Un moteur SAST sort des centaines d'alertes ; savoir lesquelles sont réellement atteignables depuis une requête HTTP demande de lire le code, pas de lire le rapport de l'outil. C'est exactement ce que valide la certification OSWE, qui porte sur l'exploitation à partir du code source, et c'est la compétence qui sépare un audit boîte blanche utile d'un export d'outil recraché en PDF. On a détaillé cette différence entre outil et mission humaine dans pentest et scan de vulnérabilités, et le tri des familles d'outils dans SAST, DAST et IAST.

Une chose ne change jamais : la phase de cadrage et l'autorisation écrite. Sans convention d'audit signée qui nomme le périmètre, les plages horaires et les personnes à prévenir, aucune mission ne démarre, quelle que soit la couleur de la boîte.

Ce que disent NIS2, DORA et PCI DSS sur le mode de test

C'est une question qui revient à chaque cadrage, et la réponse surprend souvent : aucun de ces textes n'impose une couleur de boîte. Ils exigent que vous testiez, pas que vous testiez d'une manière donnée. Ce qui veut dire que le mode reste un choix technique, à faire sur l'objectif, et que c'est le rapport qui servira de preuve devant l'auditeur.

• NIS2 demande des mesures de gestion des risques et l'évaluation de leur efficacité, sans prescrire de méthode de test. En pratique, un pentest annuel documenté avec son retest fait très bien l'affaire ; on a détaillé l'exercice dans l'audit NIS2 et le périmètre des entités concernées dans la directive NIS2.
• PCI DSS v4.0 est plus directif sur la fréquence que sur la méthode : son exigence 11.4 impose des tests d'intrusion internes et externes au moins annuels, plus une validation de la segmentation réseau. Le mode reste ouvert, et la boîte grise couvre en général le mieux le périmètre attendu.
• DORA est le seul à décrire précisément un exercice, le TLPT, mais c'est un exercice de type red team réservé aux entités financières désignées, pas le pentest applicatif courant. La distinction compte, parce que confondre les deux fait exploser un budget sans raison : on l'a creusée dans DORA et le test d'intrusion TLPT.
• ISO 27001 traite le sujet par la gestion des vulnérabilités techniques plutôt que par le test lui-même. Le pentest y entre comme moyen de preuve, pas comme obligation nommée.

Si votre exigence vient d'un donneur d'ordre public ou d'un opérateur régulé, la question n'est souvent pas le mode mais la qualification du prestataire, ce qui renvoie au référentiel PASSI de l'ANSSI. Là encore, la couleur de la boîte reste votre choix.

Comment on choisit, concrètement

Tout part de ce que vous voulez prouver. Si vous voulez mesurer votre exposition face à un inconnu, black box. Si vous voulez éprouver en profondeur une application avec des comptes et des rôles, grey box, et c'est le cas le plus fréquent. Si vous voulez la couverture la plus complète possible, code compris, white box. Rien n'empêche non plus de combiner : commencer en black box pour capturer le point de vue externe, puis basculer en grey ou white box pour la profondeur. C'est d'ailleurs ce qui se passe dans la plupart des missions sérieuses, et le déroulement d'un pentest montre comment ces phases s'enchaînent.

Un dernier repère utile : le mode de la boîte décrit la connaissance donnée au testeur, il ne dit rien de la nature de l'exercice. Un black box reste un pentest, c'est-à-dire l'exhaustivité sur un périmètre défini, et pas une simulation d'attaque à l'échelle de toute l'organisation. Si cette distinction vous intéresse, on l'a creusée dans red team ou test d'intrusion. Pour aller plus loin sur les standards de test, l'OWASP Web Security Testing Guide formalise ce que devrait couvrir une mission web quel que soit le mode choisi.

Questions fréquentes

À retenir

• La couleur de la boîte décrit une seule chose : la quantité d'informations remise au pentester avant qu'il commence.
• Black box (zéro info) maximise le réalisme du point de départ, mais sa couverture est bridée par le temps de reconnaissance.
• Grey box (comptes fournis) offre le meilleur ratio réalisme/couverture pour le web, c'est le mode le plus courant en pratique.
• White box (code source et accès complets) donne la couverture maximale, idéal pour un audit de code, contre un TJM plus élevé.
• On ne choisit pas "le meilleur mode", on choisit celui qui répond à la question qu'on se pose. Et un simple compte de test change souvent tout.

Vous ne savez pas quelle boîte cocher pour votre application ? C'est normal, et c'est aussi notre travail de vous le dire. Parlez-nous de votre contexte et de ce que vous cherchez à prouver : on vous oriente vers un pentest web blackbox ou whitebox selon la profondeur qui sert votre objectif, sans vous vendre du temps que vous n'avez pas besoin de payer.