Pentest ou audit de sécurité : quelles différences concrètes

« Nous cherchons un pentest » et « nous cherchons un audit » désignent rarement le même besoin, alors que les deux expressions sont utilisées de façon interchangeable dans la plupart des appels d’offres. La confusion a un coût : elle conduit à acheter une prestation qui répond mal à la question posée.

Deux logiques opposées

Un test d’intrusion, ou pentest, part de l’extérieur. L’auditeur adopte la position d’un attaquant : il dispose d’un point d’entrée (une URL, un compte utilisateur standard, parfois rien du tout) et cherche jusqu’où il peut aller. La question à laquelle il répond est : « que peut faire concrètement quelqu’un de malveillant ? »

Un audit de sécurité part de l’intérieur. L’auditeur dispose d’un accès documenté au système : code source, comptes administrateurs, schéma de base de données, documentation d’architecture, parfois échanges directs avec l’équipe. La question devient : « la conception et l’implémentation sont-elles correctes ? »

Cette différence de point de départ entraîne tout le reste.

Ce que chacun trouve, et ce qu’il rate

Le pentest excelle sur les chaînes d’exploitation. Il révèle qu’une information anodine exposée sur une page publique, combinée à un défaut mineur d’un formulaire, permet d’atteindre les données d’un autre client. Cette démonstration a une valeur de conviction que peu d’autres méthodes atteignent : elle est reproductible, elle a été exécutée réellement.

En revanche, le pentest est borné par le temps. Sur trois à six jours, un auditeur explore les chemins les plus prometteurs et laisse volontairement de côté des pans entiers de l’application. Une fonctionnalité peu visible, mal reliée depuis l’interface, a de bonnes chances de n’être jamais atteinte. Le pentest ne prouve donc jamais l’absence de faille, seulement la présence de celles qu’il a trouvées.

L’audit avec accès au code obtient une couverture plus homogène. Rechercher tous les points d’accès à une ressource sensible dans un dépôt prend quelques minutes ; y arriver à l’aveugle depuis l’extérieur peut prendre des jours, ou échouer. L’audit repère aussi les défauts structurels : un contrôle d’accès implémenté dans le contrôleur plutôt que dans la couche d’accès aux données, une vérification appliquée à neuf points d’entrée sur dix, un mécanisme de chiffrement mal paramétré.

Sa limite est symétrique : un constat au fil du code ne dit pas toujours s’il est exploitable en conditions réelles. Un défaut apparemment grave peut être neutralisé en amont par un filtrage dont l’auditeur n’a pas connaissance ; un autre, jugé mineur sur le papier, peut ouvrir un accès complet une fois combiné à la configuration de production.

Comparaison synthétique

	Test d’intrusion	Audit de sécurité
Point de vue	Externe, attaquant	Interne, concepteur
Accès fourni	Minimal (boîte noire ou grise)	Complet (boîte blanche)
Force	Démonstration d’impact réel	Couverture et compréhension des causes
Faiblesse	Couverture partielle	Exploitabilité parfois théorique
Durée typique	3 à 6 jours	5 à 10 jours
Livrable clé	Scénarios d’attaque aboutis	Constats hiérarchisés par composant

Les variantes qui brouillent les frontières

En pratique, la plupart des missions sérieuses sont hybrides. Le pentest en boîte grise est aujourd’hui la norme sur les applications SaaS : l’auditeur reçoit deux ou trois comptes de test avec des rôles différents, éventuellement dans deux organisations distinctes, mais pas le code. Cette configuration reproduit fidèlement la menace la plus probable pour un SaaS B2B, celle d’un client légitime qui cherche à voir ce qu’il ne devrait pas voir, tout en évitant de gaspiller des jours à reconstituer des informations que l’éditeur peut donner en dix minutes.

L’audit de code assisté par des tests fait le chemin inverse : la revue de code identifie des hypothèses, chacune étant ensuite vérifiée sur un environnement de recette. Cette approche donne des constats à la fois complets et démontrés, mais coûte plus cher.

Choisir en fonction de la question posée

Quelques situations typiques, et la réponse adaptée à chacune.

Un client grand compte exige une preuve d’audit externe avant de signer. Un pentest en boîte grise, avec une attestation de réalisation, répond exactement à la demande. Le rapport détaillé reste interne ; l’attestation, qui mentionne le périmètre, les dates et le niveau de risque résiduel, se transmet au client.

L’équipe a refondu son système de permissions. L’audit de code est plus pertinent : il faut vérifier que la logique est correcte partout, pas seulement là où un attaquant tomberait en premier.

La direction veut savoir « à quel point on est exposé ». Le pentest est plus parlant. Un scénario documenté qui va d’un compte d’essai gratuit à la lecture des données d’un autre client change les arbitrages budgétaires plus efficacement qu’une liste de constats.

Un incident vient d’avoir lieu. Ni l’un ni l’autre en premier : la réponse à incident et l’analyse de la cause racine passent avant. L’audit vient ensuite, pour vérifier si la même erreur existe ailleurs.

L’application est en cours de conception. Ni l’un ni l’autre : une revue d’architecture, plus légère et menée avant l’écriture du code, offre un bien meilleur rendement.

Une question de vocabulaire à clarifier tôt

Avant de comparer des devis, il vaut la peine de demander à chaque prestataire trois précisions : quel accès sera fourni, quelle proportion de tests manuels est prévue par rapport aux outils automatisés, et quelle est la liste des composants explicitement hors périmètre. Ces trois réponses en disent plus long sur la prestation réelle que l’intitulé commercial, quel qu’il soit.

Deux propositions au même prix peuvent recouvrir un travail totalement différent : un balayage automatisé mis en forme d’un côté, huit jours d’analyse manuelle de l’autre. Le mot employé sur le devis ne permet pas de faire la différence.