Deux devis annoncent un « test d’intrusion d’application web ». Le premier examine le portail depuis l’extérieur, sans compte utilisateur. Le second inclut les rôles client, les API et un parcours d’export. Les deux rapports peuvent décrire fidèlement leur mission tout en répondant à des questions différentes.
Pour un directeur technique qui prépare un lancement ou une revue de sécurité demandée par un grand compte, la comparaison commence par la décision à éclairer. Un tiers peut-il entrer dans l’application ? Un client connecté peut-il atteindre les dossiers d’un autre ? Un export corrigé sera-t-il revérifié de façon indépendante avant l’engagement commercial ?
Le pentest constitue une étape de ce travail. La préparation, les correctifs, leur déploiement et la décision finale demandent aussi des responsables.
L’essentiel en 60 secondes
Donnez à chaque prestataire le même parcours, les mêmes rôles et environnements, et la même question. Demandez-lui de préciser ce qui sera examiné, ce qui sera exclu et les éléments nécessaires au démarrage. Attribuez ensuite l’analyse des constats, la correction, la livraison, la contre-vérification et l’acceptation du risque résiduel.
Comparez les propositions sur cette base avant leurs montants. Un périmètre présenté comme large n’est utile que si les travaux inclus, les preuves, les exclusions et les conditions de contre-audit sont explicites.
1. Définir la question à laquelle le test doit répondre
Écrivez une phrase de décision : « Avant l’ouverture du portail, nous avons besoin d’une évaluation indépendante de la possibilité, pour les rôles utilisateurs définis, de dépasser leurs droits dans le portail et ses API. » Précisez quel lancement ou engagement dépend de la réponse.
Une question centrée sur l’accès depuis l’extérieur peut justifier un autre périmètre. Les termes boîte noire, grise ou blanche ne suffisent pas à décrire la couverture. Détaillez les informations et accès fournis aux auditeurs, puis les parcours qu’ils pourront examiner avec ces éléments.
Le guide du NCSC britannique associe responsables du risque, équipe technique et prestataire au cadrage. Publié en 2017 et revu en 2022, il apporte un cadre de commande ; il ne mesure pas la demande actuelle et ne constitue pas une exigence française.
Si un contrat ou une exigence applicable demande une qualification particulière, traitez ce point séparément. Les ressources PASSI de l’ANSSI distinguent la qualification par activité d’audit, dont les tests d’intrusion. La présentation générale d’une offre de cybersécurité n’établit pas la qualification requise pour une mission précise.
2. Décrire un parcours qui traverse les frontières importantes
Prenons un portail fictif. Il ne s’agit ni d’un cas client IZZY, ni d’une véritable proposition commerciale.
L’organisation A dispose d’un administrateur et d’un lecteur. L’organisation B possède ses propres comptes et données synthétiques. L’administrateur de A invite un collègue, ouvre un document client, demande un export et reçoit une notification de fin de traitement. L’accès du collègue est ensuite révoqué.
Le parcours soulève plusieurs questions liées. Chaque rôle reste-t-il dans ses droits ? L’API applique-t-elle les mêmes règles ? L’export contient-il uniquement les données prévues de A ? Que doit devenir l’accès après la révocation ? Si le portail utilise un fournisseur d’identité ou envoie un webhook, où s’arrête le test autorisé ?
Fournissez les réponses attendues sous forme de règles produit. Pour un lien temporaire de téléchargement, décidez par exemple si sa possession donne accès jusqu’à l’expiration ou si le téléchargement exige une appartenance toujours valide. Sans cette précision, auditeurs et développeurs risquent d’évaluer deux politiques différentes.
Ce parcours sert à discuter le périmètre. Il ne remplace ni l’expertise du prestataire, ni une méthode complète de test.
3. Faire passer ce parcours dans deux propositions
Les périmètres suivants sont entièrement illustratifs. Ils ne comportent aucun tarif, estimation de charge ou jugement sur un prestataire nommé.
| Point à comparer | Proposition A : exposition externe | Proposition B : portail authentifié |
|---|---|---|
| Accès fournis | URL publiques, sans compte client | Comptes de deux organisations fictives, avec rôles administrateur et lecteur définis |
| Question visée | Que peut atteindre une personne non authentifiée ? | Les rôles fournis peuvent-ils dépasser les droits prévus ? |
| Parcours couvert | Points d’entrée publics et interfaces exposées ; export authentifié exclu | Invitation, documents, API, export et notifications selon le périmètre convenu |
| Systèmes tiers | Infrastructure des fournisseurs exclue | Infrastructure des fournisseurs exclue ; traitement de l’intégration côté portail inclus seulement s’il est précisé |
| Correction et contre-audit | Recommandations livrées ; réalisation des correctifs et contre-audit exclus | Recommandations et fenêtre de contre-vérification définie ; réalisation des correctifs côté ingénierie |
Demandez à chaque prestataire la charge de test exprimée en jours de travail des auditeurs, le temps prévu pour les parcours importants et les limites de profondeur liées à cette allocation. Identifiez les intervenants et leur expérience pertinente des applications et des API. Distinguez cette charge des dates calendaires de mission, du temps de restitution et de la fenêtre de contre-audit.
Appliquez A au parcours d’export. Le rapport peut expliquer ce qui était accessible sans compte client. Il ne permet pas de conclure qu’un administrateur de A ne peut pas obtenir l’export de B par un chemin authentifié exclu. La question reste ouverte ; cela ne démontre pas une mauvaise prestation.
Appliquez ensuite B. L’export authentifié est inclus, mais son début et sa fin doivent être précisés. Le test couvre-t-il la création, les effets du traitement en arrière-plan, la récupération du fichier et l’accès après révocation ? Si seule la demande de génération est examinée, le téléchargement reste hors réponse.
B laisse également du travail à l’équipe : corriger, déployer sur l’environnement convenu, fournir une version testable et décider si un point résiduel empêche le lancement. Une fenêtre de contre-audit ne réalise pas ces étapes à sa place.
4. Transformer le cadrage en préparation exécutable
Joignez un inventaire reliant le parcours à l’application réelle : points d’entrée web, versions d’API pertinentes, export, notifications, rôles, appartenance aux organisations, environnement et version déployée. Placez les exclusions à côté du parcours concerné pour rendre leur effet visible.
Le Web Security Testing Guide d’OWASP fournit des références de méthode. L’Application Security Verification Standard fournit des exigences utilisables notamment dans une commande. Demandez quelle version et quelles parties pertinentes sont retenues, puis comment le rapport distinguera ce qui a été examiné, non examiné ou jugé inapplicable. La seule mention « OWASP » ne répond pas à ces questions.
Avant la date réservée, vérifiez que les comptes fonctionnent, que leurs droits diffèrent comme prévu et que les données synthétiques représentent les relations à examiner. Fournissez la documentation d’API à jour et un contact technique capable de débloquer les accès. Convenez des méthodes permises, limites d’exploitation, remontées urgentes, conditions d’arrêt et modalités de conservation des preuves.
Privilégiez un environnement de test autorisé, avec des données synthétiques représentatives, lorsqu’il permet de répondre au besoin. Si un test en production est nécessaire, réglez d’abord l’autorisation et les conditions d’intervention. Inclure votre intégration ne donne pas automatiquement le droit de tester l’infrastructure du fournisseur : prévoyez un équivalent de test maîtrisé ou indiquez la limite qui en découle.
Ce que nous aurions en place avant de réserver une date : des comptes de test pour chaque rôle dans deux organisations, une description des rôles tenant sur une page, une cartographie des intégrations, un environnement distinct avec des données synthétiques et du temps d’ingénierie réservé aux corrections. Un rapport qui arrive alors que personne n’est disponible pour corriger vieillit vite.
Cette préparation rend le parcours accessible aux auditeurs. Elle ne garantit pas la découverte de toutes les faiblesses.
5. Attribuer les corrections et la contre-vérification avant le démarrage
Un constat peut être clair et rester sans suite faute de responsable pour l’étape suivante. Définissez les passages de relais pendant la préparation de la mission.
| Travail | Responsable à nommer | Preuve ou décision attendue |
|---|---|---|
| Préparer l’application | Responsable technique interne | Comptes, données, documentation et version convenus |
| Expliquer le constat | Prestataire de pentest | Périmètre touché, preuve maîtrisée, impact et pistes de correction |
| Décider de la réponse | CTO ou responsable du risque avec l’équipe technique | Priorité, mesure provisoire et responsable du correctif |
| Corriger et déployer | Équipe d’ingénierie ou partenaire de remédiation | Modification relue, non-régression et identification de la version livrée |
| Effectuer le contre-audit | Prestataire convenu | Résultat sur le constat corrigé et limites explicites |
| Accepter les points résiduels | Responsable métier ou du risque habilité | Décision de lancement et problèmes encore ouverts |
Le guide du NCSC laisse explicitement à l’organisation l’évaluation du risque et les décisions de correction. Le rapport éclaire cette responsabilité sans la transférer.
Lors d’un appel avec un CTO, nous le formulons ainsi : « L’auditeur trouve et démontre. Vos ingénieurs, ou les nôtres, corrigent et livrent. L’auditeur vérifie ensuite le correctif. Personne ne valide son propre travail. »
Définissez les conditions concrètes du contre-audit : début et fin de la fenêtre, nombre de passages inclus, critères pour présenter un correctif, environnement utilisé et traitement d’une correction livrée hors délai. Demandez si les chemins voisins entrent dans la vérification ou nécessitent un périmètre supplémentaire.
Si le correctif désactive l’export, distinguez deux résultats : l’accès initial est empêché ; la fonctionnalité attendue fonctionne avec les bons droits. Attribuez à l’ingénierie la recette fonctionnelle et les preuves de non-régression, en complément de la contre-vérification de sécurité indépendante. Gardez les points non résolus et non testés séparés des constats corrigés.
6. Comparer le travail restant pour prendre la décision
Pour chaque proposition, reconstituez la séquence entière : préparation interne, tests du prestataire, analyse, correction, livraison, contre-audit et acceptation. Indiquez ce que couvre le devis, ce que fera votre équipe et ce qui demande un accord distinct. Ajoutez les dépendances de calendrier : la contre-vérification suppose que la bonne version corrigée soit disponible.
Vous pouvez alors comparer le travail nécessaire pour répondre à la question initiale. A peut convenir à l’exposition externe tout en laissant les accès client authentifiés à une autre mission. B peut couvrir ce parcours tout en excluant la réalisation des correctifs et certaines intégrations. Comparez le montant du devis avec la charge de test incluse, les responsabilités attribuées et le travail restant pour prendre votre décision.
Si le produit change d’équipe, le dossier de reprise d’une base de code aide à établir qui peut construire, livrer et exploiter le correctif. Cette responsabilité doit être claire pour que la date du contre-audit devienne un engagement tenable.
Reprenez les deux propositions que vous comparez actuellement. Demandez aux prestataires de parcourir le même scénario et de marquer chaque question laissée ouverte. Attribuez le travail interne avant de confirmer la mission.
Préparons le test ensemble
Où nous plaçons la limite : nous préparons l’application et corrigeons ce que le rapport relève. Nous ne réalisons pas nous-mêmes le test d’intrusion et n’en validons pas les résultats ; cette évaluation reste confiée au spécialiste indépendant que vous mandatez.
Si une application héritée demande de la préparation technique ou des corrections autour d’un test indépendant, cadrez ce besoin avec notre offre Missions de sauvetage & Durcissement de code IA. Apportez le parcours, la proposition et les éléments disponibles sur le code. Les travaux d’ingénierie et le test d’intrusion indépendant doivent conserver des responsabilités explicites et distinctes.
Sources et limites
Sources consultées le 10 novembre 2026. Cette synthèse s’appuie sur le guide de commande du NCSC, les ressources de qualification de l’ANSSI et les références OWASP. Le portail et les propositions sont fictifs ; aucun tarif, qualification de prestataire, résultat ou vécu client d’IZZY n’est affirmé. Un pentest porte sur un périmètre et une période convenus. Son rapport et le contre-audit ne démontrent ni la sécurité de toute l’application, ni le respect de toutes les exigences contractuelles ou réglementaires.